From peterson.dean at gmail.com Sun May 1 22:56:00 2016 From: peterson.dean at gmail.com (Dean Peterson) Date: Sun, 1 May 2016 21:56:00 -0500 Subject: [keycloak-user] Token audience doesn't match domain Message-ID: I use openshift to apply a wildcard certificat to my routes to keycloak. I can add https that way. However, even though I can apply https to the route and hard code https into keycloak.json files for the auth-server-url, I get the Token audience doesn't match domain errors because some auto generated url by keycloak thinks everything is http. I really don't want to have to go through the work of setting up a keystore and everything else within wildfly when I really don't need it since my route in openshift handles the https part. Is there a way around this? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160501/98afbff4/attachment.html From jayapriya.atheesan at gmail.com Mon May 2 01:10:01 2016 From: jayapriya.atheesan at gmail.com (JAYAPRIYA ATHEESAN) Date: Mon, 2 May 2016 10:40:01 +0530 Subject: [keycloak-user] Modify Email template Message-ID: <5726e132.21dd420a.996d4.3958@mx.google.com> Hi Team, Any help would be highly appreciated. We are in critical stage of our project. Thanks, Jayapriya Atheesan From: JAYAPRIYA ATHEESAN [mailto:jayapriya.atheesan at gmail.com] Sent: Friday, April 29, 2016 10:06 PM To: 'keycloak-user at lists.jboss.org' Subject: Modify Email template Hi team, A mail is being sent from keycloak, when we enable verify option and password reset option. Someone has created a Giggzo account with this email address. If this was you, click the link below to verify your email address https://:8444/auth/realms/giggzo/login-actions/email-verification ?key=aKn9xARWV3hpXw_bjwfHwrGAcyGrhRx9vXAm4jICE8Y.e74ce8ec-8c36-4a3b-8fc6-bbe 5fd289ee1 This link will expire within 5 minutes. If you didn't create this account, just ignore this message. Is it possible to change this message content? And increase the expiry time from 5mins to 1hr. Thanks, Jayapriya Atheesan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160502/f1302581/attachment.html From jayapriya.atheesan at gmail.com Mon May 2 01:29:08 2016 From: jayapriya.atheesan at gmail.com (JAYAPRIYA ATHEESAN) Date: Mon, 2 May 2016 10:59:08 +0530 Subject: [keycloak-user] Keycloak redirection after email verification Message-ID: <5726e5ac.422e620a.3b0be.3bd2@mx.google.com> Hi, I'm facing issues with redirection to our application after email verification or password update. After the mail is verified, by the user clicking on the mail link, the flow is not getting redirected to our application How to handle this? Additionally, I would need information on how to modify the expiry time for the mail link. Is it possible to modify the url that is sent in mail? Thanks, Jayapriya Atheesan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160502/c5ccbfbb/attachment.html From mposolda at redhat.com Mon May 2 02:41:47 2016 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 2 May 2016 08:41:47 +0200 Subject: [keycloak-user] stand alone app connect to keycloak example In-Reply-To: References: Message-ID: <5726F6AB.4020302@redhat.com> "Standalone" means that it's non-browser application? If yes, then either direct-access-grants (See docs [1] or some of our examples - for example "admin-access-app" from preconfigured-demo). You can also take a look at CLI example from preconfigured-demo/customer-app-cli . [1] http://keycloak.github.io/docs/userguide/keycloak-server/html/direct-access-grants.html Marek On 29/04/16 21:34, Juan Diego wrote: > I have a small app, I was wondering if there is an example on how to > log from a standalone app to keycloak? > Thanks. > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160502/f88625ae/attachment.html From mposolda at redhat.com Mon May 2 02:47:49 2016 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 2 May 2016 08:47:49 +0200 Subject: [keycloak-user] Role Attributes In-Reply-To: References: Message-ID: <5726F815.2040403@redhat.com> Feel free to create JIRA. It may already exists, but not sure at 100%... You can also take a look at "protocol mappers" SPI and possibly create new protocolMapper implementation to achieve better what you need. Marek On 29/04/16 20:41, Brian Watson wrote: > Hi all, > > I know this may be a long shot, but is there any plan to support > attributes for roles? Use case: I am replacing a pre-existing > home-grown auth system with Keycloak. There is metadata associated > with the existing roles that is required by the services consuming the > JWS. I have a very hacky plan to support what I need via role > descriptions, but having role attributes would allow me to implement > this need is a cleaner fashion. > > Thoughts? > > Thanks! > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160502/a3ab3cb0/attachment-0001.html From mposolda at redhat.com Mon May 2 02:57:36 2016 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 2 May 2016 08:57:36 +0200 Subject: [keycloak-user] Modify Email template In-Reply-To: <5726e132.21dd420a.996d4.3958@mx.google.com> References: <5726e132.21dd420a.996d4.3958@mx.google.com> Message-ID: <5726FA60.6000006@redhat.com> You can take a look and possibly change the files: $KEYCLOAK_HOME/themes/base/email/html/email-verification.ftl $KEYCLOAK_HOME/themes/base/email/messages/messages_en.properties For the timeout see "Login action timeout" in the tab "Tokens" in admin console. Marek On 02/05/16 07:10, JAYAPRIYA ATHEESAN wrote: > > Hi Team, > > Any help would be highly appreciated. We are in critical stage of our > project. > > Thanks, > > Jayapriya Atheesan > > *From:*JAYAPRIYA ATHEESAN [mailto:jayapriya.atheesan at gmail.com] > *Sent:* Friday, April 29, 2016 10:06 PM > *To:* 'keycloak-user at lists.jboss.org' > *Subject:* Modify Email template > > Hi team, > > A mail is being sent from keycloak, when we enable verify option and > password reset option. > > Someone has created a Giggzo account with this email address. If this > was you, click the link below to verify your email address > > https://:8444/auth/realms/giggzo/login-actions/email-verification?key=aKn9xARWV3hpXw_bjwfHwrGAcyGrhRx9vXAm4jICE8Y.e74ce8ec-8c36-4a3b-8fc6-bbe5fd289ee1 > > > This link will expire within 5 minutes. > > If you didn't create this account, just ignore this message. > > Is it possible to change this message content? And increase the expiry > time from 5mins to 1hr. > > Thanks, > > Jayapriya Atheesan > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160502/ed38d1b9/attachment.html From mposolda at redhat.com Mon May 2 03:07:55 2016 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 2 May 2016 09:07:55 +0200 Subject: [keycloak-user] Keycloak redirection after email verification In-Reply-To: <5726e5ac.422e620a.3b0be.3bd2@mx.google.com> References: <5726e5ac.422e620a.3b0be.3bd2@mx.google.com> Message-ID: <5726FCCB.3000808@redhat.com> On 02/05/16 07:29, JAYAPRIYA ATHEESAN wrote: > > Hi, > > I?m facing issues with redirection to our application after email > verification or password update. > > After the mail is verified, by the user clicking on the mail link, the > flow is not getting redirected to our application > > How to handle this? > Isn't that because you start login from browser1 (for example Firefox), then login user, then you open thunderbird and click on the link for "Verify email", but the link is opened in different browser2 (For example Chrome)? The only way to handle this would be to use your "default" browser for login (Which is browser2 (chrome) in the example above, as that's the browser which was opened by thunderbird). Or copy the URL and open it manually in browser1 (Firefox). Marek > > Additionally, I would need information on how to modify the expiry > time for the mail link. Is it possible to modify the url that is sent > in mail? > > Thanks, > > Jayapriya Atheesan > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160502/284cfd40/attachment.html From sthorger at redhat.com Mon May 2 04:53:56 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 2 May 2016 10:53:56 +0200 Subject: [keycloak-user] Modify Email template In-Reply-To: <5726e132.21dd420a.996d4.3958@mx.google.com> References: <5726e132.21dd420a.996d4.3958@mx.google.com> Message-ID: All emails comes from message bundles in the email theme. Create your own theme with a message bundle and override the email you want to change. Then set it as the email theme for your realm. You can also set the timeout for the realm under token Hi Team, Any help would be highly appreciated. We are in critical stage of our project. Thanks, Jayapriya Atheesan *From:* JAYAPRIYA ATHEESAN [mailto:jayapriya.atheesan at gmail.com] *Sent:* Friday, April 29, 2016 10:06 PM *To:* 'keycloak-user at lists.jboss.org' *Subject:* Modify Email template Hi team, A mail is being sent from keycloak, when we enable verify option and password reset option. Someone has created a Giggzo account with this email address. If this was you, click the link below to verify your email address https://:8444/auth/realms/giggzo/login-actions/email-verification?key=aKn9xARWV3hpXw_bjwfHwrGAcyGrhRx9vXAm4jICE8Y.e74ce8ec-8c36-4a3b-8fc6-bbe5fd289ee1 This link will expire within 5 minutes. If you didn't create this account, just ignore this message. Is it possible to change this message content? And increase the expiry time from 5mins to 1hr. Thanks, Jayapriya Atheesan _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160502/6ffe86b5/attachment.html From sthorger at redhat.com Mon May 2 04:54:41 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 2 May 2016 10:54:41 +0200 Subject: [keycloak-user] Modify Email template Message-ID: Don't modify built-in themes, we recommend creating your own theme to override. On 2 May 2016 08:59, "Marek Posolda" wrote: You can take a look and possibly change the files: $KEYCLOAK_HOME/themes/base/email/html/email-verification.ftl $KEYCLOAK_HOME/themes/base/email/messages/messages_en.properties For the timeout see "Login action timeout" in the tab "Tokens" in admin console. Marek On 02/05/16 07:10, JAYAPRIYA ATHEESAN wrote: Hi Team, Any help would be highly appreciated. We are in critical stage of our project. Thanks, Jayapriya Atheesan *From:* JAYAPRIYA ATHEESAN [mailto:jayapriya.atheesan at gmail.com ] *Sent:* Friday, April 29, 2016 10:06 PM *To:* 'keycloak-user at lists.jboss.org' *Subject:* Modify Email template Hi team, A mail is being sent from keycloak, when we enable verify option and password reset option. Someone has created a Giggzo account with this email address. If this was you, click the link below to verify your email address https:// :8444/auth/realms/giggzo/login-actions/email-verification?key=aKn9xARWV3hpXw_bjwfHwrGAcyGrhRx9vXAm4jICE8Y.e74ce8ec-8c36-4a3b-8fc6-bbe5fd289ee1 This link will expire within 5 minutes. If you didn't create this account, just ignore this message. Is it possible to change this message content? And increase the expiry time from 5mins to 1hr. Thanks, Jayapriya Atheesan _______________________________________________ keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160502/9eca3514/attachment-0001.html From jayapriya.atheesan at gmail.com Mon May 2 06:49:05 2016 From: jayapriya.atheesan at gmail.com (JAYAPRIYA ATHEESAN) Date: Mon, 2 May 2016 16:19:05 +0530 Subject: [keycloak-user] Modify Email template In-Reply-To: References: Message-ID: <572730a6.8e43620a.a9ed4.7380@mx.google.com> Sure.. Thanks for your suggestion. Thanks, Jayapriya Atheesan From: Stian Thorgersen [mailto:sthorger at redhat.com] Sent: Monday, May 2, 2016 2:25 PM To: Posolda, Marek Cc: keycloak-user; JAYAPRIYA ATHEESAN Subject: Re: [keycloak-user] Modify Email template Don't modify built-in themes, we recommend creating your own theme to override. On 2 May 2016 08:59, "Marek Posolda" wrote: You can take a look and possibly change the files: $KEYCLOAK_HOME/themes/base/email/html/email-verification.ftl $KEYCLOAK_HOME/themes/base/email/messages/messages_en.properties For the timeout see "Login action timeout" in the tab "Tokens" in admin console. Marek On 02/05/16 07:10, JAYAPRIYA ATHEESAN wrote: Hi Team, Any help would be highly appreciated. We are in critical stage of our project. Thanks, Jayapriya Atheesan From: JAYAPRIYA ATHEESAN [mailto:jayapriya.atheesan at gmail.com] Sent: Friday, April 29, 2016 10:06 PM To: 'keycloak-user at lists.jboss.org' Subject: Modify Email template Hi team, A mail is being sent from keycloak, when we enable verify option and password reset option. Someone has created a Giggzo account with this email address. If this was you, click the link below to verify your email address https:// :8444/auth/realms/giggzo/login-actions/email-verification?key=aKn9xARWV3hpXw_bjwfHwrGAcyGrhRx9vXAm4jICE8Y.e74ce8ec-8c36-4a3b-8fc6-bbe5fd289ee1 This link will expire within 5 minutes. If you didn't create this account, just ignore this message. Is it possible to change this message content? And increase the expiry time from 5mins to 1hr. Thanks, Jayapriya Atheesan _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160502/3acb9c71/attachment.html From jayapriya.atheesan at gmail.com Mon May 2 08:24:27 2016 From: jayapriya.atheesan at gmail.com (JAYAPRIYA ATHEESAN) Date: Mon, 2 May 2016 17:54:27 +0530 Subject: [keycloak-user] Session time out - Redirection Message-ID: <572746ff.9b41620a.acc68.ffffa248@mx.google.com> Hi Team, I have set session time out value to 1minute. Now after 1 we get errors. To be clear. If a person clicks on login button the url gets redirected to keycloak.. After sometime if the person tries to perform some action, the url would have got expired. That is why we face "An error occurred please try to login through your application". Instead of this we need to refresh the page and show to the user to login or redirect to our application index.html page. How to do this?. cid:image007.png at 01D1A469.D3367D60 Thanks, Jayapriya Atheesan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160502/b7dad86e/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 63241 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160502/b7dad86e/attachment-0001.png From jayapriya.atheesan at gmail.com Mon May 2 09:11:19 2016 From: jayapriya.atheesan at gmail.com (JAYAPRIYA ATHEESAN) Date: Mon, 2 May 2016 18:41:19 +0530 Subject: [keycloak-user] Password reset redirection Message-ID: <572751fb.e681420a.a20ab.ffffb02c@mx.google.com> Hi Team, We have UI written in angular JS. We have integrated the same with keycloak for authentication and authorization. When we follow the reset password link, a mail is sent to the associated user's email id. When I click on the link sent for password reset, a page opens up for providing new password. After I submit the password change request, the application just changes the password. But the problem is that, it does not login to our application dashboard. If we click on login button, the user gets logged in. How to make the application seamlessly go to the dashboard? By going through the files shared by your team in example, we see that we cannot capture the onsuccess. Onlogin method goes through, but it is not being redirected. Is it possible to specify the url to be redirected after successful password reset? The flow reaches the below part We expect that the flow should go through the below method, but it doesn't happen. keycloakAuth.onAuthSuccess = function () { $rootScope.authLogin = true; console.log('coming in auth success'); loginService.login(keycloakAuth); $rootScope.dataloading = true; }; Thanks, Jayapriya Atheesan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160502/e85de67f/attachment.html From jayapriya.atheesan at gmail.com Mon May 2 09:12:36 2016 From: jayapriya.atheesan at gmail.com (JAYAPRIYA ATHEESAN) Date: Mon, 2 May 2016 18:42:36 +0530 Subject: [keycloak-user] Password reset redirection Message-ID: <57275248.1a45620a.83d75.ffffa36c@mx.google.com> Hi Team, We have UI written in angular JS. We have integrated the same with keycloak for authentication and authorization. When we follow the reset password link, a mail is sent to the associated user's email id. When I click on the link sent for password reset, a page opens up for providing new password. After I submit the password change request, the application just changes the password. But the problem is that, it does not login to our application dashboard. If we click on login button, the user gets logged in. How to make the application seamlessly go to the dashboard? By going through the files shared by your team in example, we see that we cannot capture the onsuccess. Onlogin method goes through, but it is not being redirected. Is it possible to specify the url to be redirected after successful password reset? The flow reaches the below part var kInit = function () { keycloakAuth.init().success(function () { $rootScope.keycloak = keycloakAuth; console.log('token = ' + keycloakAuth.token); }).error(function () { //console.log("failed to intialize"); }); }; kInit(); We expect that the flow should go through the below method also, but it doesn't happen. keycloakAuth.onAuthSuccess = function () { $rootScope.authLogin = true; console.log('coming in auth success'); loginService.login(keycloakAuth); $rootScope.dataloading = true; }; Thanks, Jayapriya Atheesan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160502/0a4ed929/attachment.html From jayapriya.atheesan at gmail.com Mon May 2 09:12:51 2016 From: jayapriya.atheesan at gmail.com (JAYAPRIYA ATHEESAN) Date: Mon, 2 May 2016 18:42:51 +0530 Subject: [keycloak-user] Recall: Password reset redirection Message-ID: JAYAPRIYA ATHEESAN would like to recall the message, "Password reset redirection". -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 1001 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160502/542f9edd/attachment.bin From jayapriya.atheesan at gmail.com Mon May 2 09:13:55 2016 From: jayapriya.atheesan at gmail.com (JAYAPRIYA ATHEESAN) Date: Mon, 2 May 2016 18:43:55 +0530 Subject: [keycloak-user] Keycloak redirection after email verification In-Reply-To: <5726FCCB.3000808@redhat.com> References: <5726e5ac.422e620a.3b0be.3bd2@mx.google.com> <5726FCCB.3000808@redhat.com> Message-ID: <57275296.8246620a.39bf0.4583@mx.google.com> Using the same browser for both signup and verification resolved the issue. Thanks, Jayapriya Atheesan From: Marek Posolda [mailto:mposolda at redhat.com] Sent: Monday, May 2, 2016 12:38 PM To: JAYAPRIYA ATHEESAN; keycloak-user at lists.jboss.org Subject: Re: [keycloak-user] Keycloak redirection after email verification On 02/05/16 07:29, JAYAPRIYA ATHEESAN wrote: Hi, I'm facing issues with redirection to our application after email verification or password update. After the mail is verified, by the user clicking on the mail link, the flow is not getting redirected to our application How to handle this? Isn't that because you start login from browser1 (for example Firefox), then login user, then you open thunderbird and click on the link for "Verify email", but the link is opened in different browser2 (For example Chrome)? The only way to handle this would be to use your "default" browser for login (Which is browser2 (chrome) in the example above, as that's the browser which was opened by thunderbird). Or copy the URL and open it manually in browser1 (Firefox). Marek Additionally, I would need information on how to modify the expiry time for the mail link. Is it possible to modify the url that is sent in mail? Thanks, Jayapriya Atheesan _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160502/61f92756/attachment-0001.html From aikeaguinea at xsmail.com Mon May 2 10:01:52 2016 From: aikeaguinea at xsmail.com (Aikeaguinea) Date: Mon, 02 May 2016 10:01:52 -0400 Subject: [keycloak-user] Authorization code flow without a browser In-Reply-To: <1461952699.3554231.593643321.79570F43@webmail.messagingengine.com> References: <1461770250.3043050.591261689.255D8ED8@webmail.messagingengine.com> <1461858810.3020988.592457473.4BD3BFED@webmail.messagingengine.com> <1461952699.3554231.593643321.79570F43@webmail.messagingengine.com> Message-ID: <1462197712.1267693.595600905.18E59637@webmail.messagingengine.com> I should add that both the OAuth 2.0 spec and the OpenID Connect 1.0 spec indicate that the in the authorization code flow the access token is not revealed to the user agent (see RFC-6749 section 1.3.1 and Open ID Connect Core 1.0 at the top of section 3). Passing the access token to the user agent removes the security benefit of using this flow. Does Keycloak support a flow where the access token is not passed to the user agent? On Fri, Apr 29, 2016, at 01:58 PM, Aikeaguinea wrote: > I understand that RFC-6749 only says that the user agent is typically > a browser, but that's not a requirement of the spec. In this case, it > isn't going to be. > > The security advantage of the authorization code flow is that the > access token is transmitted directly to the client application without > passing it through the resource owner's user agent. The request for > the access token is made on the server side, and there is no > requirement that the access token then be passed back to the user > agent. Once the server validates the access token, it can consider the > user's session as logged in and can associate that session with the > permissions returned to it in the access token. If session state is > held on the server, the user's session identifier then need contain no > information about the user's ID and permissions; if the session > information is maintained on the client side, the user's session token > can be encrypted, which is not currently the case with Keycloak's > signed JWT tokens. > > > On Fri, Apr 29, 2016, at 12:13 AM, Stian Thorgersen wrote: >> >> >> On 28 April 2016 at 17:53, Aikeaguinea >> wrote: >>> __ >>> We have something of a special case. We have privileged devices for >>> which we will use service accounts and certificates/JWT based >>> authentication. >>> >>> Then we will have a user (employee of ours) perform a second log in >>> to the application running on the device. The particulars don't >>> allow us to use a browser in this instance. (For one thing, the >>> user's credentials are not a username/password -- I've had to create >>> a special authenticator for this purpose. But this isn't the only >>> reason.) So, to Brian's question, we are not embedding these >>> credentials in our code. >> >> That would normally be an argument for using a browser. Using an >> embedded browser allows you to enable different authentication modes >> in Keycloak without modifying your applications. Keycloak has built- >> in support for authentication Kerberos tickets for example, all >> without the applications knowledge. >> >>> >>> >>> Since the device is trusted, we could use the password credentials >>> grant. However, since this is a fairly high-security situation we'd >>> prefer not to be sending access tokens over the wire, particularly >>> if we're only relying on TLS for encrypting the token. >> >> If you're not sending access tokens over the wire, what are you >> sending over the wire? That's how Keycloak works and an access token >> is always going to be sent over the wire. Doesn't matter what flow >> you use. You can choose exactly what goes into the token though. >> >>> >>> >>> We could, on the other hand, use the authorization code flow--I'd >>> just have to follow the redirects and dig the form action out of the >>> form that's returned in the challenge page. I was just wondering if >>> there was some way to access that URL other than by chomping on the >>> HTML, e.g., by using a different "Accept:" header. >> >> The?authorization?code flows is by design a purely browser flow. >> Using this outside of the browser isn't the correct approach. The >> direct access grant (resource owner credentials) is the flow you want >> to use if you're not going to use a browser. >> >>> >>> >>> >>> On Thu, Apr 28, 2016, at 12:58 AM, Stian Thorgersen wrote: >>>> The answer depends on what your code is doing: >>>> >>>> a) Is it a server not invoking services on behalf of users, but >>>> rather on behalf of itself? Then use service accounts and you >>>> can also use public/private key based auth here (client >>>> credential flow from oauth2). >>>> b) Is it a user logging in through a non-browser based application? >>>> Then the ideal option if possible is to embed a web browser and >>>> use the authorization code flow. The alternative is to use >>>> direct grant (resource owner credential grant flow from oauth2). >>>> c) Is it a background process invoking a service on behalf of users >>>> when the users are not online? Then use offline tokens. >>>> >>>> On 27 April 2016 at 17:17, Aikeaguinea >>>> wrote: >>>>> As I understand it, using the authorization code flow rather >>>>> than the >>>>> implicit flow is recommended where possible. >>>>> >>>>> We have a server-side client application, but the user agents >>>>> making >>>>> requests are not browsers, but instead our own code. >>>>> >>>>> I'm not entirely sure how to make the authorization code flow work >>>>> without a browser. For instance, if on the command line I request >>>>> >>>>> curl >>>>> ' >>>>> http://host:port/auth/realms/foo/protocol/openid-connect/auth?response_type=code&client_id=test-client&state=state&redirect_uri=http://www.example.com/hello-world' >>>>> >>>>> Then (assuming the parameters are correct) I get back an HTML >>>>> login page >>>>> with a form. In order to submit the credentials, I would need to >>>>> dig the >>>>> URL out of the action of the form and then submit a request like >>>>> >>>>> curl -X POST -d 'username=test-user' -d 'password=test1234' >>>>> ' >>>>> http://host:port/auth/realms/foo/login-actions/authenticate?code=Ctr79aRsbwPPkC4nEeT2vR9-TuC31uuXngQXoHQH6FE.ef26cfcd-a35b-4d1e-a4f7-49790f6e2f00&execution=a86f56da-9900-4f1d-a461-f18617a2333b' >>>>> >>>>> Three questions: >>>>> 1. Is there some reason I shouldn't be trying to implement the >>>>> authorization code flow like this? >>>>> >>>>> 2. Is there a way to get the proper login action back without >>>>> having to >>>>> dig it out of an HTML form? I've tried adding --header "Accept: >>>>> application/json" to the command but this has no effect. >>>>> >>>>> 3. Is there a way of submitting credentials other than by using >>>>> form >>>>> parameters? I've tried HTTP basic auth but it doesn't work for me. > > -- http://www.fastmail.com - Send your email first class > -- Aikeaguinea aikeaguinea at xsmail.com -- http://www.fastmail.com - A fast, anti-spam email service. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160502/8dc8fa58/attachment.html From mposolda at redhat.com Mon May 2 10:20:55 2016 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 2 May 2016 16:20:55 +0200 Subject: [keycloak-user] Password reset redirection In-Reply-To: <57275248.1a45620a.83d75.ffffa36c@mx.google.com> References: <57275248.1a45620a.83d75.ffffa36c@mx.google.com> Message-ID: <57276247.4060800@redhat.com> It seems that what you need is to call keycloak.init with 'check-sso' flag. Something like this: keycloak.init({ onLoad: 'check-sso' }) See docs for some more details http://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#javascript-adapter . With the 'check-sso' option, the javascript adapter will try to redirect to KEycloak server and see if user was already logged-in to keycloak through SSO (which is the case after successful registration). If he is logged, the keycloak will redirect back to application with the login success (code+state) and javascript application will be logged-in automatically. Marek On 02/05/16 15:12, JAYAPRIYA ATHEESAN wrote: > > Hi Team, > > We have UI written in angular JS. We have integrated the same with > keycloak for authentication and authorization. > > When we follow the reset password link, a mail is sent to the > associated user?s email id. When I click on the link sent for password > reset, a page opens up for providing new password. > > After I submit the password change request, the application just > changes the password. But the problem is that, it does not login to > our application dashboard. If we click on login button, the user gets > logged in. > > How to make the application seamlessly go to the dashboard? By going > through the files shared by your team in example, we see that we > cannot capture the onsuccess. > > Onlogin method goes through, but it is not being redirected. Is it > possible to specify the url to be redirected after successful > password reset? > > The flow reaches the below part > > var kInit = function () { > > keycloakAuth.init().success(function () { > > $rootScope.keycloak = keycloakAuth; > > console.log('token = ' + keycloakAuth.token); > > }).error(function () { > > //console.log("failed to intialize"); > > }); > > }; > > kInit(); > > We expect that the flow should go through the below methodalso, but it > doesn?t happen. > > keycloakAuth.onAuthSuccess = function () { > > $rootScope.authLogin = true; > > console.log('coming in auth success'); > > loginService.login(keycloakAuth); > > $rootScope.dataloading = true; > > }; > > Thanks, > > Jayapriya Atheesan > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160502/02112b55/attachment-0001.html From jayapriya.atheesan at gmail.com Mon May 2 10:54:58 2016 From: jayapriya.atheesan at gmail.com (JAYAPRIYA ATHEESAN) Date: Mon, 2 May 2016 20:24:58 +0530 Subject: [keycloak-user] Issue in logging in with identity provider after session time out. Message-ID: <57276a46.c459620a.9412f.fffff5f1@mx.google.com> Hi Team, We are testing session timed out feature, and I have set my "login timeout" to 10seconds. If I click on login after 10sec, I get an error saying "YOUR LOGIN TOOK TOO MUCH TIME TO PROCESS". After which if I give my user credentials, the login happens. But I I use social media to login, I get the below error. And even if I try to close it and click on login again, I get the same issue. Unless and until I type my application url , this issue is not going through. The flow stops here https:// :8444/auth/realms/giggzo/broker/facebook/login?code=Y5DU748Sx0YL19 3xRYcv7bQHpvKAV8VlYAVfl2Pbd-4.63d5ab87-a882-4d54-8bed-126ac2cbfa89 Each time, we don't want our users to give the entire url to get the login page again. How to resolve this issue? Thanks, Jayapriya Atheesan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160502/d91ff2a8/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 79123 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160502/d91ff2a8/attachment-0001.png From bcook at redhat.com Mon May 2 16:30:47 2016 From: bcook at redhat.com (Brian Cook) Date: Mon, 2 May 2016 13:30:47 -0700 Subject: [keycloak-user] Authorization code flow without a browser In-Reply-To: <1462197712.1267693.595600905.18E59637@webmail.messagingengine.com> References: <1461770250.3043050.591261689.255D8ED8@webmail.messagingengine.com> <1461858810.3020988.592457473.4BD3BFED@webmail.messagingengine.com> <1461952699.3554231.593643321.79570F43@webmail.messagingengine.com> <1462197712.1267693.595600905.18E59637@webmail.messagingengine.com> Message-ID: In auth code flow the authorization code is passed back as a URL parameter to the redirect uri. The oauth client then uses the client ID, secret and auth code to request the access token. I think the confusion was you said 'over the wire'. The access code is transmitted over the wire but not to the user agent. -Brian On May 2, 2016 7:02 AM, "Aikeaguinea" wrote: > I should add that both the OAuth 2.0 spec and the OpenID Connect 1.0 spec > indicate that the in the authorization code flow the access token is not > revealed to the user agent (see RFC-6749 section 1.3.1 and Open ID Connect > Core 1.0 at the top of section 3). Passing the access token to the user > agent removes the security benefit of using this flow. > > Does Keycloak support a flow where the access token is not passed to the > user agent? > > > On Fri, Apr 29, 2016, at 01:58 PM, Aikeaguinea wrote: > > I understand that RFC-6749 only says that the user agent is typically a > browser, but that's not a requirement of the spec. In this case, it isn't > going to be. > > The security advantage of the authorization code flow is that the access > token is transmitted directly to the client application without passing it > through the resource owner's user agent. The request for the access token > is made on the server side, and there is no requirement that the access > token then be passed back to the user agent. Once the server validates the > access token, it can consider the user's session as logged in and can > associate that session with the permissions returned to it in the access > token. If session state is held on the server, the user's session > identifier then need contain no information about the user's ID and > permissions; if the session information is maintained on the client side, > the user's session token can be encrypted, which is not currently the case > with Keycloak's signed JWT tokens. > > > On Fri, Apr 29, 2016, at 12:13 AM, Stian Thorgersen wrote: > > > > On 28 April 2016 at 17:53, Aikeaguinea wrote: > > > We have something of a special case. We have privileged devices for which > we will use service accounts and certificates/JWT based authentication. > > Then we will have a user (employee of ours) perform a second log in to the > application running on the device. The particulars don't allow us to use a > browser in this instance. (For one thing, the user's credentials are not a > username/password -- I've had to create a special authenticator for this > purpose. But this isn't the only reason.) So, to Brian's question, we are > not embedding these credentials in our code. > > > That would normally be an argument for using a browser. Using an embedded > browser allows you to enable different authentication modes in Keycloak > without modifying your applications. Keycloak has built-in support for > authentication Kerberos tickets for example, all without the applications > knowledge. > > > > > Since the device is trusted, we could use the password credentials grant. > However, since this is a fairly high-security situation we'd prefer not to > be sending access tokens over the wire, particularly if we're only relying > on TLS for encrypting the token. > > > If you're not sending access tokens over the wire, what are you sending > over the wire? That's how Keycloak works and an access token is always > going to be sent over the wire. Doesn't matter what flow you use. You can > choose exactly what goes into the token though. > > > > > We could, on the other hand, use the authorization code flow--I'd just > have to follow the redirects and dig the form action out of the form that's > returned in the challenge page. I was just wondering if there was some way > to access that URL other than by chomping on the HTML, e.g., by using a > different "Accept:" header. > > > The authorization code flows is by design a purely browser flow. Using > this outside of the browser isn't the correct approach. The direct access > grant (resource owner credentials) is the flow you want to use if you're > not going to use a browser. > > > > > > On Thu, Apr 28, 2016, at 12:58 AM, Stian Thorgersen wrote: > > The answer depends on what your code is doing: > > a) Is it a server not invoking services on behalf of users, but rather on > behalf of itself? Then use service accounts and you can also use > public/private key based auth here (client credential flow from oauth2). > b) Is it a user logging in through a non-browser based application? Then > the ideal option if possible is to embed a web browser and use the > authorization code flow. The alternative is to use direct grant (resource > owner credential grant flow from oauth2). > c) Is it a background process invoking a service on behalf of users when > the users are not online? Then use offline tokens. > > On 27 April 2016 at 17:17, Aikeaguinea wrote: > > As I understand it, using the authorization code flow rather than the > implicit flow is recommended where possible. > > We have a server-side client application, but the user agents making > requests are not browsers, but instead our own code. > > I'm not entirely sure how to make the authorization code flow work > without a browser. For instance, if on the command line I request > > curl > 'http://host:port > /auth/realms/foo/protocol/openid-connect/auth?response_type=code&client_id=test-client&state=state&redirect_uri= > http://www.example.com/hello-world' > > Then (assuming the parameters are correct) I get back an HTML login page > with a form. In order to submit the credentials, I would need to dig the > URL out of the action of the form and then submit a request like > > curl -X POST -d 'username=test-user' -d 'password=test1234' > 'http://host:port > /auth/realms/foo/login-actions/authenticate?code=Ctr79aRsbwPPkC4nEeT2vR9-TuC31uuXngQXoHQH6FE.ef26cfcd-a35b-4d1e-a4f7-49790f6e2f00&execution=a86f56da-9900-4f1d-a461-f18617a2333b' > > Three questions: > 1. Is there some reason I shouldn't be trying to implement the > authorization code flow like this? > > 2. Is there a way to get the proper login action back without having to > dig it out of an HTML form? I've tried adding --header "Accept: > application/json" to the command but this has no effect. > > 3. Is there a way of submitting credentials other than by using form > parameters? I've tried HTTP basic auth but it doesn't work for me. > > > > -- http://www.fastmail.com - Send your email first class > > > -- > Aikeaguinea > aikeaguinea at xsmail.com > > > > > -- http://www.fastmail.com - A fast, anti-spam email service. > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160502/8bd48496/attachment.html From jaxley at expedia.com Mon May 2 16:33:23 2016 From: jaxley at expedia.com (Jason Axley) Date: Mon, 2 May 2016 20:33:23 +0000 Subject: [keycloak-user] Keycloak admin role to group not working Message-ID: <729B2DAE-CF52-426D-9DD3-534CCF9EBB01@expedia.com> I have an LDAP user who is definitely listed as being in a given LDAP group in Keycloak admin console. If I grant the User the admin Realm Role in the master realm, they can login and access the admin console for the master realm. However, if I remove the direct role grant from the user and add it to the LDAP group, keycloak doesn?t think the user has the role and gives an error that the user ?You don't have access to the requested resource.? with the below exception: 2016-05-02 20:25:37,677 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-2) RESTEASY002005: Failed executing GET /admin/serverinfo: org.keycloak.services.ForbiddenException at org.keycloak.services.resources.admin.AdminRoot.getServerInfo(AdminRoot.java:231) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:79) at org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:58) at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:100) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:78) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Is there something magical that needs to be configured for this to work? Or does this look like a bug? I also did a quick test where I created a new local group and did the same role assignment to the group, and assigned the group to the same LDAP user and it did not grant access. -Jason Jason Axley Sr. Security Engineer, Expedia Worldwide Engineering Team 425-679-4157 (o) | 206-484-2778 (m) | 206-55-AXLEY (gv) 333 108th Ave NE, 9S-282, Bellevue, WA 98004 EWE Security Wiki -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160502/86ad7f3f/attachment-0001.html From jaxley at expedia.com Mon May 2 17:02:38 2016 From: jaxley at expedia.com (Jason Axley) Date: Mon, 2 May 2016 21:02:38 +0000 Subject: [keycloak-user] Control which user profile attributes can be changed by the user Message-ID: <7AA5ACD5-A5BE-4D2F-AA03-9A06C85737D1@expedia.com> I did not see any way to set a policy for which user profile attributes the user can change. The account management UI displays all of the information in edit input boxes and presumably lets users change anything including name, email, etc. What if I want to restrict which data users can change based on possibly their group or role? Is that at all possible? -Jason Jason Axley Sr. Security Engineer, Expedia Worldwide Engineering Team 425-679-4157 (o) | 206-484-2778 (m) | 206-55-AXLEY (gv) 333 108th Ave NE, 9S-282, Bellevue, WA 98004 EWE Security Wiki -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160502/2ba6333f/attachment.html From James_Saxton at ao.uscourts.gov Mon May 2 17:04:21 2016 From: James_Saxton at ao.uscourts.gov (James_Saxton at ao.uscourts.gov) Date: Mon, 2 May 2016 17:04:21 -0400 Subject: [keycloak-user] Getting Started Message-ID: Hey, I installed keycloak 1.9.3. Final, and the app seems to start ok, I can render the banner UI in a browser and click the admin link, once the admin rage tried to render, it only shows {{notification.header}} {{notification.message}} I did use add-user-keycloak.sh. I can see the creds get added to the correct *.json file This is an install on linux RHEL 6.using keycloak-1.9.3.Final ( step 3.1.1 ) from the docs. Any hints as to the missing Admin UI? The only message I see in the logs is this .... 20:51:44,692 WARN [org.hibernate.dialect.H2Dialect] (ServerService Thread Pool -- 53) HHH000431: Unable to determine H2 database version, certain features may not work and I cannot seem to locate any direction using google. Thanks in advance for your help! James Saxton Software Infrastructure Division Administrative Office of the U.S. Courts One Columbus Circle, N.E. Washington, DC 20544 (C) 908-910-5566 Teamwork makes the dream work! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160502/722ac825/attachment.html From peterson.dean at gmail.com Mon May 2 20:08:38 2016 From: peterson.dean at gmail.com (Dean Peterson) Date: Mon, 2 May 2016 19:08:38 -0500 Subject: [keycloak-user] upgrade to 1.9.3 "Property "databaseSchema" needs to be specified error (but it is) Message-ID: I get this error when migrating my database and upgrading to 1.9.3: "Property 'databaseSchema' needs to be specified in the configuration I have this in my keycloak-server.json file: "connectionsMongo": { "default": { "host": "xx.xx.xx.xx", "port": "27017", "db": "keycloaktest", "databaseSchema": "update" } } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160502/1fb92a95/attachment.html From peterson.dean at gmail.com Mon May 2 20:32:06 2016 From: peterson.dean at gmail.com (Dean Peterson) Date: Mon, 2 May 2016 19:32:06 -0500 Subject: [keycloak-user] upgrade to 1.9.3 "Property "databaseSchema" needs to be specified error (but it is) In-Reply-To: References: Message-ID: The error was misleading. The userSessionPersister needed to be mongo instead of jpa. The documentation said: " However in all cases, you will need to update standalone/configuration/keycloak-server.json and add userSessionPersister like this:" "userSessionPersister": { "provider": "jpa" }, On Mon, May 2, 2016 at 7:08 PM, Dean Peterson wrote: > I get this error when migrating my database and upgrading to 1.9.3: > "Property 'databaseSchema' needs to be specified in the configuration > > I have this in my keycloak-server.json file: > > "connectionsMongo": { > "default": { > "host": "xx.xx.xx.xx", > "port": "27017", > "db": "keycloaktest", > "databaseSchema": "update" > } > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160502/ed172ff2/attachment.html From peterson.dean at gmail.com Mon May 2 20:49:36 2016 From: peterson.dean at gmail.com (Dean Peterson) Date: Mon, 2 May 2016 19:49:36 -0500 Subject: [keycloak-user] Import of v1.3.1 export to v1.9.3 does not work Message-ID: I get no errors; but 0 users are imported. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160502/8c734bc0/attachment.html From peterson.dean at gmail.com Mon May 2 21:03:51 2016 From: peterson.dean at gmail.com (Dean Peterson) Date: Mon, 2 May 2016 20:03:51 -0500 Subject: [keycloak-user] Import of v1.3.1 export to v1.9.3 does not work In-Reply-To: References: Message-ID: Nevermind, I got it working. On Mon, May 2, 2016 at 7:49 PM, Dean Peterson wrote: > I get no errors; but 0 users are imported. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160502/cade0a17/attachment.html From thomas_connolly at yahoo.com Tue May 3 01:41:43 2016 From: thomas_connolly at yahoo.com (Thomas Connolly) Date: Tue, 3 May 2016 05:41:43 +0000 (UTC) Subject: [keycloak-user] Production deployment - without exposing admin gui References: <60356427.6652478.1462254103511.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <60356427.6652478.1462254103511.JavaMail.yahoo@mail.yahoo.com> Hi Please advise on the approach to deploying KC where the Admin GUI and APIs are not exposed. We want to control what is exposed onto the internet and what is available within the organisation.The flows are exposed but the admin gui / api are only accessible within the organisation. Currently we're considering filtering at the load balancer essentially whitelisting traffic.The admin GUI is accessed internally within the organisation. Alternatively is there a way to config off admin ui & api and only deploy this into production? With the admin deployed internally??Regards Tom Connolly. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160503/fea9be61/attachment-0001.html From sthorger at redhat.com Tue May 3 02:00:48 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 3 May 2016 08:00:48 +0200 Subject: [keycloak-user] Production deployment - without exposing admin gui In-Reply-To: <60356427.6652478.1462254103511.JavaMail.yahoo@mail.yahoo.com> References: <60356427.6652478.1462254103511.JavaMail.yahoo.ref@mail.yahoo.com> <60356427.6652478.1462254103511.JavaMail.yahoo@mail.yahoo.com> Message-ID: We are planning to make the admin console/endpoints exposed on a separate bind address and port in the future, but for now this has to be done with a proxy/loadbalancer/firewall. On 3 May 2016 at 07:41, Thomas Connolly wrote: > Hi > > Please advise on the approach to deploying KC where the Admin GUI and APIs > are not exposed. > > We want to control what is exposed onto the internet and what is available > within the organisation. > The flows are exposed but the admin gui / api are only accessible within > the organisation. > > Currently we're considering filtering at the load balancer essentially > whitelisting traffic. > The admin GUI is accessed internally within the organisation. > > Alternatively is there a way to config off admin ui & api and only deploy > this into production? With the admin deployed internally? > > Regards Tom Connolly. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160503/2dfd9a2a/attachment.html From sthorger at redhat.com Tue May 3 02:01:42 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 3 May 2016 08:01:42 +0200 Subject: [keycloak-user] Control which user profile attributes can be changed by the user In-Reply-To: <7AA5ACD5-A5BE-4D2F-AA03-9A06C85737D1@expedia.com> References: <7AA5ACD5-A5BE-4D2F-AA03-9A06C85737D1@expedia.com> Message-ID: Afraid this is not possible at the moment, feel free to create a JIRA On 2 May 2016 at 23:02, Jason Axley wrote: > I did not see any way to set a policy for which user profile attributes > the user can change. The account management UI displays all of the > information in edit input boxes and presumably lets users change anything > including name, email, etc. What if I want to restrict which data users > can change based on possibly their group or role? Is that at all possible? > > -Jason > > *Jason Axley* > > Sr. Security Engineer, Expedia Worldwide Engineering Team > > 425-679-4157 (o) | 206-484-2778 (m) | 206-55-AXLEY (gv) > > 333 108th Ave NE, 9S-282, Bellevue, WA 98004 > > EWE Security Wiki > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160503/e55ac22e/attachment.html From sthorger at redhat.com Tue May 3 02:08:28 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 3 May 2016 08:08:28 +0200 Subject: [keycloak-user] Session time out - Redirection In-Reply-To: <572746ff.9b41620a.acc68.ffffa248@mx.google.com> References: <572746ff.9b41620a.acc68.ffffa248@mx.google.com> Message-ID: I honestly have no clue what you're asking about here. Setting session timeout value to 1 minute makes no sense. On 2 May 2016 at 14:24, JAYAPRIYA ATHEESAN wrote: > Hi Team, > > > > I have set session time out value to 1minute. Now after 1 we get errors. > To be clear. > > > > If a person clicks on login button the url gets redirected to keycloak.. > After sometime if the person tries to perform some action, the url would > have got expired. That is why we face > > ?An error occurred please try to login through your application?. Instead > of this we need to refresh the page and show to the user to login or > redirect to our application index.html page. How to do this?. > > > > > > [image: cid:image007.png at 01D1A469.D3367D60] > > > > Thanks, > > Jayapriya Atheesan > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160503/cd28fad7/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 63241 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160503/cd28fad7/attachment-0001.png From anunay.sinha at arvindinternet.com Tue May 3 02:08:57 2016 From: anunay.sinha at arvindinternet.com (Anunay Sinha) Date: Tue, 03 May 2016 06:08:57 +0000 Subject: [keycloak-user] Auto login after registration Message-ID: Hi We are using Keycloak 1.5.0 and are looking for a feature where user gets logged in automatically once they do registration. Is it possible to do that? We can try to capture the password at time of registration and do the login for the user Some how this idea of capturing information which is not meant for us in the first place just doesn't seem right. Is there a way we can do this? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160503/ef6933ed/attachment.html From mposolda at redhat.com Tue May 3 03:08:04 2016 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 3 May 2016 09:08:04 +0200 Subject: [keycloak-user] Auto login after registration In-Reply-To: References: Message-ID: <57284E54.8010408@redhat.com> By default, registered users are logged automatically to keycloak after their successful registration. Or are you talking about login automatically to javascript app? Then you can use onLoad: "check-sso" . See the similar thread from yesterday http://lists.jboss.org/pipermail/keycloak-user/2016-May/006000.html . Btv. If it's possible, I would suggest to upgrade to 1.9.3 . Version 1.5.0 is quite old. Marek On 03/05/16 08:08, Anunay Sinha wrote: > Hi > We are using Keycloak 1.5.0 and are looking for a feature where user > gets logged in automatically once they do registration. > Is it possible to do that? > We can try to capture the password at time of registration and do the > login for the user > Some how this idea of capturing information which is not meant for us > in the first place just doesn't seem right. > Is there a way we can do this? > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160503/819e2e68/attachment.html From bystrik.horvath at gmail.com Tue May 3 06:49:02 2016 From: bystrik.horvath at gmail.com (Bystrik Horvath) Date: Tue, 3 May 2016 12:49:02 +0200 Subject: [keycloak-user] NPE after importing master realm/Keycloak 1.9.2 Message-ID: Hi, I'm facing NullPointerException when log-in to security admin console after importing the master realm. I just wanted to access to master realm by SSL only, so I changed in security admin console 'Require SSL' -to 'all requests' in the master realm settings, saved and exported the master realm. After successful import - using overwriting the existing strategy - I'm getting NPE after log-in to master like follows below. Is it a bug or do I do anything wrong by manipulating the master realm? Best regards, Bystrik 12:35:12,820 ERROR [io.undertow.request] (default task-38) UT005023: Exception handling request to /auth/admin/master/console/whoami: org.jboss.resteasy.spi.UnhandledException: java.lang .NullPointerException at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76) at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212) at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:168) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:411) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:78) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.lang.NullPointerException at org.keycloak.services.resources.admin.AdminConsole.addMasterRealmAccess(AdminConsole.java:239) at org.keycloak.services.resources.admin.AdminConsole.whoAmI(AdminConsole.java:212) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) ... 37 more -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160503/8136f3d5/attachment.html From emanuel.amaral.couto at gmail.com Tue May 3 10:59:41 2016 From: emanuel.amaral.couto at gmail.com (Emanuel Couto) Date: Tue, 03 May 2016 14:59:41 +0000 Subject: [keycloak-user] DSA_SHA1 error Message-ID: I'm getting the following error when trying to connect to a SAML 2.0 identity provider: 15:57:50,387 ERROR [org.keycloak.services] (default task-27) couldNotSendAuthenticationRequestMessage: org.keycloak.broker.provider.IdentityBrokerException: Could not create authentication request. at org.keycloak.broker.saml.SAMLIdentityProvider.performLogin(SAMLIdentityProvider.java:124) at org.keycloak.services.resources.IdentityBrokerService.performLogin(IdentityBrokerService.java:157) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:88) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: org.keycloak.saml.common.exceptions.ProcessingException: javax.xml.crypto.dsig.XMLSignatureException: PL00100: Signing Process Failure: at org.keycloak.saml.processing.api.saml.v2.sig.SAML2Signature.signSAMLDocument(SAML2Signature.java:162) at org.keycloak.saml.BaseSAML2BindingBuilder.signDocument(BaseSAML2BindingBuilder.java:266) at org.keycloak.saml.BaseSAML2BindingBuilder$BasePostBindingBuilder.(BaseSAML2BindingBuilder.java:145) at org.keycloak.protocol.saml.JaxrsSAML2BindingBuilder$PostBindingBuilder.(JaxrsSAML2BindingBuilder.java:38) at org.keycloak.protocol.saml.JaxrsSAML2BindingBuilder.postBinding(JaxrsSAML2BindingBuilder.java:87) at org.keycloak.broker.saml.SAMLIdentityProvider.performLogin(SAMLIdentityProvider.java:119) ... 48 more Caused by: javax.xml.crypto.dsig.XMLSignatureException: PL00100: Signing Process Failure: at org.keycloak.saml.common.DefaultPicketLinkLogger.signatureError(DefaultPicketLinkLogger.java:184) ... 54 more Caused by: javax.xml.crypto.dsig.XMLSignatureException: java.security.InvalidKeyException: can't identify DSA private key. at org.apache.jcp.xml.dsig.internal.dom.DOMXMLSignature.sign(DOMXMLSignature.java:403) at org.keycloak.saml.processing.core.util.XMLSignatureUtil.signImpl(XMLSignatureUtil.java:624) at org.keycloak.saml.processing.core.util.XMLSignatureUtil.sign(XMLSignatureUtil.java:347) at org.keycloak.saml.processing.api.saml.v2.sig.SAML2Signature.sign(SAML2Signature.java:143) at org.keycloak.saml.processing.api.saml.v2.sig.SAML2Signature.signSAMLDocument(SAML2Signature.java:160) ... 53 more Caused by: java.security.InvalidKeyException: can't identify DSA private key. at org.bouncycastle.jcajce.provider.asymmetric.dsa.DSAUtil.generatePrivateKeyParameter(Unknown Source) at org.bouncycastle.jcajce.provider.asymmetric.dsa.DSASigner.engineInitSign(Unknown Source) at java.security.Signature$Delegate.init(Signature.java:1152) at java.security.Signature$Delegate.chooseProvider(Signature.java:1112) at java.security.Signature$Delegate.engineInitSign(Signature.java:1176) at java.security.Signature.initSign(Signature.java:527) at org.apache.jcp.xml.dsig.internal.dom.DOMSignatureMethod.sign(DOMSignatureMethod.java:267) at org.apache.jcp.xml.dsig.internal.dom.DOMXMLSignature.sign(DOMXMLSignature.java:399) ... 57 more I don't understand this error. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160503/eda6b6bd/attachment-0001.html From jaxley at expedia.com Tue May 3 11:49:25 2016 From: jaxley at expedia.com (Jason Axley) Date: Tue, 3 May 2016 15:49:25 +0000 Subject: [keycloak-user] Control which user profile attributes can be changed by the user In-Reply-To: References: <7AA5ACD5-A5BE-4D2F-AA03-9A06C85737D1@expedia.com> Message-ID: https://issues.jboss.org/browse/KEYCLOAK-2963 From: Stian Thorgersen > Reply-To: "stian at redhat.com" > Date: Monday, May 2, 2016 at 11:01 PM To: Jason Axley > Cc: "keycloak-user at lists.jboss.org" > Subject: Re: [keycloak-user] Control which user profile attributes can be changed by the user Afraid this is not possible at the moment, feel free to create a JIRA On 2 May 2016 at 23:02, Jason Axley > wrote: I did not see any way to set a policy for which user profile attributes the user can change. The account management UI displays all of the information in edit input boxes and presumably lets users change anything including name, email, etc. What if I want to restrict which data users can change based on possibly their group or role? Is that at all possible? -Jason Jason Axley Sr. Security Engineer, Expedia Worldwide Engineering Team 425-679-4157 (o) | 206-484-2778 (m) | 206-55-AXLEY (gv) 333 108th Ave NE, 9S-282, Bellevue, WA 98004 EWE Security Wiki _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160503/edc65d9b/attachment.html From bburke at redhat.com Tue May 3 12:01:40 2016 From: bburke at redhat.com (Bill Burke) Date: Tue, 3 May 2016 12:01:40 -0400 Subject: [keycloak-user] DSA_SHA1 error In-Reply-To: References: Message-ID: What signature algorithm is configured? On 5/3/2016 10:59 AM, Emanuel Couto wrote: > I'm getting the following error when trying to connect to a SAML 2.0 > identity provider: > > 15:57:50,387 ERROR [org.keycloak.services] (default task-27) > couldNotSendAuthenticationRequestMessage: > org.keycloak.broker.provider.IdentityBrokerException: Could not create > authentication request. > at > org.keycloak.broker.saml.SAMLIdentityProvider.performLogin(SAMLIdentityProvider.java:124) > at > org.keycloak.services.resources.IdentityBrokerService.performLogin(IdentityBrokerService.java:157) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) > at > org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) > at > org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) > at > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) > at > org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:88) > at > io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) > at > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) > at > io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) > at > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at > org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at > io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at > io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) > at > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) > at > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) > at > io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > at > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.keycloak.saml.common.exceptions.ProcessingException: > javax.xml.crypto.dsig.XMLSignatureException: PL00100: Signing Process > Failure: > at > org.keycloak.saml.processing.api.saml.v2.sig.SAML2Signature.signSAMLDocument(SAML2Signature.java:162) > at > org.keycloak.saml.BaseSAML2BindingBuilder.signDocument(BaseSAML2BindingBuilder.java:266) > at > org.keycloak.saml.BaseSAML2BindingBuilder$BasePostBindingBuilder.(BaseSAML2BindingBuilder.java:145) > at > org.keycloak.protocol.saml.JaxrsSAML2BindingBuilder$PostBindingBuilder.(JaxrsSAML2BindingBuilder.java:38) > at > org.keycloak.protocol.saml.JaxrsSAML2BindingBuilder.postBinding(JaxrsSAML2BindingBuilder.java:87) > at > org.keycloak.broker.saml.SAMLIdentityProvider.performLogin(SAMLIdentityProvider.java:119) > ... 48 more > Caused by: javax.xml.crypto.dsig.XMLSignatureException: PL00100: > Signing Process Failure: > at > org.keycloak.saml.common.DefaultPicketLinkLogger.signatureError(DefaultPicketLinkLogger.java:184) > ... 54 more > Caused by: javax.xml.crypto.dsig.XMLSignatureException: > java.security.InvalidKeyException: can't identify DSA private key. > at > org.apache.jcp.xml.dsig.internal.dom.DOMXMLSignature.sign(DOMXMLSignature.java:403) > at > org.keycloak.saml.processing.core.util.XMLSignatureUtil.signImpl(XMLSignatureUtil.java:624) > at > org.keycloak.saml.processing.core.util.XMLSignatureUtil.sign(XMLSignatureUtil.java:347) > at > org.keycloak.saml.processing.api.saml.v2.sig.SAML2Signature.sign(SAML2Signature.java:143) > at > org.keycloak.saml.processing.api.saml.v2.sig.SAML2Signature.signSAMLDocument(SAML2Signature.java:160) > ... 53 more > Caused by: java.security.InvalidKeyException: can't identify DSA > private key. > at > org.bouncycastle.jcajce.provider.asymmetric.dsa.DSAUtil.generatePrivateKeyParameter(Unknown > Source) > at > org.bouncycastle.jcajce.provider.asymmetric.dsa.DSASigner.engineInitSign(Unknown > Source) > at java.security.Signature$Delegate.init(Signature.java:1152) > at > java.security.Signature$Delegate.chooseProvider(Signature.java:1112) > at > java.security.Signature$Delegate.engineInitSign(Signature.java:1176) > at java.security.Signature.initSign(Signature.java:527) > at > org.apache.jcp.xml.dsig.internal.dom.DOMSignatureMethod.sign(DOMSignatureMethod.java:267) > at > org.apache.jcp.xml.dsig.internal.dom.DOMXMLSignature.sign(DOMXMLSignature.java:399) > ... 57 more > > I don't understand this error. > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160503/d0c58d6c/attachment-0001.html From emanuel.amaral.couto at gmail.com Tue May 3 12:07:50 2016 From: emanuel.amaral.couto at gmail.com (Emanuel Couto) Date: Tue, 03 May 2016 16:07:50 +0000 Subject: [keycloak-user] DSA_SHA1 error In-Reply-To: References: Message-ID: The signature algorithm is DSA_SHA1. Note: Sorry, didn't reply all. On Tue, May 3, 2016 at 5:02 PM Bill Burke wrote: > What signature algorithm is configured? > > On 5/3/2016 10:59 AM, Emanuel Couto wrote: > > I'm getting the following error when trying to connect to a SAML 2.0 > identity provider: > > 15:57:50,387 ERROR [org.keycloak.services] (default task-27) > couldNotSendAuthenticationRequestMessage: > org.keycloak.broker.provider.IdentityBrokerException: Could not create > authentication request. > at > org.keycloak.broker.saml.SAMLIdentityProvider.performLogin(SAMLIdentityProvider.java:124) > at > org.keycloak.services.resources.IdentityBrokerService.performLogin(IdentityBrokerService.java:157) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) > at > org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) > at > org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) > at > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) > at > org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:88) > at > io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) > at > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) > at > io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) > at > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at > org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at > io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at > io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) > at > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) > at > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) > at > io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > at > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.keycloak.saml.common.exceptions.ProcessingException: > javax.xml.crypto.dsig.XMLSignatureException: PL00100: Signing Process > Failure: > at > org.keycloak.saml.processing.api.saml.v2.sig.SAML2Signature.signSAMLDocument(SAML2Signature.java:162) > at > org.keycloak.saml.BaseSAML2BindingBuilder.signDocument(BaseSAML2BindingBuilder.java:266) > at > org.keycloak.saml.BaseSAML2BindingBuilder$BasePostBindingBuilder.(BaseSAML2BindingBuilder.java:145) > at > org.keycloak.protocol.saml.JaxrsSAML2BindingBuilder$PostBindingBuilder.(JaxrsSAML2BindingBuilder.java:38) > at > org.keycloak.protocol.saml.JaxrsSAML2BindingBuilder.postBinding(JaxrsSAML2BindingBuilder.java:87) > at > org.keycloak.broker.saml.SAMLIdentityProvider.performLogin(SAMLIdentityProvider.java:119) > ... 48 more > Caused by: javax.xml.crypto.dsig.XMLSignatureException: PL00100: Signing > Process Failure: > at > org.keycloak.saml.common.DefaultPicketLinkLogger.signatureError(DefaultPicketLinkLogger.java:184) > ... 54 more > Caused by: javax.xml.crypto.dsig.XMLSignatureException: > java.security.InvalidKeyException: can't identify DSA private key. > at > org.apache.jcp.xml.dsig.internal.dom.DOMXMLSignature.sign(DOMXMLSignature.java:403) > at > org.keycloak.saml.processing.core.util.XMLSignatureUtil.signImpl(XMLSignatureUtil.java:624) > at > org.keycloak.saml.processing.core.util.XMLSignatureUtil.sign(XMLSignatureUtil.java:347) > at > org.keycloak.saml.processing.api.saml.v2.sig.SAML2Signature.sign(SAML2Signature.java:143) > at > org.keycloak.saml.processing.api.saml.v2.sig.SAML2Signature.signSAMLDocument(SAML2Signature.java:160) > ... 53 more > Caused by: java.security.InvalidKeyException: can't identify DSA private > key. > at > org.bouncycastle.jcajce.provider.asymmetric.dsa.DSAUtil.generatePrivateKeyParameter(Unknown > Source) > at > org.bouncycastle.jcajce.provider.asymmetric.dsa.DSASigner.engineInitSign(Unknown > Source) > at java.security.Signature$Delegate.init(Signature.java:1152) > at > java.security.Signature$Delegate.chooseProvider(Signature.java:1112) > at > java.security.Signature$Delegate.engineInitSign(Signature.java:1176) > at java.security.Signature.initSign(Signature.java:527) > at > org.apache.jcp.xml.dsig.internal.dom.DOMSignatureMethod.sign(DOMSignatureMethod.java:267) > at > org.apache.jcp.xml.dsig.internal.dom.DOMXMLSignature.sign(DOMXMLSignature.java:399) > ... 57 more > > I don't understand this error. > > > _______________________________________________ > keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user > > > -- > Bill Burke > JBoss, a division of Red Hathttp://bill.burkecentral.com > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160503/9fa7f26b/attachment.html From josh.cain at redhat.com Tue May 3 12:19:23 2016 From: josh.cain at redhat.com (Josh Cain) Date: Tue, 3 May 2016 11:19:23 -0500 Subject: [keycloak-user] Fallback to secondary federation provider possible? Message-ID: Hi all, We're attempting to stack a number of FederationProviders, and I was wondering if Keycloak currently does, or plans to support falling back to a secondary provider *after* another provider has already been used. For example, consider a realm with two providers configured: 1. ProviderA, Priority 0 2. ProviderB, Priority1 Where ProviderB is a fall-back mechanism containing the same logical userbase as ProviderA. If *user1* logs into Keycloak and is associated with ProviderA, then ProviderA goes down, we'd ideally like for ProviderB to be able to authenticate the user. Right now, all our Keycloak instance does is attempt to authenticate *user1* with ProviderA, then fails if the provider is unsuccessful. Is there a way to failover to ProviderB should ProviderA become unavailable? Josh Cain | Software Applications Engineer *Identity and Access Management* *Red Hat* +1 843-737-1735 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160503/42b748a5/attachment.html From bburke at redhat.com Tue May 3 12:29:37 2016 From: bburke at redhat.com (Bill Burke) Date: Tue, 3 May 2016 12:29:37 -0400 Subject: [keycloak-user] Fallback to secondary federation provider possible? In-Reply-To: References: Message-ID: <2015bd44-49c0-8a11-5070-9881260defe5@redhat.com> We don't have anything like that. Keycloak assumes that username is unique in a federation. Before validating credentials it goes through federation list. The first provider that finds a user of that username will have credentials validated against it. So, no failover. I'm not sure i that's something Keycloak should be responsible for. I'm open to adding it though. On 5/3/2016 12:19 PM, Josh Cain wrote: > Hi all, > > We're attempting to stack a number of FederationProviders, and I was > wondering if Keycloak currently does, or plans to support falling back > to a secondary provider *after* another provider has already been used. > > For example, consider a realm with two providers configured: > > 1. ProviderA, Priority 0 > 2. ProviderB, Priority1 > > Where ProviderB is a fall-back mechanism containing the same logical > userbase as ProviderA. > > If /user1/ logs into Keycloak and is associated with ProviderA, then > ProviderA goes down, we'd ideally like for ProviderB to be able to > authenticate the user. Right now, all our Keycloak instance does is > attempt to authenticate /user1/ with ProviderA, then fails if the > provider is unsuccessful. Is there a way to failover to ProviderB > should ProviderA become unavailable? > > Josh Cain | Software Applications Engineer > /Identity and Access Management/ > *Red Hat* > +1 843-737-1735 > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160503/8d1335aa/attachment-0001.html From sthorger at redhat.com Tue May 3 13:35:39 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 3 May 2016 19:35:39 +0200 Subject: [keycloak-user] Fallback to secondary federation provider possible? In-Reply-To: <2015bd44-49c0-8a11-5070-9881260defe5@redhat.com> References: <2015bd44-49c0-8a11-5070-9881260defe5@redhat.com> Message-ID: With the current user federation strategy we have wouldn't this type of failover be implemented in the user federation provider itself? You're not actually "falling" back to another provider, it's the same provider, but the slave replica right? On 3 May 2016 at 18:29, Bill Burke wrote: > We don't have anything like that. Keycloak assumes that username is > unique in a federation. Before validating credentials it goes through > federation list. The first provider that finds a user of that username > will have credentials validated against it. > > So, no failover. I'm not sure i that's something Keycloak should be > responsible for. I'm open to adding it though. > > > On 5/3/2016 12:19 PM, Josh Cain wrote: > > Hi all, > > We're attempting to stack a number of FederationProviders, and I was > wondering if Keycloak currently does, or plans to support falling back to a > secondary provider *after* another provider has already been used. > > For example, consider a realm with two providers configured: > > 1. ProviderA, Priority 0 > 2. ProviderB, Priority1 > > Where ProviderB is a fall-back mechanism containing the same logical > userbase as ProviderA. > If *user1* logs into Keycloak and is associated with ProviderA, then > ProviderA goes down, we'd ideally like for ProviderB to be able to > authenticate the user. Right now, all our Keycloak instance does is > attempt to authenticate *user1* with ProviderA, then fails if the > provider is unsuccessful. Is there a way to failover to ProviderB should > ProviderA become unavailable? > > Josh Cain | Software Applications Engineer > *Identity and Access Management* > *Red Hat* > +1 843-737-1735 > > > _______________________________________________ > keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user > > > -- > Bill Burke > JBoss, a division of Red Hathttp://bill.burkecentral.com > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160503/c4a5a4b8/attachment.html From josh.cain at redhat.com Tue May 3 13:58:44 2016 From: josh.cain at redhat.com (Josh Cain) Date: Tue, 3 May 2016 12:58:44 -0500 Subject: [keycloak-user] Fallback to secondary federation provider possible? In-Reply-To: References: <2015bd44-49c0-8a11-5070-9881260defe5@redhat.com> Message-ID: Long story short, it's the same user base, but exposed in a completely different way (as opposed to exactly the same services set in something like different data centers). As such, we thought two separate Federation Providers were appropriate, but now have realized that the failover case described above isn't covered. I know this is a pretty non-standard use. We're in the middle of a migration of our services layer, so we're kind of an outlier when it comes to typical usage patterns. We've talked through simply handling this failover manually using a single provider, and we can by with that for now, but we're looking ahead at some similar use cases that might experience the same problem. @Bill I think some kind of stackable configuration like the authenticators have could be really useful for us. If we could mark providers as 'alternative' or 'optional' in the same way it would give us what we need. Anyway, just an idea. At the end of the day I think we're after a way to customize the way in which federation providers interact with one another (or don't), whatever that looks like. Josh Cain | Software Applications Engineer *Identity and Access Management* *Red Hat* +1 843-737-1735 On Tue, May 3, 2016 at 12:35 PM, Stian Thorgersen wrote: > With the current user federation strategy we have wouldn't this type of > failover be implemented in the user federation provider itself? You're not > actually "falling" back to another provider, it's the same provider, but > the slave replica right? > > On 3 May 2016 at 18:29, Bill Burke wrote: > >> We don't have anything like that. Keycloak assumes that username is >> unique in a federation. Before validating credentials it goes through >> federation list. The first provider that finds a user of that username >> will have credentials validated against it. >> >> So, no failover. I'm not sure i that's something Keycloak should be >> responsible for. I'm open to adding it though. >> >> >> On 5/3/2016 12:19 PM, Josh Cain wrote: >> >> Hi all, >> >> We're attempting to stack a number of FederationProviders, and I was >> wondering if Keycloak currently does, or plans to support falling back to a >> secondary provider *after* another provider has already been used. >> >> For example, consider a realm with two providers configured: >> >> 1. ProviderA, Priority 0 >> 2. ProviderB, Priority1 >> >> Where ProviderB is a fall-back mechanism containing the same logical >> userbase as ProviderA. >> If *user1* logs into Keycloak and is associated with ProviderA, then >> ProviderA goes down, we'd ideally like for ProviderB to be able to >> authenticate the user. Right now, all our Keycloak instance does is >> attempt to authenticate *user1* with ProviderA, then fails if the >> provider is unsuccessful. Is there a way to failover to ProviderB should >> ProviderA become unavailable? >> >> Josh Cain | Software Applications Engineer >> *Identity and Access Management* >> *Red Hat* >> +1 843-737-1735 >> >> >> _______________________________________________ >> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user >> >> >> -- >> Bill Burke >> JBoss, a division of Red Hathttp://bill.burkecentral.com >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160503/4421c445/attachment.html From sthorger at redhat.com Tue May 3 14:17:35 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 3 May 2016 20:17:35 +0200 Subject: [keycloak-user] Fallback to secondary federation provider possible? In-Reply-To: References: <2015bd44-49c0-8a11-5070-9881260defe5@redhat.com> Message-ID: Makes more sense now. In theory it should be relatively easy to add something like that, as you're just saying if this provider is unavailable use this other one and you're guaranteeing that the users will be the same. As you say though I'm not sure that's a very common use-case and supporting failover through a single provider would be more common. On 3 May 2016 at 19:58, Josh Cain wrote: > Long story short, it's the same user base, but exposed in a completely > different way (as opposed to exactly the same services set in something > like different data centers). As such, we thought two separate Federation > Providers were appropriate, but now have realized that the failover case > described above isn't covered. > > I know this is a pretty non-standard use. We're in the middle of a > migration of our services layer, so we're kind of an outlier when it comes > to typical usage patterns. We've talked through simply handling this > failover manually using a single provider, and we can by with that for now, > but we're looking ahead at some similar use cases that might experience the > same problem. > > @Bill I think some kind of stackable configuration like the authenticators > have could be really useful for us. If we could mark providers as > 'alternative' or 'optional' in the same way it would give us what we need. > Anyway, just an idea. At the end of the day I think we're after a way to > customize the way in which federation providers interact with one another > (or don't), whatever that looks like. > > Josh Cain | Software Applications Engineer > *Identity and Access Management* > *Red Hat* > +1 843-737-1735 > > On Tue, May 3, 2016 at 12:35 PM, Stian Thorgersen > wrote: > >> With the current user federation strategy we have wouldn't this type of >> failover be implemented in the user federation provider itself? You're not >> actually "falling" back to another provider, it's the same provider, but >> the slave replica right? >> >> On 3 May 2016 at 18:29, Bill Burke wrote: >> >>> We don't have anything like that. Keycloak assumes that username is >>> unique in a federation. Before validating credentials it goes through >>> federation list. The first provider that finds a user of that username >>> will have credentials validated against it. >>> >>> So, no failover. I'm not sure i that's something Keycloak should be >>> responsible for. I'm open to adding it though. >>> >>> >>> On 5/3/2016 12:19 PM, Josh Cain wrote: >>> >>> Hi all, >>> >>> We're attempting to stack a number of FederationProviders, and I was >>> wondering if Keycloak currently does, or plans to support falling back to a >>> secondary provider *after* another provider has already been used. >>> >>> For example, consider a realm with two providers configured: >>> >>> 1. ProviderA, Priority 0 >>> 2. ProviderB, Priority1 >>> >>> Where ProviderB is a fall-back mechanism containing the same logical >>> userbase as ProviderA. >>> If *user1* logs into Keycloak and is associated with ProviderA, then >>> ProviderA goes down, we'd ideally like for ProviderB to be able to >>> authenticate the user. Right now, all our Keycloak instance does is >>> attempt to authenticate *user1* with ProviderA, then fails if the >>> provider is unsuccessful. Is there a way to failover to ProviderB should >>> ProviderA become unavailable? >>> >>> Josh Cain | Software Applications Engineer >>> *Identity and Access Management* >>> *Red Hat* >>> +1 843-737-1735 >>> >>> >>> _______________________________________________ >>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user >>> >>> >>> -- >>> Bill Burke >>> JBoss, a division of Red Hathttp://bill.burkecentral.com >>> >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160503/1b9f5aa9/attachment-0001.html From josh.cain at redhat.com Tue May 3 14:52:33 2016 From: josh.cain at redhat.com (Josh Cain) Date: Tue, 3 May 2016 13:52:33 -0500 Subject: [keycloak-user] Fallback to secondary federation provider possible? In-Reply-To: References: <2015bd44-49c0-8a11-5070-9881260defe5@redhat.com> Message-ID: How does something a little more common like a Kerberos/LDAP failover work. I.E. if users have their kerberos ticket sometimes, but not all the time, how would we configure KC to use the kerb ticket when available and otherwise LDAP? Josh Cain | Software Applications Engineer *Identity and Access Management* *Red Hat* +1 843-737-1735 On Tue, May 3, 2016 at 1:17 PM, Stian Thorgersen wrote: > Makes more sense now. In theory it should be relatively easy to add > something like that, as you're just saying if this provider is unavailable > use this other one and you're guaranteeing that the users will be the same. > As you say though I'm not sure that's a very common use-case and supporting > failover through a single provider would be more common. > > On 3 May 2016 at 19:58, Josh Cain wrote: > >> Long story short, it's the same user base, but exposed in a completely >> different way (as opposed to exactly the same services set in something >> like different data centers). As such, we thought two separate Federation >> Providers were appropriate, but now have realized that the failover case >> described above isn't covered. >> >> I know this is a pretty non-standard use. We're in the middle of a >> migration of our services layer, so we're kind of an outlier when it comes >> to typical usage patterns. We've talked through simply handling this >> failover manually using a single provider, and we can by with that for now, >> but we're looking ahead at some similar use cases that might experience the >> same problem. >> >> @Bill I think some kind of stackable configuration like the >> authenticators have could be really useful for us. If we could mark >> providers as 'alternative' or 'optional' in the same way it would give us >> what we need. Anyway, just an idea. At the end of the day I think we're >> after a way to customize the way in which federation providers interact >> with one another (or don't), whatever that looks like. >> >> Josh Cain | Software Applications Engineer >> *Identity and Access Management* >> *Red Hat* >> +1 843-737-1735 >> >> On Tue, May 3, 2016 at 12:35 PM, Stian Thorgersen >> wrote: >> >>> With the current user federation strategy we have wouldn't this type of >>> failover be implemented in the user federation provider itself? You're not >>> actually "falling" back to another provider, it's the same provider, but >>> the slave replica right? >>> >>> On 3 May 2016 at 18:29, Bill Burke wrote: >>> >>>> We don't have anything like that. Keycloak assumes that username is >>>> unique in a federation. Before validating credentials it goes through >>>> federation list. The first provider that finds a user of that username >>>> will have credentials validated against it. >>>> >>>> So, no failover. I'm not sure i that's something Keycloak should be >>>> responsible for. I'm open to adding it though. >>>> >>>> >>>> On 5/3/2016 12:19 PM, Josh Cain wrote: >>>> >>>> Hi all, >>>> >>>> We're attempting to stack a number of FederationProviders, and I was >>>> wondering if Keycloak currently does, or plans to support falling back to a >>>> secondary provider *after* another provider has already been used. >>>> >>>> For example, consider a realm with two providers configured: >>>> >>>> 1. ProviderA, Priority 0 >>>> 2. ProviderB, Priority1 >>>> >>>> Where ProviderB is a fall-back mechanism containing the same logical >>>> userbase as ProviderA. >>>> If *user1* logs into Keycloak and is associated with ProviderA, then >>>> ProviderA goes down, we'd ideally like for ProviderB to be able to >>>> authenticate the user. Right now, all our Keycloak instance does is >>>> attempt to authenticate *user1* with ProviderA, then fails if the >>>> provider is unsuccessful. Is there a way to failover to ProviderB should >>>> ProviderA become unavailable? >>>> >>>> Josh Cain | Software Applications Engineer >>>> *Identity and Access Management* >>>> *Red Hat* >>>> +1 843-737-1735 >>>> >>>> >>>> _______________________________________________ >>>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user >>>> >>>> >>>> -- >>>> Bill Burke >>>> JBoss, a division of Red Hathttp://bill.burkecentral.com >>>> >>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>> >>> >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160503/a7725d67/attachment.html From lball at redhat.com Tue May 3 15:25:46 2016 From: lball at redhat.com (Lance Ball) Date: Tue, 3 May 2016 15:25:46 -0400 Subject: [keycloak-user] Node.js Module for Client Registration REST API Message-ID: Hi all I have just published an initial 0.1.0 version of a Node.js client for the Keycloak client registration API. You can check it out here: https://www.npmjs.com/package/keycloak-client-registration It currently supports CRUD operations for Keycloak 'default' and 'openid-connect' provider endpoints. The documentation, such as it is, can be found here: http://bucharest-gold.github.io/keycloak-client-registration/. Please feel free to give it a spin. And if you do and have something to say about it, feedback is welcome. The client requires Node.js 5.0 or higher, and is known to work with Keycloak versions 1.9.2 and 1.9.3. If you find a bug, please provide as much detail as you can in a github issue: https://github.com/bucharest-gold/keycloak-client-registration/issues. Pull requests encouraged. :) Cheers Lance -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160503/a45681fd/attachment.html From peterson.dean at gmail.com Tue May 3 23:09:11 2016 From: peterson.dean at gmail.com (Dean Peterson) Date: Tue, 3 May 2016 22:09:11 -0500 Subject: [keycloak-user] Nothing works to enable https Message-ID: I upgraded to the latest version (1.9.3). I followed all the steps in chapter 3 of the documentation for wildfly. When I go to the login page it is https; but when I log in as admin to the admin console, it immediately switches back to http!? Why is the redirect-uri http instead of https? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160503/67008820/attachment.html From peterson.dean at gmail.com Tue May 3 23:33:55 2016 From: peterson.dean at gmail.com (Dean Peterson) Date: Tue, 3 May 2016 22:33:55 -0500 Subject: [keycloak-user] Nothing works to enable https In-Reply-To: References: Message-ID: Looks like I just had to follow the documentation a little better. I had to do the extra filtering: On Tue, May 3, 2016 at 10:09 PM, Dean Peterson wrote: > I upgraded to the latest version (1.9.3). I followed all the steps in > chapter 3 of the documentation for wildfly. When I go to the login page it > is https; but when I log in as admin to the admin console, it immediately > switches back to http!? Why is the redirect-uri http instead of https? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160503/beeaeb5b/attachment.html From sthorger at redhat.com Wed May 4 00:32:36 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 4 May 2016 06:32:36 +0200 Subject: [keycloak-user] Fallback to secondary federation provider possible? In-Reply-To: References: <2015bd44-49c0-8a11-5070-9881260defe5@redhat.com> Message-ID: If Kerberos ticket is unavailable the username/password login form should be displayed. If you have LDAP configured username/password should be checked against this. That's the default behavior AFAIK. On 3 May 2016 at 20:52, Josh Cain wrote: > How does something a little more common like a Kerberos/LDAP failover > work. I.E. if users have their kerberos ticket sometimes, but not all the > time, how would we configure KC to use the kerb ticket when available and > otherwise LDAP? > > Josh Cain | Software Applications Engineer > *Identity and Access Management* > *Red Hat* > +1 843-737-1735 > > On Tue, May 3, 2016 at 1:17 PM, Stian Thorgersen > wrote: > >> Makes more sense now. In theory it should be relatively easy to add >> something like that, as you're just saying if this provider is unavailable >> use this other one and you're guaranteeing that the users will be the same. >> As you say though I'm not sure that's a very common use-case and supporting >> failover through a single provider would be more common. >> >> On 3 May 2016 at 19:58, Josh Cain wrote: >> >>> Long story short, it's the same user base, but exposed in a completely >>> different way (as opposed to exactly the same services set in something >>> like different data centers). As such, we thought two separate Federation >>> Providers were appropriate, but now have realized that the failover case >>> described above isn't covered. >>> >>> I know this is a pretty non-standard use. We're in the middle of a >>> migration of our services layer, so we're kind of an outlier when it comes >>> to typical usage patterns. We've talked through simply handling this >>> failover manually using a single provider, and we can by with that for now, >>> but we're looking ahead at some similar use cases that might experience the >>> same problem. >>> >>> @Bill I think some kind of stackable configuration like the >>> authenticators have could be really useful for us. If we could mark >>> providers as 'alternative' or 'optional' in the same way it would give us >>> what we need. Anyway, just an idea. At the end of the day I think we're >>> after a way to customize the way in which federation providers interact >>> with one another (or don't), whatever that looks like. >>> >>> Josh Cain | Software Applications Engineer >>> *Identity and Access Management* >>> *Red Hat* >>> +1 843-737-1735 >>> >>> On Tue, May 3, 2016 at 12:35 PM, Stian Thorgersen >>> wrote: >>> >>>> With the current user federation strategy we have wouldn't this type of >>>> failover be implemented in the user federation provider itself? You're not >>>> actually "falling" back to another provider, it's the same provider, but >>>> the slave replica right? >>>> >>>> On 3 May 2016 at 18:29, Bill Burke wrote: >>>> >>>>> We don't have anything like that. Keycloak assumes that username is >>>>> unique in a federation. Before validating credentials it goes through >>>>> federation list. The first provider that finds a user of that username >>>>> will have credentials validated against it. >>>>> >>>>> So, no failover. I'm not sure i that's something Keycloak should be >>>>> responsible for. I'm open to adding it though. >>>>> >>>>> >>>>> On 5/3/2016 12:19 PM, Josh Cain wrote: >>>>> >>>>> Hi all, >>>>> >>>>> We're attempting to stack a number of FederationProviders, and I was >>>>> wondering if Keycloak currently does, or plans to support falling back to a >>>>> secondary provider *after* another provider has already been used. >>>>> >>>>> For example, consider a realm with two providers configured: >>>>> >>>>> 1. ProviderA, Priority 0 >>>>> 2. ProviderB, Priority1 >>>>> >>>>> Where ProviderB is a fall-back mechanism containing the same logical >>>>> userbase as ProviderA. >>>>> If *user1* logs into Keycloak and is associated with ProviderA, then >>>>> ProviderA goes down, we'd ideally like for ProviderB to be able to >>>>> authenticate the user. Right now, all our Keycloak instance does is >>>>> attempt to authenticate *user1* with ProviderA, then fails if the >>>>> provider is unsuccessful. Is there a way to failover to ProviderB should >>>>> ProviderA become unavailable? >>>>> >>>>> Josh Cain | Software Applications Engineer >>>>> *Identity and Access Management* >>>>> *Red Hat* >>>>> +1 843-737-1735 >>>>> >>>>> >>>>> _______________________________________________ >>>>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user >>>>> >>>>> >>>>> -- >>>>> Bill Burke >>>>> JBoss, a division of Red Hathttp://bill.burkecentral.com >>>>> >>>>> >>>>> _______________________________________________ >>>>> keycloak-user mailing list >>>>> keycloak-user at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>>> >>>> >>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160504/457fa08d/attachment-0001.html From sthorger at redhat.com Wed May 4 00:34:22 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 4 May 2016 06:34:22 +0200 Subject: [keycloak-user] Token audience doesn't match domain In-Reply-To: References: Message-ID: Follow the steps in: http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e409 On 2 May 2016 at 04:56, Dean Peterson wrote: > I use openshift to apply a wildcard certificat to my routes to keycloak. > I can add https that way. However, even though I can apply https to the > route and hard code https into keycloak.json files for the auth-server-url, > I get the Token audience doesn't match domain errors because some auto > generated url by keycloak thinks everything is http. I really don't want > to have to go through the work of setting up a keystore and everything else > within wildfly when I really don't need it since my route in openshift > handles the https part. Is there a way around this? > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160504/804a326e/attachment.html From sthorger at redhat.com Wed May 4 00:54:48 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 4 May 2016 06:54:48 +0200 Subject: [keycloak-user] [keycloak-dev] Node.js Module for Client Registration REST API In-Reply-To: References: Message-ID: Nice work, thanks :) On 3 May 2016 at 21:25, Lance Ball wrote: > Hi all > > I have just published an initial 0.1.0 version of a Node.js client for the > Keycloak client registration API. You can check it out here: > https://www.npmjs.com/package/keycloak-client-registration > > It currently supports CRUD operations for Keycloak 'default' and > 'openid-connect' provider endpoints. The documentation, such as it is, can > be found here: > http://bucharest-gold.github.io/keycloak-client-registration/. Please > feel free to give it a spin. And if you do and have something to say about > it, feedback is welcome. > > The client requires Node.js 5.0 or higher, and is known to work with > Keycloak versions 1.9.2 and 1.9.3. > > If you find a bug, please provide as much detail as you can in a github > issue: > https://github.com/bucharest-gold/keycloak-client-registration/issues. > Pull requests encouraged. :) > > Cheers > Lance > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160504/16a66bb8/attachment.html From peterson.dean at gmail.com Wed May 4 00:57:50 2016 From: peterson.dean at gmail.com (Dean Peterson) Date: Tue, 3 May 2016 23:57:50 -0500 Subject: [keycloak-user] Token audience doesn't match domain In-Reply-To: References: Message-ID: Yes, you'll find some more posts from me below. Buried in one of them is that I did figure this out. I did have to use the extra filter. On May 3, 2016 11:34 PM, "Stian Thorgersen" wrote: > Follow the steps in: > > http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#d4e409 > > On 2 May 2016 at 04:56, Dean Peterson wrote: > >> I use openshift to apply a wildcard certificat to my routes to keycloak. >> I can add https that way. However, even though I can apply https to the >> route and hard code https into keycloak.json files for the auth-server-url, >> I get the Token audience doesn't match domain errors because some auto >> generated url by keycloak thinks everything is http. I really don't want >> to have to go through the work of setting up a keystore and everything else >> within wildfly when I really don't need it since my route in openshift >> handles the https part. Is there a way around this? >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160503/bc83c5dd/attachment.html From sthorger at redhat.com Wed May 4 02:08:21 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 4 May 2016 08:08:21 +0200 Subject: [keycloak-user] custom user federation syncAllUsers In-Reply-To: References: Message-ID: Not sure I'm following. Keycloak can sync users created from your database, but it can't write users back. New users created in Keycloak directly are only stored in Keycloaks database. On 29 April 2016 at 23:52, Juan Diego wrote: > So The recommend way would be to create my own user administrator and when > I create a user it will create a user on keycloak via keycloak s rest api. > > > > On Thu, Apr 28, 2016 at 11:21 PM, Stian Thorgersen > wrote: > >> User federation isn't designed to push users created in Keycloak to the >> database. It only supports syncing users that are created in the database. >> >> On 27 April 2016 at 18:55, Juan Diego wrote: >> >>> I was checking the example for federation-properties-example. In both >>> examples when you sync all users, it just checks for the users in the >>> properties file and adds it to keycloak if it doesnt exist. >>> If I want to do it both ways, so it adds users from keycloak to my >>> database, and users from my database to keycloak. Should I add them here? >>> I am not managing any password on my database, so i just need user id and >>> username and maybe email. >>> >>> Also when I add a new user I can tell that syncronizeRegistrations() is >>> being called but it is null. In order to create a new user in my database, >>> should I call a create user function to my database here. >>> >>> Thanks, >>> >>> >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160504/e6bb1f34/attachment.html From hr.stoyanov at peruncs.com Wed May 4 02:28:01 2016 From: hr.stoyanov at peruncs.com (Hristo Stoyanov) Date: Wed, 4 May 2016 06:28:01 +0000 Subject: [keycloak-user] Example of the oles manipulation via Rest API? In-Reply-To: References: Message-ID: Hi, Can someone show me a working example of changing the realm set of roles for a user? Here is an example that does not appear to work in KC1.9.3 - after the execution, there is no effect in the console, the user roles remain unchanged. No error whatsoever??? private static void updateRoles(Plan newPlan, UserResource user, RealmResource realm) { //Get all realm roles RolesResource realmRoles = realm.roles(); //Get the user's realm level roles RoleScopeResource userRoles = user.roles().realmLevel(); //Get all existing plan roles to be removed List rolesToRemove = userRoles.listEffective() .stream() .filter((RoleRepresentation r) -> !Roles.isPlanRole(r.getName()) && !Roles.isExpiredPlanRole(r.getName())) .collect(Collectors.toList()); //Add the new plan role List rolesToAdd = new ArrayList<>(1); realmRoles .list() .stream() .filter(r -> r.getName().equals(newPlan.role.getName())) .findFirst().ifPresent((RoleRepresentation r) -> rolesToAdd.add(r)); //Perform remove userRoles.remove(rolesToRemove); //Perform add userRoles.add(rolesToAdd); //Go check the admin console - Surprise .. nothing really changed??? } And here is another example that does nothing: ... RealmResource realm = admin.realm(RealmAdmin.REALM_NAME); UserResource userResource = realm.users().get(userId); UserRepresentation userRepresentation = userResource.toRepresentation(); ... //Assign new plan role updateRoles(request.plan, userResource); userResource.update(userRepresentation); private static void updateRoles(Plan newPlan, UserRepresentation userRepresentation) { List newRoles = userRepresentation.getRealmRoles(); if(newRoles!=null){ newRoles.stream() .filter(r -> !Roles.isPlanRole(r) && !Roles.isExpiredPlanRole(r)) .collect(Collectors.toList()); }else{ newRoles = new ArrayList<>(1); } newRoles.add(newPlan.role.getName()); userRepresentation.setRealmRoles(newRoles); } /Hristo Stoyanov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160504/d2f983bf/attachment-0001.html From nielsbne at gmail.com Wed May 4 04:05:24 2016 From: nielsbne at gmail.com (Niels Bertram) Date: Wed, 4 May 2016 18:05:24 +1000 Subject: [keycloak-user] custom user federation syncAllUsers In-Reply-To: References: Message-ID: <044F82A0-7625-44F1-AFB8-2912F4DAF29C@gmail.com> Is there a way to register a synchronisation callback of some sort with keycloak to ensure the user is replicates back into the user database as well? That would be a mighty useful capability especially in corporate environments where the good old user table cannot be removed for whatever reason. Thanks Niels > On 4 May 2016, at 16:08, Stian Thorgersen wrote: > > Not sure I'm following. Keycloak can sync users created from your database, but it can't write users back. New users created in Keycloak directly are only stored in Keycloaks database. > >> On 29 April 2016 at 23:52, Juan Diego wrote: >> So The recommend way would be to create my own user administrator and when I create a user it will create a user on keycloak via keycloak s rest api. >> >> >> >>> On Thu, Apr 28, 2016 at 11:21 PM, Stian Thorgersen wrote: >>> User federation isn't designed to push users created in Keycloak to the database. It only supports syncing users that are created in the database. >>> >>>> On 27 April 2016 at 18:55, Juan Diego wrote: >>>> I was checking the example for federation-properties-example. In both examples when you sync all users, it just checks for the users in the properties file and adds it to keycloak if it doesnt exist. >>>> If I want to do it both ways, so it adds users from keycloak to my database, and users from my database to keycloak. Should I add them here? I am not managing any password on my database, so i just need user id and username and maybe email. >>>> >>>> Also when I add a new user I can tell that syncronizeRegistrations() is being called but it is null. In order to create a new user in my database, should I call a create user function to my database here. >>>> >>>> Thanks, >>>> >>>> >>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160504/4838640f/attachment.html From bruno at abstractj.org Wed May 4 06:16:36 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 4 May 2016 07:16:36 -0300 Subject: [keycloak-user] NPE after importing master realm/Keycloak 1.9.2 In-Reply-To: References: Message-ID: <20160504101636.GB21875@abstractj.org> I'd recommend you to try 1.9.3.Final if possible. If the problem persists, please report the steps to reproduce and I can look at this. On 2016-05-03, Bystrik Horvath wrote: > Hi, > > I'm facing NullPointerException when log-in to security admin console after > importing the master realm. > I just wanted to access to master realm by SSL only, so I changed in > security admin console 'Require SSL' -to 'all requests' in the master realm > settings, saved and exported the master realm. After successful import - > using overwriting the existing strategy - I'm getting NPE after log-in to > master like follows below. > Is it a bug or do I do anything wrong by manipulating the master realm? > > Best regards, > Bystrik > > 12:35:12,820 ERROR [io.undertow.request] (default task-38) UT005023: > Exception handling request to /auth/admin/master/console/whoami: > org.jboss.resteasy.spi.UnhandledException: java.lang > .NullPointerException > at > org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76) > at > org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212) > at > org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:168) > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:411) > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) > at > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) > at > org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:78) > at > io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) > at > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) > at > io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) > at > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at > org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at > io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at > io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) > at > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) > at > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) > at > io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > at > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown > Source) > at java.lang.Thread.run(Unknown Source) > Caused by: java.lang.NullPointerException > at > org.keycloak.services.resources.admin.AdminConsole.addMasterRealmAccess(AdminConsole.java:239) > at > org.keycloak.services.resources.admin.AdminConsole.whoAmI(AdminConsole.java:212) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at > org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) > at > org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) > at > org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) > ... 37 more > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -- abstractj PGP: 0x84DC9914 From bystrik.horvath at gmail.com Wed May 4 07:10:17 2016 From: bystrik.horvath at gmail.com (Bystrik Horvath) Date: Wed, 4 May 2016 13:10:17 +0200 Subject: [keycloak-user] NPE after importing master realm/Keycloak 1.9.2 In-Reply-To: <20160504101636.GB21875@abstractj.org> References: <20160504101636.GB21875@abstractj.org> Message-ID: Hi Bruno, thank you for your response. It is weird, but it works fine with 1.9.3.Final... I'm switching to 1.9.3.Final ;-) Best regards, Bystrik On Wed, May 4, 2016 at 12:16 PM, Bruno Oliveira wrote: > I'd recommend you to try 1.9.3.Final if possible. If the problem > persists, please report the steps to reproduce and I can look at this. > > On 2016-05-03, Bystrik Horvath wrote: > > Hi, > > > > I'm facing NullPointerException when log-in to security admin console > after > > importing the master realm. > > I just wanted to access to master realm by SSL only, so I changed in > > security admin console 'Require SSL' -to 'all requests' in the master > realm > > settings, saved and exported the master realm. After successful import - > > using overwriting the existing strategy - I'm getting NPE after log-in to > > master like follows below. > > Is it a bug or do I do anything wrong by manipulating the master realm? > > > > Best regards, > > Bystrik > > > > 12:35:12,820 ERROR [io.undertow.request] (default task-38) UT005023: > > Exception handling request to /auth/admin/master/console/whoami: > > org.jboss.resteasy.spi.UnhandledException: java.lang > > .NullPointerException > > at > > > org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76) > > at > > > org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212) > > at > > > org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:168) > > at > > > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:411) > > at > > > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) > > at > > > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) > > at > > > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) > > at > > > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > > at > > > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > > at > > > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) > > at > > > org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:78) > > at > > io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) > > at > > > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) > > at > > > io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) > > at > > > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > > at > > > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > > at > > > org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > > at > > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > > at > > > io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > > at > > > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > > at > > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > > at > > > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > > at > > > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > > at > > > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > > at > > > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > > at > > > io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > > at > > > io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > > at > > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > > at > > > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > > at > > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > > at > > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > > at > > > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) > > at > > > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) > > at > > > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > > at > > > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) > > at > > io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > > at > > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) > > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown > Source) > > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown > > Source) > > at java.lang.Thread.run(Unknown Source) > > Caused by: java.lang.NullPointerException > > at > > > org.keycloak.services.resources.admin.AdminConsole.addMasterRealmAccess(AdminConsole.java:239) > > at > > > org.keycloak.services.resources.admin.AdminConsole.whoAmI(AdminConsole.java:212) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown > Source) > > at java.lang.reflect.Method.invoke(Unknown Source) > > at > > > org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) > > at > > > org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) > > at > > > org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) > > at > > > org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) > > at > > > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) > > at > > > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) > > ... 37 more > > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > -- > > abstractj > PGP: 0x84DC9914 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160504/90cf4368/attachment-0001.html From sblanc at redhat.com Wed May 4 07:17:04 2016 From: sblanc at redhat.com (Sebastien Blanc) Date: Wed, 4 May 2016 13:17:04 +0200 Subject: [keycloak-user] screencast of using Keycloak with Red Hat Mobile Platform Message-ID: Hi Folks, I made a short screencast that shows how to integrate keycloak (using the nodejs moduleand thet js adapter) with the Red Hat Mobile Platform : https://www.youtube.com/watch?v=4NBgiHM5aOA Enjoy ! Sebi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160504/ba31ac2a/attachment.html From sthorger at redhat.com Wed May 4 07:33:48 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 4 May 2016 13:33:48 +0200 Subject: [keycloak-user] custom user federation syncAllUsers In-Reply-To: References: Message-ID: Adding list back For your use-case user federation is not the way to go. As I said it's been designed to pull users from an external datasource into Keycloak, not to sync users into your application. You have two options really: a) Add users when the login to your application. All the details you need about the user can be added to the token and you should only store what your application needs when the user is not around, the rest you can retrieve from the token. This is the simplest and I'd recommend this b) Add an event listener that notifies your application when new users register (if you have registration enabled) and when admins create users On 4 May 2016 at 09:44, Juan Diego wrote: > It is more a question of design, I think. I have my app with its own > database, it has a table users with a relation one to many to another > table let's call it songs. The only reason I have the table users in my > app is because I need a way to know which songs belong to my users. I am > using keycloak to manage my login. > I asked a while a long how people handle this and someone referred to > custom federation providers. > My question is really regarding how to handle the relations of your data > when you have your users in a different database from the rest of your > data. > > So far I can only think on 3 ways to solve this > 1) providers syncing users from keycloak to my database replicating user > ID. I managed to make this work on my provider at the end, before you told > me providers are not meant for this. > 2) managing users in my own app. By this I mean I wouldn't use keycloak > web interface to create or delete users. I have a form to create users in > my app, and when I save the data it connects to keycloak s rest api > creates a user if it works it copies username email and the Id generated by > keycloak to my local table users > 3) adding users in keycloak first then if they logging for the first time > add the user to the database > > So far I was doing the 2nd option, it seems the best suited. Is there > another way to maintain data relation with keycloak > El may. 4, 2016 1:08 AM, "Stian Thorgersen" > escribi?: > >> Not sure I'm following. Keycloak can sync users created from your >> database, but it can't write users back. New users created in Keycloak >> directly are only stored in Keycloaks database. >> >> On 29 April 2016 at 23:52, Juan Diego wrote: >> >>> So The recommend way would be to create my own user administrator and >>> when I create a user it will create a user on keycloak via keycloak s rest >>> api. >>> >>> >>> >>> On Thu, Apr 28, 2016 at 11:21 PM, Stian Thorgersen >>> wrote: >>> >>>> User federation isn't designed to push users created in Keycloak to the >>>> database. It only supports syncing users that are created in the database. >>>> >>>> On 27 April 2016 at 18:55, Juan Diego wrote: >>>> >>>>> I was checking the example for federation-properties-example. In both >>>>> examples when you sync all users, it just checks for the users in the >>>>> properties file and adds it to keycloak if it doesnt exist. >>>>> If I want to do it both ways, so it adds users from keycloak to my >>>>> database, and users from my database to keycloak. Should I add them here? >>>>> I am not managing any password on my database, so i just need user id and >>>>> username and maybe email. >>>>> >>>>> Also when I add a new user I can tell that syncronizeRegistrations() >>>>> is being called but it is null. In order to create a new user in my >>>>> database, should I call a create user function to my database here. >>>>> >>>>> Thanks, >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> keycloak-user mailing list >>>>> keycloak-user at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>>> >>>> >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160504/ab992e2b/attachment.html From guus.der.kinderen at gmail.com Wed May 4 07:51:15 2016 From: guus.der.kinderen at gmail.com (Guus der Kinderen) Date: Wed, 4 May 2016 13:51:15 +0200 Subject: [keycloak-user] PubSub eventing on user management Message-ID: Hello all, Can you suggest an approach (or better yet, an existing solution if one is available) for the following? We have an application that is interested in events regarding user management. We would like it to be notified of user creation, modification and deletion that occurs within Keycloak. Is there some kind of publish/subscribe mechanism available for this? Our initial thought was to create a module for Keycloak, that would somehow register itself as an event listener, and subsequently transmit those events via the XMPP pub/sub mechanism (our software is XMPP-capable). Thoughts? Regards, Guus -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160504/a64c52b0/attachment.html From sthorger at redhat.com Wed May 4 07:59:05 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 4 May 2016 13:59:05 +0200 Subject: [keycloak-user] PubSub eventing on user management In-Reply-To: References: Message-ID: Event listener is the way. It's not to elegant, but it works. Problem is that it's quite low-level and you need to listen to both events and admin events. On 4 May 2016 at 13:51, Guus der Kinderen wrote: > Hello all, > > Can you suggest an approach (or better yet, an existing solution if one is > available) for the following? > > We have an application that is interested in events regarding user > management. We would like it to be notified of user creation, modification > and deletion that occurs within Keycloak. > > Is there some kind of publish/subscribe mechanism available for this? > > Our initial thought was to create a module for Keycloak, that would > somehow register itself as an event listener, and subsequently transmit > those events via the XMPP pub/sub mechanism (our software is XMPP-capable). > > Thoughts? > > Regards, > > Guus > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160504/71509b68/attachment.html From thomas.darimont at googlemail.com Wed May 4 07:59:52 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Wed, 4 May 2016 13:59:52 +0200 Subject: [keycloak-user] PubSub eventing on user management In-Reply-To: References: Message-ID: Hello Guus, I build something along the lines of: https://github.com/hawkular/hawkular-accounts/tree/master/keycloak-event-listener-jms However you need to publish "normal" Keycloak events as well as AdminEvents which are fired when interacting via the Keycloak Admin REST interfaces, e.g. by using AdminConsole or the Admin-REST client. When dealing with the AdminEvents be prepared to do a lot of string pattern matching against the associated REST resource-paths. As an example for detecting whether an AdminEvent denotes a client-role assignment to a user you need to check the resourcePath for the following Pattern: ^users/(" + UUID_PATTERN_STRING + ")/role-mappings/clients/(" + UUID_PATTERN_STRING + ") first uuid-group marks the userId the second one marks the clientId... I think the AdminEvents should be enriched with some additional context information to ease the event matching in custom EventHandlers. Cheers, Thomas 2016-05-04 13:51 GMT+02:00 Guus der Kinderen : > Hello all, > > Can you suggest an approach (or better yet, an existing solution if one is > available) for the following? > > We have an application that is interested in events regarding user > management. We would like it to be notified of user creation, modification > and deletion that occurs within Keycloak. > > Is there some kind of publish/subscribe mechanism available for this? > > Our initial thought was to create a module for Keycloak, that would > somehow register itself as an event listener, and subsequently transmit > those events via the XMPP pub/sub mechanism (our software is XMPP-capable). > > Thoughts? > > Regards, > > Guus > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160504/b4912c25/attachment-0001.html From mposolda at redhat.com Wed May 4 09:08:56 2016 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 4 May 2016 15:08:56 +0200 Subject: [keycloak-user] screencast of using Keycloak with Red Hat Mobile Platform In-Reply-To: References: Message-ID: <5729F468.9080201@redhat.com> Cool, Thanks for sharing! Marek On 04/05/16 13:17, Sebastien Blanc wrote: > Hi Folks, > > I made a short screencast that shows how to integrate keycloak (using > the nodejs moduleand thet js adapter) with the Red Hat Mobile Platform > : https://www.youtube.com/watch?v=4NBgiHM5aOA > > Enjoy ! > > Sebi > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160504/d2b7c2bd/attachment.html From mposolda at redhat.com Wed May 4 09:31:51 2016 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 4 May 2016 15:31:51 +0200 Subject: [keycloak-user] custom user federation syncAllUsers In-Reply-To: References: Message-ID: <5729F9C7.4040900@redhat.com> Well, userFederation also supports "registration" from keycloak to federationStorage. We use it for writable-LDAP federationProvider (new user registered in Keycloak is immediatelly added to LDAP too). Also the federation example is showing it - if you look at "examples/providers/federation-provider" then you see that ClasspathPropertiesFederationProvider doesn't support registration of new users, but FilePropertiesFederationFactorysupports that. If you want to go this way, you just need to: - ensure that YourUserFederationProvider.synchronizeRegistrations returns "true" - then in YourUserFederationProvider.register you can implement saving your user to your federationStorage. Note that at this point, you have just user with username and ID available. If you want to sync more attributes to your storage (ie. email, firstName, lastName, passwords etc) you will need to return "proxy" UserModel object, where you override some setter methods and always when setter is called, you will sync changes to your storage too. In the example you can see WritableUserModelProxy, which supports updating passwords. We have some spaces for improve registration usecase though. Ideally to have possibility to just send single request to federationStorage during registering new user or during update (this is already possible with current federationProvider API, but cumbersome)... Also possibility to "bulk" sync keycloak users to federationStorage. We plan to improve user federation SPI for Keycloak 2.0 though. Marek On 04/05/16 13:33, Stian Thorgersen wrote: > Adding list back > > For your use-case user federation is not the way to go. As I said it's > been designed to pull users from an external datasource into Keycloak, > not to sync users into your application. > > You have two options really: > > a) Add users when the login to your application. All the details you > need about the user can be added to the token and you should only > store what your application needs when the user is not around, the > rest you can retrieve from the token. This is the simplest and I'd > recommend this > b) Add an event listener that notifies your application when new users > register (if you have registration enabled) and when admins create users > > On 4 May 2016 at 09:44, Juan Diego > wrote: > > It is more a question of design, I think. I have my app with its > own database, it has a table users with a relation one to many to > another table let's call it songs. The only reason I have the > table users in my app is because I need a way to know which songs > belong to my users. I am using keycloak to manage my login. > I asked a while a long how people handle this and someone referred > to custom federation providers. > My question is really regarding how to handle the relations of > your data when you have your users in a different database from > the rest of your data. > > So far I can only think on 3 ways to solve this > 1) providers syncing users from keycloak to my database > replicating user ID. I managed to make this work on my provider at > the end, before you told me providers are not meant for this. > 2) managing users in my own app. By this I mean I wouldn't use > keycloak web interface to create or delete users. I have a form > to create users in my app, and when I save the data it connects > to keycloak s rest api creates a user if it works it copies > username email and the Id generated by keycloak to my local table > users > 3) adding users in keycloak first then if they logging for the > first time add the user to the database > > So far I was doing the 2nd option, it seems the best suited. Is > there another way to maintain data relation with keycloak > > El may. 4, 2016 1:08 AM, "Stian Thorgersen" > escribi?: > > Not sure I'm following. Keycloak can sync users created from > your database, but it can't write users back. New users > created in Keycloak directly are only stored in Keycloaks > database. > > On 29 April 2016 at 23:52, Juan Diego > wrote: > > So The recommend way would be to create my own user > administrator and when I create a user it will create a > user on keycloak via keycloak s rest api. > > > > On Thu, Apr 28, 2016 at 11:21 PM, Stian Thorgersen > > wrote: > > User federation isn't designed to push users created > in Keycloak to the database. It only supports syncing > users that are created in the database. > > On 27 April 2016 at 18:55, Juan Diego > > > wrote: > > I was checking the example for > federation-properties-example. In both examples > when you sync all users, it just checks for the > users in the properties file and adds it to > keycloak if it doesnt exist. > If I want to do it both ways, so it adds users > from keycloak to my database, and users from my > database to keycloak. Should I add them here? I > am not managing any password on my database, so i > just need user id and username and maybe email. > > Also when I add a new user I can tell that > syncronizeRegistrations() is being called but it > is null. In order to create a new user in my > database, should I call a create user function to > my database here. > > Thanks, > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160504/e9c056f7/attachment.html From mposolda at redhat.com Wed May 4 09:35:14 2016 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 4 May 2016 15:35:14 +0200 Subject: [keycloak-user] custom user federation syncAllUsers In-Reply-To: <044F82A0-7625-44F1-AFB8-2912F4DAF29C@gmail.com> References: <044F82A0-7625-44F1-AFB8-2912F4DAF29C@gmail.com> Message-ID: <5729FA92.3070008@redhat.com> Yes, see the other mail I've posted in this thread (If you mean the usecase, that when user is registered in Keycloak, your federationStorage will be notified and some info about user from Keycloak will be propagated to the federationStorage too). Marek On 04/05/16 10:05, Niels Bertram wrote: > Is there a way to register a synchronisation callback of some sort > with keycloak to ensure the user is replicates back into the user > database as well? That would be a mighty useful capability especially > in corporate environments where the good old user table cannot be > removed for whatever reason. Thanks Niels > > On 4 May 2016, at 16:08, Stian Thorgersen > wrote: > >> Not sure I'm following. Keycloak can sync users created from your >> database, but it can't write users back. New users created in >> Keycloak directly are only stored in Keycloaks database. >> >> On 29 April 2016 at 23:52, Juan Diego > > wrote: >> >> So The recommend way would be to create my own user administrator >> and when I create a user it will create a user on keycloak via >> keycloak s rest api. >> >> >> >> On Thu, Apr 28, 2016 at 11:21 PM, Stian Thorgersen >> > wrote: >> >> User federation isn't designed to push users created in >> Keycloak to the database. It only supports syncing users that >> are created in the database. >> >> On 27 April 2016 at 18:55, Juan Diego > > wrote: >> >> I was checking the example for >> federation-properties-example. In both examples when you >> sync all users, it just checks for the users in the >> properties file and adds it to keycloak if it doesnt exist. >> If I want to do it both ways, so it adds users from >> keycloak to my database, and users from my database to >> keycloak. Should I add them here? I am not managing any >> password on my database, so i just need user id and >> username and maybe email. >> >> Also when I add a new user I can tell that >> syncronizeRegistrations() is being called but it is >> null. In order to create a new user in my database, >> should I call a create user function to my database here. >> >> Thanks, >> >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160504/f8adb88f/attachment-0001.html From mposolda at redhat.com Wed May 4 09:40:19 2016 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 4 May 2016 15:40:19 +0200 Subject: [keycloak-user] Example of the oles manipulation via Rest API? In-Reply-To: References: Message-ID: <5729FBC3.3010008@redhat.com> For example you can take a look at our testsuite here : https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/admin/UserTest.java#L726 Marek On 04/05/16 08:28, Hristo Stoyanov wrote: > > Hi, > Can someone show me a working example of changing the realm set of > roles for a user? > > Here is an example that does not appear to work in KC1.9.3 - after the > execution, there is no effect in the console, the user roles remain > unchanged. No error whatsoever??? > > private static void updateRoles(Plan newPlan, UserResource user, > RealmResource realm) { > //Get all realm roles > RolesResource realmRoles = realm.roles(); > > //Get the user's realm level roles > RoleScopeResource userRoles = user.roles().realmLevel(); > > //Get all existing plan roles to be removed > List rolesToRemove = userRoles.listEffective() > .stream() > .filter((RoleRepresentation r) -> > !Roles.isPlanRole(r.getName()) && !Roles.isExpiredPlanRole(r.getName())) > .collect(Collectors.toList()); > > //Add the new plan role > List rolesToAdd = new ArrayList<>(1); > realmRoles > .list() > .stream() > .filter(r -> r.getName().equals(newPlan.role.getName())) > .findFirst().ifPresent((RoleRepresentation r) -> > rolesToAdd.add(r)); > > //Perform remove > userRoles.remove(rolesToRemove); > > //Perform add > userRoles.add(rolesToAdd); > > //Go check the admin console - Surprise .. nothing really changed??? > > } > > And here is another example that does nothing: > ... > RealmResource realm = admin.realm(RealmAdmin.REALM_NAME); > UserResource userResource = realm.users().get(userId); > UserRepresentation userRepresentation = > userResource.toRepresentation(); > ... > //Assign new plan role > updateRoles(request.plan, userResource); > userResource.update(userRepresentation); > > private static void updateRoles(Plan newPlan, UserRepresentation > userRepresentation) { > List newRoles = userRepresentation.getRealmRoles(); > if(newRoles!=null){ > newRoles.stream() > .filter(r -> !Roles.isPlanRole(r) && > !Roles.isExpiredPlanRole(r)) > .collect(Collectors.toList()); > }else{ > newRoles = new ArrayList<>(1); > } > newRoles.add(newPlan.role.getName()); > userRepresentation.setRealmRoles(newRoles); > } > > /Hristo Stoyanov > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160504/93286639/attachment.html From mposolda at redhat.com Wed May 4 09:50:25 2016 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 4 May 2016 15:50:25 +0200 Subject: [keycloak-user] Fallback to secondary federation provider possible? In-Reply-To: References: <2015bd44-49c0-8a11-5070-9881260defe5@redhat.com> Message-ID: <5729FE21.2010607@redhat.com> Yes, if you configure Kerberos authenticator as "ALTERNATIVE" in the Authentication tab in admin console, then SPNEGO login is done automatically just if user has kerberos ticket. Otherwise he will be switched to next authenticator in the chain (by default it's form, so showing classic username/password form). Marek On 04/05/16 06:32, Stian Thorgersen wrote: > If Kerberos ticket is unavailable the username/password login form > should be displayed. If you have LDAP configured username/password > should be checked against this. That's the default behavior AFAIK. > > On 3 May 2016 at 20:52, Josh Cain > wrote: > > How does something a little more common like a Kerberos/LDAP > failover work. I.E. if users have their kerberos ticket > sometimes, but not all the time, how would we configure KC to use > the kerb ticket when available and otherwise LDAP? > > Josh Cain | Software Applications Engineer > /Identity and Access Management/ > *Red Hat* > +1 843-737-1735 > > On Tue, May 3, 2016 at 1:17 PM, Stian Thorgersen > > wrote: > > Makes more sense now. In theory it should be relatively easy > to add something like that, as you're just saying if this > provider is unavailable use this other one and you're > guaranteeing that the users will be the same. As you say > though I'm not sure that's a very common use-case and > supporting failover through a single provider would be more > common. > > On 3 May 2016 at 19:58, Josh Cain > wrote: > > Long story short, it's the same user base, but exposed in > a completely different way (as opposed to exactly the same > services set in something like different data centers). > As such, we thought two separate Federation Providers were > appropriate, but now have realized that the failover case > described above isn't covered. > > I know this is a pretty non-standard use. We're in the > middle of a migration of our services layer, so we're kind > of an outlier when it comes to typical usage patterns. > We've talked through simply handling this failover > manually using a single provider, and we can by with that > for now, but we're looking ahead at some similar use cases > that might experience the same problem. > > @Bill I think some kind of stackable configuration like > the authenticators have could be really useful for us. If > we could mark providers as 'alternative' or 'optional' in > the same way it would give us what we need. Anyway, just > an idea. At the end of the day I think we're after a way > to customize the way in which federation providers > interact with one another (or don't), whatever that looks > like. > > Josh Cain | Software Applications Engineer > /Identity and Access Management/ > *Red Hat* > +1 843-737-1735 > > On Tue, May 3, 2016 at 12:35 PM, Stian Thorgersen > > wrote: > > With the current user federation strategy we have > wouldn't this type of failover be implemented in the > user federation provider itself? You're not actually > "falling" back to another provider, it's the same > provider, but the slave replica right? > > On 3 May 2016 at 18:29, Bill Burke > wrote: > > We don't have anything like that. Keycloak assumes > that username is unique in a federation. Before > validating credentials it goes through federation > list. The first provider that finds a user of > that username will have credentials validated > against it. > > So, no failover. I'm not sure i that's something > Keycloak should be responsible for. I'm open to > adding it though. > > > On 5/3/2016 12:19 PM, Josh Cain wrote: >> Hi all, >> >> We're attempting to stack a number of >> FederationProviders, and I was wondering if >> Keycloak currently does, or plans to support >> falling back to a secondary provider *after* >> another provider has already been used. >> >> For example, consider a realm with two providers >> configured: >> >> 1. ProviderA, Priority 0 >> 2. ProviderB, Priority1 >> >> Where ProviderB is a fall-back mechanism >> containing the same logical userbase as ProviderA. >> >> If /user1/ logs into Keycloak and is associated >> with ProviderA, then ProviderA goes down, we'd >> ideally like for ProviderB to be able to >> authenticate the user. Right now, all our >> Keycloak instance does is attempt to authenticate >> /user1/ with ProviderA, then fails if the >> provider is unsuccessful. Is there a way to >> failover to ProviderB should ProviderA become >> unavailable? >> >> Josh Cain | Software Applications Engineer >> /Identity and Access Management/ >> *Red Hat* >> +1 843-737-1735 >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160504/18fd00a1/attachment-0001.html From mposolda at redhat.com Wed May 4 09:53:07 2016 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 4 May 2016 15:53:07 +0200 Subject: [keycloak-user] Fallback to secondary federation provider possible? In-Reply-To: References: <2015bd44-49c0-8a11-5070-9881260defe5@redhat.com> Message-ID: <5729FEC3.9020206@redhat.com> I am also not sure whether to support it in Keycloak OOTB rather then implement fallback in the federationProvider itself... Maybe we can add it just if more people asks for it? Every usecase we support is nice, but on the other hand, it usually introduces some additional complexity :/ Marek On 03/05/16 20:17, Stian Thorgersen wrote: > Makes more sense now. In theory it should be relatively easy to add > something like that, as you're just saying if this provider is > unavailable use this other one and you're guaranteeing that the users > will be the same. As you say though I'm not sure that's a very common > use-case and supporting failover through a single provider would be > more common. > > On 3 May 2016 at 19:58, Josh Cain > wrote: > > Long story short, it's the same user base, but exposed in a > completely different way (as opposed to exactly the same services > set in something like different data centers). As such, we > thought two separate Federation Providers were appropriate, but > now have realized that the failover case described above isn't > covered. > > I know this is a pretty non-standard use. We're in the middle of > a migration of our services layer, so we're kind of an outlier > when it comes to typical usage patterns. We've talked through > simply handling this failover manually using a single provider, > and we can by with that for now, but we're looking ahead at some > similar use cases that might experience the same problem. > > @Bill I think some kind of stackable configuration like the > authenticators have could be really useful for us. If we could > mark providers as 'alternative' or 'optional' in the same way it > would give us what we need. Anyway, just an idea. At the end of > the day I think we're after a way to customize the way in which > federation providers interact with one another (or don't), > whatever that looks like. > > Josh Cain | Software Applications Engineer > /Identity and Access Management/ > *Red Hat* > +1 843-737-1735 > > On Tue, May 3, 2016 at 12:35 PM, Stian Thorgersen > > wrote: > > With the current user federation strategy we have wouldn't > this type of failover be implemented in the user federation > provider itself? You're not actually "falling" back to another > provider, it's the same provider, but the slave replica right? > > On 3 May 2016 at 18:29, Bill Burke > wrote: > > We don't have anything like that. Keycloak assumes that > username is unique in a federation. Before validating > credentials it goes through federation list. The first > provider that finds a user of that username will have > credentials validated against it. > > So, no failover. I'm not sure i that's something Keycloak > should be responsible for. I'm open to adding it though. > > > On 5/3/2016 12:19 PM, Josh Cain wrote: >> Hi all, >> >> We're attempting to stack a number of >> FederationProviders, and I was wondering if Keycloak >> currently does, or plans to support falling back to a >> secondary provider *after* another provider has already >> been used. >> >> For example, consider a realm with two providers configured: >> >> 1. ProviderA, Priority 0 >> 2. ProviderB, Priority1 >> >> Where ProviderB is a fall-back mechanism containing the >> same logical userbase as ProviderA. >> >> If /user1/ logs into Keycloak and is associated with >> ProviderA, then ProviderA goes down, we'd ideally like >> for ProviderB to be able to authenticate the user. Right >> now, all our Keycloak instance does is attempt to >> authenticate /user1/ with ProviderA, then fails if the >> provider is unsuccessful. Is there a way to failover to >> ProviderB should ProviderA become unavailable? >> >> Josh Cain | Software Applications Engineer >> /Identity and Access Management/ >> *Red Hat* >> +1 843-737-1735 >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160504/718f7f6b/attachment.html From bburke at redhat.com Wed May 4 09:58:03 2016 From: bburke at redhat.com (Bill Burke) Date: Wed, 4 May 2016 09:58:03 -0400 Subject: [keycloak-user] Nothing works to enable https In-Reply-To: References: Message-ID: I'm glad you said something! I forgot to add/move this section to the new documentation. On 5/3/2016 11:33 PM, Dean Peterson wrote: > Looks like I just had to follow the documentation a little better. I > had to do the extra filtering: > > class-name="io.undertow.server.handlers.ProxyPeerAddressHandler" > module="io.undertow.core" /> > > On Tue, May 3, 2016 at 10:09 PM, Dean Peterson > > wrote: > > I upgraded to the latest version (1.9.3). I followed all the > steps in chapter 3 of the documentation for wildfly. When I go to > the login page it is https; but when I log in as admin to the > admin console, it immediately switches back to http!? Why is the > redirect-uri http instead of https? > > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160504/bc0e299f/attachment-0001.html From mposolda at redhat.com Wed May 4 10:43:07 2016 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 4 May 2016 16:43:07 +0200 Subject: [keycloak-user] Keycloak admin role to group not working In-Reply-To: <729B2DAE-CF52-426D-9DD3-534CCF9EBB01@expedia.com> References: <729B2DAE-CF52-426D-9DD3-534CCF9EBB01@expedia.com> Message-ID: <572A0A7B.9020007@redhat.com> Just tested the scenario and I confirm there is an issue. It would work for all your external applications, as roles, which are indirectly assigned to user through group mappings, are correctly available inside accessToken. However Keycloak builtin applications (admin console and account management) doesn't read roles from the token, hence it doesn't work there. I've created JIRA for: admin console: https://issues.jboss.org/browse/KEYCLOAK-2969 account management: https://issues.jboss.org/browse/KEYCLOAK-2970 Marek On 02/05/16 22:33, Jason Axley wrote: > I have an LDAP user who is definitely listed as being in a given LDAP > group in Keycloak admin console. > > If I grant the User the admin Realm Role in the master realm, they can > login and access the admin console for the master realm. > > However, if I remove the direct role grant from the user and add it to > the LDAP group, keycloak doesn?t think the user has the role and gives > an error that the user ?You don't have access to the requested > resource.? with the below exception: > > 2016-05-02 20:25:37,677 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] > (default task-2) RESTEASY002005: Failed executing GET > /admin/serverinfo: org.keycloak.services.ForbiddenException > > at > org.keycloak.services.resources.admin.AdminRoot.getServerInfo(AdminRoot.java:231) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:483) > > at > org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:79) > > at > org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:58) > > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:100) > > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) > > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) > > at > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) > > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) > > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > > at > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > > at > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) > > at > org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:78) > > at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) > > at > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) > > at > io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) > > at > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > > at > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > > at > org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > > at > io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > > at > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > > at > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > > at > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > > at > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > > at > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > > at > io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > > at > io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > > at > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > > at > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) > > at > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) > > at > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > > at > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) > > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > > at > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) > > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > > at java.lang.Thread.run(Thread.java:745) > > > > Is there something magical that needs to be configured for this to > work? Or does this look like a bug? > > I also did a quick test where I created a new local group and did the > same role assignment to the group, and assigned the group to the same > LDAP user and it did not grant access. > > -Jason > > *Jason Axley* > > Sr. Security Engineer, Expedia Worldwide Engineering Team > > 425-679-4157 (o) | 206-484-2778 (m) | 206-55-AXLEY (gv) > > 333 108th Ave NE, 9S-282, Bellevue, WA 98004 > > EWE Security Wiki > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160504/6b43955c/attachment-0001.html From bburke at redhat.com Wed May 4 10:50:24 2016 From: bburke at redhat.com (Bill Burke) Date: Wed, 4 May 2016 10:50:24 -0400 Subject: [keycloak-user] Keycloak admin role to group not working In-Reply-To: <572A0A7B.9020007@redhat.com> References: <729B2DAE-CF52-426D-9DD3-534CCF9EBB01@expedia.com> <572A0A7B.9020007@redhat.com> Message-ID: <4aeeb0ff-b3fc-304d-53c2-2e8b9cb0638d@redhat.com> This was by design. Since the information is available to these built-in applications, it seemed that much safer to ignore the token permissions. On 5/4/2016 10:43 AM, Marek Posolda wrote: > Just tested the scenario and I confirm there is an issue. It would > work for all your external applications, as roles, which are > indirectly assigned to user through group mappings, are correctly > available inside accessToken. However Keycloak builtin applications > (admin console and account management) doesn't read roles from the > token, hence it doesn't work there. I've created JIRA for: > admin console: https://issues.jboss.org/browse/KEYCLOAK-2969 > account management: https://issues.jboss.org/browse/KEYCLOAK-2970 > > Marek > > On 02/05/16 22:33, Jason Axley wrote: >> I have an LDAP user who is definitely listed as being in a given LDAP >> group in Keycloak admin console. >> >> If I grant the User the admin Realm Role in the master realm, they >> can login and access the admin console for the master realm. >> >> However, if I remove the direct role grant from the user and add it >> to the LDAP group, keycloak doesn?t think the user has the role and >> gives an error that the user ?You don't have access to the requested >> resource.? with the below exception: >> >> 2016-05-02 20:25:37,677 ERROR >> [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-2) >> RESTEASY002005: Failed executing GET /admin/serverinfo: >> org.keycloak.services.ForbiddenException >> >> at >> org.keycloak.services.resources.admin.AdminRoot.getServerInfo(AdminRoot.java:231) >> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> >> at java.lang.reflect.Method.invoke(Method.java:483) >> >> at >> org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:79) >> >> at >> org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:58) >> >> at >> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:100) >> >> at >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) >> >> at >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) >> >> at >> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) >> >> at >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) >> >> at >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) >> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >> >> at >> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) >> >> at >> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) >> >> at >> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:78) >> >> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) >> >> at >> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) >> >> at >> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) >> >> at >> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) >> >> at >> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) >> >> at >> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) >> >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> >> at >> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) >> >> at >> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) >> >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> >> at >> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) >> >> at >> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) >> >> at >> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) >> >> at >> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) >> >> at >> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) >> >> at >> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) >> >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> >> at >> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >> >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> >> at >> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) >> >> at >> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) >> >> at >> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) >> >> at >> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) >> >> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) >> >> at >> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) >> >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >> >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> >> at java.lang.Thread.run(Thread.java:745) >> >> >> >> Is there something magical that needs to be configured for this to >> work? Or does this look like a bug? >> >> I also did a quick test where I created a new local group and did the >> same role assignment to the group, and assigned the group to the same >> LDAP user and it did not grant access. >> >> -Jason >> >> *Jason Axley* >> >> Sr. Security Engineer, Expedia Worldwide Engineering Team >> >> 425-679-4157 (o) | 206-484-2778 (m) | 206-55-AXLEY (gv) >> >> 333 108th Ave NE, 9S-282, Bellevue, WA 98004 >> >> EWE Security Wiki >> >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160504/b2daffd2/attachment-0001.html From mposolda at redhat.com Wed May 4 11:04:54 2016 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 4 May 2016 17:04:54 +0200 Subject: [keycloak-user] Keycloak admin role to group not working In-Reply-To: <4aeeb0ff-b3fc-304d-53c2-2e8b9cb0638d@redhat.com> References: <729B2DAE-CF52-426D-9DD3-534CCF9EBB01@expedia.com> <572A0A7B.9020007@redhat.com> <4aeeb0ff-b3fc-304d-53c2-2e8b9cb0638d@redhat.com> Message-ID: <572A0F96.3070109@redhat.com> Yeah, information is available. Problem is that it's ignored :-) Both admin console and account management are just using "user.hasRole" when asking if user is member of particular role. This returns false for the role mappings, which are available indirectly through groups. Marek On 04/05/16 16:50, Bill Burke wrote: > > This was by design. Since the information is available to these > built-in applications, it seemed that much safer to ignore the token > permissions. > > > On 5/4/2016 10:43 AM, Marek Posolda wrote: >> Just tested the scenario and I confirm there is an issue. It would >> work for all your external applications, as roles, which are >> indirectly assigned to user through group mappings, are correctly >> available inside accessToken. However Keycloak builtin applications >> (admin console and account management) doesn't read roles from the >> token, hence it doesn't work there. I've created JIRA for: >> admin console: https://issues.jboss.org/browse/KEYCLOAK-2969 >> account management: https://issues.jboss.org/browse/KEYCLOAK-2970 >> >> Marek >> >> On 02/05/16 22:33, Jason Axley wrote: >>> I have an LDAP user who is definitely listed as being in a given >>> LDAP group in Keycloak admin console. >>> >>> If I grant the User the admin Realm Role in the master realm, they >>> can login and access the admin console for the master realm. >>> >>> However, if I remove the direct role grant from the user and add it >>> to the LDAP group, keycloak doesn?t think the user has the role and >>> gives an error that the user ?You don't have access to the requested >>> resource.? with the below exception: >>> >>> 2016-05-02 20:25:37,677 ERROR >>> [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-2) >>> RESTEASY002005: Failed executing GET /admin/serverinfo: >>> org.keycloak.services.ForbiddenException >>> >>> at >>> org.keycloak.services.resources.admin.AdminRoot.getServerInfo(AdminRoot.java:231) >>> >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> >>> at >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> >>> at java.lang.reflect.Method.invoke(Method.java:483) >>> >>> at >>> org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:79) >>> >>> at >>> org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:58) >>> >>> at >>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:100) >>> >>> at >>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) >>> >>> at >>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) >>> >>> at >>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) >>> >>> at >>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) >>> >>> at >>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) >>> >>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>> >>> at >>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) >>> >>> at >>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) >>> >>> at >>> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:78) >>> >>> at >>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) >>> >>> at >>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) >>> >>> at >>> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) >>> >>> at >>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) >>> >>> at >>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) >>> >>> at >>> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) >>> >>> at >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> >>> at >>> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) >>> >>> at >>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) >>> >>> at >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> >>> at >>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) >>> >>> at >>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) >>> >>> at >>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) >>> >>> at >>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) >>> >>> at >>> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) >>> >>> at >>> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) >>> >>> at >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> >>> at >>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >>> >>> at >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> >>> at >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> >>> at >>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) >>> >>> at >>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) >>> >>> at >>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) >>> >>> at >>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) >>> >>> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) >>> >>> at >>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) >>> >>> at >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >>> >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>> >>> at java.lang.Thread.run(Thread.java:745) >>> >>> >>> >>> Is there something magical that needs to be configured for this to >>> work? Or does this look like a bug? >>> >>> I also did a quick test where I created a new local group and did >>> the same role assignment to the group, and assigned the group to the >>> same LDAP user and it did not grant access. >>> >>> -Jason >>> >>> *Jason Axley* >>> >>> Sr. Security Engineer, Expedia Worldwide Engineering Team >>> >>> 425-679-4157 (o) | 206-484-2778 (m) | 206-55-AXLEY (gv) >>> >>> 333 108th Ave NE, 9S-282, Bellevue, WA 98004 >>> >>> EWE Security Wiki >>> >>> >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160504/74080f5a/attachment-0001.html From sthorger at redhat.com Wed May 4 11:09:29 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 4 May 2016 17:09:29 +0200 Subject: [keycloak-user] Keycloak admin role to group not working In-Reply-To: <572A0F96.3070109@redhat.com> References: <729B2DAE-CF52-426D-9DD3-534CCF9EBB01@expedia.com> <572A0A7B.9020007@redhat.com> <4aeeb0ff-b3fc-304d-53c2-2e8b9cb0638d@redhat.com> <572A0F96.3070109@redhat.com> Message-ID: We really need to remove this stuff and just rely on the token. On 4 May 2016 17:06, "Marek Posolda" wrote: > Yeah, information is available. Problem is that it's ignored :-) > > Both admin console and account management are just using "user.hasRole" > when asking if user is member of particular role. This returns false for > the role mappings, which are available indirectly through groups. > > Marek > > On 04/05/16 16:50, Bill Burke wrote: > > This was by design. Since the information is available to these built-in > applications, it seemed that much safer to ignore the token permissions. > > On 5/4/2016 10:43 AM, Marek Posolda wrote: > > Just tested the scenario and I confirm there is an issue. It would work > for all your external applications, as roles, which are indirectly assigned > to user through group mappings, are correctly available inside accessToken. > However Keycloak builtin applications (admin console and account > management) doesn't read roles from the token, hence it doesn't work there. > I've created JIRA for: > admin console: https://issues.jboss.org/browse/KEYCLOAK-2969 > account management: https://issues.jboss.org/browse/KEYCLOAK-2970 > > Marek > > On 02/05/16 22:33, Jason Axley wrote: > > I have an LDAP user who is definitely listed as being in a given LDAP > group in Keycloak admin console. > > If I grant the User the admin Realm Role in the master realm, they can > login and access the admin console for the master realm. > > However, if I remove the direct role grant from the user and add it to the > LDAP group, keycloak doesn?t think the user has the role and gives an error > that the user ?You don't have access to the requested resource.? with the > below exception: > > 2016-05-02 20:25:37,677 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] > (default task-2) RESTEASY002005: Failed executing GET /admin/serverinfo: > org.keycloak.services.ForbiddenException > > at > org.keycloak.services.resources.admin.AdminRoot.getServerInfo(AdminRoot.java:231) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:483) > > at > org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:79) > > at > org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:58) > > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:100) > > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) > > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) > > at > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) > > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) > > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > > at > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > > at > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) > > at > org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:78) > > at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) > > at > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) > > at > io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) > > at > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > > at > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > > at > org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > > at > io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > > at > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > > at > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > > at > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > > at > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > > at > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > > at > io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > > at > io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > > at > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > > at > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) > > at > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) > > at > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > > at > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) > > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) > > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > > at java.lang.Thread.run(Thread.java:745) > > > > Is there something magical that needs to be configured for this to work? > Or does this look like a bug? > > I also did a quick test where I created a new local group and did the same > role assignment to the group, and assigned the group to the same LDAP user > and it did not grant access. > > -Jason > > *Jason Axley* > > Sr. Security Engineer, Expedia Worldwide Engineering Team > > 425-679-4157 (o) | 206-484-2778 (m) | 206-55-AXLEY (gv) > > 333 108th Ave NE, 9S-282, Bellevue, WA 98004 > > EWE Security Wiki > > > _______________________________________________ > keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > _______________________________________________ > keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user > > > -- > Bill Burke > JBoss, a division of Red Hathttp://bill.burkecentral.com > > > > _______________________________________________ > keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160504/dfd987b5/attachment-0001.html From mposolda at redhat.com Wed May 4 11:15:17 2016 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 4 May 2016 17:15:17 +0200 Subject: [keycloak-user] Keycloak admin role to group not working In-Reply-To: References: <729B2DAE-CF52-426D-9DD3-534CCF9EBB01@expedia.com> <572A0A7B.9020007@redhat.com> <4aeeb0ff-b3fc-304d-53c2-2e8b9cb0638d@redhat.com> <572A0F96.3070109@redhat.com> Message-ID: <572A1205.4070106@redhat.com> +1 to use the token. If relying on token is bad for security, then "external" application would be broken too, isn't it? But another issue is, that account management doesn't have token as there is not full OIDC here. It relies just on the cookie authentication. We can sort it easily by having helper methods "isMemberOf", which will take all direct and indirect roles memberhips though. Or are we going to rewrite account management to be angular+REST ? It seems it will help with much more things (REST endpoints for users, no CSRF issues, possibly better UI). Marek On 04/05/16 17:09, Stian Thorgersen wrote: > > We really need to remove this stuff and just rely on the token. > > On 4 May 2016 17:06, "Marek Posolda" > wrote: > > Yeah, information is available. Problem is that it's ignored :-) > > Both admin console and account management are just using > "user.hasRole" when asking if user is member of particular role. > This returns false for the role mappings, which are available > indirectly through groups. > > Marek > > On 04/05/16 16:50, Bill Burke wrote: >> >> This was by design. Since the information is available to these >> built-in applications, it seemed that much safer to ignore the >> token permissions. >> >> >> On 5/4/2016 10:43 AM, Marek Posolda wrote: >>> Just tested the scenario and I confirm there is an issue. It >>> would work for all your external applications, as roles, which >>> are indirectly assigned to user through group mappings, are >>> correctly available inside accessToken. However Keycloak builtin >>> applications (admin console and account management) doesn't read >>> roles from the token, hence it doesn't work there. I've created >>> JIRA for: >>> admin console: https://issues.jboss.org/browse/KEYCLOAK-2969 >>> account management: https://issues.jboss.org/browse/KEYCLOAK-2970 >>> >>> Marek >>> >>> On 02/05/16 22:33, Jason Axley wrote: >>>> I have an LDAP user who is definitely listed as being in a >>>> given LDAP group in Keycloak admin console. >>>> >>>> If I grant the User the admin Realm Role in the master realm, >>>> they can login and access the admin console for the master realm. >>>> >>>> However, if I remove the direct role grant from the user and >>>> add it to the LDAP group, keycloak doesn?t think the user has >>>> the role and gives an error that the user ?You don't have >>>> access to the requested resource.? with the below exception: >>>> >>>> 2016-05-02 20:25:37,677 ERROR >>>> [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-2) >>>> RESTEASY002005: Failed executing GET /admin/serverinfo: >>>> org.keycloak.services.ForbiddenException >>>> >>>> at >>>> org.keycloak.services.resources.admin.AdminRoot.getServerInfo(AdminRoot.java:231) >>>> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>> >>>> at >>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>> >>>> at >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> >>>> at java.lang.reflect.Method.invoke(Method.java:483) >>>> >>>> at >>>> org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:79) >>>> >>>> at >>>> org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:58) >>>> >>>> at >>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:100) >>>> >>>> at >>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) >>>> >>>> at >>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) >>>> >>>> at >>>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) >>>> >>>> at >>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) >>>> >>>> at >>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) >>>> >>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>>> >>>> at >>>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) >>>> >>>> at >>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) >>>> >>>> at >>>> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:78) >>>> >>>> at >>>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) >>>> >>>> at >>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) >>>> >>>> at >>>> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) >>>> >>>> at >>>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) >>>> >>>> at >>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) >>>> >>>> at >>>> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) >>>> >>>> at >>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>> >>>> at >>>> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) >>>> >>>> at >>>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) >>>> >>>> at >>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>> >>>> at >>>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) >>>> >>>> at >>>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) >>>> >>>> at >>>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) >>>> >>>> at >>>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) >>>> >>>> at >>>> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) >>>> >>>> at >>>> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) >>>> >>>> at >>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>> >>>> at >>>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >>>> >>>> at >>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>> >>>> at >>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>> >>>> at >>>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) >>>> >>>> at >>>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) >>>> >>>> at >>>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) >>>> >>>> at >>>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) >>>> >>>> at >>>> io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) >>>> >>>> at >>>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) >>>> >>>> at >>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >>>> >>>> at >>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>>> >>>> at java.lang.Thread.run(Thread.java:745) >>>> >>>> >>>> >>>> Is there something magical that needs to be configured for this >>>> to work? Or does this look like a bug? >>>> >>>> I also did a quick test where I created a new local group and >>>> did the same role assignment to the group, and assigned the >>>> group to the same LDAP user and it did not grant access. >>>> >>>> -Jason >>>> >>>> *Jason Axley* >>>> >>>> Sr. Security Engineer, Expedia Worldwide Engineering Team >>>> >>>> 425-679-4157 (o) | 206-484-2778 >>>> (m) | 206-55-AXLEY (gv) >>>> >>>> 333 108th Ave NE, 9S-282, Bellevue, WA 98004 >>>> >>>> EWE Security Wiki >>>> >>>> >>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user at lists.jboss.org >>>> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >>> >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160504/ee5cf470/attachment-0001.html From mposolda at redhat.com Wed May 4 11:25:51 2016 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 4 May 2016 17:25:51 +0200 Subject: [keycloak-user] Nothing works to enable https In-Reply-To: References: Message-ID: <572A147F.8010906@redhat.com> I've added just to old docs for previous release and created JIRA to move to new docs, so we don't forget for 1.9.4 release : https://issues.jboss.org/browse/KEYCLOAK-2935 Marek On 04/05/16 15:58, Bill Burke wrote: > > I'm glad you said something! I forgot to add/move this section to the > new documentation. > > > On 5/3/2016 11:33 PM, Dean Peterson wrote: >> Looks like I just had to follow the documentation a little better. I >> had to do the extra filtering: >> >> > class-name="io.undertow.server.handlers.ProxyPeerAddressHandler" >> module="io.undertow.core" /> >> >> On Tue, May 3, 2016 at 10:09 PM, Dean Peterson >> > wrote: >> >> I upgraded to the latest version (1.9.3). I followed all the >> steps in chapter 3 of the documentation for wildfly. When I go >> to the login page it is https; but when I log in as admin to the >> admin console, it immediately switches back to http!? Why is the >> redirect-uri http instead of https? >> >> >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160504/4a3fa715/attachment.html From aikeaguinea at xsmail.com Wed May 4 12:00:16 2016 From: aikeaguinea at xsmail.com (Aikeaguinea) Date: Wed, 04 May 2016 12:00:16 -0400 Subject: [keycloak-user] Validating JWT tokens Message-ID: <1462377616.1947384.598056425.5C00B82A@webmail.messagingengine.com> I have a client with a service account and credentials using Signed Jwt. Authentication works fine. The service uses org.keycloak.adapters.authentication.ClientCredentialsProviderUtils#setClientCredentials to create the JWT token and set the headers, and I get back a JWT containing an access token from Keycloak. However, when I use jwt.io to look at the access token, I can't validate the signature. This is true whether I use the client Certificate (from the client's Credentials tab), the Realm public key, or the Realm Certificate. In addition, I have generated the client's public key from the certificate using keytool -exportcert -alias x -keypass y -storepass z -rfc -keystore client-keystore.jks | openssl x509 -inform pem -pubkey on the jks file supplied when I generated the client credentials, and that doesn't work either. We've also been having trouble validating the signature programmatically using Java. Any idea why I might be seeing this? -- http://www.fastmail.com - Or how I learned to stop worrying and love email again From aikeaguinea at xsmail.com Wed May 4 12:37:27 2016 From: aikeaguinea at xsmail.com (Aikeaguinea) Date: Wed, 04 May 2016 12:37:27 -0400 Subject: [keycloak-user] Validating JWT tokens In-Reply-To: <1462377616.1947384.598056425.5C00B82A@webmail.messagingengine.com> References: <1462377616.1947384.598056425.5C00B82A@webmail.messagingengine.com> Message-ID: <1462379847.1956071.598104761.4A24EAC6@webmail.messagingengine.com> Figured it out, kinda. I have to use the Realm public key, and at least in jwt.io it has to begin with "-----BEGIN PUBLIC KEY-----" and end with "-----END PUBLIC KEY-----" -- these can't be omitted. If I try using the Realm certificate, it won't work, however, whether or not I use "-----BEGIN CERTIFICATE-----"/"-----END CERTIFICATE-----". If I use the validator at http://kjur.github.io/jsjws/tool_jwt.html and select "default X509 Certificate (RSA z4) it tells me "Error: malformed X.509 certificate PEM (code:003)" I can use the Realm public key for validating the JWT, but shouldn't the certificate work as well? On Wed, May 4, 2016, at 12:00 PM, Aikeaguinea wrote: > I have a client with a service account and credentials using Signed Jwt. > Authentication works fine. The service uses > org.keycloak.adapters.authentication.ClientCredentialsProviderUtils#setClientCredentials > to create the JWT token and set the headers, and I get back a JWT > containing an access token from Keycloak. > > However, when I use jwt.io to look at the access token, I can't validate > the signature. This is true whether I use the client Certificate (from > the client's Credentials tab), the Realm public key, or the Realm > Certificate. In addition, I have generated the client's public key from > the certificate using > > keytool -exportcert -alias x -keypass y -storepass z -rfc -keystore > client-keystore.jks | openssl x509 -inform pem -pubkey > > on the jks file supplied when I generated the client credentials, and > that doesn't work either. > > We've also been having trouble validating the signature programmatically > using Java. > > Any idea why I might be seeing this? > > -- > http://www.fastmail.com - Or how I learned to stop worrying and > love email again > -- Aikeaguinea aikeaguinea at xsmail.com -- http://www.fastmail.com - Send your email first class From sthorger at redhat.com Wed May 4 13:02:19 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 4 May 2016 19:02:19 +0200 Subject: [keycloak-user] Keycloak admin role to group not working In-Reply-To: <572A1205.4070106@redhat.com> References: <729B2DAE-CF52-426D-9DD3-534CCF9EBB01@expedia.com> <572A0A7B.9020007@redhat.com> <4aeeb0ff-b3fc-304d-53c2-2e8b9cb0638d@redhat.com> <572A0F96.3070109@redhat.com> <572A1205.4070106@redhat.com> Message-ID: I'd like to rewrite it to be all REST to be nice and modern and cool :) On 4 May 2016 at 17:15, Marek Posolda wrote: > +1 to use the token. If relying on token is bad for security, then > "external" application would be broken too, isn't it? > > But another issue is, that account management doesn't have token as there > is not full OIDC here. It relies just on the cookie authentication. We can > sort it easily by having helper methods "isMemberOf", which will take all > direct and indirect roles memberhips though. > > Or are we going to rewrite account management to be angular+REST ? It > seems it will help with much more things (REST endpoints for users, no CSRF > issues, possibly better UI). > > Marek > > > > > On 04/05/16 17:09, Stian Thorgersen wrote: > > We really need to remove this stuff and just rely on the token. > On 4 May 2016 17:06, "Marek Posolda" < > mposolda at redhat.com> wrote: > >> Yeah, information is available. Problem is that it's ignored :-) >> >> Both admin console and account management are just using "user.hasRole" >> when asking if user is member of particular role. This returns false for >> the role mappings, which are available indirectly through groups. >> >> Marek >> >> On 04/05/16 16:50, Bill Burke wrote: >> >> This was by design. Since the information is available to these built-in >> applications, it seemed that much safer to ignore the token permissions. >> >> On 5/4/2016 10:43 AM, Marek Posolda wrote: >> >> Just tested the scenario and I confirm there is an issue. It would work >> for all your external applications, as roles, which are indirectly assigned >> to user through group mappings, are correctly available inside accessToken. >> However Keycloak builtin applications (admin console and account >> management) doesn't read roles from the token, hence it doesn't work there. >> I've created JIRA for: >> admin console: https://issues.jboss.org/browse/KEYCLOAK-2969 >> account management: https://issues.jboss.org/browse/KEYCLOAK-2970 >> >> Marek >> >> On 02/05/16 22:33, Jason Axley wrote: >> >> I have an LDAP user who is definitely listed as being in a given LDAP >> group in Keycloak admin console. >> >> If I grant the User the admin Realm Role in the master realm, they can >> login and access the admin console for the master realm. >> >> However, if I remove the direct role grant from the user and add it to >> the LDAP group, keycloak doesn?t think the user has the role and gives an >> error that the user ?You don't have access to the requested resource.? >> with the below exception: >> >> 2016-05-02 20:25:37,677 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] >> (default task-2) RESTEASY002005: Failed executing GET /admin/serverinfo: >> org.keycloak.services.ForbiddenException >> >> at >> org.keycloak.services.resources.admin.AdminRoot.getServerInfo(AdminRoot.java:231) >> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> >> at java.lang.reflect.Method.invoke(Method.java:483) >> >> at >> org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:79) >> >> at >> org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:58) >> >> at >> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:100) >> >> at >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) >> >> at >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) >> >> at >> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) >> >> at >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) >> >> at >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) >> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >> >> at >> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) >> >> at >> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) >> >> at >> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:78) >> >> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) >> >> at >> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) >> >> at >> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) >> >> at >> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) >> >> at >> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) >> >> at >> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) >> >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> >> at >> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) >> >> at >> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) >> >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> >> at >> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) >> >> at >> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) >> >> at >> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) >> >> at >> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) >> >> at >> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) >> >> at >> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) >> >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> >> at >> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >> >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> >> at >> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) >> >> at >> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) >> >> at >> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) >> >> at >> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) >> >> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) >> >> at >> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) >> >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >> >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> >> at java.lang.Thread.run(Thread.java:745) >> >> >> >> Is there something magical that needs to be configured for this to work? >> Or does this look like a bug? >> >> I also did a quick test where I created a new local group and did the >> same role assignment to the group, and assigned the group to the same LDAP >> user and it did not grant access. >> >> -Jason >> >> *Jason Axley* >> >> Sr. Security Engineer, Expedia Worldwide Engineering Team >> >> 425-679-4157 (o) | 206-484-2778 (m) | 206-55-AXLEY (gv) >> >> 333 108th Ave NE, 9S-282, Bellevue, WA 98004 >> >> EWE Security Wiki >> >> >> _______________________________________________ >> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user >> >> >> >> >> _______________________________________________ >> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user >> >> >> -- >> Bill Burke >> JBoss, a division of Red Hathttp://bill.burkecentral.com >> >> >> >> _______________________________________________ >> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user >> >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160504/d3e4f26f/attachment-0001.html From daniele.bonetto at dnshosting.it Thu May 5 04:14:12 2016 From: daniele.bonetto at dnshosting.it (Daniele Bonetto) Date: Thu, 5 May 2016 10:14:12 +0200 Subject: [keycloak-user] Impersonate Message-ID: <6eef03f0-5e30-4fb3-6523-6f967192fd6b@dnshosting.it> Hi guys, i have a little confusion about how impersonate works in Keycloak. I saw there's a impersonate API that can be called with impersonate privileges. I expected when called the API in some ways changes current logged user session data with impersonated user informations, but seems nothing will change in keycloak sessions neither returns the changed tokens and the current user sessions seems still alive. I also checked keycloak.js to find some method that allows me to call impersonate API from my webapp to allow our operators to access as users. Can someone help me please? Best regards, Daniele Bonetto From mposolda at redhat.com Thu May 5 05:32:38 2016 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 5 May 2016 11:32:38 +0200 Subject: [keycloak-user] Validating JWT tokens In-Reply-To: <1462377616.1947384.598056425.5C00B82A@webmail.messagingengine.com> References: <1462377616.1947384.598056425.5C00B82A@webmail.messagingengine.com> Message-ID: <572B1336.60909@redhat.com> On 04/05/16 18:00, Aikeaguinea wrote: > I have a client with a service account and credentials using Signed Jwt. > Authentication works fine. The service uses > org.keycloak.adapters.authentication.ClientCredentialsProviderUtils#setClientCredentials > to create the JWT token and set the headers, and I get back a JWT > containing an access token from Keycloak. > > However, when I use jwt.io to look at the access token, I can't validate > the signature. This is true whether I use the client Certificate (from > the client's Credentials tab), the Realm public key, or the Realm > Certificate. In addition, I have generated the client's public key from > the certificate using > > keytool -exportcert -alias x -keypass y -storepass z -rfc -keystore > client-keystore.jks | openssl x509 -inform pem -pubkey > > on the jks file supplied when I generated the client credentials, and > that doesn't work either. > > We've also been having trouble validating the signature programmatically > using Java. Signature can be verified in Java if you have realm public key. You can use "RSATokenVerifier.verifyToken" . We have a serviceAccount example, which is part of demo and where this is also used : https://github.com/keycloak/keycloak/blob/master/examples/demo-template/service-account/src/main/java/org/keycloak/example/ProductServiceAccountServlet.java#L166 Marek > > Any idea why I might be seeing this? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160505/6173e459/attachment.html From jayapriya.atheesan at gmail.com Thu May 5 07:18:27 2016 From: jayapriya.atheesan at gmail.com (JAYAPRIYA ATHEESAN) Date: Thu, 5 May 2016 16:48:27 +0530 Subject: [keycloak-user] Social media access tokens. Message-ID: <572b2c08.5020620a.581d8.fffff758@mx.google.com> Hi, After social media login, we try to get access token from keycloak for social medias. For facebook and googleplus, we are able to get the token by hitting the rest endpoint url. Google : https://api.giggso.com:8444/auth/realms/giggzo/broker/google/token Facebook : https://api.giggso.com:8444/auth/realms/giggzo/broker/facebook/token But for twitter, we are not able to get that. Additionally when I checked the database, I was able to observe the below content as token. {"oauth_token":"3219633632-3n1tbcAQnA66jkmH9G555dhPLpsMJ7vzD6Q8Nvg","oauth_t oken_secret":"QNErayAQaMKAwxUfe7MsX1za340n0yGoH6AOGAUBezWUS","screen_name":" priya","user_id":"322632"} Can you please suggest us, how to go about this. I would like to get user information like feeds, post, friends and other details from twitter. Thanks, Jayapriya Atheesan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160505/935684a0/attachment.html From bburke at redhat.com Thu May 5 08:39:50 2016 From: bburke at redhat.com (Bill Burke) Date: Thu, 5 May 2016 08:39:50 -0400 Subject: [keycloak-user] Impersonate In-Reply-To: <6eef03f0-5e30-4fb3-6523-6f967192fd6b@dnshosting.it> References: <6eef03f0-5e30-4fb3-6523-6f967192fd6b@dnshosting.it> Message-ID: This was really only implemented to run in the admin console for browser applications. The behavior depends on what realm the user and admin/impersonator is in. If the user is NOT in the master realm and the impersonator IS in the master realm, then a brand new session is created and the admin remains logged in. That allows them to switch between being an admin and the user in the same browser session. If the user and impersonator are in the same realm, then the admin is logged out and logged in as the user. On 5/5/2016 4:14 AM, Daniele Bonetto wrote: > Hi guys, > > i have a little confusion about how impersonate works in Keycloak. > > I saw there's a impersonate API that can be called with impersonate > privileges. > I expected when called the API in some ways changes current logged user > session data with impersonated user informations, but seems nothing will > change in keycloak sessions neither returns the changed tokens and the > current user sessions seems still alive. > > I also checked keycloak.js to find some method that allows me to call > impersonate API from my webapp to allow our operators to access as users. > > Can someone help me please? > > Best regards, > Daniele Bonetto > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160505/f886ab0d/attachment.html From sthorger at redhat.com Fri May 6 01:33:21 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 6 May 2016 07:33:21 +0200 Subject: [keycloak-user] Validating JWT tokens In-Reply-To: <1462379847.1956071.598104761.4A24EAC6@webmail.messagingengine.com> References: <1462377616.1947384.598056425.5C00B82A@webmail.messagingengine.com> <1462379847.1956071.598104761.4A24EAC6@webmail.messagingengine.com> Message-ID: On 4 May 2016 at 18:37, Aikeaguinea wrote: > Figured it out, kinda. I have to use the Realm public key, and at least > in jwt.io it has to begin with "-----BEGIN PUBLIC KEY-----" and end with > "-----END PUBLIC KEY-----" -- these can't be omitted. > > If I try using the Realm certificate, it won't work, however, whether or > not I use "-----BEGIN CERTIFICATE-----"/"-----END CERTIFICATE-----". > > If I use the validator at http://kjur.github.io/jsjws/tool_jwt.html and > select "default X509 Certificate (RSA z4) it tells me "Error: malformed > X.509 certificate PEM (code:003)" > > I can use the Realm public key for validating the JWT, but shouldn't the > certificate work as well? > The certificate is only used by SAML, so no you can't verify the JWT with the certificate only the public key. > > On Wed, May 4, 2016, at 12:00 PM, Aikeaguinea wrote: > > I have a client with a service account and credentials using Signed Jwt. > > Authentication works fine. The service uses > > > org.keycloak.adapters.authentication.ClientCredentialsProviderUtils#setClientCredentials > > to create the JWT token and set the headers, and I get back a JWT > > containing an access token from Keycloak. > > > > However, when I use jwt.io to look at the access token, I can't validate > > the signature. This is true whether I use the client Certificate (from > > the client's Credentials tab), the Realm public key, or the Realm > > Certificate. In addition, I have generated the client's public key from > > the certificate using > > > > keytool -exportcert -alias x -keypass y -storepass z -rfc -keystore > > client-keystore.jks | openssl x509 -inform pem -pubkey > > > > on the jks file supplied when I generated the client credentials, and > > that doesn't work either. > > > > We've also been having trouble validating the signature programmatically > > using Java. > > > > Any idea why I might be seeing this? > > > > -- > > http://www.fastmail.com - Or how I learned to stop worrying and > > love email again > > > > > -- > Aikeaguinea > aikeaguinea at xsmail.com > > -- > http://www.fastmail.com - Send your email first class > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160506/507ae44a/attachment-0001.html From jayapriya.atheesan at gmail.com Fri May 6 08:02:58 2016 From: jayapriya.atheesan at gmail.com (JAYAPRIYA ATHEESAN) Date: Fri, 6 May 2016 17:32:58 +0530 Subject: [keycloak-user] Social media access tokens. In-Reply-To: <572b2c08.5020620a.581d8.fffff758@mx.google.com> References: <572b2c08.5020620a.581d8.fffff758@mx.google.com> Message-ID: <572c87f7.9c12620a.12fc0.1387@mx.google.com> I was able to resolve this issue by using the oauth_token and oauth_secret values obtained. Thanks a lot for you help Thanks, Jayapriya Atheesan From: JAYAPRIYA ATHEESAN [mailto:jayapriya.atheesan at gmail.com] Sent: Thursday, May 5, 2016 4:48 PM To: keycloak-user at lists.jboss.org Subject: [keycloak-user] Social media access tokens. Hi, After social media login, we try to get access token from keycloak for social medias. For facebook and googleplus, we are able to get the token by hitting the rest endpoint url. Google : https://api.giggso.com:8444/auth/realms/giggzo/broker/google/token Facebook : https://api.giggso.com:8444/auth/realms/giggzo/broker/facebook/token But for twitter, we are not able to get that. Additionally when I checked the database, I was able to observe the below content as token. {"oauth_token":"3219633632-3n1tbcAQnA66jkmH9G555dhPLpsMJ7vzD6Q8Nvg","oauth_t oken_secret":"QNErayAQaMKAwxUfe7MsX1za340n0yGoH6AOGAUBezWUS","screen_name":" priya","user_id":"322632"} Can you please suggest us, how to go about this. I would like to get user information like feeds, post, friends and other details from twitter. Thanks, Jayapriya Atheesan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160506/eee2baf9/attachment.html From chairfield at gmail.com Fri May 6 17:04:21 2016 From: chairfield at gmail.com (Chris Hairfield) Date: Fri, 06 May 2016 21:04:21 +0000 Subject: [keycloak-user] Environment-specific configuration available in theme Message-ID: We're considering building an account management theme that is capable of uploading a profile photo. We'd save the photo to an S3 bucket, and would wish to do so based on environment; our stage Keycloak would point to a stage S3 bucket, prod to the prod bucket, etc.. Is there a way to configure Keycloak on a per-environment basis such that our theme could know its environment in order to point to the correct S3 bucket? Thanks! Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160506/6b9a801f/attachment.html From keycloaklist at ulise.de Sun May 8 13:23:58 2016 From: keycloaklist at ulise.de (Uli SE) Date: Sun, 8 May 2016 19:23:58 +0200 Subject: [keycloak-user] Keycloak JWT Extension Message-ID: <15183ef6-e4ea-f976-db04-c9c9f1861c69@ulise.de> Hi, in chapter 2.2 of the users guide is stated: "The format of these tokens is a Keycloak extension to theJSON Web Token specification" Is this extension specified anywhere? Didn?t find it. Many thanks, Uli -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160508/14dd0aa8/attachment.html From guyBowdler at Dorsetnetworks.com Sun May 8 14:06:14 2016 From: guyBowdler at Dorsetnetworks.com (Guy Bowdler) Date: Sun, 08 May 2016 19:06:14 +0100 Subject: [keycloak-user] Nginx auth-request-module with keycloak Message-ID: Hi, Does anyone have any experience of getting keycloak working with nginx as a reverse proxy with auth-request-module? Want to try to terminate ssl and authentication at the proxy rather than forward unauthenticated requests to apps. Thanks Guy -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160508/0356b479/attachment.html From keycloaklist at ulise.de Sun May 8 14:49:28 2016 From: keycloaklist at ulise.de (Uli SE) Date: Sun, 8 May 2016 20:49:28 +0200 Subject: [keycloak-user] Keykloak rest service Message-ID: <19513009-222a-cf9b-bd4d-aa06384f1da2@ulise.de> Hi, after trying to secure a RestEasy app with keycloak i get an Responde Code 500. I tried to follow the advise of the user guide and the server (and I think the Wildfly adapter) is running. I expected to get a ResponseCode 401 and unauthorized using this code in my service @Path("/users") @Stateless @SecurityDomain("keycloak") public class UserRESTService { @Inject UserRepositoryrepo; @GET @RolesAllowed("admin") @Produces(MediaType.APPLICATION_JSON) public ResponselistAllUsers() { but I get the exyception at trhe bottom: Any idea? thanks, Uli Context Path: /management-service Servlet Path: /api Path Info: /users Query String: null *Stack Trace* org.jboss.resteasy.spi.UnhandledException: javax.ejb.EJBAccessException: WFLYEJB0364: Invocation on method: public javax.ws.rs.core.Response de.xy.rest.UserRESTService.listAllUsers() of bean: UserRESTService is not allowed org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76) org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212) org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:168) org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:411) org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) javax.servlet.http.HttpServlet.service(HttpServlet.java:790) io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) java.lang.Thread.run(Thread.java:745) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160508/a18caf0b/attachment-0001.html From bcook at redhat.com Sun May 8 17:19:23 2016 From: bcook at redhat.com (Brian Cook) Date: Sun, 8 May 2016 14:19:23 -0700 Subject: [keycloak-user] Nginx auth-request-module with keycloak In-Reply-To: References: Message-ID: I have not used that, but I have been using mod_auth_openidc with Apache 2.4 and it works very well if you aren't married to nginx. The developer, Hans, is also extremely helpful. -Brian On May 8, 2016 1:10 PM, "Guy Bowdler" wrote: > Hi, > > Does anyone have any experience of getting keycloak working with nginx as > a reverse proxy with auth-request-module? Want to try to terminate ssl and > authentication at the proxy rather than forward unauthenticated requests to > apps. > > Thanks > > Guy > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160508/74a17851/attachment.html From nielsbne at gmail.com Sun May 8 18:26:30 2016 From: nielsbne at gmail.com (Niels Bertram) Date: Mon, 9 May 2016 08:26:30 +1000 Subject: [keycloak-user] Nginx auth-request-module with keycloak In-Reply-To: References: Message-ID: <151AA441-5702-4505-B72F-FC12A1023B0E@gmail.com> Same here we are using Ping Identity's mod_auth_oidc on Apache with minimal effort. You will need to be running Apache httpd 2.4 which can be a bit of a hassle if you are on RHEL 6 or less. Niels > On 9 May 2016, at 07:19, Brian Cook wrote: > > I have not used that, but I have been using mod_auth_openidc with Apache 2.4 and it works very well if you aren't married to nginx. The developer, Hans, is also extremely helpful. > > -Brian > >> On May 8, 2016 1:10 PM, "Guy Bowdler" wrote: >> Hi, >> >> Does anyone have any experience of getting keycloak working with nginx as a reverse proxy with auth-request-module? Want to try to terminate ssl and authentication at the proxy rather than forward unauthenticated requests to apps. >> >> Thanks >> >> Guy >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160509/af3c6f68/attachment.html From bcook at redhat.com Sun May 8 18:42:23 2016 From: bcook at redhat.com (Brian Cook) Date: Sun, 8 May 2016 15:42:23 -0700 Subject: [keycloak-user] Nginx auth-request-module with keycloak In-Reply-To: <151AA441-5702-4505-B72F-FC12A1023B0E@gmail.com> References: <151AA441-5702-4505-B72F-FC12A1023B0E@gmail.com> Message-ID: You can use software collections to install apache 2.4 very easily on rhel 6 / CentOS 6. https://www.softwarecollections.org/en/scls/rhscl/httpd24/ I'm running 2.4 on RHEL 7 on software collections even though the OS version is 2.4 because it makes it a snap to install python 3.4 + mod_wsgi if you use everything from software collections. -Brian Brian Cook Principal Product Manager Ecosystem and Certification tools 407-212-7079 On Sun, May 8, 2016 at 3:26 PM, Niels Bertram wrote: > Same here we are using Ping Identity's mod_auth_oidc on Apache with > minimal effort. You will need to be running Apache httpd 2.4 which can be a > bit of a hassle if you are on RHEL 6 or less. Niels > > On 9 May 2016, at 07:19, Brian Cook wrote: > > I have not used that, but I have been using mod_auth_openidc with Apache > 2.4 and it works very well if you aren't married to nginx. The developer, > Hans, is also extremely helpful. > > -Brian > On May 8, 2016 1:10 PM, "Guy Bowdler" > wrote: > >> Hi, >> >> Does anyone have any experience of getting keycloak working with nginx as >> a reverse proxy with auth-request-module? Want to try to terminate ssl and >> authentication at the proxy rather than forward unauthenticated requests to >> apps. >> >> Thanks >> >> Guy >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160508/16562222/attachment.html From sthorger at redhat.com Mon May 9 05:02:54 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 9 May 2016 11:02:54 +0200 Subject: [keycloak-user] Keycloak 1.9.4.Final Released Message-ID: We've just release 1.9.4.Final. This release only has two bug fixes, but comes with a fair bit more automated testing. For the full list of resolved issues check out JIRA and to download the release go to the Keycloak homepage . -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160509/c3c9a40b/attachment.html From SKiewidt at de.hellmann.net Mon May 9 06:36:10 2016 From: SKiewidt at de.hellmann.net (Sven Kiewidt) Date: Mon, 9 May 2016 12:36:10 +0200 Subject: [keycloak-user] Integrate Keycloak as SP with ADFS 3.0 as IdP Message-ID: Hi all, i want to connect my Keycloak as ServiceProvider to an ADFS 3.0 Infrastructure as Identity Provider. Is there any documentation available on the net, how to setup the Relying Party Trust or which Claim Rules to set up? Thank you and best regards, Sven Kiewidt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160509/3a6e7561/attachment.html From kevin.thorpe at p-i.net Mon May 9 09:13:57 2016 From: kevin.thorpe at p-i.net (Kevin Thorpe) Date: Mon, 9 May 2016 14:13:57 +0100 Subject: [keycloak-user] Forced password change for service accounts Message-ID: Hi, we've just hit an issue where Keycloak was requiring a password change on a service account. We have addressed this by changing the password and also on the client service. We do though need to handle this before it all falls over as we missed a reporting run last night and breached our SLA with our client. What would be best practice for this? I'm thinking best to enforce rollover but we need a report on which service passwords are going to require reset. Is there any way to do that? *Kevin Thorpe* VP Enterprise Platform www.p-i.net | @PI_150 *T: +44 (0)20 3005 6750 <%2B44%20%280%2920%203005%206750> | F: +44(0)20 7730 2635 <%2B44%280%2920%207730%202635> | T: +44 (0)808 204 0344 <%2B44%20%280%29808%20204%200344> * *150 Buckingham Palace Road, London, SW1W 9TR, UK* *SAVE PAPER - THINK BEFORE YOU PRINT!* ____________________________________________________________________ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160509/dc9659bd/attachment-0001.html From mposolda at redhat.com Mon May 9 09:51:05 2016 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 9 May 2016 15:51:05 +0200 Subject: [keycloak-user] Forced password change for service accounts In-Reply-To: References: Message-ID: <573095C9.4000104@redhat.com> If I understand correctly, you configured password policy "ForceExpiredPasswordChange" in Keycloak and after that period, you are seeing that keycloak requires changing password from serviceAccount user? This looks like a bug, serviceAccount users shouldn't be subject to password policy. Not even sure how is that possible... Feel free to create JIRA for this. Ideally with describing a bit more details (how you configured passwordPolicy, how you use serviceAccount, at which stage you see an issue, stacktrace (if present) etc. Thanks! Marek On 09/05/16 15:13, Kevin Thorpe wrote: > Hi, we've just hit an issue where Keycloak was requiring a password > change on a service account. We have addressed this by changing the > password and also on the client service. We do though need to handle > this before it all falls over as we missed a reporting run last night > and breached our SLA with our client. > > What would be best practice for this? I'm thinking best to enforce > rollover but we need a report on which service passwords are going to > require reset. Is there any way to do that? > > *Kevin Thorpe* > VP Enterprise Platform > > www.p-i.net | @PI_150 > > *T: +44 (0)20 3005 6750 | F: > +44(0)20 7730 2635 | T: +44 (0)808 > 204 0344 * > *150 Buckingham Palace Road, London, SW1W 9TR, UK* > > > *SAVE PAPER - THINK BEFORE YOU PRINT!* > > ____________________________________________________________________ > > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > the system manager. This message contains confidential information and > is intended only for the individual named. If you are not the named > addressee you should not disseminate, distribute or copy this e-mail. > Please notify the sender immediately by e-mail if you have received > this e-mail by mistake and delete this e-mail from your system. If you > are not the intended recipient you are notified that disclosing, > copying, distributing or taking any action in reliance on the contents > of this information is strictly prohibited. > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160509/fa3d6381/attachment.html From mposolda at redhat.com Mon May 9 10:03:23 2016 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 9 May 2016 16:03:23 +0200 Subject: [keycloak-user] Environment-specific configuration available in theme In-Reply-To: References: Message-ID: <573098AB.30701@redhat.com> Maybe you can use "theme.properties" file and configure some property, which will be different in your staging and production environment . In the freemarker template, the properties of theme should be available under key "properties" . So you can read your property from the freemarker file. Seems you will need different version of theme.properties for your staging and production, but I don't have better idea to solve this :/ Marek On 06/05/16 23:04, Chris Hairfield wrote: > > We're considering building an account management theme that is capable > of uploading a profile photo. We'd save the photo to an S3 bucket, and > would wish to do so based on environment; our stage Keycloak would > point to a stage S3 bucket, prod to the prod bucket, etc.. > > > Is there a way to configure Keycloak on a per-environment basis such > that our theme could know its environment in order to point to the > correct S3 bucket? > > > Thanks! > Chris > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160509/0e10b905/attachment.html From mposolda at redhat.com Mon May 9 10:07:14 2016 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 9 May 2016 16:07:14 +0200 Subject: [keycloak-user] Keycloak JWT Extension In-Reply-To: <15183ef6-e4ea-f976-db04-c9c9f1861c69@ulise.de> References: <15183ef6-e4ea-f976-db04-c9c9f1861c69@ulise.de> Message-ID: <57309992.5070704@redhat.com> Probably not documented though. You can either take a look at Keycloak class org.keycloak.representations.AccessToken and org.keycloak.representations.IDToken to see all the fields. Marek On 08/05/16 19:23, Uli SE wrote: > > Hi, > > in chapter 2.2 of the users guide is stated: > > "The format of these tokens is a Keycloak extension to theJSON Web > Token > specification" > > Is this extension specified anywhere? Didn?t find it. > Many thanks, > > Uli > > > > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160509/421e7c47/attachment.html From kevin.thorpe at p-i.net Mon May 9 12:17:12 2016 From: kevin.thorpe at p-i.net (Kevin Thorpe) Date: Mon, 9 May 2016 17:17:12 +0100 Subject: [keycloak-user] Forced password change for service accounts In-Reply-To: <573095C9.4000104@redhat.com> References: <573095C9.4000104@redhat.com> Message-ID: Ah, we were missing something so not a bug. It may be that Keycloak itoo old on that install. It's 1.4.0.final. I've also looked in 1.7.0.final as well and can't see where to turn service accounts on. *Kevin Thorpe* VP Enterprise Platform www.p-i.net | @PI_150 *T: +44 (0)20 3005 6750 <%2B44%20%280%2920%203005%206750> | F: +44(0)20 7730 2635 <%2B44%280%2920%207730%202635> | T: +44 (0)808 204 0344 <%2B44%20%280%29808%20204%200344> * *150 Buckingham Palace Road, London, SW1W 9TR, UK* *SAVE PAPER - THINK BEFORE YOU PRINT!* ____________________________________________________________________ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. On 9 May 2016 at 14:51, Marek Posolda wrote: > If I understand correctly, you configured password policy > "ForceExpiredPasswordChange" in Keycloak and after that period, you are > seeing that keycloak requires changing password from serviceAccount user? > This looks like a bug, serviceAccount users shouldn't be subject to > password policy. Not even sure how is that possible... > > Feel free to create JIRA for this. Ideally with describing a bit more > details (how you configured passwordPolicy, how you use serviceAccount, at > which stage you see an issue, stacktrace (if present) etc. Thanks! > Marek > > > On 09/05/16 15:13, Kevin Thorpe wrote: > > Hi, we've just hit an issue where Keycloak was requiring a password change > on a service account. We have addressed this by changing the password and > also on the client service. We do though need to handle this before it all > falls over as we missed a reporting run last night and breached our SLA > with our client. > > What would be best practice for this? I'm thinking best to enforce > rollover but we need a report on which service passwords are going to > require reset. Is there any way to do that? > > *Kevin Thorpe* > VP Enterprise Platform > > www.p-i.net | @PI_150 > > *T: +44 (0)20 3005 6750 <%2B44%20%280%2920%203005%206750> | F: +44(0)20 > 7730 2635 <%2B44%280%2920%207730%202635> | T: +44 (0)808 204 0344 > <%2B44%20%280%29808%20204%200344> * > *150 Buckingham Palace Road, London, SW1W 9TR, UK* > > > > *SAVE PAPER - THINK BEFORE YOU PRINT!* > > ____________________________________________________________________ > > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the system manager. > This message contains confidential information and is intended only for the > individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this e-mail by mistake and > delete this e-mail from your system. If you are not the intended recipient > you are notified that disclosing, copying, distributing or taking any > action in reliance on the contents of this information is strictly > prohibited. > > > _______________________________________________ > keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160509/18e7e796/attachment-0001.html From thomas.darimont at googlemail.com Mon May 9 13:31:01 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Mon, 9 May 2016 19:31:01 +0200 Subject: [keycloak-user] Keycloak Android OIDC example Message-ID: Hello, I just played a bit with the oidc android example [0] here and made it work with keycloak see my branch [1]. I added a small gif that demonstrates the auth flow: https://github.com/thomasdarimont/android-openid-connect/blob/feature/keycloak-oidc-demo/keycloak-android-oidc-demo.gif Note I tested this with latest Keycloak 1.9.x branch (but should work as well with current master 2.0.x): If you want to play with the example app you need to setup your keycloak like so: # Keycloak Setup ## create new client for the android app: - clientid: android-app-1 - clientname: android-app-1 - access type: confidential - valid redirect url: app://oidcsample.lnikkila.com ## Create a demo user - username: demo - password: demo https://github.com/thomasdarimont/android-openid-connect/tree/feature/keycloak-oidc-demo Note that I needed to use the AuthCode flow [2] since the Hybrid-Flow wasn't supported by Keycloak. Hope you find that interesting :) Cheers, Thomas [0] https://github.com/learning-layers/android-openid-connect [1] https://github.com/thomasdarimont/android-openid-connect/tree/feature/keycloak-oidc-demo [2] https://github.com/thomasdarimont/android-openid-connect/blob/feature/keycloak-oidc-demo/app/src/main/java/com/lnikkila/oidcsample/Config.java#L44 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160509/c710ca6f/attachment.html From fabricio.milone at shinetech.com Mon May 9 19:49:25 2016 From: fabricio.milone at shinetech.com (Fabricio Milone) Date: Tue, 10 May 2016 09:49:25 +1000 Subject: [keycloak-user] JWT - Base64 encode/decode issues Message-ID: Hi everyone, I've been experiencing some random issues when trying to decode the returned idToken from the /protocol/openid-connect/token call. I've found that sometimes the returned idToken is not multiple of 4 and has no padding at the end of the payload section (where mappers are added). So the result is that I'm losing the last 2 characters of the last mapper value. This is one example of a failing token (payload only): eyJqdGkiOiI4NWNlOGVlZS00N2Y5LTQzOTMtODc4Yi1iMjRiNTA0YWIzMWYiLCJleHAiOjE0NjI3NjY3MjMsIm5iZiI6MCwiaWF0IjoxNDYyNzY2NDIzLCJpc3MiOiJodHRwczovL2lkbS1zMi5zYi5kZXYuc2JldGVudi5jb20vYXV0aC9yZWFsbXMvZWxlY3RyaWNzaGVlcCIsImF1ZCI6ImVzIiwic3ViIjoiMDNlZGMzNzQtYzgyMC00ZDFhLWJhN2YtM2Y0NzlmOGRiMmM4IiwidHlwIjoiSUQiLCJhenAiOiJlcyIsInNlc3Npb25fc3RhdGUiOiIxY2I0Mjk3Zi04ODA3LTQ4ZWUtODBhNS1hMTI5NzRhN2EyYmQiLCJuYW1lIjoiZm5hbWUgbG5hbWUiLCJjdXN0SWQiOiIyNTY3NTgxIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiYW50aHRlc3QiLCJnaXZlbl9uYW1lIjoiZm5hbWUiLCJmYW1pbHlfbmFtZSI6ImxuYW1lIiwiZW1haWwiOiJub2JvZGF5QHNwb3J0c2JldC5jb20uYXUiLCJ0b2tlbiI6Ims4Z3NaKzlsV0dlZUVob212d09ocFk5bXlmeXdOQi9CWE1GWXBEQjErZTdHREJRa0h1R1BSYjJHOE4xYjFRdzJyUHdOVitvTTJzUUlMVVlXYXUvSHFFZ3JWUVhGeGdQd2dTVXl6UUtxaEYydW9KN3JzTFJkSFcza3ZRRy9JMUc1WlFtRnlnRE1va2NUIn0 787 chars (should be 788) if you try to decode it, you'll get: {"jti":"85ce8eee-47f9-4393-878b-b24b504ab31f","exp":1462766723,"nbf":0,"iat":1462766423,"iss":" > https://idm-s2.sb.dev.sbetenv.com/auth/realms/electricsheep","aud":"es","sub":"03edc374-c820-4d1a-ba7f-3f479f8db2c8","typ":"ID","azp":"es","session_state":"1cb4297f-8807-48ee-80a5-a12974a7a2bd","name":"fname > lname","custId":"2567581","preferred_username":"anthtest","given_name":"fname","family_name":"lname","email":" > noboday at sportsbet.com.au > ","token":"k8gsZ+9lWGeeEhomvwOhpY9myfywNB/BXMFYpDB1+e7GDBQkHuGPRb2G8N1b1Qw2rPwNV+oM2sQILUYWau/HqEgrVQXFxgPwgSUyzQKqhF2uoJ7rsLRdHW3kvQG/I1G5ZQmFygDMokcT Which is incomplete. The last two chars (which are *"}*) are missing at the end. So now, if I take the correct complete json and try to encode using another library (as the one used here: https://www.base64encode.org/), I'll get: eyJqdGkiOiI4NWNlOGVlZS00N2Y5LTQzOTMtODc4Yi1iMjRiNTA0YWIzMWYiLCJleHAiOjE0NjI3NjY3MjMsIm5iZiI6MCwiaWF0IjoxNDYyNzY2NDIzLCJpc3MiOiJodHRwczovL2lkbS1zMi5zYi5kZXYuc2JldGVudi5jb20vYXV0aC9yZWFsbXMvZWxlY3RyaWNzaGVlcCIsImF1ZCI6ImVzIiwic3ViIjoiMDNlZGMzNzQtYzgyMC00ZDFhLWJhN2YtM2Y0NzlmOGRiMmM4IiwidHlwIjoiSUQiLCJhenAiOiJlcyIsInNlc3Npb25fc3RhdGUiOiIxY2I0Mjk3Zi04ODA3LTQ4ZWUtODBhNS1hMTI5NzRhN2EyYmQiLCJuYW1lIjoiZm5hbWUgbG5hbWUiLCJjdXN0SWQiOiIyNTY3NTgxIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiYW50aHRlc3QiLCJnaXZlbl9uYW1lIjoiZm5hbWUiLCJmYW1pbHlfbmFtZSI6ImxuYW1lIiwiZW1haWwiOiJub2JvZGF5QHNwb3J0c2JldC5jb20uYXUiLCJ0b2tlbiI6Ims4Z3NaKzlsV0dlZUVob212d09ocFk5bXlmeXdOQi9CWE1GWXBEQjErZTdHREJRa0h1R1BSYjJHOE4xYjFRdzJyUHdOVitvTTJzUUlMVVlXYXUvSHFFZ3JWUVhGeGdQd2dTVXl6UUtxaEYydW9KN3JzTFJkSFcza3ZRRy9JMUc1WlFtRnlnRE1va2NUIn0 > *=* (788 chars, which is ok) Note the equal sign at the end. I'm wondering why Keycloak is not adding those paddings, is that a bug on the lib you are using to encode the payload? As for now, I'm using a workaround that checks for the length of the token and adds the missing padding when needed before try to decode it. while (payload.length() % 4 != 0) payload += "="; That works but it is not ideal. *Should I create a bug on Keycloak's issue tracker?* Thanks in advance. Regards, Fab -- *Fabricio Milone* Developer *Shine Consulting * 30/600 Bourke Street Melbourne VIC 3000 T: 03 8488 9939 M: 04 3200 4006 www.shinetech.com *a* passion for excellence -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160510/dad4ffba/attachment.html From sthorger at redhat.com Tue May 10 00:37:17 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 10 May 2016 06:37:17 +0200 Subject: [keycloak-user] JWT - Base64 encode/decode issues In-Reply-To: References: Message-ID: It's base 64 url encoded, not base 64 encoded, so some padding is removed. I've just checked the payload you have above that is missing using http://kjur.github.io/jsjws/tool_b64udec.html and it's working just fine. On 10 May 2016 at 01:49, Fabricio Milone wrote: > Hi everyone, > > I've been experiencing some random issues when trying to decode the > returned idToken from the /protocol/openid-connect/token call. > > I've found that sometimes the returned idToken is not multiple of 4 and > has no padding at the end of the payload section (where mappers are added). > So the result is that I'm losing the last 2 characters of the last mapper > value. > > This is one example of a failing token (payload only): > > >> eyJqdGkiOiI4NWNlOGVlZS00N2Y5LTQzOTMtODc4Yi1iMjRiNTA0YWIzMWYiLCJleHAiOjE0NjI3NjY3MjMsIm5iZiI6MCwiaWF0IjoxNDYyNzY2NDIzLCJpc3MiOiJodHRwczovL2lkbS1zMi5zYi5kZXYuc2JldGVudi5jb20vYXV0aC9yZWFsbXMvZWxlY3RyaWNzaGVlcCIsImF1ZCI6ImVzIiwic3ViIjoiMDNlZGMzNzQtYzgyMC00ZDFhLWJhN2YtM2Y0NzlmOGRiMmM4IiwidHlwIjoiSUQiLCJhenAiOiJlcyIsInNlc3Npb25fc3RhdGUiOiIxY2I0Mjk3Zi04ODA3LTQ4ZWUtODBhNS1hMTI5NzRhN2EyYmQiLCJuYW1lIjoiZm5hbWUgbG5hbWUiLCJjdXN0SWQiOiIyNTY3NTgxIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiYW50aHRlc3QiLCJnaXZlbl9uYW1lIjoiZm5hbWUiLCJmYW1pbHlfbmFtZSI6ImxuYW1lIiwiZW1haWwiOiJub2JvZGF5QHNwb3J0c2JldC5jb20uYXUiLCJ0b2tlbiI6Ims4Z3NaKzlsV0dlZUVob212d09ocFk5bXlmeXdOQi9CWE1GWXBEQjErZTdHREJRa0h1R1BSYjJHOE4xYjFRdzJyUHdOVitvTTJzUUlMVVlXYXUvSHFFZ3JWUVhGeGdQd2dTVXl6UUtxaEYydW9KN3JzTFJkSFcza3ZRRy9JMUc1WlFtRnlnRE1va2NUIn0 > > > 787 chars (should be 788) > > if you try to decode it, you'll get: > > >> {"jti":"85ce8eee-47f9-4393-878b-b24b504ab31f","exp":1462766723,"nbf":0,"iat":1462766423,"iss":" >> https://idm-s2.sb.dev.sbetenv.com/auth/realms/electricsheep","aud":"es","sub":"03edc374-c820-4d1a-ba7f-3f479f8db2c8","typ":"ID","azp":"es","session_state":"1cb4297f-8807-48ee-80a5-a12974a7a2bd","name":"fname >> lname","custId":"2567581","preferred_username":"anthtest","given_name":"fname","family_name":"lname","email":" >> noboday at sportsbet.com.au >> ","token":"k8gsZ+9lWGeeEhomvwOhpY9myfywNB/BXMFYpDB1+e7GDBQkHuGPRb2G8N1b1Qw2rPwNV+oM2sQILUYWau/HqEgrVQXFxgPwgSUyzQKqhF2uoJ7rsLRdHW3kvQG/I1G5ZQmFygDMokcT > > > Which is incomplete. The last two chars (which are *"}*) are missing at > the end. > > So now, if I take the correct complete json and try to encode using > another library (as the one used here: https://www.base64encode.org/), > I'll get: > > >> eyJqdGkiOiI4NWNlOGVlZS00N2Y5LTQzOTMtODc4Yi1iMjRiNTA0YWIzMWYiLCJleHAiOjE0NjI3NjY3MjMsIm5iZiI6MCwiaWF0IjoxNDYyNzY2NDIzLCJpc3MiOiJodHRwczovL2lkbS1zMi5zYi5kZXYuc2JldGVudi5jb20vYXV0aC9yZWFsbXMvZWxlY3RyaWNzaGVlcCIsImF1ZCI6ImVzIiwic3ViIjoiMDNlZGMzNzQtYzgyMC00ZDFhLWJhN2YtM2Y0NzlmOGRiMmM4IiwidHlwIjoiSUQiLCJhenAiOiJlcyIsInNlc3Npb25fc3RhdGUiOiIxY2I0Mjk3Zi04ODA3LTQ4ZWUtODBhNS1hMTI5NzRhN2EyYmQiLCJuYW1lIjoiZm5hbWUgbG5hbWUiLCJjdXN0SWQiOiIyNTY3NTgxIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiYW50aHRlc3QiLCJnaXZlbl9uYW1lIjoiZm5hbWUiLCJmYW1pbHlfbmFtZSI6ImxuYW1lIiwiZW1haWwiOiJub2JvZGF5QHNwb3J0c2JldC5jb20uYXUiLCJ0b2tlbiI6Ims4Z3NaKzlsV0dlZUVob212d09ocFk5bXlmeXdOQi9CWE1GWXBEQjErZTdHREJRa0h1R1BSYjJHOE4xYjFRdzJyUHdOVitvTTJzUUlMVVlXYXUvSHFFZ3JWUVhGeGdQd2dTVXl6UUtxaEYydW9KN3JzTFJkSFcza3ZRRy9JMUc1WlFtRnlnRE1va2NUIn0 >> *=* > > > (788 chars, which is ok) > > Note the equal sign at the end. > > I'm wondering why Keycloak is not adding those paddings, is that a bug on > the lib you are using to encode the payload? > > As for now, I'm using a workaround that checks for the length of the token > and adds the missing padding when needed before try to decode it. > > while (payload.length() % 4 != 0) payload += "="; > > > That works but it is not ideal. > > *Should I create a bug on Keycloak's issue tracker?* > > Thanks in advance. > > Regards, > Fab > -- > *Fabricio Milone* > Developer > > *Shine Consulting * > > 30/600 Bourke Street > > Melbourne VIC 3000 > > T: 03 8488 9939 > > M: 04 3200 4006 > > > www.shinetech.com *a* passion for excellence > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160510/c11e1220/attachment-0001.html From sthorger at redhat.com Tue May 10 00:40:58 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 10 May 2016 06:40:58 +0200 Subject: [keycloak-user] Environment-specific configuration available in theme In-Reply-To: <573098AB.30701@redhat.com> References: <573098AB.30701@redhat.com> Message-ID: Not sure how you're implementing the profile upload, but you just need to use a environment value. Any code you write would have access to that. On 9 May 2016 at 16:03, Marek Posolda wrote: > Maybe you can use "theme.properties" file and configure some property, > which will be different in your staging and production environment . In the > freemarker template, the properties of theme should be available under key > "properties" . So you can read your property from the freemarker file. > > Seems you will need different version of theme.properties for your staging > and production, but I don't have better idea to solve this :/ > > Marek > > > On 06/05/16 23:04, Chris Hairfield wrote: > > We're considering building an account management theme that is capable of > uploading a profile photo. We'd save the photo to an S3 bucket, and would > wish to do so based on environment; our stage Keycloak would point to a > stage S3 bucket, prod to the prod bucket, etc.. > > > Is there a way to configure Keycloak on a per-environment basis such that > our theme could know its environment in order to point to the correct S3 > bucket? > > > Thanks! > Chris > > > _______________________________________________ > keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160510/6b9b6978/attachment.html From bcook at redhat.com Tue May 10 01:09:18 2016 From: bcook at redhat.com (Brian Cook) Date: Mon, 9 May 2016 23:09:18 -0600 Subject: [keycloak-user] JWT - Base64 encode/decode issues In-Reply-To: References: Message-ID: I had the same problem as fabricio and implemented a version if the same solution. The online checkers know how to fix the padding issue. Missing padding doesn't affect the payload contents of course, and it really depends on what language you are using when you decode. Python is strict about the padding and will throw an error if the input string isn't the right length. -Brian On May 9, 2016 10:38 PM, "Stian Thorgersen" wrote: > It's base 64 url encoded, not base 64 encoded, so some padding is removed. > I've just checked the payload you have above that is missing using > http://kjur.github.io/jsjws/tool_b64udec.html and it's working just fine. > > On 10 May 2016 at 01:49, Fabricio Milone > wrote: > >> Hi everyone, >> >> I've been experiencing some random issues when trying to decode the >> returned idToken from the /protocol/openid-connect/token call. >> >> I've found that sometimes the returned idToken is not multiple of 4 and >> has no padding at the end of the payload section (where mappers are added). >> So the result is that I'm losing the last 2 characters of the last mapper >> value. >> >> This is one example of a failing token (payload only): >> >> >>> eyJqdGkiOiI4NWNlOGVlZS00N2Y5LTQzOTMtODc4Yi1iMjRiNTA0YWIzMWYiLCJleHAiOjE0NjI3NjY3MjMsIm5iZiI6MCwiaWF0IjoxNDYyNzY2NDIzLCJpc3MiOiJodHRwczovL2lkbS1zMi5zYi5kZXYuc2JldGVudi5jb20vYXV0aC9yZWFsbXMvZWxlY3RyaWNzaGVlcCIsImF1ZCI6ImVzIiwic3ViIjoiMDNlZGMzNzQtYzgyMC00ZDFhLWJhN2YtM2Y0NzlmOGRiMmM4IiwidHlwIjoiSUQiLCJhenAiOiJlcyIsInNlc3Npb25fc3RhdGUiOiIxY2I0Mjk3Zi04ODA3LTQ4ZWUtODBhNS1hMTI5NzRhN2EyYmQiLCJuYW1lIjoiZm5hbWUgbG5hbWUiLCJjdXN0SWQiOiIyNTY3NTgxIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiYW50aHRlc3QiLCJnaXZlbl9uYW1lIjoiZm5hbWUiLCJmYW1pbHlfbmFtZSI6ImxuYW1lIiwiZW1haWwiOiJub2JvZGF5QHNwb3J0c2JldC5jb20uYXUiLCJ0b2tlbiI6Ims4Z3NaKzlsV0dlZUVob212d09ocFk5bXlmeXdOQi9CWE1GWXBEQjErZTdHREJRa0h1R1BSYjJHOE4xYjFRdzJyUHdOVitvTTJzUUlMVVlXYXUvSHFFZ3JWUVhGeGdQd2dTVXl6UUtxaEYydW9KN3JzTFJkSFcza3ZRRy9JMUc1WlFtRnlnRE1va2NUIn0 >> >> >> 787 chars (should be 788) >> >> if you try to decode it, you'll get: >> >> >>> {"jti":"85ce8eee-47f9-4393-878b-b24b504ab31f","exp":1462766723,"nbf":0,"iat":1462766423,"iss":" >>> https://idm-s2.sb.dev.sbetenv.com/auth/realms/electricsheep","aud":"es","sub":"03edc374-c820-4d1a-ba7f-3f479f8db2c8","typ":"ID","azp":"es","session_state":"1cb4297f-8807-48ee-80a5-a12974a7a2bd","name":"fname >>> lname","custId":"2567581","preferred_username":"anthtest","given_name":"fname","family_name":"lname","email":" >>> noboday at sportsbet.com.au >>> ","token":"k8gsZ+9lWGeeEhomvwOhpY9myfywNB/BXMFYpDB1+e7GDBQkHuGPRb2G8N1b1Qw2rPwNV+oM2sQILUYWau/HqEgrVQXFxgPwgSUyzQKqhF2uoJ7rsLRdHW3kvQG/I1G5ZQmFygDMokcT >> >> >> Which is incomplete. The last two chars (which are *"}*) are missing at >> the end. >> >> So now, if I take the correct complete json and try to encode using >> another library (as the one used here: https://www.base64encode.org/), >> I'll get: >> >> >>> eyJqdGkiOiI4NWNlOGVlZS00N2Y5LTQzOTMtODc4Yi1iMjRiNTA0YWIzMWYiLCJleHAiOjE0NjI3NjY3MjMsIm5iZiI6MCwiaWF0IjoxNDYyNzY2NDIzLCJpc3MiOiJodHRwczovL2lkbS1zMi5zYi5kZXYuc2JldGVudi5jb20vYXV0aC9yZWFsbXMvZWxlY3RyaWNzaGVlcCIsImF1ZCI6ImVzIiwic3ViIjoiMDNlZGMzNzQtYzgyMC00ZDFhLWJhN2YtM2Y0NzlmOGRiMmM4IiwidHlwIjoiSUQiLCJhenAiOiJlcyIsInNlc3Npb25fc3RhdGUiOiIxY2I0Mjk3Zi04ODA3LTQ4ZWUtODBhNS1hMTI5NzRhN2EyYmQiLCJuYW1lIjoiZm5hbWUgbG5hbWUiLCJjdXN0SWQiOiIyNTY3NTgxIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiYW50aHRlc3QiLCJnaXZlbl9uYW1lIjoiZm5hbWUiLCJmYW1pbHlfbmFtZSI6ImxuYW1lIiwiZW1haWwiOiJub2JvZGF5QHNwb3J0c2JldC5jb20uYXUiLCJ0b2tlbiI6Ims4Z3NaKzlsV0dlZUVob212d09ocFk5bXlmeXdOQi9CWE1GWXBEQjErZTdHREJRa0h1R1BSYjJHOE4xYjFRdzJyUHdOVitvTTJzUUlMVVlXYXUvSHFFZ3JWUVhGeGdQd2dTVXl6UUtxaEYydW9KN3JzTFJkSFcza3ZRRy9JMUc1WlFtRnlnRE1va2NUIn0 >>> *=* >> >> >> (788 chars, which is ok) >> >> Note the equal sign at the end. >> >> I'm wondering why Keycloak is not adding those paddings, is that a bug on >> the lib you are using to encode the payload? >> >> As for now, I'm using a workaround that checks for the length of the >> token and adds the missing padding when needed before try to decode it. >> >> while (payload.length() % 4 != 0) payload += "="; >> >> >> That works but it is not ideal. >> >> *Should I create a bug on Keycloak's issue tracker?* >> >> Thanks in advance. >> >> Regards, >> Fab >> -- >> *Fabricio Milone* >> Developer >> >> *Shine Consulting * >> >> 30/600 Bourke Street >> >> Melbourne VIC 3000 >> >> T: 03 8488 9939 >> >> M: 04 3200 4006 >> >> >> www.shinetech.com *a* passion for excellence >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160509/b3d90190/attachment.html From sthorger at redhat.com Tue May 10 01:21:11 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 10 May 2016 07:21:11 +0200 Subject: [keycloak-user] JWT - Base64 encode/decode issues In-Reply-To: References: Message-ID: The online checkers doesn't fix anything, they just use the correct libraries. Plain base64 libraries doesn't work and that's expected because it's not the correct algorithm. The tokens are base64url encoded to make them URL safe so you need to use a base64url library. Alternatively, you can convert it into a base64 padded string first, then use a base64 decoder. On 10 May 2016 at 07:09, Brian Cook wrote: > I had the same problem as fabricio and implemented a version if the same > solution. The online checkers know how to fix the padding issue. Missing > padding doesn't affect the payload contents of course, and it really > depends on what language you are using when you decode. Python is strict > about the padding and will throw an error if the input string isn't the > right length. > > -Brian > On May 9, 2016 10:38 PM, "Stian Thorgersen" wrote: > >> It's base 64 url encoded, not base 64 encoded, so some padding is >> removed. I've just checked the payload you have above that is missing using >> http://kjur.github.io/jsjws/tool_b64udec.html and it's working just fine. >> >> On 10 May 2016 at 01:49, Fabricio Milone >> wrote: >> >>> Hi everyone, >>> >>> I've been experiencing some random issues when trying to decode the >>> returned idToken from the /protocol/openid-connect/token call. >>> >>> I've found that sometimes the returned idToken is not multiple of 4 and >>> has no padding at the end of the payload section (where mappers are added). >>> So the result is that I'm losing the last 2 characters of the last mapper >>> value. >>> >>> This is one example of a failing token (payload only): >>> >>> >>>> eyJqdGkiOiI4NWNlOGVlZS00N2Y5LTQzOTMtODc4Yi1iMjRiNTA0YWIzMWYiLCJleHAiOjE0NjI3NjY3MjMsIm5iZiI6MCwiaWF0IjoxNDYyNzY2NDIzLCJpc3MiOiJodHRwczovL2lkbS1zMi5zYi5kZXYuc2JldGVudi5jb20vYXV0aC9yZWFsbXMvZWxlY3RyaWNzaGVlcCIsImF1ZCI6ImVzIiwic3ViIjoiMDNlZGMzNzQtYzgyMC00ZDFhLWJhN2YtM2Y0NzlmOGRiMmM4IiwidHlwIjoiSUQiLCJhenAiOiJlcyIsInNlc3Npb25fc3RhdGUiOiIxY2I0Mjk3Zi04ODA3LTQ4ZWUtODBhNS1hMTI5NzRhN2EyYmQiLCJuYW1lIjoiZm5hbWUgbG5hbWUiLCJjdXN0SWQiOiIyNTY3NTgxIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiYW50aHRlc3QiLCJnaXZlbl9uYW1lIjoiZm5hbWUiLCJmYW1pbHlfbmFtZSI6ImxuYW1lIiwiZW1haWwiOiJub2JvZGF5QHNwb3J0c2JldC5jb20uYXUiLCJ0b2tlbiI6Ims4Z3NaKzlsV0dlZUVob212d09ocFk5bXlmeXdOQi9CWE1GWXBEQjErZTdHREJRa0h1R1BSYjJHOE4xYjFRdzJyUHdOVitvTTJzUUlMVVlXYXUvSHFFZ3JWUVhGeGdQd2dTVXl6UUtxaEYydW9KN3JzTFJkSFcza3ZRRy9JMUc1WlFtRnlnRE1va2NUIn0 >>> >>> >>> 787 chars (should be 788) >>> >>> if you try to decode it, you'll get: >>> >>> >>>> {"jti":"85ce8eee-47f9-4393-878b-b24b504ab31f","exp":1462766723,"nbf":0,"iat":1462766423,"iss":" >>>> https://idm-s2.sb.dev.sbetenv.com/auth/realms/electricsheep","aud":"es","sub":"03edc374-c820-4d1a-ba7f-3f479f8db2c8","typ":"ID","azp":"es","session_state":"1cb4297f-8807-48ee-80a5-a12974a7a2bd","name":"fname >>>> lname","custId":"2567581","preferred_username":"anthtest","given_name":"fname","family_name":"lname","email":" >>>> noboday at sportsbet.com.au >>>> ","token":"k8gsZ+9lWGeeEhomvwOhpY9myfywNB/BXMFYpDB1+e7GDBQkHuGPRb2G8N1b1Qw2rPwNV+oM2sQILUYWau/HqEgrVQXFxgPwgSUyzQKqhF2uoJ7rsLRdHW3kvQG/I1G5ZQmFygDMokcT >>> >>> >>> Which is incomplete. The last two chars (which are *"}*) are missing at >>> the end. >>> >>> So now, if I take the correct complete json and try to encode using >>> another library (as the one used here: https://www.base64encode.org/), >>> I'll get: >>> >>> >>>> eyJqdGkiOiI4NWNlOGVlZS00N2Y5LTQzOTMtODc4Yi1iMjRiNTA0YWIzMWYiLCJleHAiOjE0NjI3NjY3MjMsIm5iZiI6MCwiaWF0IjoxNDYyNzY2NDIzLCJpc3MiOiJodHRwczovL2lkbS1zMi5zYi5kZXYuc2JldGVudi5jb20vYXV0aC9yZWFsbXMvZWxlY3RyaWNzaGVlcCIsImF1ZCI6ImVzIiwic3ViIjoiMDNlZGMzNzQtYzgyMC00ZDFhLWJhN2YtM2Y0NzlmOGRiMmM4IiwidHlwIjoiSUQiLCJhenAiOiJlcyIsInNlc3Npb25fc3RhdGUiOiIxY2I0Mjk3Zi04ODA3LTQ4ZWUtODBhNS1hMTI5NzRhN2EyYmQiLCJuYW1lIjoiZm5hbWUgbG5hbWUiLCJjdXN0SWQiOiIyNTY3NTgxIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiYW50aHRlc3QiLCJnaXZlbl9uYW1lIjoiZm5hbWUiLCJmYW1pbHlfbmFtZSI6ImxuYW1lIiwiZW1haWwiOiJub2JvZGF5QHNwb3J0c2JldC5jb20uYXUiLCJ0b2tlbiI6Ims4Z3NaKzlsV0dlZUVob212d09ocFk5bXlmeXdOQi9CWE1GWXBEQjErZTdHREJRa0h1R1BSYjJHOE4xYjFRdzJyUHdOVitvTTJzUUlMVVlXYXUvSHFFZ3JWUVhGeGdQd2dTVXl6UUtxaEYydW9KN3JzTFJkSFcza3ZRRy9JMUc1WlFtRnlnRE1va2NUIn0 >>>> *=* >>> >>> >>> (788 chars, which is ok) >>> >>> Note the equal sign at the end. >>> >>> I'm wondering why Keycloak is not adding those paddings, is that a bug >>> on the lib you are using to encode the payload? >>> >>> As for now, I'm using a workaround that checks for the length of the >>> token and adds the missing padding when needed before try to decode it. >>> >>> while (payload.length() % 4 != 0) payload += "="; >>> >>> >>> That works but it is not ideal. >>> >>> *Should I create a bug on Keycloak's issue tracker?* >>> >>> Thanks in advance. >>> >>> Regards, >>> Fab >>> -- >>> *Fabricio Milone* >>> Developer >>> >>> *Shine Consulting * >>> >>> 30/600 Bourke Street >>> >>> Melbourne VIC 3000 >>> >>> T: 03 8488 9939 >>> >>> M: 04 3200 4006 >>> >>> >>> www.shinetech.com *a* passion for excellence >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160510/10c0e43a/attachment-0001.html From fabricio.milone at shinetech.com Tue May 10 01:48:34 2016 From: fabricio.milone at shinetech.com (Fabricio Milone) Date: Tue, 10 May 2016 15:48:34 +1000 Subject: [keycloak-user] JWT - Base64 encode/decode issues In-Reply-To: References: Message-ID: Well, that makes more sense now, since in Base64url padding is optional. Just wondering why you would use the URL safe when it is not included in a url... Thanks Stian. Regards. On 10 May 2016 at 15:21, Stian Thorgersen wrote: > The online checkers doesn't fix anything, they just use the correct > libraries. Plain base64 libraries doesn't work and that's expected because > it's not the correct algorithm. The tokens are base64url encoded to make > them URL safe so you need to use a base64url library. Alternatively, you > can convert it into a base64 padded string first, then use a base64 decoder. > > On 10 May 2016 at 07:09, Brian Cook wrote: > >> I had the same problem as fabricio and implemented a version if the same >> solution. The online checkers know how to fix the padding issue. Missing >> padding doesn't affect the payload contents of course, and it really >> depends on what language you are using when you decode. Python is strict >> about the padding and will throw an error if the input string isn't the >> right length. >> >> -Brian >> On May 9, 2016 10:38 PM, "Stian Thorgersen" wrote: >> >>> It's base 64 url encoded, not base 64 encoded, so some padding is >>> removed. I've just checked the payload you have above that is missing using >>> http://kjur.github.io/jsjws/tool_b64udec.html and it's working just >>> fine. >>> >>> On 10 May 2016 at 01:49, Fabricio Milone >>> wrote: >>> >>>> Hi everyone, >>>> >>>> I've been experiencing some random issues when trying to decode the >>>> returned idToken from the /protocol/openid-connect/token call. >>>> >>>> I've found that sometimes the returned idToken is not multiple of 4 and >>>> has no padding at the end of the payload section (where mappers are added). >>>> So the result is that I'm losing the last 2 characters of the last mapper >>>> value. >>>> >>>> This is one example of a failing token (payload only): >>>> >>>> >>>>> eyJqdGkiOiI4NWNlOGVlZS00N2Y5LTQzOTMtODc4Yi1iMjRiNTA0YWIzMWYiLCJleHAiOjE0NjI3NjY3MjMsIm5iZiI6MCwiaWF0IjoxNDYyNzY2NDIzLCJpc3MiOiJodHRwczovL2lkbS1zMi5zYi5kZXYuc2JldGVudi5jb20vYXV0aC9yZWFsbXMvZWxlY3RyaWNzaGVlcCIsImF1ZCI6ImVzIiwic3ViIjoiMDNlZGMzNzQtYzgyMC00ZDFhLWJhN2YtM2Y0NzlmOGRiMmM4IiwidHlwIjoiSUQiLCJhenAiOiJlcyIsInNlc3Npb25fc3RhdGUiOiIxY2I0Mjk3Zi04ODA3LTQ4ZWUtODBhNS1hMTI5NzRhN2EyYmQiLCJuYW1lIjoiZm5hbWUgbG5hbWUiLCJjdXN0SWQiOiIyNTY3NTgxIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiYW50aHRlc3QiLCJnaXZlbl9uYW1lIjoiZm5hbWUiLCJmYW1pbHlfbmFtZSI6ImxuYW1lIiwiZW1haWwiOiJub2JvZGF5QHNwb3J0c2JldC5jb20uYXUiLCJ0b2tlbiI6Ims4Z3NaKzlsV0dlZUVob212d09ocFk5bXlmeXdOQi9CWE1GWXBEQjErZTdHREJRa0h1R1BSYjJHOE4xYjFRdzJyUHdOVitvTTJzUUlMVVlXYXUvSHFFZ3JWUVhGeGdQd2dTVXl6UUtxaEYydW9KN3JzTFJkSFcza3ZRRy9JMUc1WlFtRnlnRE1va2NUIn0 >>>> >>>> >>>> 787 chars (should be 788) >>>> >>>> if you try to decode it, you'll get: >>>> >>>> >>>>> {"jti":"85ce8eee-47f9-4393-878b-b24b504ab31f","exp":1462766723,"nbf":0,"iat":1462766423,"iss":" >>>>> https://idm-s2.sb.dev.sbetenv.com/auth/realms/electricsheep","aud":"es","sub":"03edc374-c820-4d1a-ba7f-3f479f8db2c8","typ":"ID","azp":"es","session_state":"1cb4297f-8807-48ee-80a5-a12974a7a2bd","name":"fname >>>>> lname","custId":"2567581","preferred_username":"anthtest","given_name":"fname","family_name":"lname","email":" >>>>> noboday at sportsbet.com.au >>>>> ","token":"k8gsZ+9lWGeeEhomvwOhpY9myfywNB/BXMFYpDB1+e7GDBQkHuGPRb2G8N1b1Qw2rPwNV+oM2sQILUYWau/HqEgrVQXFxgPwgSUyzQKqhF2uoJ7rsLRdHW3kvQG/I1G5ZQmFygDMokcT >>>> >>>> >>>> Which is incomplete. The last two chars (which are *"}*) are missing >>>> at the end. >>>> >>>> So now, if I take the correct complete json and try to encode using >>>> another library (as the one used here: https://www.base64encode.org/), >>>> I'll get: >>>> >>>> >>>>> eyJqdGkiOiI4NWNlOGVlZS00N2Y5LTQzOTMtODc4Yi1iMjRiNTA0YWIzMWYiLCJleHAiOjE0NjI3NjY3MjMsIm5iZiI6MCwiaWF0IjoxNDYyNzY2NDIzLCJpc3MiOiJodHRwczovL2lkbS1zMi5zYi5kZXYuc2JldGVudi5jb20vYXV0aC9yZWFsbXMvZWxlY3RyaWNzaGVlcCIsImF1ZCI6ImVzIiwic3ViIjoiMDNlZGMzNzQtYzgyMC00ZDFhLWJhN2YtM2Y0NzlmOGRiMmM4IiwidHlwIjoiSUQiLCJhenAiOiJlcyIsInNlc3Npb25fc3RhdGUiOiIxY2I0Mjk3Zi04ODA3LTQ4ZWUtODBhNS1hMTI5NzRhN2EyYmQiLCJuYW1lIjoiZm5hbWUgbG5hbWUiLCJjdXN0SWQiOiIyNTY3NTgxIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiYW50aHRlc3QiLCJnaXZlbl9uYW1lIjoiZm5hbWUiLCJmYW1pbHlfbmFtZSI6ImxuYW1lIiwiZW1haWwiOiJub2JvZGF5QHNwb3J0c2JldC5jb20uYXUiLCJ0b2tlbiI6Ims4Z3NaKzlsV0dlZUVob212d09ocFk5bXlmeXdOQi9CWE1GWXBEQjErZTdHREJRa0h1R1BSYjJHOE4xYjFRdzJyUHdOVitvTTJzUUlMVVlXYXUvSHFFZ3JWUVhGeGdQd2dTVXl6UUtxaEYydW9KN3JzTFJkSFcza3ZRRy9JMUc1WlFtRnlnRE1va2NUIn0 >>>>> *=* >>>> >>>> >>>> (788 chars, which is ok) >>>> >>>> Note the equal sign at the end. >>>> >>>> I'm wondering why Keycloak is not adding those paddings, is that a bug >>>> on the lib you are using to encode the payload? >>>> >>>> As for now, I'm using a workaround that checks for the length of the >>>> token and adds the missing padding when needed before try to decode it. >>>> >>>> while (payload.length() % 4 != 0) payload += "="; >>>> >>>> >>>> That works but it is not ideal. >>>> >>>> *Should I create a bug on Keycloak's issue tracker?* >>>> >>>> Thanks in advance. >>>> >>>> Regards, >>>> Fab >>>> -- >>>> *Fabricio Milone* >>>> Developer >>>> >>>> *Shine Consulting * >>>> >>>> 30/600 Bourke Street >>>> >>>> Melbourne VIC 3000 >>>> >>>> T: 03 8488 9939 >>>> >>>> M: 04 3200 4006 >>>> >>>> >>>> www.shinetech.com *a* passion for excellence >>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>> >>> >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> > -- *Fabricio Milone* Developer *Shine Consulting * 30/600 Bourke Street Melbourne VIC 3000 T: 03 8488 9939 M: 04 3200 4006 www.shinetech.com *a* passion for excellence -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160510/1ed28b52/attachment.html From sthorger at redhat.com Tue May 10 01:53:33 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 10 May 2016 07:53:33 +0200 Subject: [keycloak-user] JWT - Base64 encode/decode issues In-Reply-To: References: Message-ID: Tokens can be included in the URL if you use implicit flow ( https://tools.ietf.org/html/rfc6749#section-1.3.2) it's also mandated by the JWT spec ( https://self-issued.info/docs/draft-ietf-oauth-json-web-token.html). On 10 May 2016 at 07:48, Fabricio Milone wrote: > Well, that makes more sense now, since in Base64url padding is optional. > > Just wondering why you would use the URL safe when it is not included in a > url... > > Thanks Stian. > > Regards. > > On 10 May 2016 at 15:21, Stian Thorgersen wrote: > >> The online checkers doesn't fix anything, they just use the correct >> libraries. Plain base64 libraries doesn't work and that's expected because >> it's not the correct algorithm. The tokens are base64url encoded to make >> them URL safe so you need to use a base64url library. Alternatively, you >> can convert it into a base64 padded string first, then use a base64 decoder. >> >> On 10 May 2016 at 07:09, Brian Cook wrote: >> >>> I had the same problem as fabricio and implemented a version if the same >>> solution. The online checkers know how to fix the padding issue. Missing >>> padding doesn't affect the payload contents of course, and it really >>> depends on what language you are using when you decode. Python is strict >>> about the padding and will throw an error if the input string isn't the >>> right length. >>> >>> -Brian >>> On May 9, 2016 10:38 PM, "Stian Thorgersen" wrote: >>> >>>> It's base 64 url encoded, not base 64 encoded, so some padding is >>>> removed. I've just checked the payload you have above that is missing using >>>> http://kjur.github.io/jsjws/tool_b64udec.html and it's working just >>>> fine. >>>> >>>> On 10 May 2016 at 01:49, Fabricio Milone >>> > wrote: >>>> >>>>> Hi everyone, >>>>> >>>>> I've been experiencing some random issues when trying to decode the >>>>> returned idToken from the /protocol/openid-connect/token call. >>>>> >>>>> I've found that sometimes the returned idToken is not multiple of 4 >>>>> and has no padding at the end of the payload section (where mappers are >>>>> added). So the result is that I'm losing the last 2 characters of the last >>>>> mapper value. >>>>> >>>>> This is one example of a failing token (payload only): >>>>> >>>>> >>>>>> eyJqdGkiOiI4NWNlOGVlZS00N2Y5LTQzOTMtODc4Yi1iMjRiNTA0YWIzMWYiLCJleHAiOjE0NjI3NjY3MjMsIm5iZiI6MCwiaWF0IjoxNDYyNzY2NDIzLCJpc3MiOiJodHRwczovL2lkbS1zMi5zYi5kZXYuc2JldGVudi5jb20vYXV0aC9yZWFsbXMvZWxlY3RyaWNzaGVlcCIsImF1ZCI6ImVzIiwic3ViIjoiMDNlZGMzNzQtYzgyMC00ZDFhLWJhN2YtM2Y0NzlmOGRiMmM4IiwidHlwIjoiSUQiLCJhenAiOiJlcyIsInNlc3Npb25fc3RhdGUiOiIxY2I0Mjk3Zi04ODA3LTQ4ZWUtODBhNS1hMTI5NzRhN2EyYmQiLCJuYW1lIjoiZm5hbWUgbG5hbWUiLCJjdXN0SWQiOiIyNTY3NTgxIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiYW50aHRlc3QiLCJnaXZlbl9uYW1lIjoiZm5hbWUiLCJmYW1pbHlfbmFtZSI6ImxuYW1lIiwiZW1haWwiOiJub2JvZGF5QHNwb3J0c2JldC5jb20uYXUiLCJ0b2tlbiI6Ims4Z3NaKzlsV0dlZUVob212d09ocFk5bXlmeXdOQi9CWE1GWXBEQjErZTdHREJRa0h1R1BSYjJHOE4xYjFRdzJyUHdOVitvTTJzUUlMVVlXYXUvSHFFZ3JWUVhGeGdQd2dTVXl6UUtxaEYydW9KN3JzTFJkSFcza3ZRRy9JMUc1WlFtRnlnRE1va2NUIn0 >>>>> >>>>> >>>>> 787 chars (should be 788) >>>>> >>>>> if you try to decode it, you'll get: >>>>> >>>>> >>>>>> {"jti":"85ce8eee-47f9-4393-878b-b24b504ab31f","exp":1462766723,"nbf":0,"iat":1462766423,"iss":" >>>>>> https://idm-s2.sb.dev.sbetenv.com/auth/realms/electricsheep","aud":"es","sub":"03edc374-c820-4d1a-ba7f-3f479f8db2c8","typ":"ID","azp":"es","session_state":"1cb4297f-8807-48ee-80a5-a12974a7a2bd","name":"fname >>>>>> lname","custId":"2567581","preferred_username":"anthtest","given_name":"fname","family_name":"lname","email":" >>>>>> noboday at sportsbet.com.au >>>>>> ","token":"k8gsZ+9lWGeeEhomvwOhpY9myfywNB/BXMFYpDB1+e7GDBQkHuGPRb2G8N1b1Qw2rPwNV+oM2sQILUYWau/HqEgrVQXFxgPwgSUyzQKqhF2uoJ7rsLRdHW3kvQG/I1G5ZQmFygDMokcT >>>>> >>>>> >>>>> Which is incomplete. The last two chars (which are *"}*) are missing >>>>> at the end. >>>>> >>>>> So now, if I take the correct complete json and try to encode using >>>>> another library (as the one used here: https://www.base64encode.org/), >>>>> I'll get: >>>>> >>>>> >>>>>> eyJqdGkiOiI4NWNlOGVlZS00N2Y5LTQzOTMtODc4Yi1iMjRiNTA0YWIzMWYiLCJleHAiOjE0NjI3NjY3MjMsIm5iZiI6MCwiaWF0IjoxNDYyNzY2NDIzLCJpc3MiOiJodHRwczovL2lkbS1zMi5zYi5kZXYuc2JldGVudi5jb20vYXV0aC9yZWFsbXMvZWxlY3RyaWNzaGVlcCIsImF1ZCI6ImVzIiwic3ViIjoiMDNlZGMzNzQtYzgyMC00ZDFhLWJhN2YtM2Y0NzlmOGRiMmM4IiwidHlwIjoiSUQiLCJhenAiOiJlcyIsInNlc3Npb25fc3RhdGUiOiIxY2I0Mjk3Zi04ODA3LTQ4ZWUtODBhNS1hMTI5NzRhN2EyYmQiLCJuYW1lIjoiZm5hbWUgbG5hbWUiLCJjdXN0SWQiOiIyNTY3NTgxIiwicHJlZmVycmVkX3VzZXJuYW1lIjoiYW50aHRlc3QiLCJnaXZlbl9uYW1lIjoiZm5hbWUiLCJmYW1pbHlfbmFtZSI6ImxuYW1lIiwiZW1haWwiOiJub2JvZGF5QHNwb3J0c2JldC5jb20uYXUiLCJ0b2tlbiI6Ims4Z3NaKzlsV0dlZUVob212d09ocFk5bXlmeXdOQi9CWE1GWXBEQjErZTdHREJRa0h1R1BSYjJHOE4xYjFRdzJyUHdOVitvTTJzUUlMVVlXYXUvSHFFZ3JWUVhGeGdQd2dTVXl6UUtxaEYydW9KN3JzTFJkSFcza3ZRRy9JMUc1WlFtRnlnRE1va2NUIn0 >>>>>> *=* >>>>> >>>>> >>>>> (788 chars, which is ok) >>>>> >>>>> Note the equal sign at the end. >>>>> >>>>> I'm wondering why Keycloak is not adding those paddings, is that a bug >>>>> on the lib you are using to encode the payload? >>>>> >>>>> As for now, I'm using a workaround that checks for the length of the >>>>> token and adds the missing padding when needed before try to decode it. >>>>> >>>>> while (payload.length() % 4 != 0) payload += "="; >>>>> >>>>> >>>>> That works but it is not ideal. >>>>> >>>>> *Should I create a bug on Keycloak's issue tracker?* >>>>> >>>>> Thanks in advance. >>>>> >>>>> Regards, >>>>> Fab >>>>> -- >>>>> *Fabricio Milone* >>>>> Developer >>>>> >>>>> *Shine Consulting * >>>>> >>>>> 30/600 Bourke Street >>>>> >>>>> Melbourne VIC 3000 >>>>> >>>>> T: 03 8488 9939 >>>>> >>>>> M: 04 3200 4006 >>>>> >>>>> >>>>> www.shinetech.com *a* passion for excellence >>>>> >>>>> _______________________________________________ >>>>> keycloak-user mailing list >>>>> keycloak-user at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>>> >>>> >>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>> >>> >> > > > -- > *Fabricio Milone* > Developer > > *Shine Consulting * > > 30/600 Bourke Street > > Melbourne VIC 3000 > > T: 03 8488 9939 > > M: 04 3200 4006 > > > www.shinetech.com *a* passion for excellence > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160510/e2f1fc18/attachment-0001.html From tech at psynd.net Tue May 10 03:17:18 2016 From: tech at psynd.net (Tech @ PSYND) Date: Tue, 10 May 2016 09:17:18 +0200 Subject: [keycloak-user] SMS customize authentication workflow Message-ID: <47dc0d1ec7ed7104ac64d43ded534c7c@psynd.net> Dear experts, after the successful login we would like the person to be challenged by a SMS sent on the phone. We think that the best option is to customize the OTP interface where, instead of trigger the procedure that will wait for the OTP challenge, will call a web service (already developed) and it will wait for the user entering the SMS received on the mobile. What steps should we perform to reach this goal? Thanks in advance From thomas.darimont at googlemail.com Tue May 10 03:43:06 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Tue, 10 May 2016 09:43:06 +0200 Subject: [keycloak-user] SMS customize authentication workflow In-Reply-To: <47dc0d1ec7ed7104ac64d43ded534c7c@psynd.net> References: <47dc0d1ec7ed7104ac64d43ded534c7c@psynd.net> Message-ID: Hello, would love to have support for that :) This was discussed a while ago [0*] and there is also a JIRA issue for that [1]. A common way to send SMS messages via API is twillio [2] - if we had a basic SPI we could write a twilio extension for sending SMS. Cheers, Thomas [0a] http://lists.jboss.org/pipermail/keycloak-dev/2015-August/005088.html [0b] http://lists.jboss.org/pipermail/keycloak-user/2015-October/003253.html [1] https://issues.jboss.org/browse/KEYCLOAK-241?jql=project%20%3D%20KEYCLOAK%20AND%20status%20%3D%20Open%20AND%20text%20~%20%22SMS%22 [2] https://www.twilio.com/sms 2016-05-10 9:17 GMT+02:00 Tech @ PSYND : > Dear experts, > > after the successful login we would like the person to be challenged by > a SMS sent on the phone. > > We think that the best option is to customize the OTP interface where, > instead of trigger the procedure that will wait for the OTP challenge, > will call a web service (already developed) and it will wait for the > user entering the SMS received on the mobile. > > What steps should we perform to reach this goal? > > Thanks in advance > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160510/c2a6b361/attachment.html From Vincent.Sluijter at crv4all.com Tue May 10 05:46:08 2016 From: Vincent.Sluijter at crv4all.com (Vincent Sluijter) Date: Tue, 10 May 2016 09:46:08 +0000 Subject: [keycloak-user] realm-identity-provider html for custom identity provider Message-ID: Hello, We created a custom (saml) identity provider module for keycloak and we want to configure it through the admin interface. To do this keycloak seems to expect a 'realm-identity-provider-providerid.html' in the base.admin.resources.partials theme folder. - What would be the best way to add this custom html file? We tried to add it to the module with a keycloak-themes.json but this only works when selecting the new theme in the Master realm. - Is it possible to extend the base/keycloak theme through the module? Because adding a theme for a provider in the master realm does not seem very maintainable. Vincent This message is subject to the following E-mail Disclaimer. (http://www.crv4all.com/disclaimer-email/) CRV Holding B.V. seats according to the articles of association in Arnhem, Dutch trade number 09125050. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160510/02aee188/attachment.html From tech at psynd.net Tue May 10 06:54:02 2016 From: tech at psynd.net (Tech @ PSYND) Date: Tue, 10 May 2016 12:54:02 +0200 Subject: [keycloak-user] SMS customize authentication workflow In-Reply-To: References: <47dc0d1ec7ed7104ac64d43ded534c7c@psynd.net> Message-ID: Hello Thomas, thank you for your tips, I'm happy that I'm not the only one struggleing with this topic! We are quite new to KeyCloak, and we are currently creating the forms for accepting the token received via SMS. We have already a system that implements the SMS gateway, in our case we only have to execute the SOAP call to this service. We are going through the documentation: have you some example about how to structure the code to integrate some forms? Thanks for the support! Mauro On 2016-05-10 09:43, Thomas Darimont wrote: > Hello, > > would love to have support for that :) > This was discussed a while ago [0*] and there is also a JIRA issue for > that [1]. > > A common way to send SMS messages via API is twillio [2] - if we had a > basic SPI > we could write a twilio extension for sending SMS. > > Cheers, > Thomas > > [0a] > http://lists.jboss.org/pipermail/keycloak-dev/2015-August/005088.html > [2] > [0b] > http://lists.jboss.org/pipermail/keycloak-user/2015-October/003253.html > [3] > [1] > https://issues.jboss.org/browse/KEYCLOAK-241?jql=project%20%3D%20KEYCLOAK%20AND%20status%20%3D%20Open%20AND%20text%20~%20%22SMS%22 > [4] > [2] https://www.twilio.com/sms [5] > > 2016-05-10 9:17 GMT+02:00 Tech @ PSYND : > >> Dear experts, >> >> after the successful login we would like the person to be >> challenged by >> a SMS sent on the phone. >> >> We think that the best option is to customize the OTP interface >> where, >> instead of trigger the procedure that will wait for the OTP >> challenge, >> will call a web service (already developed) and it will wait for >> the >> user entering the SMS received on the mobile. >> >> What steps should we perform to reach this goal? >> >> Thanks in advance >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user [1] > > > > Links: > ------ > [1] https://lists.jboss.org/mailman/listinfo/keycloak-user > [2] > http://lists.jboss.org/pipermail/keycloak-dev/2015-August/005088.html > [3] > http://lists.jboss.org/pipermail/keycloak-user/2015-October/003253.html > [4] > https://issues.jboss.org/browse/KEYCLOAK-241?jql=project%20%3D%20KEYCLOAK%20AND%20status%20%3D%20Open%20AND%20text%20~%20%22SMS%22 > [5] https://www.twilio.com/sms From ton at finalist.nl Tue May 10 08:18:47 2016 From: ton at finalist.nl (Ton Swieb) Date: Tue, 10 May 2016 14:18:47 +0200 Subject: [keycloak-user] Keycloak in production. Use MongoDB or an RDBMS flavour? Message-ID: Hi, I understand from the Keycloak documentation that both MongoDB and multiple flavours of RDBMS are supported, but I cannot find any recommendation whether to use MongoDB or an RDBMS by default. Which one is best suited for the Keycloak product? I am anticipating a user base of around 10000 users (mainly via Identity Brokering), will use offline tokens and use Keycloak as an Identity Broker for a SAML IdP. I am starting from a green field situation and do not have any restrictions on using a specific DB. I found a comment of Bill Birke on the Keycloak developer mailing-list, http://lists.jboss.org/pipermail/keycloak-dev/2015-July/004924.html, wishing he could drop Mongo and not seeing any advantages of using Mongo, but unfortunately the thread does not end with a conclusion/decision :-) What is the current position of the Keycloak team about using Mongo? In which scenario should I consider using MongoDB over an RDBMS or vice versa? There are off course the usual pro/con's between NoSQL and RDBMS, but I would like to know to what extend they hold true when it comes to using Keycloak in production or whether Keycloak is optimized specifically for NoSQL or RDBMS. Regards, Ton -- From kalc04 at gmail.com Tue May 10 08:35:37 2016 From: kalc04 at gmail.com (Lohitha Chiranjeewa) Date: Tue, 10 May 2016 18:05:37 +0530 Subject: [keycloak-user] Last Login Time of User Message-ID: Hi, Is there a way to retrieve the last login time of a given user? I checked the Admin Console, Rest specification and the mysql DB structure but couldn't find a place where that bit of information could be stored and retrieved from. Have I missed a place or is that feature not available (yet)? Regards, Lohitha. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160510/132ad417/attachment.html From thomas.darimont at googlemail.com Tue May 10 08:38:22 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Tue, 10 May 2016 14:38:22 +0200 Subject: [keycloak-user] Last Login Time of User In-Reply-To: References: Message-ID: Hello, I implemented a custom RequiredAction that maintains stuff like: - first login time - most recent login time - login count in user attributes. Cheers, Thomas 2016-05-10 14:35 GMT+02:00 Lohitha Chiranjeewa : > Hi, > > Is there a way to retrieve the last login time of a given user? > > I checked the Admin Console, Rest specification and the mysql DB structure > but couldn't find a place where that bit of information could be stored and > retrieved from. Have I missed a place or is that feature not available > (yet)? > > > Regards, > Lohitha. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160510/69af4aa6/attachment.html From subhrajyotim at gmail.com Tue May 10 09:11:13 2016 From: subhrajyotim at gmail.com (Subhrajyoti Moitra) Date: Tue, 10 May 2016 18:41:13 +0530 Subject: [keycloak-user] Keycloak for Client services behind loadbalancers Message-ID: Hello, I have a client application, that will be using Keycloak for authentication and authorization. There are 2 instances of this application running on (lets say) service1 and service2. These 2 service instance are behind the load balancer. The load balancer has sticky sessions on. Now a user browses to the loadbalancer url, which in turn serves the service instances, service1 or service2. Now when the service instance pages are using keycloak.js to verify the login, I dont get the loadbalancer URL as the redirect url value, rather the redirect url is of the actual service instance URL on which the service is hosted. How do i use Keycloak for loadbalanced services? Is there some specific setting, or setup of the server? Please help and guide, Thanks and cheers, Subhro. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160510/cda29cc0/attachment.html From binarymonk01 at yahoo.com Tue May 10 09:17:19 2016 From: binarymonk01 at yahoo.com (Darren Hartford) Date: Tue, 10 May 2016 13:17:19 +0000 (UTC) Subject: [keycloak-user] Authorization question (maybe not keycloak?) References: <379356563.1922580.1462886239492.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <379356563.1922580.1462886239492.JavaMail.yahoo@mail.yahoo.com> Hi all,So, Keycloak has a lot of items around Authentication approaches, but I haven't seen anything specific around authorization - is that a different project? My actual question is this - if you have java apps that have?role1 or are using @DeclareRoles, is there a mechanism where the application/SP can *register* with the PDP with those roles, rather than copy-pasting into those different IAM/PDP solutions? thanky!-D -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160510/c470276d/attachment.html From tech at psynd.net Tue May 10 09:51:45 2016 From: tech at psynd.net (Tech @ PSYND) Date: Tue, 10 May 2016 15:51:45 +0200 Subject: [keycloak-user] CUstom authentication flow Message-ID: <96373974ef3ec2de43c949bfbc020f1b@psynd.net> Dear experts, I'm working with version 1.9.4 of the product, I'm developing a couple of custom forms that should be integrated into an authentication workflow. Following the example integrated into the product: 1) I compiled the "org.keycloak.examples.authenticator" 2) I copied the "secret'question.ftl" and "secret'question'config.ftl" files into the keycloak/themes/keycloak/login and keycloak/themes/base/login 3) I moved the generated jar file "authenticator-required-action-example.jar" into keycloak/providers 4) I opened the admin console, I create a new flow consisting of "Username and passowrd" and "Secret-question". I try to login with a user and the error message that I get is: 15:36:26,319 ERROR [org.keycloak.forms.login.freemarker.FreeMarkerLoginFormsProvider] (default task-15) Failed to process template: org.keycloak.theme.FreeMarkerException: Failed to process template secret-question-config.ftl That is compatible with what I found here: https://issues.jboss.org/browse/KEYCLOAK-2534 But I copied the files in the correct position: what else could cause such error? Thanks From thomas.darimont at googlemail.com Tue May 10 11:10:36 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Tue, 10 May 2016 17:10:36 +0200 Subject: [keycloak-user] Last Login Time of User In-Reply-To: References: Message-ID: Would be great to store some additional information like: - count of failed logins - last failed login date Cheers, Thomas 2016-05-10 14:38 GMT+02:00 Thomas Darimont : > Hello, > > I implemented a custom RequiredAction that maintains stuff like: > - first login time > - most recent login time > - login count > in user attributes. > > Cheers, > Thomas > > 2016-05-10 14:35 GMT+02:00 Lohitha Chiranjeewa : > >> Hi, >> >> Is there a way to retrieve the last login time of a given user? >> >> I checked the Admin Console, Rest specification and the mysql DB >> structure but couldn't find a place where that bit of information could be >> stored and retrieved from. Have I missed a place or is that feature not >> available (yet)? >> >> >> Regards, >> Lohitha. >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160510/05b259b6/attachment.html From chairfield at gmail.com Tue May 10 11:29:19 2016 From: chairfield at gmail.com (Chris Hairfield) Date: Tue, 10 May 2016 15:29:19 +0000 Subject: [keycloak-user] Environment-specific configuration available in theme In-Reply-To: References: <573098AB.30701@redhat.com> Message-ID: Interesting. Would you mind showing a code example, Stian? I assumed that the Javascript had no access to environment variables, as is standard; are environment variables accessible from the template? Any ability to read environment variables directly would simplify our approach. Marek, thank you for your suggestion. We are able to read values from our theme.properties file exactly as you described. On Mon, May 9, 2016 at 10:40 PM Stian Thorgersen wrote: > Not sure how you're implementing the profile upload, but you just need to > use a environment value. Any code you write would have access to that. > > On 9 May 2016 at 16:03, Marek Posolda wrote: > >> Maybe you can use "theme.properties" file and configure some property, >> which will be different in your staging and production environment . In the >> freemarker template, the properties of theme should be available under key >> "properties" . So you can read your property from the freemarker file. >> >> Seems you will need different version of theme.properties for your >> staging and production, but I don't have better idea to solve this :/ >> >> Marek >> >> >> On 06/05/16 23:04, Chris Hairfield wrote: >> >> We're considering building an account management theme that is capable of >> uploading a profile photo. We'd save the photo to an S3 bucket, and would >> wish to do so based on environment; our stage Keycloak would point to a >> stage S3 bucket, prod to the prod bucket, etc.. >> >> >> Is there a way to configure Keycloak on a per-environment basis such that >> our theme could know its environment in order to point to the correct S3 >> bucket? >> >> >> Thanks! >> Chris >> >> >> _______________________________________________ >> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user >> >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160510/01a7c802/attachment-0001.html From sthorger at redhat.com Wed May 11 00:42:17 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 11 May 2016 06:42:17 +0200 Subject: [keycloak-user] Environment-specific configuration available in theme In-Reply-To: References: <573098AB.30701@redhat.com> Message-ID: I was assuming Java code, but didn't understand how you implemented profile upload ;) Go with Mareks suggestions as you won't have access to env variables from within JavaScript. theme.properties doesn't currently support using system properties or env variables, but maybe it should. You can create JIRA for it if you want. On 10 May 2016 at 17:29, Chris Hairfield wrote: > Interesting. Would you mind showing a code example, Stian? I assumed that > the Javascript had no access to environment variables, as is standard; are > environment variables accessible from the template? Any ability to read > environment variables directly would simplify our approach. > > Marek, thank you for your suggestion. We are able to read values from our > theme.properties file exactly as you described. > > On Mon, May 9, 2016 at 10:40 PM Stian Thorgersen > wrote: > >> Not sure how you're implementing the profile upload, but you just need to >> use a environment value. Any code you write would have access to that. >> >> On 9 May 2016 at 16:03, Marek Posolda wrote: >> >>> Maybe you can use "theme.properties" file and configure some property, >>> which will be different in your staging and production environment . In the >>> freemarker template, the properties of theme should be available under key >>> "properties" . So you can read your property from the freemarker file. >>> >>> Seems you will need different version of theme.properties for your >>> staging and production, but I don't have better idea to solve this :/ >>> >>> Marek >>> >>> >>> On 06/05/16 23:04, Chris Hairfield wrote: >>> >>> We're considering building an account management theme that is capable >>> of uploading a profile photo. We'd save the photo to an S3 bucket, and >>> would wish to do so based on environment; our stage Keycloak would point to >>> a stage S3 bucket, prod to the prod bucket, etc.. >>> >>> >>> Is there a way to configure Keycloak on a per-environment basis such >>> that our theme could know its environment in order to point to the correct >>> S3 bucket? >>> >>> >>> Thanks! >>> Chris >>> >>> >>> _______________________________________________ >>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user >>> >>> >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160511/c9257cde/attachment.html From sthorger at redhat.com Wed May 11 00:45:32 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 11 May 2016 06:45:32 +0200 Subject: [keycloak-user] realm-identity-provider html for custom identity provider In-Reply-To: References: Message-ID: I don't recommend adding it to the base/keycloak theme as it could make upgrading more difficult. Instead create your own theme, but it's not "provider" specific. You can add as many providers as you want in the theme, so I don't see how it wouldn't be maintainable? On 10 May 2016 at 11:46, Vincent Sluijter wrote: > Hello, > > > > We created a custom (saml) identity provider module for keycloak and we > want to configure it through the admin interface. To do this keycloak seems > to expect a ?realm-identity-provider-providerid.html? in the > base.admin.resources.partials theme folder. > > - What would be the best way to add this custom html file? We > tried to add it to the module with a keycloak-themes.json but this only > works when selecting the new theme in the Master realm. > > - Is it possible to extend the base/keycloak theme through the > module? Because adding a theme for a provider in the master realm does not > seem very maintainable. > > > > Vincent > This message is subject to the following E-mail Disclaimer. ( > http://www.crv4all.com/disclaimer-email/) CRV Holding B.V. seats > according to the articles of association in Arnhem, Dutch trade number > 09125050. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160511/1ca99742/attachment.html From mposolda at redhat.com Wed May 11 03:23:12 2016 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 11 May 2016 09:23:12 +0200 Subject: [keycloak-user] Last Login Time of User In-Reply-To: References: Message-ID: <5732DDE0.70207@redhat.com> Another possibility is to look at userSession (this info is available in admin console). When user authenticates, the new userSession is created for him with the "started" attribute containing the time of authentication. In admin console (and also via REST endpoints) there is possibility to look at all userSessions of particular user, so you can chose the one with last "started" attribute. This requires some additional work for parse userSessions and also there is corner case when this info is not accurate (as new userSession is also created when "verify-email" is requested for particular user, which is not the time of successful authentication of particular user). On the other hand, you don't need the custom Authenticator implementation. And there is also performance penalty in store the info in DB in user attributes, because you need to write to DB and update user during each login. Marek On 10/05/16 17:10, Thomas Darimont wrote: > Would be great to store some additional information like: > - count of failed logins > - last failed login date > > Cheers, > Thomas > > 2016-05-10 14:38 GMT+02:00 Thomas Darimont > >: > > Hello, > > I implemented a custom RequiredAction that maintains stuff like: > - first login time > - most recent login time > - login count > in user attributes. > > Cheers, > Thomas > > 2016-05-10 14:35 GMT+02:00 Lohitha Chiranjeewa >: > > Hi, > > Is there a way to retrieve the last login time of a given user? > > I checked the Admin Console, Rest specification and the mysql > DB structure but couldn't find a place where that bit of > information could be stored and retrieved from. Have I missed > a place or is that feature not available (yet)? > > > Regards, > Lohitha. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160511/ac956142/attachment.html From mposolda at redhat.com Wed May 11 03:31:06 2016 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 11 May 2016 09:31:06 +0200 Subject: [keycloak-user] CUstom authentication flow In-Reply-To: <96373974ef3ec2de43c949bfbc020f1b@psynd.net> References: <96373974ef3ec2de43c949bfbc020f1b@psynd.net> Message-ID: <5732DFBA.7010508@redhat.com> Maybe if you copy just to "keycloak/themes/base/login", but not to "keycloak/themes/keycloak/login" ? Besides that, the error is different then in the JIRA you linked. You have "Failed to process template" . Didn't you any changes in the security-question-config.ftl? Adding whole stacktrace might be better though... Marek On 10/05/16 15:51, Tech @ PSYND wrote: > Dear experts, > > I'm working with version 1.9.4 of the product, I'm developing a couple > of custom forms that should be integrated into an authentication > workflow. > > Following the example integrated into the product: > 1) I compiled the "org.keycloak.examples.authenticator" > 2) I copied the "secret'question.ftl" and "secret'question'config.ftl" > files into the keycloak/themes/keycloak/login and > keycloak/themes/base/login > 3) I moved the generated jar file > "authenticator-required-action-example.jar" into keycloak/providers > 4) I opened the admin console, I create a new flow consisting of > "Username and passowrd" and "Secret-question". > > I try to login with a user and the error message that I get is: > > 15:36:26,319 ERROR > [org.keycloak.forms.login.freemarker.FreeMarkerLoginFormsProvider] > (default task-15) Failed to process template: > org.keycloak.theme.FreeMarkerException: Failed to process template > secret-question-config.ftl > > That is compatible with what I found here: > https://issues.jboss.org/browse/KEYCLOAK-2534 > > But I copied the files in the correct position: what else could cause > such error? > > Thanks > > > > > > > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From mposolda at redhat.com Wed May 11 03:45:05 2016 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 11 May 2016 09:45:05 +0200 Subject: [keycloak-user] Keycloak in production. Use MongoDB or an RDBMS flavour? In-Reply-To: References: Message-ID: <5732E301.5040108@redhat.com> On 10/05/16 14:18, Ton Swieb wrote: > Hi, > > I understand from the Keycloak documentation that both MongoDB and > multiple flavours of RDBMS are supported, but I cannot find any > recommendation whether to use MongoDB or an RDBMS by default. > > Which one is best suited for the Keycloak product? > I am anticipating a user base of around 10000 users (mainly via > Identity Brokering), will use offline tokens and use Keycloak as an > Identity Broker for a SAML IdP. I am starting from a green field > situation and do not have any restrictions on using a specific DB. > > I found a comment of Bill Birke on the Keycloak developer > mailing-list, http://lists.jboss.org/pipermail/keycloak-dev/2015-July/004924.html, > wishing he could drop Mongo and not seeing any advantages of using > Mongo, but unfortunately the thread does not end with a > conclusion/decision :-) > > What is the current position of the Keycloak team about using Mongo? We added Mongo support very early (somewhen around 2013) as an alternative storage, which was at that time required by other project, which consumed keycloak. The second project (Liveoak) is not under active development anymore, but in the meantime, a lot of people started to use Keycloak with Mongo and it seems that some of them already in production. The advantage of Mongo is good performance and scalability. At some point, when I tested performance with bigger number of users, I saw much better performance for Mongo then for MySQL. Also Mongo has support for DB clustering and sharding (some RDBMS has it too AFAIK, but usually you need to pay for them, which is not the case with Mongo ;)) . On the other hand, biggest disadvantage of Mongo is missing support for transactions. So in theory, if some error/bad situation happens, you can theoretically end with partially inconsistent data in DB. Marek > > In which scenario should I consider using MongoDB over an RDBMS or > vice versa? There are off course the usual pro/con's between NoSQL and > RDBMS, but I would like to know to what extend they hold true when it > comes to using Keycloak in production or whether Keycloak is optimized > specifically for NoSQL or RDBMS. > > Regards, > > Ton > From mposolda at redhat.com Wed May 11 03:49:36 2016 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 11 May 2016 09:49:36 +0200 Subject: [keycloak-user] Authorization question (maybe not keycloak?) In-Reply-To: <379356563.1922580.1462886239492.JavaMail.yahoo@mail.yahoo.com> References: <379356563.1922580.1462886239492.JavaMail.yahoo.ref@mail.yahoo.com> <379356563.1922580.1462886239492.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5732E410.4090007@redhat.com> On 10/05/16 15:17, Darren Hartford wrote: > Hi all, > So, Keycloak has a lot of items around Authentication approaches, but > I haven't seen anything specific around authorization - is that a > different project? We plan to add support for authorization. The prototype and instructions to try it are here [1] . > > My actual question is this - if you have java apps that have > role1 or are > using @DeclareRoles, is there a mechanism where the application/SP can > *register* with the PDP with those roles, rather than copy-pasting > into those different IAM/PDP solutions? We have client registration documented here [2] , but not sure if it has support for register client roles into Keycloak based on roles declared in web.xml. Probably not (and not sure if it's even realistic to add that). [1] https://github.com/pedroigor/keycloak/blob/KEYCLOAK-2753/authz/README.md [2] http://keycloak.github.io/docs/userguide/keycloak-server/html/client-registration.html Marek > thanky! > -D > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160511/411df1ea/attachment.html From glaissard at axway.com Wed May 11 04:45:53 2016 From: glaissard at axway.com (Gerard Laissard) Date: Wed, 11 May 2016 08:45:53 +0000 Subject: [keycloak-user] Validating JWT tokens In-Reply-To: References: <1462377616.1947384.598056425.5C00B82A@webmail.messagingengine.com> <1462379847.1956071.598104761.4A24EAC6@webmail.messagingengine.com> Message-ID: <4AC8C602867B3A4CB6F9F6BA4528DEE477CD682C@WPHXMAIL1.phx.axway.int> My 2 cents: There is an openSSL example to verify a jwt: https://gist.github.com/rolandyoung/176dd310a6948e094be6 By using jose4j // be sure you do not have any EOL at the end of the token String accesToken = ?; accesToken = accesToken.replaceAll("\r\n", ""); accesToken = accesToken.replaceAll("\n", ""); JsonWebSignature jws = new JsonWebSignature(); jws.setCompactSerialization(accesToken); jws.setKey(publicKey); boolean signatureVerified = jws.verifySignature(); To get a PublicKey : if you put the content of the realm public you get from keycloak admin public PublicKey getPublicKey(String fileName) { File f = new File(fileName); try (FileInputStream fis = new FileInputStream(f); DataInputStream dis = new DataInputStream(fis);) { byte[] keyBytes = new byte[(int) f.length()]; dis.readFully(keyBytes); dis.close(); // convert to der format String pem = new String(keyBytes); pem = pem.replaceAll("-----BEGIN (.*)-----", ""); pem = pem.replaceAll("-----END (.*)----", ""); pem = pem.replaceAll("\r\n", ""); pem = pem.replaceAll("\n", ""); byte[] der = Base64.getDecoder().decode(pem); // java 8 X509EncodedKeySpec spec = new X509EncodedKeySpec(der); KeyFactory kf = KeyFactory.getInstance(RSA); return kf.generatePublic(spec); } catch (IOException | InvalidKeySpecException | NoSuchAlgorithmException e) { throw new RuntimeException("Failed to load public key from file '" + fileName + "'", e); } } With Java 8, it is quite simple too String[] tokenParts = accessToken.split("\\."); // detect algo from tokenParts[0] or put "SHA256withRSA? (for ?RS256?) String jwtSignAlgo = "SHA256withRSA"; String jwtInputString = tokenParts[0] + ?.? + tokenParts[1]; String jwtDecodedSign = new String(Base64.getUrlDecoder().decode(tokenParts[2]); Signature verifier = Signature.getInstance(jwtSignAlgo); verifier.initVerify(publicKey); verifier.update(jwtInputString.getBytes("UTF-8")); boolean signatureVerified = verifier.verify(jwtDecodedSign); gerard From: keycloak-user-bounces at lists.jboss.org [mailto:keycloak-user-bounces at lists.jboss.org] On Behalf Of Stian Thorgersen Sent: vendredi 6 mai 2016 07:33 To: Aikeaguinea Cc: keycloak-user Subject: Re: [keycloak-user] Validating JWT tokens On 4 May 2016 at 18:37, Aikeaguinea > wrote: Figured it out, kinda. I have to use the Realm public key, and at least in jwt.io it has to begin with "-----BEGIN PUBLIC KEY-----" and end with "-----END PUBLIC KEY-----" -- these can't be omitted. If I try using the Realm certificate, it won't work, however, whether or not I use "-----BEGIN CERTIFICATE-----"/"-----END CERTIFICATE-----". If I use the validator at http://kjur.github.io/jsjws/tool_jwt.html and select "default X509 Certificate (RSA z4) it tells me "Error: malformed X.509 certificate PEM (code:003)" I can use the Realm public key for validating the JWT, but shouldn't the certificate work as well? The certificate is only used by SAML, so no you can't verify the JWT with the certificate only the public key. On Wed, May 4, 2016, at 12:00 PM, Aikeaguinea wrote: > I have a client with a service account and credentials using Signed Jwt. > Authentication works fine. The service uses > org.keycloak.adapters.authentication.ClientCredentialsProviderUtils#setClientCredentials > to create the JWT token and set the headers, and I get back a JWT > containing an access token from Keycloak. > > However, when I use jwt.io to look at the access token, I can't validate > the signature. This is true whether I use the client Certificate (from > the client's Credentials tab), the Realm public key, or the Realm > Certificate. In addition, I have generated the client's public key from > the certificate using > > keytool -exportcert -alias x -keypass y -storepass z -rfc -keystore > client-keystore.jks | openssl x509 -inform pem -pubkey > > on the jks file supplied when I generated the client credentials, and > that doesn't work either. > > We've also been having trouble validating the signature programmatically > using Java. > > Any idea why I might be seeing this? > > -- > http://www.fastmail.com - Or how I learned to stop worrying and > love email again > -- Aikeaguinea aikeaguinea at xsmail.com -- http://www.fastmail.com - Send your email first class _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160511/0c265644/attachment-0001.html From thomas.darimont at googlemail.com Wed May 11 05:09:46 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Wed, 11 May 2016 11:09:46 +0200 Subject: [keycloak-user] Validating JWT tokens In-Reply-To: <4AC8C602867B3A4CB6F9F6BA4528DEE477CD682C@WPHXMAIL1.phx.axway.int> References: <1462377616.1947384.598056425.5C00B82A@webmail.messagingengine.com> <1462379847.1956071.598104761.4A24EAC6@webmail.messagingengine.com> <4AC8C602867B3A4CB6F9F6BA4528DEE477CD682C@WPHXMAIL1.phx.axway.int> Message-ID: Hello, another example for (Parsing) & Validating a Keycloak JWT was posted on the ML a few months ago: http://lists.jboss.org/pipermail/keycloak-user/2016-March/005325.html In the example the token is only successfully parsed when the token is valid. Cheers, Thomas 2016-05-11 10:45 GMT+02:00 Gerard Laissard : > > > My 2 cents: > > There is an openSSL example to verify a jwt: > > https://gist.github.com/rolandyoung/176dd310a6948e094be6 > > > > By using jose4j > > // be sure you do not have any EOL at the end of the token > > String accesToken = ?; > > accesToken = accesToken.replaceAll("\r\n", ""); > > accesToken = accesToken.replaceAll("\n", ""); > > > > JsonWebSignature jws = *new* JsonWebSignature(); > > jws.setCompactSerialization(accesToken); > > jws.setKey(publicKey); > > boolean signatureVerified = jws.verifySignature(); > > To get a PublicKey : if you put the content of the realm public you get > from keycloak admin > > *public* PublicKey getPublicKey(String fileName) { > > File f = *new* File(fileName); > > *try* (FileInputStream fis = *new* FileInputStream(f); > > DataInputStream dis = *new* DataInputStream(fis);) { > > *byte*[] keyBytes = *new* *byte*[(*int*) f.length()]; > > dis.readFully(keyBytes); > > dis.close(); > > // convert to der format > > String pem = new String(keyBytes); > > pem = pem.replaceAll("-----BEGIN (.*)-----", ""); > > pem = pem.replaceAll("-----END (.*)----", ""); > > pem = pem.replaceAll("\r\n", ""); > > pem = pem.replaceAll("\n", ""); > > byte[] der = Base64.getDecoder().decode(pem); // java 8 > > X509EncodedKeySpec spec = *new* X509EncodedKeySpec(der); > > KeyFactory kf = KeyFactory.*getInstance*(*RSA*); > > *return* kf.generatePublic(spec); > > > > } *catch* (IOException | InvalidKeySpecException | > NoSuchAlgorithmException e) { > > *throw* *new* RuntimeException("Failed to load public key > from file '" + fileName + "'", e); > > } > > } > > > > With Java 8, it is quite simple too > > String[] tokenParts = accessToken.split("\\."); > > // detect algo from tokenParts[0] or put "SHA256withRSA? (for ?RS256?) > > String jwtSignAlgo = "SHA256withRSA"; > > String jwtInputString = tokenParts[0] + ?.? + tokenParts[1]; > > String jwtDecodedSign = new > String(Base64.getUrlDecoder().decode(tokenParts[2]); > > Signature verifier = Signature.getInstance(jwtSignAlgo); > > verifier.initVerify(publicKey); > > verifier.update(jwtInputString.getBytes("UTF-8")); > > boolean signatureVerified = verifier.verify(jwtDecodedSign); > > > > > > gerard > > > > > > *From:* keycloak-user-bounces at lists.jboss.org [mailto: > keycloak-user-bounces at lists.jboss.org] *On Behalf Of *Stian Thorgersen > *Sent:* vendredi 6 mai 2016 07:33 > *To:* Aikeaguinea > *Cc:* keycloak-user > *Subject:* Re: [keycloak-user] Validating JWT tokens > > > > > > > > On 4 May 2016 at 18:37, Aikeaguinea wrote: > > Figured it out, kinda. I have to use the Realm public key, and at least > in jwt.io it has to begin with "-----BEGIN PUBLIC KEY-----" and end with > "-----END PUBLIC KEY-----" -- these can't be omitted. > > If I try using the Realm certificate, it won't work, however, whether or > not I use "-----BEGIN CERTIFICATE-----"/"-----END CERTIFICATE-----". > > If I use the validator at http://kjur.github.io/jsjws/tool_jwt.html and > select "default X509 Certificate (RSA z4) it tells me "Error: malformed > X.509 certificate PEM (code:003)" > > I can use the Realm public key for validating the JWT, but shouldn't the > certificate work as well? > > > > The certificate is only used by SAML, so no you can't verify the JWT with > the certificate only the public key. > > > > > On Wed, May 4, 2016, at 12:00 PM, Aikeaguinea wrote: > > I have a client with a service account and credentials using Signed Jwt. > > Authentication works fine. The service uses > > > org.keycloak.adapters.authentication.ClientCredentialsProviderUtils#setClientCredentials > > to create the JWT token and set the headers, and I get back a JWT > > containing an access token from Keycloak. > > > > However, when I use jwt.io to look at the access token, I can't validate > > the signature. This is true whether I use the client Certificate (from > > the client's Credentials tab), the Realm public key, or the Realm > > Certificate. In addition, I have generated the client's public key from > > the certificate using > > > > keytool -exportcert -alias x -keypass y -storepass z -rfc -keystore > > client-keystore.jks | openssl x509 -inform pem -pubkey > > > > on the jks file supplied when I generated the client credentials, and > > that doesn't work either. > > > > We've also been having trouble validating the signature programmatically > > using Java. > > > > Any idea why I might be seeing this? > > > > -- > > http://www.fastmail.com - Or how I learned to stop worrying and > > love email again > > > > > -- > Aikeaguinea > aikeaguinea at xsmail.com > > -- > http://www.fastmail.com - Send your email first class > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160511/72411397/attachment-0001.html From ivan at akvo.org Wed May 11 05:31:30 2016 From: ivan at akvo.org (=?UTF-8?Q?Iv=c3=a1n_Perdomo?=) Date: Wed, 11 May 2016 11:31:30 +0200 Subject: [keycloak-user] Authorization question (maybe not keycloak?) In-Reply-To: <5732E410.4090007@redhat.com> References: <379356563.1922580.1462886239492.JavaMail.yahoo.ref@mail.yahoo.com> <379356563.1922580.1462886239492.JavaMail.yahoo@mail.yahoo.com> <5732E410.4090007@redhat.com> Message-ID: <205ab086-6407-f7ae-7dfd-5c805b1e40f5@akvo.org> Hi Marek, On 05/11/2016 09:49 AM, Marek Posolda wrote: > We plan to add support for authorization. The prototype and instructions > to try it are here [1] . Do you know if this work is still targeting 2.0.0RC1? I've not seen activity in the pull request [1] or issue [2] [1] https://github.com/keycloak/keycloak/pull/2617 [2] https://issues.jboss.org/browse/KEYCLOAK-2753 Thanks, -- Iv?n -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160511/654516c0/attachment.bin From mposolda at redhat.com Wed May 11 06:05:57 2016 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 11 May 2016 12:05:57 +0200 Subject: [keycloak-user] Authorization question (maybe not keycloak?) In-Reply-To: <205ab086-6407-f7ae-7dfd-5c805b1e40f5@akvo.org> References: <379356563.1922580.1462886239492.JavaMail.yahoo.ref@mail.yahoo.com> <379356563.1922580.1462886239492.JavaMail.yahoo@mail.yahoo.com> <5732E410.4090007@redhat.com> <205ab086-6407-f7ae-7dfd-5c805b1e40f5@akvo.org> Message-ID: <57330405.9040706@redhat.com> Hi Ivan, the PR and issue is inactive just because we are mainly focused on polishing/testing of 1.9.x instead of new features for 2.0.x. I guess it will be merged within few months (or even earlier) and hopefully available in 2.0.0.CR1. Marek On 11/05/16 11:31, Iv?n Perdomo wrote: > Hi Marek, > > On 05/11/2016 09:49 AM, Marek Posolda wrote: >> We plan to add support for authorization. The prototype and instructions >> to try it are here [1] . > Do you know if this work is still targeting 2.0.0RC1? I've not seen > activity in the pull request [1] or issue [2] > > [1] https://github.com/keycloak/keycloak/pull/2617 > [2] https://issues.jboss.org/browse/KEYCLOAK-2753 > > Thanks, > From psilva at redhat.com Wed May 11 08:23:14 2016 From: psilva at redhat.com (Pedro Igor Silva) Date: Wed, 11 May 2016 08:23:14 -0400 (EDT) Subject: [keycloak-user] Authorization question (maybe not keycloak?) In-Reply-To: <205ab086-6407-f7ae-7dfd-5c805b1e40f5@akvo.org> References: <379356563.1922580.1462886239492.JavaMail.yahoo.ref@mail.yahoo.com> <379356563.1922580.1462886239492.JavaMail.yahoo@mail.yahoo.com> <5732E410.4090007@redhat.com> <205ab086-6407-f7ae-7dfd-5c805b1e40f5@akvo.org> Message-ID: <484103131.3799971.1462969394596.JavaMail.zimbra@redhat.com> Hi Iv?n, Can you share what you are looking for around authorization ? Regards. Pedro Igor ----- Original Message ----- From: "Iv?n Perdomo" To: "Marek Posolda" , keycloak-user at lists.jboss.org Sent: Wednesday, May 11, 2016 6:31:30 AM Subject: Re: [keycloak-user] Authorization question (maybe not keycloak?) Hi Marek, On 05/11/2016 09:49 AM, Marek Posolda wrote: > We plan to add support for authorization. The prototype and instructions > to try it are here [1] . Do you know if this work is still targeting 2.0.0RC1? I've not seen activity in the pull request [1] or issue [2] [1] https://github.com/keycloak/keycloak/pull/2617 [2] https://issues.jboss.org/browse/KEYCLOAK-2753 Thanks, -- Iv?n _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user From josh.cain at redhat.com Wed May 11 09:50:43 2016 From: josh.cain at redhat.com (Josh Cain) Date: Wed, 11 May 2016 08:50:43 -0500 Subject: [keycloak-user] Validating JWT tokens In-Reply-To: References: <1462377616.1947384.598056425.5C00B82A@webmail.messagingengine.com> <1462379847.1956071.598104761.4A24EAC6@webmail.messagingengine.com> <4AC8C602867B3A4CB6F9F6BA4528DEE477CD682C@WPHXMAIL1.phx.axway.int> Message-ID: I recently put together a quick test for this as well using jjwt: https://github.com/cainj13/jwtExamples/blob/master/src/test/java/jcain/example/TokenParseTest.java Pretty similar to the gist that Thomas mentioned above. Josh Cain | Software Applications Engineer *Identity and Access Management* *Red Hat* +1 843-737-1735 On Wed, May 11, 2016 at 4:09 AM, Thomas Darimont < thomas.darimont at googlemail.com> wrote: > Hello, > > another example for (Parsing) & Validating a Keycloak JWT was posted on > the ML a few months ago: > http://lists.jboss.org/pipermail/keycloak-user/2016-March/005325.html > > In the example the token is only successfully parsed when the token is > valid. > > Cheers, > Thomas > > 2016-05-11 10:45 GMT+02:00 Gerard Laissard : > >> >> >> My 2 cents: >> >> There is an openSSL example to verify a jwt: >> >> https://gist.github.com/rolandyoung/176dd310a6948e094be6 >> >> >> >> By using jose4j >> >> // be sure you do not have any EOL at the end of the token >> >> String accesToken = ?; >> >> accesToken = accesToken.replaceAll("\r\n", ""); >> >> accesToken = accesToken.replaceAll("\n", ""); >> >> >> >> JsonWebSignature jws = *new* JsonWebSignature(); >> >> jws.setCompactSerialization(accesToken); >> >> jws.setKey(publicKey); >> >> boolean signatureVerified = jws.verifySignature(); >> >> To get a PublicKey : if you put the content of the realm public you get >> from keycloak admin >> >> *public* PublicKey getPublicKey(String fileName) { >> >> File f = *new* File(fileName); >> >> *try* (FileInputStream fis = *new* FileInputStream(f); >> >> DataInputStream dis = *new* DataInputStream(fis);) { >> >> *byte*[] keyBytes = *new* *byte*[(*int*) f.length()]; >> >> dis.readFully(keyBytes); >> >> dis.close(); >> >> // convert to der format >> >> String pem = new String(keyBytes); >> >> pem = pem.replaceAll("-----BEGIN (.*)-----", ""); >> >> pem = pem.replaceAll("-----END (.*)----", ""); >> >> pem = pem.replaceAll("\r\n", ""); >> >> pem = pem.replaceAll("\n", ""); >> >> byte[] der = Base64.getDecoder().decode(pem); // java 8 >> >> X509EncodedKeySpec spec = *new* X509EncodedKeySpec(der); >> >> KeyFactory kf = KeyFactory.*getInstance*(*RSA*); >> >> *return* kf.generatePublic(spec); >> >> >> >> } *catch* (IOException | InvalidKeySpecException | >> NoSuchAlgorithmException e) { >> >> *throw* *new* RuntimeException("Failed to load public >> key from file '" + fileName + "'", e); >> >> } >> >> } >> >> >> >> With Java 8, it is quite simple too >> >> String[] tokenParts = accessToken.split("\\."); >> >> // detect algo from tokenParts[0] or put "SHA256withRSA? (for ?RS256?) >> >> String jwtSignAlgo = "SHA256withRSA"; >> >> String jwtInputString = tokenParts[0] + ?.? + tokenParts[1]; >> >> String jwtDecodedSign = new >> String(Base64.getUrlDecoder().decode(tokenParts[2]); >> >> Signature verifier = Signature.getInstance(jwtSignAlgo); >> >> verifier.initVerify(publicKey); >> >> verifier.update(jwtInputString.getBytes("UTF-8")); >> >> boolean signatureVerified = verifier.verify(jwtDecodedSign); >> >> >> >> >> >> gerard >> >> >> >> >> >> *From:* keycloak-user-bounces at lists.jboss.org [mailto: >> keycloak-user-bounces at lists.jboss.org] *On Behalf Of *Stian Thorgersen >> *Sent:* vendredi 6 mai 2016 07:33 >> *To:* Aikeaguinea >> *Cc:* keycloak-user >> *Subject:* Re: [keycloak-user] Validating JWT tokens >> >> >> >> >> >> >> >> On 4 May 2016 at 18:37, Aikeaguinea wrote: >> >> Figured it out, kinda. I have to use the Realm public key, and at least >> in jwt.io it has to begin with "-----BEGIN PUBLIC KEY-----" and end with >> "-----END PUBLIC KEY-----" -- these can't be omitted. >> >> If I try using the Realm certificate, it won't work, however, whether or >> not I use "-----BEGIN CERTIFICATE-----"/"-----END CERTIFICATE-----". >> >> If I use the validator at http://kjur.github.io/jsjws/tool_jwt.html and >> select "default X509 Certificate (RSA z4) it tells me "Error: malformed >> X.509 certificate PEM (code:003)" >> >> I can use the Realm public key for validating the JWT, but shouldn't the >> certificate work as well? >> >> >> >> The certificate is only used by SAML, so no you can't verify the JWT with >> the certificate only the public key. >> >> >> >> >> On Wed, May 4, 2016, at 12:00 PM, Aikeaguinea wrote: >> > I have a client with a service account and credentials using Signed Jwt. >> > Authentication works fine. The service uses >> > >> org.keycloak.adapters.authentication.ClientCredentialsProviderUtils#setClientCredentials >> > to create the JWT token and set the headers, and I get back a JWT >> > containing an access token from Keycloak. >> > >> > However, when I use jwt.io to look at the access token, I can't >> validate >> > the signature. This is true whether I use the client Certificate (from >> > the client's Credentials tab), the Realm public key, or the Realm >> > Certificate. In addition, I have generated the client's public key from >> > the certificate using >> > >> > keytool -exportcert -alias x -keypass y -storepass z -rfc -keystore >> > client-keystore.jks | openssl x509 -inform pem -pubkey >> > >> > on the jks file supplied when I generated the client credentials, and >> > that doesn't work either. >> > >> > We've also been having trouble validating the signature programmatically >> > using Java. >> > >> > Any idea why I might be seeing this? >> > >> > -- >> > http://www.fastmail.com - Or how I learned to stop worrying and >> > love email again >> > >> >> >> -- >> Aikeaguinea >> aikeaguinea at xsmail.com >> >> -- >> http://www.fastmail.com - Send your email first class >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160511/ba631767/attachment-0001.html From g.orciuch at gmail.com Wed May 11 10:35:42 2016 From: g.orciuch at gmail.com (Gregory Orciuch) Date: Wed, 11 May 2016 16:35:42 +0200 Subject: [keycloak-user] AJAX(xhr) calls Message-ID: Hi, we do protect our app with the KeyCloak wildfly adapter. Generally it's jee app + JSF (primefaces). The case is, when SSO session is expired, the user on the webpage can still try to make AJAX call to JSF application. In same time, adapter intercepts and wants the request to go to keycloack page for redirection to relogin (http 302). >From what I read, ajax does not well support the 302 response and in order to make browser to really redirect response should contain an XML with something like Is there a way to make KeyCloak aware of AJAX calls ? and not produce 302 ? I could even contribute and write some code in order to support such configuration. Just name the class where I should look for. Cheers, Gregory -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160511/d90a4a66/attachment.html From guus.der.kinderen at gmail.com Wed May 11 10:46:09 2016 From: guus.der.kinderen at gmail.com (Guus der Kinderen) Date: Wed, 11 May 2016 16:46:09 +0200 Subject: [keycloak-user] Unique username across realms? Message-ID: Hi all, Is it possible to have multiple realms, in which every username is unique across all of the realms? Regards, Guus -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160511/edebc930/attachment.html From daniele.bonetto at dnshosting.it Wed May 11 10:50:01 2016 From: daniele.bonetto at dnshosting.it (Daniele Bonetto) Date: Wed, 11 May 2016 16:50:01 +0200 Subject: [keycloak-user] Impersonate Message-ID: Hi all, i've a question about impersonation. As wrote before, we need to allow our operators to impersonate final users. We need call impersonate API from our backoffice. I searched in keycloak.js some function that does the magic, but nothing. How can we manage it? We didn't want that our operators have to access to keycloak admin-interface to impersonate users. Thanks in advance, regards. Daniele Bonetto From tech at psynd.net Wed May 11 11:08:40 2016 From: tech at psynd.net (Tech @ PSYND) Date: Wed, 11 May 2016 17:08:40 +0200 Subject: [keycloak-user] CUstom authentication flow In-Reply-To: <5732DFBA.7010508@redhat.com> References: <96373974ef3ec2de43c949bfbc020f1b@psynd.net> <5732DFBA.7010508@redhat.com> Message-ID: <4d6b051ae01d66b6e46cef4d39c0610b@psynd.net> I was not able to fix this problem, but I exported the configuration, I reinstalled the product, repeated all the steps and it was finally working. On 2016-05-11 09:31, Marek Posolda wrote: > Maybe if you copy just to "keycloak/themes/base/login", but not to > "keycloak/themes/keycloak/login" ? Besides that, the error is > different then in the JIRA you linked. You have "Failed to process > template" . Didn't you any changes in the > security-question-config.ftl? Adding whole stacktrace might be better > though... > > Marek > > > > On 10/05/16 15:51, Tech @ PSYND wrote: >> Dear experts, >> >> I'm working with version 1.9.4 of the product, I'm developing a couple >> of custom forms that should be integrated into an authentication >> workflow. >> >> Following the example integrated into the product: >> 1) I compiled the "org.keycloak.examples.authenticator" >> 2) I copied the "secret'question.ftl" and "secret'question'config.ftl" >> files into the keycloak/themes/keycloak/login and >> keycloak/themes/base/login >> 3) I moved the generated jar file >> "authenticator-required-action-example.jar" into keycloak/providers >> 4) I opened the admin console, I create a new flow consisting of >> "Username and passowrd" and "Secret-question". >> >> I try to login with a user and the error message that I get is: >> >> 15:36:26,319 ERROR >> [org.keycloak.forms.login.freemarker.FreeMarkerLoginFormsProvider] >> (default task-15) Failed to process template: >> org.keycloak.theme.FreeMarkerException: Failed to process template >> secret-question-config.ftl >> >> That is compatible with what I found here: >> https://issues.jboss.org/browse/KEYCLOAK-2534 >> >> But I copied the files in the correct position: what else could cause >> such error? >> >> Thanks >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user From tech at psynd.net Wed May 11 11:11:01 2016 From: tech at psynd.net (Tech @ PSYND) Date: Wed, 11 May 2016 17:11:01 +0200 Subject: [keycloak-user] From UserFederation to Authenticator info flow Message-ID: <55154055fa1bb4c784ae9b353dabe58e@psynd.net> Dear experts, we are getting information through a UserFederation class, and we need to use the information collected for an Authenticator. What should we do pass the data from a UserFederation to the Authenticator? From bruno at abstractj.org Wed May 11 11:16:24 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 11 May 2016 12:16:24 -0300 Subject: [keycloak-user] keycloak-nodejs-connect connection issues In-Reply-To: References: Message-ID: <20160511151624.GA5652@abstractj.org> Hi Elston, I'm including the keycloak-user mailing list. If you haven't subscribed yet, please do it for further questions. Have you tried to run the examples from here[1]? How your realm JSON file looks like? [1] - https://github.com/keycloak/keycloak-nodejs-connect/tree/master/example On 2016-05-05, Elston Baretto wrote: > Hi Bruno > > I've been banging my head against a brick wall for while now and wondering > if you can rescue me since you're a contributor. > > I currently have a loopback app that I'm trying to protect with Keycloak > and my server/boot/root.js contains: > > module.exports = function (server) { > var session = require('express-session'); > var Keycloak = require('keycloak-connect'); > > var keycloak = new Keycloak(); > var memoryStore = new session.MemoryStore(); > > server.use(session({ > secret: '3249d976-7c6c-481d-83e6-c8012904f00a', > resave: false, > saveUninitialized: true, > store: memoryStore, > })) > > var keycloak = new Keycloak({ > store: memoryStore > }); > > server.use(keycloak.middleware({})); > > server.get('/*', keycloak.protect(), function (req, resp) { > resp.send('hello'); > }) > > }; > > I've tried to follow the example as closely as possible but when I hit any > API I get into a redirect loop and the request fails. > > I've also tried swapping the server.use(session line with > server.use(keycloak but then see: > > Cannot read property 'keycloak-token' of undefined > > Is there something I'm doing wrong? > > Thanks in advance! > > Cheers, > Elston -- abstractj PGP: 0x84DC9914 From thomas.darimont at googlemail.com Wed May 11 11:28:09 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Wed, 11 May 2016 17:28:09 +0200 Subject: [keycloak-user] AJAX(xhr) calls In-Reply-To: References: Message-ID: Hi Gregory, have a look at this: https://issues.jboss.org/browse/KEYCLOAK-2962?jql=project%20%3D%20KEYCLOAK%20AND%20text%20~%20JSF Cheers, Thomas 2016-05-11 16:35 GMT+02:00 Gregory Orciuch : > Hi, > > we do protect our app with the KeyCloak wildfly adapter. Generally it's > jee app + JSF (primefaces). > > The case is, when SSO session is expired, the user on the webpage can > still try to make AJAX call to JSF application. In same time, adapter > intercepts and wants the request to go to keycloack page for redirection to > relogin (http 302). > > From what I read, ajax does not well support the 302 response and in order > to make browser to really redirect response should contain an XML with > something like > > > > > > > Is there a way to make KeyCloak aware of AJAX calls ? and not produce 302 ? > I could even contribute and write some code in order to support such > configuration. Just name the class where I should look for. > > Cheers, > Gregory > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160511/c58f15f5/attachment.html From ton at finalist.nl Wed May 11 11:43:15 2016 From: ton at finalist.nl (Ton Swieb) Date: Wed, 11 May 2016 17:43:15 +0200 Subject: [keycloak-user] Keycloak in production. Use MongoDB or an RDBMS flavour? In-Reply-To: <5732E301.5040108@redhat.com> References: <5732E301.5040108@redhat.com> Message-ID: Hi Marek, Thank you for your answer. So if I understand you correctly there are no plans to drop Mongo support in the near feature. Good to know. How many (concurrent) users did you need to use to see a performance difference between Mongo and MySQL? I assume the lack of transaction support in Mongo only becomes an issue with multi row/document transactions. Are multi row/document transactions used commonly in the Keycloak application or are most transactions limited to a single row/document? Regards, Ton 2016-05-11 9:45 GMT+02:00 Marek Posolda : > On 10/05/16 14:18, Ton Swieb wrote: >> >> Hi, >> >> I understand from the Keycloak documentation that both MongoDB and >> multiple flavours of RDBMS are supported, but I cannot find any >> recommendation whether to use MongoDB or an RDBMS by default. >> >> Which one is best suited for the Keycloak product? >> I am anticipating a user base of around 10000 users (mainly via >> Identity Brokering), will use offline tokens and use Keycloak as an >> Identity Broker for a SAML IdP. I am starting from a green field >> situation and do not have any restrictions on using a specific DB. >> >> I found a comment of Bill Birke on the Keycloak developer >> mailing-list, >> http://lists.jboss.org/pipermail/keycloak-dev/2015-July/004924.html, >> wishing he could drop Mongo and not seeing any advantages of using >> Mongo, but unfortunately the thread does not end with a >> conclusion/decision :-) >> >> What is the current position of the Keycloak team about using Mongo? > > We added Mongo support very early (somewhen around 2013) as an alternative > storage, which was at that time required by other project, which consumed > keycloak. The second project (Liveoak) is not under active development > anymore, but in the meantime, a lot of people started to use Keycloak with > Mongo and it seems that some of them already in production. > > The advantage of Mongo is good performance and scalability. At some point, > when I tested performance with bigger number of users, I saw much better > performance for Mongo then for MySQL. Also Mongo has support for DB > clustering and sharding (some RDBMS has it too AFAIK, but usually you need > to pay for them, which is not the case with Mongo ;)) . On the other hand, > biggest disadvantage of Mongo is missing support for transactions. So in > theory, if some error/bad situation happens, you can theoretically end with > partially inconsistent data in DB. > > Marek >> >> >> In which scenario should I consider using MongoDB over an RDBMS or >> vice versa? There are off course the usual pro/con's between NoSQL and >> RDBMS, but I would like to know to what extend they hold true when it >> comes to using Keycloak in production or whether Keycloak is optimized >> specifically for NoSQL or RDBMS. >> >> Regards, >> >> Ton >> > -- From emanuel.amaral.couto at gmail.com Wed May 11 13:14:48 2016 From: emanuel.amaral.couto at gmail.com (Emanuel Couto) Date: Wed, 11 May 2016 17:14:48 +0000 Subject: [keycloak-user] Change user attributes using the user account Message-ID: Hello Is it possible for a user to change its attributes after he is logged in? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160511/a2031a0b/attachment.html From emanuel.amaral.couto at gmail.com Wed May 11 13:23:17 2016 From: emanuel.amaral.couto at gmail.com (Emanuel Couto) Date: Wed, 11 May 2016 17:23:17 +0000 Subject: [keycloak-user] DSA_SHA1 error In-Reply-To: References: Message-ID: Hello Does this error have anything to do with not having a private key in the Realm? When I go to "Realm Settings -> Keys" the private key input is empty. I'm not sure if the page is simply not showing the private key or if it doesn't exist. If it does not exist, how to I generate a a keypair and input it manually? I switched to the 'saml-broker-authentication' demo to have a more controlled environment. With every other signature algorithm (e.g., RSA_SHA1) everything just works. On Tue, May 3, 2016 at 5:07 PM Emanuel Couto wrote: > The signature algorithm is DSA_SHA1. > > Note: Sorry, didn't reply all. > > On Tue, May 3, 2016 at 5:02 PM Bill Burke wrote: > >> What signature algorithm is configured? >> >> On 5/3/2016 10:59 AM, Emanuel Couto wrote: >> >> I'm getting the following error when trying to connect to a SAML 2.0 >> identity provider: >> >> 15:57:50,387 ERROR [org.keycloak.services] (default task-27) >> couldNotSendAuthenticationRequestMessage: >> org.keycloak.broker.provider.IdentityBrokerException: Could not create >> authentication request. >> at >> org.keycloak.broker.saml.SAMLIdentityProvider.performLogin(SAMLIdentityProvider.java:124) >> at >> org.keycloak.services.resources.IdentityBrokerService.performLogin(IdentityBrokerService.java:157) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:497) >> at >> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) >> at >> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) >> at >> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) >> at >> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) >> at >> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) >> at >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) >> at >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) >> at >> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) >> at >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) >> at >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >> at >> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) >> at >> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) >> at >> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:88) >> at >> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) >> at >> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) >> at >> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) >> at >> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) >> at >> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) >> at >> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at >> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) >> at >> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at >> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) >> at >> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) >> at >> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) >> at >> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) >> at >> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) >> at >> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at >> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at >> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) >> at >> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) >> at >> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) >> at >> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) >> at >> io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) >> at >> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:745) >> Caused by: org.keycloak.saml.common.exceptions.ProcessingException: >> javax.xml.crypto.dsig.XMLSignatureException: PL00100: Signing Process >> Failure: >> at >> org.keycloak.saml.processing.api.saml.v2.sig.SAML2Signature.signSAMLDocument(SAML2Signature.java:162) >> at >> org.keycloak.saml.BaseSAML2BindingBuilder.signDocument(BaseSAML2BindingBuilder.java:266) >> at >> org.keycloak.saml.BaseSAML2BindingBuilder$BasePostBindingBuilder.(BaseSAML2BindingBuilder.java:145) >> at >> org.keycloak.protocol.saml.JaxrsSAML2BindingBuilder$PostBindingBuilder.(JaxrsSAML2BindingBuilder.java:38) >> at >> org.keycloak.protocol.saml.JaxrsSAML2BindingBuilder.postBinding(JaxrsSAML2BindingBuilder.java:87) >> at >> org.keycloak.broker.saml.SAMLIdentityProvider.performLogin(SAMLIdentityProvider.java:119) >> ... 48 more >> Caused by: javax.xml.crypto.dsig.XMLSignatureException: PL00100: Signing >> Process Failure: >> at >> org.keycloak.saml.common.DefaultPicketLinkLogger.signatureError(DefaultPicketLinkLogger.java:184) >> ... 54 more >> Caused by: javax.xml.crypto.dsig.XMLSignatureException: >> java.security.InvalidKeyException: can't identify DSA private key. >> at >> org.apache.jcp.xml.dsig.internal.dom.DOMXMLSignature.sign(DOMXMLSignature.java:403) >> at >> org.keycloak.saml.processing.core.util.XMLSignatureUtil.signImpl(XMLSignatureUtil.java:624) >> at >> org.keycloak.saml.processing.core.util.XMLSignatureUtil.sign(XMLSignatureUtil.java:347) >> at >> org.keycloak.saml.processing.api.saml.v2.sig.SAML2Signature.sign(SAML2Signature.java:143) >> at >> org.keycloak.saml.processing.api.saml.v2.sig.SAML2Signature.signSAMLDocument(SAML2Signature.java:160) >> ... 53 more >> Caused by: java.security.InvalidKeyException: can't identify DSA private >> key. >> at >> org.bouncycastle.jcajce.provider.asymmetric.dsa.DSAUtil.generatePrivateKeyParameter(Unknown >> Source) >> at >> org.bouncycastle.jcajce.provider.asymmetric.dsa.DSASigner.engineInitSign(Unknown >> Source) >> at java.security.Signature$Delegate.init(Signature.java:1152) >> at >> java.security.Signature$Delegate.chooseProvider(Signature.java:1112) >> at >> java.security.Signature$Delegate.engineInitSign(Signature.java:1176) >> at java.security.Signature.initSign(Signature.java:527) >> at >> org.apache.jcp.xml.dsig.internal.dom.DOMSignatureMethod.sign(DOMSignatureMethod.java:267) >> at >> org.apache.jcp.xml.dsig.internal.dom.DOMXMLSignature.sign(DOMXMLSignature.java:399) >> ... 57 more >> >> I don't understand this error. >> >> >> _______________________________________________ >> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user >> >> >> -- >> Bill Burke >> JBoss, a division of Red Hathttp://bill.burkecentral.com >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160511/48b4d2eb/attachment-0001.html From josh.cain at redhat.com Wed May 11 13:31:07 2016 From: josh.cain at redhat.com (Josh Cain) Date: Wed, 11 May 2016 12:31:07 -0500 Subject: [keycloak-user] XXE Switches warning Message-ID: Hi all, I'm running Keycloak 1.9.3.Final with the standard out-of-the-box Wildfly configuration in a test environment, and I noticed this warning: WARN [org.keycloak.saml.common] XML External Entity switches are not supported. You may get XML injection vulnerabilities. I was curious as to what might be vulnerable, so I sent some malicious XML payloads with XXE type attacks to the SAML endpoint, and got this message: ERROR [org.keycloak.saml.common] Error in base64 decoding saml message: ParsingException [location=null]or g.keycloak.saml.common.exceptions.ParsingException: PL00074: Parsing Error:DOCTYPE is disallowed when the feature "http://apache.org/xml /features/disallow-doctype-decl" set to true. I can see clearly where the DocumentUtil is setting the flag mentioned in this error message (as well as a couple of others). Based on this, is it safe to assume that XXE attacks are protected against by the KC SAML processing operations? Also, are there other endpoints or operations that don't use the DocumentUtil that I should be concerned with? If so, what are the recommended actions to ensure the TransformerFactory settings are appropriate? Josh Cain | Software Applications Engineer *Identity and Access Management* *Red Hat* +1 843-737-1735 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160511/c2197d47/attachment.html From rllavallee at hotmail.com Wed May 11 14:55:49 2016 From: rllavallee at hotmail.com (Richard Lavallee) Date: Wed, 11 May 2016 18:55:49 +0000 Subject: [keycloak-user] Production hosting requirements for Keycloak Message-ID: Where can I find a list of minimum production requirements for hosting keycloak instance(s) for CentOS 7 and Microsoft Windows? E.g. Number of CPUs, appserver, database requirement, RAM, Disk space. Thanks -Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160511/4e47d30b/attachment.html From scott at xigole.com Wed May 11 15:09:40 2016 From: scott at xigole.com (Scott Dunbar) Date: Wed, 11 May 2016 13:09:40 -0600 Subject: [keycloak-user] Production hosting requirements for Keycloak In-Reply-To: References: Message-ID: I'm hardly a KeyCloak expert but I can say that "it depends". How many users? How active is each user? How many calls/second do you expect to, for example, get an Oauth token? The list goes on. For development purposes I've hosted a KeyCloak server, with a PostgreSQL database server, on an Amazon t2.small instance (2GB memory, single core CPU). No, it wasn't the fastest in the world but it did work for the development testing I needed. I think you need to define the usage first. After that people who are far more experienced than I am can give you directional information but hard and fast rules will still be tough. Just my $0.02 worth. On Wed, May 11, 2016 at 12:55 PM, Richard Lavallee wrote: > Where can I find a list of minimum production requirements for hosting > keycloak instance(s) for CentOS 7 and Microsoft Windows? > > E.g. Number of CPUs, appserver, database requirement, RAM, Disk space. > > Thanks > > -Richard > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Scott Dunbar Cell: 303 667 6343 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160511/88bcbffd/attachment.html From bburke at redhat.com Wed May 11 15:19:35 2016 From: bburke at redhat.com (Bill Burke) Date: Wed, 11 May 2016 15:19:35 -0400 Subject: [keycloak-user] XXE Switches warning In-Reply-To: References: Message-ID: <21db145a-ccb0-5b46-1758-8f99061b29e1@redhat.com> Ugh, I forgot the specific around that warning message. I think JDK 8 doesn't support some of the XXE flags or something, or, earlier versions of the JDK don't support them. I forget. On 5/11/16 1:31 PM, Josh Cain wrote: > Hi all, > > I'm running Keycloak 1.9.3.Final with the standard out-of-the-box > Wildfly configuration in a test environment, and I noticed this warning: > > WARN [org.keycloak.saml.common] XML External Entity switches are not > supported. You may get XML injection vulnerabilities. > > I was curious as to what might be vulnerable, so I sent some malicious > XML payloads with XXE type attacks to the SAML endpoint, and got this > message: > > ERROR [org.keycloak.saml.common] Error in base64 decoding saml > message: ParsingException [location=null]or > g.keycloak.saml.common.exceptions.ParsingException: PL00074: Parsing > Error:DOCTYPE is disallowed when the feature "http://apache.org/xml > /features/disallow-doctype-decl" set to true. > > I can see clearly where the DocumentUtil is setting the flag mentioned > in this error message (as well as a couple of others). Based on this, > is it safe to assume that XXE attacks are protected against by the KC > SAML processing operations? > > Also, are there other endpoints or operations that don't use the > DocumentUtil that I should be concerned with? If so, what are the > recommended actions to ensure the TransformerFactory settings are > appropriate? > > Josh Cain | Software Applications Engineer > /Identity and Access Management/ > *Red Hat* > +1 843-737-1735 > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160511/4747b294/attachment.html From bcook at redhat.com Wed May 11 16:36:27 2016 From: bcook at redhat.com (Brian Cook) Date: Wed, 11 May 2016 14:36:27 -0600 Subject: [keycloak-user] custom role description not showing up on consent screen Message-ID: I created a new role at the client level and in my link to start the openid connect authorization code flow it is being pased in. I get the login screen and login successfully, but when the consent screen shows up there is no mention of this scope or its description. Is there something additional I need to do? Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160511/00bd3e54/attachment.html From anshulm at stytch.com Wed May 11 18:29:18 2016 From: anshulm at stytch.com (Anshul Malpani) Date: Wed, 11 May 2016 15:29:18 -0700 Subject: [keycloak-user] Keycloak impersonate programmatically Message-ID: <4E607652-258B-4527-A07F-FB87114F703B@dnbcloud.com> Hi, I am trying to use impersonate feature using my java client. When I call impersonate api using admin access grant. I get back the cookies. How can I get the access token for the impersonate user. HttpPost post = new HttpPost( KeycloakUriBuilder.fromUri(authServerUrl).path(?/admin/realms/{realm}/users/{id}/impersonation").build(realm, accountKeycloakId)); This is returning me cookies. In next step I would like to get the access token of impersonate user. Thanks A -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160511/0b27b90b/attachment-0001.html From sthorger at redhat.com Thu May 12 01:34:55 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 12 May 2016 07:34:55 +0200 Subject: [keycloak-user] Keycloak in production. Use MongoDB or an RDBMS flavour? In-Reply-To: References: <5732E301.5040108@redhat.com> Message-ID: One thing to add is that Mongo is not going to be supported in productized version of Keycloak. At least not initially. On 11 May 2016 at 17:43, Ton Swieb wrote: > Hi Marek, > > Thank you for your answer. So if I understand you correctly there are > no plans to drop Mongo support in the near feature. Good to know. > > How many (concurrent) users did you need to use to see a performance > difference between Mongo and MySQL? > > I assume the lack of transaction support in Mongo only becomes an > issue with multi row/document transactions. Are multi row/document > transactions used commonly in the Keycloak application or are most > transactions limited to a single row/document? > > Regards, Ton > > 2016-05-11 9:45 GMT+02:00 Marek Posolda : > > On 10/05/16 14:18, Ton Swieb wrote: > >> > >> Hi, > >> > >> I understand from the Keycloak documentation that both MongoDB and > >> multiple flavours of RDBMS are supported, but I cannot find any > >> recommendation whether to use MongoDB or an RDBMS by default. > >> > >> Which one is best suited for the Keycloak product? > >> I am anticipating a user base of around 10000 users (mainly via > >> Identity Brokering), will use offline tokens and use Keycloak as an > >> Identity Broker for a SAML IdP. I am starting from a green field > >> situation and do not have any restrictions on using a specific DB. > >> > >> I found a comment of Bill Birke on the Keycloak developer > >> mailing-list, > >> http://lists.jboss.org/pipermail/keycloak-dev/2015-July/004924.html, > >> wishing he could drop Mongo and not seeing any advantages of using > >> Mongo, but unfortunately the thread does not end with a > >> conclusion/decision :-) > >> > >> What is the current position of the Keycloak team about using Mongo? > > > > We added Mongo support very early (somewhen around 2013) as an > alternative > > storage, which was at that time required by other project, which consumed > > keycloak. The second project (Liveoak) is not under active development > > anymore, but in the meantime, a lot of people started to use Keycloak > with > > Mongo and it seems that some of them already in production. > > > > The advantage of Mongo is good performance and scalability. At some > point, > > when I tested performance with bigger number of users, I saw much better > > performance for Mongo then for MySQL. Also Mongo has support for DB > > clustering and sharding (some RDBMS has it too AFAIK, but usually you > need > > to pay for them, which is not the case with Mongo ;)) . On the other > hand, > > biggest disadvantage of Mongo is missing support for transactions. So in > > theory, if some error/bad situation happens, you can theoretically end > with > > partially inconsistent data in DB. > > > > Marek > >> > >> > >> In which scenario should I consider using MongoDB over an RDBMS or > >> vice versa? There are off course the usual pro/con's between NoSQL and > >> RDBMS, but I would like to know to what extend they hold true when it > >> comes to using Keycloak in production or whether Keycloak is optimized > >> specifically for NoSQL or RDBMS. > >> > >> Regards, > >> > >> Ton > >> > > > > -- > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160512/16b0c9ea/attachment.html From mposolda at redhat.com Thu May 12 02:43:48 2016 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 12 May 2016 08:43:48 +0200 Subject: [keycloak-user] Keycloak in production. Use MongoDB or an RDBMS flavour? In-Reply-To: References: <5732E301.5040108@redhat.com> Message-ID: <57342624.3050307@redhat.com> On 11/05/16 17:43, Ton Swieb wrote: > Hi Marek, > > Thank you for your answer. So if I understand you correctly there are > no plans to drop Mongo support in the near feature. Good to know. AFAIK we will keep mongo as many people are using that. But I am not in position to promise anything related this :-) > > How many (concurrent) users did you need to use to see a performance > difference between Mongo and MySQL? Depends on test scenario. For example if you have test for concurrent login/logout of same set of users, then you might not see so big difference. That's because keycloak has caching layer, so once user (or other object) is read from DB for first time, then it's cached and next reads of same user read this user from cache instead of from DB. So performance of DB is not so visible here due to huge amount of caching. The difference might be more visible if you do some write operations (like creating or deleting users). For example test for write/deleting of users. I've just tried to run performance for create and delete 10000 users. The results: MySQL: 8:08:47,096 INFO Operation 'create 10000 users' average: 227756 ms 08:08:47,096 INFO Operation 'delete 10000 users' average: 110315 ms Mongo: 08:14:57,957 INFO Operation 'create 10000 users' average: 157432 ms 08:14:57,958 INFO Operation 'delete 10000 users' average: 49908 ms You can see that difference is not so big. That's because in 1.9 release, we did lot of tuning for RDBMS model and we added some DB indexes to tune performance. However for Mongo, we did not yet do this tuning.Once we do that, the difference will be likely bigger. You can see here the indexes we did for RDBMS for inspiration if you want to tune your mongo: https://github.com/keycloak/keycloak/blob/master/model/jpa/src/main/resources/META-INF/jpa-changelog-1.9.0.xml#L78-80 https://github.com/keycloak/keycloak/blob/master/model/jpa/src/main/resources/META-INF/jpa-changelog-1.9.2.xml#L22-59 If you want to try the performance test, you can do this (with MySQL, assuming you have DB "keycloak" on localhost:3306 and user "keycloak" with password "keycloak"): cd $KEYCLOAK_SOURCES mvn clean install -DskipTests=true cd testsuite/integration-arquillian/tests/other/jpa-performance mvn clean install -Dkeycloak.connectionsJpa.url=jdbc:mysql://localhost/keycloak -Dkeycloak.connectionsJpa.driver=com.mysql.jdbc.Driver -Dkeycloak.connectionsJpa.user=keycloak -Dkeycloak.connectionsJpa.password=keycloak -Dmany.users.read.after.create=true -Dmany.users.create.objects=true with mongo, you can run the same test with last command like this (assuming mongo running on localhost, test will use DB "keycloak-perf" ): mvn clean install -Dkeycloak.realm.provider=mongo -Dkeycloak.user.provider=mongo -Dkeycloak.userSessionPersister.provider=mongo -Dkeycloak.eventsStore.provider=mongo -Dkeycloak.connectionsMongo.db=keycloak-perf -Dmany.users.read.after.create=true -Dmany.users.create.objects=true See the files for more available properties: https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/other/jpa-performance/README.md https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/resources/META-INF/keycloak-server.json > > I assume the lack of transaction support in Mongo only becomes an > issue with multi row/document transactions. Are multi row/document > transactions used commonly in the Keycloak application or are most > transactions limited to a single row/document? No, most of operations in admin console usually create/update just single object. Same if user updates his profile in account management or new user registers, it's just single user row involved. There are some exceptions for this - for example if you create new realm or import realm, there are transactions under many different objects in different collection. But creating or importing realm is usually very rare operation. Marek > > Regards, Ton > > 2016-05-11 9:45 GMT+02:00 Marek Posolda : >> On 10/05/16 14:18, Ton Swieb wrote: >>> Hi, >>> >>> I understand from the Keycloak documentation that both MongoDB and >>> multiple flavours of RDBMS are supported, but I cannot find any >>> recommendation whether to use MongoDB or an RDBMS by default. >>> >>> Which one is best suited for the Keycloak product? >>> I am anticipating a user base of around 10000 users (mainly via >>> Identity Brokering), will use offline tokens and use Keycloak as an >>> Identity Broker for a SAML IdP. I am starting from a green field >>> situation and do not have any restrictions on using a specific DB. >>> >>> I found a comment of Bill Birke on the Keycloak developer >>> mailing-list, >>> http://lists.jboss.org/pipermail/keycloak-dev/2015-July/004924.html, >>> wishing he could drop Mongo and not seeing any advantages of using >>> Mongo, but unfortunately the thread does not end with a >>> conclusion/decision :-) >>> >>> What is the current position of the Keycloak team about using Mongo? >> We added Mongo support very early (somewhen around 2013) as an alternative >> storage, which was at that time required by other project, which consumed >> keycloak. The second project (Liveoak) is not under active development >> anymore, but in the meantime, a lot of people started to use Keycloak with >> Mongo and it seems that some of them already in production. >> >> The advantage of Mongo is good performance and scalability. At some point, >> when I tested performance with bigger number of users, I saw much better >> performance for Mongo then for MySQL. Also Mongo has support for DB >> clustering and sharding (some RDBMS has it too AFAIK, but usually you need >> to pay for them, which is not the case with Mongo ;)) . On the other hand, >> biggest disadvantage of Mongo is missing support for transactions. So in >> theory, if some error/bad situation happens, you can theoretically end with >> partially inconsistent data in DB. >> >> Marek >>> >>> In which scenario should I consider using MongoDB over an RDBMS or >>> vice versa? There are off course the usual pro/con's between NoSQL and >>> RDBMS, but I would like to know to what extend they hold true when it >>> comes to using Keycloak in production or whether Keycloak is optimized >>> specifically for NoSQL or RDBMS. >>> >>> Regards, >>> >>> Ton >>> From eduard.matuszak at atos.net Thu May 12 04:29:57 2016 From: eduard.matuszak at atos.net (Matuszak, Eduard) Date: Thu, 12 May 2016 08:29:57 +0000 Subject: [keycloak-user] Keycloak as ID provider for large amount of devices Message-ID: <61D077C6283D454FAFD06F6AC4AB74D723DD53F4@DEFTHW99EZ1MSX.ww931.my-it-solutions.net> Hello We are planning to get a lot of devices, identifyable by individual certificates, into an IOT-system being designed and developed at the moment. We choosed to authenticate all actors (users, software components and devices as well) by OIDC-tokens and (pre)decided to use Keycloak as ID provider. User and software components are quite straightforward to handle with Keycloak (as Keycloak users with the help of a user federation provider & id brokerage and for applications as Keycloak clients respectively). But I am not sure of how to represent our devices (we want to support hundreds of thousands of them later on!) by Keycloak means. It seems that we essentially have 2 possiblities to register a device in Keycloak - As a user - As a client By representing devices as Keycloak clients we might take advantage of the ServiceAccount (Oauth-Client Credential) flow and become able to implement it via (dynamic!) registration and it and seems, that we will even be able to authenticate our device by their certificates by choosing "Signed Jwt" as authenticator option. My question is, if it would be a good idea to register a very big amount of devices as Keycloak clients with regards to performance and manageability. In principle I would prefer a user-representation (faciliting usage of user federation provider & id brokerage for instance), but as far as I understood, the appropriate flow would be Direct Access (ResourceOwnerPassword Credentials) and here we can only deal with username/password instead of certificates. Do you have any suggestions or hints (even the conclusion, that Keycloak is not the suitable ID-provider-implementation for large-scale IOT-systems)? Best regards, Eduard Matuszak -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160512/a81e9d01/attachment.html From thomas.darimont at googlemail.com Thu May 12 04:45:41 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Thu, 12 May 2016 10:45:41 +0200 Subject: [keycloak-user] Needs review: Proposed fixes to the german translations of login pages in Keycloak base theme Message-ID: Hello group, I reworded some translations and fixed some spelling errors in the german translations of the login pages in the base theme: https://github.com/keycloak/keycloak/pull/2825 Would be great if some other native german speakers would take a quick look. Thanks in advance! Cheers, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160512/6fa76d3e/attachment-0001.html From ton at finalist.nl Thu May 12 07:25:45 2016 From: ton at finalist.nl (Ton Swieb) Date: Thu, 12 May 2016 13:25:45 +0200 Subject: [keycloak-user] Keycloak in production. Use MongoDB or an RDBMS flavour? In-Reply-To: <57342624.3050307@redhat.com> References: <5732E301.5040108@redhat.com> <57342624.3050307@redhat.com> Message-ID: Hi Marek, Thanks for this anwer. It makes the decision between MongoDB and a RDBMS flavour much easier. I don't expect to do a lot of concurrent user creation / deletion. Usrs will added over time through Identity Brokering. I expect the focus of the load to be on users login/logout session. As this is mainly handled by caching I think I will go for a RDBMS flavour. Also because Stian pointed out that MongoDB will not be supported in the productized version in the beginning. A remaining question I have is what the size of the cache must be per user. I found another Keycloak thread which stated the size of the cache is not equal to the number of users in the DB. Do you know how big the cache must be to facilitate for example 10000 users? Regards, Ton 2016-05-12 8:43 GMT+02:00 Marek Posolda : > On 11/05/16 17:43, Ton Swieb wrote: >> >> Hi Marek, >> >> Thank you for your answer. So if I understand you correctly there are >> no plans to drop Mongo support in the near feature. Good to know. > > AFAIK we will keep mongo as many people are using that. But I am not in > position to promise anything related this :-) >> >> >> How many (concurrent) users did you need to use to see a performance >> difference between Mongo and MySQL? > > Depends on test scenario. For example if you have test for concurrent > login/logout of same set of users, then you might not see so big difference. > That's because keycloak has caching layer, so once user (or other object) is > read from DB for first time, then it's cached and next reads of same user > read this user from cache instead of from DB. So performance of DB is not so > visible here due to huge amount of caching. > > The difference might be more visible if you do some write operations (like > creating or deleting users). For example test for write/deleting of users. > I've just tried to run performance for create and delete 10000 users. The > results: > MySQL: > 8:08:47,096 INFO Operation 'create 10000 users' average: 227756 ms > 08:08:47,096 INFO Operation 'delete 10000 users' average: 110315 ms > > Mongo: > 08:14:57,957 INFO Operation 'create 10000 users' average: 157432 ms > 08:14:57,958 INFO Operation 'delete 10000 users' average: 49908 ms > > You can see that difference is not so big. That's because in 1.9 release, we > did lot of tuning for RDBMS model and we added some DB indexes to tune > performance. However for Mongo, we did not yet do this tuning.Once we do > that, the difference will be likely bigger. You can see here the indexes we > did for RDBMS for inspiration if you want to tune your mongo: > > https://github.com/keycloak/keycloak/blob/master/model/jpa/src/main/resources/META-INF/jpa-changelog-1.9.0.xml#L78-80 > https://github.com/keycloak/keycloak/blob/master/model/jpa/src/main/resources/META-INF/jpa-changelog-1.9.2.xml#L22-59 > > > If you want to try the performance test, you can do this (with MySQL, > assuming you have DB "keycloak" on localhost:3306 and user "keycloak" with > password "keycloak"): > > cd $KEYCLOAK_SOURCES > mvn clean install -DskipTests=true > cd testsuite/integration-arquillian/tests/other/jpa-performance > mvn clean install > -Dkeycloak.connectionsJpa.url=jdbc:mysql://localhost/keycloak > -Dkeycloak.connectionsJpa.driver=com.mysql.jdbc.Driver > -Dkeycloak.connectionsJpa.user=keycloak > -Dkeycloak.connectionsJpa.password=keycloak > -Dmany.users.read.after.create=true -Dmany.users.create.objects=true > > > with mongo, you can run the same test with last command like this (assuming > mongo running on localhost, test will use DB "keycloak-perf" ): > > mvn clean install -Dkeycloak.realm.provider=mongo > -Dkeycloak.user.provider=mongo > -Dkeycloak.userSessionPersister.provider=mongo > -Dkeycloak.eventsStore.provider=mongo > -Dkeycloak.connectionsMongo.db=keycloak-perf > -Dmany.users.read.after.create=true -Dmany.users.create.objects=true > > See the files for more available properties: > https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/other/jpa-performance/README.md > https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/resources/META-INF/keycloak-server.json > >> >> I assume the lack of transaction support in Mongo only becomes an >> issue with multi row/document transactions. Are multi row/document >> transactions used commonly in the Keycloak application or are most >> transactions limited to a single row/document? > > No, most of operations in admin console usually create/update just single > object. Same if user updates his profile in account management or new user > registers, it's just single user row involved. There are some exceptions for > this - for example if you create new realm or import realm, there are > transactions under many different objects in different collection. But > creating or importing realm is usually very rare operation. > > Marek >> >> >> Regards, Ton >> >> 2016-05-11 9:45 GMT+02:00 Marek Posolda : >>> >>> On 10/05/16 14:18, Ton Swieb wrote: >>>> >>>> Hi, >>>> >>>> I understand from the Keycloak documentation that both MongoDB and >>>> multiple flavours of RDBMS are supported, but I cannot find any >>>> recommendation whether to use MongoDB or an RDBMS by default. >>>> >>>> Which one is best suited for the Keycloak product? >>>> I am anticipating a user base of around 10000 users (mainly via >>>> Identity Brokering), will use offline tokens and use Keycloak as an >>>> Identity Broker for a SAML IdP. I am starting from a green field >>>> situation and do not have any restrictions on using a specific DB. >>>> >>>> I found a comment of Bill Birke on the Keycloak developer >>>> mailing-list, >>>> http://lists.jboss.org/pipermail/keycloak-dev/2015-July/004924.html, >>>> wishing he could drop Mongo and not seeing any advantages of using >>>> Mongo, but unfortunately the thread does not end with a >>>> conclusion/decision :-) >>>> >>>> What is the current position of the Keycloak team about using Mongo? >>> >>> We added Mongo support very early (somewhen around 2013) as an >>> alternative >>> storage, which was at that time required by other project, which consumed >>> keycloak. The second project (Liveoak) is not under active development >>> anymore, but in the meantime, a lot of people started to use Keycloak >>> with >>> Mongo and it seems that some of them already in production. >>> >>> The advantage of Mongo is good performance and scalability. At some >>> point, >>> when I tested performance with bigger number of users, I saw much better >>> performance for Mongo then for MySQL. Also Mongo has support for DB >>> clustering and sharding (some RDBMS has it too AFAIK, but usually you >>> need >>> to pay for them, which is not the case with Mongo ;)) . On the other >>> hand, >>> biggest disadvantage of Mongo is missing support for transactions. So in >>> theory, if some error/bad situation happens, you can theoretically end >>> with >>> partially inconsistent data in DB. >>> >>> Marek >>>> >>>> >>>> In which scenario should I consider using MongoDB over an RDBMS or >>>> vice versa? There are off course the usual pro/con's between NoSQL and >>>> RDBMS, but I would like to know to what extend they hold true when it >>>> comes to using Keycloak in production or whether Keycloak is optimized >>>> specifically for NoSQL or RDBMS. >>>> >>>> Regards, >>>> >>>> Ton >>>> > -- From daniele.bonetto at dnshosting.it Thu May 12 08:25:45 2016 From: daniele.bonetto at dnshosting.it (Daniele Bonetto) Date: Thu, 12 May 2016 14:25:45 +0200 Subject: [keycloak-user] Keycloak impersonate programmatically In-Reply-To: <4E607652-258B-4527-A07F-FB87114F703B@dnbcloud.com> References: <4E607652-258B-4527-A07F-FB87114F703B@dnbcloud.com> Message-ID: Hi, i suppose you've to set cookies from response and keycloak automagically made the things for you. I resolved the problem to call impersonation API from our back-office panel applying the following modifications to keycloak.js file. After /processInit /function definition add the following lines of code: /** * Append methods to keycloak object */ adapter.impersonate = function(options) { var url = kc.createImpersonationUrl(options); var req = new XMLHttpRequest(); req.open('POST', url, true); req.setRequestHeader('Accept', 'application/json'); req.setRequestHeader('Authorization', 'bearer ' + kc.token); req.withCredentials = true; var promise = createPromise(); req.onreadystatechange = function () { if (req.readyState == 4) { if (req.status == 200) { promise.setSuccess(); } else { promise.setError(); } } } req.send(null); return promise.promise; }; kc.impersonate = function(options) { return adapter.impersonate(options); }; kc.createImpersonationUrl = function(user) { return getRealmUrl().replace('/auth/', '/auth/admin/') + '/users/' + user + '/impersonation'; }; Then define your impersonate method that calls keycloak.impersonate where you manage local session refresh, like that: function impersonate(user) { var deferred = $.Deferred(); keycloak.impersonate(user).success(function() { console.log('user ' + user + ' impersonated'); // clear local session user informations clearSession(); // refresh logged user keycloak.login(); deferred.resolve(); }); return deferred.promise(); } Hope this helps! ;) Daniele Bonetto Il 12/05/2016 00:29, Anshul Malpani ha scritto: > Hi, > > I am trying to use impersonate feature using my java client. When I > call impersonate api using admin access grant. I get back the cookies. > How can I get the access token for the impersonate user. > > > > HttpPost post = new HttpPost( > KeycloakUriBuilder.fromUri(authServerUrl).path(?/admin/realms/{realm}/users/{id}/impersonation").build(realm, > accountKeycloakId)); > > This is returning me cookies. In next step I would like to get the > access token of impersonate user. > > Thanks > A > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160512/859e59c8/attachment.html From khirschmann at huebinet.de Thu May 12 08:52:31 2016 From: khirschmann at huebinet.de (Kevin Hirschmann) Date: Thu, 12 May 2016 14:52:31 +0200 Subject: [keycloak-user] CORS Message-ID: <002b01d1ac4d$2588b2f0$709a18d0$@huebinet.de> Hello, I have a front-end and one back-end application. For the front-end I entered the web origin: http://localhost:4000. Additionally I added a line true to the standalone.xml (wildfly 10 / keycloak 1.9.4.Final) The browser console displays: The 'Access-Control-Allow-Origin' header contains multiple values 'http://localhost:4000, http://localhost:4000', but only one is allowed. Origin 'http://localhost:4000' is therefore not allowed access. If I remove the line from the client I get: localhost/:1 XMLHttpRequest cannot load http://localhost:8080/auth/realms/... /protocol/openid-connect/token. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:4000' is therefore not allowed access. Has anyone a hint what could cause this? Thx a lot Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160512/240aa825/attachment.html From bcook at redhat.com Thu May 12 09:55:24 2016 From: bcook at redhat.com (Brian Cook) Date: Thu, 12 May 2016 07:55:24 -0600 Subject: [keycloak-user] when is the issuer field determined? Message-ID: I have a keycloak server in a test environment with several realms on it. It noticed yesterday that the issue in tokens from one realm seems to use the DNS name while in tokens from another realm it uses the the IP address. When is the issuer determined, and is it possible to change it? Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160512/c7d91dd0/attachment-0001.html From tech at psynd.net Thu May 12 10:29:56 2016 From: tech at psynd.net (Tech @ PSYND) Date: Thu, 12 May 2016 16:29:56 +0200 Subject: [keycloak-user] Keycloak 1.9.4 custom authenticator reference Message-ID: Dear experts, I'm working with keycloak 1.9.4. We ran some customization with the Authenticators: we implemented a couple of authenticators in sequence, like provide an OTP token, provide an additional information etc. We are facing several issues: 1) we create our custom Flow from the Authentication interface 2) we add our 4 form (Add Execution) 3) from the Flows Module we select the order in which they should be selected 4) we define in the binding sour flow as Browser Flow 5) we register and enable our executions from the Required Actions module. About point 3): even if we change the order of the flows using the priorities arrows, the forms doesn't show up in order. We tried to delete and to re-create, but we don't understand if we should do something else to impose the order we need. After creation, we decided to remove each single "Execution" and then remove the flow. We set again the "Browser Flow" to the standard "Browser", we removed the created jars from the provider/ directory, but every time that we try to authenticate we get an error saying that there is still an existing reference to the old deployment, although the provider/ directory is currently empty. 16:00:40,199 ERROR [io.undertow.request] (default task-4) UT005023: Exception handling request to /auth/realms/etatvs/login-actions/required-action: org.jboss.resteasy.spi.UnhandledException: java.lang.RuntimeException: Unable to find factory for Required Action: renew_password_config did you forget to declare it in a META-INF/services file? at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) Caused by: java.lang.RuntimeException: Unable to find factory for Required Action: renew_password_config did you forget to declare it in a META-INF/services file? at org.keycloak.services.managers.AuthenticationManager.executionActions(AuthenticationManager.java:569) at org.keycloak.services.managers.AuthenticationManager.actionRequired(AuthenticationManager.java:504) at org.keycloak.services.managers.AuthenticationManager.nextActionAfterAuthentication(AuthenticationManager.java:426) at org.keycloak.services.resources.LoginActionsService$Checks.verifyRequiredAction(LoginActionsService.java:302) at org.keycloak.services.resources.LoginActionsService.processRequireAction(LoginActionsService.java:856) Could you support? Thanks From mposolda at redhat.com Thu May 12 10:32:20 2016 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 12 May 2016 16:32:20 +0200 Subject: [keycloak-user] Keycloak in production. Use MongoDB or an RDBMS flavour? In-Reply-To: References: <5732E301.5040108@redhat.com> <57342624.3050307@redhat.com> Message-ID: <573493F4.3010604@redhat.com> On 12/05/16 13:25, Ton Swieb wrote: > Hi Marek, > > Thanks for this anwer. It makes the decision between MongoDB and a > RDBMS flavour much easier. > I don't expect to do a lot of concurrent user creation / deletion. > Usrs will added over time through Identity Brokering. I expect the > focus of the load to be on users login/logout session. > As this is mainly handled by caching I think I will go for a RDBMS > flavour. Also because Stian pointed out that MongoDB will not be > supported in the productized version in the beginning. > > A remaining question I have is what the size of the cache must be per > user. I found another Keycloak thread which stated the size of the > cache is not equal to the number of users in the DB. Do you know how > big the cache must be to facilitate for example 10000 users? Good question, currently you can count with like 3 items per user, but it may be more if identity brokering is involved as we have some additional cache items for quick lookup user by identity broker "link" . It can also depend how much "links" (federated identities) particular user has. You can try to add few users based on your environment and then see how cache grows. Cache can be monitored via MBean (so for example via jconsole) if you look at "org.infinispan:type=Cache,name="users(local)",manager="DefaultCacheManager",component=Statistics" and attribute "numberOfEntries". Default size of cache is 10000 (configured in standalone/configuration/standalone-ha.xml ). You may need to increase it to 50000 or so (depends if all of your 10000 users login frequently and you want to cache them all at the same time etc). Another thing is memory consumption. As of now, I don't know how much memory it consumes if you have 50000 records in cache, we may need to do some benchmarks regarding this... You can again try in your env and then possibly increase memory for your server. Marek > > Regards, Ton > > 2016-05-12 8:43 GMT+02:00 Marek Posolda : >> On 11/05/16 17:43, Ton Swieb wrote: >>> Hi Marek, >>> >>> Thank you for your answer. So if I understand you correctly there are >>> no plans to drop Mongo support in the near feature. Good to know. >> AFAIK we will keep mongo as many people are using that. But I am not in >> position to promise anything related this :-) >>> >>> How many (concurrent) users did you need to use to see a performance >>> difference between Mongo and MySQL? >> Depends on test scenario. For example if you have test for concurrent >> login/logout of same set of users, then you might not see so big difference. >> That's because keycloak has caching layer, so once user (or other object) is >> read from DB for first time, then it's cached and next reads of same user >> read this user from cache instead of from DB. So performance of DB is not so >> visible here due to huge amount of caching. >> >> The difference might be more visible if you do some write operations (like >> creating or deleting users). For example test for write/deleting of users. >> I've just tried to run performance for create and delete 10000 users. The >> results: >> MySQL: >> 8:08:47,096 INFO Operation 'create 10000 users' average: 227756 ms >> 08:08:47,096 INFO Operation 'delete 10000 users' average: 110315 ms >> >> Mongo: >> 08:14:57,957 INFO Operation 'create 10000 users' average: 157432 ms >> 08:14:57,958 INFO Operation 'delete 10000 users' average: 49908 ms >> >> You can see that difference is not so big. That's because in 1.9 release, we >> did lot of tuning for RDBMS model and we added some DB indexes to tune >> performance. However for Mongo, we did not yet do this tuning.Once we do >> that, the difference will be likely bigger. You can see here the indexes we >> did for RDBMS for inspiration if you want to tune your mongo: >> >> https://github.com/keycloak/keycloak/blob/master/model/jpa/src/main/resources/META-INF/jpa-changelog-1.9.0.xml#L78-80 >> https://github.com/keycloak/keycloak/blob/master/model/jpa/src/main/resources/META-INF/jpa-changelog-1.9.2.xml#L22-59 >> >> >> If you want to try the performance test, you can do this (with MySQL, >> assuming you have DB "keycloak" on localhost:3306 and user "keycloak" with >> password "keycloak"): >> >> cd $KEYCLOAK_SOURCES >> mvn clean install -DskipTests=true >> cd testsuite/integration-arquillian/tests/other/jpa-performance >> mvn clean install >> -Dkeycloak.connectionsJpa.url=jdbc:mysql://localhost/keycloak >> -Dkeycloak.connectionsJpa.driver=com.mysql.jdbc.Driver >> -Dkeycloak.connectionsJpa.user=keycloak >> -Dkeycloak.connectionsJpa.password=keycloak >> -Dmany.users.read.after.create=true -Dmany.users.create.objects=true >> >> >> with mongo, you can run the same test with last command like this (assuming >> mongo running on localhost, test will use DB "keycloak-perf" ): >> >> mvn clean install -Dkeycloak.realm.provider=mongo >> -Dkeycloak.user.provider=mongo >> -Dkeycloak.userSessionPersister.provider=mongo >> -Dkeycloak.eventsStore.provider=mongo >> -Dkeycloak.connectionsMongo.db=keycloak-perf >> -Dmany.users.read.after.create=true -Dmany.users.create.objects=true >> >> See the files for more available properties: >> https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/other/jpa-performance/README.md >> https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/resources/META-INF/keycloak-server.json >> >>> I assume the lack of transaction support in Mongo only becomes an >>> issue with multi row/document transactions. Are multi row/document >>> transactions used commonly in the Keycloak application or are most >>> transactions limited to a single row/document? >> No, most of operations in admin console usually create/update just single >> object. Same if user updates his profile in account management or new user >> registers, it's just single user row involved. There are some exceptions for >> this - for example if you create new realm or import realm, there are >> transactions under many different objects in different collection. But >> creating or importing realm is usually very rare operation. >> >> Marek >>> >>> Regards, Ton >>> >>> 2016-05-11 9:45 GMT+02:00 Marek Posolda : >>>> On 10/05/16 14:18, Ton Swieb wrote: >>>>> Hi, >>>>> >>>>> I understand from the Keycloak documentation that both MongoDB and >>>>> multiple flavours of RDBMS are supported, but I cannot find any >>>>> recommendation whether to use MongoDB or an RDBMS by default. >>>>> >>>>> Which one is best suited for the Keycloak product? >>>>> I am anticipating a user base of around 10000 users (mainly via >>>>> Identity Brokering), will use offline tokens and use Keycloak as an >>>>> Identity Broker for a SAML IdP. I am starting from a green field >>>>> situation and do not have any restrictions on using a specific DB. >>>>> >>>>> I found a comment of Bill Birke on the Keycloak developer >>>>> mailing-list, >>>>> http://lists.jboss.org/pipermail/keycloak-dev/2015-July/004924.html, >>>>> wishing he could drop Mongo and not seeing any advantages of using >>>>> Mongo, but unfortunately the thread does not end with a >>>>> conclusion/decision :-) >>>>> >>>>> What is the current position of the Keycloak team about using Mongo? >>>> We added Mongo support very early (somewhen around 2013) as an >>>> alternative >>>> storage, which was at that time required by other project, which consumed >>>> keycloak. The second project (Liveoak) is not under active development >>>> anymore, but in the meantime, a lot of people started to use Keycloak >>>> with >>>> Mongo and it seems that some of them already in production. >>>> >>>> The advantage of Mongo is good performance and scalability. At some >>>> point, >>>> when I tested performance with bigger number of users, I saw much better >>>> performance for Mongo then for MySQL. Also Mongo has support for DB >>>> clustering and sharding (some RDBMS has it too AFAIK, but usually you >>>> need >>>> to pay for them, which is not the case with Mongo ;)) . On the other >>>> hand, >>>> biggest disadvantage of Mongo is missing support for transactions. So in >>>> theory, if some error/bad situation happens, you can theoretically end >>>> with >>>> partially inconsistent data in DB. >>>> >>>> Marek >>>>> >>>>> In which scenario should I consider using MongoDB over an RDBMS or >>>>> vice versa? There are off course the usual pro/con's between NoSQL and >>>>> RDBMS, but I would like to know to what extend they hold true when it >>>>> comes to using Keycloak in production or whether Keycloak is optimized >>>>> specifically for NoSQL or RDBMS. >>>>> >>>>> Regards, >>>>> >>>>> Ton >>>>> From emanuel.amaral.couto at gmail.com Thu May 12 12:46:50 2016 From: emanuel.amaral.couto at gmail.com (Emanuel Couto) Date: Thu, 12 May 2016 16:46:50 +0000 Subject: [keycloak-user] Manually input Realm Keys Message-ID: Hello I'm trying to manually input keys in a Realm. I tried generating a key pair using 'ssh-keygen': $ ssh-keygen Then I copied the content of 'id_rsa' and 'id_rsa.pub' to the input boxes and pressed "Upload Keys". However an error message is shown "Failed to decode public key". How do I manually input a key pair or certificate? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160512/15c21e4c/attachment.html From sthorger at redhat.com Fri May 13 01:48:03 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 13 May 2016 07:48:03 +0200 Subject: [keycloak-user] Manually input Realm Keys In-Reply-To: References: Message-ID: Keycloak expects both keys in PEM format. ssh-keygen writes the private key in PEM format, but not the public key. You can create the public key from the private key with ssh-keygen or openssl: ssh-keygen -f mykey -e -m pem openssl rsa -in mykey -pubout On 12 May 2016 at 18:46, Emanuel Couto wrote: > Hello > > I'm trying to manually input keys in a Realm. I tried generating a key > pair using 'ssh-keygen': > > $ ssh-keygen > > Then I copied the content of 'id_rsa' and 'id_rsa.pub' to the input boxes > and pressed "Upload Keys". However an error message is shown "Failed to > decode public key". > > How do I manually input a key pair or certificate? > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160513/eb503c35/attachment.html From sthorger at redhat.com Fri May 13 02:00:52 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 13 May 2016 08:00:52 +0200 Subject: [keycloak-user] when is the issuer field determined? In-Reply-To: References: Message-ID: The issuer is based on the URL used to access Keycloak. If the application requests the token with the DNS name that'll be the issuer, if it requests the token with the IP address that'll be the issuer. On 12 May 2016 at 15:55, Brian Cook wrote: > I have a keycloak server in a test environment with several realms on it. > It noticed yesterday that the issue in tokens from one realm seems to use > the DNS name while in tokens from another realm it uses the the IP > address. When is the issuer determined, and is it possible to change it? > > Thanks, > Brian > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160513/3843bea6/attachment.html From sthorger at redhat.com Fri May 13 02:11:15 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 13 May 2016 08:11:15 +0200 Subject: [keycloak-user] Keycloak as ID provider for large amount of devices In-Reply-To: <61D077C6283D454FAFD06F6AC4AB74D723DD53F4@DEFTHW99EZ1MSX.ww931.my-it-solutions.net> References: <61D077C6283D454FAFD06F6AC4AB74D723DD53F4@DEFTHW99EZ1MSX.ww931.my-it-solutions.net> Message-ID: Hi, That's a very interesting use-case. One which we have wanted to look into ourselves, but haven't had the resources. Ideally I'd say we'd have a device concept in Keycloak as they're not strictly clients or users. They'd most likely be backed by users, but would have different screens for configuration and would have separate authentication flows. That would require a fair bit of work to add though. In the mean time I don't think clients are a good fit as Keycloak is not currently designed to have large amounts of clients, both for manageability and performance. Both of the issues can be overcome fairly easily, but that would require some work. The best solution in my opinion is to use users and implement your own custom authenticator to handle IOT devices. It's fairly simply to do and gives you the ability to handle authentication of the devices exactly how you want to. See http://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html for more details. I'd appreciate if you kept me updated on your progress as I'm very interested :) On 12 May 2016 at 10:29, Matuszak, Eduard wrote: > Hello > > We are planning to get a lot of devices, identifyable by individual > certificates, into an IOT-system being designed and developed at the > moment. We choosed to authenticate all actors (users, software components > and devices as well) by OIDC-tokens and (pre)decided to use Keycloak as ID > provider. User and software components are quite straightforward to handle > with Keycloak (as Keycloak users with the help of a user federation > provider & id brokerage and for applications as Keycloak clients > respectively). But I am not sure of how to represent our devices (we want > to support hundreds of thousands of them later on!) by Keycloak means. > > It seems that we essentially have 2 possiblities to register a device in > Keycloak > > - As a user > - As a client > > > By representing devices as Keycloak clients we might take advantage of the > ServiceAccount (Oauth-Client Credential) flow and become able to implement > it via (dynamic!) registration and it and seems, that we will even be able > to authenticate our device by their certificates by choosing "Signed Jwt" > as authenticator option. > > My question is, if it would be a good idea to register a very big amount > of devices as Keycloak clients with regards to performance and > manageability. In principle I would prefer a user-representation > (faciliting usage of user federation provider & id brokerage for instance), > but as far as I understood, the appropriate flow would be Direct Access > (ResourceOwnerPassword Credentials) and here we can only deal with > username/password instead of certificates. > > Do you have any suggestions or hints (even the conclusion, that Keycloak > is not the suitable ID-provider-implementation for large-scale IOT-systems)? > > Best regards, Eduard Matuszak > > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160513/3fedfa09/attachment-0001.html From Sven.Riedel at glomex.com Fri May 13 04:10:30 2016 From: Sven.Riedel at glomex.com (Riedel, Sven) Date: Fri, 13 May 2016 08:10:30 +0000 Subject: [keycloak-user] Cross-Site Replication Message-ID: Hi, in my current project we would need to do a cross-site replication of keycloak data, i.e. we'd have one "master" cluster with authoritative user data, and multiple "slave" clusters in different computing centers. Realm and User Data is only written to the master cluster and the slave clusters are read only. Session data could be handled independently for each cluster. I have a few questions to this use case: - Can I use keycloaks clustering via infinispan for this? I have no experience with infinispan, but I could imagine that the cross site latency would destroy performance. - The other naive approach would be to do a database replication between the sites. The problem I see here is that the keycloak invalidation cache would not respond to data that is changed in the backing database via replication, and I'd either have to disable the caches (which I'd prefer not to do) or periodically flush the caches via some scheduled job in the slave clusters. Is this correct? - Does some other mechanism for the cross-site replication use case already exist that I'm not aware of? I'm kind of hoping that we won't have to write components that feed data changes via api to the slave clusters so that we can use the invalidation caches without problems. Any thoughts are welcome. Thanks, Sven -- Sven Riedel Senior Systemsarchitect glomex GmbH Ein Unternehmen der ProSiebenSat.1 Media SE Medienallee 4 D-85774 Unterf?hring Tel. +49 [89] 9507-8167 sven.riedel at glomex.com Gesch?ftsf?hrer: Michael Jaschke, Arnd M?ckenberger HRB 224542 AG M?nchen USt.-ID.-Nr. DE 218559421 St.-Nr. 143/141/71293 From emanuel.amaral.couto at gmail.com Fri May 13 05:20:11 2016 From: emanuel.amaral.couto at gmail.com (Emanuel Couto) Date: Fri, 13 May 2016 09:20:11 +0000 Subject: [keycloak-user] Manually input Realm Keys In-Reply-To: References: Message-ID: Still not working, I get the same error. I've sent the steps in attachment. I'm copying the following keys to "Realm Settings -> Keys" to the respective input boxes. I'm leaving the certificate box empty. *Private Key:* MIIEogIBAAKCAQEAsoGXdarRCouoMkJDtZHqnJwdHz6M1e8ZbZmJaP3Fg44oDcg1LIy6w0jqYBKlI9PMYT6FsErxroLJX+2412k/PvZ0zKE9eUQn4/XVMZ6GfpKNA89fhCPwwCfW3Oo+Pv9wO+6a+FTo0yeCGSpGpXrwCbFqlxkZDrhkMAiJfDa0uRx18eFYHoyt5NFxfe4Hih7EUKEX8C0De+q1inawTqkFjFwETBRw+c4KEX2O5L/GJVx+1fXTcaeNvRbGq5kN9IskD1OKu1JH3rF49f036U/g55pSkcB/uWsW9GpUSYbSs6GRBJnbRnP4HfbUqcBepMGdeu1SwjTEKteQoIS1q+LxiwIDAQABAoIBAFqzZlYvmVAWbjw7V1Qm9GLnIBUEH2OEvhLmdN+YMogJ72gxVnNwfmVD43M1hhuSPsMalatiKTNW2SOZEtbBb5V6fRaMx0Oa0foOq2ku93/Qzz4kXJA0AtxgYdiWXVJ9UHXjY3LTEgpYhM5soMDsmpMSRurHoefM4XtWmyU2VtXHOhw/ZCbszOQRJ7fjm2ZOJ3Qj0O3Xo7Q8AJ5CalGNfvieeh8p885s74tBviiBla5k3ZcXZqadUUDFd/HQHYA9f7bSJdmZE/fcayjD1ksdc4KDwaH9srDPpYF16eHYO5KwF9xjCYWptEa4ZVzA5XqAMLI9KCeEFuMjUZP1g+K8FeECgYEA6yfLaP28UphTeDJUc7adJHSUM0VSBiAn2AcIbMkToDfshELwPZf4rcxZG5LDnIRjJ+lDKGIbcIm/IJLeNMfcbtvQtWqVjimPMxVYbi7rO2S5jqKZwUGUOGiRKKtFNZw+q4hDtMxHl3pX8FIswfLMVfIccnx3ht8pQ+SlCMeZrP8CgYEAwlRMe5xNNMLtoaXMC35QmB+diVsNiDL1C0DNIBjhj7gGrjXx1sIL/UeP0jsEJBgFdJlysXjeb1HbYSiwZfrAPHDIcqNfamTm9ljTSlX2kcT/bDg4Y8POdODRLiRAdwe8m4bE/fkeTzsf3CdPsoCHYeZgT1bF9ES+txNV+YVMH3UCgYBVBj5158h/1LPZcdk3PX/z/nLXVukhbd76LRDOxKVj+NR7vfg/TQONU6WkYpx3qyZu99hgcZiaSDPjAzd0vg7lxnTgI3mPvVcZkU44CJ7lCrZM7F3LknqVKrnRipurlqLSQqK4bGQ2UPYa3ptwROm86Z1/h6FwEqBI/BLv6buW4QKBgCni3bFvGT0cHvhOslJv4ZNIjT5EAACxaxwH1a7rbgL6WYZHXl856DepqxhXXCcjflmJka0rLla0QCMLECqLB9B/RtVe3XwjT50dvD0zljgJTDzZSV5HoEKVCsF1UufVJRQo0mEjxyKwzcc4OfdxuLyjWXMAcx6ZiroPUuK7lpLZAoGAWO+bkP9134OdPfsjnXt1hrbMhayKpgkSnN/tZWl9m6oNfpBwMJD11VwKVHBcM+IVZX8Iklv/+pT3+KWTn0DrFlcFc+nRRs/8b78xVJ17Il2mz4P6+IYVLLdA0Bgq7UB6GP4Xxqkbmwkc+SmPERM77V8XP6KfqbSUoCUmqybr4yI= *Public Key:* MIIBCgKCAQEAsoGXdarRCouoMkJDtZHqnJwdHz6M1e8ZbZmJaP3Fg44oDcg1LIy6w0jqYBKlI9PMYT6FsErxroLJX+2412k/PvZ0zKE9eUQn4/XVMZ6GfpKNA89fhCPwwCfW3Oo+Pv9wO+6a+FTo0yeCGSpGpXrwCbFqlxkZDrhkMAiJfDa0uRx18eFYHoyt5NFxfe4Hih7EUKEX8C0De+q1inawTqkFjFwETBRw+c4KEX2O5L/GJVx+1fXTcaeNvRbGq5kN9IskD1OKu1JH3rF49f036U/g55pSkcB/uWsW9GpUSYbSs6GRBJnbRnP4HfbUqcBepMGdeu1SwjTEKteQoIS1q+LxiwIDAQAB Thanks. On Fri, May 13, 2016 at 6:48 AM Stian Thorgersen wrote: > Keycloak expects both keys in PEM format. > > ssh-keygen writes the private key in PEM format, but not the public key. > You can create the public key from the private key with ssh-keygen or > openssl: > > ssh-keygen -f mykey -e -m pem > openssl rsa -in mykey -pubout > > > On 12 May 2016 at 18:46, Emanuel Couto > wrote: > >> Hello >> >> I'm trying to manually input keys in a Realm. I tried generating a key >> pair using 'ssh-keygen': >> >> $ ssh-keygen >> >> Then I copied the content of 'id_rsa' and 'id_rsa.pub' to the input boxes >> and pressed "Upload Keys". However an error message is shown "Failed to >> decode public key". >> >> How do I manually input a key pair or certificate? >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160513/cb80eb2c/attachment.html -------------- next part -------------- $ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/c/Users/emanuel.couto/.ssh/id_rsa): id_rsa Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in id_rsa. Your public key has been saved in id_rsa.pub. The key fingerprint is: SHA256:mB0CkvOWA6YOr5RRnzN+bN0+Jsr7V6n7cS1w2beyNsg emanuel.couto at pwecouto01 The key's randomart image is: +---[RSA 2048]----+ | ... | | =o . | | o.+..o . | |o. == = . o | |o.o...* S . . + o| | +. . + . . = +| |.. o o +o.o.| |. . . E o=. | | ++.+.=o. | +----[SHA256]-----+ $ cat id_rsa -----BEGIN RSA PRIVATE KEY----- MIIEogIBAAKCAQEAsoGXdarRCouoMkJDtZHqnJwdHz6M1e8ZbZmJaP3Fg44oDcg1 LIy6w0jqYBKlI9PMYT6FsErxroLJX+2412k/PvZ0zKE9eUQn4/XVMZ6GfpKNA89f hCPwwCfW3Oo+Pv9wO+6a+FTo0yeCGSpGpXrwCbFqlxkZDrhkMAiJfDa0uRx18eFY Hoyt5NFxfe4Hih7EUKEX8C0De+q1inawTqkFjFwETBRw+c4KEX2O5L/GJVx+1fXT caeNvRbGq5kN9IskD1OKu1JH3rF49f036U/g55pSkcB/uWsW9GpUSYbSs6GRBJnb RnP4HfbUqcBepMGdeu1SwjTEKteQoIS1q+LxiwIDAQABAoIBAFqzZlYvmVAWbjw7 V1Qm9GLnIBUEH2OEvhLmdN+YMogJ72gxVnNwfmVD43M1hhuSPsMalatiKTNW2SOZ EtbBb5V6fRaMx0Oa0foOq2ku93/Qzz4kXJA0AtxgYdiWXVJ9UHXjY3LTEgpYhM5s oMDsmpMSRurHoefM4XtWmyU2VtXHOhw/ZCbszOQRJ7fjm2ZOJ3Qj0O3Xo7Q8AJ5C alGNfvieeh8p885s74tBviiBla5k3ZcXZqadUUDFd/HQHYA9f7bSJdmZE/fcayjD 1ksdc4KDwaH9srDPpYF16eHYO5KwF9xjCYWptEa4ZVzA5XqAMLI9KCeEFuMjUZP1 g+K8FeECgYEA6yfLaP28UphTeDJUc7adJHSUM0VSBiAn2AcIbMkToDfshELwPZf4 rcxZG5LDnIRjJ+lDKGIbcIm/IJLeNMfcbtvQtWqVjimPMxVYbi7rO2S5jqKZwUGU OGiRKKtFNZw+q4hDtMxHl3pX8FIswfLMVfIccnx3ht8pQ+SlCMeZrP8CgYEAwlRM e5xNNMLtoaXMC35QmB+diVsNiDL1C0DNIBjhj7gGrjXx1sIL/UeP0jsEJBgFdJly sXjeb1HbYSiwZfrAPHDIcqNfamTm9ljTSlX2kcT/bDg4Y8POdODRLiRAdwe8m4bE /fkeTzsf3CdPsoCHYeZgT1bF9ES+txNV+YVMH3UCgYBVBj5158h/1LPZcdk3PX/z /nLXVukhbd76LRDOxKVj+NR7vfg/TQONU6WkYpx3qyZu99hgcZiaSDPjAzd0vg7l xnTgI3mPvVcZkU44CJ7lCrZM7F3LknqVKrnRipurlqLSQqK4bGQ2UPYa3ptwROm8 6Z1/h6FwEqBI/BLv6buW4QKBgCni3bFvGT0cHvhOslJv4ZNIjT5EAACxaxwH1a7r bgL6WYZHXl856DepqxhXXCcjflmJka0rLla0QCMLECqLB9B/RtVe3XwjT50dvD0z ljgJTDzZSV5HoEKVCsF1UufVJRQo0mEjxyKwzcc4OfdxuLyjWXMAcx6ZiroPUuK7 lpLZAoGAWO+bkP9134OdPfsjnXt1hrbMhayKpgkSnN/tZWl9m6oNfpBwMJD11VwK VHBcM+IVZX8Iklv/+pT3+KWTn0DrFlcFc+nRRs/8b78xVJ17Il2mz4P6+IYVLLdA 0Bgq7UB6GP4Xxqkbmwkc+SmPERM77V8XP6KfqbSUoCUmqybr4yI= -----END RSA PRIVATE KEY----- $ ssh-keygen -f id_rsa -e -m pem -----BEGIN RSA PUBLIC KEY----- MIIBCgKCAQEAsoGXdarRCouoMkJDtZHqnJwdHz6M1e8ZbZmJaP3Fg44oDcg1LIy6 w0jqYBKlI9PMYT6FsErxroLJX+2412k/PvZ0zKE9eUQn4/XVMZ6GfpKNA89fhCPw wCfW3Oo+Pv9wO+6a+FTo0yeCGSpGpXrwCbFqlxkZDrhkMAiJfDa0uRx18eFYHoyt 5NFxfe4Hih7EUKEX8C0De+q1inawTqkFjFwETBRw+c4KEX2O5L/GJVx+1fXTcaeN vRbGq5kN9IskD1OKu1JH3rF49f036U/g55pSkcB/uWsW9GpUSYbSs6GRBJnbRnP4 HfbUqcBepMGdeu1SwjTEKteQoIS1q+LxiwIDAQAB -----END RSA PUBLIC KEY----- From kalc04 at gmail.com Fri May 13 05:44:10 2016 From: kalc04 at gmail.com (Lohitha Chiranjeewa) Date: Fri, 13 May 2016 15:14:10 +0530 Subject: [keycloak-user] Last Login Time of User In-Reply-To: <5732DDE0.70207@redhat.com> References: <5732DDE0.70207@redhat.com> Message-ID: Thanks for suggestions guys, will try out and see how it works. Regards, Lohitha. On Wed, May 11, 2016 at 12:53 PM, Marek Posolda wrote: > Another possibility is to look at userSession (this info is available in > admin console). When user authenticates, the new userSession is created for > him with the "started" attribute containing the time of authentication. In > admin console (and also via REST endpoints) there is possibility to look at > all userSessions of particular user, so you can chose the one with last > "started" attribute. > > This requires some additional work for parse userSessions and also there > is corner case when this info is not accurate (as new userSession is also > created when "verify-email" is requested for particular user, which is not > the time of successful authentication of particular user). > > On the other hand, you don't need the custom Authenticator implementation. > And there is also performance penalty in store the info in DB in user > attributes, because you need to write to DB and update user during each > login. > > Marek > > > > On 10/05/16 17:10, Thomas Darimont wrote: > > Would be great to store some additional information like: > - count of failed logins > - last failed login date > > Cheers, > Thomas > > 2016-05-10 14:38 GMT+02:00 Thomas Darimont >: > >> Hello, >> >> I implemented a custom RequiredAction that maintains stuff like: >> - first login time >> - most recent login time >> - login count >> in user attributes. >> >> Cheers, >> Thomas >> >> 2016-05-10 14:35 GMT+02:00 Lohitha Chiranjeewa < >> kalc04 at gmail.com>: >> >>> Hi, >>> >>> Is there a way to retrieve the last login time of a given user? >>> >>> I checked the Admin Console, Rest specification and the mysql DB >>> structure but couldn't find a place where that bit of information could be >>> stored and retrieved from. Have I missed a place or is that feature not >>> available (yet)? >>> >>> >>> Regards, >>> Lohitha. >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> >> > > > _______________________________________________ > keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160513/8b2c60e6/attachment-0001.html From bruno at abstractj.org Fri May 13 08:05:19 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 13 May 2016 09:05:19 -0300 Subject: [keycloak-user] keycloak-nodejs-connect connection issues In-Reply-To: References: <20160511151624.GA5652@abstractj.org> Message-ID: <20160513120519.GB30817@abstractj.org> Hi Elston, at your realm, try to change nodejs-connect client to this configuration[1], plus, make sure that you have keycloak.json[2] properly configured. I hope it helps. [1] - https://github.com/keycloak/keycloak-nodejs-connect/blob/master/example/nodejs-example-realm.json#L44-L55 [2] - https://github.com/keycloak/keycloak-nodejs-connect/blob/master/example/keycloak.json On 2016-05-12, Elston Baretto wrote: > Hi Bruno > > Thanks for your reply and introducing me to the mailing list. I was not > aware of it. > > I've attached my Realm JSON file and have been following the example > exactly as shown on github but with no luck. > > I've also created a Stack Overflow question to explain my loopback side of > thing if this helps: > > http://stackoverflow.com/questions/37056089/oauth-2-0-openid-connect-loopback-and-keycloak > > > Still really stumped. > > Thanks a lot for your help > > Regards, > Elston > > On 11 May 2016 at 11:16, Bruno Oliveira wrote: > > > Hi Elston, I'm including the keycloak-user mailing list. If you haven't > > subscribed yet, please do it for further questions. > > > > Have you tried to run the examples from here[1]? How your realm JSON > > file looks like? > > > > [1] - > > https://github.com/keycloak/keycloak-nodejs-connect/tree/master/example > > > > On 2016-05-05, Elston Baretto wrote: > > > Hi Bruno > > > > > > I've been banging my head against a brick wall for while now and > > wondering > > > if you can rescue me since you're a contributor. > > > > > > I currently have a loopback app that I'm trying to protect with Keycloak > > > and my server/boot/root.js contains: > > > > > > module.exports = function (server) { > > > var session = require('express-session'); > > > var Keycloak = require('keycloak-connect'); > > > > > > var keycloak = new Keycloak(); > > > var memoryStore = new session.MemoryStore(); > > > > > > server.use(session({ > > > secret: '3249d976-7c6c-481d-83e6-c8012904f00a', > > > resave: false, > > > saveUninitialized: true, > > > store: memoryStore, > > > })) > > > > > > var keycloak = new Keycloak({ > > > store: memoryStore > > > }); > > > > > > server.use(keycloak.middleware({})); > > > > > > server.get('/*', keycloak.protect(), function (req, resp) { > > > resp.send('hello'); > > > }) > > > > > > }; > > > > > > I've tried to follow the example as closely as possible but when I hit > > any > > > API I get into a redirect loop and the request fails. > > > > > > I've also tried swapping the server.use(session line with > > > server.use(keycloak but then see: > > > > > > Cannot read property 'keycloak-token' of undefined > > > > > > Is there something I'm doing wrong? > > > > > > Thanks in advance! > > > > > > Cheers, > > > Elston > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > > [ { > "id" : "master", > "realm" : "master", > "displayName" : "Keycloak", > "displayNameHtml" : "
Keycloak
", > "notBefore" : 0, > "revokeRefreshToken" : false, > "accessTokenLifespan" : 60, > "accessTokenLifespanForImplicitFlow" : 900, > "ssoSessionIdleTimeout" : 1800, > "ssoSessionMaxLifespan" : 36000, > "offlineSessionIdleTimeout" : 2592000, > "accessCodeLifespan" : 60, > "accessCodeLifespanUserAction" : 300, > "accessCodeLifespanLogin" : 1800, > "enabled" : true, > "sslRequired" : "external", > "registrationAllowed" : false, > "registrationEmailAsUsername" : false, > "rememberMe" : false, > "verifyEmail" : false, > "resetPasswordAllowed" : false, > "editUsernameAllowed" : false, > "bruteForceProtected" : false, > "maxFailureWaitSeconds" : 900, > "minimumQuickLoginWaitSeconds" : 60, > "waitIncrementSeconds" : 60, > "quickLoginCheckMilliSeconds" : 1000, > "maxDeltaTimeSeconds" : 43200, > "failureFactor" : 30, > "privateKey" : "MIIEpAIBAAKCAQEAoWBRNNb/w7Y6dHGcFLiclx7mO/VWe/4rQ8njjY7qO0KEzY6+5ai6HQyUX41o2BEb/LcoOF4vWboRZ3Gv55lO32158PFavDPc4k1Cw0s7zB9fBInCEFhvzn2PvesVXBk6GYdmZF5oF6ppNz0U+HTTMKWl/uEfOymy93URt2SwHGi1984/RfYpEbDXb7mgn0ODCBdQTWQFhvr6Eynve1UoV00xKxDxWlkAtG1pMZXSF80VNfNQIG4kf93WhCV2vOHwQtDb4reaxqbgC030/BToVaUhZup+F6pXz5pnzIf5Rmuv02e5vIceKXwNamXt0mnBu/phj2+iDPoO/mkWaQ3DuwIDAQABAoIBAGD2kJShQpiD2+evg8rnih87T7djGI30EGbw3atm3dKxiz4/sPApS3q83kHzo7V/wkM8ggwse2L8bAytwLX15fBVxVlCi/RdbTEEn0Lc55ckmmENrO9JVBTMWRwSLoliFwjT1HAmUYE2wXWRXBJVj7fBMFZPSgawbXpGe1ioRTEruxsC2SfXIhzLsLrmtHtS3xGW54EiRNL43q0iG0MWy2OObD5MK44WYkwXkPnqLPAAAVNgtLVCEwwwL0Dkihr+fVSsB94sow2W/FmCkzfLvdDxqsdDCDxTgKsrtfNT5xKZKk8oVEjo0/X6vbsZ/y2dKn2qH1MI/GkRaZ8ZxElMqYECgYEA59hsj3LgasR6g7NfQKMeslM9KzDCpqZi425CTOWEDmnEsRmPXefezLF0sLy47b4x3NY4WW+JxIMF9yaj5YYynj+WlCTV2tAHm885iJGx2HRmRODI3JhBLXTh5LgQhBAsSMOH3tUuQW6V3h3NG6qexwJ51QiO+n9eWUhgzf86fBsCgYEAsjBm2PwoLkbhpZ6iOqElTonhTVPM0v3j12od6qlb1Nukt1//ZiitZzyzwABKcV7dt79Sej9QG+tmOVv/zIhZAn8n1vJKVNmTM27Bm5xwavSpQpXGM+gN2DprvWanhjp/cgikHRpO9j+EUbeOAFQnc0Mw+Bly/BR7JdoAGHD/EOECgYEAkMUwzMZD4gd8JR7tfLQe5+VYTc7tzRgaqb9gwRmUQ1fCTYATaOTv18t7fRzrMPFRu388woQGd+IE6JaFQz5v/ybfxPPXYgICrkVQvLmVXv8YGSxv4GdmU5cnsyVIkt5yeKE4B2oArzT5ejALspnw+X3PS7pDZaIA7Sln4VndUD8CgYByI8b9nygt3IGWEXNhku/Oy0tiuRcu4CseRX88XZfRVZDBVeDHk67fvmZ1yrnkvRvRI+C1JfEusS8d9ux4G67IhqMCcNlkWKqN+5hREXiBSo9Rc5cukKqto154SFVvCfGxHg/iBIQoAK/FmIqBc2aB0rx/b+3Tw1rO+EGvZlI8gQKBgQDPf79nt9Et+IK8OR4woWMa7YPPbCHCM0/PmpsqrZTzNzxIHaZYi3kK64OWz3y9O3ymz1QjkKgnL8T1dXtRRefz3HDulX8TxD4CV6jcZSItmhWol2Ps2VnY9G8vB3ag2ceCugCMkLqzn6R2ZHGaK36cPaZamITfiHSUN3zdYSDIqQ==", > "publicKey" : "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoWBRNNb/w7Y6dHGcFLiclx7mO/VWe/4rQ8njjY7qO0KEzY6+5ai6HQyUX41o2BEb/LcoOF4vWboRZ3Gv55lO32158PFavDPc4k1Cw0s7zB9fBInCEFhvzn2PvesVXBk6GYdmZF5oF6ppNz0U+HTTMKWl/uEfOymy93URt2SwHGi1984/RfYpEbDXb7mgn0ODCBdQTWQFhvr6Eynve1UoV00xKxDxWlkAtG1pMZXSF80VNfNQIG4kf93WhCV2vOHwQtDb4reaxqbgC030/BToVaUhZup+F6pXz5pnzIf5Rmuv02e5vIceKXwNamXt0mnBu/phj2+iDPoO/mkWaQ3DuwIDAQAB", > "certificate" : "MIICmzCCAYMCBgFUfeZaNzANBgkqhkiG9w0BAQsFADARMQ8wDQYDVQQDDAZtYXN0ZXIwHhcNMTYwNTA0MjIzMDI5WhcNMjYwNTA0MjIzMjA5WjARMQ8wDQYDVQQDDAZtYXN0ZXIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChYFE01v/Dtjp0cZwUuJyXHuY79VZ7/itDyeONjuo7QoTNjr7lqLodDJRfjWjYERv8tyg4Xi9ZuhFnca/nmU7fbXnw8Vq8M9ziTULDSzvMH18EicIQWG/OfY+96xVcGToZh2ZkXmgXqmk3PRT4dNMwpaX+4R87KbL3dRG3ZLAcaLX3zj9F9ikRsNdvuaCfQ4MIF1BNZAWG+voTKe97VShXTTErEPFaWQC0bWkxldIXzRU181AgbiR/3daEJXa84fBC0Nvit5rGpuALTfT8FOhVpSFm6n4XqlfPmmfMh/lGa6/TZ7m8hx4pfA1qZe3SacG7+mGPb6IM+g7+aRZpDcO7AgMBAAEwDQYJKoZIhvcNAQELBQADggEBAEV+1ciCOXxWpYXJoGTMFoyGR0L/N5/CPwquHylpHJ5aC1nU6IHZTE7uy9u8WZmEWQjAbCbqrZqSbL3Hx8d6+CYX+lxylo8822ivOabqRuLfJgBiqGrxuha0c1iqxbxq4/c5Z6IL3AA0fA6Xi1JadSZWGLqbc7zNLwUte1RrWUOsIVOjKMUSfcceGUHOCvltAMfu6DVumQizUlbWJOUNBB7Xonrt03RpXzYxWjfRawXZDY/uZTy0zflJaZRM7PQYwsdmztJN0ylkM/ovgg2mRZtCwAr2X+wuOZXyKdNE1lEAZfgOGy0JSREbTkmqG24J4b2FN/UVmW6Ro7hb4FDP2h8=", > "codeSecret" : "1bba70f7-616c-41a0-8b62-52e763f7a782", > "roles" : { > "realm" : [ { > "id" : "a6889f38-83b6-42db-90e7-c5ee83903ce5", > "name" : "admin", > "description" : "${role_admin}", > "scopeParamRequired" : false, > "composite" : true, > "composites" : { > "realm" : [ "create-realm" ], > "client" : { > "master-realm" : [ "manage-realm", "manage-identity-providers", "view-clients", "view-identity-providers", "manage-events", "view-users", "view-realm", "create-client", "manage-clients", "manage-users", "impersonation", "view-events" ] > } > } > }, { > "id" : "33777574-a7c4-42f8-9c3a-b0c2ca45aa74", > "name" : "create-realm", > "description" : "${role_create-realm}", > "scopeParamRequired" : false, > "composite" : false > }, { > "id" : "ce37188d-c2e5-4a39-be4f-2bcbecb736f2", > "name" : "user", > "description" : "User privileges", > "scopeParamRequired" : false, > "composite" : false > }, { > "id" : "488e7dde-55c9-4d63-8274-ea3833882f13", > "name" : "offline_access", > "description" : "${role_offline-access}", > "scopeParamRequired" : true, > "composite" : false > } ], > "client" : { > "nodejs-connect" : [ ], > "security-admin-console" : [ ], > "admin-cli" : [ ], > "broker" : [ { > "id" : "60a9b97b-a6da-41e0-bf18-a5420b4777ff", > "name" : "read-token", > "description" : "${role_read-token}", > "scopeParamRequired" : false, > "composite" : false > } ], > "master-realm" : [ { > "id" : "fb82647e-5ce7-4531-8f96-cae6e226fa1d", > "name" : "view-realm", > "description" : "${role_view-realm}", > "scopeParamRequired" : false, > "composite" : false > }, { > "id" : "1ad46c41-1f3b-46da-b36b-1c6ef3321f3a", > "name" : "manage-realm", > "description" : "${role_manage-realm}", > "scopeParamRequired" : false, > "composite" : false > }, { > "id" : "ea0a2b65-7e52-4ab2-b202-2fdfc74e4ef2", > "name" : "create-client", > "description" : "${role_create-client}", > "scopeParamRequired" : false, > "composite" : false > }, { > "id" : "ffa8e1b6-7c0a-44dd-89ab-95181bf40566", > "name" : "manage-clients", > "description" : "${role_manage-clients}", > "scopeParamRequired" : false, > "composite" : false > }, { > "id" : "8b964c7d-cfbf-4e64-baad-457d1203ecc5", > "name" : "manage-identity-providers", > "description" : "${role_manage-identity-providers}", > "scopeParamRequired" : false, > "composite" : false > }, { > "id" : "4507f850-c410-45cd-ba2e-7532b3f0b407", > "name" : "view-clients", > "description" : "${role_view-clients}", > "scopeParamRequired" : false, > "composite" : false > }, { > "id" : "4f1e76b4-427a-4e98-8339-d7bf0d7a0cf7", > "name" : "manage-users", > "description" : "${role_manage-users}", > "scopeParamRequired" : false, > "composite" : false > }, { > "id" : "f6d0b384-6312-46c3-8952-b06360bcb445", > "name" : "view-identity-providers", > "description" : "${role_view-identity-providers}", > "scopeParamRequired" : false, > "composite" : false > }, { > "id" : "8bbb95eb-f5a2-4e4c-ab3a-c914e16e65d1", > "name" : "manage-events", > "description" : "${role_manage-events}", > "scopeParamRequired" : false, > "composite" : false > }, { > "id" : "80098f49-7e94-40f8-8770-3ca980ba392c", > "name" : "impersonation", > "description" : "${role_impersonation}", > "scopeParamRequired" : false, > "composite" : false > }, { > "id" : "e5b8fa6c-8b3a-47c7-b533-3c2ee9033bc3", > "name" : "view-users", > "description" : "${role_view-users}", > "scopeParamRequired" : false, > "composite" : false > }, { > "id" : "a62567b7-03be-4998-be67-60f77c8e9410", > "name" : "view-events", > "description" : "${role_view-events}", > "scopeParamRequired" : false, > "composite" : false > } ], > "account" : [ { > "id" : "6be5d236-0261-4261-a754-9e6de811cc12", > "name" : "view-profile", > "description" : "${role_view-profile}", > "scopeParamRequired" : false, > "composite" : false > }, { > "id" : "f15c3f83-a7ae-4917-9fcd-93afadb03e78", > "name" : "manage-account", > "description" : "${role_manage-account}", > "scopeParamRequired" : false, > "composite" : false > } ] > } > }, > "groups" : [ ], > "defaultRoles" : [ "offline_access" ], > "requiredCredentials" : [ "password" ], > "otpPolicyType" : "totp", > "otpPolicyAlgorithm" : "HmacSHA1", > "otpPolicyInitialCounter" : 0, > "otpPolicyDigits" : 6, > "otpPolicyLookAheadWindow" : 1, > "otpPolicyPeriod" : 30, > "users" : [ { > "id" : "0f1c29f4-0fbc-4ea3-a9c4-f092d7d61012", > "createdTimestamp" : 1462401272607, > "username" : "admin", > "enabled" : true, > "totp" : false, > "emailVerified" : false, > "credentials" : [ { > "type" : "password", > "hashedSaltedValue" : "DEtF8jvm9lKf61SPv+hmE5K1D0G5o/n1GII3qL7Da3F4BNYDtWU9aSczewAlB1xxYavwqgEafZy2wcz8ZbYeaw==", > "salt" : "UQWCsPkHm+o8nkwBjc1IRA==", > "hashIterations" : 1, > "counter" : 0, > "algorithm" : "pbkdf2", > "digits" : 0, > "createdDate" : 1462401272000 > } ], > "requiredActions" : [ ], > "realmRoles" : [ "admin", "offline_access" ], > "clientRoles" : { > "account" : [ "view-profile", "manage-account" ] > }, > "groups" : [ ] > }, { > "id" : "3c97f62a-1138-49d1-b997-2333c90b7ef6", > "createdTimestamp" : 1462427039434, > "username" : "service-account-nodejs-connect", > "enabled" : true, > "totp" : false, > "emailVerified" : false, > "email" : "service-account-nodejs-connect at placeholder.org", > "serviceAccountClientId" : "nodejs-connect", > "credentials" : [ ], > "requiredActions" : [ ], > "realmRoles" : [ "offline_access" ], > "clientRoles" : { > "account" : [ "view-profile", "manage-account" ] > }, > "groups" : [ ] > }, { > "id" : "5e7a87da-8fbf-4f22-9d67-21b58ffe38a0", > "username" : "user", > "enabled" : true, > "totp" : false, > "emailVerified" : false, > "firstName" : "Sample", > "lastName" : "User", > "email" : "sample-user at nodejs-example", > "credentials" : [ { > "type" : "password", > "hashedSaltedValue" : "YAUIoceB1Ghc2KkQ7rtCALitlKEmIGbTWpV26lhaO1TAU1iyw4ScnKMQHRzN1x4Olt+Ki/4YCNIA08lltPzfNg==", > "salt" : "tsZRVBJfaVwRG/+Z4P8f5A==", > "hashIterations" : 1, > "counter" : 0, > "algorithm" : "pbkdf2", > "digits" : 0, > "createdDate" : 1462401722000 > } ], > "requiredActions" : [ ], > "realmRoles" : [ "user" ], > "clientRoles" : { > "account" : [ "view-profile", "manage-account" ] > }, > "groups" : [ ] > } ], > "scopeMappings" : [ { > "client" : "admin-cli", > "roles" : [ "admin" ] > }, { > "client" : "security-admin-console", > "roles" : [ "admin" ] > } ], > "clients" : [ { > "id" : "20eca54a-65e8-497e-8237-1dfe8ebe64e8", > "clientId" : "account", > "name" : "${client_account}", > "baseUrl" : "/auth/realms/master/account", > "surrogateAuthRequired" : false, > "enabled" : true, > "clientAuthenticatorType" : "client-secret", > "secret" : "4b506311-fef9-423b-bf45-5ca0c439eb33", > "defaultRoles" : [ "view-profile", "manage-account" ], > "redirectUris" : [ "/auth/realms/master/account/*" ], > "webOrigins" : [ ], > "notBefore" : 0, > "bearerOnly" : false, > "consentRequired" : false, > "standardFlowEnabled" : true, > "implicitFlowEnabled" : false, > "directAccessGrantsEnabled" : false, > "serviceAccountsEnabled" : false, > "publicClient" : false, > "frontchannelLogout" : false, > "attributes" : { }, > "fullScopeAllowed" : false, > "nodeReRegistrationTimeout" : 0, > "protocolMappers" : [ { > "id" : "59ff8a1b-26cb-4ff5-ba00-c4b2b487378a", > "name" : "full name", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-full-name-mapper", > "consentRequired" : true, > "consentText" : "${fullName}", > "config" : { > "id.token.claim" : "true", > "access.token.claim" : "true" > } > }, { > "id" : "d762d94f-0ec9-42d3-9ec4-b3d1e0f5564a", > "name" : "email", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-usermodel-property-mapper", > "consentRequired" : true, > "consentText" : "${email}", > "config" : { > "user.attribute" : "email", > "id.token.claim" : "true", > "access.token.claim" : "true", > "claim.name" : "email", > "jsonType.label" : "String" > } > }, { > "id" : "528a7748-f9c4-40a6-b09a-eb0a6e1d97f4", > "name" : "given name", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-usermodel-property-mapper", > "consentRequired" : true, > "consentText" : "${givenName}", > "config" : { > "user.attribute" : "firstName", > "id.token.claim" : "true", > "access.token.claim" : "true", > "claim.name" : "given_name", > "jsonType.label" : "String" > } > }, { > "id" : "8c0f6fa8-6042-477d-9ade-81a3a1df5be5", > "name" : "family name", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-usermodel-property-mapper", > "consentRequired" : true, > "consentText" : "${familyName}", > "config" : { > "user.attribute" : "lastName", > "id.token.claim" : "true", > "access.token.claim" : "true", > "claim.name" : "family_name", > "jsonType.label" : "String" > } > }, { > "id" : "7f2b1626-b062-4392-a6a0-1ce233773845", > "name" : "username", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-usermodel-property-mapper", > "consentRequired" : true, > "consentText" : "${username}", > "config" : { > "user.attribute" : "username", > "id.token.claim" : "true", > "access.token.claim" : "true", > "claim.name" : "preferred_username", > "jsonType.label" : "String" > } > }, { > "id" : "b260bf8d-61fb-4744-9a46-b3fb3687aca9", > "name" : "role list", > "protocol" : "saml", > "protocolMapper" : "saml-role-list-mapper", > "consentRequired" : false, > "config" : { > "single" : "false", > "attribute.nameformat" : "Basic", > "attribute.name" : "Role" > } > } ], > "useTemplateConfig" : false, > "useTemplateScope" : false, > "useTemplateMappers" : false > }, { > "id" : "3b52c6fc-9737-4730-94ff-d91a227d1377", > "clientId" : "admin-cli", > "name" : "${client_admin-cli}", > "surrogateAuthRequired" : false, > "enabled" : true, > "clientAuthenticatorType" : "client-secret", > "secret" : "0cf3fa8c-f56c-4a0d-a0d9-937ef1b3cd2d", > "redirectUris" : [ ], > "webOrigins" : [ ], > "notBefore" : 0, > "bearerOnly" : false, > "consentRequired" : false, > "standardFlowEnabled" : false, > "implicitFlowEnabled" : false, > "directAccessGrantsEnabled" : true, > "serviceAccountsEnabled" : false, > "publicClient" : true, > "frontchannelLogout" : false, > "attributes" : { }, > "fullScopeAllowed" : false, > "nodeReRegistrationTimeout" : 0, > "protocolMappers" : [ { > "id" : "48ca850a-f7f9-4099-b062-8c8e46e40e52", > "name" : "role list", > "protocol" : "saml", > "protocolMapper" : "saml-role-list-mapper", > "consentRequired" : false, > "config" : { > "single" : "false", > "attribute.nameformat" : "Basic", > "attribute.name" : "Role" > } > }, { > "id" : "ce882a58-bd9f-49af-8394-7eab6e160476", > "name" : "username", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-usermodel-property-mapper", > "consentRequired" : true, > "consentText" : "${username}", > "config" : { > "user.attribute" : "username", > "id.token.claim" : "true", > "access.token.claim" : "true", > "claim.name" : "preferred_username", > "jsonType.label" : "String" > } > }, { > "id" : "a26be397-b92c-4355-a1bd-f8a6617d090f", > "name" : "given name", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-usermodel-property-mapper", > "consentRequired" : true, > "consentText" : "${givenName}", > "config" : { > "user.attribute" : "firstName", > "id.token.claim" : "true", > "access.token.claim" : "true", > "claim.name" : "given_name", > "jsonType.label" : "String" > } > }, { > "id" : "2d4d48da-e6a9-4478-9e75-8a80c05441cc", > "name" : "family name", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-usermodel-property-mapper", > "consentRequired" : true, > "consentText" : "${familyName}", > "config" : { > "user.attribute" : "lastName", > "id.token.claim" : "true", > "access.token.claim" : "true", > "claim.name" : "family_name", > "jsonType.label" : "String" > } > }, { > "id" : "4ce3cd75-575a-4bc7-8ac2-e13aee05a416", > "name" : "email", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-usermodel-property-mapper", > "consentRequired" : true, > "consentText" : "${email}", > "config" : { > "user.attribute" : "email", > "id.token.claim" : "true", > "access.token.claim" : "true", > "claim.name" : "email", > "jsonType.label" : "String" > } > }, { > "id" : "68e548f1-8d4e-4ef1-8367-df84e06c8703", > "name" : "full name", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-full-name-mapper", > "consentRequired" : true, > "consentText" : "${fullName}", > "config" : { > "id.token.claim" : "true", > "access.token.claim" : "true" > } > } ], > "useTemplateConfig" : false, > "useTemplateScope" : false, > "useTemplateMappers" : false > }, { > "id" : "548a1745-1830-4916-96df-d2ab93f6dfec", > "clientId" : "broker", > "name" : "${client_broker}", > "surrogateAuthRequired" : false, > "enabled" : true, > "clientAuthenticatorType" : "client-secret", > "secret" : "2065aff4-75db-4616-b3a9-3468f553eaaa", > "redirectUris" : [ ], > "webOrigins" : [ ], > "notBefore" : 0, > "bearerOnly" : false, > "consentRequired" : false, > "standardFlowEnabled" : true, > "implicitFlowEnabled" : false, > "directAccessGrantsEnabled" : false, > "serviceAccountsEnabled" : false, > "publicClient" : false, > "frontchannelLogout" : false, > "attributes" : { }, > "fullScopeAllowed" : false, > "nodeReRegistrationTimeout" : 0, > "protocolMappers" : [ { > "id" : "f0705077-1317-47f0-872f-68a5f12f2f5c", > "name" : "role list", > "protocol" : "saml", > "protocolMapper" : "saml-role-list-mapper", > "consentRequired" : false, > "config" : { > "single" : "false", > "attribute.nameformat" : "Basic", > "attribute.name" : "Role" > } > }, { > "id" : "e5179732-4f2c-4740-9b02-dcc241a019c8", > "name" : "full name", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-full-name-mapper", > "consentRequired" : true, > "consentText" : "${fullName}", > "config" : { > "id.token.claim" : "true", > "access.token.claim" : "true" > } > }, { > "id" : "7275a940-6453-4838-be34-b01a12771a84", > "name" : "username", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-usermodel-property-mapper", > "consentRequired" : true, > "consentText" : "${username}", > "config" : { > "user.attribute" : "username", > "id.token.claim" : "true", > "access.token.claim" : "true", > "claim.name" : "preferred_username", > "jsonType.label" : "String" > } > }, { > "id" : "a06b5a15-a645-40f7-9a0a-a0bdf46bab23", > "name" : "email", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-usermodel-property-mapper", > "consentRequired" : true, > "consentText" : "${email}", > "config" : { > "user.attribute" : "email", > "id.token.claim" : "true", > "access.token.claim" : "true", > "claim.name" : "email", > "jsonType.label" : "String" > } > }, { > "id" : "00bd4027-18c0-4e23-9ac4-409b3e10eac2", > "name" : "family name", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-usermodel-property-mapper", > "consentRequired" : true, > "consentText" : "${familyName}", > "config" : { > "user.attribute" : "lastName", > "id.token.claim" : "true", > "access.token.claim" : "true", > "claim.name" : "family_name", > "jsonType.label" : "String" > } > }, { > "id" : "e7503546-4a72-4d28-8c86-1dc51a36bcea", > "name" : "given name", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-usermodel-property-mapper", > "consentRequired" : true, > "consentText" : "${givenName}", > "config" : { > "user.attribute" : "firstName", > "id.token.claim" : "true", > "access.token.claim" : "true", > "claim.name" : "given_name", > "jsonType.label" : "String" > } > } ], > "useTemplateConfig" : false, > "useTemplateScope" : false, > "useTemplateMappers" : false > }, { > "id" : "6083374e-8eef-4082-93d4-743cb5a876eb", > "clientId" : "master-realm", > "name" : "master Realm", > "surrogateAuthRequired" : false, > "enabled" : true, > "clientAuthenticatorType" : "client-secret", > "secret" : "d475d279-adc3-491c-9f85-802c3793fc4f", > "redirectUris" : [ ], > "webOrigins" : [ ], > "notBefore" : 0, > "bearerOnly" : true, > "consentRequired" : false, > "standardFlowEnabled" : true, > "implicitFlowEnabled" : false, > "directAccessGrantsEnabled" : false, > "serviceAccountsEnabled" : false, > "publicClient" : false, > "frontchannelLogout" : false, > "attributes" : { }, > "fullScopeAllowed" : true, > "nodeReRegistrationTimeout" : 0, > "protocolMappers" : [ { > "id" : "8fd60363-8a89-4e10-80ec-30645c539a47", > "name" : "email", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-usermodel-property-mapper", > "consentRequired" : true, > "consentText" : "${email}", > "config" : { > "user.attribute" : "email", > "id.token.claim" : "true", > "access.token.claim" : "true", > "claim.name" : "email", > "jsonType.label" : "String" > } > }, { > "id" : "45638876-65fb-4b19-aff9-e1da0230f401", > "name" : "given name", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-usermodel-property-mapper", > "consentRequired" : true, > "consentText" : "${givenName}", > "config" : { > "user.attribute" : "firstName", > "id.token.claim" : "true", > "access.token.claim" : "true", > "claim.name" : "given_name", > "jsonType.label" : "String" > } > }, { > "id" : "766362b9-e934-41e0-8c79-88a51526cb8b", > "name" : "family name", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-usermodel-property-mapper", > "consentRequired" : true, > "consentText" : "${familyName}", > "config" : { > "user.attribute" : "lastName", > "id.token.claim" : "true", > "access.token.claim" : "true", > "claim.name" : "family_name", > "jsonType.label" : "String" > } > }, { > "id" : "0894502b-4628-4c68-8fe3-0ef4e8f6addc", > "name" : "username", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-usermodel-property-mapper", > "consentRequired" : true, > "consentText" : "${username}", > "config" : { > "user.attribute" : "username", > "id.token.claim" : "true", > "access.token.claim" : "true", > "claim.name" : "preferred_username", > "jsonType.label" : "String" > } > }, { > "id" : "d9952d38-81b9-49ac-8510-1a8a961784e9", > "name" : "role list", > "protocol" : "saml", > "protocolMapper" : "saml-role-list-mapper", > "consentRequired" : false, > "config" : { > "single" : "false", > "attribute.nameformat" : "Basic", > "attribute.name" : "Role" > } > }, { > "id" : "a64419ad-a606-4d21-9e51-1a1f8a2357f9", > "name" : "full name", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-full-name-mapper", > "consentRequired" : true, > "consentText" : "${fullName}", > "config" : { > "id.token.claim" : "true", > "access.token.claim" : "true" > } > } ], > "useTemplateConfig" : false, > "useTemplateScope" : false, > "useTemplateMappers" : false > }, { > "id" : "82dc41d7-0c7e-4545-b92c-89204a5ac667", > "clientId" : "nodejs-connect", > "baseUrl" : "/", > "surrogateAuthRequired" : false, > "enabled" : true, > "clientAuthenticatorType" : "client-secret", > "secret" : "3249d976-7c6c-481d-83e6-c8012904f00a", > "redirectUris" : [ "http://localhost:3000/*" ], > "webOrigins" : [ ], > "notBefore" : 0, > "bearerOnly" : false, > "consentRequired" : false, > "standardFlowEnabled" : true, > "implicitFlowEnabled" : false, > "directAccessGrantsEnabled" : false, > "serviceAccountsEnabled" : false, > "publicClient" : false, > "frontchannelLogout" : false, > "protocol" : "openid-connect", > "attributes" : { > "saml.assertion.signature" : "false", > "saml.force.post.binding" : "false", > "saml.multivalued.roles" : "false", > "saml.encrypt" : "false", > "saml_force_name_id_format" : "false", > "saml.client.signature" : "false", > "saml.authnstatement" : "false", > "saml.server.signature" : "false" > }, > "fullScopeAllowed" : true, > "nodeReRegistrationTimeout" : -1, > "protocolMappers" : [ { > "id" : "a4f6ce65-c190-445b-b3bf-bbea12b11196", > "name" : "username", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-usermodel-property-mapper", > "consentRequired" : true, > "consentText" : "${username}", > "config" : { > "user.attribute" : "username", > "id.token.claim" : "true", > "access.token.claim" : "true", > "claim.name" : "preferred_username", > "jsonType.label" : "String" > } > }, { > "id" : "dff0eeba-06e7-46da-9a4b-9e8359ca628a", > "name" : "given name", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-usermodel-property-mapper", > "consentRequired" : true, > "consentText" : "${givenName}", > "config" : { > "user.attribute" : "firstName", > "id.token.claim" : "true", > "access.token.claim" : "true", > "claim.name" : "given_name", > "jsonType.label" : "String" > } > }, { > "id" : "cb6035d8-c539-450f-ba0c-40a1e99abb34", > "name" : "Client Host", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-usersessionmodel-note-mapper", > "consentRequired" : false, > "consentText" : "", > "config" : { > "user.session.note" : "clientHost", > "id.token.claim" : "true", > "access.token.claim" : "true", > "claim.name" : "clientHost", > "jsonType.label" : "String" > } > }, { > "id" : "597c825b-5853-419c-8dd2-1040eca1a5aa", > "name" : "Client IP Address", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-usersessionmodel-note-mapper", > "consentRequired" : false, > "consentText" : "", > "config" : { > "user.session.note" : "clientAddress", > "id.token.claim" : "true", > "access.token.claim" : "true", > "claim.name" : "clientAddress", > "jsonType.label" : "String" > } > }, { > "id" : "ae5e268c-1839-4daa-9b2c-614557de9877", > "name" : "full name", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-full-name-mapper", > "consentRequired" : true, > "consentText" : "${fullName}", > "config" : { > "id.token.claim" : "true", > "access.token.claim" : "true" > } > }, { > "id" : "4897d589-7df6-4855-bd54-798e8409bcdc", > "name" : "Client ID", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-usersessionmodel-note-mapper", > "consentRequired" : false, > "consentText" : "", > "config" : { > "user.session.note" : "clientId", > "id.token.claim" : "true", > "access.token.claim" : "true", > "claim.name" : "clientId", > "jsonType.label" : "String" > } > }, { > "id" : "7ddba791-0bc9-4e16-bcf6-f9a8fe5e42ad", > "name" : "family name", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-usermodel-property-mapper", > "consentRequired" : true, > "consentText" : "${familyName}", > "config" : { > "user.attribute" : "lastName", > "id.token.claim" : "true", > "access.token.claim" : "true", > "claim.name" : "family_name", > "jsonType.label" : "String" > } > }, { > "id" : "8efe13bf-ed5c-48d5-b508-fedae3b0908d", > "name" : "role list", > "protocol" : "saml", > "protocolMapper" : "saml-role-list-mapper", > "consentRequired" : false, > "config" : { > "single" : "false", > "attribute.nameformat" : "Basic", > "attribute.name" : "Role" > } > }, { > "id" : "8e063cb1-6f62-4772-860e-41e9e9938eda", > "name" : "email", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-usermodel-property-mapper", > "consentRequired" : true, > "consentText" : "${email}", > "config" : { > "user.attribute" : "email", > "id.token.claim" : "true", > "access.token.claim" : "true", > "claim.name" : "email", > "jsonType.label" : "String" > } > } ], > "useTemplateConfig" : false, > "useTemplateScope" : false, > "useTemplateMappers" : false > }, { > "id" : "95275b2b-df98-4f57-831c-f4ff8689684b", > "clientId" : "security-admin-console", > "name" : "${client_security-admin-console}", > "baseUrl" : "/auth/admin/master/console/index.html", > "surrogateAuthRequired" : false, > "enabled" : true, > "clientAuthenticatorType" : "client-secret", > "secret" : "dc0c817c-ffc2-4f22-bfe0-f15e1803ee27", > "redirectUris" : [ "/auth/admin/master/console/*" ], > "webOrigins" : [ ], > "notBefore" : 0, > "bearerOnly" : false, > "consentRequired" : false, > "standardFlowEnabled" : true, > "implicitFlowEnabled" : false, > "directAccessGrantsEnabled" : false, > "serviceAccountsEnabled" : false, > "publicClient" : true, > "frontchannelLogout" : false, > "attributes" : { }, > "fullScopeAllowed" : false, > "nodeReRegistrationTimeout" : 0, > "protocolMappers" : [ { > "id" : "7acf99cc-a1a0-4453-85c5-c5f2e0489cd6", > "name" : "role list", > "protocol" : "saml", > "protocolMapper" : "saml-role-list-mapper", > "consentRequired" : false, > "config" : { > "single" : "false", > "attribute.nameformat" : "Basic", > "attribute.name" : "Role" > } > }, { > "id" : "c66be24c-8fdd-45b9-8d10-100e2d8f9b65", > "name" : "email", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-usermodel-property-mapper", > "consentRequired" : true, > "consentText" : "${email}", > "config" : { > "user.attribute" : "email", > "id.token.claim" : "true", > "access.token.claim" : "true", > "claim.name" : "email", > "jsonType.label" : "String" > } > }, { > "id" : "7a1908f7-fde1-454c-8110-038400a20a5e", > "name" : "family name", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-usermodel-property-mapper", > "consentRequired" : true, > "consentText" : "${familyName}", > "config" : { > "user.attribute" : "lastName", > "id.token.claim" : "true", > "access.token.claim" : "true", > "claim.name" : "family_name", > "jsonType.label" : "String" > } > }, { > "id" : "dc288cdc-346a-4ba5-a8ad-783a8fe86eec", > "name" : "username", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-usermodel-property-mapper", > "consentRequired" : true, > "consentText" : "${username}", > "config" : { > "user.attribute" : "username", > "id.token.claim" : "true", > "access.token.claim" : "true", > "claim.name" : "preferred_username", > "jsonType.label" : "String" > } > }, { > "id" : "53fdf991-5f23-454a-8be2-d5147e59d2bf", > "name" : "locale", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-usermodel-attribute-mapper", > "consentRequired" : false, > "consentText" : "${locale}", > "config" : { > "user.attribute" : "locale", > "id.token.claim" : "true", > "access.token.claim" : "true", > "claim.name" : "locale", > "jsonType.label" : "String" > } > }, { > "id" : "9f85538e-0025-4fee-8550-db028267c129", > "name" : "given name", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-usermodel-property-mapper", > "consentRequired" : true, > "consentText" : "${givenName}", > "config" : { > "user.attribute" : "firstName", > "id.token.claim" : "true", > "access.token.claim" : "true", > "claim.name" : "given_name", > "jsonType.label" : "String" > } > }, { > "id" : "e70a7e6c-4122-41cd-bed9-5e28dd963470", > "name" : "full name", > "protocol" : "openid-connect", > "protocolMapper" : "oidc-full-name-mapper", > "consentRequired" : true, > "consentText" : "${fullName}", > "config" : { > "id.token.claim" : "true", > "access.token.claim" : "true" > } > } ], > "useTemplateConfig" : false, > "useTemplateScope" : false, > "useTemplateMappers" : false > } ], > "clientTemplates" : [ ], > "browserSecurityHeaders" : { > "xFrameOptions" : "SAMEORIGIN", > "contentSecurityPolicy" : "frame-src 'self'" > }, > "smtpServer" : { }, > "eventsEnabled" : false, > "eventsListeners" : [ "jboss-logging" ], > "enabledEventTypes" : [ ], > "adminEventsEnabled" : false, > "adminEventsDetailsEnabled" : false, > "internationalizationEnabled" : false, > "supportedLocales" : [ ], > "authenticationFlows" : [ { > "id" : "2c19b4f5-eec1-4fbc-983e-39aa0a410029", > "alias" : "Handle Existing Account", > "description" : "Handle what to do if there is existing account with same email/username like authenticated identity provider", > "providerId" : "basic-flow", > "topLevel" : false, > "builtIn" : true, > "authenticationExecutions" : [ { > "authenticator" : "idp-confirm-link", > "requirement" : "REQUIRED", > "priority" : 10, > "userSetupAllowed" : false, > "autheticatorFlow" : false > }, { > "authenticator" : "idp-email-verification", > "requirement" : "ALTERNATIVE", > "priority" : 20, > "userSetupAllowed" : false, > "autheticatorFlow" : false > }, { > "requirement" : "ALTERNATIVE", > "priority" : 30, > "flowAlias" : "Verify Existing Account by Re-authentication", > "userSetupAllowed" : false, > "autheticatorFlow" : true > } ] > }, { > "id" : "08e6d4b3-01f6-4be9-8f4a-80b5f21ad39e", > "alias" : "Verify Existing Account by Re-authentication", > "description" : "Reauthentication of existing account", > "providerId" : "basic-flow", > "topLevel" : false, > "builtIn" : true, > "authenticationExecutions" : [ { > "authenticator" : "idp-username-password-form", > "requirement" : "REQUIRED", > "priority" : 10, > "userSetupAllowed" : false, > "autheticatorFlow" : false > }, { > "authenticator" : "auth-otp-form", > "requirement" : "OPTIONAL", > "priority" : 20, > "userSetupAllowed" : false, > "autheticatorFlow" : false > } ] > }, { > "id" : "55e137c5-886f-46fb-bb85-8e0decee3375", > "alias" : "browser", > "description" : "browser based authentication", > "providerId" : "basic-flow", > "topLevel" : true, > "builtIn" : true, > "authenticationExecutions" : [ { > "authenticator" : "auth-cookie", > "requirement" : "ALTERNATIVE", > "priority" : 10, > "userSetupAllowed" : false, > "autheticatorFlow" : false > }, { > "authenticator" : "auth-spnego", > "requirement" : "DISABLED", > "priority" : 20, > "userSetupAllowed" : false, > "autheticatorFlow" : false > }, { > "requirement" : "ALTERNATIVE", > "priority" : 30, > "flowAlias" : "forms", > "userSetupAllowed" : false, > "autheticatorFlow" : true > } ] > }, { > "id" : "daa7f3d6-1365-4377-a29e-ac8a797da11e", > "alias" : "clients", > "description" : "Base authentication for clients", > "providerId" : "client-flow", > "topLevel" : true, > "builtIn" : true, > "authenticationExecutions" : [ { > "authenticator" : "client-secret", > "requirement" : "ALTERNATIVE", > "priority" : 10, > "userSetupAllowed" : false, > "autheticatorFlow" : false > }, { > "authenticator" : "client-jwt", > "requirement" : "ALTERNATIVE", > "priority" : 20, > "userSetupAllowed" : false, > "autheticatorFlow" : false > } ] > }, { > "id" : "bac9fea1-2b7d-4dc9-a15f-3f318efb3d37", > "alias" : "direct grant", > "description" : "OpenID Connect Resource Owner Grant", > "providerId" : "basic-flow", > "topLevel" : true, > "builtIn" : true, > "authenticationExecutions" : [ { > "authenticator" : "direct-grant-validate-username", > "requirement" : "REQUIRED", > "priority" : 10, > "userSetupAllowed" : false, > "autheticatorFlow" : false > }, { > "authenticator" : "direct-grant-validate-password", > "requirement" : "REQUIRED", > "priority" : 20, > "userSetupAllowed" : false, > "autheticatorFlow" : false > }, { > "authenticator" : "direct-grant-validate-otp", > "requirement" : "OPTIONAL", > "priority" : 30, > "userSetupAllowed" : false, > "autheticatorFlow" : false > } ] > }, { > "id" : "96698f70-e399-46f7-857d-61484f7c1128", > "alias" : "first broker login", > "description" : "Actions taken after first broker login with identity provider account, which is not yet linked to any Keycloak account", > "providerId" : "basic-flow", > "topLevel" : true, > "builtIn" : true, > "authenticationExecutions" : [ { > "authenticatorConfig" : "review profile config", > "authenticator" : "idp-review-profile", > "requirement" : "REQUIRED", > "priority" : 10, > "userSetupAllowed" : false, > "autheticatorFlow" : false > }, { > "authenticatorConfig" : "create unique user config", > "authenticator" : "idp-create-user-if-unique", > "requirement" : "ALTERNATIVE", > "priority" : 20, > "userSetupAllowed" : false, > "autheticatorFlow" : false > }, { > "requirement" : "ALTERNATIVE", > "priority" : 30, > "flowAlias" : "Handle Existing Account", > "userSetupAllowed" : false, > "autheticatorFlow" : true > } ] > }, { > "id" : "9ce7531c-0885-45b6-a80d-b739210fdd38", > "alias" : "forms", > "description" : "Username, password, otp and other auth forms.", > "providerId" : "basic-flow", > "topLevel" : false, > "builtIn" : true, > "authenticationExecutions" : [ { > "authenticator" : "auth-username-password-form", > "requirement" : "REQUIRED", > "priority" : 10, > "userSetupAllowed" : false, > "autheticatorFlow" : false > }, { > "authenticator" : "auth-otp-form", > "requirement" : "OPTIONAL", > "priority" : 20, > "userSetupAllowed" : false, > "autheticatorFlow" : false > } ] > }, { > "id" : "00c3a508-4afc-4f78-8bf2-90be8905fc35", > "alias" : "registration", > "description" : "registration flow", > "providerId" : "basic-flow", > "topLevel" : true, > "builtIn" : true, > "authenticationExecutions" : [ { > "authenticator" : "registration-page-form", > "requirement" : "REQUIRED", > "priority" : 10, > "flowAlias" : "registration form", > "userSetupAllowed" : false, > "autheticatorFlow" : true > } ] > }, { > "id" : "d5497eb1-0412-45cb-80bf-7a89f93df6d9", > "alias" : "registration form", > "description" : "registration form", > "providerId" : "form-flow", > "topLevel" : false, > "builtIn" : true, > "authenticationExecutions" : [ { > "authenticator" : "registration-user-creation", > "requirement" : "REQUIRED", > "priority" : 20, > "userSetupAllowed" : false, > "autheticatorFlow" : false > }, { > "authenticator" : "registration-profile-action", > "requirement" : "REQUIRED", > "priority" : 40, > "userSetupAllowed" : false, > "autheticatorFlow" : false > }, { > "authenticator" : "registration-password-action", > "requirement" : "REQUIRED", > "priority" : 50, > "userSetupAllowed" : false, > "autheticatorFlow" : false > }, { > "authenticator" : "registration-recaptcha-action", > "requirement" : "DISABLED", > "priority" : 60, > "userSetupAllowed" : false, > "autheticatorFlow" : false > } ] > }, { > "id" : "9812dc51-c3e2-4850-b868-dec68f54cbc6", > "alias" : "reset credentials", > "description" : "Reset credentials for a user if they forgot their password or something", > "providerId" : "basic-flow", > "topLevel" : true, > "builtIn" : true, > "authenticationExecutions" : [ { > "authenticator" : "reset-credentials-choose-user", > "requirement" : "REQUIRED", > "priority" : 10, > "userSetupAllowed" : false, > "autheticatorFlow" : false > }, { > "authenticator" : "reset-credential-email", > "requirement" : "REQUIRED", > "priority" : 20, > "userSetupAllowed" : false, > "autheticatorFlow" : false > }, { > "authenticator" : "reset-password", > "requirement" : "REQUIRED", > "priority" : 30, > "userSetupAllowed" : false, > "autheticatorFlow" : false > }, { > "authenticator" : "reset-otp", > "requirement" : "OPTIONAL", > "priority" : 40, > "userSetupAllowed" : false, > "autheticatorFlow" : false > } ] > }, { > "id" : "e3d8ca62-d114-475d-a54a-614bab9786d7", > "alias" : "saml ecp", > "description" : "SAML ECP Profile Authentication Flow", > "providerId" : "basic-flow", > "topLevel" : true, > "builtIn" : true, > "authenticationExecutions" : [ { > "authenticator" : "http-basic-authenticator", > "requirement" : "REQUIRED", > "priority" : 10, > "userSetupAllowed" : false, > "autheticatorFlow" : false > } ] > } ], > "authenticatorConfig" : [ { > "alias" : "create unique user config", > "config" : { > "require.password.update.after.registration" : "false" > } > }, { > "alias" : "review profile config", > "config" : { > "update.profile.on.first.login" : "missing" > } > } ], > "requiredActions" : [ { > "alias" : "CONFIGURE_TOTP", > "name" : "Configure Totp", > "providerId" : "CONFIGURE_TOTP", > "enabled" : true, > "defaultAction" : false, > "config" : { } > }, { > "alias" : "UPDATE_PASSWORD", > "name" : "Update Password", > "providerId" : "UPDATE_PASSWORD", > "enabled" : true, > "defaultAction" : false, > "config" : { } > }, { > "alias" : "UPDATE_PROFILE", > "name" : "Update Profile", > "providerId" : "UPDATE_PROFILE", > "enabled" : true, > "defaultAction" : false, > "config" : { } > }, { > "alias" : "VERIFY_EMAIL", > "name" : "Verify Email", > "providerId" : "VERIFY_EMAIL", > "enabled" : true, > "defaultAction" : false, > "config" : { } > }, { > "alias" : "terms_and_conditions", > "name" : "Terms and Conditions", > "providerId" : "terms_and_conditions", > "enabled" : false, > "defaultAction" : false, > "config" : { } > } ], > "browserFlow" : "browser", > "registrationFlow" : "registration", > "directGrantFlow" : "direct grant", > "resetCredentialsFlow" : "reset credentials", > "clientAuthenticationFlow" : "clients" > } ] -- abstractj PGP: 0x84DC9914 From sthorger at redhat.com Fri May 13 08:19:15 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 13 May 2016 14:19:15 +0200 Subject: [keycloak-user] Manually input Realm Keys In-Reply-To: References: Message-ID: Try with openssl. On 13 May 2016 at 11:20, Emanuel Couto wrote: > Still not working, I get the same error. I've sent the steps in attachment. > I'm copying the following keys to "Realm Settings -> Keys" to the > respective input boxes. I'm leaving the certificate box empty. > > *Private Key:* > > MIIEogIBAAKCAQEAsoGXdarRCouoMkJDtZHqnJwdHz6M1e8ZbZmJaP3Fg44oDcg1LIy6w0jqYBKlI9PMYT6FsErxroLJX+2412k/PvZ0zKE9eUQn4/XVMZ6GfpKNA89fhCPwwCfW3Oo+Pv9wO+6a+FTo0yeCGSpGpXrwCbFqlxkZDrhkMAiJfDa0uRx18eFYHoyt5NFxfe4Hih7EUKEX8C0De+q1inawTqkFjFwETBRw+c4KEX2O5L/GJVx+1fXTcaeNvRbGq5kN9IskD1OKu1JH3rF49f036U/g55pSkcB/uWsW9GpUSYbSs6GRBJnbRnP4HfbUqcBepMGdeu1SwjTEKteQoIS1q+LxiwIDAQABAoIBAFqzZlYvmVAWbjw7V1Qm9GLnIBUEH2OEvhLmdN+YMogJ72gxVnNwfmVD43M1hhuSPsMalatiKTNW2SOZEtbBb5V6fRaMx0Oa0foOq2ku93/Qzz4kXJA0AtxgYdiWXVJ9UHXjY3LTEgpYhM5soMDsmpMSRurHoefM4XtWmyU2VtXHOhw/ZCbszOQRJ7fjm2ZOJ3Qj0O3Xo7Q8AJ5CalGNfvieeh8p885s74tBviiBla5k3ZcXZqadUUDFd/HQHYA9f7bSJdmZE/fcayjD1ksdc4KDwaH9srDPpYF16eHYO5KwF9xjCYWptEa4ZVzA5XqAMLI9KCeEFuMjUZP1g+K8FeECgYEA6yfLaP28UphTeDJUc7adJHSUM0VSBiAn2AcIbMkToDfshELwPZf4rcxZG5LDnIRjJ+lDKGIbcIm/IJLeNMfcbtvQtWqVjimPMxVYbi7rO2S5jqKZwUGUOGiRKKtFNZw+q4hDtMxHl3pX8FIswfLMVfIccnx3ht8pQ+SlCMeZrP8CgYEAwlRMe5xNNMLtoaXMC35QmB+diVsNiDL1C0DNIBjhj7gGrjXx1sIL/UeP0jsEJBgFdJlysXjeb1HbYSiwZfrAPHDIcqNfamTm9ljTSlX2kcT/bDg4Y8POdODRLiRAdwe8m4bE/fkeTzsf3CdPsoCHYeZgT1bF9ES+txNV+YVMH3UCgYBVBj5158h/1LPZcdk3PX/z/nLXVukhbd76LRDOxKVj+NR7vfg/TQONU6WkYpx3qyZu99hgcZiaSDPjAzd0vg7lxnTgI3mPvVcZkU44CJ7lCrZM7F3LknqVKrnRipurlqLSQqK4bGQ2UPYa3ptwROm86Z1/h6FwEqBI/BLv6buW4QKBgCni3bFvGT0cHvhOslJv4ZNIjT5EAACxaxwH1a7rbgL6WYZHXl856DepqxhXXCcjflmJka0rLla0QCMLECqLB9B/RtVe3XwjT50dvD0zljgJTDzZSV5HoEKVCsF1UufVJRQo0mEjxyKwzcc4OfdxuLyjWXMAcx6ZiroPUuK7lpLZAoGAWO+bkP9134OdPfsjnXt1hrbMhayKpgkSnN/tZWl9m6oNfpBwMJD11VwKVHBcM+IVZX8Iklv/+pT3+KWTn0DrFlcFc+nRRs/8b78xVJ17Il2mz4P6+IYVLLdA0Bgq7UB6GP4Xxqkbmwkc+SmPERM77V8XP6KfqbSUoCUmqybr4yI= > > *Public Key:* > > MIIBCgKCAQEAsoGXdarRCouoMkJDtZHqnJwdHz6M1e8ZbZmJaP3Fg44oDcg1LIy6w0jqYBKlI9PMYT6FsErxroLJX+2412k/PvZ0zKE9eUQn4/XVMZ6GfpKNA89fhCPwwCfW3Oo+Pv9wO+6a+FTo0yeCGSpGpXrwCbFqlxkZDrhkMAiJfDa0uRx18eFYHoyt5NFxfe4Hih7EUKEX8C0De+q1inawTqkFjFwETBRw+c4KEX2O5L/GJVx+1fXTcaeNvRbGq5kN9IskD1OKu1JH3rF49f036U/g55pSkcB/uWsW9GpUSYbSs6GRBJnbRnP4HfbUqcBepMGdeu1SwjTEKteQoIS1q+LxiwIDAQAB > > Thanks. > > On Fri, May 13, 2016 at 6:48 AM Stian Thorgersen > wrote: > >> Keycloak expects both keys in PEM format. >> >> ssh-keygen writes the private key in PEM format, but not the public key. >> You can create the public key from the private key with ssh-keygen or >> openssl: >> >> ssh-keygen -f mykey -e -m pem >> openssl rsa -in mykey -pubout >> >> >> On 12 May 2016 at 18:46, Emanuel Couto >> wrote: >> >>> Hello >>> >>> I'm trying to manually input keys in a Realm. I tried generating a key >>> pair using 'ssh-keygen': >>> >>> $ ssh-keygen >>> >>> Then I copied the content of 'id_rsa' and 'id_rsa.pub' to the input >>> boxes and pressed "Upload Keys". However an error message is shown "Failed >>> to decode public key". >>> >>> How do I manually input a key pair or certificate? >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160513/af66fbfa/attachment.html From bruno at abstractj.org Fri May 13 08:58:28 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 13 May 2016 09:58:28 -0300 Subject: [keycloak-user] CORS In-Reply-To: <002b01d1ac4d$2588b2f0$709a18d0$@huebinet.de> References: <002b01d1ac4d$2588b2f0$709a18d0$@huebinet.de> Message-ID: <20160513125828.GB8456@abstractj.org> Hi Kevin, have you tried this: https://github.com/keycloak/keycloak/tree/master/examples/cors ? IMO, you don't have to change your standalone.xml get CORS working. On 2016-05-12, Kevin Hirschmann wrote: > Hello, > > > > I have a front-end and one back-end application. For the front-end I entered > the web origin: http://localhost:4000. > > Additionally I added a line true to the > standalone.xml (wildfly 10 / keycloak 1.9.4.Final) > > > > > > The browser console displays: > > The 'Access-Control-Allow-Origin' header contains multiple values > 'http://localhost:4000, http://localhost:4000', but only one is allowed. > Origin 'http://localhost:4000' is therefore not allowed access. > > > > If I remove the line from the client I get: > > localhost/:1 XMLHttpRequest cannot load > http://localhost:8080/auth/realms/... /protocol/openid-connect/token. No > 'Access-Control-Allow-Origin' header is present on the requested resource. > Origin 'http://localhost:4000' is therefore not allowed access. > > > > Has anyone a hint what could cause this? > > > > Thx a lot > > Kevin > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -- abstractj PGP: 0x84DC9914 From amaeztu at tesicnor.com Fri May 13 09:40:01 2016 From: amaeztu at tesicnor.com (Aritz Maeztu) Date: Fri, 13 May 2016 15:40:01 +0200 Subject: [keycloak-user] Browser can't load an external secured resource from a link even if user is already logged in Message-ID: <8611cfe2-085f-9051-f4a9-333aaefe8f38@tesicnor.com> Hi all, We're building a microservice based architecture in which all the services share the SSO point which is a keycloak server. Services are Spring Boot based and we're using the Spring Security keycloak adapter in order to manage our security configuration. We've got some backend services and the one dealing with the frontend, which is based in JSF. ------------------------- --------------------------------- - JSF UI service - ------> - Equipment service - ------------------------- --------------------------------- We can access all the Equipment Service endpoints properly using the KeycloakRestTemplate. Problem comes when JSF renders a direct link to a back end endpoint like that: ``. As our JSF service is being executed in other port, the browser seems not to have access to the image and 401 UNAUTHORIZED code is returned. However, copying the link in the browser bar we can display the image (that's correct because both services are in the same realm and no further security is involved). I've already implemented a solution which implies pointing the src attribute to the JSF UI service and from there, loading the resource using the KeycloakRestTemplate (kind of proxy). But it seems strange for a user not being able to load the resource of the equipment service directly (that could be because no authorization header is sent when the browser requests the extra resources). Is there any other workaround for this? -- Aritz Maeztu Ota?o Departamento Desarrollo de Software Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra) Telf.: 948 21 40 40 Fax.: 948 21 40 41 Antes de imprimir este e-mail piense bien si es necesario hacerlo: El medioambiente es cosa de todos. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160513/cb590a58/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: linkdin.gif Type: image/gif Size: 1295 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160513/cb590a58/attachment-0001.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 2983 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160513/cb590a58/attachment-0001.png From emil.posmyk at gmail.com Fri May 13 10:07:13 2016 From: emil.posmyk at gmail.com (Emil Posmyk) Date: Fri, 13 May 2016 16:07:13 +0200 Subject: [keycloak-user] Keycloak 1.9.4 alternative for method AdapterUtils.getOriginForRestCalls which was in KC 1.4.0.Final Message-ID: Hi all can you help me to find method getOriginForRestCalls from class: AdapterUtils ? Is there any alternative method now and how to use it if it is. Many thanks. *ragards* *--* *Emil Posmyk* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160513/31dd40f6/attachment.html From caitlyn.a.bishop at gmail.com Fri May 13 10:53:22 2016 From: caitlyn.a.bishop at gmail.com (Caitlyn Bishop) Date: Fri, 13 May 2016 10:53:22 -0400 Subject: [keycloak-user] User information (Tomcat Application) Message-ID: I have a tomcat application that I am securing using the standalone Keycloak server. How can I pull out the current user's information? I am assuming it is some sort of REST call to the Keycloak API but I am having trouble to get something to work. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160513/9904043c/attachment.html From jaxley at expedia.com Fri May 13 10:58:53 2016 From: jaxley at expedia.com (Jason Axley) Date: Fri, 13 May 2016 14:58:53 +0000 Subject: [keycloak-user] Two realms; one LDAP; one namespace? Message-ID: Just configured two different realms pointing to the same LDAP directory. Logged into master via LDAP the first time. The second time, logged into another realm with the same user and got an error ?Email already exists.? Shouldn?t the realms be independent of one another? It seems like there is a universal namespace for users that crosses realms. Is that intended? What is the ?Keycloak way? to handle this situation if it?s by design? -Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160513/cbb54a1f/attachment.html From guybowdler at dorsetnetworks.com Fri May 13 11:00:12 2016 From: guybowdler at dorsetnetworks.com (Guy Bowdler) Date: Fri, 13 May 2016 15:00:12 +0000 Subject: [keycloak-user] Keycloak Proxy passing thorugh unauthenticated Message-ID: <14765d5fbe4a7940075dfa715d55d789@dorsetnetworks.com> Hi, We've got the Keycloak Security Proxy (official one - https://keycloak.github.io/docs/userguide/keycloak-server/html/proxy.html) running and passing to an nginx proxy which is in turn proxying out different apps, ie: [client] ----> [:80|443 KeyCloak Proxy ----> :8080 Nginx Reverse Proxy] ------> [application] Where [] denotes a different box, the ProxyBox is hostname.domain and the apps are published as hostname.domain/appname However, the client is able to access the application without authentication, we have clients and roles set up in keycloak and the config looks ok (although obviously isn't!) Are there any KeyCloak Proxy logs we can look at, or debugging options? I haven't found any as yet andnothing is jumping out of the config. We can access the back end apps ok either from the Keycloak proxy running on ports 80 or 443 or via the nginx proxy on 8080 (and yes, this latter connection will be restricted to localhost when it's working!). The keycloak proxy config is very similar to the default except the values from the keycloak installation GUI have been pasted in. Any troubleshooting tips would be much appreciated! thanks in advance:) Guy From jaxley at expedia.com Fri May 13 11:52:17 2016 From: jaxley at expedia.com (Jason Axley) Date: Fri, 13 May 2016 15:52:17 +0000 Subject: [keycloak-user] Keycloak Proxy passing thorugh unauthenticated In-Reply-To: <14765d5fbe4a7940075dfa715d55d789@dorsetnetworks.com> References: <14765d5fbe4a7940075dfa715d55d789@dorsetnetworks.com> Message-ID: <31868C1A-298E-4510-A111-B1198C88A791@expedia.com> >From my read of the design, it doesn?t look like the proxy design provides a secure way of front-ending an application that won?t allow someone with network access behind the proxy to access the application either without authentication or by impersonating any user since the design appears to rely on HTTP headers set with identity information sent to the backend application. A better design would have been to pass the actual Id Token to the backend application so that the backend application can actually verify the identity signature on the JWT so that someone can?t just fabricate arbitrary identity information. I would think this could work in concert with an application plugin that could consume these tokens and validate and make the identity information available to the application in a trustworthy manner. -Jason On 5/13/16, 8:00 AM, "keycloak-user-bounces at lists.jboss.org on behalf of Guy Bowdler" wrote: >Hi, > >We've got the Keycloak Security Proxy (official one - >https://keycloak.github.io/docs/userguide/keycloak-server/html/proxy.html) >running and passing to an nginx proxy which is in turn proxying out >different apps, ie: > >[client] ----> [:80|443 KeyCloak Proxy ----> :8080 Nginx Reverse Proxy] >------> [application] > >Where [] denotes a different box, the ProxyBox is hostname.domain and >the apps are published as hostname.domain/appname > > >However, the client is able to access the application without >authentication, we have clients and roles set up in keycloak and the >config looks ok (although obviously isn't!) > >Are there any KeyCloak Proxy logs we can look at, or debugging options? >I haven't found any as yet andnothing is jumping out of the config. > >We can access the back end apps ok either from the Keycloak proxy >running on ports 80 or 443 or via the nginx proxy on 8080 (and yes, this >latter connection will be restricted to localhost when it's working!). >The keycloak proxy config is very similar to the default except the >values from the keycloak installation GUI have been pasted in. > >Any troubleshooting tips would be much appreciated! > >thanks in advance:) > >Guy > >_______________________________________________ >keycloak-user mailing list >keycloak-user at lists.jboss.org >https://lists.jboss.org/mailman/listinfo/keycloak-user From M.Notarnicola at klopotek.it Fri May 13 11:59:29 2016 From: M.Notarnicola at klopotek.it (Notarnicola, Mara) Date: Fri, 13 May 2016 15:59:29 +0000 Subject: [keycloak-user] Forgotten Pawword information Message-ID: Dear all, I'm using keycloak 1.7.0 final and I have enabled the "Forgotten Password" flow. I would to know if there is a way to avoid the automatic login after the update of the password and redirect the user to the login page. Thank you for reply Mara -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160513/98b4bbab/attachment.html From David.Everson at state.mn.us Fri May 13 14:29:25 2016 From: David.Everson at state.mn.us (Everson, David (MNIT)) Date: Fri, 13 May 2016 18:29:25 +0000 Subject: [keycloak-user] Export/Import Single Client 1.8 Message-ID: <072EABBC7C3CAB46835445106D1029715E5A14@055-CH1MPN1-012.055d.mgd.msft.net> Hi, Our environment still has 1.8 of Keycloak. I understand that in 1.9 import/export features were added in the admin console. Are there recommendations on how to perform an export/import with 1.8 to avoid having to rekey (and perhaps miskey) client configurations from one environment to the next. Any advice would be greatly appreciated. Thanks, Dave Dave Everson | DIVISION OF ENVIRONMENTAL HEALTH MN.IT Services @ mINNESOTA dEPARTMENT OF hEALTH 651-201-5146 (w) | david.everson at state.mn.us [cid:image001.jpg at 01CE4005.70B223E0] Information Technology for Minnesota Government | mn.gov/oet -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160513/0a410dd6/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1712 bytes Desc: image001.jpg Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160513/0a410dd6/attachment-0001.jpg From bburke at redhat.com Fri May 13 14:56:42 2016 From: bburke at redhat.com (Bill Burke) Date: Fri, 13 May 2016 14:56:42 -0400 Subject: [keycloak-user] Export/Import Single Client 1.8 In-Reply-To: <072EABBC7C3CAB46835445106D1029715E5A14@055-CH1MPN1-012.055d.mgd.msft.net> References: <072EABBC7C3CAB46835445106D1029715E5A14@055-CH1MPN1-012.055d.mgd.msft.net> Message-ID: <8846fa84-c27b-c041-43f9-9caefdd7437d@redhat.com> Search the docs for export/import On 5/13/16 2:29 PM, Everson, David (MNIT) wrote: > > Hi, > > Our environment still has 1.8 of Keycloak. I understand that in 1.9 > import/export features were added in the admin console. > > Are there recommendations on how to perform an export/import with 1.8 > to avoid having to rekey (and perhaps miskey) client configurations > from one environment to the next. Any advice would be greatly > appreciated. > > Thanks, > > Dave > > *Dave Everson | * DIVISION OF ENVIRONMENTAL HEALTH > > MN.IT Services @ mINNESOTA dEPARTMENT OF hEALTH > > 651-201-5146 (w) *| * _david.everson at state.mn.us > _ > > /cid:image001.jpg at 01CE4005.70B223E0/ // > > > > Information Technology for Minnesota Government *|* mn.gov/oet > > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160513/d8a39319/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 1712 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160513/d8a39319/attachment.jpe From bburke at redhat.com Fri May 13 14:58:47 2016 From: bburke at redhat.com (Bill Burke) Date: Fri, 13 May 2016 14:58:47 -0400 Subject: [keycloak-user] Keycloak Proxy passing thorugh unauthenticated In-Reply-To: <31868C1A-298E-4510-A111-B1198C88A791@expedia.com> References: <14765d5fbe4a7940075dfa715d55d789@dorsetnetworks.com> <31868C1A-298E-4510-A111-B1198C88A791@expedia.com> Message-ID: The idea of the proxy is that the secured app doesn't have to have a plugin. The secured app is supposed to be on a private network and the proxy sits on a public one. On 5/13/16 11:52 AM, Jason Axley wrote: > From my read of the design, it doesn?t look like the proxy design provides a secure way of front-ending an application that won?t allow someone with network access behind the proxy to access the application either without authentication or by impersonating any user since the design appears to rely on HTTP headers set with identity information sent to the backend application. > > A better design would have been to pass the actual Id Token to the backend application so that the backend application can actually verify the identity signature on the JWT so that someone can?t just fabricate arbitrary identity information. I would think this could work in concert with an application plugin that could consume these tokens and validate and make the identity information available to the application in a trustworthy manner. > > -Jason > > On 5/13/16, 8:00 AM, "keycloak-user-bounces at lists.jboss.org on behalf of Guy Bowdler" wrote: > >> Hi, >> >> We've got the Keycloak Security Proxy (official one - >> https://keycloak.github.io/docs/userguide/keycloak-server/html/proxy.html) >> running and passing to an nginx proxy which is in turn proxying out >> different apps, ie: >> >> [client] ----> [:80|443 KeyCloak Proxy ----> :8080 Nginx Reverse Proxy] >> ------> [application] >> >> Where [] denotes a different box, the ProxyBox is hostname.domain and >> the apps are published as hostname.domain/appname >> >> >> However, the client is able to access the application without >> authentication, we have clients and roles set up in keycloak and the >> config looks ok (although obviously isn't!) >> >> Are there any KeyCloak Proxy logs we can look at, or debugging options? >> I haven't found any as yet andnothing is jumping out of the config. >> >> We can access the back end apps ok either from the Keycloak proxy >> running on ports 80 or 443 or via the nginx proxy on 8080 (and yes, this >> latter connection will be restricted to localhost when it's working!). >> The keycloak proxy config is very similar to the default except the >> values from the keycloak installation GUI have been pasted in. >> >> Any troubleshooting tips would be much appreciated! >> >> thanks in advance:) >> >> Guy >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From guybowdler at dorsetnetworks.com Fri May 13 16:32:04 2016 From: guybowdler at dorsetnetworks.com (Guy Bowdler) Date: Fri, 13 May 2016 21:32:04 +0100 Subject: [keycloak-user] Keycloak Proxy passing thorugh unauthenticated In-Reply-To: References: <14765d5fbe4a7940075dfa715d55d789@dorsetnetworks.com> <31868C1A-298E-4510-A111-B1198C88A791@expedia.com> Message-ID: <4E0789DE-4010-4F0F-8CF8-7DA65B7A1D11@dorsetnetworks.com> The proxy configuration includes all the adapter configuration etc except that in or case the key cloak login page isn't displayed and the client is redirected through both proxies direct to the app without having to authenticate. Something fundamental is a bit skew whiff, trouble is I can't see any output from the key cloak proxy to troubleshoot. On 13 May 2016 19:58:47 BST, Bill Burke wrote: >The idea of the proxy is that the secured app doesn't have to have a >plugin. The secured app is supposed to be on a private network and the > >proxy sits on a public one. > > >On 5/13/16 11:52 AM, Jason Axley wrote: >> From my read of the design, it doesn?t look like the proxy design >provides a secure way of front-ending an application that won?t allow >someone with network access behind the proxy to access the application >either without authentication or by impersonating any user since the >design appears to rely on HTTP headers set with identity information >sent to the backend application. >> >> A better design would have been to pass the actual Id Token to the >backend application so that the backend application can actually verify >the identity signature on the JWT so that someone can?t just fabricate >arbitrary identity information. I would think this could work in >concert with an application plugin that could consume these tokens and >validate and make the identity information available to the application >in a trustworthy manner. >> >> -Jason >> >> On 5/13/16, 8:00 AM, "keycloak-user-bounces at lists.jboss.org on behalf >of Guy Bowdler" guybowdler at dorsetnetworks.com> wrote: >> >>> Hi, >>> >>> We've got the Keycloak Security Proxy (official one - >>> >https://keycloak.github.io/docs/userguide/keycloak-server/html/proxy.html) >>> running and passing to an nginx proxy which is in turn proxying out >>> different apps, ie: >>> >>> [client] ----> [:80|443 KeyCloak Proxy ----> :8080 Nginx Reverse >Proxy] >>> ------> [application] >>> >>> Where [] denotes a different box, the ProxyBox is hostname.domain >and >>> the apps are published as hostname.domain/appname >>> >>> >>> However, the client is able to access the application without >>> authentication, we have clients and roles set up in keycloak and the >>> config looks ok (although obviously isn't!) >>> >>> Are there any KeyCloak Proxy logs we can look at, or debugging >options? >>> I haven't found any as yet andnothing is jumping out of the config. >>> >>> We can access the back end apps ok either from the Keycloak proxy >>> running on ports 80 or 443 or via the nginx proxy on 8080 (and yes, >this >>> latter connection will be restricted to localhost when it's >working!). >>> The keycloak proxy config is very similar to the default except the >>> values from the keycloak installation GUI have been pasted in. >>> >>> Any troubleshooting tips would be much appreciated! >>> >>> thanks in advance:) >>> >>> Guy >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > >_______________________________________________ >keycloak-user mailing list >keycloak-user at lists.jboss.org >https://lists.jboss.org/mailman/listinfo/keycloak-user -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160513/d9b16470/attachment.html From guybowdler at dorsetnetworks.com Fri May 13 16:32:33 2016 From: guybowdler at dorsetnetworks.com (Guy Bowdler) Date: Fri, 13 May 2016 21:32:33 +0100 Subject: [keycloak-user] Keycloak Proxy passing thorugh unauthenticated In-Reply-To: References: <14765d5fbe4a7940075dfa715d55d789@dorsetnetworks.com> <31868C1A-298E-4510-A111-B1198C88A791@expedia.com> Message-ID: <37EA5277-8538-4CAF-A6D2-9B723243C2DC@dorsetnetworks.com> As always, thanks for your replies btw:) On 13 May 2016 19:58:47 BST, Bill Burke wrote: >The idea of the proxy is that the secured app doesn't have to have a >plugin. The secured app is supposed to be on a private network and the > >proxy sits on a public one. > > >On 5/13/16 11:52 AM, Jason Axley wrote: >> From my read of the design, it doesn?t look like the proxy design >provides a secure way of front-ending an application that won?t allow >someone with network access behind the proxy to access the application >either without authentication or by impersonating any user since the >design appears to rely on HTTP headers set with identity information >sent to the backend application. >> >> A better design would have been to pass the actual Id Token to the >backend application so that the backend application can actually verify >the identity signature on the JWT so that someone can?t just fabricate >arbitrary identity information. I would think this could work in >concert with an application plugin that could consume these tokens and >validate and make the identity information available to the application >in a trustworthy manner. >> >> -Jason >> >> On 5/13/16, 8:00 AM, "keycloak-user-bounces at lists.jboss.org on behalf >of Guy Bowdler" guybowdler at dorsetnetworks.com> wrote: >> >>> Hi, >>> >>> We've got the Keycloak Security Proxy (official one - >>> >https://keycloak.github.io/docs/userguide/keycloak-server/html/proxy.html) >>> running and passing to an nginx proxy which is in turn proxying out >>> different apps, ie: >>> >>> [client] ----> [:80|443 KeyCloak Proxy ----> :8080 Nginx Reverse >Proxy] >>> ------> [application] >>> >>> Where [] denotes a different box, the ProxyBox is hostname.domain >and >>> the apps are published as hostname.domain/appname >>> >>> >>> However, the client is able to access the application without >>> authentication, we have clients and roles set up in keycloak and the >>> config looks ok (although obviously isn't!) >>> >>> Are there any KeyCloak Proxy logs we can look at, or debugging >options? >>> I haven't found any as yet andnothing is jumping out of the config. >>> >>> We can access the back end apps ok either from the Keycloak proxy >>> running on ports 80 or 443 or via the nginx proxy on 8080 (and yes, >this >>> latter connection will be restricted to localhost when it's >working!). >>> The keycloak proxy config is very similar to the default except the >>> values from the keycloak installation GUI have been pasted in. >>> >>> Any troubleshooting tips would be much appreciated! >>> >>> thanks in advance:) >>> >>> Guy >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > >_______________________________________________ >keycloak-user mailing list >keycloak-user at lists.jboss.org >https://lists.jboss.org/mailman/listinfo/keycloak-user -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160513/b8b1e140/attachment-0001.html From guybowdler at dorsetnetworks.com Fri May 13 16:33:35 2016 From: guybowdler at dorsetnetworks.com (Guy Bowdler) Date: Fri, 13 May 2016 21:33:35 +0100 Subject: [keycloak-user] Keycloak Proxy passing thorugh unauthenticated In-Reply-To: References: <14765d5fbe4a7940075dfa715d55d789@dorsetnetworks.com> <31868C1A-298E-4510-A111-B1198C88A791@expedia.com> Message-ID: <45D64FAC-4227-4110-9B2F-5A203E0F09D4@dorsetnetworks.com> Also, you just need to configure and back end proxy only to accept connections from the key cloak proxy to secure, we've just left it open for now to troubleshoot On 13 May 2016 19:58:47 BST, Bill Burke wrote: >The idea of the proxy is that the secured app doesn't have to have a >plugin. The secured app is supposed to be on a private network and the > >proxy sits on a public one. > > >On 5/13/16 11:52 AM, Jason Axley wrote: >> From my read of the design, it doesn?t look like the proxy design >provides a secure way of front-ending an application that won?t allow >someone with network access behind the proxy to access the application >either without authentication or by impersonating any user since the >design appears to rely on HTTP headers set with identity information >sent to the backend application. >> >> A better design would have been to pass the actual Id Token to the >backend application so that the backend application can actually verify >the identity signature on the JWT so that someone can?t just fabricate >arbitrary identity information. I would think this could work in >concert with an application plugin that could consume these tokens and >validate and make the identity information available to the application >in a trustworthy manner. >> >> -Jason >> >> On 5/13/16, 8:00 AM, "keycloak-user-bounces at lists.jboss.org on behalf >of Guy Bowdler" guybowdler at dorsetnetworks.com> wrote: >> >>> Hi, >>> >>> We've got the Keycloak Security Proxy (official one - >>> >https://keycloak.github.io/docs/userguide/keycloak-server/html/proxy.html) >>> running and passing to an nginx proxy which is in turn proxying out >>> different apps, ie: >>> >>> [client] ----> [:80|443 KeyCloak Proxy ----> :8080 Nginx Reverse >Proxy] >>> ------> [application] >>> >>> Where [] denotes a different box, the ProxyBox is hostname.domain >and >>> the apps are published as hostname.domain/appname >>> >>> >>> However, the client is able to access the application without >>> authentication, we have clients and roles set up in keycloak and the >>> config looks ok (although obviously isn't!) >>> >>> Are there any KeyCloak Proxy logs we can look at, or debugging >options? >>> I haven't found any as yet andnothing is jumping out of the config. >>> >>> We can access the back end apps ok either from the Keycloak proxy >>> running on ports 80 or 443 or via the nginx proxy on 8080 (and yes, >this >>> latter connection will be restricted to localhost when it's >working!). >>> The keycloak proxy config is very similar to the default except the >>> values from the keycloak installation GUI have been pasted in. >>> >>> Any troubleshooting tips would be much appreciated! >>> >>> thanks in advance:) >>> >>> Guy >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > >_______________________________________________ >keycloak-user mailing list >keycloak-user at lists.jboss.org >https://lists.jboss.org/mailman/listinfo/keycloak-user -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160513/35884f74/attachment.html From bburke at redhat.com Fri May 13 16:49:26 2016 From: bburke at redhat.com (Bill Burke) Date: Fri, 13 May 2016 16:49:26 -0400 Subject: [keycloak-user] Keycloak Proxy passing thorugh unauthenticated In-Reply-To: <45D64FAC-4227-4110-9B2F-5A203E0F09D4@dorsetnetworks.com> References: <14765d5fbe4a7940075dfa715d55d789@dorsetnetworks.com> <31868C1A-298E-4510-A111-B1198C88A791@expedia.com> <45D64FAC-4227-4110-9B2F-5A203E0F09D4@dorsetnetworks.com> Message-ID: <67ac14f4-d29d-ca81-117c-2803ccee3b6b@redhat.com> FYI I haven't touched this code in more than a year and have been relying on the community to maintain it. Why? Well, we're not supporting it in product and Apache plugins like mod-auth-mellon and mod-auth-oidc exist. We're also talking to other teams like API Man to see if we can offload the proxy on them. Anyways, sounds like lame excuses...I know you just want answers... On 5/13/16 4:33 PM, Guy Bowdler wrote: > Also, you just need to configure and back end proxy only to accept > connections from the key cloak proxy to secure, we've just left it > open for now to troubleshoot > > On 13 May 2016 19:58:47 BST, Bill Burke wrote: > > The idea of the proxy is that the secured app doesn't have to have a > plugin. The secured app is supposed to be on a private network and the > proxy sits on a public one. > > > On 5/13/16 11:52 AM, Jason Axley wrote: > > From my read of the design, it doesn?t look like the proxy > design provides a secure way of front-ending an application > that won?t allow someone with network access behind the proxy > to access the application either without authentication or by > impersonating any user since the design appears to rely on > HTTP headers set with identity information sent to the backend > application. A better design would have been to pass the > actual Id Token to the backend application so that the backend > application can actually verify the identity signature on the > JWT so that someone can?t just fabricate arbitrary identity > information. I would think this could work in concert with an > application plugin that could consume these tokens and > validate and make the identity information available to the > application in a trustworthy manner. -Jason On 5/13/16, 8:00 > AM, "keycloak-user-bounces at lists.jboss.org on behalf of Guy > Bowdler" guybowdler at dorsetnetworks.com> wrote: > > Hi, We've got the Keycloak Security Proxy (official one - > https://keycloak.github.io/docs/userguide/keycloak-server/html/proxy.html) > running and passing to an nginx proxy which is in turn > proxying out different apps, ie: [client] ----> [:80|443 > KeyCloak Proxy ----> :8080 Nginx Reverse Proxy] ------> > [application] Where [] denotes a different box, the > ProxyBox is hostname.domain and the apps are published as > hostname.domain/appname However, the client is able to > access the application without authentication, we have > clients and roles set up in keycloak and the config looks > ok (although obviously isn't!) Are there any KeyCloak > Proxy logs we can look at, or debugging options? I haven't > found any as yet andnothing is jumping out of the config. > We can access the back end apps ok either from the > Keycloak proxy running on ports 80 or 443 or via the nginx > proxy on 8080 (and yes, this latter connection will be > restricted to localhost when it's working!). The keycloak > proxy config is very similar to the default except the > values from the keycloak installation GUI have been pasted > in. Any troubleshooting tips would be much > appreciated!thanks in advance:) Guy > ------------------------------------------------------------------------ > keycloak-user mailing list keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > ------------------------------------------------------------------------ > keycloak-user mailing list keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > ------------------------------------------------------------------------ > > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160513/1de60be6/attachment.html From guybowdler at dorsetnetworks.com Fri May 13 17:18:08 2016 From: guybowdler at dorsetnetworks.com (Guy Bowdler) Date: Fri, 13 May 2016 22:18:08 +0100 Subject: [keycloak-user] Export/Import Single Client 1.8 In-Reply-To: <8846fa84-c27b-c041-43f9-9caefdd7437d@redhat.com> References: <072EABBC7C3CAB46835445106D1029715E5A14@055-CH1MPN1-012.055d.mgd.msft.net> <8846fa84-c27b-c041-43f9-9caefdd7437d@redhat.com> Message-ID: Pretty sure I read you gave to start keycloak with a parameter and it will either dump or import the config respectively. Let me know how you get on as when we get it working I will want to try to get it working with a mysql db so will need to do the same! On 13 May 2016 19:56:42 BST, Bill Burke wrote: >Search the docs for export/import > > >On 5/13/16 2:29 PM, Everson, David (MNIT) wrote: >> >> Hi, >> >> Our environment still has 1.8 of Keycloak. I understand that in 1.9 >> import/export features were added in the admin console. >> >> Are there recommendations on how to perform an export/import with 1.8 > >> to avoid having to rekey (and perhaps miskey) client configurations >> from one environment to the next. Any advice would be greatly >> appreciated. >> >> Thanks, >> >> Dave >> >> *Dave Everson | * DIVISION OF ENVIRONMENTAL HEALTH >> >> MN.IT Services @ mINNESOTA dEPARTMENT OF hEALTH >> >> 651-201-5146 (w) *| * _david.everson at state.mn.us >> _ >> >> /cid:image001.jpg at 01CE4005.70B223E0/ // >> >> >> >> Information Technology for Minnesota Government *|* mn.gov/oet >> >> >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > > >------------------------------------------------------------------------ > >_______________________________________________ >keycloak-user mailing list >keycloak-user at lists.jboss.org >https://lists.jboss.org/mailman/listinfo/keycloak-user -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160513/ed7cd954/attachment-0001.html From fuchs at fuchs3.net Sat May 14 16:56:22 2016 From: fuchs at fuchs3.net (Daniel Fuchs) Date: Sat, 14 May 2016 17:56:22 -0300 Subject: [keycloak-user] Captive Portal with Keycloak for Wireless Routers Message-ID: Hi, I?m starting to read about Keycloak and it?s functionalities and I?m wondering how can we make it act as the Captive Portal for our Wireless Network? Since the users will have different services with a customer, Keycloak seems perfect because we can authenticate multiple applications with multiple identity providers aside of having internal registered customers, but one of these services will be the network access. Maybe Keycloak can become a central point in my architecture. Thanks in advance, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160514/4802d828/attachment.html From cpitman at redhat.com Sun May 15 10:39:59 2016 From: cpitman at redhat.com (Chris Pitman) Date: Sun, 15 May 2016 10:39:59 -0400 (EDT) Subject: [keycloak-user] Keycloak Proxy passing thorugh unauthenticated In-Reply-To: <67ac14f4-d29d-ca81-117c-2803ccee3b6b@redhat.com> References: <14765d5fbe4a7940075dfa715d55d789@dorsetnetworks.com> <31868C1A-298E-4510-A111-B1198C88A791@expedia.com> <45D64FAC-4227-4110-9B2F-5A203E0F09D4@dorsetnetworks.com> <67ac14f4-d29d-ca81-117c-2803ccee3b6b@redhat.com> Message-ID: <1768701862.5490276.1463323199855.JavaMail.zimbra@redhat.com> I'm using the proxy in one of my environments and it definitely is requiring authentication. The logs are pretty poor, so debugging is a pain. Two possibilities come to mind: First, are you sure you haven't already authenticated? If you look at the network activity in your browser, are you redirected to keycloak then directed back to your app? Second, have you set constraints in the proxy config? Do those constraints (starting at your configured base path) match the urls you are trying to hit? Bill: As far as I am aware, neither of those httpd modules are supported by us either. A supported option for getting SSO in front of legacy apps is step 1 of getting in the door at clients. If we do end up telling customers to use an apache module, adding generated config for them to the web ui would really help. Chris Pitman Senior Architect, Red Hat Consulting ----- Original Message ----- > > > FYI I haven't touched this code in more than a year and have been relying on > the community to maintain it. Why? Well, we're not supporting it in product > and Apache plugins like mod-auth-mellon and mod-auth-oidc exist. We're also > talking to other teams like API Man to see if we can offload the proxy on > them. Anyways, sounds like lame excuses...I know you just want answers... > > On 5/13/16 4:33 PM, Guy Bowdler wrote: > > > Also, you just need to configure and back end proxy only to accept > connections from the key cloak proxy to secure, we've just left it open for > now to troubleshoot > > On 13 May 2016 19:58:47 BST, Bill Burke wrote: > > > The idea of the proxy is that the secured app doesn't have to have a > plugin. The secured app is supposed to be on a private network and the > proxy sits on a public one. > > > On 5/13/16 11:52 AM, Jason Axley wrote: > > From my read of the design, it doesn?t look like the proxy design provides a > secure way of front-ending an application that won?t allow someone with > network access behind the proxy to access the application either without > authentication or by impersonating any user since the design appears to rely > on HTTP headers set with identity information sent to the backend > application. > > A better design would have been to pass the actual Id Token to the backend > application so that the backend application can actually verify the > identity signature on the JWT so that someone can?t just fabricate > arbitrary identity information. I would think this could work in concert > with an application plugin that could consume these tokens and validate and > make the identity information available to the application in a trustworthy > manner. > > -Jason > > On 5/13/16, 8:00 AM, "keycloak-user-bounces at lists.jboss.org on behalf of Guy > Bowdler" guybowdler at dorsetnetworks.com> wrote: > > Hi, > > We've got the Keycloak Security Proxy (official one - > https://keycloak.github.io/docs/userguide/keycloak-server/html/proxy.html ) > running and passing to an nginx proxy which is in turn proxying out > different apps, ie: > > [client] ----> [:80|443 KeyCloak Proxy ----> :8080 Nginx > Reverse Proxy] > ------> [application] > > Where [] denotes a different box, the ProxyBox is hostname.domain and > the apps are published as hostname.domain/appname > > > However, the client is able to access the application without > authentication, we have clients and roles set up in keycloak and the > config looks ok (although obviously isn't!) > > Are there any KeyCloak Proxy logs we can look at, or debugging options? > I haven't found any as yet andnothing is jumping out of the config. > > We can access the back end apps ok either from the Keycloak proxy > running on ports 80 or 443 or via the nginx proxy on 8080 (and yes, this > latter connection will be restricted to localhost when it's working!). > The keycloak proxy config is very similar to the default except the > values from the keycloak installation GUI have been pasted in. > > Any troubleshooting tips would be much appreciated! thanks in advance:) > > Guy > keycloak-user mailing list keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > keycloak-user mailing list keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > keycloak-user mailing list keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -- Sent from my Android device with K-9 Mail. Please excuse my brevity. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From mosheb at perfectomobile.com Sun May 15 14:59:08 2016 From: mosheb at perfectomobile.com (Moshe Ben-Shoham) Date: Sun, 15 May 2016 18:59:08 +0000 Subject: [keycloak-user] How to secure REST APIs with KeyCloak Message-ID: Hi, I?m trying to figure out the best way to secure REST APIs with KeyCloak. The REST APIs are to be invoked by unattended batch processes that are not KeyCloak clients but end-user scripts. I imagine a process in which the user generates a token using some web app and then uses this token in his scripts in order to authenticate when invoking the REST APIs. So far I have found 2 options, but none of them seems like a very good option: (1) Use offline tokens ? according to the docs, offline token are to be used by KeyCloak clients that need to do things on behalf of the user. In my case, it is the end-user that needs the token and not a client. Should I build a dedicated client that will create the offline tokens and give them to the end-user to use? Is this a misuse for offline tokens? (2) Use Direct Access Grants ? seems like in this option, at least in its simplest form, the user needs to pass username and password to get a token. This means users need to keep their password in their scripts (or scripts configuration) and it is bad practice. In addition, what happens when KeyCloak is configured to be an Identity Broker? In this case KeyCloak does not even know how to handle the user/password. Any help is appreciated! The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160515/e42a0134/attachment.html From guybowdler at dorsetnetworks.com Sun May 15 15:01:43 2016 From: guybowdler at dorsetnetworks.com (Guy Bowdler) Date: Sun, 15 May 2016 20:01:43 +0100 Subject: [keycloak-user] Keycloak Proxy passing thorugh unauthenticated In-Reply-To: <1768701862.5490276.1463323199855.JavaMail.zimbra@redhat.com> References: <14765d5fbe4a7940075dfa715d55d789@dorsetnetworks.com> <31868C1A-298E-4510-A111-B1198C88A791@expedia.com> <45D64FAC-4227-4110-9B2F-5A203E0F09D4@dorsetnetworks.com> <67ac14f4-d29d-ca81-117c-2803ccee3b6b@redhat.com> <1768701862.5490276.1463323199855.JavaMail.zimbra@redhat.com> Message-ID: <72876850-BD35-4B93-8580-9F0CC8297139@dorsetnetworks.com> Thanks for your reply Chris, Good point about the constraints I'll check tomorrow, must admit I'd forgotten all about them, just assumed you'd have to login regardless. So from what you say, there is no currently supported way of getting key cloak to authenticate direct from the proxy. Is this correct? Kind regards Guy On 15 May 2016 15:39:59 BST, Chris Pitman wrote: >I'm using the proxy in one of my environments and it definitely is >requiring authentication. The logs are pretty poor, so debugging is a >pain. > >Two possibilities come to mind: > >First, are you sure you haven't already authenticated? If you look at >the network activity in your browser, are you redirected to keycloak >then directed back to your app? > >Second, have you set constraints in the proxy config? Do those >constraints (starting at your configured base path) match the urls you >are trying to hit? > >Bill: As far as I am aware, neither of those httpd modules are >supported by us either. A supported option for getting SSO in front of >legacy apps is step 1 of getting in the door at clients. If we do end >up telling customers to use an apache module, adding generated config >for them to the web ui would really help. > >Chris Pitman >Senior Architect, Red Hat Consulting > >----- Original Message ----- >> >> >> FYI I haven't touched this code in more than a year and have been >relying on >> the community to maintain it. Why? Well, we're not supporting it in >product >> and Apache plugins like mod-auth-mellon and mod-auth-oidc exist. >We're also >> talking to other teams like API Man to see if we can offload the >proxy on >> them. Anyways, sounds like lame excuses...I know you just want >answers... >> >> On 5/13/16 4:33 PM, Guy Bowdler wrote: >> >> >> Also, you just need to configure and back end proxy only to accept >> connections from the key cloak proxy to secure, we've just left it >open for >> now to troubleshoot >> >> On 13 May 2016 19:58:47 BST, Bill Burke wrote: >> >> >> The idea of the proxy is that the secured app doesn't have to have a >> plugin. The secured app is supposed to be on a private network and >the >> proxy sits on a public one. >> >> >> On 5/13/16 11:52 AM, Jason Axley wrote: >> >> From my read of the design, it doesn?t look like the proxy design >provides a >> secure way of front-ending an application that won?t allow someone >with >> network access behind the proxy to access the application either >without >> authentication or by impersonating any user since the design appears >to rely >> on HTTP headers set with identity information sent to the backend >> application. >> >> A better design would have been to pass the actual Id Token to the >backend >> application so that the backend application can actually verify the >> identity signature on the JWT so that someone can?t just fabricate >> arbitrary identity information. I would think this could work in >concert >> with an application plugin that could consume these tokens and >validate and >> make the identity information available to the application in a >trustworthy >> manner. >> >> -Jason >> >> On 5/13/16, 8:00 AM, "keycloak-user-bounces at lists.jboss.org on >behalf of Guy >> Bowdler" > guybowdler at dorsetnetworks.com> wrote: >> >> Hi, >> >> We've got the Keycloak Security Proxy (official one - >> >https://keycloak.github.io/docs/userguide/keycloak-server/html/proxy.html >) >> running and passing to an nginx proxy which is in turn proxying out >> different apps, ie: >> >> [client] ----> [:80|443 KeyCloak Proxy ----> :8080 Nginx >> Reverse Proxy] >> ------> [application] >> >> Where [] denotes a different box, the ProxyBox is hostname.domain >and >> the apps are published as hostname.domain/appname >> >> >> However, the client is able to access the application without >> authentication, we have clients and roles set up in keycloak and the >> config looks ok (although obviously isn't!) >> >> Are there any KeyCloak Proxy logs we can look at, or debugging >options? >> I haven't found any as yet andnothing is jumping out of the config. >> >> We can access the back end apps ok either from the Keycloak proxy >> running on ports 80 or 443 or via the nginx proxy on 8080 (and yes, >this >> latter connection will be restricted to localhost when it's >working!). >> The keycloak proxy config is very similar to the default except the >> values from the keycloak installation GUI have been pasted in. >> >> Any troubleshooting tips would be much appreciated! thanks in >advance:) >> >> Guy >> keycloak-user mailing list keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> keycloak-user mailing list keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> keycloak-user mailing list keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> -- Sent from my Android device with K-9 Mail. Please excuse my >brevity. >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160515/e885887a/attachment-0001.html From mposolda at redhat.com Mon May 16 02:33:07 2016 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 16 May 2016 08:33:07 +0200 Subject: [keycloak-user] Two realms; one LDAP; one namespace? In-Reply-To: References: Message-ID: <573969A3.3070900@redhat.com> On 13/05/16 16:58, Jason Axley wrote: > > Just configured two different realms pointing to the same LDAP > directory. Logged into master via LDAP the first time. The second > time, logged into another realm with the same user and got an error > ?Email already exists.? > > Shouldn?t the realms be independent of one another? It seems like > there is a universal namespace for users that crosses realms. Is that > intended? What is the ?Keycloak way? to handle this situation if it?s > by design? > yes, realms should be independent on each other. And AFAIK they are. I've just tried the scenario you described and wasn't able to reproduce with steps you provided. I have user "john" successfully imported from same LDAP in both "realm-a" and "realm-b". The fact that you had "Email already exists" in "realm-b" is maybe not related to the fact that you previously logged to "realm-a". You can try to see admin console and list of users in "realm-b" and doublecheck if there is really not a already existing user with the conflicting email. Marek > > -Jason > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160516/1b6a6723/attachment.html From mposolda at redhat.com Mon May 16 02:35:30 2016 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 16 May 2016 08:35:30 +0200 Subject: [keycloak-user] User information (Tomcat Application) In-Reply-To: References: Message-ID: <57396A32.6060906@redhat.com> You can see sources of our examples. For example: https://github.com/keycloak/keycloak/blob/master/examples/demo-template/customer-app/src/main/java/org/keycloak/example/CustomerDatabaseClient.java#L59 Marek On 13/05/16 16:53, Caitlyn Bishop wrote: > I have a tomcat application that I am securing using the standalone > Keycloak server. How can I pull out the current user's information? I > am assuming it is some sort of REST call to the Keycloak API but I am > having trouble to get something to work. > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160516/279a6c7b/attachment.html From mposolda at redhat.com Mon May 16 02:41:03 2016 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 16 May 2016 08:41:03 +0200 Subject: [keycloak-user] Keycloak 1.9.4 alternative for method AdapterUtils.getOriginForRestCalls which was in KC 1.4.0.Final In-Reply-To: References: Message-ID: <57396B7F.5030209@redhat.com> We removed "auth-server-url-for-backend-requests", so it's simplified now. Assuming your UI app and REST service are on same host, you can probably just use: UriUtils.getOrigin(req.getRequestURL().toString()) For example see how our examples were changed: https://github.com/keycloak/keycloak/commit/65dc7ddb4457e3cd6ba8d2488380c7d71ca6bca0#diff-6268b803d6242c4da807bdd5057ee990 Marek On 13/05/16 16:07, Emil Posmyk wrote: > Hi all > > can you help me to find method getOriginForRestCalls from class: > AdapterUtils ? Is there any alternative method now and how to use it > if it is. > > Many thanks. > / > ragards/ > /--/ > /Emil Posmyk > / > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160516/54db4a75/attachment.html From guybowdler at dorsetnetworks.com Mon May 16 09:11:44 2016 From: guybowdler at dorsetnetworks.com (Guy Bowdler) Date: Mon, 16 May 2016 13:11:44 +0000 Subject: [keycloak-user] Keycloak Proxy passing thorugh unauthenticated In-Reply-To: <1768701862.5490276.1463323199855.JavaMail.zimbra@redhat.com> References: <14765d5fbe4a7940075dfa715d55d789@dorsetnetworks.com> <31868C1A-298E-4510-A111-B1198C88A791@expedia.com> <45D64FAC-4227-4110-9B2F-5A203E0F09D4@dorsetnetworks.com> <67ac14f4-d29d-ca81-117c-2803ccee3b6b@redhat.com> <1768701862.5490276.1463323199855.JavaMail.zimbra@redhat.com> Message-ID: <4f681b9cba28c6e390b9bb7a6eafa475@dorsetnetworks.com> Hi Chris, I need to do some tweaking, but basically you were right, I'd neglected to configure the constraints. Now hitting the URL redirects to keycloak and authenticating redirects to the page so thanks very much for the pointer. We'll play around and get used to integrate it. The main concern now is that our idea to make this work is all based on un maintained code Thanks again Guy On 2016-05-15 14:39, Chris Pitman wrote: > I'm using the proxy in one of my environments and it definitely is > requiring authentication. The logs are pretty poor, so debugging is a > pain. > > Two possibilities come to mind: > > First, are you sure you haven't already authenticated? If you look at > the network activity in your browser, are you redirected to keycloak > then directed back to your app? > > Second, have you set constraints in the proxy config? Do those > constraints (starting at your configured base path) match the urls you > are trying to hit? > > Bill: As far as I am aware, neither of those httpd modules are > supported by us either. A supported option for getting SSO in front of > legacy apps is step 1 of getting in the door at clients. If we do end > up telling customers to use an apache module, adding generated config > for them to the web ui would really help. > > Chris Pitman > Senior Architect, Red Hat Consulting > > ----- Original Message ----- >> >> >> FYI I haven't touched this code in more than a year and have been >> relying on >> the community to maintain it. Why? Well, we're not supporting it in >> product >> and Apache plugins like mod-auth-mellon and mod-auth-oidc exist. We're >> also >> talking to other teams like API Man to see if we can offload the proxy >> on >> them. Anyways, sounds like lame excuses...I know you just want >> answers... >> >> On 5/13/16 4:33 PM, Guy Bowdler wrote: >> >> >> Also, you just need to configure and back end proxy only to accept >> connections from the key cloak proxy to secure, we've just left it >> open for >> now to troubleshoot >> >> On 13 May 2016 19:58:47 BST, Bill Burke wrote: >> >> >> The idea of the proxy is that the secured app doesn't have to have a >> plugin. The secured app is supposed to be on a private network and >> the >> proxy sits on a public one. >> >> >> On 5/13/16 11:52 AM, Jason Axley wrote: >> >> From my read of the design, it doesn?t look like the proxy design >> provides a >> secure way of front-ending an application that won?t allow someone >> with >> network access behind the proxy to access the application either >> without >> authentication or by impersonating any user since the design appears >> to rely >> on HTTP headers set with identity information sent to the backend >> application. >> >> A better design would have been to pass the actual Id Token to the >> backend >> application so that the backend application can actually verify the >> identity signature on the JWT so that someone can?t just fabricate >> arbitrary identity information. I would think this could work in >> concert >> with an application plugin that could consume these tokens and >> validate and >> make the identity information available to the application in a >> trustworthy >> manner. >> >> -Jason >> >> On 5/13/16, 8:00 AM, "keycloak-user-bounces at lists.jboss.org on behalf >> of Guy >> Bowdler" > guybowdler at dorsetnetworks.com> wrote: >> >> Hi, >> >> We've got the Keycloak Security Proxy (official one - >> >> https://keycloak.github.io/docs/userguide/keycloak-server/html/proxy.html >> ) >> running and passing to an nginx proxy which is in turn proxying out >> different apps, ie: >> >> [client] ----> [:80|443 KeyCloak Proxy ----> :8080 Nginx >> Reverse Proxy] >> ------> [application] >> >> Where [] denotes a different box, the ProxyBox is hostname.domain and >> the apps are published as hostname.domain/appname >> >> >> However, the client is able to access the application without >> authentication, we have clients and roles set up in keycloak and the >> config looks ok (although obviously isn't!) >> >> Are there any KeyCloak Proxy logs we can look at, or debugging >> options? >> I haven't found any as yet andnothing is jumping out of the config. >> >> We can access the back end apps ok either from the Keycloak proxy >> running on ports 80 or 443 or via the nginx proxy on 8080 (and yes, >> this >> latter connection will be restricted to localhost when it's >> working!). >> The keycloak proxy config is very similar to the default except the >> values from the keycloak installation GUI have been pasted in. >> >> Any troubleshooting tips would be much appreciated! thanks in >> advance:) >> >> Guy >> keycloak-user mailing list keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> keycloak-user mailing list keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> keycloak-user mailing list keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> -- Sent from my Android device with K-9 Mail. Please excuse my >> brevity. >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user From bburke at redhat.com Mon May 16 09:15:04 2016 From: bburke at redhat.com (Bill Burke) Date: Mon, 16 May 2016 09:15:04 -0400 Subject: [keycloak-user] Keycloak Proxy passing thorugh unauthenticated In-Reply-To: <4f681b9cba28c6e390b9bb7a6eafa475@dorsetnetworks.com> References: <14765d5fbe4a7940075dfa715d55d789@dorsetnetworks.com> <31868C1A-298E-4510-A111-B1198C88A791@expedia.com> <45D64FAC-4227-4110-9B2F-5A203E0F09D4@dorsetnetworks.com> <67ac14f4-d29d-ca81-117c-2803ccee3b6b@redhat.com> <1768701862.5490276.1463323199855.JavaMail.zimbra@redhat.com> <4f681b9cba28c6e390b9bb7a6eafa475@dorsetnetworks.com> Message-ID: Again, there is mod-auth-mellon and mod-auth-oidc, but they are apache httpd plugins. On 5/16/16 9:11 AM, Guy Bowdler wrote: > Hi Chris, > > I need to do some tweaking, but basically you were right, I'd > neglected to configure the constraints. Now hitting the URL redirects > to keycloak and authenticating redirects to the page so thanks very > much for the pointer. We'll play around and get used to integrate it. > > The main concern now is that our idea to make this work is all based > on un maintained code > > Thanks again > > Guy > > On 2016-05-15 14:39, Chris Pitman wrote: >> I'm using the proxy in one of my environments and it definitely is >> requiring authentication. The logs are pretty poor, so debugging is a >> pain. >> >> Two possibilities come to mind: >> >> First, are you sure you haven't already authenticated? If you look at >> the network activity in your browser, are you redirected to keycloak >> then directed back to your app? >> >> Second, have you set constraints in the proxy config? Do those >> constraints (starting at your configured base path) match the urls you >> are trying to hit? >> >> Bill: As far as I am aware, neither of those httpd modules are >> supported by us either. A supported option for getting SSO in front of >> legacy apps is step 1 of getting in the door at clients. If we do end >> up telling customers to use an apache module, adding generated config >> for them to the web ui would really help. >> >> Chris Pitman >> Senior Architect, Red Hat Consulting >> >> ----- Original Message ----- >>> >>> >>> FYI I haven't touched this code in more than a year and have been >>> relying on >>> the community to maintain it. Why? Well, we're not supporting it in >>> product >>> and Apache plugins like mod-auth-mellon and mod-auth-oidc exist. >>> We're also >>> talking to other teams like API Man to see if we can offload the >>> proxy on >>> them. Anyways, sounds like lame excuses...I know you just want >>> answers... >>> >>> On 5/13/16 4:33 PM, Guy Bowdler wrote: >>> >>> >>> Also, you just need to configure and back end proxy only to accept >>> connections from the key cloak proxy to secure, we've just left it >>> open for >>> now to troubleshoot >>> >>> On 13 May 2016 19:58:47 BST, Bill Burke wrote: >>> >>> >>> The idea of the proxy is that the secured app doesn't have to have a >>> plugin. The secured app is supposed to be on a private network and the >>> proxy sits on a public one. >>> >>> >>> On 5/13/16 11:52 AM, Jason Axley wrote: >>> >>> From my read of the design, it doesn?t look like the proxy design >>> provides a >>> secure way of front-ending an application that won?t allow someone with >>> network access behind the proxy to access the application either >>> without >>> authentication or by impersonating any user since the design appears >>> to rely >>> on HTTP headers set with identity information sent to the backend >>> application. >>> >>> A better design would have been to pass the actual Id Token to the >>> backend >>> application so that the backend application can actually verify the >>> identity signature on the JWT so that someone can?t just fabricate >>> arbitrary identity information. I would think this could work in >>> concert >>> with an application plugin that could consume these tokens and >>> validate and >>> make the identity information available to the application in a >>> trustworthy >>> manner. >>> >>> -Jason >>> >>> On 5/13/16, 8:00 AM, "keycloak-user-bounces at lists.jboss.org on >>> behalf of Guy >>> Bowdler" >> guybowdler at dorsetnetworks.com> wrote: >>> >>> Hi, >>> >>> We've got the Keycloak Security Proxy (official one - >>> >>> https://keycloak.github.io/docs/userguide/keycloak-server/html/proxy.html >>> ) >>> running and passing to an nginx proxy which is in turn proxying out >>> different apps, ie: >>> >>> [client] ----> [:80|443 KeyCloak Proxy ----> :8080 Nginx >>> Reverse Proxy] >>> ------> [application] >>> >>> Where [] denotes a different box, the ProxyBox is hostname.domain and >>> the apps are published as hostname.domain/appname >>> >>> >>> However, the client is able to access the application without >>> authentication, we have clients and roles set up in keycloak and the >>> config looks ok (although obviously isn't!) >>> >>> Are there any KeyCloak Proxy logs we can look at, or debugging >>> options? >>> I haven't found any as yet andnothing is jumping out of the config. >>> >>> We can access the back end apps ok either from the Keycloak proxy >>> running on ports 80 or 443 or via the nginx proxy on 8080 (and yes, >>> this >>> latter connection will be restricted to localhost when it's working!). >>> The keycloak proxy config is very similar to the default except the >>> values from the keycloak installation GUI have been pasted in. >>> >>> Any troubleshooting tips would be much appreciated! thanks in >>> advance:) >>> >>> Guy >>> keycloak-user mailing list keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> keycloak-user mailing list keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> keycloak-user mailing list keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user From aikeaguinea at xsmail.com Mon May 16 10:28:58 2016 From: aikeaguinea at xsmail.com (Aikeaguinea) Date: Mon, 16 May 2016 10:28:58 -0400 Subject: [keycloak-user] Keycloak as ID provider for large amount of devices In-Reply-To: References: <61D077C6283D454FAFD06F6AC4AB74D723DD53F4@DEFTHW99EZ1MSX.ww931.my-it-solutions.net> Message-ID: <1463408938.3065960.609181441.1F1B1DC0@webmail.messagingengine.com> This is disappointing news, as when I asked this same question back in January the answer was that the intention is to have Keycloak scale to hundreds if not thousands of clients, and if there were issues you'd work with us on that. There's more to this issue than having a custom authenticator; the client interface allows you to click one button and generate the jks file containing the client's private key. We would need this not only for the first time a device is set up, but for key rotation on an ongoing basis. Are there ways to plug into the user management interface to allow generation of non-username/password credentials for a user? On Fri, May 13, 2016, at 02:11 AM, Stian Thorgersen wrote: > Hi, > > That's a very interesting use-case. One which we have wanted to look > into ourselves, but haven't had the resources. Ideally I'd say we'd > have a device concept in Keycloak as they're not strictly clients or > users. They'd most likely be backed by users, but would have different > screens for configuration and would have separate authentication > flows. That would require a fair bit of work to add though. > > In the mean time I don't think clients are a good fit as Keycloak is > not currently designed to have large amounts of clients, both for > manageability and performance. Both of the issues can be overcome > fairly easily, but that would require some work. > > The best solution in my opinion is to use users and implement your own > custom authenticator to handle IOT devices. It's fairly simply to do > and gives you the ability to handle authentication of the devices > exactly how you want to. See > http://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html > for more details. > > I'd appreciate if you kept me updated on your progress as I'm very > interested :) > > On 12 May 2016 at 10:29, Matuszak, Eduard > wrote: >> >> Hello >> >> We are planning to get a lot of devices, identifyable by individual >> certificates, into an IOT-system being designed and developed at the >> moment. We choosed to authenticate all actors (users, software >> components and devices as well) by OIDC-tokens and (pre)decided to >> use Keycloak as ID provider. User and software components are quite >> straightforward to handle with Keycloak (as Keycloak users with the >> help of a user federation provider & id brokerage and for >> applications as Keycloak clients respectively). But I am not sure of >> how to represent our devices (we want to support hundreds of >> thousands of them later on!) by Keycloak means. >> >> It seems that we essentially have 2 possiblities to register a device >> in Keycloak >> * As a user >> * As a client >> >> By representing devices as Keycloak clients we might take advantage >> of the ServiceAccount (Oauth-Client Credential) flow and become able >> to implement it via (dynamic!) registration and it and seems, that we >> will even be able to authenticate our device by their certificates by >> choosing "Signed Jwt" as authenticator option. >> >> My question is, if it would be a good idea to register a very big >> amount of devices as Keycloak clients with regards to performance and >> manageability. In principle I would prefer a user-representation >> (faciliting usage of user federation provider & id brokerage for >> instance), but as far as I understood, the appropriate flow would be >> Direct Access (ResourceOwnerPassword Credentials) and here we can >> only deal with username/password instead of certificates. >> >> Do you have any suggestions or hints (even the conclusion, that >> Keycloak is not the suitable ID-provider-implementation for large- >> scale IOT-systems)? >> >> Best regards, Eduard Matuszak >> >> >> >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > _________________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -- Aikeaguinea aikeaguinea at xsmail.com -- http://www.fastmail.com - Access your email from home and the web -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160516/5491069a/attachment.html From jaxley at expedia.com Mon May 16 12:19:40 2016 From: jaxley at expedia.com (Jason Axley) Date: Mon, 16 May 2016 16:19:40 +0000 Subject: [keycloak-user] Two realms; one LDAP; one namespace? In-Reply-To: <573969A3.3070900@redhat.com> References: <573969A3.3070900@redhat.com> Message-ID: <8C32351D-7DBE-4B76-951F-1666B30CD7A3@expedia.com> You are right ? I found a dummy test account that had the same email address on it. My bad ;-) And it?s still an open issue to support non-unique email addresses on accounts I see: https://issues.jboss.org/browse/KEYCLOAK-2141 -Jason From: Marek Posolda Date: Sunday, May 15, 2016 at 11:33 PM To: Jason Axley , "keycloak-user at lists.jboss.org" Subject: Re: [keycloak-user] Two realms; one LDAP; one namespace? On 13/05/16 16:58, Jason Axley wrote: Just configured two different realms pointing to the same LDAP directory. Logged into master via LDAP the first time. The second time, logged into another realm with the same user and got an error ?Email already exists.? Shouldn?t the realms be independent of one another? It seems like there is a universal namespace for users that crosses realms. Is that intended? What is the ?Keycloak way? to handle this situation if it?s by design? yes, realms should be independent on each other. And AFAIK they are. I've just tried the scenario you described and wasn't able to reproduce with steps you provided. I have user "john" successfully imported from same LDAP in both "realm-a" and "realm-b". The fact that you had "Email already exists" in "realm-b" is maybe not related to the fact that you previously logged to "realm-a". You can try to see admin console and list of users in "realm-b" and doublecheck if there is really not a already existing user with the conflicting email. Marek -Jason _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160516/c46583e3/attachment.html From palermo at pobox.com Mon May 16 12:55:07 2016 From: palermo at pobox.com (Bruno Palermo) Date: Mon, 16 May 2016 13:55:07 -0300 Subject: [keycloak-user] Email format Message-ID: Hi, How can I choose between text and html for the e-mail messages? Also is possible to include some custom fields on the template, such as user first name? Thanks, Bruno -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160516/0513203a/attachment-0001.html From hekonsek at gmail.com Mon May 16 15:37:53 2016 From: hekonsek at gmail.com (Henryk Konsek) Date: Mon, 16 May 2016 19:37:53 +0000 Subject: [keycloak-user] Keycloak as ID provider for large amount of devices In-Reply-To: <1463408938.3065960.609181441.1F1B1DC0@webmail.messagingengine.com> References: <61D077C6283D454FAFD06F6AC4AB74D723DD53F4@DEFTHW99EZ1MSX.ww931.my-it-solutions.net> <1463408938.3065960.609181441.1F1B1DC0@webmail.messagingengine.com> Message-ID: IMHO mapping device per use should be fine. KeyCloak scales well even for hundred of thousands of users, so it will handle gazillion of devices as well. Cheers! pon., 16.05.2016 o 16:29 u?ytkownik Aikeaguinea napisa?: > This is disappointing news, as when I asked this same question back in > January the answer was that the intention is to have Keycloak scale to > hundreds if not thousands of clients, and if there were issues you'd work > with us on that. > > There's more to this issue than having a custom authenticator; the client > interface allows you to click one button and generate the jks file > containing the client's private key. We would need this not only for the > first time a device is set up, but for key rotation on an ongoing basis. > > Are there ways to plug into the user management interface to allow > generation of non-username/password credentials for a user? > > > On Fri, May 13, 2016, at 02:11 AM, Stian Thorgersen wrote: > > Hi, > > That's a very interesting use-case. One which we have wanted to look into > ourselves, but haven't had the resources. Ideally I'd say we'd have a > device concept in Keycloak as they're not strictly clients or users. They'd > most likely be backed by users, but would have different screens for > configuration and would have separate authentication flows. That would > require a fair bit of work to add though. > > In the mean time I don't think clients are a good fit as Keycloak is not > currently designed to have large amounts of clients, both for manageability > and performance. Both of the issues can be overcome fairly easily, but that > would require some work. > > The best solution in my opinion is to use users and implement your own > custom authenticator to handle IOT devices. It's fairly simply to do and > gives you the ability to handle authentication of the devices exactly how > you want to. See > http://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html > for more details. > > I'd appreciate if you kept me updated on your progress as I'm very > interested :) > > On 12 May 2016 at 10:29, Matuszak, Eduard > wrote: > > > Hello > > We are planning to get a lot of devices, identifyable by individual > certificates, into an IOT-system being designed and developed at the > moment. We choosed to authenticate all actors (users, software components > and devices as well) by OIDC-tokens and (pre)decided to use Keycloak as ID > provider. User and software components are quite straightforward to handle > with Keycloak (as Keycloak users with the help of a user federation > provider & id brokerage and for applications as Keycloak clients > respectively). But I am not sure of how to represent our devices (we want > to support hundreds of thousands of them later on!) by Keycloak means. > > It seems that we essentially have 2 possiblities to register a device in > Keycloak > > - As a user > - As a client > > > By representing devices as Keycloak clients we might take advantage of the > ServiceAccount (Oauth-Client Credential) flow and become able to implement > it via (dynamic!) registration and it and seems, that we will even be able > to authenticate our device by their certificates by choosing "Signed Jwt" > as authenticator option. > > My question is, if it would be a good idea to register a very big amount > of devices as Keycloak clients with regards to performance and > manageability. In principle I would prefer a user-representation > (faciliting usage of user federation provider & id brokerage for instance), > but as far as I understood, the appropriate flow would be Direct Access > (ResourceOwnerPassword Credentials) and here we can only deal with > username/password instead of certificates. > > Do you have any suggestions or hints (even the conclusion, that Keycloak > is not the suitable ID-provider-implementation for large-scale IOT-systems)? > > Best regards, Eduard Matuszak > > > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > *_______________________________________________* > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > -- > Aikeaguinea > aikeaguinea at xsmail.com > > > > > -- http://www.fastmail.com - Access your email from home and the web > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -- Henryk Konsek https://linkedin.com/in/hekonsek -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160516/be79e2b3/attachment.html From hr.stoyanov at peruncs.com Mon May 16 15:48:03 2016 From: hr.stoyanov at peruncs.com (Hristo Stoyanov) Date: Mon, 16 May 2016 19:48:03 +0000 Subject: [keycloak-user] (KC1.9.3) admin client issue Message-ID: Hi all, I am seeing some unpredicatble behavior from KC 1.9.3, leading to the following exception (see line comment BOOM!) in the code. Do you see anything that I am doing wrong? The problem with this issue is that it sometimes work, sometimes not. It almost feels like timing issue with the KC internals (cache?) and there is no guaranateed way to reproduce it. Usually restarting the WF10 server or redeploying the app fixes it. Also, can the exception be a bit more helpfull (like what resource is not found?) 12:03:50,354 ERROR [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-81) RESTEASY002010: Failed to execute: javax.ws.rs.NotFoundException: HTTP 404 Not Found at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.handleErrorStatus(ClientInvocation.java:201) at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.extractResult(ClientInvocation.java:174) at org.jboss.resteasy.client.jaxrs.internal.proxy.extractors.BodyEntityExtractor.extractEntity(BodyEntityExtractor.java:59) at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientInvoker.invoke(ClientInvoker.java:104) at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientProxy.invoke(ClientProxy.java:64) at com.sun.proxy.$Proxy296.toRepresentation(Unknown Source) at com.xxxxx.web.server.UserManagerService.updateKeycloakRoles(UserManagerService.java:86) at com.xxxxx.web.server.UserManagerService.changeSubscription(UserManagerService.java:67) ==========================RealmAdmin.java================================ @ApplicationScoped public class RealmAdmin { ... //Use JNDI resources to inject adminUser, adminPassword into this producer bean @Produces Keycloak getKeycloak() { return Keycloak.getInstance(adminUrl, REALM_NAME, adminUser, adminPassword, CLIENT_ID); } } ===========================UserManagerService.java=========================== @Stateless @SecurityDomain("keycloak") public class UserManagerService implements UserManager { @Inject private Keycloak admin; //Producer above is used @Context private HttpServletRequest httpRequest; @Inject private StripeService stripeService; @Override @RolesAllowed({Roles.ACTIVE}) public void changeSubscription(final UserPlanRequest request) { final String userId = httpRequest.getUserPrincipal().getName(); RealmResource realm = admin.realm(RealmAdmin.REALM_NAME); UserResource userResource = realm.users().get(userId); UserRepresentation userRepresentation = userResource.toRepresentation(); Map> userAttributes = userRepresentation.getAttributesAsListValues(); final String customerId = extractKeycloakAttribute(userAttributes, StripeService.STRIPE_ID); final String subscriptionId = extractKeycloakAttribute(userAttributes, StripeService.STRIPE_SUBSCRIPTION_ID); stripeService.changeSubscription(customerId, subscriptionId, JNDIUtils.getPlanStripeKey(request.plan)); updateKeycloakRoles(request.plan, userResource, realm); } private static void updateKeycloakRoles(Plan newPlan, UserResource user, RealmResource realm) { RoleRepresentation newPlanRole = realm.roles().get(newPlan.role.getName()).toRepresentation();//BOOM! RoleScopeResource userRoles = user.roles().realmLevel(); userRoles.remove(userRoles.listAll() .stream() .filter(r -> Roles.isActiveOrExpiredPlanRole(r.getName())) .collect(Collectors.toList())); userRoles.add(Collections.singletonList(newPlanRole)); } } /Hristo Stoyanov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160516/850e94f2/attachment.html From bburke at redhat.com Mon May 16 17:19:36 2016 From: bburke at redhat.com (Bill Burke) Date: Mon, 16 May 2016 17:19:36 -0400 Subject: [keycloak-user] Keycloak as ID provider for large amount of devices In-Reply-To: References: <61D077C6283D454FAFD06F6AC4AB74D723DD53F4@DEFTHW99EZ1MSX.ww931.my-it-solutions.net> <1463408938.3065960.609181441.1F1B1DC0@webmail.messagingengine.com> Message-ID: <260b7be4-20e7-6a9c-c9f0-4d83576d3680@redhat.com> I think the only thing that doesn't scale very well as it pertains to number of clients is logout. Logout for OIDC requires a redirect uri. We validate this uri by iterating over every client's register register uri patterns. We don't have any services on key rotation. That's all something you'd have to implement yourself. On 5/16/16 3:37 PM, Henryk Konsek wrote: > IMHO mapping device per use should be fine. KeyCloak scales well even > for hundred of thousands of users, so it will handle gazillion of > devices as well. > > Cheers! > > pon., 16.05.2016 o 16:29 u?ytkownik Aikeaguinea > > napisa?: > > This is disappointing news, as when I asked this same question > back in January the answer was that the intention is to have > Keycloak scale to hundreds if not thousands of clients, and if > there were issues you'd work with us on that. > There's more to this issue than having a custom authenticator; the > client interface allows you to click one button and generate the > jks file containing the client's private key. We would need this > not only for the first time a device is set up, but for key > rotation on an ongoing basis. > Are there ways to plug into the user management interface to allow > generation of non-username/password credentials for a user? > On Fri, May 13, 2016, at 02:11 AM, Stian Thorgersen wrote: >> Hi, >> That's a very interesting use-case. One which we have wanted to >> look into ourselves, but haven't had the resources. Ideally I'd >> say we'd have a device concept in Keycloak as they're not >> strictly clients or users. They'd most likely be backed by users, >> but would have different screens for configuration and would have >> separate authentication flows. That would require a fair bit of >> work to add though. >> In the mean time I don't think clients are a good fit as Keycloak >> is not currently designed to have large amounts of clients, both >> for manageability and performance. Both of the issues can be >> overcome fairly easily, but that would require some work. >> The best solution in my opinion is to use users and implement >> your own custom authenticator to handle IOT devices. It's fairly >> simply to do and gives you the ability to handle authentication >> of the devices exactly how you want to. See >> http://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html >> for more details. >> I'd appreciate if you kept me updated on your progress as I'm >> very interested :) >> On 12 May 2016 at 10:29, Matuszak, Eduard >> > wrote: >> >> Hello >> >> We are planning to get a lot of devices, identifyable by >> individual certificates, into an IOT-system being designed >> and developed at the moment. We choosed to authenticate all >> actors (users, software components and devices as well) by >> OIDC-tokens and (pre)decided to use Keycloak as ID provider. >> User and software components are quite straightforward to >> handle with Keycloak (as Keycloak users with the help of a >> user federation provider & id brokerage and for applications >> as Keycloak clients respectively). But I am not sure of how >> to represent our devices (we want to support hundreds of >> thousands of them later on!) by Keycloak means. >> >> It seems that we essentially have 2 possiblities to register >> a device in Keycloak >> >> * As a user >> * As a client >> >> >> By representing devices as Keycloak clients we might take >> advantage of the ServiceAccount (Oauth-Client Credential) >> flow and become able to implement it via (dynamic!) >> registration and it and seems, that we will even be able to >> authenticate our device by their certificates by choosing >> "Signed Jwt" as authenticator option. >> >> My question is, if it would be a good idea to register a very >> big amount of devices as Keycloak clients with regards to >> performance and manageability. In principle I would prefer a >> user-representation (faciliting usage of user federation >> provider & id brokerage for instance), but as far as I >> understood, the appropriate flow would be Direct Access >> (ResourceOwnerPassword Credentials) and here we can only deal >> with username/password instead of certificates. >> >> Do you have any suggestions or hints (even the conclusion, >> that Keycloak is not the suitable ID-provider-implementation >> for large-scale IOT-systems)? >> >> Best regards, Eduard Matuszak >> >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> _________________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > -- > Aikeaguinea > aikeaguinea at xsmail.com > > -- > http://www.fastmail.com - Access your email from home and the web > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > -- > Henryk Konsek > https://linkedin.com/in/hekonsek > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160516/f4aeeab9/attachment-0001.html From imbacen at gmail.com Mon May 16 17:37:21 2016 From: imbacen at gmail.com (cen) Date: Mon, 16 May 2016 23:37:21 +0200 Subject: [keycloak-user] ENV in keycloak.json does not seem to be working, base64 errors Message-ID: <79d79246-f3da-2965-1880-2d4dc4562a81@gmail.com> Hi I am trying to use env vars in keycloak.json but I am getting base64 errors. My keycloak.json: { "realm": "myrealm", "realm-public-key": "${env.KC_REALM_PUBLIC_KEY}", "auth-server-url": "${env.KC_AUTH_SERVER_URL}", "ssl-required": "none", "resource": "myrealm", "public-client": true } I am deploying my ear to WildFly 10 using the following properties: Error on deploy: Bad Base64 input character decimal 36 in array position 0.. (char 36 is $) It seems that KC wants to parse the value as string instead of trying to resolve the env variable. Looking through the code and commits (https://issues.jboss.org/browse/KEYCLOAK-1289) this should work. What am I doing wrong? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160516/12e6458e/attachment.bin From pavel.masloff at gmail.com Tue May 17 08:26:09 2016 From: pavel.masloff at gmail.com (Pavel Maslov) Date: Tue, 17 May 2016 14:26:09 +0200 Subject: [keycloak-user] Securing 3rd party APIs Message-ID: Hi all, Suppose we have a 3rd party REST API, which is not secured. How could we integrate OAuth2.0 authentication using Keycloak? My first guess is to create a mediation service (written in Java), which will use the Keycloak Java adapter and will authenticate users based off the security_token (passed to the mediation service with each request), and forward all requests (including headers) to the 3rd party REST API (unsecured). Does it make any sense? If so, has anyone written something similar? Thanks. Regards, Pavel Maslov, MS -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160517/43c4b7a0/attachment.html From Jitendra.Biswal at majesco.com Tue May 17 09:25:24 2016 From: Jitendra.Biswal at majesco.com (Jitendra P Biswal) Date: Tue, 17 May 2016 13:25:24 +0000 Subject: [keycloak-user] SQL Server 2014 DB throws error at time of user hetch Message-ID: <922da49bb89e4ecda8a1207d49a7a77a@ind-mhp1mbx1301.mastek.com> Hi All, I am using keycloak-1.9.0.Final version and configured it to point SQL Server 2014. I was able to create new realm and create user under the realm But, when I am click on view all users getting error. Server log attached. Anybody have any solution please help. Thanks & Regards, [Description: cid:image001.jpg at 01D065A7.375670A0] Jitendra Biswal / Software Specialist Majesco, Majesco New Development Centre, MBP-P-136,136A, Mahape, Navi Mumbai - 400 710 Phone: +91 22 6150 1800 Ext 5698 http://www.majesco.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160517/57876e8d/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 19294 bytes Desc: image001.jpg Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160517/57876e8d/attachment-0001.jpg -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: server.txt Url: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160517/57876e8d/attachment-0001.txt From vramik at redhat.com Tue May 17 09:31:05 2016 From: vramik at redhat.com (Vlasta Ramik) Date: Tue, 17 May 2016 15:31:05 +0200 Subject: [keycloak-user] SQL Server 2014 DB throws error at time of user hetch In-Reply-To: <922da49bb89e4ecda8a1207d49a7a77a@ind-mhp1mbx1301.mastek.com> References: <922da49bb89e4ecda8a1207d49a7a77a@ind-mhp1mbx1301.mastek.com> Message-ID: <573B1D19.3060809@redhat.com> Hi Jitendra, the issue is fixed in 1.9.2.Final. see https://github.com/keycloak/keycloak/pull/2352/files The cause is that Hibernate doesn't detect correct dialect for MSSQL2014, which is causing some incorrectly generated SQL queries. In 1.9.2.Final is auto-detected dialect overridden. Vlasta On 05/17/2016 03:25 PM, Jitendra P Biswal wrote: > > Hi All, > > I am using keycloak-1.9.0.Final version and configured it to point > *SQL Server 2014.* > > I was able to create new realm and create user under the realm > > But, when I am click on view all users getting error. Server log attached. > > Anybody have any solution please help. > > Thanks & Regards, > > Description: cid:image001.jpg at 01D065A7.375670A0 > > Jitendra Biswal/ Software Specialist > > *Majesco,*Majesco New Development Centre, MBP-P?136,136A, Mahape,Navi > Mumbai - 400 710 > Phone: +91 22 6150 1800 Ext 5698 > http://www.majesco.com > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160517/252ed4e7/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 19294 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160517/252ed4e7/attachment-0001.jpe From vramik at redhat.com Tue May 17 09:33:43 2016 From: vramik at redhat.com (Vlasta Ramik) Date: Tue, 17 May 2016 15:33:43 +0200 Subject: [keycloak-user] SQL Server 2014 DB throws error at time of user hetch In-Reply-To: <573B1D19.3060809@redhat.com> References: <922da49bb89e4ecda8a1207d49a7a77a@ind-mhp1mbx1301.mastek.com> <573B1D19.3060809@redhat.com> Message-ID: <573B1DB7.20308@redhat.com> One more note. In wildfly, the dialect can be set in $KEYCLOAK_HOME/standalone/configuration/keycloak-server.json like: "connectionsJpa": { "default": { "driverDialect": "org.hibernate.dialect.SQLServer2012Dialect", "dataSource": "java:jboss/datasources/KeycloakDS", ... } }, On 05/17/2016 03:31 PM, Vlasta Ramik wrote: > Hi Jitendra, > > the issue is fixed in 1.9.2.Final. > > see https://github.com/keycloak/keycloak/pull/2352/files > > The cause is that Hibernate doesn't detect correct dialect for > MSSQL2014, which is causing some incorrectly generated SQL queries. In > 1.9.2.Final is auto-detected dialect overridden. > > Vlasta > > On 05/17/2016 03:25 PM, Jitendra P Biswal wrote: >> >> Hi All, >> >> I am using keycloak-1.9.0.Final version and configured it to point >> *SQL Server 2014.* >> >> I was able to create new realm and create user under the realm >> >> But, when I am click on view all users getting error. Server log >> attached. >> >> Anybody have any solution please help. >> >> Thanks & Regards, >> >> Description: cid:image001.jpg at 01D065A7.375670A0 >> >> Jitendra Biswal/ Software Specialist >> >> *Majesco,*Majesco New Development Centre, MBP-P?136,136A, Mahape,Navi >> Mumbai - 400 710 >> Phone: +91 22 6150 1800 Ext 5698 >> http://www.majesco.com >> >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160517/b940e6d3/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/jpeg Size: 19294 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160517/b940e6d3/attachment-0001.jpe From jfalkner at redhat.com Tue May 17 09:37:04 2016 From: jfalkner at redhat.com (James Falkner) Date: Tue, 17 May 2016 09:37:04 -0400 Subject: [keycloak-user] Using EAP 7 exclusively Message-ID: <573B1E80.9080403@redhat.com> All, I'm hoping to setup an environment using only EAP 7 as the container for both Keycloak and my applications, on OpenShift 3. I noticed during the Commons Briefing last month they were using several templates and images that were EAP 7 based (although I never saw any log file output verifying this). Are there templates, imagestreams, and s2i builder images for Keycloak applications on EAP 7 (not EAP 6.x)? I searched around for anything like eap70-sso-s2i and found nothing except what was shown in the demo. I'd like to not have to do any Docker-based builds, and only use OpenShift objects, if they exist. Thanks! -James From aikeaguinea at xsmail.com Tue May 17 09:53:55 2016 From: aikeaguinea at xsmail.com (Aikeaguinea) Date: Tue, 17 May 2016 09:53:55 -0400 Subject: [keycloak-user] Keycloak as ID provider for large amount of devices In-Reply-To: <260b7be4-20e7-6a9c-c9f0-4d83576d3680@redhat.com> References: <61D077C6283D454FAFD06F6AC4AB74D723DD53F4@DEFTHW99EZ1MSX.ww931.my-it-solutions.net> <1463408938.3065960.609181441.1F1B1DC0@webmail.messagingengine.com> <260b7be4-20e7-6a9c-c9f0-4d83576d3680@redhat.com> Message-ID: <1463493235.3334646.610310569.147B85A0@webmail.messagingengine.com> Would only the logout request experience significant delay, or would logging out significantly slow down the entire system when there is a large number of clients? We can probably work with a long logout time per device. With regard to key rotation, we're initially planning on using the UI to generate new credentials when we need new keys. But couldn't we automate this by calling?/admin/realms/{realm}/clients/{id}/certificates/{attr}/generate-and- download ? On Mon, May 16, 2016, at 05:19 PM, Bill Burke wrote: > I think the only thing that doesn't scale very well as it pertains to > number of clients is logout.? Logout for OIDC requires a redirect uri. > We validate this uri by iterating over every client's register > register uri patterns. > We don't have any services on key rotation.? That's all something > you'd have to implement yourself. > > On 5/16/16 3:37 PM, Henryk Konsek wrote: >> IMHO mapping device per use should be fine. KeyCloak scales well even >> for hundred of thousands of users, so it will handle gazillion of >> devices as well. >> >> Cheers! >> >> pon., 16.05.2016 o 16:29?u?ytkownik Aikeaguinea >> napisa?: >>> This is disappointing news, as when I asked this same question back >>> in January the answer was that the intention is to have Keycloak >>> scale to hundreds if not thousands of clients, and if there were >>> issues you'd work with us on that. >>> >>> There's more to this issue than having a custom authenticator; the >>> client interface allows you to click one button and generate the jks >>> file containing the client's private key. We would need this not >>> only for the first time a device is set up, but for key rotation on >>> an ongoing basis. >>> >>> Are there ways to plug into the user management interface to allow >>> generation of non-username/password credentials for a user? >>> >>> >>> On Fri, May 13, 2016, at 02:11 AM, Stian Thorgersen wrote: >>>> Hi, >>>> >>>> That's a very interesting use-case. One which we have wanted to >>>> look into ourselves, but haven't had the resources. Ideally I'd say >>>> we'd have a device concept in Keycloak as they're not strictly >>>> clients or users. They'd most likely be backed by users, but would >>>> have different screens for configuration and would have separate >>>> authentication flows. That would require a fair bit of work to add >>>> though. >>>> >>>> In the mean time I don't think clients are a good fit as Keycloak >>>> is not currently designed to have large amounts of clients, both >>>> for manageability and performance. Both of the issues can be >>>> overcome fairly easily, but that would require some work. >>>> >>>> The best solution in my opinion is to use users and implement your >>>> own custom authenticator to handle IOT devices. It's fairly simply >>>> to do and gives you the ability to handle authentication of the >>>> devices exactly how you want to. See >>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html >>>> for more details. >>>> >>>> I'd appreciate if you kept me updated on your progress as I'm very >>>> interested :) >>>> >>>> On 12 May 2016 at 10:29, Matuszak, Eduard >>>> wrote: >>>>> >>>>> Hello >>>>> >>>>> We are planning to get a lot of devices, identifyable by >>>>> individual certificates, into an IOT-system being designed and >>>>> developed at the moment. We choosed to authenticate all actors >>>>> (users, software components and devices as well) by OIDC-tokens >>>>> and (pre)decided to use Keycloak as ID provider. User and software >>>>> components are quite straightforward to handle with Keycloak (as >>>>> Keycloak users with the help of a user federation provider & id >>>>> brokerage and for applications as Keycloak clients respectively). >>>>> But I am not sure of how to represent our devices (we want to >>>>> support hundreds of thousands of them later on!) by Keycloak >>>>> means. >>>>> >>>>> It seems that we essentially have 2 possiblities to register a >>>>> device in Keycloak >>>>> * As a user >>>>> * As a client >>>>> >>>>> By representing devices as Keycloak clients we might take >>>>> advantage of the ServiceAccount (Oauth-Client Credential) flow and >>>>> become able to implement it via (dynamic!) registration and it and >>>>> seems, that we will even be able to authenticate our device by >>>>> their certificates by choosing "Signed Jwt" as authenticator >>>>> option. >>>>> >>>>> My question is, if it would be a good idea to register a very big >>>>> amount of devices as Keycloak clients with regards to performance >>>>> and manageability. In principle I would prefer a user- >>>>> representation (faciliting usage of user federation provider & id >>>>> brokerage for instance), but as far as I understood, the >>>>> appropriate flow would be Direct Access (ResourceOwnerPassword >>>>> Credentials) and here we can only deal with username/password >>>>> instead of certificates. >>>>> >>>>> Do you have any suggestions or hints (even the conclusion, that >>>>> Keycloak is not the suitable ID-provider-implementation for large- >>>>> scale IOT-systems)? >>>>> >>>>> Best regards, Eduard Matuszak >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> keycloak-user mailing list >>>>> keycloak-user at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>> _________________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >>> -- >>> Aikeaguinea >>> aikeaguinea at xsmail.com >>> >>> >>> -- >>> http://www.fastmail.com - Access your email from home and the web >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >> -- >> Henryk Konsek >> https://linkedin.com/in/hekonsek >> >> >> _______________________________________________ keycloak-user mailing >> list keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > _________________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -- Aikeaguinea aikeaguinea at xsmail.com -- http://www.fastmail.com - Or how I learned to stop worrying and love email again -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160517/df850d14/attachment.html From bburke at redhat.com Tue May 17 10:23:45 2016 From: bburke at redhat.com (Bill Burke) Date: Tue, 17 May 2016 10:23:45 -0400 Subject: [keycloak-user] Keycloak as ID provider for large amount of devices In-Reply-To: <1463493235.3334646.610310569.147B85A0@webmail.messagingengine.com> References: <61D077C6283D454FAFD06F6AC4AB74D723DD53F4@DEFTHW99EZ1MSX.ww931.my-it-solutions.net> <1463408938.3065960.609181441.1F1B1DC0@webmail.messagingengine.com> <260b7be4-20e7-6a9c-c9f0-4d83576d3680@redhat.com> <1463493235.3334646.610310569.147B85A0@webmail.messagingengine.com> Message-ID: <34ca9eb3-484a-4271-1843-72feef558c1e@redhat.com> I don't know how much performance would be hurt on logout with a large number of clients. Sounds like you have a way to handle things. Maybe blog about it? :) On 5/17/16 9:53 AM, Aikeaguinea wrote: > Would only the logout request experience significant delay, or would > logging out significantly slow down the entire system when there is a > large number of clients? We can probably work with a long logout time > per device. > With regard to key rotation, we're initially planning on using the UI > to generate new credentials when we need new keys. But couldn't we > automate this by > calling /admin/realms/{realm}/clients/{id}/certificates/{attr}/generate-and-download > ? > On Mon, May 16, 2016, at 05:19 PM, Bill Burke wrote: >> >> I think the only thing that doesn't scale very well as it pertains to >> number of clients is logout. Logout for OIDC requires a redirect >> uri. We validate this uri by iterating over every client's register >> register uri patterns. >> >> We don't have any services on key rotation. That's all something >> you'd have to implement yourself. >> >> On 5/16/16 3:37 PM, Henryk Konsek wrote: >>> IMHO mapping device per use should be fine. KeyCloak scales well >>> even for hundred of thousands of users, so it will handle gazillion >>> of devices as well. >>> Cheers! >>> pon., 16.05.2016 o 16:29 u?ytkownik Aikeaguinea >>> > napisa?: >>> >>> This is disappointing news, as when I asked this same question >>> back in January the answer was that the intention is to have >>> Keycloak scale to hundreds if not thousands of clients, and if >>> there were issues you'd work with us on that. >>> >>> There's more to this issue than having a custom authenticator; >>> the client interface allows you to click one button and generate >>> the jks file containing the client's private key. We would need >>> this not only for the first time a device is set up, but for key >>> rotation on an ongoing basis. >>> >>> Are there ways to plug into the user management interface to >>> allow generation of non-username/password credentials for a user? >>> >>> >>> On Fri, May 13, 2016, at 02:11 AM, Stian Thorgersen wrote: >>>> Hi, >>>> >>>> That's a very interesting use-case. One which we have wanted to >>>> look into ourselves, but haven't had the resources. Ideally I'd >>>> say we'd have a device concept in Keycloak as they're not >>>> strictly clients or users. They'd most likely be backed by >>>> users, but would have different screens for configuration and >>>> would have separate authentication flows. That would require a >>>> fair bit of work to add though. >>>> >>>> In the mean time I don't think clients are a good fit as >>>> Keycloak is not currently designed to have large amounts of >>>> clients, both for manageability and performance. Both of the >>>> issues can be overcome fairly easily, but that would require >>>> some work. >>>> >>>> The best solution in my opinion is to use users and implement >>>> your own custom authenticator to handle IOT devices. It's >>>> fairly simply to do and gives you the ability to handle >>>> authentication of the devices exactly how you want to. See >>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html >>>> for more details. >>>> >>>> I'd appreciate if you kept me updated on your progress as I'm >>>> very interested :) >>>> >>>> On 12 May 2016 at 10:29, Matuszak, Eduard >>>> > wrote: >>>> >>>> >>>> Hello >>>> >>>> We are planning to get a lot of devices, identifyable by >>>> individual certificates, into an IOT-system being designed >>>> and developed at the moment. We choosed to authenticate all >>>> actors (users, software components and devices as well) by >>>> OIDC-tokens and (pre)decided to use Keycloak as ID >>>> provider. User and software components are quite >>>> straightforward to handle with Keycloak (as Keycloak users >>>> with the help of a user federation provider & id brokerage >>>> and for applications as Keycloak clients respectively). But >>>> I am not sure of how to represent our devices (we want to >>>> support hundreds of thousands of them later on!) by >>>> Keycloak means. >>>> >>>> It seems that we essentially have 2 possiblities to >>>> register a device in Keycloak >>>> >>>> * As a user >>>> * As a client >>>> >>>> >>>> By representing devices as Keycloak clients we might take >>>> advantage of the ServiceAccount (Oauth-Client Credential) >>>> flow and become able to implement it via (dynamic!) >>>> registration and it and seems, that we will even be able to >>>> authenticate our device by their certificates by choosing >>>> "Signed Jwt" as authenticator option. >>>> >>>> My question is, if it would be a good idea to register a >>>> very big amount of devices as Keycloak clients with regards >>>> to performance and manageability. In principle I would >>>> prefer a user-representation (faciliting usage of user >>>> federation provider & id brokerage for instance), but as >>>> far as I understood, the appropriate flow would be Direct >>>> Access (ResourceOwnerPassword Credentials) and here we can >>>> only deal with username/password instead of certificates. >>>> >>>> Do you have any suggestions or hints (even the conclusion, >>>> that Keycloak is not the suitable >>>> ID-provider-implementation for large-scale IOT-systems)? >>>> >>>> Best regards, Eduard Matuszak >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user at lists.jboss.org >>>> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>> >>>> _________________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user at lists.jboss.org >>>> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >>> -- >>> Aikeaguinea >>> aikeaguinea at xsmail.com >>> >>> >>> -- >>> http://www.fastmail.com - Access your email from home and the web >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >>> -- >>> Henryk Konsek >>> https://linkedin.com/in/hekonsek >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >> _________________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > -- > Aikeaguinea > aikeaguinea at xsmail.com > -- > http://www.fastmail.com - Or how I learned to stop worrying and > love email again > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160517/c55be82d/attachment-0001.html From bruno at abstractj.org Tue May 17 10:38:54 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 17 May 2016 11:38:54 -0300 Subject: [keycloak-user] Securing 3rd party APIs In-Reply-To: References: Message-ID: <20160517143854.GA17292@abstractj.org> Hi Pavel, isn't something like this http://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#d4e1006 enough? On 2016-05-17, Pavel Maslov wrote: > Hi all, > > > Suppose we have a 3rd party REST API, which is not secured. How could we > integrate OAuth2.0 authentication using Keycloak? My first guess is to > create a mediation service (written in Java), which will use the Keycloak > Java adapter and will authenticate users based off the security_token > (passed to the mediation service with each request), and forward all > requests (including headers) to the 3rd party REST API (unsecured). > > Does it make any sense? If so, has anyone written something similar? > > Thanks. > > Regards, > Pavel Maslov, MS > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -- abstractj PGP: 0x84DC9914 From bburke at redhat.com Tue May 17 10:43:18 2016 From: bburke at redhat.com (Bill Burke) Date: Tue, 17 May 2016 10:43:18 -0400 Subject: [keycloak-user] Securing 3rd party APIs In-Reply-To: <20160517143854.GA17292@abstractj.org> References: <20160517143854.GA17292@abstractj.org> Message-ID: <7598b373-2051-4b31-f0f9-f12741f0106e@redhat.com> See Keycloak Proxy. On 5/17/16 10:38 AM, Bruno Oliveira wrote: > Hi Pavel, isn't something like this http://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#d4e1006 > enough? > > On 2016-05-17, Pavel Maslov wrote: >> Hi all, >> >> >> Suppose we have a 3rd party REST API, which is not secured. How could we >> integrate OAuth2.0 authentication using Keycloak? My first guess is to >> create a mediation service (written in Java), which will use the Keycloak >> Java adapter and will authenticate users based off the security_token >> (passed to the mediation service with each request), and forward all >> requests (including headers) to the 3rd party REST API (unsecured). >> >> Does it make any sense? If so, has anyone written something similar? >> >> Thanks. >> >> Regards, >> Pavel Maslov, MS >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From pavel.masloff at gmail.com Tue May 17 10:44:10 2016 From: pavel.masloff at gmail.com (Pavel Maslov) Date: Tue, 17 May 2016 16:44:10 +0200 Subject: [keycloak-user] Securing 3rd party APIs In-Reply-To: <20160517143854.GA17292@abstractj.org> References: <20160517143854.GA17292@abstractj.org> Message-ID: Hi Bruno, 3rd party APIs are treated as black boxes, so we cannot mess up with their code by adding keycloak.json and editing config files (also there is no guarantee they are deployed as WAR). That's why my first guess is some kind of a proxy. Regards, Pavel Maslov, MS On Tue, May 17, 2016 at 4:38 PM, Bruno Oliveira wrote: > Hi Pavel, isn't something like this > http://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#d4e1006 > enough? > > On 2016-05-17, Pavel Maslov wrote: > > Hi all, > > > > > > Suppose we have a 3rd party REST API, which is not secured. How could we > > integrate OAuth2.0 authentication using Keycloak? My first guess is to > > create a mediation service (written in Java), which will use the Keycloak > > Java adapter and will authenticate users based off the security_token > > (passed to the mediation service with each request), and forward all > > requests (including headers) to the 3rd party REST API (unsecured). > > > > Does it make any sense? If so, has anyone written something similar? > > > > Thanks. > > > > Regards, > > Pavel Maslov, MS > > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > -- > > abstractj > PGP: 0x84DC9914 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160517/351c61de/attachment.html From pavel.masloff at gmail.com Tue May 17 10:45:25 2016 From: pavel.masloff at gmail.com (Pavel Maslov) Date: Tue, 17 May 2016 16:45:25 +0200 Subject: [keycloak-user] Securing 3rd party APIs In-Reply-To: <7598b373-2051-4b31-f0f9-f12741f0106e@redhat.com> References: <20160517143854.GA17292@abstractj.org> <7598b373-2051-4b31-f0f9-f12741f0106e@redhat.com> Message-ID: Thanks Bill, that's what I was looking for. Will take a look. Regards, Pavel Maslov, MS On Tue, May 17, 2016 at 4:43 PM, Bill Burke wrote: > See Keycloak Proxy. > > On 5/17/16 10:38 AM, Bruno Oliveira wrote: > > Hi Pavel, isn't something like this > http://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#d4e1006 > > enough? > > > > On 2016-05-17, Pavel Maslov wrote: > >> Hi all, > >> > >> > >> Suppose we have a 3rd party REST API, which is not secured. How could we > >> integrate OAuth2.0 authentication using Keycloak? My first guess is to > >> create a mediation service (written in Java), which will use the > Keycloak > >> Java adapter and will authenticate users based off the security_token > >> (passed to the mediation service with each request), and forward all > >> requests (including headers) to the 3rd party REST API (unsecured). > >> > >> Does it make any sense? If so, has anyone written something similar? > >> > >> Thanks. > >> > >> Regards, > >> Pavel Maslov, MS > >> _______________________________________________ > >> keycloak-user mailing list > >> keycloak-user at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160517/82a0aa65/attachment.html From bruno at abstractj.org Tue May 17 11:12:40 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 17 May 2016 12:12:40 -0300 Subject: [keycloak-user] ENV in keycloak.json does not seem to be working, base64 errors In-Reply-To: <79d79246-f3da-2965-1880-2d4dc4562a81@gmail.com> References: <79d79246-f3da-2965-1880-2d4dc4562a81@gmail.com> Message-ID: <20160517151240.GA22497@abstractj.org> Hi, try something like this: - At your standalone.xml add: - keycloak.json { "realm": "myrealm", "realm-public-key": "${KC_REALM_PUBLIC_KEY}", "auth-server-url": "${KC_AUTH_SERVER_URL}", "ssl-required": "none", "resource": "myrealm", "public-client": true } I hope it helps. On 2016-05-16, cen wrote: > Hi > > I am trying to use env vars in keycloak.json but I am getting base64 errors. > > My keycloak.json: > { > "realm": "myrealm", > "realm-public-key": "${env.KC_REALM_PUBLIC_KEY}", > "auth-server-url": "${env.KC_AUTH_SERVER_URL}", > "ssl-required": "none", > "resource": "myrealm", > "public-client": true > } > > I am deploying my ear to WildFly 10 using the following properties: > > > > Error on deploy: > Bad Base64 input character decimal 36 in array position 0.. (char 36 is $) > > It seems that KC wants to parse the value as string instead of trying to > resolve the env variable. Looking through the code and commits > (https://issues.jboss.org/browse/KEYCLOAK-1289) this should work. What > am I doing wrong? > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -- abstractj PGP: 0x84DC9914 From imbacen at gmail.com Tue May 17 11:25:42 2016 From: imbacen at gmail.com (cen) Date: Tue, 17 May 2016 17:25:42 +0200 Subject: [keycloak-user] ENV in keycloak.json does not seem to be working, base64 errors In-Reply-To: <20160517151240.GA22497@abstractj.org> References: <79d79246-f3da-2965-1880-2d4dc4562a81@gmail.com> <20160517151240.GA22497@abstractj.org> Message-ID: <573B37F6.20605@gmail.com> That works, thanks. Bruno Oliveira je 17. 05. 2016 ob 17:12 napisal: > Hi, try something like this: > > - At your standalone.xml add: > > > > > > - keycloak.json > > { > "realm": "myrealm", > "realm-public-key": "${KC_REALM_PUBLIC_KEY}", > "auth-server-url": "${KC_AUTH_SERVER_URL}", > "ssl-required": "none", > "resource": "myrealm", > "public-client": true > } > > I hope it helps. > > > On 2016-05-16, cen wrote: >> Hi >> >> I am trying to use env vars in keycloak.json but I am getting base64 errors. >> >> My keycloak.json: >> { >> "realm": "myrealm", >> "realm-public-key": "${env.KC_REALM_PUBLIC_KEY}", >> "auth-server-url": "${env.KC_AUTH_SERVER_URL}", >> "ssl-required": "none", >> "resource": "myrealm", >> "public-client": true >> } >> >> I am deploying my ear to WildFly 10 using the following properties: >> >> >> >> Error on deploy: >> Bad Base64 input character decimal 36 in array position 0.. (char 36 is $) >> >> It seems that KC wants to parse the value as string instead of trying to >> resolve the env variable. Looking through the code and commits >> (https://issues.jboss.org/browse/KEYCLOAK-1289) this should work. What >> am I doing wrong? >> > > > >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > -- > > abstractj > PGP: 0x84DC9914 From yelata at blulogix.com Tue May 17 13:13:58 2016 From: yelata at blulogix.com (Yasser El-ata) Date: Tue, 17 May 2016 20:13:58 +0300 Subject: [keycloak-user] Error appear when change the servers to HTTPS Message-ID: *Hello,When we change our server to work with https we start see the following error "Missing parameters: response_type" , and i'am sure the parameters is exist in the URLwhen the application was working on http this error wasn't happenedplease find the attached screen shoutplease adviseThanks* -- Yasser El-Ata Java Developer BluLogix 737 Walker Rd Ste 3, Great Falls, VA 22066 t: 443.333.4100 | f: 443.333.4101 *www.blulogix.com * The information transmitted is intended only for the person(s) to whom it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160517/e2598776/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: screen.jpg Type: image/jpeg Size: 29066 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160517/e2598776/attachment-0001.jpg From jaxley at expedia.com Tue May 17 13:42:58 2016 From: jaxley at expedia.com (Jason Axley) Date: Tue, 17 May 2016 17:42:58 +0000 Subject: [keycloak-user] Keycloak Proxy passing thorugh unauthenticated In-Reply-To: References: <14765d5fbe4a7940075dfa715d55d789@dorsetnetworks.com> <31868C1A-298E-4510-A111-B1198C88A791@expedia.com> Message-ID: Not requiring a plugin is a fine design goal, but the applications must have custom code to at least extract the user?s identity information from the HTTP requests. It would be best design approach to actually provide the application with *verifiable* identity information in the form of the JWT that can be verified with a plugin or inside the same set of application code that is responsible for extracting the identity for the request. Perhaps since the access token is sent along as KEYCLOAK_ACCESS_TOKEN so the server could request the JWT if they knew the URL? I would be sure to document how integrating applications behind the proxy should securely integrate and validate the identity information, otherwise apps won?t do this securely. Secure design necessitates replacing assumptions with controls wherever possible. Assumptions such as ?there is no bad guy on my network? are pretty devastating to security and in practice impossible to ensure but a control such as ?attackers cannot forge JWT tokens? are much more robust and easy to reason about. -Jason On 5/13/16, 11:58 AM, "keycloak-user-bounces at lists.jboss.org on behalf of Bill Burke" wrote: >The idea of the proxy is that the secured app doesn't have to have a >plugin. The secured app is supposed to be on a private network and the >proxy sits on a public one. > > >On 5/13/16 11:52 AM, Jason Axley wrote: >> From my read of the design, it doesn?t look like the proxy design provides a secure way of front-ending an application that won?t allow someone with network access behind the proxy to access the application either without authentication or by impersonating any user since the design appears to rely on HTTP headers set with identity information sent to the backend application. >> >> A better design would have been to pass the actual Id Token to the backend application so that the backend application can actually verify the identity signature on the JWT so that someone can?t just fabricate arbitrary identity information. I would think this could work in concert with an application plugin that could consume these tokens and validate and make the identity information available to the application in a trustworthy manner. >> >> -Jason >> >> On 5/13/16, 8:00 AM, "keycloak-user-bounces at lists.jboss.org on behalf of Guy Bowdler" wrote: >> >>> Hi, >>> >>> We've got the Keycloak Security Proxy (official one - >>> https://keycloak.github.io/docs/userguide/keycloak-server/html/proxy.html) >>> running and passing to an nginx proxy which is in turn proxying out >>> different apps, ie: >>> >>> [client] ----> [:80|443 KeyCloak Proxy ----> :8080 Nginx Reverse Proxy] >>> ------> [application] >>> >>> Where [] denotes a different box, the ProxyBox is hostname.domain and >>> the apps are published as hostname.domain/appname >>> >>> >>> However, the client is able to access the application without >>> authentication, we have clients and roles set up in keycloak and the >>> config looks ok (although obviously isn't!) >>> >>> Are there any KeyCloak Proxy logs we can look at, or debugging options? >>> I haven't found any as yet andnothing is jumping out of the config. >>> >>> We can access the back end apps ok either from the Keycloak proxy >>> running on ports 80 or 443 or via the nginx proxy on 8080 (and yes, this >>> latter connection will be restricted to localhost when it's working!). >>> The keycloak proxy config is very similar to the default except the >>> values from the keycloak installation GUI have been pasted in. >>> >>> Any troubleshooting tips would be much appreciated! >>> >>> thanks in advance:) >>> >>> Guy >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > >_______________________________________________ >keycloak-user mailing list >keycloak-user at lists.jboss.org >https://lists.jboss.org/mailman/listinfo/keycloak-user From frank.herrmann at modernizingmedicine.com Tue May 17 14:18:39 2016 From: frank.herrmann at modernizingmedicine.com (Frank Herrmann) Date: Tue, 17 May 2016 14:18:39 -0400 Subject: [keycloak-user] Spring Security Adapter - Custom Parameter to KeyCloak Message-ID: Hello, Our app is using openid-conntect and the Spring Security Adapter to authenticate to a KeyCloak IDP. The KeyCloak server has custom AuthenticatorFactory and UserFederationProviderFactory. We have also customized some of the KeyCloak/Spring code on the app. At this point, I need a custom query parameter included with the redirect call to KeyCloak. I cannot find in the KeyCloak/Spring Security Adapter code any way to set an additional query parameter. Is there a way to set an additional parameter, or another way to pass a custom map of information to KeyCloak as part of the redirect? For now I am using the "login_hint" parameter to pass additional information. I was just wondering if there is a better way. Thanks, -Frank -- FRANK HERRMANN SOFTWARE ENGINEER T: 561-880-2998 x1563 E: frank.herrmann at modmed.com [image: [ Modernizing Medicine ]] [image: [ Facebook ]] [image: [ LinkedIn ]] [image: [ YouTube ]] [image: [ Twitter ]] [image: [ Blog ]] [image: [ Instagram ]] -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160517/a708b3ef/attachment.html From frank.herrmann at modernizingmedicine.com Tue May 17 14:19:24 2016 From: frank.herrmann at modernizingmedicine.com (Frank Herrmann) Date: Tue, 17 May 2016 14:19:24 -0400 Subject: [keycloak-user] Tempates - login.ftl - How is login.username being set? Message-ID: In the template, login.ftl, the parameter login.username is begin used to fill back in the username field after a failed login. In our custom template, I have additional fields I wound not want a user to have to refill after a failed login. Some of these fields are pre-populated via the form authenticator with context.form().setAttribute, which works fine. However, on a failed login, the login page changes and this context is lost. Is it possible to set additional fields to save their data during failed login? Thanks, -Frank -- FRANK HERRMANN SOFTWARE ENGINEER T: 561-880-2998 x1563 E: frank.herrmann at modmed.com [image: [ Modernizing Medicine ]] [image: [ Facebook ]] [image: [ LinkedIn ]] [image: [ YouTube ]] [image: [ Twitter ]] [image: [ Blog ]] [image: [ Instagram ]] -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160517/2b2b74fe/attachment.html From bruno at abstractj.org Tue May 17 15:17:10 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 17 May 2016 16:17:10 -0300 Subject: [keycloak-user] Error appear when change the servers to HTTPS In-Reply-To: References: Message-ID: <20160517191710.GA7143@abstractj.org> How your keycloak.json file looks like? What about the realm JSON file?[1] Would help if you could provide more details than just the screenshot. [1] - https://github.com/keycloak/keycloak/blob/master/examples/demo-template/testrealm.json On 2016-05-17, Yasser El-ata wrote: > *Hello,When we change our server to work with https we start see the > following error "Missing parameters: response_type" , and i'am sure the > parameters is exist in the URLwhen the application was working on http this > error wasn't happenedplease find the attached screen shoutplease > adviseThanks* > > -- > Yasser El-Ata > Java Developer > BluLogix > 737 Walker Rd Ste 3, Great Falls, VA 22066 > t: 443.333.4100 | f: 443.333.4101 > *www.blulogix.com * > > The information transmitted is intended only for the person(s) to whom it > is addressed and may contain confidential and/or privileged material. Any > review, retransmission, dissemination or other use of, or taking of any > action in reliance upon, this information by persons or entities other than > the intended recipient is prohibited. If you received this in error, please > contact the sender and delete the material from any computer. > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -- abstractj PGP: 0x84DC9914 From guybowdler at dorsetnetworks.com Tue May 17 15:28:37 2016 From: guybowdler at dorsetnetworks.com (Guy Bowdler) Date: Tue, 17 May 2016 20:28:37 +0100 Subject: [keycloak-user] Keycloak Proxy passing thorugh unauthenticated In-Reply-To: References: <14765d5fbe4a7940075dfa715d55d789@dorsetnetworks.com> <31868C1A-298E-4510-A111-B1198C88A791@expedia.com> Message-ID: <6C1B7781-FB36-433B-8E5B-67D0E1BB3384@dorsetnetworks.com> Hi Jason, Thanks for your input. Rest assured this all under consideration, especially the authorisation side of things. The keycloak proxy does look like it exposes key fields in headers that are otherwise quite tricky to extract by other means and that can be easily processed by the application. Ensuring that no header manipulation may be trickier, but there should be some signing in the JWT our devs can check against Guy Bowdler Dorset Networks 01202 694966 | 07793 290798 | www.dorsetnetworks.com Website and email hosting | Computer Networks > On 17 May 2016, at 18:42, Jason Axley wrote: > > Not requiring a plugin is a fine design goal, but the applications must have custom code to at least extract the user?s identity information from the HTTP requests. It would be best design approach to actually provide the application with *verifiable* identity information in the form of the JWT that can be verified with a plugin or inside the same set of application code that is responsible for extracting the identity for the request. > > Perhaps since the access token is sent along as KEYCLOAK_ACCESS_TOKEN so the server could request the JWT if they knew the URL? I would be sure to document how integrating applications behind the proxy should securely integrate and validate the identity information, otherwise apps won?t do this securely. > > Secure design necessitates replacing assumptions with controls wherever possible. Assumptions such as ?there is no bad guy on my network? are pretty devastating to security and in practice impossible to ensure but a control such as ?attackers cannot forge JWT tokens? are much more robust and easy to reason about. > > -Jason > > On 5/13/16, 11:58 AM, "keycloak-user-bounces at lists.jboss.org on behalf of Bill Burke" wrote: > >> The idea of the proxy is that the secured app doesn't have to have a >> plugin. The secured app is supposed to be on a private network and the >> proxy sits on a public one. >> >> >> On 5/13/16 11:52 AM, Jason Axley wrote: >>> From my read of the design, it doesn?t look like the proxy design provides a secure way of front-ending an application that won?t allow someone with network access behind the proxy to access the application either without authentication or by impersonating any user since the design appears to rely on HTTP headers set with identity information sent to the backend application. >>> >>> A better design would have been to pass the actual Id Token to the backend application so that the backend application can actually verify the identity signature on the JWT so that someone can?t just fabricate arbitrary identity information. I would think this could work in concert with an application plugin that could consume these tokens and validate and make the identity information available to the application in a trustworthy manner. >>> >>> -Jason >>> >>> On 5/13/16, 8:00 AM, "keycloak-user-bounces at lists.jboss.org on behalf of Guy Bowdler" wrote: >>> >>>> Hi, >>>> >>>> We've got the Keycloak Security Proxy (official one - >>>> https://keycloak.github.io/docs/userguide/keycloak-server/html/proxy.html) >>>> running and passing to an nginx proxy which is in turn proxying out >>>> different apps, ie: >>>> >>>> [client] ----> [:80|443 KeyCloak Proxy ----> :8080 Nginx Reverse Proxy] >>>> ------> [application] >>>> >>>> Where [] denotes a different box, the ProxyBox is hostname.domain and >>>> the apps are published as hostname.domain/appname >>>> >>>> >>>> However, the client is able to access the application without >>>> authentication, we have clients and roles set up in keycloak and the >>>> config looks ok (although obviously isn't!) >>>> >>>> Are there any KeyCloak Proxy logs we can look at, or debugging options? >>>> I haven't found any as yet andnothing is jumping out of the config. >>>> >>>> We can access the back end apps ok either from the Keycloak proxy >>>> running on ports 80 or 443 or via the nginx proxy on 8080 (and yes, this >>>> latter connection will be restricted to localhost when it's working!). >>>> The keycloak proxy config is very similar to the default except the >>>> values from the keycloak installation GUI have been pasted in. >>>> >>>> Any troubleshooting tips would be much appreciated! >>>> >>>> thanks in advance:) >>>> >>>> Guy >>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160517/18e1b171/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160517/18e1b171/attachment.bin From bburke at redhat.com Tue May 17 16:05:25 2016 From: bburke at redhat.com (Bill Burke) Date: Tue, 17 May 2016 16:05:25 -0400 Subject: [keycloak-user] Keycloak Proxy passing thorugh unauthenticated In-Reply-To: <6C1B7781-FB36-433B-8E5B-67D0E1BB3384@dorsetnetworks.com> References: <14765d5fbe4a7940075dfa715d55d789@dorsetnetworks.com> <31868C1A-298E-4510-A111-B1198C88A791@expedia.com> <6C1B7781-FB36-433B-8E5B-67D0E1BB3384@dorsetnetworks.com> Message-ID: <340ccbd6-391b-b6ec-a55d-528cfaa62921@redhat.com> The access token is a Json Web Signature (JWS) signed by the realm. What you're describing is bearer token auth. The different being that the token is in the KEYCLOAK_ACCESS_TOKEN header rather than the Authorization header. On 5/17/16 3:28 PM, Guy Bowdler wrote: > Hi Jason, > > Thanks for your input. Rest assured this all under consideration, > especially the authorisation side of things. The keycloak proxy does > look like it exposes key fields in headers that are otherwise quite > tricky to extract by other means and that can be easily processed by > the application. Ensuring that no header manipulation may be > trickier, but there should be some signing in the JWT our devs can > check against > > Guy Bowdler > > Dorset Networks > 01202 694966 | 07793 290798 | www.dorsetnetworks.com > > Website and email hosting | Computer Networks > > > > >> On 17 May 2016, at 18:42, Jason Axley > > wrote: >> >> Not requiring a plugin is a fine design goal, but the applications >> must have custom code to at least extract the user?s identity >> information from the HTTP requests. It would be best design approach >> to actually provide the application with *verifiable* identity >> information in the form of the JWT that can be verified with a plugin >> or inside the same set of application code that is responsible for >> extracting the identity for the request. >> >> Perhaps since the access token is sent along as KEYCLOAK_ACCESS_TOKEN >> so the server could request the JWT if they knew the URL? I would be >> sure to document how integrating applications behind the proxy should >> securely integrate and validate the identity information, otherwise >> apps won?t do this securely. >> >> Secure design necessitates replacing assumptions with controls >> wherever possible. Assumptions such as ?there is no bad guy on my >> network? are pretty devastating to security and in practice >> impossible to ensure but a control such as ?attackers cannot forge >> JWT tokens? are much more robust and easy to reason about. >> >> -Jason >> >> On 5/13/16, 11:58 AM, "keycloak-user-bounces at lists.jboss.org >> on behalf of Bill >> Burke" > on behalf of >> bburke at redhat.com > wrote: >> >>> The idea of the proxy is that the secured app doesn't have to have a >>> plugin. The secured app is supposed to be on a private network and the >>> proxy sits on a public one. >>> >>> >>> On 5/13/16 11:52 AM, Jason Axley wrote: >>>> From my read of the design, it doesn?t look like the proxy design >>>> provides a secure way of front-ending an application that won?t >>>> allow someone with network access behind the proxy to access the >>>> application either without authentication or by impersonating any >>>> user since the design appears to rely on HTTP headers set with >>>> identity information sent to the backend application. >>>> >>>> A better design would have been to pass the actual Id Token to the >>>> backend application so that the backend application can actually >>>> verify the identity signature on the JWT so that someone can?t just >>>> fabricate arbitrary identity information. I would think this could >>>> work in concert with an application plugin that could consume these >>>> tokens and validate and make the identity information available to >>>> the application in a trustworthy manner. >>>> >>>> -Jason >>>> >>>> On 5/13/16, 8:00 AM, "keycloak-user-bounces at lists.jboss.org >>>> on behalf of Guy >>>> Bowdler" >>> on behalf of >>>> guybowdler at dorsetnetworks.com >>>> > wrote: >>>> >>>>> Hi, >>>>> >>>>> We've got the Keycloak Security Proxy (official one - >>>>> https://keycloak.github.io/docs/userguide/keycloak-server/html/proxy.html) >>>>> running and passing to an nginx proxy which is in turn proxying out >>>>> different apps, ie: >>>>> >>>>> [client] ----> [:80|443 KeyCloak Proxy ----> :8080 Nginx Reverse >>>>> Proxy] >>>>> ------> [application] >>>>> >>>>> Where [] denotes a different box, the ProxyBox is hostname.domain and >>>>> the apps are published as hostname.domain/appname >>>>> >>>>> >>>>> However, the client is able to access the application without >>>>> authentication, we have clients and roles set up in keycloak and the >>>>> config looks ok (although obviously isn't!) >>>>> >>>>> Are there any KeyCloak Proxy logs we can look at, or debugging >>>>> options? >>>>> I haven't found any as yet andnothing is jumping out of the config. >>>>> >>>>> We can access the back end apps ok either from the Keycloak proxy >>>>> running on ports 80 or 443 or via the nginx proxy on 8080 (and >>>>> yes, this >>>>> latter connection will be restricted to localhost when it's working!). >>>>> The keycloak proxy config is very similar to the default except the >>>>> values from the keycloak installation GUI have been pasted in. >>>>> >>>>> Any troubleshooting tips would be much appreciated! >>>>> >>>>> thanks in advance:) >>>>> >>>>> Guy >>>>> >>>>> _______________________________________________ >>>>> keycloak-user mailing list >>>>> keycloak-user at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160517/887e137f/attachment-0001.html From yelata at blulogix.com Tue May 17 16:38:49 2016 From: yelata at blulogix.com (Yasser El-ata) Date: Tue, 17 May 2016 23:38:49 +0300 Subject: [keycloak-user] Error appear when change the servers to HTTPS In-Reply-To: <20160517191710.GA7143@abstractj.org> References: <20160517191710.GA7143@abstractj.org> Message-ID: Hello Bruno, Thanks for your quick response the following are my Realms , AngularJs and bearer JSON files i paste them to the ubuntu paste i also attache them in the email My Realms: http://paste.ubuntu.com/16481701/ AngularJs App Json File : http://paste.ubuntu.com/16481216/ Bearer Application (API) Json File: http://paste.ubuntu.com/16481242/ please advise , this issue is so annoying me :( On Tue, May 17, 2016 at 10:17 PM, Bruno Oliveira wrote: > How your keycloak.json file looks like? What about the realm JSON > file?[1] > > Would help if you could provide more details than just the screenshot. > > [1] - > https://github.com/keycloak/keycloak/blob/master/examples/demo-template/testrealm.json > > On 2016-05-17, Yasser El-ata wrote: > > *Hello,When we change our server to work with https we start see the > > following error "Missing parameters: response_type" , and i'am sure the > > parameters is exist in the URLwhen the application was working on http > this > > error wasn't happenedplease find the attached screen shoutplease > > adviseThanks* > > > > -- > > Yasser El-Ata > > Java Developer > > BluLogix > > 737 Walker Rd Ste 3, Great Falls, VA 22066 > > t: 443.333.4100 | f: 443.333.4101 > > *www.blulogix.com * > > > > The information transmitted is intended only for the person(s) to whom it > > is addressed and may contain confidential and/or privileged material. Any > > review, retransmission, dissemination or other use of, or taking of any > > action in reliance upon, this information by persons or entities other > than > > the intended recipient is prohibited. If you received this in error, > please > > contact the sender and delete the material from any computer. > > > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > -- > > abstractj > PGP: 0x84DC9914 > -- Yasser El-Ata Java Developer BluLogix 737 Walker Rd Ste 3, Great Falls, VA 22066 t: 443.333.4100 | f: 443.333.4101 *www.blulogix.com * The information transmitted is intended only for the person(s) to whom it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160517/958def0f/attachment-0001.html -------------- next part -------------- { "realm": "BluLogix", "realm-public-key": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6DT7MeQjyxP+MX/iwNPUy3g3JzcPZ4fWLdlHI0pMnkUS4bksIrjCWNWZV6V7TLQLHE0aOfcrZz634lfgt2H0WEDDAvQWo2aPCzxQKvXD+/ioYem18we4XbM6f6NsjJ1cmBRiQpHlZrEQ5AR9RA5734Xyc0SMn0td4Q5WP48QYfc5iGpWYHzQvGUbCnwR95ysZP34v2n7j1cwkNg7PClHtmgUWz7RQIczR8c1VzXIrYwvACYavblcvO98Wh50sKX2h3S7Zgspz23f/oaAl7lmvVuBo/yF87T+7qSXDRo737I7nyBxTERya8ShCDrMVCuhWoBRzMGFeovhfse7TNZoswIDAQAB", "auth-server-url": "https://trialblua3administration.blulogix.com/auth", "ssl-required": "all", "resource": "CIS", "credentials": { "secret": "fdb61205-d0c5-4c48-b6d6-8dd28a2f040d" }, "use-resource-role-mappings": true } -------------- next part -------------- { "realm": "BluLogix", "realm-public-key": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6DT7MeQjyxP+MX/iwNPUy3g3JzcPZ4fWLdlHI0pMnkUS4bksIrjCWNWZV6V7TLQLHE0aOfcrZz634lfgt2H0WEDDAvQWo2aPCzxQKvXD+/ioYem18we4XbM6f6NsjJ1cmBRiQpHlZrEQ5AR9RA5734Xyc0SMn0td4Q5WP48QYfc5iGpWYHzQvGUbCnwR95ysZP34v2n7j1cwkNg7PClHtmgUWz7RQIczR8c1VzXIrYwvACYavblcvO98Wh50sKX2h3S7Zgspz23f/oaAl7lmvVuBo/yF87T+7qSXDRo737I7nyBxTERya8ShCDrMVCuhWoBRzMGFeovhfse7TNZoswIDAQAB", "bearer-only": true, "auth-server-url": "https://trialblua3administration.blulogix.com/auth", "ssl-required": "all", "resource": "CIS-SERVER", "use-resource-role-mappings": true, "enable-cors" : true, "cors-max-age" : 3600, "cors-allowed-methods" : "POST, PUT, DELETE, GET", "allow-any-hostname" : true } -------------- next part -------------- [ { "id": "BluLogix", "realm": "BluLogix", "displayName": "Please Login:", "notBefore": 0, "revokeRefreshToken": false, "accessTokenLifespan": 1200, "accessTokenLifespanForImplicitFlow": 900, "ssoSessionIdleTimeout": 1800, "ssoSessionMaxLifespan": 1800, "offlineSessionIdleTimeout": 2592000, "accessCodeLifespan": 60, "accessCodeLifespanUserAction": 900, "accessCodeLifespanLogin": 1800, "enabled": true, "sslRequired": "all", "registrationAllowed": false, "registrationEmailAsUsername": true, "rememberMe": true, "verifyEmail": true, "resetPasswordAllowed": true, "editUsernameAllowed": true, "bruteForceProtected": false, "maxFailureWaitSeconds": 900, "minimumQuickLoginWaitSeconds": 60, "waitIncrementSeconds": 60, "quickLoginCheckMilliSeconds": 1000, "maxDeltaTimeSeconds": 43200, "failureFactor": 30, "privateKey": "MIIEpAIBAAKCAQEA6DT7MeQjyxP+MX/iwNPUy3g3JzcPZ4fWLdlHI0pMnkUS4bksIrjCWNWZV6V7TLQLHE0aOfcrZz634lfgt2H0WEDDAvQWo2aPCzxQKvXD+/ioYem18we4XbM6f6NsjJ1cmBRiQpHlZrEQ5AR9RA5734Xyc0SMn0td4Q5WP48QYfc5iGpWYHzQvGUbCnwR95ysZP34v2n7j1cwkNg7PClHtmgUWz7RQIczR8c1VzXIrYwvACYavblcvO98Wh50sKX2h3S7Zgspz23f/oaAl7lmvVuBo/yF87T+7qSXDRo737I7nyBxTERya8ShCDrMVCuhWoBRzMGFeovhfse7TNZoswIDAQABAoIBAQDETs4yPooYDD3wwQoFNNCId4hBCeZnA0qJlk/ywMSHZSPyWma6r/H1whaSJ19W2DswYOqUKKaz8SzqGJrszc4RsiZrX8mnuHOj7whjWUSnx28q37cnz9YIuRXyhEmnkv2NwGXVm5wRtg3uhvET0R7eOFJhKomrvb6PHlzB/QO/nPLdpmZdxoSe4igBlhLb9WLGTdBUx3MTmITUZfZlFR4DOqNeMhfttGf5+S9ZnuPECSO70EICuRUHbBcfJnfMBa82V4Z3yuh9bhtO4hjptabqDV/tIgQOOmjflwIOymqkCUIbe2TXl/R1EaQVxI4NG01LWs+j+fnMHe5Oke5n7S9xAoGBAPi5SYqgO8UasOUiWtH64QzBrWJgSrM4hbc6AF6+3ns43IpX0whEn/euH08K6raoi18GhMS+deJH2BUpNHi2bLB7qpQYxOwgFXWQ3q/5VIXoda2kH8SNoR7K+5MdGVsKVjLPulANLPhUyySOKpxKOeWSHusEmQSZdTYy3vT0rQ3LAoGBAO7//4YA32ONv7rkJFpWgi2JHRyhx2MWTcTHZA2xcj5mBgt8Wz9nfsOoseWcRyoNHNUSX4bSf+Ix7B7CN6osZ60qrwXPk3LVTzetNE2FhOjRN+9VBf9Tky3/7Pdl+h3O8Sual+MDQJSx0ShZXY8ipzdt8neoMMsvoSKMxDVFGDO5AoGBAKZ4nVhDVr3d13gFPnQ8TlSTbNDjUhwSQK0aDRVc+tvOew29KmnmRIsp55qn2+DVfjLj0gk80PnazC2dnpkMwEJ/AvSMf4DrGHHPvLxbTM8zf0/xAbI0eRp7EVatq0Lb8EWh8zmRGAA+AJk+7hYdOBMHcdorAZ+qdmEIO2IIQatxAoGAT5K0RK1tsvuy5kqnP9ylovuP0cSbWgZHBklMqrJ10wis4o4Y41dWAVbdRBFwMDQFcXuYio7zPSBZ+TO4zNPUAPfBJjIiaY1TvrnQPC9EPS/La8fnI0d0LVCUWRp+2AXajiX+g/rFObyqYsC+QbXL7syQef5poHzPLW2otgO3NyECgYAuQOVfomVpiF+oWscNjmnsG+T86P8ZaH7jKxNlJ9EKz/eoDmEu6GG0gdEY/p3iUnvs/kR3vzkiBa/k8XZgCDcRn8Le6Dzx35qNyltj/cbscv0PANhFKLhShmarZEvGriN7xOMrfhZGbj7oL+QtAJr2zOIa9uxdW+fu0vNJGnFoHQ==", "publicKey": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6DT7MeQjyxP+MX/iwNPUy3g3JzcPZ4fWLdlHI0pMnkUS4bksIrjCWNWZV6V7TLQLHE0aOfcrZz634lfgt2H0WEDDAvQWo2aPCzxQKvXD+/ioYem18we4XbM6f6NsjJ1cmBRiQpHlZrEQ5AR9RA5734Xyc0SMn0td4Q5WP48QYfc5iGpWYHzQvGUbCnwR95ysZP34v2n7j1cwkNg7PClHtmgUWz7RQIczR8c1VzXIrYwvACYavblcvO98Wh50sKX2h3S7Zgspz23f/oaAl7lmvVuBo/yF87T+7qSXDRo737I7nyBxTERya8ShCDrMVCuhWoBRzMGFeovhfse7TNZoswIDAQAB", "certificate": "MIICnzCCAYcCBgFSXpioszANBgkqhkiG9w0BAQsFADATMREwDwYDVQQDDAhCbHVMb2dpeDAeFw0xNjAxMjAxMDMxNDlaFw0yNjAxMjAxMDMzMjlaMBMxETAPBgNVBAMMCEJsdUxvZ2l4MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6DT7MeQjyxP+MX/iwNPUy3g3JzcPZ4fWLdlHI0pMnkUS4bksIrjCWNWZV6V7TLQLHE0aOfcrZz634lfgt2H0WEDDAvQWo2aPCzxQKvXD+/ioYem18we4XbM6f6NsjJ1cmBRiQpHlZrEQ5AR9RA5734Xyc0SMn0td4Q5WP48QYfc5iGpWYHzQvGUbCnwR95ysZP34v2n7j1cwkNg7PClHtmgUWz7RQIczR8c1VzXIrYwvACYavblcvO98Wh50sKX2h3S7Zgspz23f/oaAl7lmvVuBo/yF87T+7qSXDRo737I7nyBxTERya8ShCDrMVCuhWoBRzMGFeovhfse7TNZoswIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQBXogxS9bcEKYSWUosA7ddl+p8tNPzte38e/1L6dmD0Eoswo7M46WndWr5uNkrZvfMOCrNP6nPny1ugehZ6+2ZkmuL0qeoCdmaMwqPiqiUi2zm00vsocdF9cl63pZLKts0WQ2G+VzdJon0+ltWR89TYzj9it5oU4FG0IN0Fn87drcplvUKXhZ4EvlS+HnkndIOEufnUXvZaTd9oP5JiZXNQSGUBjWlUjIWGefWKiyEC+7OYWT4kcknfceLf0rB7Tqme+Twzg+Om3vRQKTRuTKBfFERIexihmpWBsIkBL44wCO/9Ln/LhVm/PPmn0BqMfxJnm1Ep3WrOYkCGMMA0WsaS", "codeSecret": "8ce2ceef-cd9e-4831-8993-6f05be6014bf", "roles": { "realm": [ { "id": "a71d2bd8-4501-4ba8-a72a-309bb0f49f9e", "name": "admin", "description": "admin privalage", "scopeParamRequired": false, "composite": false }, { "id": "4b84029a-54a4-4d9f-b01d-b7cfb8eb6d2f", "name": "offline_access", "description": "${role_offline-access}", "scopeParamRequired": true, "composite": false }, { "id": "7bb2f395-037d-497f-a2f6-ab8173fd810b", "name": "user", "description": "user privalage", "scopeParamRequired": false, "composite": false } ], "client": { "realm-management": [ { "id": "3002cbb1-dc46-4002-84af-13a479fca739", "name": "manage-clients", "description": "${role_manage-clients}", "scopeParamRequired": false, "composite": false }, { "id": "4c372e57-1de0-449f-8988-7b510dd1150a", "name": "manage-events", "description": "${role_manage-events}", "scopeParamRequired": false, "composite": false }, { "id": "207c5734-bc3f-4e8a-ac7b-17046e5d9ba4", "name": "impersonation", "description": "${role_impersonation}", "scopeParamRequired": false, "composite": false }, { "id": "cfc9af9d-5e7e-4782-8447-8af70d862424", "name": "view-identity-providers", "description": "${role_view-identity-providers}", "scopeParamRequired": false, "composite": false }, { "id": "909a610c-27f5-4e16-8d66-7fb0a93ce3d9", "name": "view-clients", "description": "${role_view-clients}", "scopeParamRequired": false, "composite": false }, { "id": "33b6363b-c7e7-4b2a-91eb-14ebe13fd09b", "name": "create-client", "description": "${role_create-client}", "scopeParamRequired": false, "composite": false }, { "id": "332b78c7-9f5c-4cba-8391-2fa3316942ae", "name": "view-realm", "description": "${role_view-realm}", "scopeParamRequired": false, "composite": false }, { "id": "92ce4f2f-3afe-405e-8bfb-6c29fa00838d", "name": "view-events", "description": "${role_view-events}", "scopeParamRequired": false, "composite": false }, { "id": "97ba934e-3f8f-4719-a9eb-197cf4415220", "name": "manage-realm", "description": "${role_manage-realm}", "scopeParamRequired": false, "composite": false }, { "id": "6b69c32f-59a7-4462-bb0d-b4625b96ebb3", "name": "realm-admin", "description": "${role_realm-admin}", "scopeParamRequired": false, "composite": true, "composites": { "client": { "realm-management": [ "manage-clients", "manage-events", "view-clients", "impersonation", "create-client", "view-realm", "view-events", "manage-realm", "view-users", "view-identity-providers", "manage-users", "manage-identity-providers" ] } } }, { "id": "334d7de3-db22-478b-85fe-b1e77f70319d", "name": "view-users", "description": "${role_view-users}", "scopeParamRequired": false, "composite": false }, { "id": "82086eca-c0ab-4819-abcd-ba750e63fd93", "name": "manage-users", "description": "${role_manage-users}", "scopeParamRequired": false, "composite": false }, { "id": "e1cdfd0e-20b5-4910-8acf-5f7a7bcb068c", "name": "manage-identity-providers", "description": "${role_manage-identity-providers}", "scopeParamRequired": false, "composite": false } ], "security-admin-console": [], "CIS-SERVER": [ { "id": "efa125c0-a43b-44ff-aee5-97d83f70bd33", "name": "api_user", "description": "api_user", "scopeParamRequired": false, "composite": false } ], "admin-cli": [], "CIS": [ { "id": "0ec4e381-79cb-4ef2-8dec-94286e070af1", "name": "user_role", "description": "user_role", "scopeParamRequired": false, "composite": false } ], "broker": [ { "id": "1da7cb4c-9681-489c-9af2-45a567746731", "name": "read-token", "description": "${role_read-token}", "scopeParamRequired": false, "composite": false } ], "account": [ { "id": "8ec77e25-0f38-4cde-b277-e2461e68f1de", "name": "view-profile", "description": "${role_view-profile}", "scopeParamRequired": false, "composite": false }, { "id": "36beae54-f8fe-44a9-b569-ab33f26c937f", "name": "manage-account", "description": "${role_manage-account}", "scopeParamRequired": false, "composite": false } ] } }, "groups": [ { "id": "32a5eac2-0ade-4756-80c8-754f366176ab", "name": "User Test", "path": "/User Test", "attributes": { "partnerCode": [ "t68ur7tyr77r" ] }, "realmRoles": [ "admin", "offline_access", "user" ], "clientRoles": { "CIS-SERVER": [ "api_user" ], "CIS": [ "user_role" ] }, "subGroups": [] } ], "defaultRoles": [ "offline_access" ], "requiredCredentials": [ "password" ], "otpPolicyType": "totp", "otpPolicyAlgorithm": "HmacSHA1", "otpPolicyInitialCounter": 0, "otpPolicyDigits": 6, "otpPolicyLookAheadWindow": 1, "otpPolicyPeriod": 30, "users": [], "scopeMappings": [ { "client": "CIS", "roles": [ "admin", "user" ] }, { "client": "security-admin-console", "roles": [ "admin", "user" ] } ], "clientScopeMappings": { "realm-management": [ { "client": "admin-cli", "roles": [ "realm-admin" ] }, { "client": "security-admin-console", "roles": [ "realm-admin" ] } ], "CIS-SERVER": [ { "client": "CIS", "roles": [ "api_user" ] } ] }, "clients": [ { "id": "a8eed917-823d-4aa9-8a72-0f91777905fa", "clientId": "CIS", "name": "CIS", "description": "Cloud Innovations Suit", "surrogateAuthRequired": false, "enabled": true, "clientAuthenticatorType": "client-secret", "secret": "fdb61205-d0c5-4c48-b6d6-8dd28a2f040d", "redirectUris": [ "https://developtrial1.blulogix.com" ], "webOrigins": ["https://storetrial1.blulogix.com/G6_V2/public_html/index.html" ], "notBefore": 0, "bearerOnly": false, "consentRequired": false, "standardFlowEnabled": true, "implicitFlowEnabled": false, "directAccessGrantsEnabled": true, "serviceAccountsEnabled": false, "publicClient": false, "frontchannelLogout": false, "protocol": "openid-connect", "attributes": { "saml.assertion.signature": "false", "saml.force.post.binding": "false", "saml.multivalued.roles": "false", "saml.signature.algorithm": "RSA_SHA256", "saml.encrypt": "false", "saml_force_name_id_format": "false", "saml.client.signature": "false", "saml.authnstatement": "true", "saml_name_id_format": "username", "saml.server.signature": "false", "saml_signature_canonicalization_method": "http://www.w3.org/2001/10/xml-exc-c14n#" }, "fullScopeAllowed": false, "nodeReRegistrationTimeout": -1, "protocolMappers": [ { "id": "9f6b0864-c825-4bac-ac14-cd558f176a3f", "name": "Client ID", "protocol": "openid-connect", "protocolMapper": "oidc-usersessionmodel-note-mapper", "consentRequired": false, "config": { "user.session.note": "clientId", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "clientId", "jsonType.label": "String" } }, { "id": "e9e8202c-0ffc-4dbd-baed-362c1b6723ce", "name": "accountNumber", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-attribute-mapper", "consentRequired": false, "config": { "multivalued": "false", "user.attribute": "accountNumber", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "accountNumber", "jsonType.label": "String" } }, { "id": "9dfdc7c9-e81e-45f1-99d7-3dfccbafbebd", "name": "Client Host", "protocol": "openid-connect", "protocolMapper": "oidc-usersessionmodel-note-mapper", "consentRequired": false, "config": { "user.session.note": "clientHost", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "clientHost", "jsonType.label": "String" } }, { "id": "23c0db37-2aaf-4a57-9c5f-087a57abeaed", "name": "username", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${username}", "config": { "user.attribute": "username", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "preferred_username", "jsonType.label": "String" } }, { "id": "495c2caa-c987-48a2-b73b-565833d7f247", "name": "family name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${familyName}", "config": { "user.attribute": "lastName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "family_name", "jsonType.label": "String" } }, { "id": "0fe169e7-d0a4-427a-9272-507e1f87f42c", "name": "role list", "protocol": "saml", "protocolMapper": "saml-role-list-mapper", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } }, { "id": "604a27c8-c735-4bd4-aa41-c0dd886bb95a", "name": "Client IP Address", "protocol": "openid-connect", "protocolMapper": "oidc-usersessionmodel-note-mapper", "consentRequired": false, "config": { "user.session.note": "clientAddress", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "clientAddress", "jsonType.label": "String" } }, { "id": "d80117fa-3478-4846-97ec-277f0f0994ae", "name": "full name", "protocol": "openid-connect", "protocolMapper": "oidc-full-name-mapper", "consentRequired": true, "consentText": "${fullName}", "config": { "id.token.claim": "true", "access.token.claim": "true" } }, { "id": "9af3dd9b-d1f2-42ff-9a7d-01098c34042a", "name": "partnerCode", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-attribute-mapper", "consentRequired": false, "config": { "user.attribute": "partnerCode", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "partnerCode", "jsonType.label": "String" } }, { "id": "6d090757-28a9-43df-9e73-a00e435a7848", "name": "email verified", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": false, "consentText": "${emailVerified}", "config": { "user.attribute": "emailVerified", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email_verified", "jsonType.label": "boolean" } }, { "id": "c5932d5f-a92e-4eb7-a71a-04f48767bb01", "name": "locale", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-attribute-mapper", "consentRequired": false, "consentText": "${locale}", "config": { "user.attribute": "locale", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "locale", "jsonType.label": "String" } }, { "id": "ac39401c-5b2f-4a6a-aeeb-765243213830", "name": "address", "protocol": "openid-connect", "protocolMapper": "oidc-address-mapper", "consentRequired": true, "consentText": "${address}", "config": { "id.token.claim": "true", "access.token.claim": "true" } }, { "id": "9df2ae53-d513-43f6-93af-84d1d30782e6", "name": "email", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${email}", "config": { "user.attribute": "email", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email", "jsonType.label": "String" } }, { "id": "a72d07f3-f3a9-4e47-bd02-36789ed9ce37", "name": "given name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${givenName}", "config": { "user.attribute": "firstName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "given_name", "jsonType.label": "String" } }, { "id": "ee24264d-7546-49dd-8865-f490c0056d8f", "name": "gss delegation credential", "protocol": "openid-connect", "protocolMapper": "oidc-usersessionmodel-note-mapper", "consentRequired": true, "consentText": "${gssDelegationCredential}", "config": { "user.session.note": "gss_delegation_credential", "access.token.claim": "true", "claim.name": "gss_delegation_credential", "jsonType.label": "String" } } ], "useTemplateConfig": false, "useTemplateScope": false, "useTemplateMappers": false }, { "id": "227606d3-4b6b-40a1-af82-8eade110dfff", "clientId": "CIS-SERVER", "name": "CIS-SERVER", "description": "BluLogix Server Api's", "surrogateAuthRequired": false, "enabled": true, "clientAuthenticatorType": "client-secret", "secret": "b05948ee-5c52-4ae1-b1b2-98eba92d46c4", "redirectUris": [], "webOrigins": [], "notBefore": 0, "bearerOnly": true, "consentRequired": false, "standardFlowEnabled": true, "implicitFlowEnabled": false, "directAccessGrantsEnabled": false, "serviceAccountsEnabled": false, "publicClient": false, "frontchannelLogout": false, "protocol": "openid-connect", "attributes": { "saml.assertion.signature": "false", "saml.force.post.binding": "false", "saml.multivalued.roles": "false", "saml.signature.algorithm": "RSA_SHA256", "saml.encrypt": "false", "saml_force_name_id_format": "false", "saml.client.signature": "false", "saml.authnstatement": "true", "saml_name_id_format": "username", "saml.server.signature": "false", "saml_signature_canonicalization_method": "http://www.w3.org/2001/10/xml-exc-c14n#" }, "fullScopeAllowed": true, "nodeReRegistrationTimeout": -1, "protocolMappers": [ { "id": "c8f6d52c-1f71-4310-a35f-2359553859ed", "name": "given name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${givenName}", "config": { "user.attribute": "firstName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "given_name", "jsonType.label": "String" } }, { "id": "57e72513-431e-43ec-add8-6210b6e4b9c7", "name": "family name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${familyName}", "config": { "user.attribute": "lastName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "family_name", "jsonType.label": "String" } }, { "id": "cc545c42-f73d-4f4c-8681-0be38b7994af", "name": "role list", "protocol": "saml", "protocolMapper": "saml-role-list-mapper", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } }, { "id": "416f28b3-f9e3-4178-a3dd-4c420e423864", "name": "username", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${username}", "config": { "user.attribute": "username", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "preferred_username", "jsonType.label": "String" } }, { "id": "cdf3545d-a11c-4885-9d22-c56f01160e64", "name": "email", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${email}", "config": { "user.attribute": "email", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email", "jsonType.label": "String" } }, { "id": "43496269-da8e-4fc6-8425-728a02afaa76", "name": "full name", "protocol": "openid-connect", "protocolMapper": "oidc-full-name-mapper", "consentRequired": true, "consentText": "${fullName}", "config": { "id.token.claim": "true", "access.token.claim": "true" } } ], "useTemplateConfig": false, "useTemplateScope": false, "useTemplateMappers": false }, { "id": "eac1955b-3eb5-4360-b07c-29d8879870f5", "clientId": "account", "name": "${client_account}", "baseUrl": "/auth/realms/BluLogix/account", "surrogateAuthRequired": false, "enabled": true, "clientAuthenticatorType": "client-secret", "secret": "488edcdd-1bbf-4c7f-8265-312dc3e8858c", "defaultRoles": [ "view-profile", "manage-account" ], "redirectUris": [ "/auth/realms/BluLogix/account/*" ], "webOrigins": [], "notBefore": 0, "bearerOnly": false, "consentRequired": false, "standardFlowEnabled": true, "implicitFlowEnabled": false, "directAccessGrantsEnabled": false, "serviceAccountsEnabled": false, "publicClient": false, "frontchannelLogout": false, "attributes": {}, "fullScopeAllowed": false, "nodeReRegistrationTimeout": 0, "protocolMappers": [ { "id": "8b8f1929-1dae-4c49-af7c-9428dd98ea8e", "name": "username", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${username}", "config": { "user.attribute": "username", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "preferred_username", "jsonType.label": "String" } }, { "id": "3245c3f1-cedc-4171-9866-38670415a2ef", "name": "family name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${familyName}", "config": { "user.attribute": "lastName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "family_name", "jsonType.label": "String" } }, { "id": "2d5d8913-f08c-453b-983d-34de9db31801", "name": "email", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${email}", "config": { "user.attribute": "email", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email", "jsonType.label": "String" } }, { "id": "5f338d95-f27d-488b-ade2-e1a65e3ede88", "name": "full name", "protocol": "openid-connect", "protocolMapper": "oidc-full-name-mapper", "consentRequired": true, "consentText": "${fullName}", "config": { "id.token.claim": "true", "access.token.claim": "true" } }, { "id": "7ea30832-216b-4016-ad5e-75e750faa2b0", "name": "given name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${givenName}", "config": { "user.attribute": "firstName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "given_name", "jsonType.label": "String" } }, { "id": "f387b5e2-4241-4631-b127-26ac47f299e7", "name": "role list", "protocol": "saml", "protocolMapper": "saml-role-list-mapper", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } } ], "useTemplateConfig": false, "useTemplateScope": false, "useTemplateMappers": false }, { "id": "9d1c53f5-9ded-4ad3-b511-3b5ff6aa08a1", "clientId": "admin-cli", "name": "${client_admin-cli}", "surrogateAuthRequired": false, "enabled": true, "clientAuthenticatorType": "client-secret", "secret": "1154222a-fe1d-444b-b29c-682065a77d8b", "redirectUris": [], "webOrigins": [], "notBefore": 0, "bearerOnly": false, "consentRequired": false, "standardFlowEnabled": false, "implicitFlowEnabled": false, "directAccessGrantsEnabled": true, "serviceAccountsEnabled": false, "publicClient": true, "frontchannelLogout": false, "attributes": {}, "fullScopeAllowed": false, "nodeReRegistrationTimeout": 0, "protocolMappers": [ { "id": "ae7cc777-2e71-42c2-81c7-89a458abd046", "name": "email", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${email}", "config": { "user.attribute": "email", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email", "jsonType.label": "String" } }, { "id": "e022bcf7-9676-478b-8e9e-b3321db31325", "name": "given name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${givenName}", "config": { "user.attribute": "firstName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "given_name", "jsonType.label": "String" } }, { "id": "b949fa0f-8db4-4daa-822c-3f68ef82c366", "name": "role list", "protocol": "saml", "protocolMapper": "saml-role-list-mapper", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } }, { "id": "614f4b41-c229-4731-befa-fe14b0ecf3e8", "name": "username", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${username}", "config": { "user.attribute": "username", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "preferred_username", "jsonType.label": "String" } }, { "id": "d832c7f9-78de-42ec-a612-84353213630a", "name": "full name", "protocol": "openid-connect", "protocolMapper": "oidc-full-name-mapper", "consentRequired": true, "consentText": "${fullName}", "config": { "id.token.claim": "true", "access.token.claim": "true" } }, { "id": "cfefffc7-13a8-4719-be88-7f64584f1fa3", "name": "family name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${familyName}", "config": { "user.attribute": "lastName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "family_name", "jsonType.label": "String" } } ], "useTemplateConfig": false, "useTemplateScope": false, "useTemplateMappers": false }, { "id": "153f8d34-7425-4734-8373-49e292963d63", "clientId": "broker", "name": "${client_broker}", "surrogateAuthRequired": false, "enabled": true, "clientAuthenticatorType": "client-secret", "secret": "7cff6841-64da-4911-89fe-63bd17914b4f", "redirectUris": [], "webOrigins": [], "notBefore": 0, "bearerOnly": false, "consentRequired": false, "standardFlowEnabled": true, "implicitFlowEnabled": false, "directAccessGrantsEnabled": false, "serviceAccountsEnabled": false, "publicClient": false, "frontchannelLogout": false, "attributes": {}, "fullScopeAllowed": false, "nodeReRegistrationTimeout": 0, "protocolMappers": [ { "id": "5596c5cc-4f57-461e-8858-26842efbaa1f", "name": "full name", "protocol": "openid-connect", "protocolMapper": "oidc-full-name-mapper", "consentRequired": true, "consentText": "${fullName}", "config": { "id.token.claim": "true", "access.token.claim": "true" } }, { "id": "85c6388c-b440-4ba8-ac64-ce95f851cb87", "name": "given name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${givenName}", "config": { "user.attribute": "firstName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "given_name", "jsonType.label": "String" } }, { "id": "d57f9b94-a466-449d-b75a-fa9b2fadfd35", "name": "email", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${email}", "config": { "user.attribute": "email", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email", "jsonType.label": "String" } }, { "id": "64b4962b-7a34-423d-8ef9-ca1340f00351", "name": "family name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${familyName}", "config": { "user.attribute": "lastName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "family_name", "jsonType.label": "String" } }, { "id": "17ca0341-a8d2-4c69-886b-65f8efd5d780", "name": "role list", "protocol": "saml", "protocolMapper": "saml-role-list-mapper", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } }, { "id": "cfae52c5-8434-4431-9442-a45cc37c44df", "name": "username", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${username}", "config": { "user.attribute": "username", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "preferred_username", "jsonType.label": "String" } } ], "useTemplateConfig": false, "useTemplateScope": false, "useTemplateMappers": false }, { "id": "952ec9d0-1570-4785-8afb-bccccdaa1904", "clientId": "realm-management", "name": "${client_realm-management}", "surrogateAuthRequired": false, "enabled": true, "clientAuthenticatorType": "client-secret", "secret": "09d204d1-b9a3-468b-924f-d8c591632934", "redirectUris": [], "webOrigins": [], "notBefore": 0, "bearerOnly": true, "consentRequired": false, "standardFlowEnabled": true, "implicitFlowEnabled": false, "directAccessGrantsEnabled": false, "serviceAccountsEnabled": false, "publicClient": false, "frontchannelLogout": false, "attributes": {}, "fullScopeAllowed": false, "nodeReRegistrationTimeout": 0, "protocolMappers": [ { "id": "89c52126-8fff-480f-a13a-b23bbc8680e3", "name": "given name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${givenName}", "config": { "user.attribute": "firstName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "given_name", "jsonType.label": "String" } }, { "id": "54b7855b-8076-4dc5-bf48-004579b4fc8a", "name": "email", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${email}", "config": { "user.attribute": "email", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email", "jsonType.label": "String" } }, { "id": "72424f27-839c-456c-a74e-67f9736362fc", "name": "role list", "protocol": "saml", "protocolMapper": "saml-role-list-mapper", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } }, { "id": "4d8f2ff6-b537-4392-99a2-96a43845b4ee", "name": "username", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${username}", "config": { "user.attribute": "username", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "preferred_username", "jsonType.label": "String" } }, { "id": "7bde3192-50ca-4f75-857b-61aa09e8766c", "name": "family name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${familyName}", "config": { "user.attribute": "lastName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "family_name", "jsonType.label": "String" } }, { "id": "d18e512e-4027-4b71-b34f-4c93a6fa3aa2", "name": "full name", "protocol": "openid-connect", "protocolMapper": "oidc-full-name-mapper", "consentRequired": true, "consentText": "${fullName}", "config": { "id.token.claim": "true", "access.token.claim": "true" } } ], "useTemplateConfig": false, "useTemplateScope": false, "useTemplateMappers": false }, { "id": "b2a51131-b70f-493a-92c8-8464ad1494f7", "clientId": "security-admin-console", "name": "${client_security-admin-console}", "baseUrl": "/auth/admin/BluLogix/console/index.html", "surrogateAuthRequired": false, "enabled": true, "clientAuthenticatorType": "client-secret", "secret": "74ca6b66-0dee-451d-a25f-e6b3072bbcea", "redirectUris": [ "/auth/admin/BluLogix/console/*" ], "webOrigins": [], "notBefore": 0, "bearerOnly": false, "consentRequired": false, "standardFlowEnabled": true, "implicitFlowEnabled": false, "directAccessGrantsEnabled": false, "serviceAccountsEnabled": false, "publicClient": true, "frontchannelLogout": false, "attributes": {}, "fullScopeAllowed": false, "nodeReRegistrationTimeout": 0, "protocolMappers": [ { "id": "ba12433f-750d-425d-ad55-6e71ef48d57f", "name": "full name", "protocol": "openid-connect", "protocolMapper": "oidc-full-name-mapper", "consentRequired": true, "consentText": "${fullName}", "config": { "id.token.claim": "true", "access.token.claim": "true" } }, { "id": "cbc8a691-a30f-4685-b1d6-b01e02b1819d", "name": "username", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${username}", "config": { "user.attribute": "username", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "preferred_username", "jsonType.label": "String" } }, { "id": "8a2186ad-7fc3-4f76-b698-f9b9bc2f8226", "name": "family name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${familyName}", "config": { "user.attribute": "lastName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "family_name", "jsonType.label": "String" } }, { "id": "4f37c212-a357-4f1c-87cf-8317d3489e67", "name": "given name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${givenName}", "config": { "user.attribute": "firstName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "given_name", "jsonType.label": "String" } }, { "id": "1daabf0b-7276-4d3f-9003-c71e17615080", "name": "role list", "protocol": "saml", "protocolMapper": "saml-role-list-mapper", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } }, { "id": "21d66e88-ae45-44ed-8b06-821434e13c01", "name": "email", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${email}", "config": { "user.attribute": "email", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email", "jsonType.label": "String" } }, { "id": "9e91d808-107a-4a9e-8ca2-775aa0a6e39c", "name": "locale", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-attribute-mapper", "consentRequired": false, "consentText": "${locale}", "config": { "user.attribute": "locale", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "locale", "jsonType.label": "String" } } ], "useTemplateConfig": false, "useTemplateScope": false, "useTemplateMappers": false } ], "clientTemplates": [], "browserSecurityHeaders": { "xFrameOptions": "SAMEORIGIN", "contentSecurityPolicy": "frame-src 'self'" }, "smtpServer": { "password": "0785813567", "starttls": "true", "auth": "true", "port": "587", "host": "smtp.gmail.com", "from": "blulogix_noreply at blulogix.com", "user": "YasbPana at gmail.com" }, "loginTheme": "keycloak", "accountTheme": "keycloak", "adminTheme": "keycloak", "eventsEnabled": false, "eventsListeners": [ "jboss-logging" ], "enabledEventTypes": [], "adminEventsEnabled": false, "adminEventsDetailsEnabled": false, "internationalizationEnabled": false, "supportedLocales": [ "en", "es" ], "defaultLocale": "en", "authenticationFlows": [ { "id": "5e446bd6-5d70-43b4-a622-debd9c4a3e53", "alias": "Handle Existing Account", "description": "Handle what to do if there is existing account with same email/username like authenticated identity provider", "providerId": "basic-flow", "topLevel": false, "builtIn": true, "authenticationExecutions": [ { "authenticator": "idp-confirm-link", "requirement": "REQUIRED", "priority": 10, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "idp-email-verification", "requirement": "ALTERNATIVE", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false }, { "requirement": "ALTERNATIVE", "priority": 30, "flowAlias": "Verify Existing Account by Re-authentication", "userSetupAllowed": false, "autheticatorFlow": true } ] }, { "id": "52d9a25e-0c07-444d-b28d-42e7a24f1d11", "alias": "Verify Existing Account by Re-authentication", "description": "Reauthentication of existing account", "providerId": "basic-flow", "topLevel": false, "builtIn": true, "authenticationExecutions": [ { "authenticator": "idp-username-password-form", "requirement": "REQUIRED", "priority": 10, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "auth-otp-form", "requirement": "OPTIONAL", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false } ] }, { "id": "b4abfcba-2302-48ab-8ddb-c84bda02f139", "alias": "browser", "description": "browser based authentication", "providerId": "basic-flow", "topLevel": true, "builtIn": true, "authenticationExecutions": [ { "authenticator": "auth-cookie", "requirement": "ALTERNATIVE", "priority": 10, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "auth-spnego", "requirement": "DISABLED", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false }, { "requirement": "ALTERNATIVE", "priority": 30, "flowAlias": "forms", "userSetupAllowed": false, "autheticatorFlow": true } ] }, { "id": "776cf637-b7e8-4267-8564-7dcb6aa3ba9c", "alias": "clients", "description": "Base authentication for clients", "providerId": "client-flow", "topLevel": true, "builtIn": true, "authenticationExecutions": [ { "authenticator": "client-secret", "requirement": "ALTERNATIVE", "priority": 10, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "client-jwt", "requirement": "ALTERNATIVE", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false } ] }, { "id": "8bd0ddb1-60b4-4f4a-b8e8-8e26acc78e3b", "alias": "direct grant", "description": "OpenID Connect Resource Owner Grant", "providerId": "basic-flow", "topLevel": true, "builtIn": true, "authenticationExecutions": [ { "authenticator": "direct-grant-validate-username", "requirement": "REQUIRED", "priority": 10, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "direct-grant-validate-password", "requirement": "REQUIRED", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "direct-grant-validate-otp", "requirement": "OPTIONAL", "priority": 30, "userSetupAllowed": false, "autheticatorFlow": false } ] }, { "id": "e01eb3ab-23d4-48a4-87fd-3d55e3a373d2", "alias": "first broker login", "description": "Actions taken after first broker login with identity provider account, which is not yet linked to any Keycloak account", "providerId": "basic-flow", "topLevel": true, "builtIn": true, "authenticationExecutions": [ { "authenticatorConfig": "review profile config", "authenticator": "idp-review-profile", "requirement": "REQUIRED", "priority": 10, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticatorConfig": "create unique user config", "authenticator": "idp-create-user-if-unique", "requirement": "ALTERNATIVE", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false }, { "requirement": "ALTERNATIVE", "priority": 30, "flowAlias": "Handle Existing Account", "userSetupAllowed": false, "autheticatorFlow": true } ] }, { "id": "b17be33a-5ddf-43cc-95aa-2cd69b15b1ea", "alias": "forms", "description": "Username, password, otp and other auth forms.", "providerId": "basic-flow", "topLevel": false, "builtIn": true, "authenticationExecutions": [ { "authenticator": "auth-username-password-form", "requirement": "REQUIRED", "priority": 10, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "auth-otp-form", "requirement": "OPTIONAL", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false } ] }, { "id": "0e0d5e97-b785-4281-948c-d71cd1727214", "alias": "registration", "description": "registration flow", "providerId": "basic-flow", "topLevel": true, "builtIn": true, "authenticationExecutions": [ { "authenticator": "registration-page-form", "requirement": "REQUIRED", "priority": 10, "flowAlias": "registration form", "userSetupAllowed": false, "autheticatorFlow": true } ] }, { "id": "b62130e5-e565-4491-aa1d-7eb22b96340a", "alias": "registration form", "description": "registration form", "providerId": "form-flow", "topLevel": false, "builtIn": true, "authenticationExecutions": [ { "authenticator": "registration-user-creation", "requirement": "REQUIRED", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "registration-profile-action", "requirement": "REQUIRED", "priority": 40, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "registration-password-action", "requirement": "REQUIRED", "priority": 50, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "registration-recaptcha-action", "requirement": "DISABLED", "priority": 60, "userSetupAllowed": false, "autheticatorFlow": false } ] }, { "id": "d15ec48f-93a6-4a5f-81a5-0d8aa739b032", "alias": "reset credentials", "description": "Reset credentials for a user if they forgot their password or something", "providerId": "basic-flow", "topLevel": true, "builtIn": true, "authenticationExecutions": [ { "authenticator": "reset-credentials-choose-user", "requirement": "REQUIRED", "priority": 10, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "reset-credential-email", "requirement": "REQUIRED", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "reset-password", "requirement": "REQUIRED", "priority": 30, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "reset-otp", "requirement": "OPTIONAL", "priority": 40, "userSetupAllowed": false, "autheticatorFlow": false } ] } ], "authenticatorConfig": [ { "alias": "create unique user config", "config": { "require.password.update.after.registration": "false" } }, { "alias": "review profile config", "config": { "update.profile.on.first.login": "missing" } } ], "requiredActions": [ { "alias": "CONFIGURE_TOTP", "name": "Configure Totp", "providerId": "CONFIGURE_TOTP", "enabled": true, "defaultAction": false, "config": {} }, { "alias": "UPDATE_PASSWORD", "name": "Update Password", "providerId": "UPDATE_PASSWORD", "enabled": true, "defaultAction": false, "config": {} }, { "alias": "UPDATE_PROFILE", "name": "Update Profile", "providerId": "UPDATE_PROFILE", "enabled": true, "defaultAction": false, "config": {} }, { "alias": "VERIFY_EMAIL", "name": "Verify Email", "providerId": "VERIFY_EMAIL", "enabled": true, "defaultAction": false, "config": {} }, { "alias": "terms_and_conditions", "name": "Terms and Conditions", "providerId": "terms_and_conditions", "enabled": false, "defaultAction": false, "config": {} } ], "browserFlow": "browser", "registrationFlow": "registration", "directGrantFlow": "direct grant", "resetCredentialsFlow": "reset credentials", "clientAuthenticationFlow": "clients" }, { "id": "master", "realm": "master", "notBefore": 1457967229, "revokeRefreshToken": false, "accessTokenLifespan": 1800, "accessTokenLifespanForImplicitFlow": 900, "ssoSessionIdleTimeout": 1800, "ssoSessionMaxLifespan": 36000, "offlineSessionIdleTimeout": 2592000, "accessCodeLifespan": 60, "accessCodeLifespanUserAction": 300, "accessCodeLifespanLogin": 1800, "enabled": true, "sslRequired": "all", "registrationAllowed": false, "registrationEmailAsUsername": true, "rememberMe": true, "verifyEmail": true, "resetPasswordAllowed": true, "editUsernameAllowed": true, "bruteForceProtected": false, "maxFailureWaitSeconds": 900, "minimumQuickLoginWaitSeconds": 60, "waitIncrementSeconds": 60, "quickLoginCheckMilliSeconds": 1000, "maxDeltaTimeSeconds": 43200, "failureFactor": 30, "privateKey": "MIIEowIBAAKCAQEAnCdIogmClWETmRKSH8Iow53XCfVA8i55pDMpRe69jff1P86hGtSVSMknN1ZGVq1bHxbf9umIpzxUPTcDWMna2HpDOdm6I0oLLHXeMrIZfzaw3sClkuHF0mWJC6ykRzmdSqfEC3KoY+Qeg2IUAr5SzWFTB62C8mkcRcOdVvT3fTacZl+GEDHLUyhBB2rinT9HyEdSrj9Bi605kyR7ll8va0OVz+nOsw/TcDuP4Xa9OXrLPSNFafiS9e7PPAB33g/So0ZEH7xDx+13Hoq4MdtvXkn5/eRBU+20xg7AChImF17rYnCwrvqE5gZ8Hrtw6iqsLBB0uPGOP18m9epg2yClgwIDAQABAoIBAG2JUPX5XdSTaD/0OvR0KkwuKG4f0BMSbtmz2bvooKc5zJuZwoEjpiSMlinHJ0geCtFgJnL5lpZZR245bOuXjSBVg1rNVDj086mYdOly7VfDcYaP9JV4MmBIQT4jOImN7Lw1utuc7mpD1vOqlQbnowXWw3ubR0PsX5zAf1pENGdsDJNNgQXllMgSB+BkoWejiotsMQWyzivnoSkjCkAtSbRgK5sFU9wE5i54V4hjfFUaf5KthRXpAFnW1TsE05nzDMFcWKzw5+EFchPpURFk9dL/U8tPUgxQDBQIBwwOzBfZf8GyfbROazPd82VlNCm6XXrGyH9H7sL0RmncZlW8/MECgYEA95GBR1r1hVLi2PtZZpGnlN22TDqfT9IAteQNc2j9oDAE5C2Ex6Q0C/tNvW8PYDTZAAQlt/QEzMfZemqOFAlpQ8w0UnywWYc5NGS+0ZBIn+gYMZzAp+/f4gT5tO/IChsRwTOTpKrYTU+7gKkNJWe3FO8xzk1xdLMrRTdGUtCDmBkCgYEAoXjAdlSd4ykEhXVKNR87vOanOvbYKmYLr+T4f0K+ravanW+ajyto/JtnuAZ9WB1L2vbOmXKTwj5v8ulnFQ2GVYaWIZvdiP3rBCY7VZwJwpwN+ODjSQyMYmbNqLGclzcY2CacAkn2m0ZSP3HkDoc0RNxPAZ9JOfxFSvUKpleTTfsCgYAHcg3USo0FxHdkFTMcHZdPp9datYyjBurUjZZF+UtfbPJItoG+y1ZxYc51uwhYWV6JXJaR0LnwOrZ0sw2w1pOe4V5VeMCJAMMcq0b94Hv+qylHHLLCmjk+f+3OnkOC4kuHZviyxBybPqGh/fOSQ2tDKupxjOyzmMvdWgs4ZGMAyQKBgAmHEXwp9AMCWZTyXcWSqTi1N2rgQ9MEoG3picwgiRXATS769di6zAATv2P5Zg379IzgAULGovdULdDcesugN6v2PAeRpdm+ec6N3vRnN6A3CxADXQXjaqknvbzVdhLqGloutQfhi16QIKxDsRw2WBw0D6ld17lHLGOG3/D+u99fAoGBAJb7KBJtcE7CuBeLJ42Vq4WCXj1xDq8Aj3ZQ4TFkqlEusxpnP99eADSbbQ6IDTN9uwROnNer2iM3lNceHBB3oCCMLAykf6HGxrjFseKWVZYLY73Q/ITPjWxiAD/sCNAinHTO2bA3JZyQmaRJ2Ul1pZVxnvFgl3t3M9DifnaSyH65", "publicKey": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnCdIogmClWETmRKSH8Iow53XCfVA8i55pDMpRe69jff1P86hGtSVSMknN1ZGVq1bHxbf9umIpzxUPTcDWMna2HpDOdm6I0oLLHXeMrIZfzaw3sClkuHF0mWJC6ykRzmdSqfEC3KoY+Qeg2IUAr5SzWFTB62C8mkcRcOdVvT3fTacZl+GEDHLUyhBB2rinT9HyEdSrj9Bi605kyR7ll8va0OVz+nOsw/TcDuP4Xa9OXrLPSNFafiS9e7PPAB33g/So0ZEH7xDx+13Hoq4MdtvXkn5/eRBU+20xg7AChImF17rYnCwrvqE5gZ8Hrtw6iqsLBB0uPGOP18m9epg2yClgwIDAQAB", "certificate": "MIICmzCCAYMCBgFSXlE/DDANBgkqhkiG9w0BAQsFADARMQ8wDQYDVQQDDAZtYXN0ZXIwHhcNMTYwMTIwMDkxMzQ4WhcNMjYwMTIwMDkxNTI4WjARMQ8wDQYDVQQDDAZtYXN0ZXIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCcJ0iiCYKVYROZEpIfwijDndcJ9UDyLnmkMylF7r2N9/U/zqEa1JVIySc3VkZWrVsfFt/26YinPFQ9NwNYydrYekM52bojSgssdd4yshl/NrDewKWS4cXSZYkLrKRHOZ1Kp8QLcqhj5B6DYhQCvlLNYVMHrYLyaRxFw51W9Pd9NpxmX4YQMctTKEEHauKdP0fIR1KuP0GLrTmTJHuWXy9rQ5XP6c6zD9NwO4/hdr05ess9I0Vp+JL17s88AHfeD9KjRkQfvEPH7Xceirgx229eSfn95EFT7bTGDsAKEiYXXuticLCu+oTmBnweu3DqKqwsEHS48Y4/Xyb16mDbIKWDAgMBAAEwDQYJKoZIhvcNAQELBQADggEBACz0belJeUpPqMejt7OQG0UJ+ZX7z7SXFqGVQi8gQGChLVEzKMsbpOSSV0tWvuuBkrIIctIrtdCBjNylBrCgT42x5lEFx7PR3HbkmAG4DYH7reMWqIwHcvMILC8R+4isH3SiWxUywy8HSxTRKwOXXE2DWkwtppzis8ijnm73BmUTvX+bTphbGFVK90etfMaZLLDTWSnG3ZMVI2H9L54z2Zk5omcQn9JLg0RI/TQ6r3xJtJ2blb/coWiar5moCrDcbYHy7wh/845Xj08Srd0yHc4nv07R0utfM8nNP6N8Y12WHyIyDZMErPWeQckJOv3wl67rw65Ae3YF6Mq5b9lzhZ0=", "codeSecret": "4f25a961-53eb-45c6-baa1-415522c40b2d", "roles": { "realm": [ { "id": "19a7d556-a847-4d07-8ada-a2f1df48d9f1", "name": "admin", "description": "${role_admin}", "scopeParamRequired": false, "composite": true, "composites": { "realm": [ "create-realm" ], "client": { "cis-p-T102-0000002-realm": [ "create-client", "view-identity-providers", "manage-realm", "manage-clients", "view-realm", "manage-identity-providers", "view-events", "view-clients", "view-users", "manage-events", "impersonation", "manage-users" ], "Test-realm": [ "manage-events", "view-events", "manage-clients", "create-client", "view-users", "manage-realm", "view-clients", "view-realm", "view-identity-providers", "manage-identity-providers", "impersonation", "manage-users" ], "BluLogix-realm": [ "view-realm", "manage-events", "manage-users", "manage-realm", "view-clients", "impersonation", "view-events", "manage-identity-providers", "create-client", "view-identity-providers", "view-users", "manage-clients" ], "master-realm": [ "view-users", "view-identity-providers", "manage-users", "manage-identity-providers", "view-clients", "view-realm", "manage-realm", "create-client", "view-events", "manage-events", "impersonation", "manage-clients" ] } } }, { "id": "62ed373a-89fd-41bb-8373-19a6bbdcd4c1", "name": "create-realm", "description": "${role_create-realm}", "scopeParamRequired": false, "composite": false }, { "id": "1d5b3a93-91c5-4de8-888f-9e88f55cd66f", "name": "offline_access", "description": "${role_offline-access}", "scopeParamRequired": true, "composite": false } ], "client": { "cis-p-T102-0000002-realm": [ { "id": "a206e5e8-922a-4674-908f-c7c9e747ba38", "name": "view-realm", "description": "${role_view-realm}", "scopeParamRequired": false, "composite": false }, { "id": "b572ad1c-0aa7-4276-9858-e57478219ed1", "name": "create-client", "description": "${role_create-client}", "scopeParamRequired": false, "composite": false }, { "id": "89d073cc-19c6-42b6-a67c-b2eed96b172a", "name": "manage-events", "description": "${role_manage-events}", "scopeParamRequired": false, "composite": false }, { "id": "f8cea2bd-020e-4038-9452-e27a549db675", "name": "manage-identity-providers", "description": "${role_manage-identity-providers}", "scopeParamRequired": false, "composite": false }, { "id": "e6860fc5-57d6-4ca6-bf69-5007bad4f050", "name": "view-events", "description": "${role_view-events}", "scopeParamRequired": false, "composite": false }, { "id": "8283eb68-6b42-4e78-8871-b77b22b8acca", "name": "impersonation", "description": "${role_impersonation}", "scopeParamRequired": false, "composite": false }, { "id": "bd7b7062-b4b8-4556-9b6f-43b6dcfcf4b6", "name": "view-clients", "description": "${role_view-clients}", "scopeParamRequired": false, "composite": false }, { "id": "c79dfddc-a262-46b0-bd6b-89ad53019675", "name": "manage-users", "description": "${role_manage-users}", "scopeParamRequired": false, "composite": false }, { "id": "3d7aacd1-02a5-42a8-8a25-a0bb01af05be", "name": "view-identity-providers", "description": "${role_view-identity-providers}", "scopeParamRequired": false, "composite": false }, { "id": "6107d4b3-9c71-48d0-8de5-5151a4b42cbd", "name": "manage-realm", "description": "${role_manage-realm}", "scopeParamRequired": false, "composite": false }, { "id": "08268084-f717-4d96-9dd3-19d069d9f737", "name": "manage-clients", "description": "${role_manage-clients}", "scopeParamRequired": false, "composite": false }, { "id": "a463dd0e-27fa-4679-b664-87cbe1a235d9", "name": "view-users", "description": "${role_view-users}", "scopeParamRequired": false, "composite": false } ], "Test-realm": [ { "id": "0a5b0184-c697-4c68-b612-04a56a8ab3ec", "name": "manage-realm", "description": "${role_manage-realm}", "scopeParamRequired": false, "composite": false }, { "id": "9c1f3489-920a-4fff-b14c-1ea55a5a1e24", "name": "manage-events", "description": "${role_manage-events}", "scopeParamRequired": false, "composite": false }, { "id": "2e5ab0c7-68af-4241-8517-709f7324a3ff", "name": "manage-clients", "description": "${role_manage-clients}", "scopeParamRequired": false, "composite": false }, { "id": "2d9c1052-9e79-4f18-9c44-4d14c7b3876c", "name": "impersonation", "description": "${role_impersonation}", "scopeParamRequired": false, "composite": false }, { "id": "396d8fc0-78aa-4a71-a72b-4fe1a3250ffd", "name": "create-client", "description": "${role_create-client}", "scopeParamRequired": false, "composite": false }, { "id": "bc180464-33a9-4594-acaf-7c9832fee529", "name": "view-realm", "description": "${role_view-realm}", "scopeParamRequired": false, "composite": false }, { "id": "15d68be9-04a0-4881-82a8-f3aeef2105f6", "name": "view-events", "description": "${role_view-events}", "scopeParamRequired": false, "composite": false }, { "id": "dd3b9c80-0778-4ce4-813a-ef98f2f076fa", "name": "manage-users", "description": "${role_manage-users}", "scopeParamRequired": false, "composite": false }, { "id": "ce4a3198-70b2-4401-bf4b-7cf7fe336a0d", "name": "view-identity-providers", "description": "${role_view-identity-providers}", "scopeParamRequired": false, "composite": false }, { "id": "77844130-7f1b-4634-adc2-e785f3eab3da", "name": "manage-identity-providers", "description": "${role_manage-identity-providers}", "scopeParamRequired": false, "composite": false }, { "id": "2ab52e4f-06df-4370-83c1-8e74cb4dbade", "name": "view-users", "description": "${role_view-users}", "scopeParamRequired": false, "composite": false }, { "id": "4cbe5e5f-178d-47b7-9a02-ee2648269522", "name": "view-clients", "description": "${role_view-clients}", "scopeParamRequired": false, "composite": false } ], "security-admin-console": [], "BluLogix-realm": [ { "id": "3d6b7c66-f8d1-47b4-8c3d-f5d64929a0f6", "name": "view-events", "description": "${role_view-events}", "scopeParamRequired": false, "composite": false }, { "id": "bd6f06ae-3aa6-4b8d-9b1d-faaa77f4b38e", "name": "view-users", "description": "${role_view-users}", "scopeParamRequired": false, "composite": false }, { "id": "8e30faf0-7dfa-4be9-80f5-1ee7779dd625", "name": "view-clients", "description": "${role_view-clients}", "scopeParamRequired": false, "composite": false }, { "id": "3285810d-c154-44ca-8208-b3a847c6c668", "name": "manage-events", "description": "${role_manage-events}", "scopeParamRequired": false, "composite": false }, { "id": "41eb2f3b-f8fd-4190-be10-c1809deb2a57", "name": "manage-users", "description": "${role_manage-users}", "scopeParamRequired": false, "composite": false }, { "id": "b4caa233-a301-4dd8-8503-c01e20a9a501", "name": "manage-realm", "description": "${role_manage-realm}", "scopeParamRequired": false, "composite": false }, { "id": "5e386d9f-b6b4-46ed-b445-cbf276d54d61", "name": "manage-identity-providers", "description": "${role_manage-identity-providers}", "scopeParamRequired": false, "composite": false }, { "id": "b4a745de-5475-4342-a5cd-fa2c2ecfc8b3", "name": "view-realm", "description": "${role_view-realm}", "scopeParamRequired": false, "composite": false }, { "id": "92822b7b-3ef8-473a-b78b-cfa05ac2aa8a", "name": "impersonation", "description": "${role_impersonation}", "scopeParamRequired": false, "composite": false }, { "id": "5c2eab59-a99b-4e6f-b2da-208f85624dff", "name": "manage-clients", "description": "${role_manage-clients}", "scopeParamRequired": false, "composite": false }, { "id": "d36f56de-038c-4ab9-903f-e4f09414ef87", "name": "create-client", "description": "${role_create-client}", "scopeParamRequired": false, "composite": false }, { "id": "b540a90a-b223-42eb-b838-a911442f0aa1", "name": "view-identity-providers", "description": "${role_view-identity-providers}", "scopeParamRequired": false, "composite": false } ], "admin-cli": [], "CCCCC": [], "broker": [ { "id": "eb9bb617-33d3-4842-bc88-4b89495a89fd", "name": "read-token", "description": "${role_read-token}", "scopeParamRequired": false, "composite": false } ], "master-realm": [ { "id": "35aa428c-f6e2-4673-9226-8389f6ef315d", "name": "manage-realm", "description": "${role_manage-realm}", "scopeParamRequired": false, "composite": false }, { "id": "77983826-60b6-4b6e-bd94-fb34a62ad1b1", "name": "manage-events", "description": "${role_manage-events}", "scopeParamRequired": false, "composite": false }, { "id": "dccb4ae9-85c6-4efc-a061-fc5f72ceebff", "name": "view-users", "description": "${role_view-users}", "scopeParamRequired": false, "composite": false }, { "id": "9948b0f1-e8cd-4350-a60e-06e43e9216c0", "name": "impersonation", "description": "${role_impersonation}", "scopeParamRequired": false, "composite": false }, { "id": "f4b31534-4919-41e9-8998-3f0643a12d94", "name": "manage-identity-providers", "description": "${role_manage-identity-providers}", "scopeParamRequired": false, "composite": false }, { "id": "51f3eebd-df90-4ca5-bcec-b5912361f2e2", "name": "view-clients", "description": "${role_view-clients}", "scopeParamRequired": false, "composite": false }, { "id": "f3f9eada-3f0b-4b42-9166-bd63037abaf6", "name": "view-events", "description": "${role_view-events}", "scopeParamRequired": false, "composite": false }, { "id": "abaa56df-aa57-4d5e-b1b6-fcf3dabdb8e8", "name": "view-identity-providers", "description": "${role_view-identity-providers}", "scopeParamRequired": false, "composite": false }, { "id": "221af9bb-eb9c-4063-8975-00d09770da90", "name": "view-realm", "description": "${role_view-realm}", "scopeParamRequired": false, "composite": false }, { "id": "120acc78-b6d5-40c1-a274-04dccc0ca204", "name": "manage-users", "description": "${role_manage-users}", "scopeParamRequired": false, "composite": false }, { "id": "45c1fcd7-715e-4f25-a67a-826046583ea2", "name": "create-client", "description": "${role_create-client}", "scopeParamRequired": false, "composite": false }, { "id": "bebb6675-5d87-4070-adfa-ee592c7b4354", "name": "manage-clients", "description": "${role_manage-clients}", "scopeParamRequired": false, "composite": false } ], "account": [ { "id": "6ddadb41-aaec-41c9-9cb0-9f2d35f6b6c3", "name": "manage-account", "description": "${role_manage-account}", "scopeParamRequired": false, "composite": false }, { "id": "4903c5ff-d365-4261-afbf-ce654e4ba1df", "name": "view-profile", "description": "${role_view-profile}", "scopeParamRequired": false, "composite": false } ] } }, "groups": [], "defaultRoles": [ "offline_access" ], "requiredCredentials": [ "password" ], "otpPolicyType": "totp", "otpPolicyAlgorithm": "HmacSHA1", "otpPolicyInitialCounter": 0, "otpPolicyDigits": 6, "otpPolicyLookAheadWindow": 1, "otpPolicyPeriod": 30, "users": [], "scopeMappings": [ { "client": "admin-cli", "roles": [ "admin" ] }, { "client": "security-admin-console", "roles": [ "admin" ] } ], "clients": [ { "id": "d4e09f02-c339-4bca-9a89-e1547e59c07d", "clientId": "BluLogix-realm", "name": "BluLogix Realm", "surrogateAuthRequired": false, "enabled": true, "clientAuthenticatorType": "client-secret", "secret": "8ec0bb88-f731-4cef-98d1-cb42c6ce6d9a", "redirectUris": [], "webOrigins": [], "notBefore": 0, "bearerOnly": true, "consentRequired": false, "standardFlowEnabled": true, "implicitFlowEnabled": false, "directAccessGrantsEnabled": false, "serviceAccountsEnabled": false, "publicClient": false, "frontchannelLogout": false, "attributes": {}, "fullScopeAllowed": true, "nodeReRegistrationTimeout": 0, "protocolMappers": [ { "id": "7738d536-e85e-4a17-9354-44c522f3fa82", "name": "family name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${familyName}", "config": { "user.attribute": "lastName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "family_name", "jsonType.label": "String" } }, { "id": "1b255962-5579-4512-9979-19283638279c", "name": "role list", "protocol": "saml", "protocolMapper": "saml-role-list-mapper", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } }, { "id": "76d714dd-2faa-4696-8bc4-84c3a38a9948", "name": "username", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${username}", "config": { "user.attribute": "username", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "preferred_username", "jsonType.label": "String" } }, { "id": "85fe191c-d3f4-45da-96ef-81abdcb0e3f8", "name": "email", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${email}", "config": { "user.attribute": "email", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email", "jsonType.label": "String" } }, { "id": "75a9709e-88b0-47d6-8004-e86acd4247f8", "name": "given name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${givenName}", "config": { "user.attribute": "firstName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "given_name", "jsonType.label": "String" } }, { "id": "6b37a02c-8090-469a-a819-1cae558fcd17", "name": "full name", "protocol": "openid-connect", "protocolMapper": "oidc-full-name-mapper", "consentRequired": true, "consentText": "${fullName}", "config": { "id.token.claim": "true", "access.token.claim": "true" } } ], "useTemplateConfig": false, "useTemplateScope": false, "useTemplateMappers": false }, { "id": "d02cef07-a40a-46d7-858b-54e5aeaa595e", "clientId": "CCCCC", "surrogateAuthRequired": false, "enabled": true, "clientAuthenticatorType": "client-secret", "secret": "cebbc92a-ab20-47a9-9ab6-5b5e769a74ab", "redirectUris": [], "webOrigins": [], "notBefore": 0, "bearerOnly": false, "consentRequired": false, "standardFlowEnabled": true, "implicitFlowEnabled": false, "directAccessGrantsEnabled": true, "serviceAccountsEnabled": false, "publicClient": true, "frontchannelLogout": false, "protocol": "openid-connect", "attributes": {}, "fullScopeAllowed": true, "nodeReRegistrationTimeout": -1, "protocolMappers": [ { "id": "4457114c-5c75-4a57-af73-6fc7ce4baccf", "name": "full name", "protocol": "openid-connect", "protocolMapper": "oidc-full-name-mapper", "consentRequired": true, "consentText": "${fullName}", "config": { "id.token.claim": "true", "access.token.claim": "true" } }, { "id": "31036a99-0566-4e64-b544-8f7dbb0feaea", "name": "role list", "protocol": "saml", "protocolMapper": "saml-role-list-mapper", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } }, { "id": "d66825d4-36cd-401e-ad13-b5118b69b8f3", "name": "email", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${email}", "config": { "user.attribute": "email", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email", "jsonType.label": "String" } }, { "id": "4af4cdb6-c124-476c-bc22-f048c41635cd", "name": "family name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${familyName}", "config": { "user.attribute": "lastName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "family_name", "jsonType.label": "String" } }, { "id": "8b488858-ffb4-4596-a797-663f18adcc18", "name": "username", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${username}", "config": { "user.attribute": "username", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "preferred_username", "jsonType.label": "String" } }, { "id": "ec30ea4b-f333-4fd4-81c4-812cc25aa62c", "name": "given name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${givenName}", "config": { "user.attribute": "firstName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "given_name", "jsonType.label": "String" } } ], "useTemplateConfig": false, "useTemplateScope": false, "useTemplateMappers": false }, { "id": "370159cb-6579-4eca-a871-b1b033d9955e", "clientId": "Test-realm", "name": "Test Realm", "surrogateAuthRequired": false, "enabled": true, "clientAuthenticatorType": "client-secret", "secret": "ea10f2ce-9e2d-4406-80b2-4abb01279ca7", "redirectUris": [], "webOrigins": [], "notBefore": 0, "bearerOnly": true, "consentRequired": false, "standardFlowEnabled": true, "implicitFlowEnabled": false, "directAccessGrantsEnabled": false, "serviceAccountsEnabled": false, "publicClient": false, "frontchannelLogout": false, "attributes": {}, "fullScopeAllowed": true, "nodeReRegistrationTimeout": 0, "protocolMappers": [ { "id": "8d190663-f649-47f9-bb70-164d91d01201", "name": "family name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${familyName}", "config": { "user.attribute": "lastName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "family_name", "jsonType.label": "String" } }, { "id": "fe2db5c6-4d84-467d-9d20-ddf57dd63cc7", "name": "username", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${username}", "config": { "user.attribute": "username", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "preferred_username", "jsonType.label": "String" } }, { "id": "34f5f093-da1f-4dd1-9a52-4fa7055fdc45", "name": "given name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${givenName}", "config": { "user.attribute": "firstName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "given_name", "jsonType.label": "String" } }, { "id": "2ef71afa-0bca-42d7-aad6-284179da382a", "name": "email", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${email}", "config": { "user.attribute": "email", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email", "jsonType.label": "String" } }, { "id": "b6b86c08-eabc-4131-bd42-28e496dd181b", "name": "full name", "protocol": "openid-connect", "protocolMapper": "oidc-full-name-mapper", "consentRequired": true, "consentText": "${fullName}", "config": { "id.token.claim": "true", "access.token.claim": "true" } }, { "id": "ec1f25f5-5aa8-422f-ab90-14b3bb4f32e1", "name": "role list", "protocol": "saml", "protocolMapper": "saml-role-list-mapper", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } } ], "useTemplateConfig": false, "useTemplateScope": false, "useTemplateMappers": false }, { "id": "7f090257-ceec-429d-b0e3-947a4fcfe3ea", "clientId": "account", "name": "${client_account}", "baseUrl": "/auth/realms/master/account", "surrogateAuthRequired": false, "enabled": true, "clientAuthenticatorType": "client-secret", "secret": "1b470e66-93ed-46d7-84ff-790ed2cff54f", "defaultRoles": [ "view-profile", "manage-account" ], "redirectUris": [ "/auth/realms/master/account/*" ], "webOrigins": [], "notBefore": 0, "bearerOnly": false, "consentRequired": false, "standardFlowEnabled": true, "implicitFlowEnabled": false, "directAccessGrantsEnabled": true, "serviceAccountsEnabled": false, "publicClient": false, "frontchannelLogout": false, "protocol": "openid-connect", "attributes": { "saml.assertion.signature": "false", "saml.force.post.binding": "false", "saml.multivalued.roles": "false", "saml.encrypt": "false", "saml_force_name_id_format": "false", "saml.client.signature": "false", "saml.authnstatement": "false", "saml.server.signature": "false" }, "fullScopeAllowed": false, "nodeReRegistrationTimeout": 0, "protocolMappers": [ { "id": "0b68f5a9-559d-4b0e-bf3f-c13831964c00", "name": "username", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${username}", "config": { "user.attribute": "username", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "preferred_username", "jsonType.label": "String" } }, { "id": "59386658-2c1d-4e55-b550-67353cbe1a39", "name": "email", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${email}", "config": { "user.attribute": "email", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email", "jsonType.label": "String" } }, { "id": "b3c975b9-8840-492f-9119-5d4f11c3a24d", "name": "role list", "protocol": "saml", "protocolMapper": "saml-role-list-mapper", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } }, { "id": "a05f2141-e8d5-4868-874e-0f8123fae6b0", "name": "given name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${givenName}", "config": { "user.attribute": "firstName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "given_name", "jsonType.label": "String" } }, { "id": "93f5ffeb-8087-47fa-98df-2a2babf16b57", "name": "family name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${familyName}", "config": { "user.attribute": "lastName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "family_name", "jsonType.label": "String" } }, { "id": "d590fefc-d10a-4e55-8b53-12c5f67c218c", "name": "full name", "protocol": "openid-connect", "protocolMapper": "oidc-full-name-mapper", "consentRequired": true, "consentText": "${fullName}", "config": { "id.token.claim": "true", "access.token.claim": "true" } } ], "useTemplateConfig": false, "useTemplateScope": false, "useTemplateMappers": false }, { "id": "f73ad9b7-f192-40eb-a3d3-bb9599272b04", "clientId": "admin-cli", "name": "${client_admin-cli}", "surrogateAuthRequired": false, "enabled": true, "clientAuthenticatorType": "client-secret", "secret": "548c591d-69af-46bf-a223-c60f243a34b6", "redirectUris": [], "webOrigins": [], "notBefore": 0, "bearerOnly": false, "consentRequired": false, "standardFlowEnabled": false, "implicitFlowEnabled": false, "directAccessGrantsEnabled": true, "serviceAccountsEnabled": false, "publicClient": true, "frontchannelLogout": false, "attributes": {}, "fullScopeAllowed": false, "nodeReRegistrationTimeout": 0, "protocolMappers": [ { "id": "ce0fcf42-0def-425c-94a9-dc5f4036d01c", "name": "role list", "protocol": "saml", "protocolMapper": "saml-role-list-mapper", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } }, { "id": "725f56a2-4e80-44e4-9eaf-1e1fbd1b33ad", "name": "family name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${familyName}", "config": { "user.attribute": "lastName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "family_name", "jsonType.label": "String" } }, { "id": "2797d9ed-d4fe-4f17-b69b-136df6a5f761", "name": "username", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${username}", "config": { "user.attribute": "username", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "preferred_username", "jsonType.label": "String" } }, { "id": "8e860be4-c4c7-41b1-a292-ee3120cf0687", "name": "given name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${givenName}", "config": { "user.attribute": "firstName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "given_name", "jsonType.label": "String" } }, { "id": "45e548dd-96b7-4507-9dfc-644f9697ba7b", "name": "full name", "protocol": "openid-connect", "protocolMapper": "oidc-full-name-mapper", "consentRequired": true, "consentText": "${fullName}", "config": { "id.token.claim": "true", "access.token.claim": "true" } }, { "id": "127b9e1a-af40-4475-9cd8-c2348a65daa9", "name": "email", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${email}", "config": { "user.attribute": "email", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email", "jsonType.label": "String" } } ], "useTemplateConfig": false, "useTemplateScope": false, "useTemplateMappers": false }, { "id": "ee09e5cc-7afb-45a3-8798-25cd4041adec", "clientId": "broker", "name": "${client_broker}", "surrogateAuthRequired": false, "enabled": true, "clientAuthenticatorType": "client-secret", "secret": "a3c847c4-f945-44a0-86e3-399ab3cef173", "redirectUris": [], "webOrigins": [], "notBefore": 0, "bearerOnly": false, "consentRequired": false, "standardFlowEnabled": true, "implicitFlowEnabled": false, "directAccessGrantsEnabled": false, "serviceAccountsEnabled": false, "publicClient": false, "frontchannelLogout": false, "attributes": {}, "fullScopeAllowed": false, "nodeReRegistrationTimeout": 0, "protocolMappers": [ { "id": "53431658-f4c7-4389-a132-592f0975f1e7", "name": "given name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${givenName}", "config": { "user.attribute": "firstName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "given_name", "jsonType.label": "String" } }, { "id": "32cb41c8-1fa7-423a-bb0a-ed63d3f667b8", "name": "username", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${username}", "config": { "user.attribute": "username", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "preferred_username", "jsonType.label": "String" } }, { "id": "746f7515-5801-415d-8dde-4b14f8584d82", "name": "full name", "protocol": "openid-connect", "protocolMapper": "oidc-full-name-mapper", "consentRequired": true, "consentText": "${fullName}", "config": { "id.token.claim": "true", "access.token.claim": "true" } }, { "id": "95f206ce-9067-444d-97e8-adeabf86742d", "name": "email", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${email}", "config": { "user.attribute": "email", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email", "jsonType.label": "String" } }, { "id": "67abc4e7-32f8-4397-9c21-fa8784e24f34", "name": "family name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${familyName}", "config": { "user.attribute": "lastName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "family_name", "jsonType.label": "String" } }, { "id": "8d65c546-a4b1-4d26-ad22-7df862e54158", "name": "role list", "protocol": "saml", "protocolMapper": "saml-role-list-mapper", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } } ], "useTemplateConfig": false, "useTemplateScope": false, "useTemplateMappers": false }, { "id": "f17f466d-ab00-45a9-b1ed-a958816fc14e", "clientId": "cis-p-T102-0000002-realm", "name": "cis-p-T102-0000002 Realm", "surrogateAuthRequired": false, "enabled": true, "clientAuthenticatorType": "client-secret", "secret": "6bbb6b42-2fe2-4a6d-8426-8a0cd318958f", "redirectUris": [], "webOrigins": [], "notBefore": 0, "bearerOnly": true, "consentRequired": false, "standardFlowEnabled": true, "implicitFlowEnabled": false, "directAccessGrantsEnabled": false, "serviceAccountsEnabled": false, "publicClient": false, "frontchannelLogout": false, "attributes": {}, "fullScopeAllowed": true, "nodeReRegistrationTimeout": 0, "protocolMappers": [ { "id": "11e3f127-65c5-410e-8497-1344f9c011d2", "name": "email", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${email}", "config": { "user.attribute": "email", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email", "jsonType.label": "String" } }, { "id": "b2ec893d-c734-4893-8d38-005b9e31ccb0", "name": "family name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${familyName}", "config": { "user.attribute": "lastName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "family_name", "jsonType.label": "String" } }, { "id": "8980f64e-9691-4f53-9684-b7cb6ef0c5eb", "name": "full name", "protocol": "openid-connect", "protocolMapper": "oidc-full-name-mapper", "consentRequired": true, "consentText": "${fullName}", "config": { "id.token.claim": "true", "access.token.claim": "true" } }, { "id": "3abd37d0-8a9b-4151-88f9-5df9c191dcfb", "name": "username", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${username}", "config": { "user.attribute": "username", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "preferred_username", "jsonType.label": "String" } }, { "id": "9dac32df-b5a7-4e4a-b477-d083f9d378b5", "name": "role list", "protocol": "saml", "protocolMapper": "saml-role-list-mapper", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } }, { "id": "5feec88b-e070-4c8a-a7a0-356a3b66fff1", "name": "given name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${givenName}", "config": { "user.attribute": "firstName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "given_name", "jsonType.label": "String" } } ], "useTemplateConfig": false, "useTemplateScope": false, "useTemplateMappers": false }, { "id": "1ea35428-f6c8-47e0-91b2-17470bd3f963", "clientId": "master-realm", "name": "master Realm", "surrogateAuthRequired": false, "enabled": true, "clientAuthenticatorType": "client-secret", "secret": "62223e3a-d23e-4c0d-bd5e-52926aa486f7", "redirectUris": [], "webOrigins": [], "notBefore": 0, "bearerOnly": true, "consentRequired": false, "standardFlowEnabled": true, "implicitFlowEnabled": false, "directAccessGrantsEnabled": false, "serviceAccountsEnabled": false, "publicClient": false, "frontchannelLogout": false, "attributes": {}, "fullScopeAllowed": true, "nodeReRegistrationTimeout": 0, "protocolMappers": [ { "id": "05c11812-4ee8-4673-bdc7-6c92f9a259ef", "name": "username", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${username}", "config": { "user.attribute": "username", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "preferred_username", "jsonType.label": "String" } }, { "id": "ebb36dc1-925b-4b37-bd5c-ed1330b5a538", "name": "family name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${familyName}", "config": { "user.attribute": "lastName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "family_name", "jsonType.label": "String" } }, { "id": "11961162-9d1a-4b65-a7b9-fe5e09467f15", "name": "role list", "protocol": "saml", "protocolMapper": "saml-role-list-mapper", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } }, { "id": "0d17f3fb-5525-432a-b09f-07108948039b", "name": "email", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${email}", "config": { "user.attribute": "email", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email", "jsonType.label": "String" } }, { "id": "6ee143c0-a555-4382-aa2d-05c795d96d14", "name": "full name", "protocol": "openid-connect", "protocolMapper": "oidc-full-name-mapper", "consentRequired": true, "consentText": "${fullName}", "config": { "id.token.claim": "true", "access.token.claim": "true" } }, { "id": "5923bf76-91d7-47c3-8e92-9d696f65f2e8", "name": "given name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${givenName}", "config": { "user.attribute": "firstName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "given_name", "jsonType.label": "String" } } ], "useTemplateConfig": false, "useTemplateScope": false, "useTemplateMappers": false }, { "id": "88191502-6b85-4b3b-92a0-5c211e211f40", "clientId": "security-admin-console", "name": "${client_security-admin-console}", "baseUrl": "/auth/admin/master/console/index.html", "surrogateAuthRequired": false, "enabled": true, "clientAuthenticatorType": "client-secret", "secret": "d8d0f1a1-0f0c-4ebb-a1c6-0fdee036548a", "redirectUris": [ "/auth/admin/master/console/*" ], "webOrigins": [], "notBefore": 0, "bearerOnly": false, "consentRequired": false, "standardFlowEnabled": true, "implicitFlowEnabled": false, "directAccessGrantsEnabled": true, "serviceAccountsEnabled": false, "publicClient": true, "frontchannelLogout": false, "protocol": "openid-connect", "attributes": { "saml.assertion.signature": "false", "saml.force.post.binding": "false", "saml.multivalued.roles": "false", "saml.encrypt": "false", "saml_force_name_id_format": "false", "saml.client.signature": "false", "saml.authnstatement": "false", "saml.server.signature": "false" }, "fullScopeAllowed": false, "nodeReRegistrationTimeout": 0, "protocolMappers": [ { "id": "bf585693-cbc1-4629-a76a-44d15247d635", "name": "locale", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-attribute-mapper", "consentRequired": false, "consentText": "${locale}", "config": { "user.attribute": "locale", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "locale", "jsonType.label": "String" } }, { "id": "172b6c39-0059-41d8-bcf0-fe9069c8f7a0", "name": "email", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${email}", "config": { "user.attribute": "email", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email", "jsonType.label": "String" } }, { "id": "c8442ee7-b9d0-4e22-bd1c-3092e5d37b44", "name": "given name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${givenName}", "config": { "user.attribute": "firstName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "given_name", "jsonType.label": "String" } }, { "id": "2a7d9620-2ec4-401a-acab-ebb5b58b1f2e", "name": "family name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${familyName}", "config": { "user.attribute": "lastName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "family_name", "jsonType.label": "String" } }, { "id": "b669b98b-f94b-4d84-9f85-f62f4c24bb06", "name": "full name", "protocol": "openid-connect", "protocolMapper": "oidc-full-name-mapper", "consentRequired": true, "consentText": "${fullName}", "config": { "id.token.claim": "true", "access.token.claim": "true" } }, { "id": "42174dba-cfe8-4fac-99ea-b0e949b36dee", "name": "role list", "protocol": "saml", "protocolMapper": "saml-role-list-mapper", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } }, { "id": "d946b1c2-9213-49d8-90aa-863a9c7dc158", "name": "username", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${username}", "config": { "user.attribute": "username", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "preferred_username", "jsonType.label": "String" } } ], "useTemplateConfig": false, "useTemplateScope": false, "useTemplateMappers": false } ], "clientTemplates": [], "browserSecurityHeaders": { "xFrameOptions": "SAMEORIGIN", "contentSecurityPolicy": "frame-src 'self'" }, "smtpServer": { "password": "0785813567", "starttls": "true", "auth": "true", "port": "587", "host": "smtp.gmail.com", "from": "YasbPana at gmail.com", "ssl": "false", "user": "YasbPana at gmail.com" }, "eventsEnabled": false, "eventsListeners": [ "jboss-logging" ], "enabledEventTypes": [], "adminEventsEnabled": false, "adminEventsDetailsEnabled": false, "internationalizationEnabled": true, "supportedLocales": [ "en", "es" ], "defaultLocale": "en", "authenticationFlows": [ { "id": "8502c673-e82c-4713-8f38-0b8186a79cf9", "alias": "Handle Existing Account", "description": "Handle what to do if there is existing account with same email/username like authenticated identity provider", "providerId": "basic-flow", "topLevel": false, "builtIn": true, "authenticationExecutions": [ { "authenticator": "idp-confirm-link", "requirement": "REQUIRED", "priority": 10, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "idp-email-verification", "requirement": "ALTERNATIVE", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false }, { "requirement": "ALTERNATIVE", "priority": 30, "flowAlias": "Verify Existing Account by Re-authentication", "userSetupAllowed": false, "autheticatorFlow": true } ] }, { "id": "29806f39-15a9-4a2b-a37f-07f1527d969d", "alias": "Verify Existing Account by Re-authentication", "description": "Reauthentication of existing account", "providerId": "basic-flow", "topLevel": false, "builtIn": true, "authenticationExecutions": [ { "authenticator": "idp-username-password-form", "requirement": "REQUIRED", "priority": 10, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "auth-otp-form", "requirement": "OPTIONAL", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false } ] }, { "id": "d29fe567-0975-41f1-9232-8c3ca602e34c", "alias": "browser", "description": "browser based authentication", "providerId": "basic-flow", "topLevel": true, "builtIn": true, "authenticationExecutions": [ { "authenticator": "auth-cookie", "requirement": "ALTERNATIVE", "priority": 10, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "auth-spnego", "requirement": "DISABLED", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false }, { "requirement": "ALTERNATIVE", "priority": 30, "flowAlias": "forms", "userSetupAllowed": false, "autheticatorFlow": true } ] }, { "id": "e198a546-8a35-4bfd-a81a-5345fcf0deda", "alias": "clients", "description": "Base authentication for clients", "providerId": "client-flow", "topLevel": true, "builtIn": true, "authenticationExecutions": [ { "authenticator": "client-secret", "requirement": "ALTERNATIVE", "priority": 10, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "client-jwt", "requirement": "ALTERNATIVE", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false } ] }, { "id": "94e7874e-347c-4c20-80e6-951557a847d1", "alias": "direct grant", "description": "OpenID Connect Resource Owner Grant", "providerId": "basic-flow", "topLevel": true, "builtIn": true, "authenticationExecutions": [ { "authenticator": "direct-grant-validate-username", "requirement": "REQUIRED", "priority": 10, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "direct-grant-validate-password", "requirement": "REQUIRED", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "direct-grant-validate-otp", "requirement": "OPTIONAL", "priority": 30, "userSetupAllowed": false, "autheticatorFlow": false } ] }, { "id": "c362ae25-7882-4c5a-9a76-ab4ce85d82dc", "alias": "first broker login", "description": "Actions taken after first broker login with identity provider account, which is not yet linked to any Keycloak account", "providerId": "basic-flow", "topLevel": true, "builtIn": true, "authenticationExecutions": [ { "authenticatorConfig": "review profile config", "authenticator": "idp-review-profile", "requirement": "REQUIRED", "priority": 10, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticatorConfig": "create unique user config", "authenticator": "idp-create-user-if-unique", "requirement": "ALTERNATIVE", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false }, { "requirement": "ALTERNATIVE", "priority": 30, "flowAlias": "Handle Existing Account", "userSetupAllowed": false, "autheticatorFlow": true } ] }, { "id": "b84d7f61-aa46-4fa3-bf7a-16dcf1a28b25", "alias": "forms", "description": "Username, password, otp and other auth forms.", "providerId": "basic-flow", "topLevel": false, "builtIn": true, "authenticationExecutions": [ { "authenticator": "auth-username-password-form", "requirement": "REQUIRED", "priority": 10, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "auth-otp-form", "requirement": "OPTIONAL", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false } ] }, { "id": "0f2b1667-0f7c-428b-9efe-ffdb2688453c", "alias": "registration", "description": "registration flow", "providerId": "basic-flow", "topLevel": true, "builtIn": true, "authenticationExecutions": [ { "authenticator": "registration-page-form", "requirement": "REQUIRED", "priority": 10, "flowAlias": "registration form", "userSetupAllowed": false, "autheticatorFlow": true } ] }, { "id": "fdb73e02-6264-493f-a7b1-b7f8374eded9", "alias": "registration form", "description": "registration form", "providerId": "form-flow", "topLevel": false, "builtIn": true, "authenticationExecutions": [ { "authenticator": "registration-user-creation", "requirement": "REQUIRED", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "registration-profile-action", "requirement": "REQUIRED", "priority": 40, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "registration-password-action", "requirement": "REQUIRED", "priority": 50, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "registration-recaptcha-action", "requirement": "DISABLED", "priority": 60, "userSetupAllowed": false, "autheticatorFlow": false } ] }, { "id": "5b6e2c06-9c1a-4373-95dc-13f54a3d41d0", "alias": "reset credentials", "description": "Reset credentials for a user if they forgot their password or something", "providerId": "basic-flow", "topLevel": true, "builtIn": true, "authenticationExecutions": [ { "authenticator": "reset-credentials-choose-user", "requirement": "REQUIRED", "priority": 10, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "reset-credential-email", "requirement": "REQUIRED", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "reset-password", "requirement": "REQUIRED", "priority": 30, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "reset-otp", "requirement": "OPTIONAL", "priority": 40, "userSetupAllowed": false, "autheticatorFlow": false } ] } ], "authenticatorConfig": [ { "alias": "create unique user config", "config": { "require.password.update.after.registration": "false" } }, { "alias": "review profile config", "config": { "update.profile.on.first.login": "missing" } } ], "requiredActions": [ { "alias": "CONFIGURE_TOTP", "name": "Configure Totp", "providerId": "CONFIGURE_TOTP", "enabled": true, "defaultAction": false, "config": {} }, { "alias": "UPDATE_PASSWORD", "name": "Update Password", "providerId": "UPDATE_PASSWORD", "enabled": true, "defaultAction": false, "config": {} }, { "alias": "UPDATE_PROFILE", "name": "Update Profile", "providerId": "UPDATE_PROFILE", "enabled": true, "defaultAction": false, "config": {} }, { "alias": "VERIFY_EMAIL", "name": "Verify Email", "providerId": "VERIFY_EMAIL", "enabled": true, "defaultAction": false, "config": {} }, { "alias": "terms_and_conditions", "name": "Terms and Conditions", "providerId": "terms_and_conditions", "enabled": false, "defaultAction": false, "config": {} } ], "browserFlow": "browser", "registrationFlow": "registration", "directGrantFlow": "direct grant", "resetCredentialsFlow": "reset credentials", "clientAuthenticationFlow": "clients" } ] From haimv at perfectomobile.com Wed May 18 05:53:25 2016 From: haimv at perfectomobile.com (Haim Vana) Date: Wed, 18 May 2016 09:53:25 +0000 Subject: [keycloak-user] KeyCloak offline tokens and architecture Message-ID: Hi, We are evaluating KeyCloak to be our SSO server, and we have a few questions regarding the offline token usage. First our high level use case is as follows: We have multi-tenancy applications, each tenant will have its own realm (which means the same clients will be defined for each realm). One of the applications has 3 authentication scenarios: 1. User using SDK flow to access the application (by code) 2. Offline job 3. External micro service (not registered in KeyCloak) that needs to access our application micro service 4. UI login We thought to use offline token for the first three, and define a single client for UI and micro services. Does our approach make sense ? specially regarding the realm per tenant and the fact that we will have to create the same clients for each realm, The offline token usage for the authentication flows, and the single client for the UI and micro service. Regarding the offline tokens - why are they per client ? is it mean that when using the client offline token (and getting the real token from KeyCloak) we will not be able to use it for other client (within the realm) micro service ? Also how can we generate them for each of the following cases (also described above): 1. User - should manually add the token to his code, so we thought to provide it within the application, however how can we generate the offline token to already logged in user ? we would like to avoid generating the offline token to all users and to use separate offline login page. 2. Offline job - the offline job which is cross realms will use special operator realm, the token will be generated manually by the admin which will stored it in the file system for the offline job usage, how can the admin generate this token ? can it be done in the admin console ? if not I guess we will have to create a service that logs him to the application and generate the token, is there an alternative ? 3. Micro service - it's very similar flow to the offline job only that the admin will have to create offline token per realm. I hope it's not too much [https://issues.jboss.org/images/icons/emoticons/smile.png] and any advice will be highly appreciated. Thanks, Haim. The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160518/586f4484/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 752 bytes Desc: image001.png Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160518/586f4484/attachment.png From yelata at blulogix.com Wed May 18 11:24:41 2016 From: yelata at blulogix.com (Yasser El-ata) Date: Wed, 18 May 2016 18:24:41 +0300 Subject: [keycloak-user] Error appear when change the servers to HTTPS Message-ID: *Hello,When we change our server to work with https we start see the following error "Missing parameters: response_type" , and i'am sure the parameters is exist in the URLwhen the application was working on http this error wasn't happenedplease find the attached screen shout * *the following are my Realms , AngularJs and bearer JSON filesi paste them to the ubuntu paste i also attache them in the email* *My Realms: http://paste.ubuntu.com/16481701/ AngularJs App Json File : http://paste.ubuntu.com/16481216/ Bearer Application (API) Json File: http://paste.ubuntu.com/16481242/ * *please adviseThanks* -- Yasser El-Ata Java Developer BluLogix 737 Walker Rd Ste 3, Great Falls, VA 22066 t: 443.333.4100 | f: 443.333.4101 *www.blulogix.com * The information transmitted is intended only for the person(s) to whom it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160518/1fa4c747/attachment-0001.html -------------- next part -------------- { "realm": "BluLogix", "realm-public-key": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6DT7MeQjyxP+MX/iwNPUy3g3JzcPZ4fWLdlHI0pMnkUS4bksIrjCWNWZV6V7TLQLHE0aOfcrZz634lfgt2H0WEDDAvQWo2aPCzxQKvXD+/ioYem18we4XbM6f6NsjJ1cmBRiQpHlZrEQ5AR9RA5734Xyc0SMn0td4Q5WP48QYfc5iGpWYHzQvGUbCnwR95ysZP34v2n7j1cwkNg7PClHtmgUWz7RQIczR8c1VzXIrYwvACYavblcvO98Wh50sKX2h3S7Zgspz23f/oaAl7lmvVuBo/yF87T+7qSXDRo737I7nyBxTERya8ShCDrMVCuhWoBRzMGFeovhfse7TNZoswIDAQAB", "auth-server-url": "https://trialblua3administration.blulogix.com/auth", "ssl-required": "all", "resource": "CIS", "credentials": { "secret": "fdb61205-d0c5-4c48-b6d6-8dd28a2f040d" }, "use-resource-role-mappings": true } -------------- next part -------------- { "realm": "BluLogix", "realm-public-key": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6DT7MeQjyxP+MX/iwNPUy3g3JzcPZ4fWLdlHI0pMnkUS4bksIrjCWNWZV6V7TLQLHE0aOfcrZz634lfgt2H0WEDDAvQWo2aPCzxQKvXD+/ioYem18we4XbM6f6NsjJ1cmBRiQpHlZrEQ5AR9RA5734Xyc0SMn0td4Q5WP48QYfc5iGpWYHzQvGUbCnwR95ysZP34v2n7j1cwkNg7PClHtmgUWz7RQIczR8c1VzXIrYwvACYavblcvO98Wh50sKX2h3S7Zgspz23f/oaAl7lmvVuBo/yF87T+7qSXDRo737I7nyBxTERya8ShCDrMVCuhWoBRzMGFeovhfse7TNZoswIDAQAB", "bearer-only": true, "auth-server-url": "https://trialblua3administration.blulogix.com/auth", "ssl-required": "all", "resource": "CIS-SERVER", "use-resource-role-mappings": true, "enable-cors" : true, "cors-max-age" : 3600, "cors-allowed-methods" : "POST, PUT, DELETE, GET", "allow-any-hostname" : true } -------------- next part -------------- [ { "id": "BluLogix", "realm": "BluLogix", "displayName": "Please Login:", "notBefore": 0, "revokeRefreshToken": false, "accessTokenLifespan": 1200, "accessTokenLifespanForImplicitFlow": 900, "ssoSessionIdleTimeout": 1800, "ssoSessionMaxLifespan": 1800, "offlineSessionIdleTimeout": 2592000, "accessCodeLifespan": 60, "accessCodeLifespanUserAction": 900, "accessCodeLifespanLogin": 1800, "enabled": true, "sslRequired": "all", "registrationAllowed": false, "registrationEmailAsUsername": true, "rememberMe": true, "verifyEmail": true, "resetPasswordAllowed": true, "editUsernameAllowed": true, "bruteForceProtected": false, "maxFailureWaitSeconds": 900, "minimumQuickLoginWaitSeconds": 60, "waitIncrementSeconds": 60, "quickLoginCheckMilliSeconds": 1000, "maxDeltaTimeSeconds": 43200, "failureFactor": 30, "privateKey": "MIIEpAIBAAKCAQEA6DT7MeQjyxP+MX/iwNPUy3g3JzcPZ4fWLdlHI0pMnkUS4bksIrjCWNWZV6V7TLQLHE0aOfcrZz634lfgt2H0WEDDAvQWo2aPCzxQKvXD+/ioYem18we4XbM6f6NsjJ1cmBRiQpHlZrEQ5AR9RA5734Xyc0SMn0td4Q5WP48QYfc5iGpWYHzQvGUbCnwR95ysZP34v2n7j1cwkNg7PClHtmgUWz7RQIczR8c1VzXIrYwvACYavblcvO98Wh50sKX2h3S7Zgspz23f/oaAl7lmvVuBo/yF87T+7qSXDRo737I7nyBxTERya8ShCDrMVCuhWoBRzMGFeovhfse7TNZoswIDAQABAoIBAQDETs4yPooYDD3wwQoFNNCId4hBCeZnA0qJlk/ywMSHZSPyWma6r/H1whaSJ19W2DswYOqUKKaz8SzqGJrszc4RsiZrX8mnuHOj7whjWUSnx28q37cnz9YIuRXyhEmnkv2NwGXVm5wRtg3uhvET0R7eOFJhKomrvb6PHlzB/QO/nPLdpmZdxoSe4igBlhLb9WLGTdBUx3MTmITUZfZlFR4DOqNeMhfttGf5+S9ZnuPECSO70EICuRUHbBcfJnfMBa82V4Z3yuh9bhtO4hjptabqDV/tIgQOOmjflwIOymqkCUIbe2TXl/R1EaQVxI4NG01LWs+j+fnMHe5Oke5n7S9xAoGBAPi5SYqgO8UasOUiWtH64QzBrWJgSrM4hbc6AF6+3ns43IpX0whEn/euH08K6raoi18GhMS+deJH2BUpNHi2bLB7qpQYxOwgFXWQ3q/5VIXoda2kH8SNoR7K+5MdGVsKVjLPulANLPhUyySOKpxKOeWSHusEmQSZdTYy3vT0rQ3LAoGBAO7//4YA32ONv7rkJFpWgi2JHRyhx2MWTcTHZA2xcj5mBgt8Wz9nfsOoseWcRyoNHNUSX4bSf+Ix7B7CN6osZ60qrwXPk3LVTzetNE2FhOjRN+9VBf9Tky3/7Pdl+h3O8Sual+MDQJSx0ShZXY8ipzdt8neoMMsvoSKMxDVFGDO5AoGBAKZ4nVhDVr3d13gFPnQ8TlSTbNDjUhwSQK0aDRVc+tvOew29KmnmRIsp55qn2+DVfjLj0gk80PnazC2dnpkMwEJ/AvSMf4DrGHHPvLxbTM8zf0/xAbI0eRp7EVatq0Lb8EWh8zmRGAA+AJk+7hYdOBMHcdorAZ+qdmEIO2IIQatxAoGAT5K0RK1tsvuy5kqnP9ylovuP0cSbWgZHBklMqrJ10wis4o4Y41dWAVbdRBFwMDQFcXuYio7zPSBZ+TO4zNPUAPfBJjIiaY1TvrnQPC9EPS/La8fnI0d0LVCUWRp+2AXajiX+g/rFObyqYsC+QbXL7syQef5poHzPLW2otgO3NyECgYAuQOVfomVpiF+oWscNjmnsG+T86P8ZaH7jKxNlJ9EKz/eoDmEu6GG0gdEY/p3iUnvs/kR3vzkiBa/k8XZgCDcRn8Le6Dzx35qNyltj/cbscv0PANhFKLhShmarZEvGriN7xOMrfhZGbj7oL+QtAJr2zOIa9uxdW+fu0vNJGnFoHQ==", "publicKey": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6DT7MeQjyxP+MX/iwNPUy3g3JzcPZ4fWLdlHI0pMnkUS4bksIrjCWNWZV6V7TLQLHE0aOfcrZz634lfgt2H0WEDDAvQWo2aPCzxQKvXD+/ioYem18we4XbM6f6NsjJ1cmBRiQpHlZrEQ5AR9RA5734Xyc0SMn0td4Q5WP48QYfc5iGpWYHzQvGUbCnwR95ysZP34v2n7j1cwkNg7PClHtmgUWz7RQIczR8c1VzXIrYwvACYavblcvO98Wh50sKX2h3S7Zgspz23f/oaAl7lmvVuBo/yF87T+7qSXDRo737I7nyBxTERya8ShCDrMVCuhWoBRzMGFeovhfse7TNZoswIDAQAB", "certificate": "MIICnzCCAYcCBgFSXpioszANBgkqhkiG9w0BAQsFADATMREwDwYDVQQDDAhCbHVMb2dpeDAeFw0xNjAxMjAxMDMxNDlaFw0yNjAxMjAxMDMzMjlaMBMxETAPBgNVBAMMCEJsdUxvZ2l4MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6DT7MeQjyxP+MX/iwNPUy3g3JzcPZ4fWLdlHI0pMnkUS4bksIrjCWNWZV6V7TLQLHE0aOfcrZz634lfgt2H0WEDDAvQWo2aPCzxQKvXD+/ioYem18we4XbM6f6NsjJ1cmBRiQpHlZrEQ5AR9RA5734Xyc0SMn0td4Q5WP48QYfc5iGpWYHzQvGUbCnwR95ysZP34v2n7j1cwkNg7PClHtmgUWz7RQIczR8c1VzXIrYwvACYavblcvO98Wh50sKX2h3S7Zgspz23f/oaAl7lmvVuBo/yF87T+7qSXDRo737I7nyBxTERya8ShCDrMVCuhWoBRzMGFeovhfse7TNZoswIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQBXogxS9bcEKYSWUosA7ddl+p8tNPzte38e/1L6dmD0Eoswo7M46WndWr5uNkrZvfMOCrNP6nPny1ugehZ6+2ZkmuL0qeoCdmaMwqPiqiUi2zm00vsocdF9cl63pZLKts0WQ2G+VzdJon0+ltWR89TYzj9it5oU4FG0IN0Fn87drcplvUKXhZ4EvlS+HnkndIOEufnUXvZaTd9oP5JiZXNQSGUBjWlUjIWGefWKiyEC+7OYWT4kcknfceLf0rB7Tqme+Twzg+Om3vRQKTRuTKBfFERIexihmpWBsIkBL44wCO/9Ln/LhVm/PPmn0BqMfxJnm1Ep3WrOYkCGMMA0WsaS", "codeSecret": "8ce2ceef-cd9e-4831-8993-6f05be6014bf", "roles": { "realm": [ { "id": "a71d2bd8-4501-4ba8-a72a-309bb0f49f9e", "name": "admin", "description": "admin privalage", "scopeParamRequired": false, "composite": false }, { "id": "4b84029a-54a4-4d9f-b01d-b7cfb8eb6d2f", "name": "offline_access", "description": "${role_offline-access}", "scopeParamRequired": true, "composite": false }, { "id": "7bb2f395-037d-497f-a2f6-ab8173fd810b", "name": "user", "description": "user privalage", "scopeParamRequired": false, "composite": false } ], "client": { "realm-management": [ { "id": "3002cbb1-dc46-4002-84af-13a479fca739", "name": "manage-clients", "description": "${role_manage-clients}", "scopeParamRequired": false, "composite": false }, { "id": "4c372e57-1de0-449f-8988-7b510dd1150a", "name": "manage-events", "description": "${role_manage-events}", "scopeParamRequired": false, "composite": false }, { "id": "207c5734-bc3f-4e8a-ac7b-17046e5d9ba4", "name": "impersonation", "description": "${role_impersonation}", "scopeParamRequired": false, "composite": false }, { "id": "cfc9af9d-5e7e-4782-8447-8af70d862424", "name": "view-identity-providers", "description": "${role_view-identity-providers}", "scopeParamRequired": false, "composite": false }, { "id": "909a610c-27f5-4e16-8d66-7fb0a93ce3d9", "name": "view-clients", "description": "${role_view-clients}", "scopeParamRequired": false, "composite": false }, { "id": "33b6363b-c7e7-4b2a-91eb-14ebe13fd09b", "name": "create-client", "description": "${role_create-client}", "scopeParamRequired": false, "composite": false }, { "id": "332b78c7-9f5c-4cba-8391-2fa3316942ae", "name": "view-realm", "description": "${role_view-realm}", "scopeParamRequired": false, "composite": false }, { "id": "92ce4f2f-3afe-405e-8bfb-6c29fa00838d", "name": "view-events", "description": "${role_view-events}", "scopeParamRequired": false, "composite": false }, { "id": "97ba934e-3f8f-4719-a9eb-197cf4415220", "name": "manage-realm", "description": "${role_manage-realm}", "scopeParamRequired": false, "composite": false }, { "id": "6b69c32f-59a7-4462-bb0d-b4625b96ebb3", "name": "realm-admin", "description": "${role_realm-admin}", "scopeParamRequired": false, "composite": true, "composites": { "client": { "realm-management": [ "manage-clients", "manage-events", "view-clients", "impersonation", "create-client", "view-realm", "view-events", "manage-realm", "view-users", "view-identity-providers", "manage-users", "manage-identity-providers" ] } } }, { "id": "334d7de3-db22-478b-85fe-b1e77f70319d", "name": "view-users", "description": "${role_view-users}", "scopeParamRequired": false, "composite": false }, { "id": "82086eca-c0ab-4819-abcd-ba750e63fd93", "name": "manage-users", "description": "${role_manage-users}", "scopeParamRequired": false, "composite": false }, { "id": "e1cdfd0e-20b5-4910-8acf-5f7a7bcb068c", "name": "manage-identity-providers", "description": "${role_manage-identity-providers}", "scopeParamRequired": false, "composite": false } ], "security-admin-console": [], "CIS-SERVER": [ { "id": "efa125c0-a43b-44ff-aee5-97d83f70bd33", "name": "api_user", "description": "api_user", "scopeParamRequired": false, "composite": false } ], "admin-cli": [], "CIS": [ { "id": "0ec4e381-79cb-4ef2-8dec-94286e070af1", "name": "user_role", "description": "user_role", "scopeParamRequired": false, "composite": false } ], "broker": [ { "id": "1da7cb4c-9681-489c-9af2-45a567746731", "name": "read-token", "description": "${role_read-token}", "scopeParamRequired": false, "composite": false } ], "account": [ { "id": "8ec77e25-0f38-4cde-b277-e2461e68f1de", "name": "view-profile", "description": "${role_view-profile}", "scopeParamRequired": false, "composite": false }, { "id": "36beae54-f8fe-44a9-b569-ab33f26c937f", "name": "manage-account", "description": "${role_manage-account}", "scopeParamRequired": false, "composite": false } ] } }, "groups": [ { "id": "32a5eac2-0ade-4756-80c8-754f366176ab", "name": "User Test", "path": "/User Test", "attributes": { "partnerCode": [ "t68ur7tyr77r" ] }, "realmRoles": [ "admin", "offline_access", "user" ], "clientRoles": { "CIS-SERVER": [ "api_user" ], "CIS": [ "user_role" ] }, "subGroups": [] } ], "defaultRoles": [ "offline_access" ], "requiredCredentials": [ "password" ], "otpPolicyType": "totp", "otpPolicyAlgorithm": "HmacSHA1", "otpPolicyInitialCounter": 0, "otpPolicyDigits": 6, "otpPolicyLookAheadWindow": 1, "otpPolicyPeriod": 30, "users": [], "scopeMappings": [ { "client": "CIS", "roles": [ "admin", "user" ] }, { "client": "security-admin-console", "roles": [ "admin", "user" ] } ], "clientScopeMappings": { "realm-management": [ { "client": "admin-cli", "roles": [ "realm-admin" ] }, { "client": "security-admin-console", "roles": [ "realm-admin" ] } ], "CIS-SERVER": [ { "client": "CIS", "roles": [ "api_user" ] } ] }, "clients": [ { "id": "a8eed917-823d-4aa9-8a72-0f91777905fa", "clientId": "CIS", "name": "CIS", "description": "Cloud Innovations Suit", "surrogateAuthRequired": false, "enabled": true, "clientAuthenticatorType": "client-secret", "secret": "fdb61205-d0c5-4c48-b6d6-8dd28a2f040d", "redirectUris": [ "https://developtrial1.blulogix.com" ], "webOrigins": ["https://storetrial1.blulogix.com/G6_V2/public_html/index.html" ], "notBefore": 0, "bearerOnly": false, "consentRequired": false, "standardFlowEnabled": true, "implicitFlowEnabled": false, "directAccessGrantsEnabled": true, "serviceAccountsEnabled": false, "publicClient": false, "frontchannelLogout": false, "protocol": "openid-connect", "attributes": { "saml.assertion.signature": "false", "saml.force.post.binding": "false", "saml.multivalued.roles": "false", "saml.signature.algorithm": "RSA_SHA256", "saml.encrypt": "false", "saml_force_name_id_format": "false", "saml.client.signature": "false", "saml.authnstatement": "true", "saml_name_id_format": "username", "saml.server.signature": "false", "saml_signature_canonicalization_method": "http://www.w3.org/2001/10/xml-exc-c14n#" }, "fullScopeAllowed": false, "nodeReRegistrationTimeout": -1, "protocolMappers": [ { "id": "9f6b0864-c825-4bac-ac14-cd558f176a3f", "name": "Client ID", "protocol": "openid-connect", "protocolMapper": "oidc-usersessionmodel-note-mapper", "consentRequired": false, "config": { "user.session.note": "clientId", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "clientId", "jsonType.label": "String" } }, { "id": "e9e8202c-0ffc-4dbd-baed-362c1b6723ce", "name": "accountNumber", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-attribute-mapper", "consentRequired": false, "config": { "multivalued": "false", "user.attribute": "accountNumber", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "accountNumber", "jsonType.label": "String" } }, { "id": "9dfdc7c9-e81e-45f1-99d7-3dfccbafbebd", "name": "Client Host", "protocol": "openid-connect", "protocolMapper": "oidc-usersessionmodel-note-mapper", "consentRequired": false, "config": { "user.session.note": "clientHost", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "clientHost", "jsonType.label": "String" } }, { "id": "23c0db37-2aaf-4a57-9c5f-087a57abeaed", "name": "username", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${username}", "config": { "user.attribute": "username", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "preferred_username", "jsonType.label": "String" } }, { "id": "495c2caa-c987-48a2-b73b-565833d7f247", "name": "family name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${familyName}", "config": { "user.attribute": "lastName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "family_name", "jsonType.label": "String" } }, { "id": "0fe169e7-d0a4-427a-9272-507e1f87f42c", "name": "role list", "protocol": "saml", "protocolMapper": "saml-role-list-mapper", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } }, { "id": "604a27c8-c735-4bd4-aa41-c0dd886bb95a", "name": "Client IP Address", "protocol": "openid-connect", "protocolMapper": "oidc-usersessionmodel-note-mapper", "consentRequired": false, "config": { "user.session.note": "clientAddress", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "clientAddress", "jsonType.label": "String" } }, { "id": "d80117fa-3478-4846-97ec-277f0f0994ae", "name": "full name", "protocol": "openid-connect", "protocolMapper": "oidc-full-name-mapper", "consentRequired": true, "consentText": "${fullName}", "config": { "id.token.claim": "true", "access.token.claim": "true" } }, { "id": "9af3dd9b-d1f2-42ff-9a7d-01098c34042a", "name": "partnerCode", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-attribute-mapper", "consentRequired": false, "config": { "user.attribute": "partnerCode", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "partnerCode", "jsonType.label": "String" } }, { "id": "6d090757-28a9-43df-9e73-a00e435a7848", "name": "email verified", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": false, "consentText": "${emailVerified}", "config": { "user.attribute": "emailVerified", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email_verified", "jsonType.label": "boolean" } }, { "id": "c5932d5f-a92e-4eb7-a71a-04f48767bb01", "name": "locale", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-attribute-mapper", "consentRequired": false, "consentText": "${locale}", "config": { "user.attribute": "locale", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "locale", "jsonType.label": "String" } }, { "id": "ac39401c-5b2f-4a6a-aeeb-765243213830", "name": "address", "protocol": "openid-connect", "protocolMapper": "oidc-address-mapper", "consentRequired": true, "consentText": "${address}", "config": { "id.token.claim": "true", "access.token.claim": "true" } }, { "id": "9df2ae53-d513-43f6-93af-84d1d30782e6", "name": "email", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${email}", "config": { "user.attribute": "email", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email", "jsonType.label": "String" } }, { "id": "a72d07f3-f3a9-4e47-bd02-36789ed9ce37", "name": "given name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${givenName}", "config": { "user.attribute": "firstName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "given_name", "jsonType.label": "String" } }, { "id": "ee24264d-7546-49dd-8865-f490c0056d8f", "name": "gss delegation credential", "protocol": "openid-connect", "protocolMapper": "oidc-usersessionmodel-note-mapper", "consentRequired": true, "consentText": "${gssDelegationCredential}", "config": { "user.session.note": "gss_delegation_credential", "access.token.claim": "true", "claim.name": "gss_delegation_credential", "jsonType.label": "String" } } ], "useTemplateConfig": false, "useTemplateScope": false, "useTemplateMappers": false }, { "id": "227606d3-4b6b-40a1-af82-8eade110dfff", "clientId": "CIS-SERVER", "name": "CIS-SERVER", "description": "BluLogix Server Api's", "surrogateAuthRequired": false, "enabled": true, "clientAuthenticatorType": "client-secret", "secret": "b05948ee-5c52-4ae1-b1b2-98eba92d46c4", "redirectUris": [], "webOrigins": [], "notBefore": 0, "bearerOnly": true, "consentRequired": false, "standardFlowEnabled": true, "implicitFlowEnabled": false, "directAccessGrantsEnabled": false, "serviceAccountsEnabled": false, "publicClient": false, "frontchannelLogout": false, "protocol": "openid-connect", "attributes": { "saml.assertion.signature": "false", "saml.force.post.binding": "false", "saml.multivalued.roles": "false", "saml.signature.algorithm": "RSA_SHA256", "saml.encrypt": "false", "saml_force_name_id_format": "false", "saml.client.signature": "false", "saml.authnstatement": "true", "saml_name_id_format": "username", "saml.server.signature": "false", "saml_signature_canonicalization_method": "http://www.w3.org/2001/10/xml-exc-c14n#" }, "fullScopeAllowed": true, "nodeReRegistrationTimeout": -1, "protocolMappers": [ { "id": "c8f6d52c-1f71-4310-a35f-2359553859ed", "name": "given name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${givenName}", "config": { "user.attribute": "firstName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "given_name", "jsonType.label": "String" } }, { "id": "57e72513-431e-43ec-add8-6210b6e4b9c7", "name": "family name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${familyName}", "config": { "user.attribute": "lastName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "family_name", "jsonType.label": "String" } }, { "id": "cc545c42-f73d-4f4c-8681-0be38b7994af", "name": "role list", "protocol": "saml", "protocolMapper": "saml-role-list-mapper", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } }, { "id": "416f28b3-f9e3-4178-a3dd-4c420e423864", "name": "username", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${username}", "config": { "user.attribute": "username", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "preferred_username", "jsonType.label": "String" } }, { "id": "cdf3545d-a11c-4885-9d22-c56f01160e64", "name": "email", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${email}", "config": { "user.attribute": "email", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email", "jsonType.label": "String" } }, { "id": "43496269-da8e-4fc6-8425-728a02afaa76", "name": "full name", "protocol": "openid-connect", "protocolMapper": "oidc-full-name-mapper", "consentRequired": true, "consentText": "${fullName}", "config": { "id.token.claim": "true", "access.token.claim": "true" } } ], "useTemplateConfig": false, "useTemplateScope": false, "useTemplateMappers": false }, { "id": "eac1955b-3eb5-4360-b07c-29d8879870f5", "clientId": "account", "name": "${client_account}", "baseUrl": "/auth/realms/BluLogix/account", "surrogateAuthRequired": false, "enabled": true, "clientAuthenticatorType": "client-secret", "secret": "488edcdd-1bbf-4c7f-8265-312dc3e8858c", "defaultRoles": [ "view-profile", "manage-account" ], "redirectUris": [ "/auth/realms/BluLogix/account/*" ], "webOrigins": [], "notBefore": 0, "bearerOnly": false, "consentRequired": false, "standardFlowEnabled": true, "implicitFlowEnabled": false, "directAccessGrantsEnabled": false, "serviceAccountsEnabled": false, "publicClient": false, "frontchannelLogout": false, "attributes": {}, "fullScopeAllowed": false, "nodeReRegistrationTimeout": 0, "protocolMappers": [ { "id": "8b8f1929-1dae-4c49-af7c-9428dd98ea8e", "name": "username", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${username}", "config": { "user.attribute": "username", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "preferred_username", "jsonType.label": "String" } }, { "id": "3245c3f1-cedc-4171-9866-38670415a2ef", "name": "family name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${familyName}", "config": { "user.attribute": "lastName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "family_name", "jsonType.label": "String" } }, { "id": "2d5d8913-f08c-453b-983d-34de9db31801", "name": "email", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${email}", "config": { "user.attribute": "email", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email", "jsonType.label": "String" } }, { "id": "5f338d95-f27d-488b-ade2-e1a65e3ede88", "name": "full name", "protocol": "openid-connect", "protocolMapper": "oidc-full-name-mapper", "consentRequired": true, "consentText": "${fullName}", "config": { "id.token.claim": "true", "access.token.claim": "true" } }, { "id": "7ea30832-216b-4016-ad5e-75e750faa2b0", "name": "given name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${givenName}", "config": { "user.attribute": "firstName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "given_name", "jsonType.label": "String" } }, { "id": "f387b5e2-4241-4631-b127-26ac47f299e7", "name": "role list", "protocol": "saml", "protocolMapper": "saml-role-list-mapper", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } } ], "useTemplateConfig": false, "useTemplateScope": false, "useTemplateMappers": false }, { "id": "9d1c53f5-9ded-4ad3-b511-3b5ff6aa08a1", "clientId": "admin-cli", "name": "${client_admin-cli}", "surrogateAuthRequired": false, "enabled": true, "clientAuthenticatorType": "client-secret", "secret": "1154222a-fe1d-444b-b29c-682065a77d8b", "redirectUris": [], "webOrigins": [], "notBefore": 0, "bearerOnly": false, "consentRequired": false, "standardFlowEnabled": false, "implicitFlowEnabled": false, "directAccessGrantsEnabled": true, "serviceAccountsEnabled": false, "publicClient": true, "frontchannelLogout": false, "attributes": {}, "fullScopeAllowed": false, "nodeReRegistrationTimeout": 0, "protocolMappers": [ { "id": "ae7cc777-2e71-42c2-81c7-89a458abd046", "name": "email", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${email}", "config": { "user.attribute": "email", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email", "jsonType.label": "String" } }, { "id": "e022bcf7-9676-478b-8e9e-b3321db31325", "name": "given name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${givenName}", "config": { "user.attribute": "firstName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "given_name", "jsonType.label": "String" } }, { "id": "b949fa0f-8db4-4daa-822c-3f68ef82c366", "name": "role list", "protocol": "saml", "protocolMapper": "saml-role-list-mapper", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } }, { "id": "614f4b41-c229-4731-befa-fe14b0ecf3e8", "name": "username", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${username}", "config": { "user.attribute": "username", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "preferred_username", "jsonType.label": "String" } }, { "id": "d832c7f9-78de-42ec-a612-84353213630a", "name": "full name", "protocol": "openid-connect", "protocolMapper": "oidc-full-name-mapper", "consentRequired": true, "consentText": "${fullName}", "config": { "id.token.claim": "true", "access.token.claim": "true" } }, { "id": "cfefffc7-13a8-4719-be88-7f64584f1fa3", "name": "family name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${familyName}", "config": { "user.attribute": "lastName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "family_name", "jsonType.label": "String" } } ], "useTemplateConfig": false, "useTemplateScope": false, "useTemplateMappers": false }, { "id": "153f8d34-7425-4734-8373-49e292963d63", "clientId": "broker", "name": "${client_broker}", "surrogateAuthRequired": false, "enabled": true, "clientAuthenticatorType": "client-secret", "secret": "7cff6841-64da-4911-89fe-63bd17914b4f", "redirectUris": [], "webOrigins": [], "notBefore": 0, "bearerOnly": false, "consentRequired": false, "standardFlowEnabled": true, "implicitFlowEnabled": false, "directAccessGrantsEnabled": false, "serviceAccountsEnabled": false, "publicClient": false, "frontchannelLogout": false, "attributes": {}, "fullScopeAllowed": false, "nodeReRegistrationTimeout": 0, "protocolMappers": [ { "id": "5596c5cc-4f57-461e-8858-26842efbaa1f", "name": "full name", "protocol": "openid-connect", "protocolMapper": "oidc-full-name-mapper", "consentRequired": true, "consentText": "${fullName}", "config": { "id.token.claim": "true", "access.token.claim": "true" } }, { "id": "85c6388c-b440-4ba8-ac64-ce95f851cb87", "name": "given name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${givenName}", "config": { "user.attribute": "firstName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "given_name", "jsonType.label": "String" } }, { "id": "d57f9b94-a466-449d-b75a-fa9b2fadfd35", "name": "email", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${email}", "config": { "user.attribute": "email", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email", "jsonType.label": "String" } }, { "id": "64b4962b-7a34-423d-8ef9-ca1340f00351", "name": "family name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${familyName}", "config": { "user.attribute": "lastName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "family_name", "jsonType.label": "String" } }, { "id": "17ca0341-a8d2-4c69-886b-65f8efd5d780", "name": "role list", "protocol": "saml", "protocolMapper": "saml-role-list-mapper", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } }, { "id": "cfae52c5-8434-4431-9442-a45cc37c44df", "name": "username", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${username}", "config": { "user.attribute": "username", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "preferred_username", "jsonType.label": "String" } } ], "useTemplateConfig": false, "useTemplateScope": false, "useTemplateMappers": false }, { "id": "952ec9d0-1570-4785-8afb-bccccdaa1904", "clientId": "realm-management", "name": "${client_realm-management}", "surrogateAuthRequired": false, "enabled": true, "clientAuthenticatorType": "client-secret", "secret": "09d204d1-b9a3-468b-924f-d8c591632934", "redirectUris": [], "webOrigins": [], "notBefore": 0, "bearerOnly": true, "consentRequired": false, "standardFlowEnabled": true, "implicitFlowEnabled": false, "directAccessGrantsEnabled": false, "serviceAccountsEnabled": false, "publicClient": false, "frontchannelLogout": false, "attributes": {}, "fullScopeAllowed": false, "nodeReRegistrationTimeout": 0, "protocolMappers": [ { "id": "89c52126-8fff-480f-a13a-b23bbc8680e3", "name": "given name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${givenName}", "config": { "user.attribute": "firstName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "given_name", "jsonType.label": "String" } }, { "id": "54b7855b-8076-4dc5-bf48-004579b4fc8a", "name": "email", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${email}", "config": { "user.attribute": "email", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email", "jsonType.label": "String" } }, { "id": "72424f27-839c-456c-a74e-67f9736362fc", "name": "role list", "protocol": "saml", "protocolMapper": "saml-role-list-mapper", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } }, { "id": "4d8f2ff6-b537-4392-99a2-96a43845b4ee", "name": "username", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${username}", "config": { "user.attribute": "username", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "preferred_username", "jsonType.label": "String" } }, { "id": "7bde3192-50ca-4f75-857b-61aa09e8766c", "name": "family name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${familyName}", "config": { "user.attribute": "lastName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "family_name", "jsonType.label": "String" } }, { "id": "d18e512e-4027-4b71-b34f-4c93a6fa3aa2", "name": "full name", "protocol": "openid-connect", "protocolMapper": "oidc-full-name-mapper", "consentRequired": true, "consentText": "${fullName}", "config": { "id.token.claim": "true", "access.token.claim": "true" } } ], "useTemplateConfig": false, "useTemplateScope": false, "useTemplateMappers": false }, { "id": "b2a51131-b70f-493a-92c8-8464ad1494f7", "clientId": "security-admin-console", "name": "${client_security-admin-console}", "baseUrl": "/auth/admin/BluLogix/console/index.html", "surrogateAuthRequired": false, "enabled": true, "clientAuthenticatorType": "client-secret", "secret": "74ca6b66-0dee-451d-a25f-e6b3072bbcea", "redirectUris": [ "/auth/admin/BluLogix/console/*" ], "webOrigins": [], "notBefore": 0, "bearerOnly": false, "consentRequired": false, "standardFlowEnabled": true, "implicitFlowEnabled": false, "directAccessGrantsEnabled": false, "serviceAccountsEnabled": false, "publicClient": true, "frontchannelLogout": false, "attributes": {}, "fullScopeAllowed": false, "nodeReRegistrationTimeout": 0, "protocolMappers": [ { "id": "ba12433f-750d-425d-ad55-6e71ef48d57f", "name": "full name", "protocol": "openid-connect", "protocolMapper": "oidc-full-name-mapper", "consentRequired": true, "consentText": "${fullName}", "config": { "id.token.claim": "true", "access.token.claim": "true" } }, { "id": "cbc8a691-a30f-4685-b1d6-b01e02b1819d", "name": "username", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${username}", "config": { "user.attribute": "username", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "preferred_username", "jsonType.label": "String" } }, { "id": "8a2186ad-7fc3-4f76-b698-f9b9bc2f8226", "name": "family name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${familyName}", "config": { "user.attribute": "lastName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "family_name", "jsonType.label": "String" } }, { "id": "4f37c212-a357-4f1c-87cf-8317d3489e67", "name": "given name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${givenName}", "config": { "user.attribute": "firstName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "given_name", "jsonType.label": "String" } }, { "id": "1daabf0b-7276-4d3f-9003-c71e17615080", "name": "role list", "protocol": "saml", "protocolMapper": "saml-role-list-mapper", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } }, { "id": "21d66e88-ae45-44ed-8b06-821434e13c01", "name": "email", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${email}", "config": { "user.attribute": "email", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email", "jsonType.label": "String" } }, { "id": "9e91d808-107a-4a9e-8ca2-775aa0a6e39c", "name": "locale", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-attribute-mapper", "consentRequired": false, "consentText": "${locale}", "config": { "user.attribute": "locale", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "locale", "jsonType.label": "String" } } ], "useTemplateConfig": false, "useTemplateScope": false, "useTemplateMappers": false } ], "clientTemplates": [], "browserSecurityHeaders": { "xFrameOptions": "SAMEORIGIN", "contentSecurityPolicy": "frame-src 'self'" }, "smtpServer": { "password": "0785813567", "starttls": "true", "auth": "true", "port": "587", "host": "smtp.gmail.com", "from": "blulogix_noreply at blulogix.com", "user": "YasbPana at gmail.com" }, "loginTheme": "keycloak", "accountTheme": "keycloak", "adminTheme": "keycloak", "eventsEnabled": false, "eventsListeners": [ "jboss-logging" ], "enabledEventTypes": [], "adminEventsEnabled": false, "adminEventsDetailsEnabled": false, "internationalizationEnabled": false, "supportedLocales": [ "en", "es" ], "defaultLocale": "en", "authenticationFlows": [ { "id": "5e446bd6-5d70-43b4-a622-debd9c4a3e53", "alias": "Handle Existing Account", "description": "Handle what to do if there is existing account with same email/username like authenticated identity provider", "providerId": "basic-flow", "topLevel": false, "builtIn": true, "authenticationExecutions": [ { "authenticator": "idp-confirm-link", "requirement": "REQUIRED", "priority": 10, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "idp-email-verification", "requirement": "ALTERNATIVE", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false }, { "requirement": "ALTERNATIVE", "priority": 30, "flowAlias": "Verify Existing Account by Re-authentication", "userSetupAllowed": false, "autheticatorFlow": true } ] }, { "id": "52d9a25e-0c07-444d-b28d-42e7a24f1d11", "alias": "Verify Existing Account by Re-authentication", "description": "Reauthentication of existing account", "providerId": "basic-flow", "topLevel": false, "builtIn": true, "authenticationExecutions": [ { "authenticator": "idp-username-password-form", "requirement": "REQUIRED", "priority": 10, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "auth-otp-form", "requirement": "OPTIONAL", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false } ] }, { "id": "b4abfcba-2302-48ab-8ddb-c84bda02f139", "alias": "browser", "description": "browser based authentication", "providerId": "basic-flow", "topLevel": true, "builtIn": true, "authenticationExecutions": [ { "authenticator": "auth-cookie", "requirement": "ALTERNATIVE", "priority": 10, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "auth-spnego", "requirement": "DISABLED", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false }, { "requirement": "ALTERNATIVE", "priority": 30, "flowAlias": "forms", "userSetupAllowed": false, "autheticatorFlow": true } ] }, { "id": "776cf637-b7e8-4267-8564-7dcb6aa3ba9c", "alias": "clients", "description": "Base authentication for clients", "providerId": "client-flow", "topLevel": true, "builtIn": true, "authenticationExecutions": [ { "authenticator": "client-secret", "requirement": "ALTERNATIVE", "priority": 10, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "client-jwt", "requirement": "ALTERNATIVE", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false } ] }, { "id": "8bd0ddb1-60b4-4f4a-b8e8-8e26acc78e3b", "alias": "direct grant", "description": "OpenID Connect Resource Owner Grant", "providerId": "basic-flow", "topLevel": true, "builtIn": true, "authenticationExecutions": [ { "authenticator": "direct-grant-validate-username", "requirement": "REQUIRED", "priority": 10, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "direct-grant-validate-password", "requirement": "REQUIRED", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "direct-grant-validate-otp", "requirement": "OPTIONAL", "priority": 30, "userSetupAllowed": false, "autheticatorFlow": false } ] }, { "id": "e01eb3ab-23d4-48a4-87fd-3d55e3a373d2", "alias": "first broker login", "description": "Actions taken after first broker login with identity provider account, which is not yet linked to any Keycloak account", "providerId": "basic-flow", "topLevel": true, "builtIn": true, "authenticationExecutions": [ { "authenticatorConfig": "review profile config", "authenticator": "idp-review-profile", "requirement": "REQUIRED", "priority": 10, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticatorConfig": "create unique user config", "authenticator": "idp-create-user-if-unique", "requirement": "ALTERNATIVE", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false }, { "requirement": "ALTERNATIVE", "priority": 30, "flowAlias": "Handle Existing Account", "userSetupAllowed": false, "autheticatorFlow": true } ] }, { "id": "b17be33a-5ddf-43cc-95aa-2cd69b15b1ea", "alias": "forms", "description": "Username, password, otp and other auth forms.", "providerId": "basic-flow", "topLevel": false, "builtIn": true, "authenticationExecutions": [ { "authenticator": "auth-username-password-form", "requirement": "REQUIRED", "priority": 10, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "auth-otp-form", "requirement": "OPTIONAL", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false } ] }, { "id": "0e0d5e97-b785-4281-948c-d71cd1727214", "alias": "registration", "description": "registration flow", "providerId": "basic-flow", "topLevel": true, "builtIn": true, "authenticationExecutions": [ { "authenticator": "registration-page-form", "requirement": "REQUIRED", "priority": 10, "flowAlias": "registration form", "userSetupAllowed": false, "autheticatorFlow": true } ] }, { "id": "b62130e5-e565-4491-aa1d-7eb22b96340a", "alias": "registration form", "description": "registration form", "providerId": "form-flow", "topLevel": false, "builtIn": true, "authenticationExecutions": [ { "authenticator": "registration-user-creation", "requirement": "REQUIRED", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "registration-profile-action", "requirement": "REQUIRED", "priority": 40, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "registration-password-action", "requirement": "REQUIRED", "priority": 50, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "registration-recaptcha-action", "requirement": "DISABLED", "priority": 60, "userSetupAllowed": false, "autheticatorFlow": false } ] }, { "id": "d15ec48f-93a6-4a5f-81a5-0d8aa739b032", "alias": "reset credentials", "description": "Reset credentials for a user if they forgot their password or something", "providerId": "basic-flow", "topLevel": true, "builtIn": true, "authenticationExecutions": [ { "authenticator": "reset-credentials-choose-user", "requirement": "REQUIRED", "priority": 10, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "reset-credential-email", "requirement": "REQUIRED", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "reset-password", "requirement": "REQUIRED", "priority": 30, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "reset-otp", "requirement": "OPTIONAL", "priority": 40, "userSetupAllowed": false, "autheticatorFlow": false } ] } ], "authenticatorConfig": [ { "alias": "create unique user config", "config": { "require.password.update.after.registration": "false" } }, { "alias": "review profile config", "config": { "update.profile.on.first.login": "missing" } } ], "requiredActions": [ { "alias": "CONFIGURE_TOTP", "name": "Configure Totp", "providerId": "CONFIGURE_TOTP", "enabled": true, "defaultAction": false, "config": {} }, { "alias": "UPDATE_PASSWORD", "name": "Update Password", "providerId": "UPDATE_PASSWORD", "enabled": true, "defaultAction": false, "config": {} }, { "alias": "UPDATE_PROFILE", "name": "Update Profile", "providerId": "UPDATE_PROFILE", "enabled": true, "defaultAction": false, "config": {} }, { "alias": "VERIFY_EMAIL", "name": "Verify Email", "providerId": "VERIFY_EMAIL", "enabled": true, "defaultAction": false, "config": {} }, { "alias": "terms_and_conditions", "name": "Terms and Conditions", "providerId": "terms_and_conditions", "enabled": false, "defaultAction": false, "config": {} } ], "browserFlow": "browser", "registrationFlow": "registration", "directGrantFlow": "direct grant", "resetCredentialsFlow": "reset credentials", "clientAuthenticationFlow": "clients" }, { "id": "master", "realm": "master", "notBefore": 1457967229, "revokeRefreshToken": false, "accessTokenLifespan": 1800, "accessTokenLifespanForImplicitFlow": 900, "ssoSessionIdleTimeout": 1800, "ssoSessionMaxLifespan": 36000, "offlineSessionIdleTimeout": 2592000, "accessCodeLifespan": 60, "accessCodeLifespanUserAction": 300, "accessCodeLifespanLogin": 1800, "enabled": true, "sslRequired": "all", "registrationAllowed": false, "registrationEmailAsUsername": true, "rememberMe": true, "verifyEmail": true, "resetPasswordAllowed": true, "editUsernameAllowed": true, "bruteForceProtected": false, "maxFailureWaitSeconds": 900, "minimumQuickLoginWaitSeconds": 60, "waitIncrementSeconds": 60, "quickLoginCheckMilliSeconds": 1000, "maxDeltaTimeSeconds": 43200, "failureFactor": 30, "privateKey": "MIIEowIBAAKCAQEAnCdIogmClWETmRKSH8Iow53XCfVA8i55pDMpRe69jff1P86hGtSVSMknN1ZGVq1bHxbf9umIpzxUPTcDWMna2HpDOdm6I0oLLHXeMrIZfzaw3sClkuHF0mWJC6ykRzmdSqfEC3KoY+Qeg2IUAr5SzWFTB62C8mkcRcOdVvT3fTacZl+GEDHLUyhBB2rinT9HyEdSrj9Bi605kyR7ll8va0OVz+nOsw/TcDuP4Xa9OXrLPSNFafiS9e7PPAB33g/So0ZEH7xDx+13Hoq4MdtvXkn5/eRBU+20xg7AChImF17rYnCwrvqE5gZ8Hrtw6iqsLBB0uPGOP18m9epg2yClgwIDAQABAoIBAG2JUPX5XdSTaD/0OvR0KkwuKG4f0BMSbtmz2bvooKc5zJuZwoEjpiSMlinHJ0geCtFgJnL5lpZZR245bOuXjSBVg1rNVDj086mYdOly7VfDcYaP9JV4MmBIQT4jOImN7Lw1utuc7mpD1vOqlQbnowXWw3ubR0PsX5zAf1pENGdsDJNNgQXllMgSB+BkoWejiotsMQWyzivnoSkjCkAtSbRgK5sFU9wE5i54V4hjfFUaf5KthRXpAFnW1TsE05nzDMFcWKzw5+EFchPpURFk9dL/U8tPUgxQDBQIBwwOzBfZf8GyfbROazPd82VlNCm6XXrGyH9H7sL0RmncZlW8/MECgYEA95GBR1r1hVLi2PtZZpGnlN22TDqfT9IAteQNc2j9oDAE5C2Ex6Q0C/tNvW8PYDTZAAQlt/QEzMfZemqOFAlpQ8w0UnywWYc5NGS+0ZBIn+gYMZzAp+/f4gT5tO/IChsRwTOTpKrYTU+7gKkNJWe3FO8xzk1xdLMrRTdGUtCDmBkCgYEAoXjAdlSd4ykEhXVKNR87vOanOvbYKmYLr+T4f0K+ravanW+ajyto/JtnuAZ9WB1L2vbOmXKTwj5v8ulnFQ2GVYaWIZvdiP3rBCY7VZwJwpwN+ODjSQyMYmbNqLGclzcY2CacAkn2m0ZSP3HkDoc0RNxPAZ9JOfxFSvUKpleTTfsCgYAHcg3USo0FxHdkFTMcHZdPp9datYyjBurUjZZF+UtfbPJItoG+y1ZxYc51uwhYWV6JXJaR0LnwOrZ0sw2w1pOe4V5VeMCJAMMcq0b94Hv+qylHHLLCmjk+f+3OnkOC4kuHZviyxBybPqGh/fOSQ2tDKupxjOyzmMvdWgs4ZGMAyQKBgAmHEXwp9AMCWZTyXcWSqTi1N2rgQ9MEoG3picwgiRXATS769di6zAATv2P5Zg379IzgAULGovdULdDcesugN6v2PAeRpdm+ec6N3vRnN6A3CxADXQXjaqknvbzVdhLqGloutQfhi16QIKxDsRw2WBw0D6ld17lHLGOG3/D+u99fAoGBAJb7KBJtcE7CuBeLJ42Vq4WCXj1xDq8Aj3ZQ4TFkqlEusxpnP99eADSbbQ6IDTN9uwROnNer2iM3lNceHBB3oCCMLAykf6HGxrjFseKWVZYLY73Q/ITPjWxiAD/sCNAinHTO2bA3JZyQmaRJ2Ul1pZVxnvFgl3t3M9DifnaSyH65", "publicKey": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnCdIogmClWETmRKSH8Iow53XCfVA8i55pDMpRe69jff1P86hGtSVSMknN1ZGVq1bHxbf9umIpzxUPTcDWMna2HpDOdm6I0oLLHXeMrIZfzaw3sClkuHF0mWJC6ykRzmdSqfEC3KoY+Qeg2IUAr5SzWFTB62C8mkcRcOdVvT3fTacZl+GEDHLUyhBB2rinT9HyEdSrj9Bi605kyR7ll8va0OVz+nOsw/TcDuP4Xa9OXrLPSNFafiS9e7PPAB33g/So0ZEH7xDx+13Hoq4MdtvXkn5/eRBU+20xg7AChImF17rYnCwrvqE5gZ8Hrtw6iqsLBB0uPGOP18m9epg2yClgwIDAQAB", "certificate": "MIICmzCCAYMCBgFSXlE/DDANBgkqhkiG9w0BAQsFADARMQ8wDQYDVQQDDAZtYXN0ZXIwHhcNMTYwMTIwMDkxMzQ4WhcNMjYwMTIwMDkxNTI4WjARMQ8wDQYDVQQDDAZtYXN0ZXIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCcJ0iiCYKVYROZEpIfwijDndcJ9UDyLnmkMylF7r2N9/U/zqEa1JVIySc3VkZWrVsfFt/26YinPFQ9NwNYydrYekM52bojSgssdd4yshl/NrDewKWS4cXSZYkLrKRHOZ1Kp8QLcqhj5B6DYhQCvlLNYVMHrYLyaRxFw51W9Pd9NpxmX4YQMctTKEEHauKdP0fIR1KuP0GLrTmTJHuWXy9rQ5XP6c6zD9NwO4/hdr05ess9I0Vp+JL17s88AHfeD9KjRkQfvEPH7Xceirgx229eSfn95EFT7bTGDsAKEiYXXuticLCu+oTmBnweu3DqKqwsEHS48Y4/Xyb16mDbIKWDAgMBAAEwDQYJKoZIhvcNAQELBQADggEBACz0belJeUpPqMejt7OQG0UJ+ZX7z7SXFqGVQi8gQGChLVEzKMsbpOSSV0tWvuuBkrIIctIrtdCBjNylBrCgT42x5lEFx7PR3HbkmAG4DYH7reMWqIwHcvMILC8R+4isH3SiWxUywy8HSxTRKwOXXE2DWkwtppzis8ijnm73BmUTvX+bTphbGFVK90etfMaZLLDTWSnG3ZMVI2H9L54z2Zk5omcQn9JLg0RI/TQ6r3xJtJ2blb/coWiar5moCrDcbYHy7wh/845Xj08Srd0yHc4nv07R0utfM8nNP6N8Y12WHyIyDZMErPWeQckJOv3wl67rw65Ae3YF6Mq5b9lzhZ0=", "codeSecret": "4f25a961-53eb-45c6-baa1-415522c40b2d", "roles": { "realm": [ { "id": "19a7d556-a847-4d07-8ada-a2f1df48d9f1", "name": "admin", "description": "${role_admin}", "scopeParamRequired": false, "composite": true, "composites": { "realm": [ "create-realm" ], "client": { "cis-p-T102-0000002-realm": [ "create-client", "view-identity-providers", "manage-realm", "manage-clients", "view-realm", "manage-identity-providers", "view-events", "view-clients", "view-users", "manage-events", "impersonation", "manage-users" ], "Test-realm": [ "manage-events", "view-events", "manage-clients", "create-client", "view-users", "manage-realm", "view-clients", "view-realm", "view-identity-providers", "manage-identity-providers", "impersonation", "manage-users" ], "BluLogix-realm": [ "view-realm", "manage-events", "manage-users", "manage-realm", "view-clients", "impersonation", "view-events", "manage-identity-providers", "create-client", "view-identity-providers", "view-users", "manage-clients" ], "master-realm": [ "view-users", "view-identity-providers", "manage-users", "manage-identity-providers", "view-clients", "view-realm", "manage-realm", "create-client", "view-events", "manage-events", "impersonation", "manage-clients" ] } } }, { "id": "62ed373a-89fd-41bb-8373-19a6bbdcd4c1", "name": "create-realm", "description": "${role_create-realm}", "scopeParamRequired": false, "composite": false }, { "id": "1d5b3a93-91c5-4de8-888f-9e88f55cd66f", "name": "offline_access", "description": "${role_offline-access}", "scopeParamRequired": true, "composite": false } ], "client": { "cis-p-T102-0000002-realm": [ { "id": "a206e5e8-922a-4674-908f-c7c9e747ba38", "name": "view-realm", "description": "${role_view-realm}", "scopeParamRequired": false, "composite": false }, { "id": "b572ad1c-0aa7-4276-9858-e57478219ed1", "name": "create-client", "description": "${role_create-client}", "scopeParamRequired": false, "composite": false }, { "id": "89d073cc-19c6-42b6-a67c-b2eed96b172a", "name": "manage-events", "description": "${role_manage-events}", "scopeParamRequired": false, "composite": false }, { "id": "f8cea2bd-020e-4038-9452-e27a549db675", "name": "manage-identity-providers", "description": "${role_manage-identity-providers}", "scopeParamRequired": false, "composite": false }, { "id": "e6860fc5-57d6-4ca6-bf69-5007bad4f050", "name": "view-events", "description": "${role_view-events}", "scopeParamRequired": false, "composite": false }, { "id": "8283eb68-6b42-4e78-8871-b77b22b8acca", "name": "impersonation", "description": "${role_impersonation}", "scopeParamRequired": false, "composite": false }, { "id": "bd7b7062-b4b8-4556-9b6f-43b6dcfcf4b6", "name": "view-clients", "description": "${role_view-clients}", "scopeParamRequired": false, "composite": false }, { "id": "c79dfddc-a262-46b0-bd6b-89ad53019675", "name": "manage-users", "description": "${role_manage-users}", "scopeParamRequired": false, "composite": false }, { "id": "3d7aacd1-02a5-42a8-8a25-a0bb01af05be", "name": "view-identity-providers", "description": "${role_view-identity-providers}", "scopeParamRequired": false, "composite": false }, { "id": "6107d4b3-9c71-48d0-8de5-5151a4b42cbd", "name": "manage-realm", "description": "${role_manage-realm}", "scopeParamRequired": false, "composite": false }, { "id": "08268084-f717-4d96-9dd3-19d069d9f737", "name": "manage-clients", "description": "${role_manage-clients}", "scopeParamRequired": false, "composite": false }, { "id": "a463dd0e-27fa-4679-b664-87cbe1a235d9", "name": "view-users", "description": "${role_view-users}", "scopeParamRequired": false, "composite": false } ], "Test-realm": [ { "id": "0a5b0184-c697-4c68-b612-04a56a8ab3ec", "name": "manage-realm", "description": "${role_manage-realm}", "scopeParamRequired": false, "composite": false }, { "id": "9c1f3489-920a-4fff-b14c-1ea55a5a1e24", "name": "manage-events", "description": "${role_manage-events}", "scopeParamRequired": false, "composite": false }, { "id": "2e5ab0c7-68af-4241-8517-709f7324a3ff", "name": "manage-clients", "description": "${role_manage-clients}", "scopeParamRequired": false, "composite": false }, { "id": "2d9c1052-9e79-4f18-9c44-4d14c7b3876c", "name": "impersonation", "description": "${role_impersonation}", "scopeParamRequired": false, "composite": false }, { "id": "396d8fc0-78aa-4a71-a72b-4fe1a3250ffd", "name": "create-client", "description": "${role_create-client}", "scopeParamRequired": false, "composite": false }, { "id": "bc180464-33a9-4594-acaf-7c9832fee529", "name": "view-realm", "description": "${role_view-realm}", "scopeParamRequired": false, "composite": false }, { "id": "15d68be9-04a0-4881-82a8-f3aeef2105f6", "name": "view-events", "description": "${role_view-events}", "scopeParamRequired": false, "composite": false }, { "id": "dd3b9c80-0778-4ce4-813a-ef98f2f076fa", "name": "manage-users", "description": "${role_manage-users}", "scopeParamRequired": false, "composite": false }, { "id": "ce4a3198-70b2-4401-bf4b-7cf7fe336a0d", "name": "view-identity-providers", "description": "${role_view-identity-providers}", "scopeParamRequired": false, "composite": false }, { "id": "77844130-7f1b-4634-adc2-e785f3eab3da", "name": "manage-identity-providers", "description": "${role_manage-identity-providers}", "scopeParamRequired": false, "composite": false }, { "id": "2ab52e4f-06df-4370-83c1-8e74cb4dbade", "name": "view-users", "description": "${role_view-users}", "scopeParamRequired": false, "composite": false }, { "id": "4cbe5e5f-178d-47b7-9a02-ee2648269522", "name": "view-clients", "description": "${role_view-clients}", "scopeParamRequired": false, "composite": false } ], "security-admin-console": [], "BluLogix-realm": [ { "id": "3d6b7c66-f8d1-47b4-8c3d-f5d64929a0f6", "name": "view-events", "description": "${role_view-events}", "scopeParamRequired": false, "composite": false }, { "id": "bd6f06ae-3aa6-4b8d-9b1d-faaa77f4b38e", "name": "view-users", "description": "${role_view-users}", "scopeParamRequired": false, "composite": false }, { "id": "8e30faf0-7dfa-4be9-80f5-1ee7779dd625", "name": "view-clients", "description": "${role_view-clients}", "scopeParamRequired": false, "composite": false }, { "id": "3285810d-c154-44ca-8208-b3a847c6c668", "name": "manage-events", "description": "${role_manage-events}", "scopeParamRequired": false, "composite": false }, { "id": "41eb2f3b-f8fd-4190-be10-c1809deb2a57", "name": "manage-users", "description": "${role_manage-users}", "scopeParamRequired": false, "composite": false }, { "id": "b4caa233-a301-4dd8-8503-c01e20a9a501", "name": "manage-realm", "description": "${role_manage-realm}", "scopeParamRequired": false, "composite": false }, { "id": "5e386d9f-b6b4-46ed-b445-cbf276d54d61", "name": "manage-identity-providers", "description": "${role_manage-identity-providers}", "scopeParamRequired": false, "composite": false }, { "id": "b4a745de-5475-4342-a5cd-fa2c2ecfc8b3", "name": "view-realm", "description": "${role_view-realm}", "scopeParamRequired": false, "composite": false }, { "id": "92822b7b-3ef8-473a-b78b-cfa05ac2aa8a", "name": "impersonation", "description": "${role_impersonation}", "scopeParamRequired": false, "composite": false }, { "id": "5c2eab59-a99b-4e6f-b2da-208f85624dff", "name": "manage-clients", "description": "${role_manage-clients}", "scopeParamRequired": false, "composite": false }, { "id": "d36f56de-038c-4ab9-903f-e4f09414ef87", "name": "create-client", "description": "${role_create-client}", "scopeParamRequired": false, "composite": false }, { "id": "b540a90a-b223-42eb-b838-a911442f0aa1", "name": "view-identity-providers", "description": "${role_view-identity-providers}", "scopeParamRequired": false, "composite": false } ], "admin-cli": [], "CCCCC": [], "broker": [ { "id": "eb9bb617-33d3-4842-bc88-4b89495a89fd", "name": "read-token", "description": "${role_read-token}", "scopeParamRequired": false, "composite": false } ], "master-realm": [ { "id": "35aa428c-f6e2-4673-9226-8389f6ef315d", "name": "manage-realm", "description": "${role_manage-realm}", "scopeParamRequired": false, "composite": false }, { "id": "77983826-60b6-4b6e-bd94-fb34a62ad1b1", "name": "manage-events", "description": "${role_manage-events}", "scopeParamRequired": false, "composite": false }, { "id": "dccb4ae9-85c6-4efc-a061-fc5f72ceebff", "name": "view-users", "description": "${role_view-users}", "scopeParamRequired": false, "composite": false }, { "id": "9948b0f1-e8cd-4350-a60e-06e43e9216c0", "name": "impersonation", "description": "${role_impersonation}", "scopeParamRequired": false, "composite": false }, { "id": "f4b31534-4919-41e9-8998-3f0643a12d94", "name": "manage-identity-providers", "description": "${role_manage-identity-providers}", "scopeParamRequired": false, "composite": false }, { "id": "51f3eebd-df90-4ca5-bcec-b5912361f2e2", "name": "view-clients", "description": "${role_view-clients}", "scopeParamRequired": false, "composite": false }, { "id": "f3f9eada-3f0b-4b42-9166-bd63037abaf6", "name": "view-events", "description": "${role_view-events}", "scopeParamRequired": false, "composite": false }, { "id": "abaa56df-aa57-4d5e-b1b6-fcf3dabdb8e8", "name": "view-identity-providers", "description": "${role_view-identity-providers}", "scopeParamRequired": false, "composite": false }, { "id": "221af9bb-eb9c-4063-8975-00d09770da90", "name": "view-realm", "description": "${role_view-realm}", "scopeParamRequired": false, "composite": false }, { "id": "120acc78-b6d5-40c1-a274-04dccc0ca204", "name": "manage-users", "description": "${role_manage-users}", "scopeParamRequired": false, "composite": false }, { "id": "45c1fcd7-715e-4f25-a67a-826046583ea2", "name": "create-client", "description": "${role_create-client}", "scopeParamRequired": false, "composite": false }, { "id": "bebb6675-5d87-4070-adfa-ee592c7b4354", "name": "manage-clients", "description": "${role_manage-clients}", "scopeParamRequired": false, "composite": false } ], "account": [ { "id": "6ddadb41-aaec-41c9-9cb0-9f2d35f6b6c3", "name": "manage-account", "description": "${role_manage-account}", "scopeParamRequired": false, "composite": false }, { "id": "4903c5ff-d365-4261-afbf-ce654e4ba1df", "name": "view-profile", "description": "${role_view-profile}", "scopeParamRequired": false, "composite": false } ] } }, "groups": [], "defaultRoles": [ "offline_access" ], "requiredCredentials": [ "password" ], "otpPolicyType": "totp", "otpPolicyAlgorithm": "HmacSHA1", "otpPolicyInitialCounter": 0, "otpPolicyDigits": 6, "otpPolicyLookAheadWindow": 1, "otpPolicyPeriod": 30, "users": [], "scopeMappings": [ { "client": "admin-cli", "roles": [ "admin" ] }, { "client": "security-admin-console", "roles": [ "admin" ] } ], "clients": [ { "id": "d4e09f02-c339-4bca-9a89-e1547e59c07d", "clientId": "BluLogix-realm", "name": "BluLogix Realm", "surrogateAuthRequired": false, "enabled": true, "clientAuthenticatorType": "client-secret", "secret": "8ec0bb88-f731-4cef-98d1-cb42c6ce6d9a", "redirectUris": [], "webOrigins": [], "notBefore": 0, "bearerOnly": true, "consentRequired": false, "standardFlowEnabled": true, "implicitFlowEnabled": false, "directAccessGrantsEnabled": false, "serviceAccountsEnabled": false, "publicClient": false, "frontchannelLogout": false, "attributes": {}, "fullScopeAllowed": true, "nodeReRegistrationTimeout": 0, "protocolMappers": [ { "id": "7738d536-e85e-4a17-9354-44c522f3fa82", "name": "family name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${familyName}", "config": { "user.attribute": "lastName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "family_name", "jsonType.label": "String" } }, { "id": "1b255962-5579-4512-9979-19283638279c", "name": "role list", "protocol": "saml", "protocolMapper": "saml-role-list-mapper", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } }, { "id": "76d714dd-2faa-4696-8bc4-84c3a38a9948", "name": "username", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${username}", "config": { "user.attribute": "username", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "preferred_username", "jsonType.label": "String" } }, { "id": "85fe191c-d3f4-45da-96ef-81abdcb0e3f8", "name": "email", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${email}", "config": { "user.attribute": "email", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email", "jsonType.label": "String" } }, { "id": "75a9709e-88b0-47d6-8004-e86acd4247f8", "name": "given name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${givenName}", "config": { "user.attribute": "firstName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "given_name", "jsonType.label": "String" } }, { "id": "6b37a02c-8090-469a-a819-1cae558fcd17", "name": "full name", "protocol": "openid-connect", "protocolMapper": "oidc-full-name-mapper", "consentRequired": true, "consentText": "${fullName}", "config": { "id.token.claim": "true", "access.token.claim": "true" } } ], "useTemplateConfig": false, "useTemplateScope": false, "useTemplateMappers": false }, { "id": "d02cef07-a40a-46d7-858b-54e5aeaa595e", "clientId": "CCCCC", "surrogateAuthRequired": false, "enabled": true, "clientAuthenticatorType": "client-secret", "secret": "cebbc92a-ab20-47a9-9ab6-5b5e769a74ab", "redirectUris": [], "webOrigins": [], "notBefore": 0, "bearerOnly": false, "consentRequired": false, "standardFlowEnabled": true, "implicitFlowEnabled": false, "directAccessGrantsEnabled": true, "serviceAccountsEnabled": false, "publicClient": true, "frontchannelLogout": false, "protocol": "openid-connect", "attributes": {}, "fullScopeAllowed": true, "nodeReRegistrationTimeout": -1, "protocolMappers": [ { "id": "4457114c-5c75-4a57-af73-6fc7ce4baccf", "name": "full name", "protocol": "openid-connect", "protocolMapper": "oidc-full-name-mapper", "consentRequired": true, "consentText": "${fullName}", "config": { "id.token.claim": "true", "access.token.claim": "true" } }, { "id": "31036a99-0566-4e64-b544-8f7dbb0feaea", "name": "role list", "protocol": "saml", "protocolMapper": "saml-role-list-mapper", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } }, { "id": "d66825d4-36cd-401e-ad13-b5118b69b8f3", "name": "email", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${email}", "config": { "user.attribute": "email", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email", "jsonType.label": "String" } }, { "id": "4af4cdb6-c124-476c-bc22-f048c41635cd", "name": "family name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${familyName}", "config": { "user.attribute": "lastName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "family_name", "jsonType.label": "String" } }, { "id": "8b488858-ffb4-4596-a797-663f18adcc18", "name": "username", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${username}", "config": { "user.attribute": "username", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "preferred_username", "jsonType.label": "String" } }, { "id": "ec30ea4b-f333-4fd4-81c4-812cc25aa62c", "name": "given name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${givenName}", "config": { "user.attribute": "firstName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "given_name", "jsonType.label": "String" } } ], "useTemplateConfig": false, "useTemplateScope": false, "useTemplateMappers": false }, { "id": "370159cb-6579-4eca-a871-b1b033d9955e", "clientId": "Test-realm", "name": "Test Realm", "surrogateAuthRequired": false, "enabled": true, "clientAuthenticatorType": "client-secret", "secret": "ea10f2ce-9e2d-4406-80b2-4abb01279ca7", "redirectUris": [], "webOrigins": [], "notBefore": 0, "bearerOnly": true, "consentRequired": false, "standardFlowEnabled": true, "implicitFlowEnabled": false, "directAccessGrantsEnabled": false, "serviceAccountsEnabled": false, "publicClient": false, "frontchannelLogout": false, "attributes": {}, "fullScopeAllowed": true, "nodeReRegistrationTimeout": 0, "protocolMappers": [ { "id": "8d190663-f649-47f9-bb70-164d91d01201", "name": "family name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${familyName}", "config": { "user.attribute": "lastName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "family_name", "jsonType.label": "String" } }, { "id": "fe2db5c6-4d84-467d-9d20-ddf57dd63cc7", "name": "username", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${username}", "config": { "user.attribute": "username", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "preferred_username", "jsonType.label": "String" } }, { "id": "34f5f093-da1f-4dd1-9a52-4fa7055fdc45", "name": "given name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${givenName}", "config": { "user.attribute": "firstName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "given_name", "jsonType.label": "String" } }, { "id": "2ef71afa-0bca-42d7-aad6-284179da382a", "name": "email", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${email}", "config": { "user.attribute": "email", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email", "jsonType.label": "String" } }, { "id": "b6b86c08-eabc-4131-bd42-28e496dd181b", "name": "full name", "protocol": "openid-connect", "protocolMapper": "oidc-full-name-mapper", "consentRequired": true, "consentText": "${fullName}", "config": { "id.token.claim": "true", "access.token.claim": "true" } }, { "id": "ec1f25f5-5aa8-422f-ab90-14b3bb4f32e1", "name": "role list", "protocol": "saml", "protocolMapper": "saml-role-list-mapper", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } } ], "useTemplateConfig": false, "useTemplateScope": false, "useTemplateMappers": false }, { "id": "7f090257-ceec-429d-b0e3-947a4fcfe3ea", "clientId": "account", "name": "${client_account}", "baseUrl": "/auth/realms/master/account", "surrogateAuthRequired": false, "enabled": true, "clientAuthenticatorType": "client-secret", "secret": "1b470e66-93ed-46d7-84ff-790ed2cff54f", "defaultRoles": [ "view-profile", "manage-account" ], "redirectUris": [ "/auth/realms/master/account/*" ], "webOrigins": [], "notBefore": 0, "bearerOnly": false, "consentRequired": false, "standardFlowEnabled": true, "implicitFlowEnabled": false, "directAccessGrantsEnabled": true, "serviceAccountsEnabled": false, "publicClient": false, "frontchannelLogout": false, "protocol": "openid-connect", "attributes": { "saml.assertion.signature": "false", "saml.force.post.binding": "false", "saml.multivalued.roles": "false", "saml.encrypt": "false", "saml_force_name_id_format": "false", "saml.client.signature": "false", "saml.authnstatement": "false", "saml.server.signature": "false" }, "fullScopeAllowed": false, "nodeReRegistrationTimeout": 0, "protocolMappers": [ { "id": "0b68f5a9-559d-4b0e-bf3f-c13831964c00", "name": "username", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${username}", "config": { "user.attribute": "username", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "preferred_username", "jsonType.label": "String" } }, { "id": "59386658-2c1d-4e55-b550-67353cbe1a39", "name": "email", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${email}", "config": { "user.attribute": "email", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email", "jsonType.label": "String" } }, { "id": "b3c975b9-8840-492f-9119-5d4f11c3a24d", "name": "role list", "protocol": "saml", "protocolMapper": "saml-role-list-mapper", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } }, { "id": "a05f2141-e8d5-4868-874e-0f8123fae6b0", "name": "given name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${givenName}", "config": { "user.attribute": "firstName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "given_name", "jsonType.label": "String" } }, { "id": "93f5ffeb-8087-47fa-98df-2a2babf16b57", "name": "family name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${familyName}", "config": { "user.attribute": "lastName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "family_name", "jsonType.label": "String" } }, { "id": "d590fefc-d10a-4e55-8b53-12c5f67c218c", "name": "full name", "protocol": "openid-connect", "protocolMapper": "oidc-full-name-mapper", "consentRequired": true, "consentText": "${fullName}", "config": { "id.token.claim": "true", "access.token.claim": "true" } } ], "useTemplateConfig": false, "useTemplateScope": false, "useTemplateMappers": false }, { "id": "f73ad9b7-f192-40eb-a3d3-bb9599272b04", "clientId": "admin-cli", "name": "${client_admin-cli}", "surrogateAuthRequired": false, "enabled": true, "clientAuthenticatorType": "client-secret", "secret": "548c591d-69af-46bf-a223-c60f243a34b6", "redirectUris": [], "webOrigins": [], "notBefore": 0, "bearerOnly": false, "consentRequired": false, "standardFlowEnabled": false, "implicitFlowEnabled": false, "directAccessGrantsEnabled": true, "serviceAccountsEnabled": false, "publicClient": true, "frontchannelLogout": false, "attributes": {}, "fullScopeAllowed": false, "nodeReRegistrationTimeout": 0, "protocolMappers": [ { "id": "ce0fcf42-0def-425c-94a9-dc5f4036d01c", "name": "role list", "protocol": "saml", "protocolMapper": "saml-role-list-mapper", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } }, { "id": "725f56a2-4e80-44e4-9eaf-1e1fbd1b33ad", "name": "family name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${familyName}", "config": { "user.attribute": "lastName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "family_name", "jsonType.label": "String" } }, { "id": "2797d9ed-d4fe-4f17-b69b-136df6a5f761", "name": "username", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${username}", "config": { "user.attribute": "username", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "preferred_username", "jsonType.label": "String" } }, { "id": "8e860be4-c4c7-41b1-a292-ee3120cf0687", "name": "given name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${givenName}", "config": { "user.attribute": "firstName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "given_name", "jsonType.label": "String" } }, { "id": "45e548dd-96b7-4507-9dfc-644f9697ba7b", "name": "full name", "protocol": "openid-connect", "protocolMapper": "oidc-full-name-mapper", "consentRequired": true, "consentText": "${fullName}", "config": { "id.token.claim": "true", "access.token.claim": "true" } }, { "id": "127b9e1a-af40-4475-9cd8-c2348a65daa9", "name": "email", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${email}", "config": { "user.attribute": "email", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email", "jsonType.label": "String" } } ], "useTemplateConfig": false, "useTemplateScope": false, "useTemplateMappers": false }, { "id": "ee09e5cc-7afb-45a3-8798-25cd4041adec", "clientId": "broker", "name": "${client_broker}", "surrogateAuthRequired": false, "enabled": true, "clientAuthenticatorType": "client-secret", "secret": "a3c847c4-f945-44a0-86e3-399ab3cef173", "redirectUris": [], "webOrigins": [], "notBefore": 0, "bearerOnly": false, "consentRequired": false, "standardFlowEnabled": true, "implicitFlowEnabled": false, "directAccessGrantsEnabled": false, "serviceAccountsEnabled": false, "publicClient": false, "frontchannelLogout": false, "attributes": {}, "fullScopeAllowed": false, "nodeReRegistrationTimeout": 0, "protocolMappers": [ { "id": "53431658-f4c7-4389-a132-592f0975f1e7", "name": "given name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${givenName}", "config": { "user.attribute": "firstName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "given_name", "jsonType.label": "String" } }, { "id": "32cb41c8-1fa7-423a-bb0a-ed63d3f667b8", "name": "username", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${username}", "config": { "user.attribute": "username", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "preferred_username", "jsonType.label": "String" } }, { "id": "746f7515-5801-415d-8dde-4b14f8584d82", "name": "full name", "protocol": "openid-connect", "protocolMapper": "oidc-full-name-mapper", "consentRequired": true, "consentText": "${fullName}", "config": { "id.token.claim": "true", "access.token.claim": "true" } }, { "id": "95f206ce-9067-444d-97e8-adeabf86742d", "name": "email", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${email}", "config": { "user.attribute": "email", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email", "jsonType.label": "String" } }, { "id": "67abc4e7-32f8-4397-9c21-fa8784e24f34", "name": "family name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${familyName}", "config": { "user.attribute": "lastName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "family_name", "jsonType.label": "String" } }, { "id": "8d65c546-a4b1-4d26-ad22-7df862e54158", "name": "role list", "protocol": "saml", "protocolMapper": "saml-role-list-mapper", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } } ], "useTemplateConfig": false, "useTemplateScope": false, "useTemplateMappers": false }, { "id": "f17f466d-ab00-45a9-b1ed-a958816fc14e", "clientId": "cis-p-T102-0000002-realm", "name": "cis-p-T102-0000002 Realm", "surrogateAuthRequired": false, "enabled": true, "clientAuthenticatorType": "client-secret", "secret": "6bbb6b42-2fe2-4a6d-8426-8a0cd318958f", "redirectUris": [], "webOrigins": [], "notBefore": 0, "bearerOnly": true, "consentRequired": false, "standardFlowEnabled": true, "implicitFlowEnabled": false, "directAccessGrantsEnabled": false, "serviceAccountsEnabled": false, "publicClient": false, "frontchannelLogout": false, "attributes": {}, "fullScopeAllowed": true, "nodeReRegistrationTimeout": 0, "protocolMappers": [ { "id": "11e3f127-65c5-410e-8497-1344f9c011d2", "name": "email", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${email}", "config": { "user.attribute": "email", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email", "jsonType.label": "String" } }, { "id": "b2ec893d-c734-4893-8d38-005b9e31ccb0", "name": "family name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${familyName}", "config": { "user.attribute": "lastName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "family_name", "jsonType.label": "String" } }, { "id": "8980f64e-9691-4f53-9684-b7cb6ef0c5eb", "name": "full name", "protocol": "openid-connect", "protocolMapper": "oidc-full-name-mapper", "consentRequired": true, "consentText": "${fullName}", "config": { "id.token.claim": "true", "access.token.claim": "true" } }, { "id": "3abd37d0-8a9b-4151-88f9-5df9c191dcfb", "name": "username", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${username}", "config": { "user.attribute": "username", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "preferred_username", "jsonType.label": "String" } }, { "id": "9dac32df-b5a7-4e4a-b477-d083f9d378b5", "name": "role list", "protocol": "saml", "protocolMapper": "saml-role-list-mapper", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } }, { "id": "5feec88b-e070-4c8a-a7a0-356a3b66fff1", "name": "given name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${givenName}", "config": { "user.attribute": "firstName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "given_name", "jsonType.label": "String" } } ], "useTemplateConfig": false, "useTemplateScope": false, "useTemplateMappers": false }, { "id": "1ea35428-f6c8-47e0-91b2-17470bd3f963", "clientId": "master-realm", "name": "master Realm", "surrogateAuthRequired": false, "enabled": true, "clientAuthenticatorType": "client-secret", "secret": "62223e3a-d23e-4c0d-bd5e-52926aa486f7", "redirectUris": [], "webOrigins": [], "notBefore": 0, "bearerOnly": true, "consentRequired": false, "standardFlowEnabled": true, "implicitFlowEnabled": false, "directAccessGrantsEnabled": false, "serviceAccountsEnabled": false, "publicClient": false, "frontchannelLogout": false, "attributes": {}, "fullScopeAllowed": true, "nodeReRegistrationTimeout": 0, "protocolMappers": [ { "id": "05c11812-4ee8-4673-bdc7-6c92f9a259ef", "name": "username", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${username}", "config": { "user.attribute": "username", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "preferred_username", "jsonType.label": "String" } }, { "id": "ebb36dc1-925b-4b37-bd5c-ed1330b5a538", "name": "family name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${familyName}", "config": { "user.attribute": "lastName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "family_name", "jsonType.label": "String" } }, { "id": "11961162-9d1a-4b65-a7b9-fe5e09467f15", "name": "role list", "protocol": "saml", "protocolMapper": "saml-role-list-mapper", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } }, { "id": "0d17f3fb-5525-432a-b09f-07108948039b", "name": "email", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${email}", "config": { "user.attribute": "email", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email", "jsonType.label": "String" } }, { "id": "6ee143c0-a555-4382-aa2d-05c795d96d14", "name": "full name", "protocol": "openid-connect", "protocolMapper": "oidc-full-name-mapper", "consentRequired": true, "consentText": "${fullName}", "config": { "id.token.claim": "true", "access.token.claim": "true" } }, { "id": "5923bf76-91d7-47c3-8e92-9d696f65f2e8", "name": "given name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${givenName}", "config": { "user.attribute": "firstName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "given_name", "jsonType.label": "String" } } ], "useTemplateConfig": false, "useTemplateScope": false, "useTemplateMappers": false }, { "id": "88191502-6b85-4b3b-92a0-5c211e211f40", "clientId": "security-admin-console", "name": "${client_security-admin-console}", "baseUrl": "/auth/admin/master/console/index.html", "surrogateAuthRequired": false, "enabled": true, "clientAuthenticatorType": "client-secret", "secret": "d8d0f1a1-0f0c-4ebb-a1c6-0fdee036548a", "redirectUris": [ "/auth/admin/master/console/*" ], "webOrigins": [], "notBefore": 0, "bearerOnly": false, "consentRequired": false, "standardFlowEnabled": true, "implicitFlowEnabled": false, "directAccessGrantsEnabled": true, "serviceAccountsEnabled": false, "publicClient": true, "frontchannelLogout": false, "protocol": "openid-connect", "attributes": { "saml.assertion.signature": "false", "saml.force.post.binding": "false", "saml.multivalued.roles": "false", "saml.encrypt": "false", "saml_force_name_id_format": "false", "saml.client.signature": "false", "saml.authnstatement": "false", "saml.server.signature": "false" }, "fullScopeAllowed": false, "nodeReRegistrationTimeout": 0, "protocolMappers": [ { "id": "bf585693-cbc1-4629-a76a-44d15247d635", "name": "locale", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-attribute-mapper", "consentRequired": false, "consentText": "${locale}", "config": { "user.attribute": "locale", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "locale", "jsonType.label": "String" } }, { "id": "172b6c39-0059-41d8-bcf0-fe9069c8f7a0", "name": "email", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${email}", "config": { "user.attribute": "email", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "email", "jsonType.label": "String" } }, { "id": "c8442ee7-b9d0-4e22-bd1c-3092e5d37b44", "name": "given name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${givenName}", "config": { "user.attribute": "firstName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "given_name", "jsonType.label": "String" } }, { "id": "2a7d9620-2ec4-401a-acab-ebb5b58b1f2e", "name": "family name", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${familyName}", "config": { "user.attribute": "lastName", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "family_name", "jsonType.label": "String" } }, { "id": "b669b98b-f94b-4d84-9f85-f62f4c24bb06", "name": "full name", "protocol": "openid-connect", "protocolMapper": "oidc-full-name-mapper", "consentRequired": true, "consentText": "${fullName}", "config": { "id.token.claim": "true", "access.token.claim": "true" } }, { "id": "42174dba-cfe8-4fac-99ea-b0e949b36dee", "name": "role list", "protocol": "saml", "protocolMapper": "saml-role-list-mapper", "consentRequired": false, "config": { "single": "false", "attribute.nameformat": "Basic", "attribute.name": "Role" } }, { "id": "d946b1c2-9213-49d8-90aa-863a9c7dc158", "name": "username", "protocol": "openid-connect", "protocolMapper": "oidc-usermodel-property-mapper", "consentRequired": true, "consentText": "${username}", "config": { "user.attribute": "username", "id.token.claim": "true", "access.token.claim": "true", "claim.name": "preferred_username", "jsonType.label": "String" } } ], "useTemplateConfig": false, "useTemplateScope": false, "useTemplateMappers": false } ], "clientTemplates": [], "browserSecurityHeaders": { "xFrameOptions": "SAMEORIGIN", "contentSecurityPolicy": "frame-src 'self'" }, "smtpServer": { "password": "0785813567", "starttls": "true", "auth": "true", "port": "587", "host": "smtp.gmail.com", "from": "YasbPana at gmail.com", "ssl": "false", "user": "YasbPana at gmail.com" }, "eventsEnabled": false, "eventsListeners": [ "jboss-logging" ], "enabledEventTypes": [], "adminEventsEnabled": false, "adminEventsDetailsEnabled": false, "internationalizationEnabled": true, "supportedLocales": [ "en", "es" ], "defaultLocale": "en", "authenticationFlows": [ { "id": "8502c673-e82c-4713-8f38-0b8186a79cf9", "alias": "Handle Existing Account", "description": "Handle what to do if there is existing account with same email/username like authenticated identity provider", "providerId": "basic-flow", "topLevel": false, "builtIn": true, "authenticationExecutions": [ { "authenticator": "idp-confirm-link", "requirement": "REQUIRED", "priority": 10, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "idp-email-verification", "requirement": "ALTERNATIVE", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false }, { "requirement": "ALTERNATIVE", "priority": 30, "flowAlias": "Verify Existing Account by Re-authentication", "userSetupAllowed": false, "autheticatorFlow": true } ] }, { "id": "29806f39-15a9-4a2b-a37f-07f1527d969d", "alias": "Verify Existing Account by Re-authentication", "description": "Reauthentication of existing account", "providerId": "basic-flow", "topLevel": false, "builtIn": true, "authenticationExecutions": [ { "authenticator": "idp-username-password-form", "requirement": "REQUIRED", "priority": 10, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "auth-otp-form", "requirement": "OPTIONAL", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false } ] }, { "id": "d29fe567-0975-41f1-9232-8c3ca602e34c", "alias": "browser", "description": "browser based authentication", "providerId": "basic-flow", "topLevel": true, "builtIn": true, "authenticationExecutions": [ { "authenticator": "auth-cookie", "requirement": "ALTERNATIVE", "priority": 10, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "auth-spnego", "requirement": "DISABLED", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false }, { "requirement": "ALTERNATIVE", "priority": 30, "flowAlias": "forms", "userSetupAllowed": false, "autheticatorFlow": true } ] }, { "id": "e198a546-8a35-4bfd-a81a-5345fcf0deda", "alias": "clients", "description": "Base authentication for clients", "providerId": "client-flow", "topLevel": true, "builtIn": true, "authenticationExecutions": [ { "authenticator": "client-secret", "requirement": "ALTERNATIVE", "priority": 10, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "client-jwt", "requirement": "ALTERNATIVE", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false } ] }, { "id": "94e7874e-347c-4c20-80e6-951557a847d1", "alias": "direct grant", "description": "OpenID Connect Resource Owner Grant", "providerId": "basic-flow", "topLevel": true, "builtIn": true, "authenticationExecutions": [ { "authenticator": "direct-grant-validate-username", "requirement": "REQUIRED", "priority": 10, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "direct-grant-validate-password", "requirement": "REQUIRED", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "direct-grant-validate-otp", "requirement": "OPTIONAL", "priority": 30, "userSetupAllowed": false, "autheticatorFlow": false } ] }, { "id": "c362ae25-7882-4c5a-9a76-ab4ce85d82dc", "alias": "first broker login", "description": "Actions taken after first broker login with identity provider account, which is not yet linked to any Keycloak account", "providerId": "basic-flow", "topLevel": true, "builtIn": true, "authenticationExecutions": [ { "authenticatorConfig": "review profile config", "authenticator": "idp-review-profile", "requirement": "REQUIRED", "priority": 10, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticatorConfig": "create unique user config", "authenticator": "idp-create-user-if-unique", "requirement": "ALTERNATIVE", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false }, { "requirement": "ALTERNATIVE", "priority": 30, "flowAlias": "Handle Existing Account", "userSetupAllowed": false, "autheticatorFlow": true } ] }, { "id": "b84d7f61-aa46-4fa3-bf7a-16dcf1a28b25", "alias": "forms", "description": "Username, password, otp and other auth forms.", "providerId": "basic-flow", "topLevel": false, "builtIn": true, "authenticationExecutions": [ { "authenticator": "auth-username-password-form", "requirement": "REQUIRED", "priority": 10, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "auth-otp-form", "requirement": "OPTIONAL", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false } ] }, { "id": "0f2b1667-0f7c-428b-9efe-ffdb2688453c", "alias": "registration", "description": "registration flow", "providerId": "basic-flow", "topLevel": true, "builtIn": true, "authenticationExecutions": [ { "authenticator": "registration-page-form", "requirement": "REQUIRED", "priority": 10, "flowAlias": "registration form", "userSetupAllowed": false, "autheticatorFlow": true } ] }, { "id": "fdb73e02-6264-493f-a7b1-b7f8374eded9", "alias": "registration form", "description": "registration form", "providerId": "form-flow", "topLevel": false, "builtIn": true, "authenticationExecutions": [ { "authenticator": "registration-user-creation", "requirement": "REQUIRED", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "registration-profile-action", "requirement": "REQUIRED", "priority": 40, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "registration-password-action", "requirement": "REQUIRED", "priority": 50, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "registration-recaptcha-action", "requirement": "DISABLED", "priority": 60, "userSetupAllowed": false, "autheticatorFlow": false } ] }, { "id": "5b6e2c06-9c1a-4373-95dc-13f54a3d41d0", "alias": "reset credentials", "description": "Reset credentials for a user if they forgot their password or something", "providerId": "basic-flow", "topLevel": true, "builtIn": true, "authenticationExecutions": [ { "authenticator": "reset-credentials-choose-user", "requirement": "REQUIRED", "priority": 10, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "reset-credential-email", "requirement": "REQUIRED", "priority": 20, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "reset-password", "requirement": "REQUIRED", "priority": 30, "userSetupAllowed": false, "autheticatorFlow": false }, { "authenticator": "reset-otp", "requirement": "OPTIONAL", "priority": 40, "userSetupAllowed": false, "autheticatorFlow": false } ] } ], "authenticatorConfig": [ { "alias": "create unique user config", "config": { "require.password.update.after.registration": "false" } }, { "alias": "review profile config", "config": { "update.profile.on.first.login": "missing" } } ], "requiredActions": [ { "alias": "CONFIGURE_TOTP", "name": "Configure Totp", "providerId": "CONFIGURE_TOTP", "enabled": true, "defaultAction": false, "config": {} }, { "alias": "UPDATE_PASSWORD", "name": "Update Password", "providerId": "UPDATE_PASSWORD", "enabled": true, "defaultAction": false, "config": {} }, { "alias": "UPDATE_PROFILE", "name": "Update Profile", "providerId": "UPDATE_PROFILE", "enabled": true, "defaultAction": false, "config": {} }, { "alias": "VERIFY_EMAIL", "name": "Verify Email", "providerId": "VERIFY_EMAIL", "enabled": true, "defaultAction": false, "config": {} }, { "alias": "terms_and_conditions", "name": "Terms and Conditions", "providerId": "terms_and_conditions", "enabled": false, "defaultAction": false, "config": {} } ], "browserFlow": "browser", "registrationFlow": "registration", "directGrantFlow": "direct grant", "resetCredentialsFlow": "reset credentials", "clientAuthenticationFlow": "clients" } ] From chairfield at gmail.com Wed May 18 13:43:47 2016 From: chairfield at gmail.com (Chris Hairfield) Date: Wed, 18 May 2016 17:43:47 +0000 Subject: [keycloak-user] Manually Updating URL from Login Theme Message-ID: Hello Keycloak friends, I have an application with a custom login theme that shows/hides a user input to make a 2-step flow on a single page; it's done this way to reduce redrawing the page and to minimize code duplication. The problem here is that the URL doesn't change between both steps; without a URL change, the browser's back functionality doesn't know to step between the steps. Do we have any control over the URL from within our login theme? My current idea is to modify/increment the state parameter between steps, but I'm open to any suggestions. On the flip side, can we break our steps out into 2 separate pages in a way that our theme doesn't redraw between page changes? It's pretty jerky when it does so. Thanks! Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160518/ec42d30f/attachment.html From aikeaguinea at xsmail.com Wed May 18 15:20:44 2016 From: aikeaguinea at xsmail.com (Aikeaguinea) Date: Wed, 18 May 2016 15:20:44 -0400 Subject: [keycloak-user] Keycloak as ID provider for large amount of devices In-Reply-To: <34ca9eb3-484a-4271-1843-72feef558c1e@redhat.com> References: <61D077C6283D454FAFD06F6AC4AB74D723DD53F4@DEFTHW99EZ1MSX.ww931.my-it-solutions.net> <1463408938.3065960.609181441.1F1B1DC0@webmail.messagingengine.com> <260b7be4-20e7-6a9c-c9f0-4d83576d3680@redhat.com> <1463493235.3334646.610310569.147B85A0@webmail.messagingengine.com> <34ca9eb3-484a-4271-1843-72feef558c1e@redhat.com> Message-ID: <1463599244.1325934.611848617.3C43D824@webmail.messagingengine.com> Hoping to get us into production first... which is more an institutional issue than a technical one right now. On Tue, May 17, 2016, at 10:23 AM, Bill Burke wrote: > I don't know how much performance would be hurt on logout with a large > number of clients. > Sounds like you have a way to handle things.? Maybe blog about it? :) > > On 5/17/16 9:53 AM, Aikeaguinea wrote: >> Would only the logout request experience significant delay, or would >> logging out significantly slow down the entire system when there is a >> large number of clients? We can probably work with a long logout time >> per device. >> >> With regard to key rotation, we're initially planning on using the UI >> to generate new credentials when we need new keys. But couldn't we >> automate this by calling?/admin/realms/{realm}/clients/{id}/certificates/{attr}/generate-and- >> download ? >> >> On Mon, May 16, 2016, at 05:19 PM, Bill Burke wrote: >>> I think the only thing that doesn't scale very well as it pertains >>> to number of clients is logout.? Logout for OIDC requires a redirect >>> uri.? We validate this uri by iterating over every client's register >>> register uri patterns. >>> We don't have any services on key rotation.? That's all something >>> you'd have to implement yourself. >>> >>> On 5/16/16 3:37 PM, Henryk Konsek wrote: >>>> IMHO mapping device per use should be fine. KeyCloak scales well >>>> even for hundred of thousands of users, so it will handle gazillion >>>> of devices as well. >>>> >>>> Cheers! >>>> >>>> pon., 16.05.2016 o 16:29?u?ytkownik Aikeaguinea >>>> napisa?: >>>>> This is disappointing news, as when I asked this same question >>>>> back in January the answer was that the intention is to have >>>>> Keycloak scale to hundreds if not thousands of clients, and if >>>>> there were issues you'd work with us on that. >>>>> >>>>> There's more to this issue than having a custom authenticator; the >>>>> client interface allows you to click one button and generate the >>>>> jks file containing the client's private key. We would need this >>>>> not only for the first time a device is set up, but for key >>>>> rotation on an ongoing basis. >>>>> >>>>> Are there ways to plug into the user management interface to allow >>>>> generation of non-username/password credentials for a user? >>>>> >>>>> >>>>> On Fri, May 13, 2016, at 02:11 AM, Stian Thorgersen wrote: >>>>>> Hi, >>>>>> >>>>>> That's a very interesting use-case. One which we have wanted to >>>>>> look into ourselves, but haven't had the resources. Ideally I'd >>>>>> say we'd have a device concept in Keycloak as they're not >>>>>> strictly clients or users. They'd most likely be backed by users, >>>>>> but would have different screens for configuration and would have >>>>>> separate authentication flows. That would require a fair bit of >>>>>> work to add though. >>>>>> >>>>>> In the mean time I don't think clients are a good fit as Keycloak >>>>>> is not currently designed to have large amounts of clients, both >>>>>> for manageability and performance. Both of the issues can be >>>>>> overcome fairly easily, but that would require some work. >>>>>> >>>>>> The best solution in my opinion is to use users and implement >>>>>> your own custom authenticator to handle IOT devices. It's fairly >>>>>> simply to do and gives you the ability to handle authentication >>>>>> of the devices exactly how you want to. See >>>>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html >>>>>> for more details. >>>>>> >>>>>> I'd appreciate if you kept me updated on your progress as I'm >>>>>> very interested :) >>>>>> >>>>>> On 12 May 2016 at 10:29, Matuszak, Eduard >>>>>> wrote: >>>>>>> >>>>>>> Hello >>>>>>> >>>>>>> We are planning to get a lot of devices, identifyable by >>>>>>> individual certificates, into an IOT-system being designed and >>>>>>> developed at the moment. We choosed to authenticate all actors >>>>>>> (users, software components and devices as well) by OIDC-tokens >>>>>>> and (pre)decided to use Keycloak as ID provider. User and >>>>>>> software components are quite straightforward to handle with >>>>>>> Keycloak (as Keycloak users with the help of a user federation >>>>>>> provider & id brokerage and for applications as Keycloak clients >>>>>>> respectively). But I am not sure of how to represent our devices >>>>>>> (we want to support hundreds of thousands of them later on!) by >>>>>>> Keycloak means. >>>>>>> >>>>>>> It seems that we essentially have 2 possiblities to register a >>>>>>> device in Keycloak >>>>>>> * As a user >>>>>>> * As a client >>>>>>> >>>>>>> By representing devices as Keycloak clients we might take >>>>>>> advantage of the ServiceAccount (Oauth-Client Credential) flow >>>>>>> and become able to implement it via (dynamic!) registration and >>>>>>> it and seems, that we will even be able to authenticate our >>>>>>> device by their certificates by choosing "Signed Jwt" as >>>>>>> authenticator option. >>>>>>> >>>>>>> My question is, if it would be a good idea to register a very >>>>>>> big amount of devices as Keycloak clients with regards to >>>>>>> performance and manageability. In principle I would prefer a user- >>>>>>> representation (faciliting usage of user federation provider & >>>>>>> id brokerage for instance), but as far as I understood, the >>>>>>> appropriate flow would be Direct Access (ResourceOwnerPassword >>>>>>> Credentials) and here we can only deal with username/password >>>>>>> instead of certificates. >>>>>>> >>>>>>> Do you have any suggestions or hints (even the conclusion, that >>>>>>> Keycloak is not the suitable ID-provider-implementation for large- >>>>>>> scale IOT-systems)? >>>>>>> >>>>>>> Best regards, Eduard Matuszak >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> keycloak-user mailing list >>>>>>> keycloak-user at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>>>> _________________________________________________ >>>>>> keycloak-user mailing list >>>>>> keycloak-user at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>>> >>>>> -- >>>>> Aikeaguinea >>>>> aikeaguinea at xsmail.com >>>>> >>>>> >>>>> -- >>>>> http://www.fastmail.com - Access your email from home and the web >>>>> >>>>> _______________________________________________ >>>>> keycloak-user mailing list >>>>> keycloak-user at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>> -- >>>> Henryk Konsek >>>> https://linkedin.com/in/hekonsek >>>> >>>> >>>> _______________________________________________ keycloak-user >>>> mailing list keycloak-user at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>> >>> >>> _________________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> -- >> Aikeaguinea >> aikeaguinea at xsmail.com >> >> >> -- >> http://www.fastmail.com - Or how I learned to stop worrying and >> love email again >> >> >> >> _______________________________________________ keycloak-user mailing >> list keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > _________________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -- Aikeaguinea aikeaguinea at xsmail.com -- http://www.fastmail.com - The professional email service -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160518/196f113d/attachment-0001.html From sthorger at redhat.com Thu May 19 00:58:42 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 19 May 2016 06:58:42 +0200 Subject: [keycloak-user] Keycloak for Client services behind loadbalancers In-Reply-To: References: Message-ID: You need to configure the correct auth-server-url in keycloak.json for your application using keycloak.js. It should be the loadbalancer URL. On 10 May 2016 at 15:11, Subhrajyoti Moitra wrote: > Hello, > I have a client application, that will be using Keycloak for > authentication and authorization. > There are 2 instances of this application running on (lets say) service1 > and service2. > > These 2 service instance are behind the load balancer. The load balancer > has sticky sessions on. > > Now a user browses to the loadbalancer url, which in turn serves the > service instances, service1 or service2. > Now when the service instance pages are using keycloak.js to verify the > login, I dont get the loadbalancer URL as the redirect url value, rather > the redirect url is of the actual service instance URL on which the service > is hosted. > > How do i use Keycloak for loadbalanced services? > > Is there some specific setting, or setup of the server? > > Please help and guide, > Thanks and cheers, > Subhro. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160519/d0ab7949/attachment.html From sthorger at redhat.com Thu May 19 00:59:47 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 19 May 2016 06:59:47 +0200 Subject: [keycloak-user] Authorization question (maybe not keycloak?) In-Reply-To: <57330405.9040706@redhat.com> References: <379356563.1922580.1462886239492.JavaMail.yahoo.ref@mail.yahoo.com> <379356563.1922580.1462886239492.JavaMail.yahoo@mail.yahoo.com> <5732E410.4090007@redhat.com> <205ab086-6407-f7ae-7dfd-5c805b1e40f5@akvo.org> <57330405.9040706@redhat.com> Message-ID: The PR will be merged in a week or so and will be included in 2.0.0.CR1 due to be released in June. On 11 May 2016 at 12:05, Marek Posolda wrote: > Hi Ivan, > > the PR and issue is inactive just because we are mainly focused on > polishing/testing of 1.9.x instead of new features for 2.0.x. I guess it > will be merged within few months (or even earlier) and hopefully > available in 2.0.0.CR1. > > Marek > > On 11/05/16 11:31, Iv?n Perdomo wrote: > > Hi Marek, > > > > On 05/11/2016 09:49 AM, Marek Posolda wrote: > >> We plan to add support for authorization. The prototype and instructions > >> to try it are here [1] . > > Do you know if this work is still targeting 2.0.0RC1? I've not seen > > activity in the pull request [1] or issue [2] > > > > [1] https://github.com/keycloak/keycloak/pull/2617 > > [2] https://issues.jboss.org/browse/KEYCLOAK-2753 > > > > Thanks, > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160519/a87aeab9/attachment.html From sthorger at redhat.com Thu May 19 01:01:27 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 19 May 2016 07:01:27 +0200 Subject: [keycloak-user] Validating JWT tokens In-Reply-To: References: <1462377616.1947384.598056425.5C00B82A@webmail.messagingengine.com> <1462379847.1956071.598104761.4A24EAC6@webmail.messagingengine.com> <4AC8C602867B3A4CB6F9F6BA4528DEE477CD682C@WPHXMAIL1.phx.axway.int> Message-ID: You can also use https://github.com/keycloak/keycloak/blob/master/core/src/main/java/org/keycloak/RSATokenVerifier.java On 11 May 2016 at 15:50, Josh Cain wrote: > I recently put together a quick test for this as well using jjwt: > https://github.com/cainj13/jwtExamples/blob/master/src/test/java/jcain/example/TokenParseTest.java > > Pretty similar to the gist that Thomas mentioned above. > > Josh Cain | Software Applications Engineer > *Identity and Access Management* > *Red Hat* > +1 843-737-1735 > > On Wed, May 11, 2016 at 4:09 AM, Thomas Darimont < > thomas.darimont at googlemail.com> wrote: > >> Hello, >> >> another example for (Parsing) & Validating a Keycloak JWT was posted on >> the ML a few months ago: >> http://lists.jboss.org/pipermail/keycloak-user/2016-March/005325.html >> >> In the example the token is only successfully parsed when the token is >> valid. >> >> Cheers, >> Thomas >> >> 2016-05-11 10:45 GMT+02:00 Gerard Laissard : >> >>> >>> >>> My 2 cents: >>> >>> There is an openSSL example to verify a jwt: >>> >>> https://gist.github.com/rolandyoung/176dd310a6948e094be6 >>> >>> >>> >>> By using jose4j >>> >>> // be sure you do not have any EOL at the end of the token >>> >>> String accesToken = ?; >>> >>> accesToken = accesToken.replaceAll("\r\n", ""); >>> >>> accesToken = accesToken.replaceAll("\n", ""); >>> >>> >>> >>> JsonWebSignature jws = *new* JsonWebSignature(); >>> >>> jws.setCompactSerialization(accesToken); >>> >>> jws.setKey(publicKey); >>> >>> boolean signatureVerified = jws.verifySignature(); >>> >>> To get a PublicKey : if you put the content of the realm public you get >>> from keycloak admin >>> >>> *public* PublicKey getPublicKey(String fileName) { >>> >>> File f = *new* File(fileName); >>> >>> *try* (FileInputStream fis = *new* FileInputStream(f); >>> >>> DataInputStream dis = *new* DataInputStream(fis);) { >>> >>> *byte*[] keyBytes = *new* *byte*[(*int*) f.length()]; >>> >>> dis.readFully(keyBytes); >>> >>> dis.close(); >>> >>> // convert to der format >>> >>> String pem = new String(keyBytes); >>> >>> pem = pem.replaceAll("-----BEGIN (.*)-----", ""); >>> >>> pem = pem.replaceAll("-----END (.*)----", ""); >>> >>> pem = pem.replaceAll("\r\n", ""); >>> >>> pem = pem.replaceAll("\n", ""); >>> >>> byte[] der = Base64.getDecoder().decode(pem); // java 8 >>> >>> X509EncodedKeySpec spec = *new* X509EncodedKeySpec(der); >>> >>> KeyFactory kf = KeyFactory.*getInstance*(*RSA*); >>> >>> *return* kf.generatePublic(spec); >>> >>> >>> >>> } *catch* (IOException | InvalidKeySpecException | >>> NoSuchAlgorithmException e) { >>> >>> *throw* *new* RuntimeException("Failed to load public >>> key from file '" + fileName + "'", e); >>> >>> } >>> >>> } >>> >>> >>> >>> With Java 8, it is quite simple too >>> >>> String[] tokenParts = accessToken.split("\\."); >>> >>> // detect algo from tokenParts[0] or put "SHA256withRSA? (for ?RS256?) >>> >>> String jwtSignAlgo = "SHA256withRSA"; >>> >>> String jwtInputString = tokenParts[0] + ?.? + tokenParts[1]; >>> >>> String jwtDecodedSign = new >>> String(Base64.getUrlDecoder().decode(tokenParts[2]); >>> >>> Signature verifier = Signature.getInstance(jwtSignAlgo); >>> >>> verifier.initVerify(publicKey); >>> >>> verifier.update(jwtInputString.getBytes("UTF-8")); >>> >>> boolean signatureVerified = verifier.verify(jwtDecodedSign); >>> >>> >>> >>> >>> >>> gerard >>> >>> >>> >>> >>> >>> *From:* keycloak-user-bounces at lists.jboss.org [mailto: >>> keycloak-user-bounces at lists.jboss.org] *On Behalf Of *Stian Thorgersen >>> *Sent:* vendredi 6 mai 2016 07:33 >>> *To:* Aikeaguinea >>> *Cc:* keycloak-user >>> *Subject:* Re: [keycloak-user] Validating JWT tokens >>> >>> >>> >>> >>> >>> >>> >>> On 4 May 2016 at 18:37, Aikeaguinea wrote: >>> >>> Figured it out, kinda. I have to use the Realm public key, and at least >>> in jwt.io it has to begin with "-----BEGIN PUBLIC KEY-----" and end with >>> "-----END PUBLIC KEY-----" -- these can't be omitted. >>> >>> If I try using the Realm certificate, it won't work, however, whether or >>> not I use "-----BEGIN CERTIFICATE-----"/"-----END CERTIFICATE-----". >>> >>> If I use the validator at http://kjur.github.io/jsjws/tool_jwt.html and >>> select "default X509 Certificate (RSA z4) it tells me "Error: malformed >>> X.509 certificate PEM (code:003)" >>> >>> I can use the Realm public key for validating the JWT, but shouldn't the >>> certificate work as well? >>> >>> >>> >>> The certificate is only used by SAML, so no you can't verify the JWT >>> with the certificate only the public key. >>> >>> >>> >>> >>> On Wed, May 4, 2016, at 12:00 PM, Aikeaguinea wrote: >>> > I have a client with a service account and credentials using Signed >>> Jwt. >>> > Authentication works fine. The service uses >>> > >>> org.keycloak.adapters.authentication.ClientCredentialsProviderUtils#setClientCredentials >>> > to create the JWT token and set the headers, and I get back a JWT >>> > containing an access token from Keycloak. >>> > >>> > However, when I use jwt.io to look at the access token, I can't >>> validate >>> > the signature. This is true whether I use the client Certificate (from >>> > the client's Credentials tab), the Realm public key, or the Realm >>> > Certificate. In addition, I have generated the client's public key from >>> > the certificate using >>> > >>> > keytool -exportcert -alias x -keypass y -storepass z -rfc -keystore >>> > client-keystore.jks | openssl x509 -inform pem -pubkey >>> > >>> > on the jks file supplied when I generated the client credentials, and >>> > that doesn't work either. >>> > >>> > We've also been having trouble validating the signature >>> programmatically >>> > using Java. >>> > >>> > Any idea why I might be seeing this? >>> > >>> > -- >>> > http://www.fastmail.com - Or how I learned to stop worrying and >>> > love email again >>> > >>> >>> >>> -- >>> Aikeaguinea >>> aikeaguinea at xsmail.com >>> >>> -- >>> http://www.fastmail.com - Send your email first class >>> >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >>> >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160519/41a38889/attachment-0001.html From sthorger at redhat.com Thu May 19 01:02:11 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 19 May 2016 07:02:11 +0200 Subject: [keycloak-user] Unique username across realms? In-Reply-To: References: Message-ID: No, that's not possible. If you are using a relational database you could add a unique constraint yourself though. On 11 May 2016 at 16:46, Guus der Kinderen wrote: > Hi all, > > Is it possible to have multiple realms, in which every username is unique > across all of the realms? > > Regards, > > Guus > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160519/d32426bf/attachment.html From sthorger at redhat.com Thu May 19 01:03:07 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 19 May 2016 07:03:07 +0200 Subject: [keycloak-user] Impersonate In-Reply-To: References: Message-ID: Currently the impersonation feature is only available through the admin console, but you could relatively easily figure out the calls it makes and call them from your own application instead. On 11 May 2016 at 16:50, Daniele Bonetto wrote: > Hi all, > > > i've a question about impersonation. > > > As wrote before, we need to allow our operators to impersonate final users. > > We need call impersonate API from our backoffice. > > I searched in keycloak.js some function that does the magic, but nothing. > > > How can we manage it? We didn't want that our operators have to access > to keycloak admin-interface to impersonate users. > > > Thanks in advance, > > regards. > > Daniele Bonetto > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160519/451fb7f8/attachment.html From sthorger at redhat.com Thu May 19 01:04:50 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 19 May 2016 07:04:50 +0200 Subject: [keycloak-user] custom role description not showing up on consent screen In-Reply-To: References: Message-ID: By "link to start the openid connect authorization code flow" do you mean the scope query param? We don't support that yet. You need to configure the scope for the client through the admin console. For it to show up on the consent screen the user has to have a role mapping on the role and the client has to have a scope (through admin console) or full scope. On 11 May 2016 at 22:36, Brian Cook wrote: > > I created a new role at the client level and in my link to start the > openid connect authorization code flow it is being pased in. I get the > login screen and login successfully, but when the consent screen shows up > there is no mention of this scope or its description. Is there something > additional I need to do? > > Thanks, > Brian > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160519/ffaab887/attachment.html From sthorger at redhat.com Thu May 19 01:09:25 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 19 May 2016 07:09:25 +0200 Subject: [keycloak-user] Keycloak 1.9.4 custom authenticator reference In-Reply-To: References: Message-ID: On 12 May 2016 at 16:29, Tech @ PSYND wrote: > Dear experts, > > I'm working with keycloak 1.9.4. > > We ran some customization with the Authenticators: we implemented a > couple of authenticators in sequence, like provide an OTP token, provide > an additional information etc. > > We are facing several issues: > 1) we create our custom Flow from the Authentication interface > 2) we add our 4 form (Add Execution) > 3) from the Flows Module we select the order in which they should be > selected > 4) we define in the binding sour flow as Browser Flow > 5) we register and enable our executions from the Required Actions > module. > > > About point 3): even if we change the order of the flows using the > priorities arrows, the forms doesn't show up in order. > > We tried to delete and to re-create, but we don't understand if we > should do something else to impose the order we need. > The arrows should change the order > > After creation, we decided to remove each single "Execution" and then > remove the flow. > > We set again the "Browser Flow" to the standard "Browser", we removed > the created jars from the provider/ directory, but every time that we > try to authenticate we get an error saying that there is still an > existing reference to the old deployment, although the provider/ > directory is currently empty. > > > > > 16:00:40,199 ERROR [io.undertow.request] (default task-4) UT005023: > Exception handling request to > /auth/realms/etatvs/login-actions/required-action: > org.jboss.resteasy.spi.UnhandledException: java.lang.RuntimeException: > Unable to find factory for Required Action: renew_password_config did > you forget to declare it in a META-INF/services file? > at > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) > at > > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) > at > > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at > > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) > at > io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > at > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) > Caused by: java.lang.RuntimeException: Unable to find factory for > Required Action: renew_password_config did you forget to declare it in a > META-INF/services file? > at > > org.keycloak.services.managers.AuthenticationManager.executionActions(AuthenticationManager.java:569) > at > > org.keycloak.services.managers.AuthenticationManager.actionRequired(AuthenticationManager.java:504) > at > > org.keycloak.services.managers.AuthenticationManager.nextActionAfterAuthentication(AuthenticationManager.java:426) > at > > org.keycloak.services.resources.LoginActionsService$Checks.verifyRequiredAction(LoginActionsService.java:302) > at > > org.keycloak.services.resources.LoginActionsService.processRequireAction(LoginActionsService.java:856) > That's a required action that's missing "renew_password_config". Maybe a user that has had the action associated with it? Try checking the user through the admin console and see what required actions it has? Or maybe you've configured required actions as well as authenticators? > > > > Could you support? > > Thanks > > > > > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160519/ef313549/attachment.html From subhrajyotim at gmail.com Thu May 19 01:30:39 2016 From: subhrajyotim at gmail.com (Subhrajyoti Moitra) Date: Thu, 19 May 2016 11:00:39 +0530 Subject: [keycloak-user] Keycloak for Client services behind loadbalancers In-Reply-To: References: Message-ID: Hello Stian, Thanks for responding. Our Keycloak SSO is a single server, but the clients are load balanced. We just set the redirect_url value to the LB url in the keycloak.login() call, thats it. It seems to be working without any issues, detected so far. :) Thanks a lot again for looking into this. Regards, Subhro. On Thu, May 19, 2016 at 10:28 AM, Stian Thorgersen wrote: > You need to configure the correct auth-server-url in keycloak.json for > your application using keycloak.js. It should be the loadbalancer URL. > > On 10 May 2016 at 15:11, Subhrajyoti Moitra > wrote: > >> Hello, >> I have a client application, that will be using Keycloak for >> authentication and authorization. >> There are 2 instances of this application running on (lets say) service1 >> and service2. >> >> These 2 service instance are behind the load balancer. The load balancer >> has sticky sessions on. >> >> Now a user browses to the loadbalancer url, which in turn serves the >> service instances, service1 or service2. >> Now when the service instance pages are using keycloak.js to verify the >> login, I dont get the loadbalancer URL as the redirect url value, rather >> the redirect url is of the actual service instance URL on which the service >> is hosted. >> >> How do i use Keycloak for loadbalanced services? >> >> Is there some specific setting, or setup of the server? >> >> Please help and guide, >> Thanks and cheers, >> Subhro. >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160519/0d0c4bb8/attachment-0001.html From tech at psynd.net Thu May 19 02:01:14 2016 From: tech at psynd.net (Tech @ PSYND) Date: Thu, 19 May 2016 08:01:14 +0200 Subject: [keycloak-user] Keycloak 1.9.4 custom authenticator reference In-Reply-To: References: Message-ID: <82aa6bf978c93c41749aee956ff0a151@psynd.net> Hello Stian, About the Java error appearing, I saw that keycloak is keeping still some "no existing" dependencies, I had to re-deploy part of the code, complete some workflows and after removing again the code, everything was working. What I'm worried about is I re-deployed again the authenticator in a brand new keycloak, and the fact that I'm unable to change the order of the flows using the arrows is surprising me. I think today that this could be a bug of the product, I cannot find any other explaination in this case. May I send you the code to let you verify yourself what is happening? I've the feeling that keycloak is writing the wrong order of execution of flows in the database, but I'm not able to debug it. Thanks! On 2016-05-19 07:09, Stian Thorgersen wrote: > On 12 May 2016 at 16:29, Tech @ PSYND wrote: > >> Dear experts, >> >> I'm working with keycloak 1.9.4. >> >> We ran some customization with the Authenticators: we implemented a >> couple of authenticators in sequence, like provide an OTP token, >> provide >> an additional information etc. >> >> We are facing several issues: >> 1) we create our custom Flow from the Authentication interface >> 2) we add our 4 form (Add Execution) >> 3) from the Flows Module we select the order in which they should >> be >> selected >> 4) we define in the binding sour flow as Browser Flow >> 5) we register and enable our executions from the Required Actions >> module. >> >> About point 3): even if we change the order of the flows using the >> priorities arrows, the forms doesn't show up in order. >> >> We tried to delete and to re-create, but we don't understand if we >> should do something else to impose the order we need. > > The arrows should change the order > >> After creation, we decided to remove each single "Execution" and >> then >> remove the flow. >> >> We set again the "Browser Flow" to the standard "Browser", we >> removed >> the created jars from the provider/ directory, but every time that >> we >> try to authenticate we get an error saying that there is still an >> existing reference to the old deployment, although the provider/ >> directory is currently empty. >> >> 16:00:40,199 ERROR [io.undertow.request] (default task-4) UT005023: >> Exception handling request to >> /auth/realms/etatvs/login-actions/required-action: >> org.jboss.resteasy.spi.UnhandledException: >> java.lang.RuntimeException: >> Unable to find factory for Required Action: renew_password_config >> did >> you forget to declare it in a META-INF/services file? >> at >> > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at >> > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) >> at >> > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) >> at >> > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) >> at >> > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) >> at >> > io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) >> at >> > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) >> Caused by: java.lang.RuntimeException: Unable to find factory for >> Required Action: renew_password_config did you forget to declare it >> in a >> META-INF/services file? >> at >> > org.keycloak.services.managers.AuthenticationManager.executionActions(AuthenticationManager.java:569) >> at >> > org.keycloak.services.managers.AuthenticationManager.actionRequired(AuthenticationManager.java:504) >> at >> > org.keycloak.services.managers.AuthenticationManager.nextActionAfterAuthentication(AuthenticationManager.java:426) >> at >> > org.keycloak.services.resources.LoginActionsService$Checks.verifyRequiredAction(LoginActionsService.java:302) >> at >> > org.keycloak.services.resources.LoginActionsService.processRequireAction(LoginActionsService.java:856) > > That's a required action that's missing "renew_password_config". Maybe > a user that has had the action associated with it? Try checking the > user through the admin console and see what required actions it has? > Or maybe you've configured required actions as well as authenticators? > >> Could you support? >> >> Thanks >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user [1] > > > > Links: > ------ > [1] https://lists.jboss.org/mailman/listinfo/keycloak-user From sthorger at redhat.com Thu May 19 02:19:50 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 19 May 2016 08:19:50 +0200 Subject: [keycloak-user] Keycloak for Client services behind loadbalancers In-Reply-To: References: Message-ID: Why are you not changing the config in keycloak.json? The way you do it now you may end up with a different URL used to exchange code->token and to refresh tokens. On 19 May 2016 at 07:30, Subhrajyoti Moitra wrote: > Hello Stian, > Thanks for responding. > Our Keycloak SSO is a single server, but the clients are load balanced. > We just set the redirect_url value to the LB url in the keycloak.login() > call, thats it. > It seems to be working without any issues, detected so far. > :) > > Thanks a lot again for looking into this. > Regards, > Subhro. > > > > On Thu, May 19, 2016 at 10:28 AM, Stian Thorgersen > wrote: > >> You need to configure the correct auth-server-url in keycloak.json for >> your application using keycloak.js. It should be the loadbalancer URL. >> >> On 10 May 2016 at 15:11, Subhrajyoti Moitra >> wrote: >> >>> Hello, >>> I have a client application, that will be using Keycloak for >>> authentication and authorization. >>> There are 2 instances of this application running on (lets say) service1 >>> and service2. >>> >>> These 2 service instance are behind the load balancer. The load balancer >>> has sticky sessions on. >>> >>> Now a user browses to the loadbalancer url, which in turn serves the >>> service instances, service1 or service2. >>> Now when the service instance pages are using keycloak.js to verify the >>> login, I dont get the loadbalancer URL as the redirect url value, rather >>> the redirect url is of the actual service instance URL on which the service >>> is hosted. >>> >>> How do i use Keycloak for loadbalanced services? >>> >>> Is there some specific setting, or setup of the server? >>> >>> Please help and guide, >>> Thanks and cheers, >>> Subhro. >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160519/85a31262/attachment.html From sthorger at redhat.com Thu May 19 02:20:12 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 19 May 2016 08:20:12 +0200 Subject: [keycloak-user] Keycloak for Client services behind loadbalancers In-Reply-To: References: Message-ID: Sorry, I miss-read that. You're changing the URL for the client, not Keycloak server. Sorry. On 19 May 2016 at 08:19, Stian Thorgersen wrote: > Why are you not changing the config in keycloak.json? The way you do it > now you may end up with a different URL used to exchange code->token and to > refresh tokens. > > On 19 May 2016 at 07:30, Subhrajyoti Moitra > wrote: > >> Hello Stian, >> Thanks for responding. >> Our Keycloak SSO is a single server, but the clients are load balanced. >> We just set the redirect_url value to the LB url in the keycloak.login() >> call, thats it. >> It seems to be working without any issues, detected so far. >> :) >> >> Thanks a lot again for looking into this. >> Regards, >> Subhro. >> >> >> >> On Thu, May 19, 2016 at 10:28 AM, Stian Thorgersen >> wrote: >> >>> You need to configure the correct auth-server-url in keycloak.json for >>> your application using keycloak.js. It should be the loadbalancer URL. >>> >>> On 10 May 2016 at 15:11, Subhrajyoti Moitra >>> wrote: >>> >>>> Hello, >>>> I have a client application, that will be using Keycloak for >>>> authentication and authorization. >>>> There are 2 instances of this application running on (lets say) >>>> service1 and service2. >>>> >>>> These 2 service instance are behind the load balancer. The load >>>> balancer has sticky sessions on. >>>> >>>> Now a user browses to the loadbalancer url, which in turn serves the >>>> service instances, service1 or service2. >>>> Now when the service instance pages are using keycloak.js to verify the >>>> login, I dont get the loadbalancer URL as the redirect url value, rather >>>> the redirect url is of the actual service instance URL on which the service >>>> is hosted. >>>> >>>> How do i use Keycloak for loadbalanced services? >>>> >>>> Is there some specific setting, or setup of the server? >>>> >>>> Please help and guide, >>>> Thanks and cheers, >>>> Subhro. >>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160519/edca495a/attachment.html From sthorger at redhat.com Thu May 19 02:25:57 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 19 May 2016 08:25:57 +0200 Subject: [keycloak-user] Captive Portal with Keycloak for Wireless Routers In-Reply-To: References: Message-ID: I've got no clue how to setup a captive portal for a wireless network, but I would imagine you'd need to create a web application that delegates authentication to Keycloak rather than making Keycloak itself the captive portal page. On 14 May 2016 at 22:56, Daniel Fuchs wrote: > Hi, > > > > I?m starting to read about Keycloak and it?s functionalities and I?m > wondering how can we make it act as the Captive Portal for our Wireless > Network? > > > > Since the users will have different services with a customer, Keycloak > seems perfect because we can authenticate multiple applications with > multiple identity providers aside of having internal registered customers, > but one of these services will be the network access. > > > > Maybe Keycloak can become a central point in my architecture. > > > > Thanks in advance, > > > > Daniel > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160519/04e52d12/attachment.html From sthorger at redhat.com Thu May 19 03:03:39 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 19 May 2016 09:03:39 +0200 Subject: [keycloak-user] How to secure REST APIs with KeyCloak In-Reply-To: References: Message-ID: One option is to allow users to login through the script itself. Take a look at our customer-app-cli in the examples. It has two options one is to show the user a login that the user then opens and copy/pastes the code back to the application, the other is it opens it in a browser and can the script can then read the token directly itself. You can combine this with changing the SSO idle/max configuration for the realm to determine how often a user needs to re-authenticate. You can also combine it with offline token as well if you want the scripts to remain permanently authenticated. Using direct access grants works as well. Rather than adding username/password to the script you should have the script request the username/password, then the script stores the token, not password. Same as above you'd configure SSO idle/max to determine how often users need to re-authenticate, or you can use offline here as well. You're right that this won't support identity brokering, that's only available for the web flow. On 15 May 2016 at 20:59, Moshe Ben-Shoham wrote: > Hi, > > I?m trying to figure out the best way to secure REST APIs with KeyCloak. > The REST APIs are to be invoked by unattended batch processes that are not > KeyCloak clients but end-user scripts. I imagine a process in which the > user generates a token using some web app and then uses this token in his > scripts in order to authenticate when invoking the REST APIs. > > So far I have found 2 options, but none of them seems like a very good > option: > > (1) Use offline tokens ? according to the docs, offline token are to be > used by KeyCloak clients that need to do things on behalf of the user. In > my case, it is the end-user that needs the token and not a client. Should I > build a dedicated client that will create the offline tokens and give them > to the end-user to use? Is this a misuse for offline tokens? > > (2) Use Direct Access Grants ? seems like in this option, at least in its > simplest form, the user needs to pass username and password to get a token. > This means users need to keep their password in their scripts (or scripts > configuration) and it is bad practice. In addition, what happens when > KeyCloak is configured to be an Identity Broker? In this case KeyCloak does > not even know how to handle the user/password. > > Any help is appreciated! > The information contained in this message is proprietary to the sender, > protected from disclosure, and may be privileged. The information is > intended to be conveyed only to the designated recipient(s) of the message. > If the reader of this message is not the intended recipient, you are hereby > notified that any dissemination, use, distribution or copying of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. Thank you. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160519/b93478c2/attachment-0001.html From cmoullia at redhat.com Thu May 19 03:18:50 2016 From: cmoullia at redhat.com (Charles Moulliard) Date: Thu, 19 May 2016 09:18:50 +0200 Subject: [keycloak-user] Integrate Keycloak 1.9.4 with Openshift Origin Message-ID: Hi, According to Openshift Doc ( https://docs.openshift.com/enterprise/3.0/admin_guide/configuring_authentication.html#OpenID) and this blog article ( http://blog.keycloak.org/2015/06/openshift-ui-console-authentication.html), we can integrate Keycloak as IdentiyProvider with Openshift. So, I have configured the master-config.yaml to use Keycloak 1.9.4.Final as Identity Provider. See hereafter the config oauthConfig: > > alwaysShowProviderSelection: false > > assetPublicURL: https://192.168.99.100:8443/console/ > > grantConfig: > > method: auto > > identityProviders: > > - challenge: true > > login: true > > name: keycloak > > provider: > > apiVersion: v1 > > kind: OpenIDIdentityProvider > > ca: keycloak-ca.cert > > clientID: openshift > > clientSecret: fbde8b27-3342-4494-b3a3-7db645e9dfe5 > > claims: > > id: > > - sub > > preferredUsername: > > - preferred_username > > name: > > - name > > email: > > - email > > urls: > > authorize: >> https://192.168.1.80:8443/auth/realms/openshift/tokens/login > > token: >> https://192.168.1.80:8443/auth/realms/openshift/tokens/access/codes > > But, when I try to log on to the Openshift console, I'm redirected to Keycloak Server which returns this Error 404 --> GET https://192.168.1.80:8443/auth/realms/openshift/tokens/login?client_id=open?YlMjUyRjE5Mi4xNjguOTkuMTAwJTI1M0E4NDQzJTI1MkZjb25zb2xlJTI1MkZvYXV0aA%3D%3D 404 (Not Found) According to this thread ( http://stackoverflow.com/questions/28658735/what-are-keycloaks-oauth2-openid-connect-endpoints ), the urls to be used are these authorize: https://192.168.1.80:8443/auth/realms/openshift/protocol/openid-connect/auth token: https://192.168.1.80:8443/auth/realms/openshift/protocol/openid-connect/token FYI, I can get a token --> curl -k -s -X POST > https://192.168.1.80:8443/auth/realms/openshift/protocol/openid-connect/token -H > "Content-Type: application/x-www-form-urlencoded" -d 'username=test-user' > -d 'password=password' -d 'grant_type=password' -d 'client_id=openshift' -d > 'client_secret=fbde8b27-3342-4494-b3a3-7db645e9dfe5' | jq -r '.access_token' > eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI1ODExNGExZi1mMTQwLTQwYTctODAwOS1hNGU2 Can you confirm that the correct urls to be used are ? authorize: https://192.168.1.80:8443/auth/realms/openshift/protocol/openid-connect/auth token: https://192.168.1.80:8443/auth/realms/openshift/protocol/openid-connect/token Regards, Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160519/0f7641ef/attachment.html From shivasaxena999 at gmail.com Thu May 19 05:23:15 2016 From: shivasaxena999 at gmail.com (Shiva Saxena) Date: Thu, 19 May 2016 14:53:15 +0530 Subject: [keycloak-user] Multi Tenancy support using Jetty 8.1 adapter Message-ID: Hi, Is is possible to support multi-tenancy using the jetty 8.1 adapter? Like by using PathBasedKeycloakConfigResolver or similar. Has anyone tried any such case? Thanks! -- Best Regards *Shiva Saxena* *Blog | Linkedin | StackOverflow * -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160519/e26ec985/attachment.html From sthorger at redhat.com Thu May 19 05:25:27 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 19 May 2016 11:25:27 +0200 Subject: [keycloak-user] Email format In-Reply-To: References: Message-ID: Email are sent as multi-part emails so both text and html is included. This is not configurable at the moment. You can include custom fields, but you'd need to edit the template as well as the message bundle. The full user is available as "user", first name is "user.firstName". On 16 May 2016 at 18:55, Bruno Palermo wrote: > Hi, > > How can I choose between text and html for the e-mail messages? > > Also is possible to include some custom fields on the template, such as > user first name? > > Thanks, > Bruno > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160519/d88dc415/attachment-0001.html From vaibhav_naldurgkar at persistent.com Thu May 19 07:24:36 2016 From: vaibhav_naldurgkar at persistent.com (Vaibhav Naldurgkar) Date: Thu, 19 May 2016 11:24:36 +0000 Subject: [keycloak-user] Keycloak OAuth High CPU usage Message-ID: Hi All, I am using Keycloak 1.9.3 with default configuration. Keycloak server is installed on RHEL 6.5 virtual image with 4 CPU , 8 GB RAM and java version is jdk1.8.0_73 We are trying to use keycloak as a OAuth provider. But when we try and generate token(http:///auth/realms/master/protocol/openid-connect/token) for more than 10-20 users the server gets too slow and cpu usage goes over 100%. Any pointers on how to improve performance of keycloak OAuth provider. We need to support at least 200 concurrent users. Thanks, Vaibhav DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160519/aa472f94/attachment.html From Vincent.Sluijter at crv4all.com Thu May 19 07:30:32 2016 From: Vincent.Sluijter at crv4all.com (Vincent Sluijter) Date: Thu, 19 May 2016 11:30:32 +0000 Subject: [keycloak-user] LazyInitializationException on Partial import Message-ID: During a partial import and selecting OVERWRITE , Keycloak throws the following error: UT005023: Exception handling request to /auth/admin/realms/test/partialImport: org.jboss.resteasy.spi.UnhandledException: org.hibernate.LazyInitializationException: failed to lazily initialize a collection, could not initialize proxy - no Session Is this feature broken in keycloak 1.9.1.FINAL? I'm trying to change a parameter in an identity provider? Is this possible through this method? I also get the error when I try to import the full identity provider, for which the partial import works when It does not exists. This message is subject to the following E-mail Disclaimer. (http://www.crv4all.com/disclaimer-email/) CRV Holding B.V. seats according to the articles of association in Arnhem, Dutch trade number 09125050. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160519/1ee04ecb/attachment.html From leo.nunes at gjccorp.com.br Thu May 19 08:04:00 2016 From: leo.nunes at gjccorp.com.br (LEONARDO NUNES) Date: Thu, 19 May 2016 12:04:00 +0000 Subject: [keycloak-user] Version 2.0.0.CR1 Message-ID: Hi, when version 2.0.0.CR1 will be released? -- Leonardo ________________________________ Esta mensagem pode conter informa??o confidencial e/ou privilegiada. Se voc? n?o for o destinat?rio ou a pessoa autorizada a receber esta mensagem, n?o poder? usar, copiar ou divulgar as informa??es nela contidas ou tomar qualquer a??o baseada nessas informa??es. Se voc? recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua coopera??o. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160519/bdcbfd2a/attachment.html From guus.der.kinderen at gmail.com Thu May 19 08:18:12 2016 From: guus.der.kinderen at gmail.com (Guus der Kinderen) Date: Thu, 19 May 2016 14:18:12 +0200 Subject: [keycloak-user] Downloads archive ordering Message-ID: If reversing the order on the download archive page ( http://keycloak.jboss.org/downloads-archive.html) is a trivial task, I'd be happy to see that occur. Most users are interested in the most recently released stuff. For brownie points: add a link to the changelog? Regards, Guus -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160519/bc165f79/attachment-0001.html From sthorger at redhat.com Thu May 19 08:31:22 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 19 May 2016 14:31:22 +0200 Subject: [keycloak-user] Downloads archive ordering In-Reply-To: References: Message-ID: We're completely revamping our website soon(ish) and I'll make sure most recent is on the top On 19 May 2016 at 14:18, Guus der Kinderen wrote: > If reversing the order on the download archive page ( > http://keycloak.jboss.org/downloads-archive.html) is a trivial task, I'd > be happy to see that occur. Most users are interested in the most recently > released stuff. > > For brownie points: add a link to the changelog? > > Regards, > > Guus > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160519/98ba5910/attachment.html From sthorger at redhat.com Thu May 19 08:52:36 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 19 May 2016 14:52:36 +0200 Subject: [keycloak-user] Version 2.0.0.CR1 In-Reply-To: References: Message-ID: Mid-end of June 2016-05-19 14:04 GMT+02:00 LEONARDO NUNES : > Hi, when version 2.0.0.CR1 will be released? > > > -- > Leonardo > ------------------------------ > > > *Esta mensagem pode conter informa??o confidencial e/ou privilegiada. Se > voc? n?o for o destinat?rio ou a pessoa autorizada a receber esta mensagem, > n?o poder? usar, copiar ou divulgar as informa??es nela contidas ou tomar > qualquer a??o baseada nessas informa??es. Se voc? recebeu esta mensagem por > engano, por favor avise imediatamente o remetente, respondendo o e-mail e > em seguida apague-o. Agradecemos sua coopera??o. This message may contain > confidential and/or privileged information. If you are not the addressee or > authorized to receive this for the addressee, you must not use, copy, > disclose or take any action based on this message or any information > herein. If you have received this message in error, please advise the > sender immediately by reply e-mail and delete this message. Thank you for > your cooperation* > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160519/c9eaf41c/attachment.html From sthorger at redhat.com Thu May 19 08:57:50 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 19 May 2016 14:57:50 +0200 Subject: [keycloak-user] Keycloak OAuth High CPU usage In-Reply-To: References: Message-ID: Creating tokes are expected to be a bit CPU intensive as they need to be signed. When you say you try to generate tokens for 10-20 users are you doing performance tests and having 10-20 threads generating tokens? It shouldn't make any difference if you have 10 or if you have 200 users, it's the total number of tokens that can be generated that's an issue. Having 200 concurrent users with a access token timeout of 60 seconds should mean that you need to be able to generate roughly 200/60 tokens = 3.3 tokens/sec. On 19 May 2016 at 13:24, Vaibhav Naldurgkar < vaibhav_naldurgkar at persistent.com> wrote: > Hi All, > > > > I am using Keycloak 1.9.3 with default configuration. Keycloak server is > installed on RHEL 6.5 virtual image with 4 CPU , 8 GB RAM and java version > is jdk1.8.0_73 We are trying to use keycloak as a OAuth provider. But when > we try and generate token(http:///auth/realms/master/protocol/openid-connect/token) > for more than 10-20 users the server gets too slow and cpu usage goes over > 100%. > > Any pointers on how to improve performance of keycloak OAuth provider. We > need to support at least 200 concurrent users. > > > > > > Thanks, Vaibhav > > DISCLAIMER ========== This e-mail may contain privileged and confidential > information which is the property of Persistent Systems Ltd. It is intended > only for the use of the individual or entity to which it is addressed. If > you are not the intended recipient, you are not authorized to read, retain, > copy, print, distribute or use this message. If you have received this > communication in error, please notify the sender and delete all copies of > this message. Persistent Systems Ltd. does not accept any liability for > virus infected mails. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160519/8b218424/attachment.html From bburke at redhat.com Thu May 19 09:10:16 2016 From: bburke at redhat.com (Bill Burke) Date: Thu, 19 May 2016 09:10:16 -0400 Subject: [keycloak-user] Keycloak OAuth High CPU usage In-Reply-To: References: Message-ID: <6a4ed026-f1f1-5b5f-e965-201c24b3f284@redhat.com> Are you benching this with the same user? Or are there 10-20 different users executing at the same time? I ask because if they are different you have to factor in database access. I think the default connection pool size for the DB is 20 connections. Other things that could factor in: what are you password hashing iterations (its a password policy). Default is 1, but I don't know if you've bumped that to the recommended amount (20,000) which would greatly slow things down too. On 5/19/16 7:24 AM, Vaibhav Naldurgkar wrote: > > Hi All, > > I am using Keycloak 1.9.3 with default configuration. Keycloak server > is installed on RHEL 6.5 virtual image with 4 CPU , 8 GB RAM and java > version is jdk1.8.0_73 We are trying to use keycloak as a OAuth > provider. But when we try and generate > token(http:///auth/realms/master/protocol/openid-connect/token) for > more than 10-20 users the server gets too slow and cpu usage goes over > 100%. > > Any pointers on how to improve performance of keycloak OAuth provider. > We need to support at least 200 concurrent users. > > Thanks, Vaibhav > > DISCLAIMER ========== This e-mail may contain privileged and > confidential information which is the property of Persistent Systems > Ltd. It is intended only for the use of the individual or entity to > which it is addressed. If you are not the intended recipient, you are > not authorized to read, retain, copy, print, distribute or use this > message. If you have received this communication in error, please > notify the sender and delete all copies of this message. Persistent > Systems Ltd. does not accept any liability for virus infected mails. > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160519/01600e22/attachment.html From frank.herrmann at modernizingmedicine.com Thu May 19 09:24:53 2016 From: frank.herrmann at modernizingmedicine.com (Frank Herrmann) Date: Thu, 19 May 2016 09:24:53 -0400 Subject: [keycloak-user] Tempates - login.ftl - How is login.username being set? In-Reply-To: References: Message-ID: Hi All, I was wondering if anyone had any thoughts around this. I have a couple of fields I really need to save the information to repopulate the fields on a failed login. Basically, how is login.username populated in login.ftl, and can other fields be saved? Thanks. On Tue, May 17, 2016 at 2:19 PM, Frank Herrmann < frank.herrmann at modernizingmedicine.com> wrote: > In the template, login.ftl, the parameter login.username is begin used to > fill back in the username field after a failed login. In our custom > template, I have additional fields I wound not want a user to have to > refill after a failed login. Some of these fields are pre-populated via the > form authenticator with context.form().setAttribute, which works fine. > However, on a failed login, the login page changes and this context is lost. > > Is it possible to set additional fields to save their data during failed > login? > > Thanks, > > -Frank > > -- > FRANK HERRMANN > SOFTWARE ENGINEER > > T: 561-880-2998 x1563 > > E: frank.herrmann at modmed.com > > > > [image: [ Modernizing Medicine ]] > [image: [ Facebook ]] [image: > [ LinkedIn ]] [image: > [ YouTube ]] [image: [ > Twitter ]] [image: [ Blog ]] > [image: [ Instagram ]] > > > -- FRANK HERRMANN SOFTWARE ENGINEER T: 561-880-2998 x1563 E: frank.herrmann at modmed.com [image: [ Modernizing Medicine ]] [image: [ Facebook ]] [image: [ LinkedIn ]] [image: [ YouTube ]] [image: [ Twitter ]] [image: [ Blog ]] [image: [ Instagram ]] -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160519/767a6a45/attachment-0001.html From srossillo at smartling.com Thu May 19 11:07:04 2016 From: srossillo at smartling.com (Scott Rossillo) Date: Thu, 19 May 2016 11:07:04 -0400 Subject: [keycloak-user] Spring Security Adapter - Custom Parameter to KeyCloak In-Reply-To: References: Message-ID: <70150B37-654F-4AE7-9561-5262CA4D56C3@smartling.com> You could override KeycloakAuthenticationEntryPoint. commenceLoginRedirect() Scott Rossillo Smartling | Senior Software Engineer srossillo at smartling.com > On May 17, 2016, at 2:18 PM, Frank Herrmann wrote: > > Hello, > > Our app is using openid-conntect and the Spring Security Adapter to authenticate to a KeyCloak IDP. The KeyCloak server has custom AuthenticatorFactory and UserFederationProviderFactory. We have also customized some of the KeyCloak/Spring code on the app. > > At this point, I need a custom query parameter included with the redirect call to KeyCloak. I cannot find in the KeyCloak/Spring Security Adapter code any way to set an additional query parameter. > > Is there a way to set an additional parameter, or another way to pass a custom map of information to KeyCloak as part of the redirect? For now I am using the "login_hint" parameter to pass additional information. I was just wondering if there is a better way. > > Thanks, > > -Frank > > -- > FRANK HERRMANN > SOFTWARE ENGINEER > T: 561-880-2998 x1563 > > E: ?frank.herrmann at modmed.com > > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160519/f86d84b2/attachment.html From jessec at stytch.com Thu May 19 13:53:46 2016 From: jessec at stytch.com (Jesse Chahal) Date: Thu, 19 May 2016 10:53:46 -0700 Subject: [keycloak-user] How to apply updates to keycloak instances Message-ID: Following some of the best practices for continuous Integration and continuous delivery there needs to be environments for build, test, and production. This would mean that following these practices would require you to have multiple versions of keycloak at different stages of development cycle. Some of these environments might not have important persistent data while others might. In order to have builds transition from one environment to another there may be configuration changes required for a build to be valid. This is especially true when new services (openid clients) are being added or "default" accounts. I'm trying to come up with a scripted way of updating keycloak instances that are backed up by an RDMS. This may include adding new clients, adding new users, updating realm config, etc... Originally I was planning on simply exporting the realm config and importing it every time keycloak starts. If I enabled the OVERWRITE option I might overwrite things that I do not want overridden. This is especially true if there is some config that differ's based on whether it is a build, test, or production instance. If I don't enable it then it is only useful for new/blank keycloak environments. I considered using liquibase but since I do not have control of schema changes created by the keycloak team I might run into issues with my liquibase file not being valid after a migration/liquibase update by the keycloak team as my liquibase file would run after keycloak's does. There might also be some other unknown issues our liquibase changes conflicting somehow with keycloak's liquibase changes. I've also considered writing my own updater tool using a scripting language (python/ruby) that calls keycloak's rest api. The issues with this mechanism is it feels like I am recreating the wheel as well as not being able to find good documentation on keycloak's openid endpoints/url's used for different oauth2 flows. Even if I did find this documentation it would also require me to find a good openid client for the scripting language. This doesn't matter for our normal clients as they simply use the keycloak subsystems and adapters instead. I've also looked at commonly used server configuration software such as chef, puppet, and ansible. I don't see a good solution using any of those tools yet either. What have other people done for cases like this? Please don't tell me there is someone who is doing this all manually because that doesn't work in modern software development. - doesn't accidentally delete users - doesn't accidentally delete clients - doesn't invalidate sessions (optional) - works to bring up new, correctly configured, keycloak instances - handles applying updates to existing keycloak instances - can handle minor differences between keycloak instances (build, test, production) when updating - preferably can work well in rolling deployment scenario's. -- I hope the keycloak team is taking these into consideration when doing database migration between 1-2 releases. It would be nice if they set some specific rules for rolling updates between versions (aka backwards breaking changes) From jessec at stytch.com Thu May 19 13:56:48 2016 From: jessec at stytch.com (Jesse Chahal) Date: Thu, 19 May 2016 10:56:48 -0700 Subject: [keycloak-user] Schedule background jobs as user Message-ID: So we've done a lot of work on our migration to keycloak but still have a few holes that are using another authentication system. We are using Wildfly10 along with the keycloak subsystem. The last real blocking issues is trying to schedule background tasks on behalf of a user using quartz. We've tried using impersonation role and mocking out the impersonation workflow that a browser does, it was fairly complicated and did not work very well. Service accounts don't seem to fit this scenario either as service accounts seem to be for performing client specific actions. We considered storing offline token's on behalf of users but the thing is users might not log in for years after scheduling their job. We need to set the Context and Principle to be the user who we are performing background tasks on behalf of. Is there a recommended way of doing this that has been tested by others? I'm sure we aren't the only company who schedule tasks on behalf of users. From kalc04 at gmail.com Thu May 19 15:10:12 2016 From: kalc04 at gmail.com (Lohitha Chiranjeewa) Date: Fri, 20 May 2016 00:40:12 +0530 Subject: [keycloak-user] Last Login Time of User In-Reply-To: References: <5732DDE0.70207@redhat.com> Message-ID: Hi Thomas, As you suggested I tried out in implementing a custom Required Action. It worked fine for normal Browser auth flow, but didn't for the Direct Grant auth flow (doesn't even return tokens when a Required Action is in place). Hence I had to implement the same through a custom Authentication Flow (extra Execution step) and added it to both Browser and Direct Grant flows. Now it seems to be working fine. Many thanks for your initial suggestion that paved the way to get this done! Thanks Marek for your suggestion as well - but as per our use case, retrieving data from existing user sessions would not work. Regards, Lohitha. On Fri, May 13, 2016 at 3:14 PM, Lohitha Chiranjeewa wrote: > Thanks for suggestions guys, will try out and see how it works. > > Regards, > Lohitha. > > On Wed, May 11, 2016 at 12:53 PM, Marek Posolda > wrote: > >> Another possibility is to look at userSession (this info is available in >> admin console). When user authenticates, the new userSession is created for >> him with the "started" attribute containing the time of authentication. In >> admin console (and also via REST endpoints) there is possibility to look at >> all userSessions of particular user, so you can chose the one with last >> "started" attribute. >> >> This requires some additional work for parse userSessions and also there >> is corner case when this info is not accurate (as new userSession is also >> created when "verify-email" is requested for particular user, which is not >> the time of successful authentication of particular user). >> >> On the other hand, you don't need the custom Authenticator >> implementation. And there is also performance penalty in store the info in >> DB in user attributes, because you need to write to DB and update user >> during each login. >> >> Marek >> >> >> >> On 10/05/16 17:10, Thomas Darimont wrote: >> >> Would be great to store some additional information like: >> - count of failed logins >> - last failed login date >> >> Cheers, >> Thomas >> >> 2016-05-10 14:38 GMT+02:00 Thomas Darimont < >> thomas.darimont at googlemail.com>: >> >>> Hello, >>> >>> I implemented a custom RequiredAction that maintains stuff like: >>> - first login time >>> - most recent login time >>> - login count >>> in user attributes. >>> >>> Cheers, >>> Thomas >>> >>> 2016-05-10 14:35 GMT+02:00 Lohitha Chiranjeewa < >>> kalc04 at gmail.com>: >>> >>>> Hi, >>>> >>>> Is there a way to retrieve the last login time of a given user? >>>> >>>> I checked the Admin Console, Rest specification and the mysql DB >>>> structure but couldn't find a place where that bit of information could be >>>> stored and retrieved from. Have I missed a place or is that feature not >>>> available (yet)? >>>> >>>> >>>> Regards, >>>> Lohitha. >>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>> >>> >>> >> >> >> _______________________________________________ >> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160520/4cf45561/attachment-0001.html From sthorger at redhat.com Fri May 20 01:34:50 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 20 May 2016 07:34:50 +0200 Subject: [keycloak-user] Schedule background jobs as user In-Reply-To: References: Message-ID: This is exactly what offline tokens where created to do. The offline token is not linked to user sessions so it doesn't matter if users login or not. Our adapters doesn't support it properly though so you'd need to create a filter or something that sets up the context and principle based on the offline token. On 19 May 2016 at 19:56, Jesse Chahal wrote: > So we've done a lot of work on our migration to keycloak but still > have a few holes that are using another authentication system. We are > using Wildfly10 along with the keycloak subsystem. The last real > blocking issues is trying to schedule background tasks on behalf of a > user using quartz. We've tried using impersonation role and mocking > out the impersonation workflow that a browser does, it was fairly > complicated and did not work very well. Service accounts don't seem to > fit this scenario either as service accounts seem to be for performing > client specific actions. We considered storing offline token's on > behalf of users but the thing is users might not log in for years > after scheduling their job. We need to set the Context and Principle > to be the user who we are performing background tasks on behalf of. Is > there a recommended way of doing this that has been tested by others? > I'm sure we aren't the only company who schedule tasks on behalf of > users. > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160520/0b29ed34/attachment.html From sthorger at redhat.com Fri May 20 01:46:15 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 20 May 2016 07:46:15 +0200 Subject: [keycloak-user] How to apply updates to keycloak instances In-Reply-To: References: Message-ID: Firstly, just wanted to highlight that core Keycloak team are devs, not sysadmins/ops guys, so we have limited experience in continuous delivery and maintenance of real production systems. Hence, we'd love input from the community on this. As it stands we don't really have a proper solution. I believe the best you can do at the moment is either using import feature, partial import or admin rest endpoints. Import is not going to work IMO as it requires re-creating the whole realm. Partial import may work, but would work best for new resources rather than modifying existing resources as it does a delete/create operation rather than attempt to modify. With the admin rest endpoints you'd get the best control of what's going on, but obviously that leaves a fair amount of the work. In the future we have an idea of introducing an "import directory" it would be possible to drop json files in here that would add, modify or delete resources (realms, clients, roles, users, whatever). This would allow dropping json files before the server starts and the server would then import on startup. It would also be possible to do this at runtime and new files would be detected at runtime. Finally, we also had an idea of an offline mode to run import of this (it would basically start the server without http listener, import files, then stop, so it could be used in a script/tool). Import is probably not the best name for it, as it would support modify and delete as well as "importing" new things. On 19 May 2016 at 19:53, Jesse Chahal wrote: > Following some of the best practices for continuous Integration and > continuous delivery there needs to be environments for build, test, > and production. This would mean that following these practices would > require you to have multiple versions of keycloak at different stages > of development cycle. Some of these environments might not have > important persistent data while others might. In order to have builds > transition from one environment to another there may be configuration > changes required for a build to be valid. This is especially true when > new services (openid clients) are being added or "default" accounts. > I'm trying to come up with a scripted way of updating keycloak > instances that are backed up by an RDMS. This may include adding new > clients, adding new users, updating realm config, etc... Originally I > was planning on simply exporting the realm config and importing it > every time keycloak starts. If I enabled the OVERWRITE option I might > overwrite things that I do not want overridden. This is especially > true if there is some config that differ's based on whether it is a > build, test, or production instance. If I don't enable it then it is > only useful for new/blank keycloak environments. I considered using > liquibase but since I do not have control of schema changes created by > the keycloak team I might run into issues with my liquibase file not > being valid after a migration/liquibase update by the keycloak team as > my liquibase file would run after keycloak's does. There might also be > some other unknown issues our liquibase changes conflicting somehow > with keycloak's liquibase changes. I've also considered writing my own > updater tool using a scripting language (python/ruby) that calls > keycloak's rest api. The issues with this mechanism is it feels like I > am recreating the wheel as well as not being able to find good > documentation on keycloak's openid endpoints/url's used for different > oauth2 flows. Even if I did find this documentation it would also > require me to find a good openid client for the scripting language. > This doesn't matter for our normal clients as they simply use the > keycloak subsystems and adapters instead. I've also looked at commonly > used server configuration software such as chef, puppet, and ansible. > I don't see a good solution using any of those tools yet either. What > have other people done for cases like this? Please don't tell me there > is someone who is doing this all manually because that doesn't work in > modern software development. > > - doesn't accidentally delete users > - doesn't accidentally delete clients > - doesn't invalidate sessions (optional) > - works to bring up new, correctly configured, keycloak instances > - handles applying updates to existing keycloak instances > - can handle minor differences between keycloak instances (build, > test, production) when updating > - preferably can work well in rolling deployment scenario's. > -- I hope the keycloak team is taking these into consideration when > doing database migration between 1-2 releases. It would be nice if > they set some specific rules for rolling updates between versions (aka > backwards breaking changes) > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160520/0f37a0eb/attachment.html From sthorger at redhat.com Fri May 20 01:56:42 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 20 May 2016 07:56:42 +0200 Subject: [keycloak-user] Integrate Keycloak 1.9.4 with Openshift Origin In-Reply-To: References: Message-ID: Yes, those are the correct URLs. The URLs from the blog post you are referring to are deprecated as they where not following the spec. BTW the following endpoint lists all URLs for OIDC, we're also improving the docs around this soon: http://localhost:8080/auth/realms//.well-known/openid-configuration On 19 May 2016 at 09:18, Charles Moulliard wrote: > Hi, > > According to Openshift Doc ( > https://docs.openshift.com/enterprise/3.0/admin_guide/configuring_authentication.html#OpenID) > and this blog article ( > http://blog.keycloak.org/2015/06/openshift-ui-console-authentication.html), > we can integrate Keycloak as IdentiyProvider with Openshift. > > So, I have configured the master-config.yaml to use Keycloak 1.9.4.Final > as Identity Provider. See hereafter the config > > oauthConfig: >> >> alwaysShowProviderSelection: false >> >> assetPublicURL: https://192.168.99.100:8443/console/ >> >> grantConfig: >> >> method: auto >> >> identityProviders: >> >> - challenge: true >> >> login: true >> >> name: keycloak >> >> provider: >> >> apiVersion: v1 >> >> kind: OpenIDIdentityProvider >> >> ca: keycloak-ca.cert >> >> clientID: openshift >> >> clientSecret: fbde8b27-3342-4494-b3a3-7db645e9dfe5 >> >> claims: >> >> id: >> >> - sub >> >> preferredUsername: >> >> - preferred_username >> >> name: >> >> - name >> >> email: >> >> - email >> >> urls: >> >> authorize: >>> https://192.168.1.80:8443/auth/realms/openshift/tokens/login >> >> token: >>> https://192.168.1.80:8443/auth/realms/openshift/tokens/access/codes >> >> > But, when I try to log on to the Openshift console, I'm redirected to > Keycloak Server which returns this Error 404 > > --> GET > https://192.168.1.80:8443/auth/realms/openshift/tokens/login?client_id=open?YlMjUyRjE5Mi4xNjguOTkuMTAwJTI1M0E4NDQzJTI1MkZjb25zb2xlJTI1MkZvYXV0aA%3D%3D > 404 (Not Found) > > According to this thread ( > http://stackoverflow.com/questions/28658735/what-are-keycloaks-oauth2-openid-connect-endpoints > ), the urls to be used are these > > authorize: > https://192.168.1.80:8443/auth/realms/openshift/protocol/openid-connect/auth > token: > https://192.168.1.80:8443/auth/realms/openshift/protocol/openid-connect/token > > FYI, I can get a token --> > > curl -k -s -X POST >> https://192.168.1.80:8443/auth/realms/openshift/protocol/openid-connect/token -H >> "Content-Type: application/x-www-form-urlencoded" -d 'username=test-user' >> -d 'password=password' -d 'grant_type=password' -d 'client_id=openshift' -d >> 'client_secret=fbde8b27-3342-4494-b3a3-7db645e9dfe5' | jq -r '.access_token' >> eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI1ODExNGExZi1mMTQwLTQwYTctODAwOS1hNGU2 > > > Can you confirm that the correct urls to be used are ? > > authorize: > https://192.168.1.80:8443/auth/realms/openshift/protocol/openid-connect/auth > token: > https://192.168.1.80:8443/auth/realms/openshift/protocol/openid-connect/token > > Regards, > > Charles > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160520/00339589/attachment-0001.html From vaibhav_naldurgkar at persistent.com Fri May 20 02:00:36 2016 From: vaibhav_naldurgkar at persistent.com (Vaibhav Naldurgkar) Date: Fri, 20 May 2016 06:00:36 +0000 Subject: [keycloak-user] Keycloak OAuth High CPU usage In-Reply-To: References: Message-ID: Hi Stian, Thank you for your reply. The new tokens needs to be generated for each user, which is needed from security point of view. The performance tests were also conducted using single Admin user and token for admin user; however in that case the performance was not good. In between 15th to 20th admin token access requests ? the CPU usage of keycloak Java process was crossing 90 to 120% mark. As you have mentioned, Creating tokes are expected to be a bit CPU intensive ? what should be the server configuration in terms of CPU to deal with more than 500 users to use keycloak as OAuth provider. Thanks, Vaibhav From: Stian Thorgersen [mailto:sthorger at redhat.com] Sent: Thursday, May 19, 2016 6:28 PM To: Vaibhav Naldurgkar Cc: keycloak-user at lists.jboss.org Subject: Re: [keycloak-user] Keycloak OAuth High CPU usage Creating tokes are expected to be a bit CPU intensive as they need to be signed. When you say you try to generate tokens for 10-20 users are you doing performance tests and having 10-20 threads generating tokens? It shouldn't make any difference if you have 10 or if you have 200 users, it's the total number of tokens that can be generated that's an issue. Having 200 concurrent users with a access token timeout of 60 seconds should mean that you need to be able to generate roughly 200/60 tokens = 3.3 tokens/sec. On 19 May 2016 at 13:24, Vaibhav Naldurgkar > wrote: Hi All, I am using Keycloak 1.9.3 with default configuration. Keycloak server is installed on RHEL 6.5 virtual image with 4 CPU , 8 GB RAM and java version is jdk1.8.0_73 We are trying to use keycloak as a OAuth provider. But when we try and generate token(http:///auth/realms/master/protocol/openid-connect/token) for more than 10-20 users the server gets too slow and cpu usage goes over 100%. Any pointers on how to improve performance of keycloak OAuth provider. We need to support at least 200 concurrent users. Thanks, Vaibhav DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160520/feca25a8/attachment.html From darrell at 1placeonline.com Fri May 20 02:10:49 2016 From: darrell at 1placeonline.com (Darrell Wu) Date: Fri, 20 May 2016 18:10:49 +1200 Subject: [keycloak-user] How to include the keycloak wildfly adapter libraries in the secure war application classpath? Message-ID: Hi, With the keycloak wildfly adapter for version 1.9.x i've noticed that the location of the Keycloak Subsystem modules have changed from modules\system\layers\base\org\keycloak to modules\system\add-ons\keycloak\org\keycloak Now on my secure war application server I've installed the keycloak wildfly adpater by unzipping the archive and running the adapter-install.cl script. Now In my application i'm getting a ClassNotFoundException: org.keycloak.KeycloakSecurityContext when the following is executed KeycloakSecurityContext securityContext = (KeycloakSecurityContext) httpRequest.getAttribute(KeycloakSecurityContext.class.getName()); Obviously the application isn't loading the keycloak modules in the classpath. What is the proper way to include the keycloak libraries in my app? Should my app have a jboss-deployment-structure.xml file or should the libraries be moved back to modules\system\layers\base\org\keycloak? Thanks -- Darrell Wu 1Place Limited P.O. Box 125152, St Heliers, Auckland 1740, New Zealand Level 4, 1 Queen Street, Auckland 1010, New Zealand Phone: +64 9 5200612 ext 521 | Mob: +64 21 262 4898 | Fax: +64 9 5246203 Email: darrell at 1placeonline.com | Web: www.1placeonline.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160520/678486dc/attachment.html From sthorger at redhat.com Fri May 20 03:31:19 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 20 May 2016 09:31:19 +0200 Subject: [keycloak-user] Keycloak OAuth High CPU usage In-Reply-To: References: Message-ID: Can you please elaborate a bit more on how your are testing scenario is? I'm a bit confused to what you are testing when you are talking about generating new tokens. Are you using OIDC or SAML? Are you talking about code->token exchanges, refresh token requests, or what? To test if your hardware is capable to deal with the load you need to test logins (verifying passwords are CPU intensive) as well as obtaining tokens (both code->token, done after login, and refreshing token, done ~1 min or so by active users, but most users won't continuously use the application). 500 users should be no problem at all. As an example with a single thread (which will use a single core) I could invoke 10000 token refreshes in under 60 seconds on my laptop. So a single core on my laptop should be able to handle 500 users. On 20 May 2016 at 08:00, Vaibhav Naldurgkar < vaibhav_naldurgkar at persistent.com> wrote: > Hi Stian, > > Thank you for your reply. > > > > The new tokens needs to be generated for each user, which is needed from > security point of view. The performance tests were also conducted using > single Admin user and token for admin user; however in that case the > performance was not good. In between 15th to 20th admin token access > requests ? the CPU usage of keycloak Java process was crossing 90 to 120% > mark. > > > > As you have mentioned, Creating tokes are expected to be a bit CPU > intensive ? what should be the server configuration in terms of CPU to deal > with more than 500 users to use keycloak as OAuth provider. > > > > > > Thanks, Vaibhav > > > > > > > > *From:* Stian Thorgersen [mailto:sthorger at redhat.com] > *Sent:* Thursday, May 19, 2016 6:28 PM > *To:* Vaibhav Naldurgkar > *Cc:* keycloak-user at lists.jboss.org > *Subject:* Re: [keycloak-user] Keycloak OAuth High CPU usage > > > > Creating tokes are expected to be a bit CPU intensive as they need to be > signed. When you say you try to generate tokens for 10-20 users are you > doing performance tests and having 10-20 threads generating tokens? It > shouldn't make any difference if you have 10 or if you have 200 users, it's > the total number of tokens that can be generated that's an issue. Having > 200 concurrent users with a access token timeout of 60 seconds should mean > that you need to be able to generate roughly 200/60 tokens = 3.3 tokens/sec. > > > > On 19 May 2016 at 13:24, Vaibhav Naldurgkar < > vaibhav_naldurgkar at persistent.com> wrote: > > Hi All, > > > > I am using Keycloak 1.9.3 with default configuration. Keycloak server is > installed on RHEL 6.5 virtual image with 4 CPU , 8 GB RAM and java version > is jdk1.8.0_73 We are trying to use keycloak as a OAuth provider. But when > we try and generate token( > http:///auth/realms/master/protocol/openid-connect/token > ) for more than > 10-20 users the server gets too slow and cpu usage goes over 100%. > > Any pointers on how to improve performance of keycloak OAuth provider. We > need to support at least 200 concurrent users. > > > > > > Thanks, Vaibhav > > DISCLAIMER ========== This e-mail may contain privileged and confidential > information which is the property of Persistent Systems Ltd. It is intended > only for the use of the individual or entity to which it is addressed. If > you are not the intended recipient, you are not authorized to read, retain, > copy, print, distribute or use this message. If you have received this > communication in error, please notify the sender and delete all copies of > this message. Persistent Systems Ltd. does not accept any liability for > virus infected mails. > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > DISCLAIMER ========== This e-mail may contain privileged and confidential > information which is the property of Persistent Systems Ltd. It is intended > only for the use of the individual or entity to which it is addressed. If > you are not the intended recipient, you are not authorized to read, retain, > copy, print, distribute or use this message. If you have received this > communication in error, please notify the sender and delete all copies of > this message. Persistent Systems Ltd. does not accept any liability for > virus infected mails. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160520/d54b5fa1/attachment-0001.html From tve at quartetfs.com Fri May 20 05:22:17 2016 From: tve at quartetfs.com (Thibault Vernadat) Date: Fri, 20 May 2016 11:22:17 +0200 Subject: [keycloak-user] Update roles at login time between 2 realms Message-ID: <573ED749.6060601@quartetfs.com> Hello, What I am trying to achieve is the following : I have two realms with one client each. Let's call them realm A and realm B. Users from realm B can access my application of realm A, because I added realm B as a keycloak openid connect identity provider in realm A. First time a user from real B access my realm A client, this creates a user in realm A for this client, and I map some roles for this client. So far so good. My issue now is : let's say my client initially had a role R in realm B, and at first login this role was mapped for this user in realm A, if the realm B admin remove role R from this user, I want this role to be removed as well in realm A. Or added if a new role that should be mapped was added. Is there a way to update roles next time this user try to authenticate in the realm A app ? Or should I use another mechanism to keep my roles consistent between my realms ? Thanks a lot in advance for your help. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160520/abddbf76/attachment.html From vaibhav_naldurgkar at persistent.com Fri May 20 05:27:00 2016 From: vaibhav_naldurgkar at persistent.com (Vaibhav Naldurgkar) Date: Fri, 20 May 2016 09:27:00 +0000 Subject: [keycloak-user] Keycloak OAuth High CPU usage In-Reply-To: References: Message-ID: Hi Stian, After reading your tests results of 10000 token refreshes in under 60 seconds on your laptop, I am sure I am not following correct configuration and the documents are missing for reference. Could you please verify the below steps along with the screen-shots for the steps which I am following for the adding client and testing the Load performance using Jmeter. Please suggest if any changes are needed in the client configuration. In this case we are obtaining the token for user from KeyCloak. In my case the user have been stored on RedHat IdM which has been federated using KeyCloak. Step 1. Create new client called ?LoadTest? , use the Client Protocol as ?Openid-connect?. Used all defaults values post save of the client action. Step 2. Start the load tests using Jmeter and using the path as ?/auth/realms/master/protocol/openid-connect/token? . Used 20 Number of Threads and used Post method. Below is the screen-shot for the step 1 related to Add Client. [cid:image001.png at 01D1B2A2.4E84D7F0] Below is the screen shot for the load test using Jmeter. In this case the Client ID was used as HelloTest. [cid:image002.png at 01D1B2A2.4E84D7F0] Http requests. [cid:image003.png at 01D1B2A2.4E84D7F0] Thanks, Vaibhav From: Stian Thorgersen [mailto:sthorger at redhat.com] Sent: Friday, May 20, 2016 1:01 PM To: Vaibhav Naldurgkar Cc: keycloak-user at lists.jboss.org Subject: Re: [keycloak-user] Keycloak OAuth High CPU usage Can you please elaborate a bit more on how your are testing scenario is? I'm a bit confused to what you are testing when you are talking about generating new tokens. Are you using OIDC or SAML? Are you talking about code->token exchanges, refresh token requests, or what? To test if your hardware is capable to deal with the load you need to test logins (verifying passwords are CPU intensive) as well as obtaining tokens (both code->token, done after login, and refreshing token, done ~1 min or so by active users, but most users won't continuously use the application). 500 users should be no problem at all. As an example with a single thread (which will use a single core) I could invoke 10000 token refreshes in under 60 seconds on my laptop. So a single core on my laptop should be able to handle 500 users. On 20 May 2016 at 08:00, Vaibhav Naldurgkar > wrote: Hi Stian, Thank you for your reply. The new tokens needs to be generated for each user, which is needed from security point of view. The performance tests were also conducted using single Admin user and token for admin user; however in that case the performance was not good. In between 15th to 20th admin token access requests ? the CPU usage of keycloak Java process was crossing 90 to 120% mark. As you have mentioned, Creating tokes are expected to be a bit CPU intensive ? what should be the server configuration in terms of CPU to deal with more than 500 users to use keycloak as OAuth provider. Thanks, Vaibhav From: Stian Thorgersen [mailto:sthorger at redhat.com] Sent: Thursday, May 19, 2016 6:28 PM To: Vaibhav Naldurgkar Cc: keycloak-user at lists.jboss.org Subject: Re: [keycloak-user] Keycloak OAuth High CPU usage Creating tokes are expected to be a bit CPU intensive as they need to be signed. When you say you try to generate tokens for 10-20 users are you doing performance tests and having 10-20 threads generating tokens? It shouldn't make any difference if you have 10 or if you have 200 users, it's the total number of tokens that can be generated that's an issue. Having 200 concurrent users with a access token timeout of 60 seconds should mean that you need to be able to generate roughly 200/60 tokens = 3.3 tokens/sec. On 19 May 2016 at 13:24, Vaibhav Naldurgkar > wrote: Hi All, I am using Keycloak 1.9.3 with default configuration. Keycloak server is installed on RHEL 6.5 virtual image with 4 CPU , 8 GB RAM and java version is jdk1.8.0_73 We are trying to use keycloak as a OAuth provider. But when we try and generate token(http:///auth/realms/master/protocol/openid-connect/token) for more than 10-20 users the server gets too slow and cpu usage goes over 100%. Any pointers on how to improve performance of keycloak OAuth provider. We need to support at least 200 concurrent users. Thanks, Vaibhav DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160520/efb99598/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 101405 bytes Desc: image001.png Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160520/efb99598/attachment-0003.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 11865 bytes Desc: image002.png Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160520/efb99598/attachment-0004.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 18447 bytes Desc: image003.png Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160520/efb99598/attachment-0005.png From bruno at abstractj.org Fri May 20 06:10:13 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 20 May 2016 07:10:13 -0300 Subject: [keycloak-user] How to include the keycloak wildfly adapter libraries in the secure war application classpath? In-Reply-To: References: Message-ID: <20160520101013.GA24124@abstractj.org> Weird because it was fixed here: https://issues.jboss.org/browse/KEYCLOAK-2483. Plus, I tested on WildFly 9.0.2.Final with Keycloak adapter 1.9.4.Final and couldn't reproduce the issue. On 2016-05-20, Darrell Wu wrote: > Hi, > > With the keycloak wildfly adapter for version 1.9.x i've noticed that the > location of the Keycloak Subsystem modules have changed from > modules\system\layers\base\org\keycloak to > modules\system\add-ons\keycloak\org\keycloak > > Now on my secure war application server I've installed the keycloak wildfly > adpater by unzipping the archive and running the adapter-install.cl script. > > Now In my application i'm getting a > ClassNotFoundException: org.keycloak.KeycloakSecurityContext > > when the following is executed > > KeycloakSecurityContext securityContext = (KeycloakSecurityContext) > httpRequest.getAttribute(KeycloakSecurityContext.class.getName()); > > Obviously the application isn't loading the keycloak modules in the > classpath. > What is the proper way to include the keycloak libraries in my app? > > Should my app have a jboss-deployment-structure.xml file or should the > libraries be moved back to modules\system\layers\base\org\keycloak? > > Thanks > > > > -- > Darrell Wu > 1Place Limited > P.O. Box 125152, St Heliers, Auckland 1740, New Zealand > Level 4, 1 Queen Street, Auckland 1010, New Zealand > Phone: +64 9 5200612 ext 521 | Mob: +64 21 262 4898 | Fax: +64 9 5246203 > Email: darrell at 1placeonline.com | Web: www.1placeonline.com > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -- abstractj PGP: 0x84DC9914 From darrell at 1placeonline.com Fri May 20 07:27:16 2016 From: darrell at 1placeonline.com (Darrell Wu) Date: Fri, 20 May 2016 23:27:16 +1200 Subject: [keycloak-user] How to include the keycloak wildfly adapter libraries in the secure war application classpath? In-Reply-To: <20160520101013.GA24124@abstractj.org> References: <20160520101013.GA24124@abstractj.org> Message-ID: If it helps I'm using wildfly 10 and have keycloak on a standalone server. The authenication works. It just when my app tries to read the security context I get the class not found exception. So what triggers wildfly to include the keycloak modules in my apps class path? On 20/05/2016 10:10 pm, "Bruno Oliveira" wrote: > Weird because it was fixed here: > https://issues.jboss.org/browse/KEYCLOAK-2483. Plus, I tested > on WildFly 9.0.2.Final with Keycloak adapter 1.9.4.Final and couldn't > reproduce the issue. > > On 2016-05-20, Darrell Wu wrote: > > Hi, > > > > With the keycloak wildfly adapter for version 1.9.x i've noticed that the > > location of the Keycloak Subsystem modules have changed from > > modules\system\layers\base\org\keycloak to > > modules\system\add-ons\keycloak\org\keycloak > > > > Now on my secure war application server I've installed the keycloak > wildfly > > adpater by unzipping the archive and running the adapter-install.cl > script. > > > > Now In my application i'm getting a > > ClassNotFoundException: org.keycloak.KeycloakSecurityContext > > > > when the following is executed > > > > KeycloakSecurityContext securityContext = (KeycloakSecurityContext) > > httpRequest.getAttribute(KeycloakSecurityContext.class.getName()); > > > > Obviously the application isn't loading the keycloak modules in the > > classpath. > > What is the proper way to include the keycloak libraries in my app? > > > > Should my app have a jboss-deployment-structure.xml file or should the > > libraries be moved back to modules\system\layers\base\org\keycloak? > > > > Thanks > > > > > > > > -- > > Darrell Wu > > 1Place Limited > > P.O. Box 125152, St Heliers, Auckland 1740, New Zealand > > Level 4, 1 Queen Street, Auckland 1010, New Zealand > > Phone: +64 9 5200612 ext 521 | Mob: +64 21 262 4898 | Fax: +64 9 5246203 > > Email: darrell at 1placeonline.com | Web: www.1placeonline.com > > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > -- > > abstractj > PGP: 0x84DC9914 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160520/24dfd69e/attachment.html From cmoullia at redhat.com Fri May 20 07:59:41 2016 From: cmoullia at redhat.com (Charles Moulliard) Date: Fri, 20 May 2016 13:59:41 +0200 Subject: [keycloak-user] Integrate Keycloak 1.9.4 with Openshift Origin In-Reply-To: References: Message-ID: Thx. I have been able to configure Openshift with Keycloak as Identity Provider On Fri, May 20, 2016 at 7:56 AM, Stian Thorgersen wrote: > Yes, those are the correct URLs. The URLs from the blog post you are > referring to are deprecated as they where not following the spec. > > BTW the following endpoint lists all URLs for OIDC, we're also improving > the docs around this soon: > http://localhost:8080/auth/realms/ NAME>/.well-known/openid-configuration > > > > > On 19 May 2016 at 09:18, Charles Moulliard wrote: > >> Hi, >> >> According to Openshift Doc ( >> https://docs.openshift.com/enterprise/3.0/admin_guide/configuring_authentication.html#OpenID) >> and this blog article ( >> http://blog.keycloak.org/2015/06/openshift-ui-console-authentication.html >> ), we can integrate Keycloak as IdentiyProvider with Openshift. >> >> So, I have configured the master-config.yaml to use Keycloak 1.9.4.Final >> as Identity Provider. See hereafter the config >> >> oauthConfig: >>> >>> alwaysShowProviderSelection: false >>> >>> assetPublicURL: https://192.168.99.100:8443/console/ >>> >>> grantConfig: >>> >>> method: auto >>> >>> identityProviders: >>> >>> - challenge: true >>> >>> login: true >>> >>> name: keycloak >>> >>> provider: >>> >>> apiVersion: v1 >>> >>> kind: OpenIDIdentityProvider >>> >>> ca: keycloak-ca.cert >>> >>> clientID: openshift >>> >>> clientSecret: fbde8b27-3342-4494-b3a3-7db645e9dfe5 >>> >>> claims: >>> >>> id: >>> >>> - sub >>> >>> preferredUsername: >>> >>> - preferred_username >>> >>> name: >>> >>> - name >>> >>> email: >>> >>> - email >>> >>> urls: >>> >>> authorize: >>>> https://192.168.1.80:8443/auth/realms/openshift/tokens/login >>> >>> token: >>>> https://192.168.1.80:8443/auth/realms/openshift/tokens/access/codes >>> >>> >> But, when I try to log on to the Openshift console, I'm redirected to >> Keycloak Server which returns this Error 404 >> >> --> GET >> https://192.168.1.80:8443/auth/realms/openshift/tokens/login?client_id=open?YlMjUyRjE5Mi4xNjguOTkuMTAwJTI1M0E4NDQzJTI1MkZjb25zb2xlJTI1MkZvYXV0aA%3D%3D >> 404 (Not Found) >> >> According to this thread ( >> http://stackoverflow.com/questions/28658735/what-are-keycloaks-oauth2-openid-connect-endpoints >> ), the urls to be used are these >> >> authorize: >> https://192.168.1.80:8443/auth/realms/openshift/protocol/openid-connect/auth >> token: >> https://192.168.1.80:8443/auth/realms/openshift/protocol/openid-connect/token >> >> FYI, I can get a token --> >> >> curl -k -s -X POST >>> https://192.168.1.80:8443/auth/realms/openshift/protocol/openid-connect/token -H >>> "Content-Type: application/x-www-form-urlencoded" -d 'username=test-user' >>> -d 'password=password' -d 'grant_type=password' -d 'client_id=openshift' -d >>> 'client_secret=fbde8b27-3342-4494-b3a3-7db645e9dfe5' | jq -r '.access_token' >>> eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI1ODExNGExZi1mMTQwLTQwYTctODAwOS1hNGU2 >> >> >> Can you confirm that the correct urls to be used are ? >> >> authorize: >> https://192.168.1.80:8443/auth/realms/openshift/protocol/openid-connect/auth >> token: >> https://192.168.1.80:8443/auth/realms/openshift/protocol/openid-connect/token >> >> Regards, >> >> Charles >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160520/78783fd7/attachment-0001.html From bruno at abstractj.org Fri May 20 08:51:40 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 20 May 2016 09:51:40 -0300 Subject: [keycloak-user] How to include the keycloak wildfly adapter libraries in the secure war application classpath? In-Reply-To: References: <20160520101013.GA24124@abstractj.org> Message-ID: <20160520125140.GA29687@abstractj.org> Do you have the security domain specified like described here: http://keycloak.github.io/docs/userguide/saml-client-adapter/html/jboss-adapter.html If possible send some steps to reproduce or the code snippet. On 2016-05-20, Darrell Wu wrote: > If it helps I'm using wildfly 10 and have keycloak on a standalone server. > The authenication works. It just when my app tries to read the security > context I get the class not found exception. > > So what triggers wildfly to include the keycloak modules in my apps class > path? > On 20/05/2016 10:10 pm, "Bruno Oliveira" wrote: > > > Weird because it was fixed here: > > https://issues.jboss.org/browse/KEYCLOAK-2483. Plus, I tested > > on WildFly 9.0.2.Final with Keycloak adapter 1.9.4.Final and couldn't > > reproduce the issue. > > > > On 2016-05-20, Darrell Wu wrote: > > > Hi, > > > > > > With the keycloak wildfly adapter for version 1.9.x i've noticed that the > > > location of the Keycloak Subsystem modules have changed from > > > modules\system\layers\base\org\keycloak to > > > modules\system\add-ons\keycloak\org\keycloak > > > > > > Now on my secure war application server I've installed the keycloak > > wildfly > > > adpater by unzipping the archive and running the adapter-install.cl > > script. > > > > > > Now In my application i'm getting a > > > ClassNotFoundException: org.keycloak.KeycloakSecurityContext > > > > > > when the following is executed > > > > > > KeycloakSecurityContext securityContext = (KeycloakSecurityContext) > > > httpRequest.getAttribute(KeycloakSecurityContext.class.getName()); > > > > > > Obviously the application isn't loading the keycloak modules in the > > > classpath. > > > What is the proper way to include the keycloak libraries in my app? > > > > > > Should my app have a jboss-deployment-structure.xml file or should the > > > libraries be moved back to modules\system\layers\base\org\keycloak? > > > > > > Thanks > > > > > > > > > > > > -- > > > Darrell Wu > > > 1Place Limited > > > P.O. Box 125152, St Heliers, Auckland 1740, New Zealand > > > Level 4, 1 Queen Street, Auckland 1010, New Zealand > > > Phone: +64 9 5200612 ext 521 | Mob: +64 21 262 4898 | Fax: +64 9 5246203 > > > Email: darrell at 1placeonline.com | Web: www.1placeonline.com > > > > > _______________________________________________ > > > keycloak-user mailing list > > > keycloak-user at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > -- abstractj PGP: 0x84DC9914 From bburke at redhat.com Fri May 20 08:53:15 2016 From: bburke at redhat.com (Bill Burke) Date: Fri, 20 May 2016 08:53:15 -0400 Subject: [keycloak-user] Update roles at login time between 2 realms In-Reply-To: <573ED749.6060601@quartetfs.com> References: <573ED749.6060601@quartetfs.com> Message-ID: A better question is, why are you using 2 realms and creating the same user in each? On 5/20/16 5:22 AM, Thibault Vernadat wrote: > Hello, > > What I am trying to achieve is the following : > > I have two realms with one client each. Let's call them realm A and > realm B. > > Users from realm B can access my application of realm A, because I > added realm B as a keycloak openid connect identity provider in realm A. > > First time a user from real B access my realm A client, this creates a > user in realm A for this client, and I map some roles for this client. > > So far so good. My issue now is : let's say my client initially had a > role R in realm B, and at first login this role was mapped for this > user in realm A, if the realm B admin remove role R from this user, I > want this role to be removed as well in realm A. Or added if a new > role that should be mapped was added. > > Is there a way to update roles next time this user try to authenticate > in the realm A app ? Or should I use another mechanism to keep my > roles consistent between my realms ? > > Thanks a lot in advance for your help. > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160520/0272258b/attachment.html From tve at quartetfs.com Fri May 20 10:08:42 2016 From: tve at quartetfs.com (Thibault Vernadat) Date: Fri, 20 May 2016 16:08:42 +0200 Subject: [keycloak-user] Update roles at login time between 2 realms In-Reply-To: References: <573ED749.6060601@quartetfs.com> Message-ID: <573F1A6A.3040800@quartetfs.com> So here is a bit more of context regarding why I am doing this and trying to achieve. // Short version We have application where we would like to allow an "admin" customer user to add other users of his company with some roles, but not some specific roles that would be reserved for us. So far, we only overcame that by creating 2 realms. // Longer version Actually, the client of realm A is going to be an application where all users of my company need to have access, and with full rights (basically this is an application for administrating and configuring application of realm B). Client of realm B is going to be an application used by a given customer of ours. Initially, we would create a single user on this realm B, with "admin rights" on users for this realm. So this customer admin will be able to manage the users of this customer realm, change roles, and so forth. This customer admin user will also have a role CUSTOMER_ADMIN on this realm B. The use case we are trying to solve is : we need to be able to give to this "customer admin of realm B user" a limited access to the application of realm A. (So that our customer is able to manage part of his application, but not all of it). This limited access on application of realm A would be granted only if the user has role CUSTOMER_ADMIN on realm B. Now so far, first time this customer admin user connects to the application of realm A, this creates a user in realm A, with the CUSTOMER_ADMIN role on realm A if it was found on realm B, thanks to a role importer mapper. But let's say this CUSTOMER_ADMIN role is removed by us on realm B for this user, or this CUSTOMER_ADMIN role is given to another user on realm B, we need to sync the roles on realm A so that is has or no longer has access to application on realm A. I have no clue if this is a trivial use case of not, and if the way we thought this is correct way to do, but any input will be much appreciated! Thanks a lot! Le 05/20/2016 02:53 PM, Bill Burke a ?crit : > > A better question is, why are you using 2 realms and creating the same > user in each? > > > On 5/20/16 5:22 AM, Thibault Vernadat wrote: >> Hello, >> >> What I am trying to achieve is the following : >> >> I have two realms with one client each. Let's call them realm A and >> realm B. >> >> Users from realm B can access my application of realm A, because I >> added realm B as a keycloak openid connect identity provider in realm A. >> >> First time a user from real B access my realm A client, this creates >> a user in realm A for this client, and I map some roles for this client. >> >> So far so good. My issue now is : let's say my client initially had a >> role R in realm B, and at first login this role was mapped for this >> user in realm A, if the realm B admin remove role R from this user, I >> want this role to be removed as well in realm A. Or added if a new >> role that should be mapped was added. >> >> Is there a way to update roles next time this user try to >> authenticate in the realm A app ? Or should I use another mechanism >> to keep my roles consistent between my realms ? >> >> Thanks a lot in advance for your help. >> >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160520/f2b8cee6/attachment.html From chairfield at gmail.com Fri May 20 11:21:22 2016 From: chairfield at gmail.com (Chris Hairfield) Date: Fri, 20 May 2016 15:21:22 +0000 Subject: [keycloak-user] Checkbox in User Attributes Message-ID: Hello, We're running into an issue unchecking a checkbox in our account theme and came across the following post with no answer. As Libor asks the question elegantly, I'll copy his text verbatim and hope someone now has an answer. Hi, I?d like to use user attributes to store information like ?Subscribe to newsletter? which is obviously checkbox. How should I implement it in my account.ftl? I have in account.flt:
When I tick it and submit form everything is OK but when untick it and submit then checkbox is still checked. I guess it?s because checkbox state is included in HTTP Form Data only when it?s checked. How to handle this in KC UI ? I remember that other frameworks used some hidden fields to post the information either if checkbox was ticked or not. But I?m not sure how KC GUI framework handle this use case. Thanks, Libor Krzy?anekjboss.org Development Team -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160520/73b33d79/attachment-0001.html From chairfield at gmail.com Fri May 20 11:48:49 2016 From: chairfield at gmail.com (Chris Hairfield) Date: Fri, 20 May 2016 15:48:49 +0000 Subject: [keycloak-user] Access Token from Account Theme Message-ID: Hello, We're trying to make a web request from our account.ftl (to upload a profile photo) and wish to send the access token of the signed in user with the request to authorize that action. Does anyone know how to obtain the access token from within the account.ftl theme? I'm hoping it's stored in a cookie that we have access to from our theme's javascript. Thanks, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160520/587de236/attachment.html From jaxley at expedia.com Fri May 20 13:10:02 2016 From: jaxley at expedia.com (Jason Axley) Date: Fri, 20 May 2016 17:10:02 +0000 Subject: [keycloak-user] Validating JWT tokens In-Reply-To: References: <1462377616.1947384.598056425.5C00B82A@webmail.messagingengine.com> <1462379847.1956071.598104761.4A24EAC6@webmail.messagingengine.com> <4AC8C602867B3A4CB6F9F6BA4528DEE477CD682C@WPHXMAIL1.phx.axway.int> Message-ID: <35FCFDAA-7DC5-4548-A5CE-B5F06C663976@expedia.com> +1 for not trusting the algorithm in the JWT header to avoid these attacks: https://auth0.com/blog/2015/03/31/critical-vulnerabilities-in-json-web-token-libraries/ Should do more than just signature validation though to be secure: ? Expiration check ? Audience check ? Subject check This is a pretty good overview of the mechanics: http://www.cloudidentity.com/blog/2014/03/03/principles-of-token-validation/ -Jason From: on behalf of Stian Thorgersen Reply-To: "stian at redhat.com" Date: Wednesday, May 18, 2016 at 10:01 PM To: Josh Cain Cc: Aikeaguinea , "keycloak-user at lists.jboss.org" Subject: Re: [keycloak-user] Validating JWT tokens You can also use https://github.com/keycloak/keycloak/blob/master/core/src/main/java/org/keycloak/RSATokenVerifier.java On 11 May 2016 at 15:50, Josh Cain > wrote: I recently put together a quick test for this as well using jjwt: https://github.com/cainj13/jwtExamples/blob/master/src/test/java/jcain/example/TokenParseTest.java Pretty similar to the gist that Thomas mentioned above. Josh Cain | Software Applications Engineer Identity and Access Management Red Hat +1 843-737-1735 On Wed, May 11, 2016 at 4:09 AM, Thomas Darimont > wrote: Hello, another example for (Parsing) & Validating a Keycloak JWT was posted on the ML a few months ago: http://lists.jboss.org/pipermail/keycloak-user/2016-March/005325.html In the example the token is only successfully parsed when the token is valid. Cheers, Thomas 2016-05-11 10:45 GMT+02:00 Gerard Laissard >: My 2 cents: There is an openSSL example to verify a jwt: https://gist.github.com/rolandyoung/176dd310a6948e094be6 By using jose4j // be sure you do not have any EOL at the end of the token String accesToken = ?; accesToken = accesToken.replaceAll("\r\n", ""); accesToken = accesToken.replaceAll("\n", ""); JsonWebSignature jws = new JsonWebSignature(); jws.setCompactSerialization(accesToken); jws.setKey(publicKey); boolean signatureVerified = jws.verifySignature(); To get a PublicKey : if you put the content of the realm public you get from keycloak admin public PublicKey getPublicKey(String fileName) { File f = new File(fileName); try (FileInputStream fis = new FileInputStream(f); DataInputStream dis = new DataInputStream(fis);) { byte[] keyBytes = new byte[(int) f.length()]; dis.readFully(keyBytes); dis.close(); // convert to der format String pem = new String(keyBytes); pem = pem.replaceAll("-----BEGIN (.*)-----", ""); pem = pem.replaceAll("-----END (.*)----", ""); pem = pem.replaceAll("\r\n", ""); pem = pem.replaceAll("\n", ""); byte[] der = Base64.getDecoder().decode(pem); // java 8 X509EncodedKeySpec spec = new X509EncodedKeySpec(der); KeyFactory kf = KeyFactory.getInstance(RSA); return kf.generatePublic(spec); } catch (IOException | InvalidKeySpecException | NoSuchAlgorithmException e) { throw new RuntimeException("Failed to load public key from file '" + fileName + "'", e); } } With Java 8, it is quite simple too String[] tokenParts = accessToken.split("\\."); // detect algo from tokenParts[0] or put "SHA256withRSA? (for ?RS256?) String jwtSignAlgo = "SHA256withRSA"; String jwtInputString = tokenParts[0] + ?.? + tokenParts[1]; String jwtDecodedSign = new String(Base64.getUrlDecoder().decode(tokenParts[2]); Signature verifier = Signature.getInstance(jwtSignAlgo); verifier.initVerify(publicKey); verifier.update(jwtInputString.getBytes("UTF-8")); boolean signatureVerified = verifier.verify(jwtDecodedSign); gerard From: keycloak-user-bounces at lists.jboss.org [mailto:keycloak-user-bounces at lists.jboss.org] On Behalf Of Stian Thorgersen Sent: vendredi 6 mai 2016 07:33 To: Aikeaguinea Cc: keycloak-user Subject: Re: [keycloak-user] Validating JWT tokens On 4 May 2016 at 18:37, Aikeaguinea > wrote: Figured it out, kinda. I have to use the Realm public key, and at least in jwt.io it has to begin with "-----BEGIN PUBLIC KEY-----" and end with "-----END PUBLIC KEY-----" -- these can't be omitted. If I try using the Realm certificate, it won't work, however, whether or not I use "-----BEGIN CERTIFICATE-----"/"-----END CERTIFICATE-----". If I use the validator at http://kjur.github.io/jsjws/tool_jwt.html and select "default X509 Certificate (RSA z4) it tells me "Error: malformed X.509 certificate PEM (code:003)" I can use the Realm public key for validating the JWT, but shouldn't the certificate work as well? The certificate is only used by SAML, so no you can't verify the JWT with the certificate only the public key. On Wed, May 4, 2016, at 12:00 PM, Aikeaguinea wrote: > I have a client with a service account and credentials using Signed Jwt. > Authentication works fine. The service uses > org.keycloak.adapters.authentication.ClientCredentialsProviderUtils#setClientCredentials > to create the JWT token and set the headers, and I get back a JWT > containing an access token from Keycloak. > > However, when I use jwt.io to look at the access token, I can't validate > the signature. This is true whether I use the client Certificate (from > the client's Credentials tab), the Realm public key, or the Realm > Certificate. In addition, I have generated the client's public key from > the certificate using > > keytool -exportcert -alias x -keypass y -storepass z -rfc -keystore > client-keystore.jks | openssl x509 -inform pem -pubkey > > on the jks file supplied when I generated the client credentials, and > that doesn't work either. > > We've also been having trouble validating the signature programmatically > using Java. > > Any idea why I might be seeing this? > > -- > http://www.fastmail.com - Or how I learned to stop worrying and > love email again > -- Aikeaguinea aikeaguinea at xsmail.com -- http://www.fastmail.com - Send your email first class _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160520/4ce56967/attachment-0001.html From cmoullia at redhat.com Fri May 20 13:14:37 2016 From: cmoullia at redhat.com (Charles Moulliard) Date: Fri, 20 May 2016 19:14:37 +0200 Subject: [keycloak-user] Redirect_url is not supported anymore since 1.9.4.Final Message-ID: Hi I have configured Openshift + Keycloak as Identity Provider This request which was working with version 1.9.2.Final https://192.168.1.80:8443/auth/realms/openshift/protocol/openid-connect/auth?client_id=openshift&redirect_uri=https%3A%2F%2F192.168.99.100%3A8443%2Foauth2callback%2Fkeycloak&response_type=code&scope=openid&state=Y3NyZj0xYjlkZmRmZC0xZWFkLTExZTYtYjNiYS0zYTQ5MGQxNGNhOGImdGhlbj0lMkZvYXV0aCUyRmF1dGhvcml6ZSUzRmNsaWVudF9pZCUzRG9wZW5zaGlmdC13ZWItY29uc29sZSUyNnJlc3BvbnNlX3R5cGUlM0R0b2tlbiUyNnN0YXRlJTNEJTI1MkYlMjZyZWRpcmVjdF91cmklM0RodHRwcyUyNTNBJTI1MkYlMjUyRjE5Mi4xNjguOTkuMTAwJTI1M0E4NDQzJTI1MkZjb25zb2xlJTI1MkZvYXV0aA%3D%3D doesn't work anymore with 1.9.4.Final --> Invalid parameter: redirect_uri is displayed within the web browser The server reports this error : 19:09:34,964 WARN [org.keycloak.events] (default task-5) type=LOGIN_ERROR, realmId=openshift, clientId=openshift, userId=null, ipAddress=192.168.1.80, error=invalid_redirect_uri, response_type=code, redirect_uri= https://192.168.99.100:8443/oauth2callback/keycloak, response_mode=query Do we have to change something within the config (clientId, ...) ? Regards, Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160520/d65a946f/attachment.html From cmoullia at redhat.com Fri May 20 13:19:26 2016 From: cmoullia at redhat.com (Charles Moulliard) Date: Fri, 20 May 2016 19:19:26 +0200 Subject: [keycloak-user] Redirect_url is not supported anymore since 1.9.4.Final In-Reply-To: References: Message-ID: Problem resolved : the Valid Redirect Url wasn'( correct Bad : https://192.168.99.100/* Good https://192.168.99.100:8443/* On Fri, May 20, 2016 at 7:14 PM, Charles Moulliard wrote: > Hi > > I have configured Openshift + Keycloak as Identity Provider > > This request which was working with version 1.9.2.Final > > > https://192.168.1.80:8443/auth/realms/openshift/protocol/openid-connect/auth?client_id=openshift&redirect_uri=https%3A%2F%2F192.168.99.100%3A8443%2Foauth2callback%2Fkeycloak&response_type=code&scope=openid&state=Y3NyZj0xYjlkZmRmZC0xZWFkLTExZTYtYjNiYS0zYTQ5MGQxNGNhOGImdGhlbj0lMkZvYXV0aCUyRmF1dGhvcml6ZSUzRmNsaWVudF9pZCUzRG9wZW5zaGlmdC13ZWItY29uc29sZSUyNnJlc3BvbnNlX3R5cGUlM0R0b2tlbiUyNnN0YXRlJTNEJTI1MkYlMjZyZWRpcmVjdF91cmklM0RodHRwcyUyNTNBJTI1MkYlMjUyRjE5Mi4xNjguOTkuMTAwJTI1M0E4NDQzJTI1MkZjb25zb2xlJTI1MkZvYXV0aA%3D%3D > > doesn't work anymore with 1.9.4.Final --> Invalid parameter: redirect_uri > is displayed within the web browser > > The server reports this error : > > 19:09:34,964 WARN [org.keycloak.events] (default task-5) > type=LOGIN_ERROR, realmId=openshift, clientId=openshift, userId=null, > ipAddress=192.168.1.80, error=invalid_redirect_uri, response_type=code, > redirect_uri=https://192.168.99.100:8443/oauth2callback/keycloak, > response_mode=query > > Do we have to change something within the config (clientId, ...) ? > > Regards, > > Charles > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160520/7dc80940/attachment.html From jessec at stytch.com Fri May 20 13:42:13 2016 From: jessec at stytch.com (Jesse Chahal) Date: Fri, 20 May 2016 10:42:13 -0700 Subject: [keycloak-user] Schedule background jobs as user In-Reply-To: References: Message-ID: Thanks for the info, looks like I was on the right path. After reading through the OpenID spec I came across offline tokens and saw that it was supported by keycloak. I was trying to figure out how to use offline tokens with the adapter (since it didn't seem possible to set a flag to enable the scope for this) but based on the above it isn't possible. Is it possible for a client to request an offline token using a refresh or access token? The reason I ask is because we cannot request it using the adapter system that we are currently using. Even if we could with the adapter system that would mean that for every single login we would be requesting a offline token instead of a refresh token (seems like a bad idea). It also seems like a good idea to only request the offline_token if a user decides to schedule a offline job with us. We would prefer not having to have the user login again in order to schedule an offline job. I did some initial tests using a rest client and it did not seem possible. On Thu, May 19, 2016 at 10:34 PM, Stian Thorgersen wrote: > This is exactly what offline tokens where created to do. The offline token > is not linked to user sessions so it doesn't matter if users login or not. > Our adapters doesn't support it properly though so you'd need to create a > filter or something that sets up the context and principle based on the > offline token. > > On 19 May 2016 at 19:56, Jesse Chahal wrote: >> >> So we've done a lot of work on our migration to keycloak but still >> have a few holes that are using another authentication system. We are >> using Wildfly10 along with the keycloak subsystem. The last real >> blocking issues is trying to schedule background tasks on behalf of a >> user using quartz. We've tried using impersonation role and mocking >> out the impersonation workflow that a browser does, it was fairly >> complicated and did not work very well. Service accounts don't seem to >> fit this scenario either as service accounts seem to be for performing >> client specific actions. We considered storing offline token's on >> behalf of users but the thing is users might not log in for years >> after scheduling their job. We need to set the Context and Principle >> to be the user who we are performing background tasks on behalf of. Is >> there a recommended way of doing this that has been tested by others? >> I'm sure we aren't the only company who schedule tasks on behalf of >> users. >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > From srossillo at smartling.com Fri May 20 13:43:07 2016 From: srossillo at smartling.com (Scott Rossillo) Date: Fri, 20 May 2016 13:43:07 -0400 Subject: [keycloak-user] How to apply updates to keycloak instances In-Reply-To: References: Message-ID: <87CBA013-76D9-4A1D-B64D-70FF432D8720@smartling.com> We?re using Keycloak on production, stage/QA, development environments and every developer?s workstation / laptop. While there will always be differing options on how to successfully do change management, we?ve found a very effective method for handling Keycloak provisioning in all environments so that developers don?t need to mess around with. We?re a continuous integration / deployment shop using micro services and everything has to ?just work? ? I?ll give an overview of our process here but please keep in mind a few things: 1. This approach works for us, I?m not saying it?s the best way 2. We do _not_ allow production config changes to be automated due to security implications 3. We're very opinionated in our approach to configuration management and we don?t ever modify 3rd party software databases directly. We always use APIs. We deploy Keycloak to all environments using Docker images. On developer workstations we use Docker Compose to orchestrate bringing up all services a developer may need, including Keycloak. We have 4 docker images for Keycloak: - Keycloak Base \- Keycloak HA \- Keycloak Dev - Keycloak config manager* The base image includes all customizations necessary to bring up a Keycloak instance configured with our modules and themes installed. The HA instance builds off base and configures Keycloak to run as a cluster node. This is used on stage and prod. The dev instance builds off base and includes our realm file. On startup, this instance loads our realm configuration if it?s not already loaded. All docker images are built and published by the CI server and Keycloak HA can be deployed to stage and prod after a clean CI build. Developers are free to add clients for testing, do whatever they want, etc. to their running dev instance. If they want to get back to our stock build, they pull the latest Docker image from our private Docker repo and restart it. Adding clients to stage and prod requires approval and is done by a hand. This is for security reasons. Once a configuration change is detected on stage - say a client is added - our CI server exports the realm from stage, changes the realm keys, and creates a new Keycloak Dev instance with the updated realm file. *A word about configuration management: Obviously, the realm file we generate knows the URLs of staging services, not local or development environment URLs. To overcome this we introduced another Docker based service called the Keycloak configuration manger. It runs on development environments and workstations. It?s responsible for discovering running services and updating Keycloak via its admin endpoints to reflect the proper configuration for the given environment. That?s it. The whole process is automated with the exception of configuration changes to stage and prod which require a security review. Hope this helps. Let me know if you?d like me to elaborate on anything. Best, Scott Scott Rossillo Smartling | Senior Software Engineer srossillo at smartling.com > On May 20, 2016, at 1:46 AM, Stian Thorgersen wrote: > > Firstly, just wanted to highlight that core Keycloak team are devs, not sysadmins/ops guys, so we have limited experience in continuous delivery and maintenance of real production systems. Hence, we'd love input from the community on this. > > As it stands we don't really have a proper solution. I believe the best you can do at the moment is either using import feature, partial import or admin rest endpoints. Import is not going to work IMO as it requires re-creating the whole realm. Partial import may work, but would work best for new resources rather than modifying existing resources as it does a delete/create operation rather than attempt to modify. With the admin rest endpoints you'd get the best control of what's going on, but obviously that leaves a fair amount of the work. > > In the future we have an idea of introducing an "import directory" it would be possible to drop json files in here that would add, modify or delete resources (realms, clients, roles, users, whatever). This would allow dropping json files before the server starts and the server would then import on startup. It would also be possible to do this at runtime and new files would be detected at runtime. Finally, we also had an idea of an offline mode to run import of this (it would basically start the server without http listener, import files, then stop, so it could be used in a script/tool). Import is probably not the best name for it, as it would support modify and delete as well as "importing" new things. > > On 19 May 2016 at 19:53, Jesse Chahal > wrote: > Following some of the best practices for continuous Integration and > continuous delivery there needs to be environments for build, test, > and production. This would mean that following these practices would > require you to have multiple versions of keycloak at different stages > of development cycle. Some of these environments might not have > important persistent data while others might. In order to have builds > transition from one environment to another there may be configuration > changes required for a build to be valid. This is especially true when > new services (openid clients) are being added or "default" accounts. > I'm trying to come up with a scripted way of updating keycloak > instances that are backed up by an RDMS. This may include adding new > clients, adding new users, updating realm config, etc... Originally I > was planning on simply exporting the realm config and importing it > every time keycloak starts. If I enabled the OVERWRITE option I might > overwrite things that I do not want overridden. This is especially > true if there is some config that differ's based on whether it is a > build, test, or production instance. If I don't enable it then it is > only useful for new/blank keycloak environments. I considered using > liquibase but since I do not have control of schema changes created by > the keycloak team I might run into issues with my liquibase file not > being valid after a migration/liquibase update by the keycloak team as > my liquibase file would run after keycloak's does. There might also be > some other unknown issues our liquibase changes conflicting somehow > with keycloak's liquibase changes. I've also considered writing my own > updater tool using a scripting language (python/ruby) that calls > keycloak's rest api. The issues with this mechanism is it feels like I > am recreating the wheel as well as not being able to find good > documentation on keycloak's openid endpoints/url's used for different > oauth2 flows. Even if I did find this documentation it would also > require me to find a good openid client for the scripting language. > This doesn't matter for our normal clients as they simply use the > keycloak subsystems and adapters instead. I've also looked at commonly > used server configuration software such as chef, puppet, and ansible. > I don't see a good solution using any of those tools yet either. What > have other people done for cases like this? Please don't tell me there > is someone who is doing this all manually because that doesn't work in > modern software development. > > - doesn't accidentally delete users > - doesn't accidentally delete clients > - doesn't invalidate sessions (optional) > - works to bring up new, correctly configured, keycloak instances > - handles applying updates to existing keycloak instances > - can handle minor differences between keycloak instances (build, > test, production) when updating > - preferably can work well in rolling deployment scenario's. > -- I hope the keycloak team is taking these into consideration when > doing database migration between 1-2 releases. It would be nice if > they set some specific rules for rolling updates between versions (aka > backwards breaking changes) > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160520/a2618e24/attachment-0001.html From bruno at abstractj.org Fri May 20 15:17:36 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 20 May 2016 16:17:36 -0300 Subject: [keycloak-user] upgrade to 1.9.3 "Property "databaseSchema" needs to be specified error (but it is) In-Reply-To: References: Message-ID: <20160520191736.GA7117@abstractj.org> It looks correct, are you migrating from which version of KC? On 2016-05-02, Dean Peterson wrote: > I get this error when migrating my database and upgrading to 1.9.3: > "Property 'databaseSchema' needs to be specified in the configuration > > I have this in my keycloak-server.json file: > > "connectionsMongo": { > "default": { > "host": "xx.xx.xx.xx", > "port": "27017", > "db": "keycloaktest", > "databaseSchema": "update" > } > } > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -- abstractj PGP: 0x84DC9914 From leo.nunes at gjccorp.com.br Fri May 20 16:58:30 2016 From: leo.nunes at gjccorp.com.br (LEONARDO NUNES) Date: Fri, 20 May 2016 20:58:30 +0000 Subject: [keycloak-user] Jetty Maven Plugin Message-ID: Hi, is it possible to configure Keycloak to run with Jetty Maven Plugin? Have anyone done this? I didn't find an equivalent way to do the steps below at the pom file. java -jar $JETTY_HOME/start.jar --add-to-startd=keycloak or OPTIONS=Server,jsp,jmx,resources,websocket,ext,plus,annotations,keycloak I was able to configure Keycloak to run with Tomcat Maven Plugin. If anyone needs help with that, let me know. -- Leonardo ________________________________ Esta mensagem pode conter informa??o confidencial e/ou privilegiada. Se voc? n?o for o destinat?rio ou a pessoa autorizada a receber esta mensagem, n?o poder? usar, copiar ou divulgar as informa??es nela contidas ou tomar qualquer a??o baseada nessas informa??es. Se voc? recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua coopera??o. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160520/9253017c/attachment.html From palermo at pobox.com Fri May 20 19:24:44 2016 From: palermo at pobox.com (Bruno Palermo) Date: Fri, 20 May 2016 20:24:44 -0300 Subject: [keycloak-user] Terms and Conditions Message-ID: Hi, It's possible to link directly to the terms and conditions page? What's the URL? In case there's an update to terms, is possible to add the required action to accept the terms again to all users? Thanks, Bruno -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160520/233e7245/attachment.html From darrell at 1placeonline.com Fri May 20 23:15:41 2016 From: darrell at 1placeonline.com (Darrell Wu) Date: Sat, 21 May 2016 15:15:41 +1200 Subject: [keycloak-user] How to include the keycloak wildfly adapter libraries in the secure war application classpath? In-Reply-To: <20160520125140.GA29687@abstractj.org> References: <20160520101013.GA24124@abstractj.org> <20160520125140.GA29687@abstractj.org> Message-ID: I'm not using the saml client adapters, i'm using the jboss/wildfly adapter as mention here http://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#jboss-adapter I have the following in my wildfly 10 standalone.xml file under entensions under security subsystem under the keycloak subsystem i have secure my application 1Place 1Place-reporting xxxxxxxxKey removedxxxxxxxxxxx http://localhost:8180/ EXTERNAL xxxxxxxxKey removedxxxxxxxxxxx The reporting-server-rest.war is in an EAR archive with an ejb jar. The code with the exception is a stateless session bean(OperatorService ) in the ejb jar. It is called by a produces method public class CurrentUserProducer { @Inject OperatorService operatorService; @LoggedInUser @Produces public CurrentUser produceCurrentUser() { return operatorService.getCurrentUser(); } } The OperatorService stateless session bean getCurrentUser method looks like the following. The exception is occurring on the first line @Inject private HttpServletRequest httpRequest; public CurrentUser getCurrentUser(){ KeycloakSecurityContext securityContext = (KeycloakSecurityContext) httpRequest.getAttribute(KeycloakSecurityContext.class.getName()); a filter in the reporting-server-rest.war archive is injecting the CurrentUser like so @WebFilter(dispatcherTypes = {DispatcherType.REQUEST, DispatcherType.FORWARD}, urlPatterns = {"/*"}) public class CurrentUserFilter implements Filter { @Inject @LoggedInUser private CurrentUser currentUser; I'm getting the following exception in the log 14:26:38,444 ERROR [io.undertow.request] (default task-10) UT005023: Exception handling request to /reporting-server-rest/widgets/checklistQuestion: javax.servlet.ServletException: UT010013: Could not instantiate com.one placeonline.rest.CurrentUserFilter at io.undertow.servlet.core.ManagedFilter.createFilter(ManagedFilter.java:76) at io.undertow.servlet.core.ManagedFilter.getFilter(ManagedFilter.java:65) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.keycloak.adapters.undertow.UndertowAuthenticatedActionsHandler.handleRequest(UndertowAuthenticatedActionsHandler.java:66) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.jrHandle(ServletInitialHandler.java) at org.zeroturnaround.javarebel.integration.servlet.undertow.cbp.ServletInitialHandlerCBP.handleRequest(ServletInitialHandlerCBP.java:100) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163) at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134) at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88) at org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReferenceFactory.getReference(ComponentRegistry.java:149) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$6.createInstance(UndertowDeploymentInfoService.java:1366) at io.undertow.servlet.core.ManagedFilter.createFilter(ManagedFilter.java:74) ... 37 more Caused by: javax.ejb.EJBException: WFLYEJB0442: Unexpected Error at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:184) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195) at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) at com.oneplaceonline.business.users.boundary.OperatorService$$$view14.getCurrentUser(Unknown Source) at sun.reflect.GeneratedMethodAccessor89.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:436) at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127) at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) at org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:67) at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) at com.oneplaceonline.business.users.boundary.OperatorService$Proxy$_$$_Weld$EnterpriseProxy$.getCurrentUser(Unknown Source) at com.oneplaceonline.business.users.boundary.CurrentUserProducer.produceCurrentUser(CurrentUserProducer.java:17) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) at org.jboss.weld.injection.producer.ProducerMethodProducer.produce(ProducerMethodProducer.java:99) at org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:161) at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:181) at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:70) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742) at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:842) at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92) at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:378) at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:389) at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:71) at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:73) at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121) at org.jboss.as.weld.injection.WeldInjectionContext.inject(WeldInjectionContext.java:39) at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:51) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161) ... 42 more Caused by: java.lang.NoClassDefFoundError: org/keycloak/KeycloakSecurityContext at com.oneplaceonline.business.users.boundary.OperatorService.getCurrentUser(OperatorService.java:81) at sun.reflect.GeneratedMethodAccessor89.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64) at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) ... 124 more Does it have anything to do with the change in 1.9.0 http://keycloak.github.io/docs/userguide/keycloak-server/html/Migration_from_older_versions.html#d4e4103 under 35.6.3. Migrating to 1.9.0Adapter Subsystems only bring in dependencies if keycloak is on Previously, if you had installed our saml or oidc keycloak subsystem adapters into Wildfly or JBoss EAP, we would automatically include Keycloak client jars into EVERY application irregardless if you were using Keycloak or not. These libraries are now only added to your deployment if you have keycloak authentication turned on for that adapter (via the subsystem, or auth-method in web.xml Mind you i'm not using saml or oidc adapter On 21 May 2016 at 00:51, Bruno Oliveira wrote: > Do you have the security domain specified like described here: > > http://keycloak.github.io/docs/userguide/saml-client-adapter/html/jboss-adapter.html > > If possible send some steps to reproduce or the code snippet. > > > On 2016-05-20, Darrell Wu wrote: > > If it helps I'm using wildfly 10 and have keycloak on a standalone > server. > > The authenication works. It just when my app tries to read the security > > context I get the class not found exception. > > > > So what triggers wildfly to include the keycloak modules in my apps class > > path? > > On 20/05/2016 10:10 pm, "Bruno Oliveira" wrote: > > > > > Weird because it was fixed here: > > > https://issues.jboss.org/browse/KEYCLOAK-2483. Plus, I tested > > > on WildFly 9.0.2.Final with Keycloak adapter 1.9.4.Final and couldn't > > > reproduce the issue. > > > > > > On 2016-05-20, Darrell Wu wrote: > > > > Hi, > > > > > > > > With the keycloak wildfly adapter for version 1.9.x i've noticed > that the > > > > location of the Keycloak Subsystem modules have changed from > > > > modules\system\layers\base\org\keycloak to > > > > modules\system\add-ons\keycloak\org\keycloak > > > > > > > > Now on my secure war application server I've installed the keycloak > > > wildfly > > > > adpater by unzipping the archive and running the adapter-install.cl > > > script. > > > > > > > > Now In my application i'm getting a > > > > ClassNotFoundException: org.keycloak.KeycloakSecurityContext > > > > > > > > when the following is executed > > > > > > > > KeycloakSecurityContext securityContext = (KeycloakSecurityContext) > > > > httpRequest.getAttribute(KeycloakSecurityContext.class.getName()); > > > > > > > > Obviously the application isn't loading the keycloak modules in the > > > > classpath. > > > > What is the proper way to include the keycloak libraries in my app? > > > > > > > > Should my app have a jboss-deployment-structure.xml file or should > the > > > > libraries be moved back to modules\system\layers\base\org\keycloak? > > > > > > > > Thanks > > > > > > > > > > > > > > > > -- > > > > Darrell Wu > > > > 1Place Limited > > > > P.O. Box 125152, St Heliers, Auckland 1740, New Zealand > > > > Level 4, 1 Queen Street, Auckland 1010, New Zealand > > > > Phone: +64 9 5200612 ext 521 | Mob: +64 21 262 4898 | Fax: +64 9 > 5246203 > > > > Email: darrell at 1placeonline.com | Web: www.1placeonline.com > > > > > > > _______________________________________________ > > > > keycloak-user mailing list > > > > keycloak-user at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > > > -- > > > > > > abstractj > > > PGP: 0x84DC9914 > > > > > -- > > abstractj > PGP: 0x84DC9914 > -- Darrell Wu 1Place Limited P.O. Box 125152, St Heliers, Auckland 1740, New Zealand Level 4, 1 Queen Street, Auckland 1010, New Zealand Phone: +64 9 5200612 ext 521 | Mob: +64 21 262 4898 | Fax: +64 9 5246203 Email: darrell at 1placeonline.com | Web: www.1placeonline.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160521/db4d1dda/attachment-0001.html From dev at sgordon.totalise.co.uk Sat May 21 05:07:54 2016 From: dev at sgordon.totalise.co.uk (Simon Gordon) Date: 21 May 2016 10:07:54 +0100 Subject: [keycloak-user] custom federation/authentication Message-ID: Hello Looking for some guidance please - let's say that we want to authenticate users against an external authenticator (e.g. RADIUS server, or a custom REST API) and at the time of login, the user does not necessarily have a profile/account within keycloak. My initial scan suggests that we just need to create an Authenticator Provider - but I'm concerned that since the user account does not necessarily exist in KC, I can't see how the Authenticator provider will work. Should I be looking at a userFederation provider instead? Looking at the server-spi module, I'm not seeing the Interface(s) to implement, so any pointers gratefuilly received! Regards, Simon From pkkamos at gmail.com Sat May 21 11:15:24 2016 From: pkkamos at gmail.com (Paa Kojo Konduah Amos) Date: Sat, 21 May 2016 15:15:24 -0000 Subject: [keycloak-user] Starting Keycloak as a Service(Windows and Linux) Message-ID: <04bf01d1b373$9a917550$cfb45ff0$@gmail.com> Hello All, How do I start Keycloak as a service on Windows and Linux? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160521/829e420f/attachment.html From haimv at perfectomobile.com Sat May 21 15:33:50 2016 From: haimv at perfectomobile.com (Haim Vana) Date: Sat, 21 May 2016 19:33:50 +0000 Subject: [keycloak-user] KeyCloak offline tokens and architecture In-Reply-To: References: Message-ID: Hi, We are evaluating KeyCloak to be our SSO server, and we have a few questions regarding the offline token usage. First our high level use case is as follows: We have multi-tenancy applications, each tenant will have its own realm (which means the same clients will be defined for each realm). One of the applications has 3 authentication scenarios: 1. User using SDK flow to access the application (by code) 2. Offline job 3. External micro service (not registered in KeyCloak) that needs to access our application micro service 4. UI login We thought to use offline token for the first three, and define a single client for UI and micro services. Does our approach make sense ? specially regarding the realm per tenant and the fact that we will have to create the same clients for each realm, The offline token usage for the authentication flows, and the single client for the UI and micro service. Regarding the offline tokens - why are they per client ? is it mean that when using the client offline token (and getting the real token from KeyCloak) we will not be able to use it for other client (within the realm) micro service ? Also how can we generate them for each of the following cases (also described above): 1. User - should manually add the token to his code, so we thought to provide it within the application, however how can we generate the offline token to already logged in user ? we would like to avoid generating the offline token to all users and to use separate offline login page. 2. Offline job - the offline job which is cross realms will use special operator realm, the token will be generated manually by the admin which will stored it in the file system for the offline job usage, how can the admin generate this token ? can it be done in the admin console ? if not I guess we will have to create a service that logs him to the application and generate the token, is there an alternative ? 3. Micro service - it's very similar flow to the offline job only that the admin will have to create offline token per realm. I hope it's not too much [https://issues.jboss.org/images/icons/emoticons/smile.png] and any advice will be highly appreciated. Thanks, Haim. The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160521/9e48db87/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 752 bytes Desc: image001.png Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160521/9e48db87/attachment.png From christian.bauer at gmail.com Sat May 21 17:59:10 2016 From: christian.bauer at gmail.com (Christian Bauer) Date: Sat, 21 May 2016 23:59:10 +0200 Subject: [keycloak-user] Reverse proxy calling admin API Message-ID: Hi I'm trying to call the /admin/* API endpoints through a reverse proxy. The access token is granted to a JavaScript application, and the issuer of the token is therefore the reverse proxy. (This is actually a regular app that just happens to forward/create some requests to Keycloak.) The proxy makes a call to Keycloak with a Bearer token and the correct X-Forwarded-* headers. Keycloak/Wildfly is configured with proxy-address-forwarding=true. The request is authenticated in Keycloak with this line in AuthenticationManager.java: AccessToken token = RSATokenVerifier.verifyToken(tokenString, realm.getPublicKey(), Urls.realmIssuer(uriInfo.getBaseUri(), realm.getName()), checkActive, checkTokenType); This assumes that the "configured issuer" of a token is the JAX-RS UriInfo#getBaseUri() and fails with: 2016-05-21 23:52:37,109 DEBUG [org.keycloak.services] (default task-16) Failed to verify identity token: org.keycloak.common.VerificationException: Token audience doesn't match domain. Token issuer is http://localhost:8080/auth/realms/master, but URL from configuration is http://192.168.99.100:8081/auth/realms/master The UriInfo#getBaseUri() does not take the X-Forwarded-* headers into account. How can I call the API with a token obtained through a reverse proxy? Thanks, Christian From bburke at redhat.com Sat May 21 18:10:56 2016 From: bburke at redhat.com (Bill Burke) Date: Sat, 21 May 2016 18:10:56 -0400 Subject: [keycloak-user] Reverse proxy calling admin API In-Reply-To: References: Message-ID: I think this is a wildfly issue: https://keycloak.gitbooks.io/server-installation-and-configuration/content/topics/clustering/load-balancer.html set the proxy-address-forwarding="true" for the http-listener. On 5/21/16 5:59 PM, Christian Bauer wrote: > Hi > > I'm trying to call the /admin/* API endpoints through a reverse proxy. The access token is granted to a JavaScript application, and the issuer of the token is therefore the reverse proxy. (This is actually a regular app that just happens to forward/create some requests to Keycloak.) > > The proxy makes a call to Keycloak with a Bearer token and the correct X-Forwarded-* headers. Keycloak/Wildfly is configured with proxy-address-forwarding=true. > > The request is authenticated in Keycloak with this line in AuthenticationManager.java: > > AccessToken token = RSATokenVerifier.verifyToken(tokenString, realm.getPublicKey(), Urls.realmIssuer(uriInfo.getBaseUri(), realm.getName()), checkActive, checkTokenType); > > This assumes that the "configured issuer" of a token is the JAX-RS UriInfo#getBaseUri() and fails with: > > 2016-05-21 23:52:37,109 DEBUG [org.keycloak.services] (default task-16) Failed to verify identity token: org.keycloak.common.VerificationException: Token audience doesn't match domain. Token issuer is http://localhost:8080/auth/realms/master, but URL from configuration is http://192.168.99.100:8081/auth/realms/master > > The UriInfo#getBaseUri() does not take the X-Forwarded-* headers into account. > > How can I call the API with a token obtained through a reverse proxy? > > Thanks, > Christian > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From christian.bauer at gmail.com Sat May 21 18:18:01 2016 From: christian.bauer at gmail.com (Christian Bauer) Date: Sun, 22 May 2016 00:18:01 +0200 Subject: [keycloak-user] Reverse proxy calling admin API In-Reply-To: References: Message-ID: <8DBA3048-C140-4C5D-851D-E5BDA24108C8@gmail.com> Already done. I don't think that affects HttpServletRequest#getRequestURL(), which is what Resteasy is using to populate UriInfo#getBaseUri()? > set the proxy-address-forwarding="true" for the http-listener. > >> >> The proxy makes a call to Keycloak with a Bearer token and the correct X-Forwarded-* headers. Keycloak/Wildfly is configured with proxy-address-forwarding=true. From anthony.fryer at gmail.com Sat May 21 22:20:51 2016 From: anthony.fryer at gmail.com (Anthony Fryer) Date: Sun, 22 May 2016 12:20:51 +1000 Subject: [keycloak-user] How to apply updates to keycloak instances In-Reply-To: <87CBA013-76D9-4A1D-B64D-70FF432D8720@smartling.com> References: <87CBA013-76D9-4A1D-B64D-70FF432D8720@smartling.com> Message-ID: Hi Scott, How do you generate the realm keys when creating the new keycloak dev instances? Do you use a keycloak api or some other way? I'm interested in having a standard realm template that is used to create new realms but would need to change the realm keys when importing this template into keycloak. Cheers, Anthony On Sat, May 21, 2016 at 3:43 AM, Scott Rossillo wrote: > We?re using Keycloak on production, stage/QA, development environments and > every developer?s workstation / laptop. > > While there will always be differing options on how to successfully do > change management, we?ve found a very effective method for handling > Keycloak provisioning in all environments so that developers don?t need to > mess around with. We?re a continuous integration / deployment shop using > micro services and everything has to ?just work? ? I?ll give an overview of > our process here but please keep in mind a few things: > > 1. This approach works for us, I?m not saying it?s the best way > 2. We do _not_ allow production config changes to be automated due to > security implications > 3. We're very opinionated in our approach to configuration management and > we don?t ever modify 3rd party software databases directly. We always use > APIs. > > We deploy Keycloak to all environments using Docker images. On developer > workstations we use Docker Compose to orchestrate bringing up all services > a developer may need, including Keycloak. > > We have 4 docker images for Keycloak: > - Keycloak Base > \- Keycloak HA > \- Keycloak Dev > - Keycloak config manager* > > The base image includes all customizations necessary to bring up a > Keycloak instance configured with our modules and themes installed. > The HA instance builds off base and configures Keycloak to run as a > cluster node. This is used on stage and prod. > The dev instance builds off base and includes our realm file. On startup, > this instance loads our realm configuration if it?s not already loaded. > > All docker images are built and published by the CI server and Keycloak HA > can be deployed to stage and prod after a clean CI build. > > Developers are free to add clients for testing, do whatever they want, > etc. to their running dev instance. If they want to get back to our stock > build, they pull the latest Docker image from our private Docker repo and > restart it. > > Adding clients to stage and prod requires approval and is done by a hand. > This is for security reasons. Once a configuration change is detected on > stage - say a client is added - our CI server exports the realm from stage, > changes the realm keys, and creates a new Keycloak Dev instance with the > updated realm file. > > *A word about configuration management: > > Obviously, the realm file we generate knows the URLs of staging services, > not local or development environment URLs. To overcome this we introduced > another Docker based service called the Keycloak configuration manger. It > runs on development environments and workstations. It?s responsible for > discovering running services and updating Keycloak via its admin endpoints > to reflect the proper configuration for the given environment. > > That?s it. The whole process is automated with the exception of > configuration changes to stage and prod which require a security review. > > Hope this helps. Let me know if you?d like me to elaborate on anything. > > Best, > Scott > > Scott Rossillo > Smartling | Senior Software Engineer > srossillo at smartling.com > > On May 20, 2016, at 1:46 AM, Stian Thorgersen wrote: > > Firstly, just wanted to highlight that core Keycloak team are devs, not > sysadmins/ops guys, so we have limited experience in continuous delivery > and maintenance of real production systems. Hence, we'd love input from the > community on this. > > As it stands we don't really have a proper solution. I believe the best > you can do at the moment is either using import feature, partial import or > admin rest endpoints. Import is not going to work IMO as it requires > re-creating the whole realm. Partial import may work, but would work best > for new resources rather than modifying existing resources as it does a > delete/create operation rather than attempt to modify. With the admin rest > endpoints you'd get the best control of what's going on, but obviously that > leaves a fair amount of the work. > > In the future we have an idea of introducing an "import directory" it > would be possible to drop json files in here that would add, modify or > delete resources (realms, clients, roles, users, whatever). This would > allow dropping json files before the server starts and the server would > then import on startup. It would also be possible to do this at runtime and > new files would be detected at runtime. Finally, we also had an idea of an > offline mode to run import of this (it would basically start the server > without http listener, import files, then stop, so it could be used in a > script/tool). Import is probably not the best name for it, as it would > support modify and delete as well as "importing" new things. > > On 19 May 2016 at 19:53, Jesse Chahal wrote: > >> Following some of the best practices for continuous Integration and >> continuous delivery there needs to be environments for build, test, >> and production. This would mean that following these practices would >> require you to have multiple versions of keycloak at different stages >> of development cycle. Some of these environments might not have >> important persistent data while others might. In order to have builds >> transition from one environment to another there may be configuration >> changes required for a build to be valid. This is especially true when >> new services (openid clients) are being added or "default" accounts. >> I'm trying to come up with a scripted way of updating keycloak >> instances that are backed up by an RDMS. This may include adding new >> clients, adding new users, updating realm config, etc... Originally I >> was planning on simply exporting the realm config and importing it >> every time keycloak starts. If I enabled the OVERWRITE option I might >> overwrite things that I do not want overridden. This is especially >> true if there is some config that differ's based on whether it is a >> build, test, or production instance. If I don't enable it then it is >> only useful for new/blank keycloak environments. I considered using >> liquibase but since I do not have control of schema changes created by >> the keycloak team I might run into issues with my liquibase file not >> being valid after a migration/liquibase update by the keycloak team as >> my liquibase file would run after keycloak's does. There might also be >> some other unknown issues our liquibase changes conflicting somehow >> with keycloak's liquibase changes. I've also considered writing my own >> updater tool using a scripting language (python/ruby) that calls >> keycloak's rest api. The issues with this mechanism is it feels like I >> am recreating the wheel as well as not being able to find good >> documentation on keycloak's openid endpoints/url's used for different >> oauth2 flows. Even if I did find this documentation it would also >> require me to find a good openid client for the scripting language. >> This doesn't matter for our normal clients as they simply use the >> keycloak subsystems and adapters instead. I've also looked at commonly >> used server configuration software such as chef, puppet, and ansible. >> I don't see a good solution using any of those tools yet either. What >> have other people done for cases like this? Please don't tell me there >> is someone who is doing this all manually because that doesn't work in >> modern software development. >> >> - doesn't accidentally delete users >> - doesn't accidentally delete clients >> - doesn't invalidate sessions (optional) >> - works to bring up new, correctly configured, keycloak instances >> - handles applying updates to existing keycloak instances >> - can handle minor differences between keycloak instances (build, >> test, production) when updating >> - preferably can work well in rolling deployment scenario's. >> -- I hope the keycloak team is taking these into consideration when >> doing database migration between 1-2 releases. It would be nice if >> they set some specific rules for rolling updates between versions (aka >> backwards breaking changes) >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160522/ffdc918a/attachment-0001.html From christian.bauer at gmail.com Sun May 22 04:10:12 2016 From: christian.bauer at gmail.com (Christian Bauer) Date: Sun, 22 May 2016 10:10:12 +0200 Subject: [keycloak-user] Reverse proxy calling admin API In-Reply-To: <8DBA3048-C140-4C5D-851D-E5BDA24108C8@gmail.com> References: <8DBA3048-C140-4C5D-851D-E5BDA24108C8@gmail.com> Message-ID: <9EE9F1DE-8EB0-4BC6-BCC3-C4E56545564E@gmail.com> A workaround/solution is to set the Host header on the proxy. This is equivalent to setting ProxyPreserveHost On if you'd be using Apache mod_proxy. It requires some ugly hacks however customizing this header with my Resteasy/ApacheHttpClient proxy. > On 22.05.2016, at 00:18, Christian Bauer wrote: > > Already done. I don't think that affects HttpServletRequest#getRequestURL(), which is what Resteasy is using to populate UriInfo#getBaseUri()? > >> set the proxy-address-forwarding="true" for the http-listener. >> >>> >>> The proxy makes a call to Keycloak with a Bearer token and the correct X-Forwarded-* headers. Keycloak/Wildfly is configured with proxy-address-forwarding=true. > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From ssilvert at redhat.com Sun May 22 20:25:31 2016 From: ssilvert at redhat.com (Stan Silvert) Date: Sun, 22 May 2016 20:25:31 -0400 Subject: [keycloak-user] Terms and Conditions In-Reply-To: References: Message-ID: <57424DFB.9010200@redhat.com> On 5/20/2016 7:24 PM, Bruno Palermo wrote: > Hi, > > It's possible to link directly to the terms and conditions page? > What's the URL? You could create your own static page, but it doesn't sound like that's what you want. But linking to the middle of a login flow doesn't make much sense either. > In case there's an update to terms, is possible to add the required > action to accept the terms again to all users? This is probably what you want. It should be fairly easy to write a script for adding the required action to all users. Are you familiar with the admin client? It might be a nice addition to the admin UI if we allow you to assign a required action to all users. Something to think about for a 2.x feature. > > Thanks, > Bruno > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160522/234750c4/attachment.html From ssilvert at redhat.com Sun May 22 20:37:33 2016 From: ssilvert at redhat.com (Stan Silvert) Date: Sun, 22 May 2016 20:37:33 -0400 Subject: [keycloak-user] Terms and Conditions In-Reply-To: <57424DFB.9010200@redhat.com> References: <57424DFB.9010200@redhat.com> Message-ID: <574250CD.5000708@redhat.com> On 5/22/2016 8:25 PM, Stan Silvert wrote: > It might be a nice addition to the admin UI if we allow you to assign > a required action to all users. Something to think about for a 2.x > feature. Or not. I'll argue with myself for a moment. It opens up a can of worms I call "mass update". If we did it for one attribute like required actions we would want to do it for other attributes such as roles. While doable, mass update is hard to get right from a usability perspective. We're probably better off improving the usability of the admin client and making it easier to do your own scripting. >> >> Thanks, >> Bruno >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160522/e86d8843/attachment.html From nidhirachora at gmail.com Sun May 22 23:03:55 2016 From: nidhirachora at gmail.com (Nidhi Rachora) Date: Mon, 23 May 2016 13:03:55 +1000 Subject: [keycloak-user] Disabling unique email restriction in Keycloak In-Reply-To: References: Message-ID: Hi Keycloak Team, I am working on migrating an existing application to Keycloak. In the existing application, unique ?member_ids? are used as usernames and the ?email? field can be duplicate. However on logging into Keycloak, members with duplicate emails are not allowed. So I have identified two areas to work on: Task I) Allow members with unique member ids (who may/ maynot have unique email) to login. Task II) Disable login using email. Solution: So as a solution to the first task, in my CustomUserFederation, I have made the following changes: //Code snippet 1 CustomFederationProvider implements UserFederationProvider{ . . @Override public UserModel getUserByUsername(RealmModel realm, String username) { . . if (apiCustomer.getEmailAddresses() != null && apiCustomer.getEmailAddresses().size() > 0) { // Changed to handle duplicate emails using: Sub-addressing, so email: mailid at domain is saved as mailid+member_id at domain userModel.setEmail( subaddress(apiCustomer.getEmailAddresses().get(0).getEmail(), userModel.getMember_id())); } . . } } //Code snippet 2 CustomUserModelDelegate extends UserModelDelegate { . . @Override public String getEmail() { String email = super.getEmail(); try { // Changed to handle duplicate emails using: Sub-addressing, so while retrieving email: mailid+member_id at domain is processed as mailid at domain email = removeSubaddress(email); } catch (Exception e) { ... } return email; } . . } Now my queries are: 1.) Will my solution of sub-addressing the email resolve the first issue without any side-effects? 2.) How do I disable logging in using emails from Keycloak? Regards, Nidhi Rachora -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/9cca2332/attachment.html From sthorger at redhat.com Mon May 23 01:27:42 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 23 May 2016 07:27:42 +0200 Subject: [keycloak-user] Disabling unique email restriction in Keycloak In-Reply-To: References: Message-ID: We've planned to add support for having non-unique email addresses. The idea would be to have an option on a realm to configure if login permits username/email, username or email. The email field on users would still have to have a unique constraint as removing that results in not being able to guarantee email uniqueness. Instead we planned to have contact email address which would be non-unique. You can workaround this though as it's already possible to add custom attributes (to add contact email) and change the email sender so Keycloak supports sending email to contact email attribute if set. On 23 May 2016 at 05:03, Nidhi Rachora wrote: > Hi Keycloak Team, > > I am working on migrating an existing application to Keycloak. In the > existing application, unique ?member_ids? are used as usernames and the > ?email? field can be duplicate. However on logging into Keycloak, members > with duplicate emails are not allowed. So I have identified two areas to > work on: > > Task I) Allow members with unique member ids (who may/ maynot have unique > email) to login. > Task II) Disable login using email. > > Solution: > So as a solution to the first task, in my CustomUserFederation, I have > made the following changes: > > //Code snippet 1 CustomFederationProvider implements > UserFederationProvider{ > . . > @Override > public UserModel getUserByUsername(RealmModel realm, String username) { > . . > if (apiCustomer.getEmailAddresses() != null && > apiCustomer.getEmailAddresses().size() > 0) { > // Changed to handle duplicate emails using: Sub-addressing, so email: > mailid at domain is saved as mailid+member_id at domain > userModel.setEmail( > subaddress(apiCustomer.getEmailAddresses().get(0).getEmail(), > userModel.getMember_id())); > } > . . > } > } > > //Code snippet 2 > CustomUserModelDelegate extends UserModelDelegate { > . . > @Override > public String getEmail() { > String email = super.getEmail(); try { > // Changed to handle duplicate emails using: Sub-addressing, so while > retrieving email: mailid+member_id at domain is processed as mailid at domain > > email = removeSubaddress(email); > } catch (Exception e) { > ... > } > return email; > } > . . > } > > Now my queries are: > > 1.) Will my solution of sub-addressing the email resolve the first issue > without any side-effects? > 2.) How do I disable logging in using emails from Keycloak? > > Regards, > Nidhi Rachora > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/a9c84adb/attachment-0001.html From sthorger at redhat.com Mon May 23 01:56:11 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 23 May 2016 07:56:11 +0200 Subject: [keycloak-user] Terms and Conditions In-Reply-To: <574250CD.5000708@redhat.com> References: <57424DFB.9010200@redhat.com> <574250CD.5000708@redhat.com> Message-ID: On 23 May 2016 at 02:37, Stan Silvert wrote: > On 5/22/2016 8:25 PM, Stan Silvert wrote: > > It might be a nice addition to the admin UI if we allow you to assign a > required action to all users. Something to think about for a 2.x feature. > > Or not. I'll argue with myself for a moment. > > It opens up a can of worms I call "mass update". If we did it for one > attribute like required actions we would want to do it for other attributes > such as roles. While doable, mass update is hard to get right from a > usability perspective. > > We're probably better off improving the usability of the admin client and > making it easier to do your own scripting. > Batch updates to users is a very nice to have ( https://issues.jboss.org/browse/KEYCLOAK-1413), but when we can add it that's a question. It shouldn't be done just for required actions and also it has to be possible to filter what users to add to. > > > Thanks, > Bruno > > > _______________________________________________ > keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > _______________________________________________ > keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/908dc30a/attachment.html From sthorger at redhat.com Mon May 23 02:16:48 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 23 May 2016 08:16:48 +0200 Subject: [keycloak-user] Reverse proxy calling admin API In-Reply-To: <9EE9F1DE-8EB0-4BC6-BCC3-C4E56545564E@gmail.com> References: <8DBA3048-C140-4C5D-851D-E5BDA24108C8@gmail.com> <9EE9F1DE-8EB0-4BC6-BCC3-C4E56545564E@gmail.com> Message-ID: Take a look at http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#proxy-address-forwarding. proxy-address-forwarding=true does set HttpServletRequest#getRequestURL(), but only if http is used. If you're using ajp then you need to use ProxyPeerAddressHandler. On 22 May 2016 at 10:10, Christian Bauer wrote: > A workaround/solution is to set the Host header on the proxy. > > This is equivalent to setting ProxyPreserveHost On if you'd be using > Apache mod_proxy. It requires some ugly hacks however customizing this > header with my Resteasy/ApacheHttpClient proxy. > > > On 22.05.2016, at 00:18, Christian Bauer > wrote: > > > > Already done. I don't think that affects > HttpServletRequest#getRequestURL(), which is what Resteasy is using to > populate UriInfo#getBaseUri()? > > > >> set the proxy-address-forwarding="true" for the http-listener. > >> > >>> > >>> The proxy makes a call to Keycloak with a Bearer token and the correct > X-Forwarded-* headers. Keycloak/Wildfly is configured with > proxy-address-forwarding=true. > > > > > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/e86d28c4/attachment.html From sthorger at redhat.com Mon May 23 02:30:53 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 23 May 2016 08:30:53 +0200 Subject: [keycloak-user] Keycloak OAuth High CPU usage In-Reply-To: References: Message-ID: You are using direct grant to authenticate a user and obtain a token in the example above. This authenticates and creates a new session for each request. Are you not planning on using web based flow? What do you have password hashing intervals set to? Verifying password is CPU intensive, more than signing tokens. It shouldn't matter that user is stored in RedHat IdM as the user would be cached in Keycloak after first authentication, but it may be an idea to just double check by trying to authenticate to a user in Keycloak and not RH IdM. What results are you actually getting? On 20 May 2016 at 11:27, Vaibhav Naldurgkar < vaibhav_naldurgkar at persistent.com> wrote: > Hi Stian, > > > > After reading your tests results of 10000 token refreshes in under 60 > seconds on your laptop, I am sure I am not following correct configuration > and the documents are missing for reference. > > > > Could you please verify the below steps along with the screen-shots for > the steps which I am following for the adding client and testing the Load > performance using Jmeter. Please suggest if any changes are needed in the > client configuration. In this case we are obtaining the token for user from > KeyCloak. > > > > In my case the user have been stored on RedHat IdM which has been > federated using KeyCloak. > > > > > > Step 1. Create new client called ?LoadTest? , use the Client Protocol as > ?Openid-connect?. > > Used all defaults values post save of the client action. > > > > Step 2. Start the load tests using Jmeter and using the path as > *?/auth/realms/master/protocol/openid-connect/token?* . Used 20 Number of > Threads and used Post method. > > > > > > Below is the screen-shot for the step 1 related to Add Client. > > > > > > > > > > Below is the screen shot for the load test using Jmeter. In this case the > Client ID was used as HelloTest. > > > > > > > > Http requests. > > > > > > > > Thanks, Vaibhav > > > > > > *From:* Stian Thorgersen [mailto:sthorger at redhat.com] > *Sent:* Friday, May 20, 2016 1:01 PM > > *To:* Vaibhav Naldurgkar > *Cc:* keycloak-user at lists.jboss.org > *Subject:* Re: [keycloak-user] Keycloak OAuth High CPU usage > > > > Can you please elaborate a bit more on how your are testing scenario is? > I'm a bit confused to what you are testing when you are talking about > generating new tokens. Are you using OIDC or SAML? Are you talking about > code->token exchanges, refresh token requests, or what? > > > > To test if your hardware is capable to deal with the load you need to test > logins (verifying passwords are CPU intensive) as well as obtaining tokens > (both code->token, done after login, and refreshing token, done ~1 min or > so by active users, but most users won't continuously use the application). > > > > 500 users should be no problem at all. As an example with a single thread > (which will use a single core) I could invoke 10000 token refreshes in > under 60 seconds on my laptop. So a single core on my laptop should be able > to handle 500 users. > > > > On 20 May 2016 at 08:00, Vaibhav Naldurgkar < > vaibhav_naldurgkar at persistent.com> wrote: > > Hi Stian, > > Thank you for your reply. > > > > The new tokens needs to be generated for each user, which is needed from > security point of view. The performance tests were also conducted using > single Admin user and token for admin user; however in that case the > performance was not good. In between 15th to 20th admin token access > requests ? the CPU usage of keycloak Java process was crossing 90 to 120% > mark. > > > > > > As you have mentioned, Creating tokes are expected to be a bit CPU > intensive ? what should be the server configuration in terms of CPU to deal > with more than 500 users to use keycloak as OAuth provider. > > > > > > Thanks, Vaibhav > > > > > > > > *From:* Stian Thorgersen [mailto:sthorger at redhat.com] > *Sent:* Thursday, May 19, 2016 6:28 PM > *To:* Vaibhav Naldurgkar > *Cc:* keycloak-user at lists.jboss.org > *Subject:* Re: [keycloak-user] Keycloak OAuth High CPU usage > > > > Creating tokes are expected to be a bit CPU intensive as they need to be > signed. When you say you try to generate tokens for 10-20 users are you > doing performance tests and having 10-20 threads generating tokens? It > shouldn't make any difference if you have 10 or if you have 200 users, it's > the total number of tokens that can be generated that's an issue. Having > 200 concurrent users with a access token timeout of 60 seconds should mean > that you need to be able to generate roughly 200/60 tokens = 3.3 tokens/sec. > > > > On 19 May 2016 at 13:24, Vaibhav Naldurgkar < > vaibhav_naldurgkar at persistent.com> wrote: > > Hi All, > > > > I am using Keycloak 1.9.3 with default configuration. Keycloak server is > installed on RHEL 6.5 virtual image with 4 CPU , 8 GB RAM and java version > is jdk1.8.0_73 We are trying to use keycloak as a OAuth provider. But when > we try and generate token( > http:///auth/realms/master/protocol/openid-connect/token > ) for more than > 10-20 users the server gets too slow and cpu usage goes over 100%. > > Any pointers on how to improve performance of keycloak OAuth provider. We > need to support at least 200 concurrent users. > > > > > > Thanks, Vaibhav > > DISCLAIMER ========== This e-mail may contain privileged and confidential > information which is the property of Persistent Systems Ltd. It is intended > only for the use of the individual or entity to which it is addressed. If > you are not the intended recipient, you are not authorized to read, retain, > copy, print, distribute or use this message. If you have received this > communication in error, please notify the sender and delete all copies of > this message. Persistent Systems Ltd. does not accept any liability for > virus infected mails. > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > DISCLAIMER ========== This e-mail may contain privileged and confidential > information which is the property of Persistent Systems Ltd. It is intended > only for the use of the individual or entity to which it is addressed. If > you are not the intended recipient, you are not authorized to read, retain, > copy, print, distribute or use this message. If you have received this > communication in error, please notify the sender and delete all copies of > this message. Persistent Systems Ltd. does not accept any liability for > virus infected mails. > > > > DISCLAIMER ========== This e-mail may contain privileged and confidential > information which is the property of Persistent Systems Ltd. It is intended > only for the use of the individual or entity to which it is addressed. If > you are not the intended recipient, you are not authorized to read, retain, > copy, print, distribute or use this message. If you have received this > communication in error, please notify the sender and delete all copies of > this message. Persistent Systems Ltd. does not accept any liability for > virus infected mails. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/271740dc/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 11865 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/271740dc/attachment-0003.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 101405 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/271740dc/attachment-0004.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 18447 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/271740dc/attachment-0005.png From jayapriya.atheesan at gmail.com Mon May 23 02:40:00 2016 From: jayapriya.atheesan at gmail.com (JAYAPRIYA ATHEESAN) Date: Mon, 23 May 2016 12:10:00 +0530 Subject: [keycloak-user] Resetting password Message-ID: <5742a5d9.0cb9420a.b96f6.6132@mx.google.com> Hi, When a user clicks on reset password/forget password and enters an email id which is not registered with keycloak, it does not show any error. Is there any option to give an error message to the user saying "email id doesn't exist". Note : We are using keycloak 1.6.0Final. Thanks, Jayapriya Atheesan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/c8356342/attachment.html From christian.bauer at gmail.com Mon May 23 03:04:54 2016 From: christian.bauer at gmail.com (Christian Bauer) Date: Mon, 23 May 2016 09:04:54 +0200 Subject: [keycloak-user] Reverse proxy calling admin API In-Reply-To: References: <8DBA3048-C140-4C5D-851D-E5BDA24108C8@gmail.com> <9EE9F1DE-8EB0-4BC6-BCC3-C4E56545564E@gmail.com> Message-ID: <531227A8-29BD-47D1-819E-5EF1D63088BA@gmail.com> @WebServlet(name = "test", urlPatterns = "/test") public class TestServlet extends javax.servlet.http.HttpServlet { @Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { System.err.println("REQUEST URL : " + req.getRequestURL()); System.err.println("REMOTE HOST: " + req.getRemoteHost()); Enumeration headers = req.getHeaderNames(); while (headers.hasMoreElements()) { String header = headers.nextElement(); System.err.println(header + ": " + req.getHeader(header)); } } } /wildfly-10.0.0.Final/standalone/configuration$ grep http-listener standalone.xml /wildfly-10.0.0.Final/standalone/configuration$ curl -v --header "X-Forwarded-For: 10.0.0.1:8888" --header "X-Forwarded-Proto: http" http://localhost:8080/proxytest_war_exploded/test 08:47:32,511 ERROR [stderr] (default task-2) REQUEST URL : http://localhost:8080/proxytest_war_exploded/test 08:47:32,511 ERROR [stderr] (default task-2) REMOTE HOST: 10.0.0.1:8888 08:47:32,511 ERROR [stderr] (default task-2) Accept: */* 08:47:32,511 ERROR [stderr] (default task-2) X-Forwarded-Proto: http 08:47:32,512 ERROR [stderr] (default task-2) User-Agent: curl/7.43.0 08:47:32,512 ERROR [stderr] (default task-2) X-Forwarded-For: 10.0.0.1 08:47:32,512 ERROR [stderr] (default task-2) Host: localhost:8080 I've also looked at the code of Undertow/Wildfly and as far as I can tell, the proxy-address-forwarding affects only HttpServletRequest#getRemoteHost() etc. values. > On 23.05.2016, at 08:16, Stian Thorgersen wrote: > > Take a look at http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#proxy-address-forwarding . proxy-address-forwarding=true does set HttpServletRequest#getRequestURL(), but only if http is used. If you're using ajp then you need to use ProxyPeerAddressHandler. > > On 22 May 2016 at 10:10, Christian Bauer > wrote: > A workaround/solution is to set the Host header on the proxy. > > This is equivalent to setting ProxyPreserveHost On if you'd be using Apache mod_proxy. It requires some ugly hacks however customizing this header with my Resteasy/ApacheHttpClient proxy. > > > On 22.05.2016, at 00:18, Christian Bauer > wrote: > > > > Already done. I don't think that affects HttpServletRequest#getRequestURL(), which is what Resteasy is using to populate UriInfo#getBaseUri()? > > > >> set the proxy-address-forwarding="true" for the http-listener. > >> > >>> > >>> The proxy makes a call to Keycloak with a Bearer token and the correct X-Forwarded-* headers. Keycloak/Wildfly is configured with proxy-address-forwarding=true. > > > > > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/30f49225/attachment.html From christian.bauer at gmail.com Mon May 23 03:16:47 2016 From: christian.bauer at gmail.com (Christian Bauer) Date: Mon, 23 May 2016 09:16:47 +0200 Subject: [keycloak-user] Reverse proxy calling admin API In-Reply-To: <531227A8-29BD-47D1-819E-5EF1D63088BA@gmail.com> References: <8DBA3048-C140-4C5D-851D-E5BDA24108C8@gmail.com> <9EE9F1DE-8EB0-4BC6-BCC3-C4E56545564E@gmail.com> <531227A8-29BD-47D1-819E-5EF1D63088BA@gmail.com> Message-ID: <4337C444-BCE5-488C-8EA5-D45B43D814B5@gmail.com> > 08:47:32,512 ERROR [stderr] (default task-2) X-Forwarded-For: 10.0.0.1 Copy/paste error, the actual line is: 08:47:32,512 ERROR [stderr] (default task-2) X-Forwarded-For: 10.0.0.1:8888 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/70a6faf4/attachment.html From akaya at expedia.com Mon May 23 03:33:34 2016 From: akaya at expedia.com (Sarp Kaya) Date: Mon, 23 May 2016 07:33:34 +0000 Subject: [keycloak-user] Monitoring & Collecting Metrics from Keycloak Message-ID: Hi all, I looked into the user guide but there is no mention of any metrics. For instance how would I be able to collect metrics for the amount of users that are logged in per minute, amount of users that could not log in per minute, amount of incorrect usernames etc. as metrics? Is it somehow possible to hook any metric collection library to keycloak events, or does keycloak have anything to provide metrics? Thank you, Sarp Kaya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/3120f8ea/attachment.html From vaibhav_naldurgkar at persistent.com Mon May 23 04:02:49 2016 From: vaibhav_naldurgkar at persistent.com (Vaibhav Naldurgkar) Date: Mon, 23 May 2016 08:02:49 +0000 Subject: [keycloak-user] Keycloak OAuth High CPU usage In-Reply-To: References: Message-ID: Yes, the direct access grant is ON for this client. I am trying to understand what you mean by ?not planning on using web based flow?? Could you provide more clarification on this. This is what the scenario I am trying to execute and still have high CPU usages for KeyCloak Java process. ? The end point URL /auth/realms/master/protocol/openid-connect/token has been called by Jmeter for 20 concurrent users per seconds to generate the tokens. ? Even if used with crul command like ?curl -X POST -d "=admin&password=admin&password&client_id=HelloTest&grant_type=password" http://localhost:8080/auth/realms/master/protocol/openid-connect/token? , in this case also the CPU utilizations goes around 100%. ? After around 3 seconds of the test, in the output of top command on the KeyCloak server the CPU% for keycloak java process goes beyond 100%. Would it be possible for you to have a quick call for faster fix of this issue. This performance issue is holding to move KeyCloak to use as OAuth provider. If any other way is convenient for you please let me know for further discussion. Thanks, Vaibhav From: Stian Thorgersen [mailto:sthorger at redhat.com] Sent: Monday, May 23, 2016 12:01 PM To: Vaibhav Naldurgkar Cc: keycloak-user at lists.jboss.org Subject: Re: [keycloak-user] Keycloak OAuth High CPU usage You are using direct grant to authenticate a user and obtain a token in the example above. This authenticates and creates a new session for each request. Are you not planning on using web based flow? What do you have password hashing intervals set to? Verifying password is CPU intensive, more than signing tokens. It shouldn't matter that user is stored in RedHat IdM as the user would be cached in Keycloak after first authentication, but it may be an idea to just double check by trying to authenticate to a user in Keycloak and not RH IdM. What results are you actually getting? On 20 May 2016 at 11:27, Vaibhav Naldurgkar > wrote: Hi Stian, After reading your tests results of 10000 token refreshes in under 60 seconds on your laptop, I am sure I am not following correct configuration and the documents are missing for reference. Could you please verify the below steps along with the screen-shots for the steps which I am following for the adding client and testing the Load performance using Jmeter. Please suggest if any changes are needed in the client configuration. In this case we are obtaining the token for user from KeyCloak. In my case the user have been stored on RedHat IdM which has been federated using KeyCloak. Step 1. Create new client called ?LoadTest? , use the Client Protocol as ?Openid-connect?. Used all defaults values post save of the client action. Step 2. Start the load tests using Jmeter and using the path as ?/auth/realms/master/protocol/openid-connect/token? . Used 20 Number of Threads and used Post method. Below is the screen-shot for the step 1 related to Add Client. [cid:image001.png at 01D1B4F7.534704A0] Below is the screen shot for the load test using Jmeter. In this case the Client ID was used as HelloTest. [cid:image002.png at 01D1B4F7.534704A0] Http requests. [cid:image003.png at 01D1B4F7.534704A0] Thanks, Vaibhav From: Stian Thorgersen [mailto:sthorger at redhat.com] Sent: Friday, May 20, 2016 1:01 PM To: Vaibhav Naldurgkar Cc: keycloak-user at lists.jboss.org Subject: Re: [keycloak-user] Keycloak OAuth High CPU usage Can you please elaborate a bit more on how your are testing scenario is? I'm a bit confused to what you are testing when you are talking about generating new tokens. Are you using OIDC or SAML? Are you talking about code->token exchanges, refresh token requests, or what? To test if your hardware is capable to deal with the load you need to test logins (verifying passwords are CPU intensive) as well as obtaining tokens (both code->token, done after login, and refreshing token, done ~1 min or so by active users, but most users won't continuously use the application). 500 users should be no problem at all. As an example with a single thread (which will use a single core) I could invoke 10000 token refreshes in under 60 seconds on my laptop. So a single core on my laptop should be able to handle 500 users. On 20 May 2016 at 08:00, Vaibhav Naldurgkar > wrote: Hi Stian, Thank you for your reply. The new tokens needs to be generated for each user, which is needed from security point of view. The performance tests were also conducted using single Admin user and token for admin user; however in that case the performance was not good. In between 15th to 20th admin token access requests ? the CPU usage of keycloak Java process was crossing 90 to 120% mark. As you have mentioned, Creating tokes are expected to be a bit CPU intensive ? what should be the server configuration in terms of CPU to deal with more than 500 users to use keycloak as OAuth provider. Thanks, Vaibhav From: Stian Thorgersen [mailto:sthorger at redhat.com] Sent: Thursday, May 19, 2016 6:28 PM To: Vaibhav Naldurgkar Cc: keycloak-user at lists.jboss.org Subject: Re: [keycloak-user] Keycloak OAuth High CPU usage Creating tokes are expected to be a bit CPU intensive as they need to be signed. When you say you try to generate tokens for 10-20 users are you doing performance tests and having 10-20 threads generating tokens? It shouldn't make any difference if you have 10 or if you have 200 users, it's the total number of tokens that can be generated that's an issue. Having 200 concurrent users with a access token timeout of 60 seconds should mean that you need to be able to generate roughly 200/60 tokens = 3.3 tokens/sec. On 19 May 2016 at 13:24, Vaibhav Naldurgkar > wrote: Hi All, I am using Keycloak 1.9.3 with default configuration. Keycloak server is installed on RHEL 6.5 virtual image with 4 CPU , 8 GB RAM and java version is jdk1.8.0_73 We are trying to use keycloak as a OAuth provider. But when we try and generate token(http:///auth/realms/master/protocol/openid-connect/token) for more than 10-20 users the server gets too slow and cpu usage goes over 100%. Any pointers on how to improve performance of keycloak OAuth provider. We need to support at least 200 concurrent users. Thanks, Vaibhav DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/fb0049a8/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 101405 bytes Desc: image001.png Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/fb0049a8/attachment-0003.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 11865 bytes Desc: image002.png Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/fb0049a8/attachment-0004.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 18447 bytes Desc: image003.png Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/fb0049a8/attachment-0005.png From segatto at esteco.com Mon May 23 06:05:08 2016 From: segatto at esteco.com (Alessandro Segatto) Date: Mon, 23 May 2016 12:05:08 +0200 Subject: [keycloak-user] Updating real settings Message-ID: Hi ! I've a production environment with a realm defined for keycloak clients and a set of users registered in this realm. I'd like to update realm settings by importing them from the json, but i don't want to delete / overwrite registered users. I think i can achieve this goal by exporting the realm with users and then importing it back overwriting realm json with the new configurations but keeping users json. Are there any alternative pipelines to achieve this goal ? Thanks , Alessandro -- Ing. Alessandro Segatto Software Engineer Research and Development *ESTECO S.p.A.* - AREA Science Park, Padriciano 99 - 34149 Trieste - ITALY Phone: +39 040 3755548 - Fax: +39 040 3755549 | www.esteco.com Pursuant to Legislative Decree No. 196/2003, you are hereby informed that this message contains confidential information intended only for the use of the addressee. If you are not the addressee, and have received this message by mistake, please delete it and immediately notify us. You may not copy or disseminate this message to anyone. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/dbffc962/attachment.html From sthorger at redhat.com Mon May 23 06:20:13 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 23 May 2016 12:20:13 +0200 Subject: [keycloak-user] Multi Tenancy support using Jetty 8.1 adapter In-Reply-To: References: Message-ID: The Jetty adapter shares a lot of code with the WildFly adapter so the multi-tenancy example should work on Jetty as well. Give it a try and see ;) On 19 May 2016 at 11:23, Shiva Saxena wrote: > Hi, > > Is is possible to support multi-tenancy using the jetty 8.1 adapter? Like > by using PathBasedKeycloakConfigResolver or similar. Has anyone tried any > such case? > > Thanks! > > -- > Best Regards > *Shiva Saxena* > *Blog | Linkedin > | StackOverflow > * > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/fb89ea7c/attachment.html From sthorger at redhat.com Mon May 23 06:21:01 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 23 May 2016 12:21:01 +0200 Subject: [keycloak-user] LazyInitializationException on Partial import In-Reply-To: References: Message-ID: Try with 1.9.4. If it still doesn't work create a JIRA and attach an example JSON file where it fails. On 19 May 2016 at 13:30, Vincent Sluijter wrote: > During a partial import and selecting OVERWRITE , Keycloak throws the > following error: > > > > UT005023: Exception handling request to > /auth/admin/realms/test/partialImport: > org.jboss.resteasy.spi.UnhandledException: > org.hibernate.LazyInitializationException: failed to lazily initialize a > collection, could not initialize proxy - no Session > > > > Is this feature broken in keycloak 1.9.1.FINAL? > > > > I?m trying to change a parameter in an identity provider? Is this possible > through this method? > > I also get the error when I try to import the full identity provider, for > which the partial import works when It does not exists. > > > This message is subject to the following E-mail Disclaimer. ( > http://www.crv4all.com/disclaimer-email/) CRV Holding B.V. seats > according to the articles of association in Arnhem, Dutch trade number > 09125050. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/f2ed307a/attachment.html From Sven.Riedel at glomex.com Mon May 23 06:59:16 2016 From: Sven.Riedel at glomex.com (Riedel, Sven) Date: Mon, 23 May 2016 10:59:16 +0000 Subject: [keycloak-user] "You took too long to login" when adding the initial admin user Message-ID: Hi, I'm set up keycloak 1.9.4final on AWS as an HA-cluster using JDBC-Ping for infinispan group management behind an load balancer. Now, when I create a user with the bin/add-user-keycloak.sh script and restart keycloak on the respektive instance, I get the message "You took too long to login. Login process starting from beginning." on my first try to login with the newly created account. On my second try, I just get "An error occurred, please login again through your application." >From what I can see, the account is successfully being created in the database. The login attempts happen within one minute of restarting the keycloak service. In the console log I can see the message "type=LOGIN_ERROR, realmId=master, clientId=null, userId=null, ipAddress=a.b.c.d, error=expired_code, restart_after_timeout=true" on the first attempt and "type=LOGIN_ERROR, realmId=master, clientId=null, userId=null, ipAddress=a.b.c.d, error=invalid_code" on the second attempt. I'm a bit at a loss as to how to proceed, to get the admin user set up properly and get the login to work. Any pointers would be appreciated. Regards, Sven -- Sven Riedel Senior Systemsarchitect glomex GmbH Ein Unternehmen der ProSiebenSat.1 Media SE Medienallee 4 D-85774 Unterf?hring Tel. +49 [89] 9507-8167 sven.riedel at glomex.com Gesch?ftsf?hrer: Michael Jaschke, Arnd M?ckenberger HRB 224542 AG M?nchen USt.-ID.-Nr. DE 218559421 St.-Nr. 143/141/71293 From Sven.Riedel at glomex.com Mon May 23 08:49:46 2016 From: Sven.Riedel at glomex.com (Riedel, Sven) Date: Mon, 23 May 2016 12:49:46 +0000 Subject: [keycloak-user] "You took too long to login" when adding the initial admin user In-Reply-To: References: Message-ID: Hi, after enabling sticky sessions on the loadbalancer, the login works. Cranking up the logs to "debug" told me that the "RestartLoginCookies client session does not match the code's clientSession". The phrasing leads me to believe that the session was not shared in the infinispans cache among the nodes. I'll still need to figure out if the cache distribution per se isn't working, or if this was a special case for commandline generated users. Regards, Sven Am 2016-05-23 12:59 schrieb "Riedel, Sven" unter : >Hi, >I'm set up keycloak 1.9.4final on AWS as an HA-cluster using JDBC-Ping for >infinispan group management behind an load balancer. >Now, when I create a user with the bin/add-user-keycloak.sh script and >restart keycloak on the respektive instance, I get the message "You took >too long to login. Login process starting from beginning." on my first try >to login with the newly created account. On my second try, I just get "An >error occurred, please login again through your application." > >From what I can see, the account is successfully being created in the >database. The login attempts happen within one minute of restarting the >keycloak service. In the console log I can see the message >"type=LOGIN_ERROR, realmId=master, clientId=null, userId=null, >ipAddress=a.b.c.d, error=expired_code, restart_after_timeout=true" on the >first attempt and "type=LOGIN_ERROR, realmId=master, clientId=null, >userId=null, ipAddress=a.b.c.d, error=invalid_code" on the second attempt. > >I'm a bit at a loss as to how to proceed, to get the admin user set up >properly and get the login to work. Any pointers would be appreciated. > >Regards, >Sven > > >-- >Sven Riedel >Senior Systemsarchitect > >glomex GmbH >Ein Unternehmen der ProSiebenSat.1 Media SE > >Medienallee 4 >D-85774 Unterf?hring >Tel. +49 [89] 9507-8167 >sven.riedel at glomex.com > >Gesch?ftsf?hrer: Michael Jaschke, Arnd M?ckenberger >HRB 224542 AG M?nchen >USt.-ID.-Nr. DE 218559421 >St.-Nr. 143/141/71293 > > > > From haimv at perfectomobile.com Mon May 23 09:58:50 2016 From: haimv at perfectomobile.com (Haim Vana) Date: Mon, 23 May 2016 13:58:50 +0000 Subject: [keycloak-user] How to assign client roles to realm admin user programmatically Message-ID: Hi, I am trying to create admin user for a specific realm programmatically, I am able to create the user, however I can't assign the realm client roles to it. For example in the UI I would go to the user 'Role Mappings' choose the realm client role and move the required roles from the Available section to the Assigned. When I try to it programmatically I am getting 404, my code is below, note that I am getting 404 on the last line - adminUserClientRole.listAvailable()) createUserAndPsw(keyCloakClient, "master", user); RealmResource realm = keyCloakClient.realm("master"); UserResource userResource = realm.users().get(user.getKeyCloakId()); RoleMappingResource roles = userResource.roles(); RoleScopeResource adminUserClientRole = roles.clientLevel(tenantId + "-realm"); adminUserClientRole.add(adminUserClientRole.listAvailable()); Any advice will be appreciated. Thanks, Haim. The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/db523a8d/attachment-0001.html From ssilvert at redhat.com Mon May 23 10:10:55 2016 From: ssilvert at redhat.com (Stan Silvert) Date: Mon, 23 May 2016 10:10:55 -0400 Subject: [keycloak-user] How to assign client roles to realm admin user programmatically In-Reply-To: References: Message-ID: <57430F6F.1030003@redhat.com> Assigning roles with the admin client is rather tricky. I just finished migrating a test where I had to assign all kinds of roles. I think you'll probably find what you are looking for: https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/composites/CompositeRoleTest.java On 5/23/2016 9:58 AM, Haim Vana wrote: > > Hi, > > I am trying to create admin user for a specific realm > programmatically, I am able to create the user, however I can't assign > the realm client roles to it. > > For example in the UI I would go to the user 'Role Mappings' choose > the realm client role and move the required roles from the Available > section to the Assigned. > > When I try to it programmatically I am getting 404, my code is below, > note that I am getting 404 on the last line - > adminUserClientRole.listAvailable()) > > createUserAndPsw(keyCloakClient, *"master"*, user); > RealmResource realm = keyCloakClient.realm(*"master"*); > UserResource userResource = realm.users().get(user.getKeyCloakId()); > RoleMappingResource roles = userResource.roles(); > RoleScopeResource adminUserClientRole = roles.clientLevel(tenantId + > *"-realm"*); > > > adminUserClientRole.add(adminUserClientRole.listAvailable()); > > Any advice will be appreciated. > > Thanks, > > Haim. > > The information contained in this message is proprietary to the > sender, protected from disclosure, and may be privileged. The > information is intended to be conveyed only to the designated > recipient(s) of the message. If the reader of this message is not the > intended recipient, you are hereby notified that any dissemination, > use, distribution or copying of this communication is strictly > prohibited and may be unlawful. If you have received this > communication in error, please notify us immediately by replying to > the message and deleting it from your computer. Thank you. > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/94682d10/attachment.html From bburke at redhat.com Mon May 23 10:14:56 2016 From: bburke at redhat.com (Bill Burke) Date: Mon, 23 May 2016 10:14:56 -0400 Subject: [keycloak-user] Reverse proxy calling admin API In-Reply-To: <4337C444-BCE5-488C-8EA5-D45B43D814B5@gmail.com> References: <8DBA3048-C140-4C5D-851D-E5BDA24108C8@gmail.com> <9EE9F1DE-8EB0-4BC6-BCC3-C4E56545564E@gmail.com> <531227A8-29BD-47D1-819E-5EF1D63088BA@gmail.com> <4337C444-BCE5-488C-8EA5-D45B43D814B5@gmail.com> Message-ID: https://keycloak.gitbooks.io/server-installation-and-configuration/content/topics/clustering/load-balancer.html As Stian said, ProxyPeerAddressHandler? See above. On 5/23/16 3:16 AM, Christian Bauer wrote: >> 08:47:32,512 ERROR [stderr] (default task-2) X-Forwarded-For: 10.0.0.1 > > Copy/paste error, the actual line is: > > 08:47:32,512 ERROR [stderr] (default task-2) X-Forwarded-For: > 10.0.0.1:8888 > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/8f5be4bb/attachment.html From christian.bauer at gmail.com Mon May 23 10:47:10 2016 From: christian.bauer at gmail.com (Christian Bauer) Date: Mon, 23 May 2016 16:47:10 +0200 Subject: [keycloak-user] Reverse proxy calling admin API In-Reply-To: References: <8DBA3048-C140-4C5D-851D-E5BDA24108C8@gmail.com> <9EE9F1DE-8EB0-4BC6-BCC3-C4E56545564E@gmail.com> <531227A8-29BD-47D1-819E-5EF1D63088BA@gmail.com> <4337C444-BCE5-488C-8EA5-D45B43D814B5@gmail.com> Message-ID: This handler sets ServletRequest#getRemoteHost() etc. values in Undertow. In Wildfly code this handler is actually enabled with the listener attribute proxy-address-forwarding=true: https://github.com/wildfly/wildfly/blob/aaaeb2a13667353db2b6955b9bcdba434a89fd02/undertow/src/main/java/org/wildfly/extension/undertow/HttpListenerService.java#L93 What's the difference between enabling the listener attribute and adding the filter manually? None of this is having any effect on getRequestURL(). There are two ways I see how this host is set: From parsing the HTTP request line or from the Host header. Whatever proxy testing you do probably works because your proxy passes through the original Host header. Preserving the Host header is the default in haproxy but not mod_proxy. > On 23.05.2016, at 16:14, Bill Burke wrote: > > https://keycloak.gitbooks.io/server-installation-and-configuration/content/topics/clustering/load-balancer.html > As Stian said, ProxyPeerAddressHandler? See above. > > On 5/23/16 3:16 AM, Christian Bauer wrote: >>> 08:47:32,512 ERROR [stderr] (default task-2) X-Forwarded-For: 10.0.0.1 >> >> Copy/paste error, the actual line is: >> >> 08:47:32,512 ERROR [stderr] (default task-2) X-Forwarded-For: 10.0.0.1:8888 >> >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/44e46c29/attachment.html From amaeztu at tesicnor.com Mon May 23 11:20:42 2016 From: amaeztu at tesicnor.com (Aritz Maeztu) Date: Mon, 23 May 2016 17:20:42 +0200 Subject: [keycloak-user] Redirection issue with proxy behind keycloak Message-ID: I'm using keycloak to securize some Spring based services (with the keycloak spring security adapter). The adapter creates a `/login` endpoint in each of the services which redirects to the keycloak login page and then redirects back to the service when authentication is done. I also have a proxy service which I want to publish in the 80 port and will take care of routing all the requests to each service. The proxy performs a plain FORWARD to the service, but the problem comes when I securize the service with the keycloak adapter. When I make a request, the adapter redirects to its login endpoint and then to the keycloak auth url. When keycloak sends the redirection, the url shown in the browser is the one from the service and not the one from the proxy. Do I have some choice to tell the adapter I want to redirect back to the first requested url? -- Aritz Maeztu Ota?o Departamento Desarrollo de Software Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra) Telf.: 948 21 40 40 Fax.: 948 21 40 41 Antes de imprimir este e-mail piense bien si es necesario hacerlo: El medioambiente es cosa de todos. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/8ab203c8/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: linkdin.gif Type: image/gif Size: 1295 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/8ab203c8/attachment-0001.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 2983 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/8ab203c8/attachment-0001.png From gahealy at redhat.com Mon May 23 11:51:51 2016 From: gahealy at redhat.com (Gareth Healy) Date: Mon, 23 May 2016 16:51:51 +0100 Subject: [keycloak-user] Kerberos token Message-ID: I am trying to hook up APIMan with KeyCloak using Kerberos and OAuth2. I am trying to get a token from key cloak using the following URL: curl -X POST http://localhost:29080/auth/realms/freeipa/protocol/openid-connect/token -H "Content-Type: application/x-www-form-urlencoded" -d "username=admin" -d 'password=Secret123' -d 'grant_type=password' -d 'client_id=mapper' -d 'client_secret=027fbd51-135b-47d6-86cd-7ce541b38984' But, get an exception back: 2016-05-23 14:22:25,676 DEBUG [org.keycloak.services] (default task-51) AUTHENTICATE CLIENT 2016-05-23 14:22:25,676 TRACE [org.keycloak.services] (default task-51) Using executions for client authentication: [de08b32a-a4a5-469c-91cc-0fbca51e1c2f, de3db156-dcc2-4346-bf3a-e56e8e10ed5f] 2016-05-23 14:22:25,676 DEBUG [org.keycloak.services] (default task-51) client authenticator: client-secret 2016-05-23 14:22:25,676 DEBUG [org.keycloak.services] (default task-51) client authenticator SUCCESS: client-secret 2016-05-23 14:22:25,676 DEBUG [org.keycloak.services] (default task-51) Client mapper authenticated by client-secret 2016-05-23 14:22:25,676 TRACE [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] (default task-51) Adding cache operation: ADD on 7ad60b45-4e69-45a4-a995-ee65d9ee47ae 2016-05-23 14:22:25,676 TRACE [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] (default task-51) Adding cache operation: REPLACE on 7ad60b45-4e69-45a4-a995-ee65d9ee47ae 2016-05-23 14:22:25,676 TRACE [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] (default task-51) Adding cache operation: REPLACE on 7ad60b45-4e69-45a4-a995-ee65d9ee47ae 2016-05-23 14:22:25,676 TRACE [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] (default task-51) Adding cache operation: REPLACE on 7ad60b45-4e69-45a4-a995-ee65d9ee47ae 2016-05-23 14:22:25,676 TRACE [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] (default task-51) Adding cache operation: REPLACE on 7ad60b45-4e69-45a4-a995-ee65d9ee47ae 2016-05-23 14:22:25,676 TRACE [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] (default task-51) Adding cache operation: REPLACE on 7ad60b45-4e69-45a4-a995-ee65d9ee47ae 2016-05-23 14:22:25,676 DEBUG [org.keycloak.services] (default task-51) AUTHENTICATE ONLY 2016-05-23 14:22:25,676 TRACE [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] (default task-51) Adding cache operation: REPLACE on 7ad60b45-4e69-45a4-a995-ee65d9ee47ae 2016-05-23 14:22:25,676 DEBUG [org.keycloak.services] (default task-51) processFlow 2016-05-23 14:22:25,676 DEBUG [org.keycloak.services] (default task-51) check execution: direct-grant-validate-username requirement: REQUIRED 2016-05-23 14:22:25,676 DEBUG [org.keycloak.services] (default task-51) authenticator: direct-grant-validate-username 2016-05-23 14:22:25,676 DEBUG [org.keycloak.services] (default task-51) invoke authenticator.authenticate 2016-05-23 14:22:25,676 TRACE [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] (default task-51) Adding cache operation: REPLACE on 7ad60b45-4e69-45a4-a995-ee65d9ee47ae 2016-05-23 14:22:25,677 TRACE [org.keycloak.federation.ldap.idm.store.ldap.LDAPIdentityStore] (default task-51) Using filter for LDAP search: (&(uid=admin)(objectclass=person)) . Searching in DN: cn=users,cn=accounts,dc=example,dc=test 2016-05-23 14:22:25,682 TRACE [org.keycloak.federation.ldap.idm.store.ldap.LDAPIdentityStore] (default task-51) Found ldap object and populated with the attributes. LDAP Object: LDAP Object [ dn: uid=admin,cn=users,cn=accounts,dc=example,dc=test , uuid: afc65b08-1e75-11e6-9645-02420a01010f, attributes: {uid=[admin], gecos=[Administrator], sn=[Administrator], cn=[Administrator], createTimestamp=[20160520102908Z], modifyTimestamp=[20160523142225Z]}, readOnly attribute names: [createtimestamp, modifytimestamp] ] 2016-05-23 14:22:25,682 TRACE [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] (default task-51) Adding cache operation: REPLACE on 7ad60b45-4e69-45a4-a995-ee65d9ee47ae 2016-05-23 14:22:25,682 DEBUG [org.keycloak.services] (default task-51) authenticator SUCCESS: direct-grant-validate-username 2016-05-23 14:22:25,682 TRACE [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] (default task-51) Adding cache operation: REPLACE on 7ad60b45-4e69-45a4-a995-ee65d9ee47ae 2016-05-23 14:22:25,682 DEBUG [org.keycloak.services] (default task-51) check execution: direct-grant-validate-password requirement: DISABLED 2016-05-23 14:22:25,682 DEBUG [org.keycloak.services] (default task-51) execution is processed 2016-05-23 14:22:25,682 DEBUG [org.keycloak.services] (default task-51) check execution: auth-spnego requirement: ALTERNATIVE 2016-05-23 14:22:25,682 DEBUG [org.keycloak.services] (default task-51) authenticator: auth-spnego 2016-05-23 14:22:25,682 DEBUG [org.keycloak.services] (default task-51) invoke authenticator.authenticate 2016-05-23 14:22:25,682 TRACE [org.keycloak.services] (default task-51) Sending back WWW-Authenticate: Negotiate 2016-05-23 14:22:25,682 TRACE [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] (default task-51) Adding cache operation: REPLACE on 7ad60b45-4e69-45a4-a995-ee65d9ee47ae 2016-05-23 14:22:25,683 ERROR [io.undertow.request] (default task-51) UT005023: Exception handling request to /auth/realms/freeipa/protocol/openid-connect/token: org.jboss.resteasy.spi.UnhandledException: java.lang.IllegalArgumentException: RESTEASY003715: path was null at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76) at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212) at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:168) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:411) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:78) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.IllegalArgumentException: RESTEASY003715: path was null at org.jboss.resteasy.specimpl.ResteasyUriBuilder.path(ResteasyUriBuilder.java:357) at org.keycloak.authentication.AuthenticationProcessor$Result.getActionUrl(AuthenticationProcessor.java:478) at org.keycloak.authentication.authenticators.browser.SpnegoAuthenticator.optionalChallengeRedirect(SpnegoAuthenticator.java:137) at org.keycloak.authentication.authenticators.browser.SpnegoAuthenticator.challengeNegotiation(SpnegoAuthenticator.java:121) at org.keycloak.authentication.authenticators.browser.SpnegoAuthenticator.authenticate(SpnegoAuthenticator.java:65) at org.keycloak.authentication.DefaultAuthenticationFlow.processFlow(DefaultAuthenticationFlow.java:183) at org.keycloak.authentication.AuthenticationProcessor.authenticateOnly(AuthenticationProcessor.java:789) at org.keycloak.protocol.oidc.endpoints.TokenEndpoint.buildResourceOwnerPasswordCredentialsGrant(TokenEndpoint.java:379) at org.keycloak.protocol.oidc.endpoints.TokenEndpoint.build(TokenEndpoint.java:125) at sun.reflect.GeneratedMethodAccessor587.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107) at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133) at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) ... 37 more Looking in the code, i can see i am missing the "flowPath", but not sure where this should be set. https://github.com/keycloak/keycloak/blob/1.9.x/services/src/main/java/org/keycloak/authentication/authenticators/browser/SpnegoAuthenticator.java#L137 https://github.com/keycloak/keycloak/blob/1.9.x/services/src/main/java/org/keycloak/authentication/AuthenticationProcessor.java#L476 Can anyone point me in the right direction please. -- Gareth Healy UKI Middleware Consultant Red Hat UK Ltd 200 Fowler Avenue Farnborough, Hants GU14 7JP, UK Mobile: +44(0)7818511214 E-Mail: gahealy at redhat.com Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/7fd02220/attachment-0001.html From nielsbne at gmail.com Mon May 23 12:44:37 2016 From: nielsbne at gmail.com (Niels Bertram) Date: Tue, 24 May 2016 02:44:37 +1000 Subject: [keycloak-user] Disabling unique email restriction in Keycloak In-Reply-To: References: Message-ID: Are you suggesting that the email field will no longer be able to be populated by the user if the realm is configured to use username only for login? In the current form, we would still have to populate the current "email" field in the user model with a unique email address, which we dont have for our users. Or at least lets say we don't want to resort to a hack in the User Federation Provider and add random snippets into the email address using a fringe feature of the email spec. On Mon, May 23, 2016 at 3:27 PM, Stian Thorgersen wrote: > We've planned to add support for having non-unique email addresses. The > idea would be to have an option on a realm to configure if login permits > username/email, username or email. The email field on users would still > have to have a unique constraint as removing that results in not being able > to guarantee email uniqueness. Instead we planned to have contact email > address which would be non-unique. > > You can workaround this though as it's already possible to add custom > attributes (to add contact email) and change the email sender so Keycloak > supports sending email to contact email attribute if set. > > On 23 May 2016 at 05:03, Nidhi Rachora wrote: > >> Hi Keycloak Team, >> >> I am working on migrating an existing application to Keycloak. In the >> existing application, unique ?member_ids? are used as usernames and the >> ?email? field can be duplicate. However on logging into Keycloak, members >> with duplicate emails are not allowed. So I have identified two areas to >> work on: >> >> Task I) Allow members with unique member ids (who may/ maynot have unique >> email) to login. >> Task II) Disable login using email. >> >> Solution: >> So as a solution to the first task, in my CustomUserFederation, I have >> made the following changes: >> >> //Code snippet 1 CustomFederationProvider implements >> UserFederationProvider{ >> . . >> @Override >> public UserModel getUserByUsername(RealmModel realm, String username) { >> . . >> if (apiCustomer.getEmailAddresses() != null && >> apiCustomer.getEmailAddresses().size() > 0) { >> // Changed to handle duplicate emails using: Sub-addressing, so email: >> mailid at domain is saved as mailid+member_id at domain >> userModel.setEmail( >> subaddress(apiCustomer.getEmailAddresses().get(0).getEmail(), >> userModel.getMember_id())); >> } >> . . >> } >> } >> >> //Code snippet 2 >> CustomUserModelDelegate extends UserModelDelegate { >> . . >> @Override >> public String getEmail() { >> String email = super.getEmail(); try { >> // Changed to handle duplicate emails using: Sub-addressing, so while >> retrieving email: mailid+member_id at domain is processed as mailid at domain >> >> email = removeSubaddress(email); >> } catch (Exception e) { >> ... >> } >> return email; >> } >> . . >> } >> >> Now my queries are: >> >> 1.) Will my solution of sub-addressing the email resolve the first issue >> without any side-effects? >> 2.) How do I disable logging in using emails from Keycloak? >> >> Regards, >> Nidhi Rachora >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/b000bad9/attachment.html From srossillo at smartling.com Mon May 23 15:38:07 2016 From: srossillo at smartling.com (Scott Rossillo) Date: Mon, 23 May 2016 15:38:07 -0400 Subject: [keycloak-user] How to apply updates to keycloak instances In-Reply-To: References: <87CBA013-76D9-4A1D-B64D-70FF432D8720@smartling.com> Message-ID: <097F53B6-6373-4E88-BF9F-8E1808B6295E@smartling.com> We use Jose4J[0] to create the keys and then jq[1] to modify the realm file. See the first line of code here for a super simple example of how to generate realm keys: https://bitbucket.org/b_c/jose4j/wiki/JWT%20Examples PS - this may be doable with Keycloak but Jose4J is very lightweight for writing a simple script on a CI server. [0]: https://bitbucket.org/b_c/jose4j [1]: https://stedolan.github.io/jq/ Scott Rossillo Smartling | Senior Software Engineer srossillo at smartling.com > On May 21, 2016, at 10:20 PM, Anthony Fryer wrote: > > Hi Scott, > > How do you generate the realm keys when creating the new keycloak dev instances? Do you use a keycloak api or some other way? I'm interested in having a standard realm template that is used to create new realms but would need to change the realm keys when importing this template into keycloak. > > Cheers, > > Anthony > > On Sat, May 21, 2016 at 3:43 AM, Scott Rossillo > wrote: > We?re using Keycloak on production, stage/QA, development environments and every developer?s workstation / laptop. > > While there will always be differing options on how to successfully do change management, we?ve found a very effective method for handling Keycloak provisioning in all environments so that developers don?t need to mess around with. We?re a continuous integration / deployment shop using micro services and everything has to ?just work? ? I?ll give an overview of our process here but please keep in mind a few things: > > 1. This approach works for us, I?m not saying it?s the best way > 2. We do _not_ allow production config changes to be automated due to security implications > 3. We're very opinionated in our approach to configuration management and we don?t ever modify 3rd party software databases directly. We always use APIs. > > We deploy Keycloak to all environments using Docker images. On developer workstations we use Docker Compose to orchestrate bringing up all services a developer may need, including Keycloak. > > We have 4 docker images for Keycloak: > - Keycloak Base > \- Keycloak HA > \- Keycloak Dev > - Keycloak config manager* > > The base image includes all customizations necessary to bring up a Keycloak instance configured with our modules and themes installed. > The HA instance builds off base and configures Keycloak to run as a cluster node. This is used on stage and prod. > The dev instance builds off base and includes our realm file. On startup, this instance loads our realm configuration if it?s not already loaded. > > All docker images are built and published by the CI server and Keycloak HA can be deployed to stage and prod after a clean CI build. > > Developers are free to add clients for testing, do whatever they want, etc. to their running dev instance. If they want to get back to our stock build, they pull the latest Docker image from our private Docker repo and restart it. > > Adding clients to stage and prod requires approval and is done by a hand. This is for security reasons. Once a configuration change is detected on stage - say a client is added - our CI server exports the realm from stage, changes the realm keys, and creates a new Keycloak Dev instance with the updated realm file. > > *A word about configuration management: > > Obviously, the realm file we generate knows the URLs of staging services, not local or development environment URLs. To overcome this we introduced another Docker based service called the Keycloak configuration manger. It runs on development environments and workstations. It?s responsible for discovering running services and updating Keycloak via its admin endpoints to reflect the proper configuration for the given environment. > > That?s it. The whole process is automated with the exception of configuration changes to stage and prod which require a security review. > > Hope this helps. Let me know if you?d like me to elaborate on anything. > > Best, > Scott > > Scott Rossillo > Smartling | Senior Software Engineer > srossillo at smartling.com > >> On May 20, 2016, at 1:46 AM, Stian Thorgersen > wrote: >> >> Firstly, just wanted to highlight that core Keycloak team are devs, not sysadmins/ops guys, so we have limited experience in continuous delivery and maintenance of real production systems. Hence, we'd love input from the community on this. >> >> As it stands we don't really have a proper solution. I believe the best you can do at the moment is either using import feature, partial import or admin rest endpoints. Import is not going to work IMO as it requires re-creating the whole realm. Partial import may work, but would work best for new resources rather than modifying existing resources as it does a delete/create operation rather than attempt to modify. With the admin rest endpoints you'd get the best control of what's going on, but obviously that leaves a fair amount of the work. >> >> In the future we have an idea of introducing an "import directory" it would be possible to drop json files in here that would add, modify or delete resources (realms, clients, roles, users, whatever). This would allow dropping json files before the server starts and the server would then import on startup. It would also be possible to do this at runtime and new files would be detected at runtime. Finally, we also had an idea of an offline mode to run import of this (it would basically start the server without http listener, import files, then stop, so it could be used in a script/tool). Import is probably not the best name for it, as it would support modify and delete as well as "importing" new things. >> >> On 19 May 2016 at 19:53, Jesse Chahal > wrote: >> Following some of the best practices for continuous Integration and >> continuous delivery there needs to be environments for build, test, >> and production. This would mean that following these practices would >> require you to have multiple versions of keycloak at different stages >> of development cycle. Some of these environments might not have >> important persistent data while others might. In order to have builds >> transition from one environment to another there may be configuration >> changes required for a build to be valid. This is especially true when >> new services (openid clients) are being added or "default" accounts. >> I'm trying to come up with a scripted way of updating keycloak >> instances that are backed up by an RDMS. This may include adding new >> clients, adding new users, updating realm config, etc... Originally I >> was planning on simply exporting the realm config and importing it >> every time keycloak starts. If I enabled the OVERWRITE option I might >> overwrite things that I do not want overridden. This is especially >> true if there is some config that differ's based on whether it is a >> build, test, or production instance. If I don't enable it then it is >> only useful for new/blank keycloak environments. I considered using >> liquibase but since I do not have control of schema changes created by >> the keycloak team I might run into issues with my liquibase file not >> being valid after a migration/liquibase update by the keycloak team as >> my liquibase file would run after keycloak's does. There might also be >> some other unknown issues our liquibase changes conflicting somehow >> with keycloak's liquibase changes. I've also considered writing my own >> updater tool using a scripting language (python/ruby) that calls >> keycloak's rest api. The issues with this mechanism is it feels like I >> am recreating the wheel as well as not being able to find good >> documentation on keycloak's openid endpoints/url's used for different >> oauth2 flows. Even if I did find this documentation it would also >> require me to find a good openid client for the scripting language. >> This doesn't matter for our normal clients as they simply use the >> keycloak subsystems and adapters instead. I've also looked at commonly >> used server configuration software such as chef, puppet, and ansible. >> I don't see a good solution using any of those tools yet either. What >> have other people done for cases like this? Please don't tell me there >> is someone who is doing this all manually because that doesn't work in >> modern software development. >> >> - doesn't accidentally delete users >> - doesn't accidentally delete clients >> - doesn't invalidate sessions (optional) >> - works to bring up new, correctly configured, keycloak instances >> - handles applying updates to existing keycloak instances >> - can handle minor differences between keycloak instances (build, >> test, production) when updating >> - preferably can work well in rolling deployment scenario's. >> -- I hope the keycloak team is taking these into consideration when >> doing database migration between 1-2 releases. It would be nice if >> they set some specific rules for rolling updates between versions (aka >> backwards breaking changes) >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/8051d136/attachment-0001.html From anthony.fryer at gmail.com Mon May 23 16:49:33 2016 From: anthony.fryer at gmail.com (Anthony Fryer) Date: Mon, 23 May 2016 20:49:33 +0000 Subject: [keycloak-user] How to apply updates to keycloak instances In-Reply-To: <097F53B6-6373-4E88-BF9F-8E1808B6295E@smartling.com> References: <87CBA013-76D9-4A1D-B64D-70FF432D8720@smartling.com> <097F53B6-6373-4E88-BF9F-8E1808B6295E@smartling.com> Message-ID: Thanks, I'll check it out. On 05:38, Tue, 24/05/2016 Scott Rossillo wrote: > We use Jose4J[0] to create the keys and then jq[1] to modify the realm > file. > > See the first line of code here for a super simple example of how to > generate realm keys: > https://bitbucket.org/b_c/jose4j/wiki/JWT%20Examples > > PS - this may be doable with Keycloak but Jose4J is very lightweight for > writing a simple script on a CI server. > > [0]: https://bitbucket.org/b_c/jose4j > [1]: https://stedolan.github.io/jq/ > > > Scott Rossillo > Smartling | Senior Software Engineer > srossillo at smartling.com > > On May 21, 2016, at 10:20 PM, Anthony Fryer > wrote: > > Hi Scott, > > How do you generate the realm keys when creating the new keycloak dev > instances? Do you use a keycloak api or some other way? I'm interested in > having a standard realm template that is used to create new realms but > would need to change the realm keys when importing this template into > keycloak. > > Cheers, > > Anthony > > On Sat, May 21, 2016 at 3:43 AM, Scott Rossillo > wrote: > >> We?re using Keycloak on production, stage/QA, development environments >> and every developer?s workstation / laptop. >> >> While there will always be differing options on how to successfully do >> change management, we?ve found a very effective method for handling >> Keycloak provisioning in all environments so that developers don?t need to >> mess around with. We?re a continuous integration / deployment shop using >> micro services and everything has to ?just work? ? I?ll give an overview of >> our process here but please keep in mind a few things: >> >> 1. This approach works for us, I?m not saying it?s the best way >> 2. We do _not_ allow production config changes to be automated due to >> security implications >> 3. We're very opinionated in our approach to configuration management and >> we don?t ever modify 3rd party software databases directly. We always use >> APIs. >> >> We deploy Keycloak to all environments using Docker images. On developer >> workstations we use Docker Compose to orchestrate bringing up all services >> a developer may need, including Keycloak. >> >> We have 4 docker images for Keycloak: >> - Keycloak Base >> \- Keycloak HA >> \- Keycloak Dev >> - Keycloak config manager* >> >> The base image includes all customizations necessary to bring up a >> Keycloak instance configured with our modules and themes installed. >> The HA instance builds off base and configures Keycloak to run as a >> cluster node. This is used on stage and prod. >> The dev instance builds off base and includes our realm file. On startup, >> this instance loads our realm configuration if it?s not already loaded. >> >> All docker images are built and published by the CI server and Keycloak >> HA can be deployed to stage and prod after a clean CI build. >> >> Developers are free to add clients for testing, do whatever they want, >> etc. to their running dev instance. If they want to get back to our stock >> build, they pull the latest Docker image from our private Docker repo and >> restart it. >> >> Adding clients to stage and prod requires approval and is done by a hand. >> This is for security reasons. Once a configuration change is detected on >> stage - say a client is added - our CI server exports the realm from stage, >> changes the realm keys, and creates a new Keycloak Dev instance with the >> updated realm file. >> >> *A word about configuration management: >> >> Obviously, the realm file we generate knows the URLs of staging services, >> not local or development environment URLs. To overcome this we introduced >> another Docker based service called the Keycloak configuration manger. It >> runs on development environments and workstations. It?s responsible for >> discovering running services and updating Keycloak via its admin endpoints >> to reflect the proper configuration for the given environment. >> >> That?s it. The whole process is automated with the exception of >> configuration changes to stage and prod which require a security review. >> >> Hope this helps. Let me know if you?d like me to elaborate on anything. >> >> Best, >> Scott >> >> Scott Rossillo >> Smartling | Senior Software Engineer >> srossillo at smartling.com >> >> On May 20, 2016, at 1:46 AM, Stian Thorgersen >> wrote: >> >> Firstly, just wanted to highlight that core Keycloak team are devs, not >> sysadmins/ops guys, so we have limited experience in continuous delivery >> and maintenance of real production systems. Hence, we'd love input from the >> community on this. >> >> As it stands we don't really have a proper solution. I believe the best >> you can do at the moment is either using import feature, partial import or >> admin rest endpoints. Import is not going to work IMO as it requires >> re-creating the whole realm. Partial import may work, but would work best >> for new resources rather than modifying existing resources as it does a >> delete/create operation rather than attempt to modify. With the admin rest >> endpoints you'd get the best control of what's going on, but obviously that >> leaves a fair amount of the work. >> >> In the future we have an idea of introducing an "import directory" it >> would be possible to drop json files in here that would add, modify or >> delete resources (realms, clients, roles, users, whatever). This would >> allow dropping json files before the server starts and the server would >> then import on startup. It would also be possible to do this at runtime and >> new files would be detected at runtime. Finally, we also had an idea of an >> offline mode to run import of this (it would basically start the server >> without http listener, import files, then stop, so it could be used in a >> script/tool). Import is probably not the best name for it, as it would >> support modify and delete as well as "importing" new things. >> >> On 19 May 2016 at 19:53, Jesse Chahal wrote: >> >>> Following some of the best practices for continuous Integration and >>> continuous delivery there needs to be environments for build, test, >>> and production. This would mean that following these practices would >>> require you to have multiple versions of keycloak at different stages >>> of development cycle. Some of these environments might not have >>> important persistent data while others might. In order to have builds >>> transition from one environment to another there may be configuration >>> changes required for a build to be valid. This is especially true when >>> new services (openid clients) are being added or "default" accounts. >>> I'm trying to come up with a scripted way of updating keycloak >>> instances that are backed up by an RDMS. This may include adding new >>> clients, adding new users, updating realm config, etc... Originally I >>> was planning on simply exporting the realm config and importing it >>> every time keycloak starts. If I enabled the OVERWRITE option I might >>> overwrite things that I do not want overridden. This is especially >>> true if there is some config that differ's based on whether it is a >>> build, test, or production instance. If I don't enable it then it is >>> only useful for new/blank keycloak environments. I considered using >>> liquibase but since I do not have control of schema changes created by >>> the keycloak team I might run into issues with my liquibase file not >>> being valid after a migration/liquibase update by the keycloak team as >>> my liquibase file would run after keycloak's does. There might also be >>> some other unknown issues our liquibase changes conflicting somehow >>> with keycloak's liquibase changes. I've also considered writing my own >>> updater tool using a scripting language (python/ruby) that calls >>> keycloak's rest api. The issues with this mechanism is it feels like I >>> am recreating the wheel as well as not being able to find good >>> documentation on keycloak's openid endpoints/url's used for different >>> oauth2 flows. Even if I did find this documentation it would also >>> require me to find a good openid client for the scripting language. >>> This doesn't matter for our normal clients as they simply use the >>> keycloak subsystems and adapters instead. I've also looked at commonly >>> used server configuration software such as chef, puppet, and ansible. >>> I don't see a good solution using any of those tools yet either. What >>> have other people done for cases like this? Please don't tell me there >>> is someone who is doing this all manually because that doesn't work in >>> modern software development. >>> >>> - doesn't accidentally delete users >>> - doesn't accidentally delete clients >>> - doesn't invalidate sessions (optional) >>> - works to bring up new, correctly configured, keycloak instances >>> - handles applying updates to existing keycloak instances >>> - can handle minor differences between keycloak instances (build, >>> test, production) when updating >>> - preferably can work well in rolling deployment scenario's. >>> -- I hope the keycloak team is taking these into consideration when >>> doing database migration between 1-2 releases. It would be nice if >>> they set some specific rules for rolling updates between versions (aka >>> backwards breaking changes) >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/bad923f3/attachment.html From john.d.ament at gmail.com Mon May 23 16:54:19 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Mon, 23 May 2016 20:54:19 +0000 Subject: [keycloak-user] Keycloak API Integration/JAR Message-ID: Hi, I was wondering, is there an API JAR that would allow me to interact with Keycloak in a more type safe way? I've been through the REST api and I suspect it will do everything I need, but the work to actually build out the client seems pretty heavy, so having an existing client sounds pretty useful. John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/336aec70/attachment-0001.html From john.d.ament at gmail.com Mon May 23 17:04:26 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Mon, 23 May 2016 21:04:26 +0000 Subject: [keycloak-user] Keycloak API Integration/JAR In-Reply-To: References: Message-ID: Nevermind, I should have searched harder: https://github.com/keycloak/keycloak/tree/master/integration/admin-client John On Mon, May 23, 2016 at 4:54 PM John D. Ament wrote: > Hi, > > I was wondering, is there an API JAR that would allow me to interact with > Keycloak in a more type safe way? I've been through the REST api and I > suspect it will do everything I need, but the work to actually build out > the client seems pretty heavy, so having an existing client sounds pretty > useful. > > John > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/b2520c3a/attachment.html From srossillo at smartling.com Mon May 23 18:05:16 2016 From: srossillo at smartling.com (Scott Rossillo) Date: Mon, 23 May 2016 18:05:16 -0400 Subject: [keycloak-user] Redirection issue with proxy behind keycloak In-Reply-To: References: Message-ID: <1266C23D-C1F7-4CD6-B1E6-D766EFC27126@smartling.com> What are you using as your proxy? Spring Security needs to know it?s behind a proxy when generating login redirects. If Nginx, set: proxy_pass http://your-upstream-here; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto https; # <- only set this if you?re using SSL Scott Rossillo Smartling | Senior Software Engineer srossillo at smartling.com > On May 23, 2016, at 11:20 AM, Aritz Maeztu wrote: > > I'm using keycloak to securize some Spring based services (with the keycloak spring security adapter). The adapter creates a `/login` endpoint in each of the services which redirects to the keycloak login page and then redirects back to the service when authentication is done. I also have a proxy service which I want to publish in the 80 port and will take care of routing all the requests to each service. The proxy performs a plain FORWARD to the service, but the problem comes when I securize the service with the keycloak adapter. > When I make a request, the adapter redirects to its login endpoint and then to the keycloak auth url. When keycloak sends the redirection, the url shown in the browser is the one from the service and not the one from the proxy. Do I have some choice to tell the adapter I want to redirect back to the first requested url? > > -- > Aritz Maeztu Ota?o > Departamento Desarrollo de Software > > Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra) > Telf.: 948 21 40 40 > Fax.: 948 21 40 41 > Antes de imprimir este e-mail piense bien si es necesario hacerlo: El medioambiente es cosa de todos. _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/0c6690c6/attachment.html From nielsbne at gmail.com Mon May 23 20:08:57 2016 From: nielsbne at gmail.com (Niels Bertram) Date: Tue, 24 May 2016 10:08:57 +1000 Subject: [keycloak-user] Redirection issue with proxy behind keycloak In-Reply-To: References: Message-ID: Hi Artitz, a great way to figure out what is sent from the reverse proxy to your keycloak server is to use the undertow request dumper. >From the jboss-cli just add the request dumper filter to your undertow configuration like this: $KC_HOME/bin/jbpss-cli.sh -c /subsystem=undertow/configuration=filter/custom-filter=request-dumper:add(class-name=io.undertow.server.handlers.RequestDumpingHandler, module=io.undertow.core) /subsystem=undertow/server=default-server/host=default-host/filter-ref=request-dumper:add /:reload given your apache config looks something like this: ProxyRequests Off ProxyPreserveHost On ProxyVia On ProxyPass /auth ajp://127.0.0.1:8009/auth ProxyPassReverse /auth ajp://127.0.0.1:8009/auth you should see something like that (forwared info is somewhat rubbish in this example as I am running the hosts on Virtualbox - but you can see this request was put through 2 proxies from local pc 192.168.33.1 to haproxy on 192.168.33.80 and then apache reverse proxy on 192.168.33.81 ): ============================================================== 23:47:20,563 INFO [io.undertow.request.dump] (default task-14) ----------------------------REQUEST--------------------------- URI=/auth/welcome-content/favicon.ico characterEncoding=null contentLength=-1 contentType=null header=Accept=*/* header=Accept-Language=en-US,en;q=0.8,de;q=0.6 header=Cache-Control=no-cache header=Accept-Encoding=gzip, deflate, sdch header=DNT=1 header=Pragma=no-cache header=X-Original-To=192.168.33.80 header=User-Agent=Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 header=Authorization=Basic bmljZSB0cnkgYnV0IGFtIG5vdCBmcm9tIHllc3RlcmRheQo= header=X-Forwarded-Proto=https header=X-Forwarded-Port=443 header=X-Forwarded-For=192.168.33.1 header=Referer=https://login.vagrant.dev/auth/ header=Host=login.vagrant.dev locale=[en_US, en, de] method=GET protocol=HTTP/1.1 queryString= remoteAddr=192.168.33.1:0 remoteHost=192.168.33.1 scheme=https host=login.vagrant.dev serverPort=443 --------------------------RESPONSE-------------------------- contentLength=627 contentType=application/octet-stream header=Cache-Control=max-age=2592000 header=X-Powered-By=Undertow/1 header=Server=WildFly/10 Hope this helps diagnosing your issue. Niels On Tue, May 24, 2016 at 1:20 AM, Aritz Maeztu wrote: > I'm using keycloak to securize some Spring based services (with the > keycloak spring security adapter). The adapter creates a `/login` endpoint > in each of the services which redirects to the keycloak login page and then > redirects back to the service when authentication is done. I also have a > proxy service which I want to publish in the 80 port and will take care of > routing all the requests to each service. The proxy performs a plain > FORWARD to the service, but the problem comes when I securize the service > with the keycloak adapter. > > When I make a request, the adapter redirects to its login endpoint and > then to the keycloak auth url. When keycloak sends the redirection, the url > shown in the browser is the one from the service and not the one from the > proxy. Do I have some choice to tell the adapter I want to redirect back to > the first requested url? > > -- > Aritz Maeztu Ota?o > Departamento Desarrollo de Software > > > > Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra) > Telf.: 948 21 40 40 > Fax.: 948 21 40 41 > Antes de imprimir este e-mail piense bien si es necesario hacerlo: El > medioambiente es cosa de todos. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/17ac0d8b/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: linkdin.gif Type: image/gif Size: 1295 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/17ac0d8b/attachment-0001.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 2983 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/17ac0d8b/attachment-0001.png From srossillo at smartling.com Mon May 23 22:25:59 2016 From: srossillo at smartling.com (Scott Rossillo) Date: Mon, 23 May 2016 22:25:59 -0400 Subject: [keycloak-user] Keycloak API Integration/JAR In-Reply-To: References: Message-ID: <2F566204-7449-4F72-9EC4-8B87B2BD3B0B@smartling.com> You can us Resteasy to create a client for Keycloak (assuming you?re using Java). Take a look at: https://github.com/keycloak/keycloak/blob/57a14627e1efc016da9c69a13629ab16d605b4c8/integration/admin-client/src/main/java/org/keycloak/admin/client/KeycloakBuilder.java Scott Rossillo Smartling | Senior Software Engineer srossillo at smartling.com > On May 23, 2016, at 4:54 PM, John D. Ament wrote: > > Hi, > > I was wondering, is there an API JAR that would allow me to interact with Keycloak in a more type safe way? I've been through the REST api and I suspect it will do everything I need, but the work to actually build out the client seems pretty heavy, so having an existing client sounds pretty useful. > > John > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160523/3cc00021/attachment.html From sthorger at redhat.com Tue May 24 02:31:20 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 24 May 2016 08:31:20 +0200 Subject: [keycloak-user] Keycloak OAuth High CPU usage In-Reply-To: References: Message-ID: On 23 May 2016 at 10:02, Vaibhav Naldurgkar < vaibhav_naldurgkar at persistent.com> wrote: > Yes, the direct access grant is ON for this client. I am trying to > understand what you mean by ?not planning on using web based flow?? Could > you provide more clarification on this. > If you are planning to do the web based flow (authorization code grant flow) you should test with that rather than direct grant. That being said the direct grant should still perform as well. > > > This is what the scenario I am trying to execute and still have high CPU > usages for KeyCloak Java process. > > > > ? The end point URL > /auth/realms/master/protocol/openid-connect/token has been called by Jmeter > for 20 concurrent users per seconds to generate the tokens. > > ? Even if used with crul command like ?*curl -X POST -d > "=admin&password=admin&password&client_id=HelloTest&grant_type=password" > http://localhost:8080/auth/realms/master/protocol/openid-connect/token > *? > , in this case also the CPU utilizations goes around 100%. > > ? After around 3 seconds of the test, in the output of top > command on the KeyCloak server the CPU% for keycloak java process goes > beyond 100%. > > > > Would it be possible for you to have a quick call for faster fix of this > issue. This performance issue is holding to move KeyCloak to use as OAuth > provider. If any other way is convenient for you please let me know for > further discussion. > Your JMeter test is using 20 concurrent threads to send as many requests to the direct grant api as it can. This will obviously cause Keycloak to consume a high percentage of the CPU. Especially if you are running everything on localhost as the network isn't going to be a bottleneck. Neither will the database as Keycloak caches everything in memory. The bottleneck will be the CPU. Authenticating users and obtaining a token requires password hashing as well as signing tokens, both are mainly CPU intensive. As you are using the direct grant api there's also less network traffic. You need to add some reports to your JMeter test so you can see how many requests Keycloak can handle. That way you can find out how many users can be authenticated per-second on your machine. If you only have 500 users remember they won't all login at the same time (seconds). Even if they all login at 9am sharp they will be spread out over 10 minutes or so, which would only be 1.2 logins/second. > > > Thanks, Vaibhav > > > > > > > > > > *From:* Stian Thorgersen [mailto:sthorger at redhat.com] > *Sent:* Monday, May 23, 2016 12:01 PM > > *To:* Vaibhav Naldurgkar > *Cc:* keycloak-user at lists.jboss.org > *Subject:* Re: [keycloak-user] Keycloak OAuth High CPU usage > > > > You are using direct grant to authenticate a user and obtain a token in > the example above. This authenticates and creates a new session for each > request. Are you not planning on using web based flow? > > > > What do you have password hashing intervals set to? Verifying password is > CPU intensive, more than signing tokens. > > > > It shouldn't matter that user is stored in RedHat IdM as the user would be > cached in Keycloak after first authentication, but it may be an idea to > just double check by trying to authenticate to a user in Keycloak and not > RH IdM. > > > > What results are you actually getting? > > > > > > > > On 20 May 2016 at 11:27, Vaibhav Naldurgkar < > vaibhav_naldurgkar at persistent.com> wrote: > > Hi Stian, > > > > After reading your tests results of 10000 token refreshes in under 60 > seconds on your laptop, I am sure I am not following correct configuration > and the documents are missing for reference. > > > > Could you please verify the below steps along with the screen-shots for > the steps which I am following for the adding client and testing the Load > performance using Jmeter. Please suggest if any changes are needed in the > client configuration. In this case we are obtaining the token for user from > KeyCloak. > > > > In my case the user have been stored on RedHat IdM which has been > federated using KeyCloak. > > > > > > Step 1. Create new client called ?LoadTest? , use the Client Protocol as > ?Openid-connect?. > > Used all defaults values post save of the client action. > > > > Step 2. Start the load tests using Jmeter and using the path as > *?/auth/realms/master/protocol/openid-connect/token?* . Used 20 Number of > Threads and used Post method. > > > > > > Below is the screen-shot for the step 1 related to Add Client. > > > > > > > > > > Below is the screen shot for the load test using Jmeter. In this case the > Client ID was used as HelloTest. > > > > > > > > Http requests. > > > > > > > > Thanks, Vaibhav > > > > > > *From:* Stian Thorgersen [mailto:sthorger at redhat.com] > *Sent:* Friday, May 20, 2016 1:01 PM > > > *To:* Vaibhav Naldurgkar > *Cc:* keycloak-user at lists.jboss.org > *Subject:* Re: [keycloak-user] Keycloak OAuth High CPU usage > > > > Can you please elaborate a bit more on how your are testing scenario is? > I'm a bit confused to what you are testing when you are talking about > generating new tokens. Are you using OIDC or SAML? Are you talking about > code->token exchanges, refresh token requests, or what? > > > > To test if your hardware is capable to deal with the load you need to test > logins (verifying passwords are CPU intensive) as well as obtaining tokens > (both code->token, done after login, and refreshing token, done ~1 min or > so by active users, but most users won't continuously use the application). > > > > 500 users should be no problem at all. As an example with a single thread > (which will use a single core) I could invoke 10000 token refreshes in > under 60 seconds on my laptop. So a single core on my laptop should be able > to handle 500 users. > > > > On 20 May 2016 at 08:00, Vaibhav Naldurgkar < > vaibhav_naldurgkar at persistent.com> wrote: > > Hi Stian, > > Thank you for your reply. > > > > The new tokens needs to be generated for each user, which is needed from > security point of view. The performance tests were also conducted using > single Admin user and token for admin user; however in that case the > performance was not good. In between 15th to 20th admin token access > requests ? the CPU usage of keycloak Java process was crossing 90 to 120% > mark. > > > > > > As you have mentioned, Creating tokes are expected to be a bit CPU > intensive ? what should be the server configuration in terms of CPU to deal > with more than 500 users to use keycloak as OAuth provider. > > > > > > Thanks, Vaibhav > > > > > > > > *From:* Stian Thorgersen [mailto:sthorger at redhat.com] > *Sent:* Thursday, May 19, 2016 6:28 PM > *To:* Vaibhav Naldurgkar > *Cc:* keycloak-user at lists.jboss.org > *Subject:* Re: [keycloak-user] Keycloak OAuth High CPU usage > > > > Creating tokes are expected to be a bit CPU intensive as they need to be > signed. When you say you try to generate tokens for 10-20 users are you > doing performance tests and having 10-20 threads generating tokens? It > shouldn't make any difference if you have 10 or if you have 200 users, it's > the total number of tokens that can be generated that's an issue. Having > 200 concurrent users with a access token timeout of 60 seconds should mean > that you need to be able to generate roughly 200/60 tokens = 3.3 tokens/sec. > > > > On 19 May 2016 at 13:24, Vaibhav Naldurgkar < > vaibhav_naldurgkar at persistent.com> wrote: > > Hi All, > > > > I am using Keycloak 1.9.3 with default configuration. Keycloak server is > installed on RHEL 6.5 virtual image with 4 CPU , 8 GB RAM and java version > is jdk1.8.0_73 We are trying to use keycloak as a OAuth provider. But when > we try and generate token( > http:///auth/realms/master/protocol/openid-connect/token > ) for more than > 10-20 users the server gets too slow and cpu usage goes over 100%. > > Any pointers on how to improve performance of keycloak OAuth provider. We > need to support at least 200 concurrent users. > > > > > > Thanks, Vaibhav > > DISCLAIMER ========== This e-mail may contain privileged and confidential > information which is the property of Persistent Systems Ltd. It is intended > only for the use of the individual or entity to which it is addressed. If > you are not the intended recipient, you are not authorized to read, retain, > copy, print, distribute or use this message. If you have received this > communication in error, please notify the sender and delete all copies of > this message. Persistent Systems Ltd. does not accept any liability for > virus infected mails. > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > DISCLAIMER ========== This e-mail may contain privileged and confidential > information which is the property of Persistent Systems Ltd. It is intended > only for the use of the individual or entity to which it is addressed. If > you are not the intended recipient, you are not authorized to read, retain, > copy, print, distribute or use this message. If you have received this > communication in error, please notify the sender and delete all copies of > this message. Persistent Systems Ltd. does not accept any liability for > virus infected mails. > > > > DISCLAIMER ========== This e-mail may contain privileged and confidential > information which is the property of Persistent Systems Ltd. It is intended > only for the use of the individual or entity to which it is addressed. If > you are not the intended recipient, you are not authorized to read, retain, > copy, print, distribute or use this message. If you have received this > communication in error, please notify the sender and delete all copies of > this message. Persistent Systems Ltd. does not accept any liability for > virus infected mails. > > > > DISCLAIMER ========== This e-mail may contain privileged and confidential > information which is the property of Persistent Systems Ltd. It is intended > only for the use of the individual or entity to which it is addressed. If > you are not the intended recipient, you are not authorized to read, retain, > copy, print, distribute or use this message. If you have received this > communication in error, please notify the sender and delete all copies of > this message. Persistent Systems Ltd. does not accept any liability for > virus infected mails. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/b46c50e2/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 101405 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/b46c50e2/attachment-0003.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 11865 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/b46c50e2/attachment-0004.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 18447 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/b46c50e2/attachment-0005.png From amaeztu at tesicnor.com Tue May 24 02:46:08 2016 From: amaeztu at tesicnor.com (Aritz Maeztu) Date: Tue, 24 May 2016 08:46:08 +0200 Subject: [keycloak-user] Redirection issue with proxy behind keycloak In-Reply-To: References: Message-ID: Hi Niels and Scott. First of all, thank you very much for your help. I'm currently using Zuul (Spring Cloud) as the reverse proxy. All the services are registered in a discovery service called Eureka and then Zuul looks for the service id there and performs de redirection. I read about X-Forwarded headers, but I thought it might result in a security issue if not included, not that it could affect the redirection process. As Scott says, I suppose the Host and the X-Real-Ip headers are the relevant ones here, so I guess I should instruct Zuul to send them when the service is addressed (however I wonder why they are not already being sent, as Zuul is a proxy service, all in all). Here I include a preview of the first redirection made to the keycloak login page, which shows the request headers sent to the service /login endpoint (at port 8081 in localhost): https://www.dropbox.com/s/iof9yefytzay6j2/screenshot.PNG?dl=0 24/05/2016 2:08(e)an, Niels Bertram igorleak idatzi zuen: > Hi Artitz, > > a great way to figure out what is sent from the reverse proxy to your > keycloak server is to use the undertow request dumper. > > From the jboss-cli just add the request dumper filter to your undertow > configuration like this: > > $KC_HOME/bin/jbpss-cli.sh -c > > /subsystem=undertow/configuration=filter/custom-filter=request-dumper:add(class-name=io.undertow.server.handlers.RequestDumpingHandler, > module=io.undertow.core) > > /subsystem=undertow/server=default-server/host=default-host/filter-ref=request-dumper:add > > /:reload > > given your apache config looks something like this: > > ProxyRequests Off > ProxyPreserveHost On > ProxyVia On > > ProxyPass /auth ajp://127.0.0.1:8009/auth > ProxyPassReverse /auth ajp://127.0.0.1:8009/auth > > > > you should see something like that (forwared info is somewhat rubbish > in this example as I am running the hosts on Virtualbox - but you can > see this request was put through 2 proxies from local pc 192.168.33.1 > to haproxy on 192.168.33.80 and then apache reverse proxy on > 192.168.33.81 ): > > ============================================================== > 23:47:20,563 INFO [io.undertow.request.dump] (default task-14) > ----------------------------REQUEST--------------------------- > URI=/auth/welcome-content/favicon.ico > characterEncoding=null > contentLength=-1 > contentType=null > header=Accept=*/* > header=Accept-Language=en-US,en;q=0.8,de;q=0.6 > header=Cache-Control=no-cache > header=Accept-Encoding=gzip, deflate, sdch > header=DNT=1 > header=Pragma=no-cache > header=X-Original-To=192.168.33.80 > header=User-Agent=Mozilla/5.0 (Windows NT 6.1; WOW64) > AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 > header=Authorization=Basic > bmljZSB0cnkgYnV0IGFtIG5vdCBmcm9tIHllc3RlcmRheQo= > header=X-Forwarded-Proto=https > header=X-Forwarded-Port=443 > header=X-Forwarded-For=192.168.33.1 > header=Referer=https://login.vagrant.dev/auth/ > header=Host=login.vagrant.dev > locale=[en_US, en, de] > method=GET > protocol=HTTP/1.1 > queryString= > remoteAddr=192.168.33.1:0 > remoteHost=192.168.33.1 > scheme=https > host=login.vagrant.dev > serverPort=443 > --------------------------RESPONSE-------------------------- > contentLength=627 > contentType=application/octet-stream > header=Cache-Control=max-age=2592000 > header=X-Powered-By=Undertow/1 > header=Server=WildFly/10 > > > Hope this helps diagnosing your issue. Niels > > On Tue, May 24, 2016 at 1:20 AM, Aritz Maeztu > wrote: > > I'm using keycloak to securize some Spring based services (with > the keycloak spring security adapter). The adapter creates a > `/login` endpoint in each of the services which redirects to the > keycloak login page and then redirects back to the service when > authentication is done. I also have a proxy service which I want > to publish in the 80 port and will take care of routing all the > requests to each service. The proxy performs a plain FORWARD to > the service, but the problem comes when I securize the service > with the keycloak adapter. > > When I make a request, the adapter redirects to its login endpoint > and then to the keycloak auth url. When keycloak sends the > redirection, the url shown in the browser is the one from the > service and not the one from the proxy. Do I have some choice to > tell the adapter I want to redirect back to the first requested url? > > > -- > Aritz Maeztu Ota?o > Departamento Desarrollo de Software > > > > Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra) > Telf.: 948 21 40 40 > Fax.: 948 21 40 41 > > Antes de imprimir este e-mail piense bien si es necesario hacerlo: > El medioambiente es cosa de todos. > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > -- Aritz Maeztu Ota?o Departamento Desarrollo de Software Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra) Telf.: 948 21 40 40 Fax.: 948 21 40 41 Antes de imprimir este e-mail piense bien si es necesario hacerlo: El medioambiente es cosa de todos. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/0f1c5b78/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1295 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/0f1c5b78/attachment-0002.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 2983 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/0f1c5b78/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: linkdin.gif Type: image/gif Size: 1295 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/0f1c5b78/attachment-0003.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 2983 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/0f1c5b78/attachment-0003.png From sthorger at redhat.com Tue May 24 02:50:34 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 24 May 2016 08:50:34 +0200 Subject: [keycloak-user] Reverse proxy calling admin API In-Reply-To: References: <8DBA3048-C140-4C5D-851D-E5BDA24108C8@gmail.com> <9EE9F1DE-8EB0-4BC6-BCC3-C4E56545564E@gmail.com> <531227A8-29BD-47D1-819E-5EF1D63088BA@gmail.com> <4337C444-BCE5-488C-8EA5-D45B43D814B5@gmail.com> Message-ID: The attribute only works for HTTP connector, not for AJP. For AJP you have to manually add it. The Host header is required though. Ho would Undertow else figure out the original request URL? I can't see anything we can do on our end for this, besides documenting the fact that the original Host header has to be preserved. On 23 May 2016 at 16:47, Christian Bauer wrote: > This handler sets ServletRequest#getRemoteHost() etc. values in Undertow. > In Wildfly code this handler is actually enabled with the listener > attribute proxy-address-forwarding=true: > > > https://github.com/wildfly/wildfly/blob/aaaeb2a13667353db2b6955b9bcdba434a89fd02/undertow/src/main/java/org/wildfly/extension/undertow/HttpListenerService.java#L93 > > What's the difference between enabling the listener attribute and adding > the filter manually? > > None of this is having any effect on getRequestURL(). There are two ways I > see how this host is set: From parsing the HTTP request line or from the > Host header. > > Whatever proxy testing you do probably works because your proxy passes > through the original Host header. Preserving the Host header is the default > in haproxy but not mod_proxy. > > On 23.05.2016, at 16:14, Bill Burke wrote: > > > https://keycloak.gitbooks.io/server-installation-and-configuration/content/topics/clustering/load-balancer.html > > As Stian said, ProxyPeerAddressHandler? See above. > > > On 5/23/16 3:16 AM, Christian Bauer wrote: > > 08:47:32,512 ERROR [stderr] (default task-2) X-Forwarded-For: 10.0.0.1 > > > Copy/paste error, the actual line is: > > 08:47:32,512 ERROR [stderr] (default task-2) X-Forwarded-For: > 10.0.0.1:8888 > > > > _______________________________________________ > keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/0b161311/attachment.html From sthorger at redhat.com Tue May 24 02:55:40 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 24 May 2016 08:55:40 +0200 Subject: [keycloak-user] Reverse proxy calling admin API In-Reply-To: References: <8DBA3048-C140-4C5D-851D-E5BDA24108C8@gmail.com> <9EE9F1DE-8EB0-4BC6-BCC3-C4E56545564E@gmail.com> <531227A8-29BD-47D1-819E-5EF1D63088BA@gmail.com> <4337C444-BCE5-488C-8EA5-D45B43D814B5@gmail.com> Message-ID: Created https://issues.jboss.org/browse/KEYCLOAK-3029 On 24 May 2016 at 08:50, Stian Thorgersen wrote: > The attribute only works for HTTP connector, not for AJP. For AJP you have > to manually add it. > > The Host header is required though. Ho would Undertow else figure out the > original request URL? I can't see anything we can do on our end for this, > besides documenting the fact that the original Host header has to be > preserved. > > On 23 May 2016 at 16:47, Christian Bauer > wrote: > >> This handler sets ServletRequest#getRemoteHost() etc. values in Undertow. >> In Wildfly code this handler is actually enabled with the listener >> attribute proxy-address-forwarding=true: >> >> >> https://github.com/wildfly/wildfly/blob/aaaeb2a13667353db2b6955b9bcdba434a89fd02/undertow/src/main/java/org/wildfly/extension/undertow/HttpListenerService.java#L93 >> >> What's the difference between enabling the listener attribute and adding >> the filter manually? >> >> None of this is having any effect on getRequestURL(). There are two ways >> I see how this host is set: From parsing the HTTP request line or from the >> Host header. >> >> Whatever proxy testing you do probably works because your proxy passes >> through the original Host header. Preserving the Host header is the default >> in haproxy but not mod_proxy. >> >> On 23.05.2016, at 16:14, Bill Burke wrote: >> >> >> https://keycloak.gitbooks.io/server-installation-and-configuration/content/topics/clustering/load-balancer.html >> >> As Stian said, ProxyPeerAddressHandler? See above. >> >> >> On 5/23/16 3:16 AM, Christian Bauer wrote: >> >> 08:47:32,512 ERROR [stderr] (default task-2) X-Forwarded-For: 10.0.0.1 >> >> >> Copy/paste error, the actual line is: >> >> 08:47:32,512 ERROR [stderr] (default task-2) X-Forwarded-For: >> 10.0.0.1:8888 >> >> >> >> _______________________________________________ >> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/2747d5bd/attachment.html From shivasaxena999 at gmail.com Tue May 24 03:46:44 2016 From: shivasaxena999 at gmail.com (Shiva Saxena) Date: Tue, 24 May 2016 13:16:44 +0530 Subject: [keycloak-user] Multi Tenancy support using Jetty 8.1 adapter In-Reply-To: References: Message-ID: Hi Stian, Tried it and it does work. Just needed to specify the path based conflict resolver in jetty-web.xml like so keycloak.config.resolver com.example.PathBasedKeycloakConfigResolver It required additional permission java.lang.RuntimePermission " getClassLoader"; in *java.policy* file located at *%JavaHome%/jre/lib/security/* . Thanks! On Mon, May 23, 2016 at 3:50 PM, Stian Thorgersen wrote: > The Jetty adapter shares a lot of code with the WildFly adapter so the > multi-tenancy example should work on Jetty as well. Give it a try and see ;) > > On 19 May 2016 at 11:23, Shiva Saxena wrote: > >> Hi, >> >> Is is possible to support multi-tenancy using the jetty 8.1 adapter? Like >> by using PathBasedKeycloakConfigResolver or similar. Has anyone tried any >> such case? >> >> Thanks! >> >> -- >> Best Regards >> *Shiva Saxena* >> *Blog | Linkedin >> | StackOverflow >> * >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > -- Best Regards *Shiva Saxena* *Blog | Linkedin | StackOverflow * -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/3cb58fa2/attachment-0001.html From haimv at perfectomobile.com Tue May 24 04:20:06 2016 From: haimv at perfectomobile.com (Haim Vana) Date: Tue, 24 May 2016 08:20:06 +0000 Subject: [keycloak-user] How to assign client roles to realm admin Message-ID: Thanks for the prompt answer. I looked into the CompositeRoleTest below, especially on the addClientLevelScopeMapping method. However I don't think it's what I am looking for, I would like to create an admin user on the master realm and assign all the available client (another realm) roles for him. So in the test it is not clear what are the target and source clients in my case. Going back to my code sample below, can you please advise if this is the correct way to add the client roles and how can I get all the available ones ? realm.users().get(user.getKeyCloakId()).roles().clientLevel(tenantId + "-realm").add(); Thanks, Haim. -----Original Message----- Message: 1 Date: Mon, 23 May 2016 10:10:55 -0400 From: Stan Silvert Subject: Re: [keycloak-user] How to assign client roles to realm admin user programmatically To: keycloak-user at lists.jboss.org Message-ID: <57430F6F.1030003 at redhat.com> Content-Type: text/plain; charset="iso-8859-1" Assigning roles with the admin client is rather tricky. I just finished migrating a test where I had to assign all kinds of roles. I think you'll probably find what you are looking for: https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/composites/CompositeRoleTest.java On 5/23/2016 9:58 AM, Haim Vana wrote: > > Hi, > > I am trying to create admin user for a specific realm > programmatically, I am able to create the user, however I can't assign > the realm client roles to it. > > For example in the UI I would go to the user 'Role Mappings' choose > the realm client role and move the required roles from the Available > section to the Assigned. > > When I try to it programmatically I am getting 404, my code is below, > note that I am getting 404 on the last line - > adminUserClientRole.listAvailable()) > > createUserAndPsw(keyCloakClient, *"master"*, user); RealmResource > realm = keyCloakClient.realm(*"master"*); UserResource userResource = > realm.users().get(user.getKeyCloakId()); > RoleMappingResource roles = userResource.roles(); RoleScopeResource > adminUserClientRole = roles.clientLevel(tenantId + *"-realm"*); > > > adminUserClientRole.add(adminUserClientRole.listAvailable()); > > Any advice will be appreciated. > > Thanks, > > Haim. > > The information contained in this message is proprietary to the > sender, protected from disclosure, and may be privileged. The > information is intended to be conveyed only to the designated > recipient(s) of the message. If the reader of this message is not the > intended recipient, you are hereby notified that any dissemination, > use, distribution or copying of this communication is strictly > prohibited and may be unlawful. If you have received this > communication in error, please notify us immediately by replying to > the message and deleting it from your computer. Thank you. > > > _______________________________________________ The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. From haimv at perfectomobile.com Tue May 24 04:46:25 2016 From: haimv at perfectomobile.com (Haim Vana) Date: Tue, 24 May 2016 08:46:25 +0000 Subject: [keycloak-user] How to assign client roles to realm admin Message-ID: I found the problem - I needed to use the client id (from the DB). Thanks, Haim. -----Original Message----- From: Haim Vana Sent: Tuesday, May 24, 2016 11:20 AM To: keycloak-user at lists.jboss.org Subject: Re: Re: [keycloak-user] How to assign client roles to realm admin Thanks for the prompt answer. I looked into the CompositeRoleTest below, especially on the addClientLevelScopeMapping method. However I don't think it's what I am looking for, I would like to create an admin user on the master realm and assign all the available client (another realm) roles for him. So in the test it is not clear what are the target and source clients in my case. Going back to my code sample below, can you please advise if this is the correct way to add the client roles and how can I get all the available ones ? realm.users().get(user.getKeyCloakId()).roles().clientLevel(tenantId + "-realm").add(); Thanks, Haim. -----Original Message----- Message: 1 Date: Mon, 23 May 2016 10:10:55 -0400 From: Stan Silvert Subject: Re: [keycloak-user] How to assign client roles to realm admin user programmatically To: keycloak-user at lists.jboss.org Message-ID: <57430F6F.1030003 at redhat.com> Content-Type: text/plain; charset="iso-8859-1" Assigning roles with the admin client is rather tricky. I just finished migrating a test where I had to assign all kinds of roles. I think you'll probably find what you are looking for: https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/composites/CompositeRoleTest.java On 5/23/2016 9:58 AM, Haim Vana wrote: > > Hi, > > I am trying to create admin user for a specific realm > programmatically, I am able to create the user, however I can't assign > the realm client roles to it. > > For example in the UI I would go to the user 'Role Mappings' choose > the realm client role and move the required roles from the Available > section to the Assigned. > > When I try to it programmatically I am getting 404, my code is below, > note that I am getting 404 on the last line - > adminUserClientRole.listAvailable()) > > createUserAndPsw(keyCloakClient, *"master"*, user); RealmResource > realm = keyCloakClient.realm(*"master"*); UserResource userResource = > realm.users().get(user.getKeyCloakId()); > RoleMappingResource roles = userResource.roles(); RoleScopeResource > adminUserClientRole = roles.clientLevel(tenantId + *"-realm"*); > > > adminUserClientRole.add(adminUserClientRole.listAvailable()); > > Any advice will be appreciated. > > Thanks, > > Haim. > > The information contained in this message is proprietary to the > sender, protected from disclosure, and may be privileged. The > information is intended to be conveyed only to the designated > recipient(s) of the message. If the reader of this message is not the > intended recipient, you are hereby notified that any dissemination, > use, distribution or copying of this communication is strictly > prohibited and may be unlawful. If you have received this > communication in error, please notify us immediately by replying to > the message and deleting it from your computer. Thank you. > > > _______________________________________________ The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. From eduard.matuszak at atos.net Tue May 24 05:46:57 2016 From: eduard.matuszak at atos.net (Matuszak, Eduard) Date: Tue, 24 May 2016 09:46:57 +0000 Subject: [keycloak-user] Token generation: possibilities to improve performance Message-ID: <61D077C6283D454FAFD06F6AC4AB74D723DDFF8E@DEFTHW99EZ1MSX.ww931.my-it-solutions.net> Hello Motivated by considerations on how to improve the performance of the token generation process I have two questions: - I noticed that Keycloak's token generation via endpoint "auth/realms/ccp/protocol/openid-connect/token" generates a triple of tokens (access-, refresh- and id-token). Is there any possibility to dispense with the id-token generation? - Is there a possibility to cause Keycloak to generate more "simple" bearer tokens then complex jwt-tokens? Best regards, Eduard Matuszak -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/186f98b5/attachment.html From nielsbne at gmail.com Tue May 24 05:48:49 2016 From: nielsbne at gmail.com (Niels Bertram) Date: Tue, 24 May 2016 19:48:49 +1000 Subject: [keycloak-user] Keycloak token exchange failure behind loadbalancer and reverse proxy Message-ID: I am scratching my head with a specific setup problem which does not generate any usable error messages. I am running a haproxy as load balancer in a vm in front an apache web server configured as reverse proxy connecting to the keycloak server via ajp in another VM. client browser (192.168.33.1) login.vagrant.v8 (192.168.33.80) aka proxy.vagrant.v8 is haproxy adds X-Forwarded-For X-Forwarded-Port X-Forwarded-Proto and X-Real-Ip kc01.vagrant.v8 (192.168.33.81) apache reverse proxies to wildfly on ajp port Followed all the setup instructions in the documentation and if I connect to apache proxying through to keycloak everything works fine. All web resources are donwloaded fine however when I request a token exchange on /auth/realms/master/protocol/openid-connect/token I get a 400 response. The kc server log shows the corect IP address of the originating client and the request dump from wildfly also shows the correct X-Forwarded-For header coming in. However the query string remoteAddr=/192.168.33.80:54672 which I believe is the one sent to the ajp connector shows some half valid IP address which is that of the load balancer. Did anyone come across this before? Looks like a bug of some sort. The symptom is a endless loop trying to log into the admin panel. Cheers Niels # cat standalone/log/server.log | grep -A 58 '2016-05-24 09:19:27,672' 2016-05-24 09:19:27,672 WARN [org.keycloak.events] (default task-19) type=CODE_TO_TOKEN_ERROR, realmId=master, clientId=admin, userId=null, ipAddress=*192.168.33.1*, error=invalid_client_credentials, grant_type=authorization_code 2016-05-24 09:19:27,673 INFO [io.undertow.request.dump] (default task-19) ----------------------------REQUEST--------------------------- URI=/auth/realms/master/protocol/openid-connect/token characterEncoding=null contentLength=229 contentType=[application/x-www-form-urlencoded] cookie=KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjM5YTVkNTlmLWMyNDYtNDkwZi04ZGZkLTZhYzVhNzgyZDI5ZCIsImNpZCI6InNlY3VyaXR5LWFkbWluLWNvbnNvbGUiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9hZG1pbi9tYXN0ZXIvY29uc29sZS8iLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiOGQ5ZGI4MzctMjY2Ni00NDcxLTk0ZDgtZmFkMmIxMjA3NDQxIiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL3JlYWxtcy9tYXN0ZXIiLCJyZXNwb25zZV90eXBlIjoiY29kZSIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL2FkbWluL21hc3Rlci9jb25zb2xlLyIsInN0YXRlIjoiNTQ4ZDE5ZTUtMjlkMS00NTU2LWFjNjAtYjZjZTM1ZmJiMGU2Iiwibm9uY2UiOiI5OGY3NDFiYS03MmQwLTQ0ZDUtOGQ0ZC1jZTAxNzZhYjMyMmUiLCJyZXNwb25zZV9tb2RlIjoiZnJhZ21lbnQifX0.I0jI4nDhbYtKNrVjdlwjjBe5mtd0a8u6Dm7rQXwLE60 cookie=KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJhNjY5OWJkOS00MWQ4LTQyNWYtYjE5Ni04Y2QzNmJiZjBmNjQiLCJleHAiOjE0NjQxMTc1NjcsIm5iZiI6MCwiaWF0IjoxNDY0MDgxNTY3LCJpc3MiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9yZWFsbXMvbWFzdGVyIiwic3ViIjoiY2YyNDg4MTEtNmQ4Mi00N2U3LWJmOWEtN2IxOTdmYjk4OGQwIiwic2Vzc2lvbl9zdGF0ZSI6IjFiYTljODRlLTBlMzctNGE4Mi1hNDg0LWMyNWQyYzRhODBmYyIsInJlc291cmNlX2FjY2VzcyI6e319.E0vEe9XQJ_6IbDC_TEUfumQCJ0fS1_AOYsHh7svyGp16VC89sH9J1FQuLJfHYFVJlDTcE6o2ktLg0fLw2nLIdLOv-WXMseYr0KzudZveiLy1CZbRoPS9w9vlN-_EuXojiz0ORcyh90keUhqW5tMShccHvEaq_wpXOJQ6ITIglsgUXNhlSuEfpEcBy4CCqKQW98bRQiTKQOtoOfgc-Ez1RHR-7esTw-U22P_H-EMk23jI3nwuYGtqOn4Vvqb4-cHOzdyE_xaVWZxeteNKhU-RexfrMaHx1PSy3T796aY7gIljcqkxra-SA1dbOsRBawwlhJwFtojzBHEs1841gJ4bgg cookie=KEYCLOAK_SESSION=master/cf248811-6d82-47e7-bf9a-7b197fb988d0/1ba9c84e-0e37-4a82-a484-c25d2c4a80fc header=Accept=*/* header=Accept-Language=en-US,en;q=0.8,de;q=0.6 header=Accept-Encoding=gzip, deflate header=DNT=1 header=Origin=https://login.vagrant.v8 header=X-Original-To=192.168.33.80 header=User-Agent=Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 header=X-Forwarded-Proto=https header=X-Forwarded-Port=443 header=X-Forwarded-For=192.168.33.1 header=Content-Length=229 header=Content-Type=application/x-www-form-urlencoded header=Cookie=KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjM5YTVkNTlmLWMyNDYtNDkwZi04ZGZkLTZhYzVhNzgyZDI5ZCIsImNpZCI6InNlY3VyaXR5LWFkbWluLWNvbnNvbGUiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9hZG1pbi9tYXN0ZXIvY29uc29sZS8iLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiOGQ5ZGI4MzctMjY2Ni00NDcxLTk0ZDgtZmFkMmIxMjA3NDQxIiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL3JlYWxtcy9tYXN0ZXIiLCJyZXNwb25zZV90eXBlIjoiY29kZSIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL2FkbWluL21hc3Rlci9jb25zb2xlLyIsInN0YXRlIjoiNTQ4ZDE5ZTUtMjlkMS00NTU2LWFjNjAtYjZjZTM1ZmJiMGU2Iiwibm9uY2UiOiI5OGY3NDFiYS03MmQwLTQ0ZDUtOGQ0ZC1jZTAxNzZhYjMyMmUiLCJyZXNwb25zZV9tb2RlIjoiZnJhZ21lbnQifX0.I0jI4nDhbYtKNrVjdlwjjBe5mtd0a8u6Dm7rQXwLE60; KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJhNjY5OWJkOS00MWQ4LTQyNWYtYjE5Ni04Y2QzNmJiZjBmNjQiLCJleHAiOjE0NjQxMTc1NjcsIm5iZiI6MCwiaWF0IjoxNDY0MDgxNTY3LCJpc3MiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9yZWFsbXMvbWFzdGVyIiwic3ViIjoiY2YyNDg4MTEtNmQ4Mi00N2U3LWJmOWEtN2IxOTdmYjk4OGQwIiwic2Vzc2lvbl9zdGF0ZSI6IjFiYTljODRlLTBlMzctNGE4Mi1hNDg0LWMyNWQyYzRhODBmYyIsInJlc291cmNlX2FjY2VzcyI6e319.E0vEe9XQJ_6IbDC_TEUfumQCJ0fS1_AOYsHh7svyGp16VC89sH9J1FQuLJfHYFVJlDTcE6o2ktLg0fLw2nLIdLOv-WXMseYr0KzudZveiLy1CZbRoPS9w9vlN-_EuXojiz0ORcyh90keUhqW5tMShccHvEaq_wpXOJQ6ITIglsgUXNhlSuEfpEcBy4CCqKQW98bRQiTKQOtoOfgc-Ez1RHR-7esTw-U22P_H-EMk23jI3nwuYGtqOn4Vvqb4-cHOzdyE_xaVWZxeteNKhU-RexfrMaHx1PSy3T796aY7gIljcqkxra-SA1dbOsRBawwlhJwFtojzBHEs1841gJ4bgg; KEYCLOAK_SESSION=master/cf248811-6d82-47e7-bf9a-7b197fb988d0/1ba9c84e-0e37-4a82-a484-c25d2c4a80fc header=Referer= https://login.vagrant.v8/auth/admin/master/console/ header=Host=login.vagrant.v8 locale=[en_US, en, de] method=POST protocol=HTTP/1.1 queryString= * remoteAddr=/192.168.33.80:54672 * remoteHost=proxy.vagrant.v8 scheme=https host=login.vagrant.v8 serverPort=443 --------------------------RESPONSE-------------------------- contentLength=123 contentType=application/json header=X-Powered-By=Undertow/1 header=Server=WildFly/10 header=Content-Type=application/json header=Content-Length=123 header=Date=Tue, 24 May 2016 09:19:27 GMT status=400 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/bd6878a8/attachment-0001.html From guybowdler at dorsetnetworks.com Tue May 24 06:48:47 2016 From: guybowdler at dorsetnetworks.com (Guy Bowdler) Date: Tue, 24 May 2016 10:48:47 +0000 Subject: [keycloak-user] redirection error with Keycloak-proxy Message-ID: <3f56c50382d2333ec4f4435350b07891@dorsetnetworks.com> Hi:) Has anybody seen this error? I have (http://host.name/appname) --> [KeyCloakProxy:80 --> nginx:8080] --> [Web apps on different boxes] where [] denotes on same box. Namespace is hostname/appname where nginx location directives proxy out again to different boxes. I've previously had this working but when I changed the keystore it all broke and haven't found the problem yet. Troubleshooting steps have been to take out the ssl entirely and try different client settings. If I remove the contraints in the proxy config, it proxies ok to the webpages, and it the constraints are in, I log in ok and then the browser goes blank with a URL like this in the address bar: http://apps.host.name/python?state=0%2F52043b01-976f-464f-8651-ebe295aac2af&code=-_odSdHkDVnID6JhPeKV2QXh_1oub5DDLP2ZLZ6pA_0.ef2bd934-2fd8-48da-a626-106712b687b1 The error stack below is from the console of the keycloak proxy. Refreshing the page, simply returns a different error of "NO STATE COOKIE". Thanks in advance for any assistance, kind regards Guy ERROR: failed to turn code into token java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:589) at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:668) at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:532) at org.keycloak.adapters.SniSSLSocketFactory.connectSocket(SniSSLSocketFactory.java:109) at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:409) at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177) at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:144) at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:131) at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446) at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55) at org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:107) at org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuthenticator.java:314) at org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:260) at org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:112) at org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110) at org.keycloak.adapters.undertow.UndertowAuthenticationMechanism.authenticate(UndertowAuthenticationMechanism.java:56) at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233) at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250) at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219) at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121) at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96) at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89) at org.keycloak.proxy.ProxyAuthenticationCallHandler.handleRequest(ProxyAuthenticationCallHandler.java:44) at org.keycloak.proxy.ConstraintMatcherHandler.handleRequest(ConstraintMatcherHandler.java:89) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) at org.keycloak.adapters.undertow.UndertowPreAuthActionsHandler.handleRequest(UndertowPreAuthActionsHandler.java:54) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.server.session.SessionAttachmentHandler.handleRequest(SessionAttachmentHandler.java:68) at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:94) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:232) at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:130) at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:56) at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:88) at org.xnio.nio.WorkerThread.run(WorkerThread.java:559) May 24, 2016 11:04:30 AM org.keycloak.adapters.OAuthRequestAuthenticator checkStateCookie WARN: No state cookie From adilelfahmi at gmail.com Tue May 24 07:07:32 2016 From: adilelfahmi at gmail.com (Harits Elfahmi) Date: Tue, 24 May 2016 18:07:32 +0700 Subject: [keycloak-user] Retrieve Roles-Groups association from LDAP Message-ID: Hello guys, We're trying to sync roles and groups from LDAP to Keycloak and vice versa. If we attach some keycloak roles to a group, can this association be synced back to LDAP? How should I config my User Federation Mapper for Group mapper? >From what I understand we can set the Membership LDAP Attribute, but I think this is to associate between groups and users, not groups and roles. Is it possible to do this, or is the group-roles association can only be configured from keycloak? Thanks -- Cheers, *Harits* Elfahmi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/d61cc0f5/attachment.html From guybowdler at dorsetnetworks.com Tue May 24 07:25:28 2016 From: guybowdler at dorsetnetworks.com (Guy Bowdler) Date: Tue, 24 May 2016 11:25:28 +0000 Subject: [keycloak-user] redirection error with Keycloak-proxy In-Reply-To: <3f56c50382d2333ec4f4435350b07891@dorsetnetworks.com> References: <3f56c50382d2333ec4f4435350b07891@dorsetnetworks.com> Message-ID: <16b8e67b70d16ff086db00f3c1709851@dorsetnetworks.com> It might be this, as we have the keycloak instance running behind another nginx proxy: https://issues.jboss.org/browse/KEYCLOAK-2054 If anyone can help confirm this is would be a massive help as the fix isn't due out until June 22 and would save unnecessary troubleshooting On 2016-05-24 10:48, Guy Bowdler wrote: > Hi:) > > Has anybody seen this error? > > I have (http://host.name/appname) --> [KeyCloakProxy:80 --> > nginx:8080] > --> [Web apps on different boxes] where [] denotes on same box. > Namespace is hostname/appname where nginx location directives proxy out > again to different boxes. > > I've previously had this working but when I changed the keystore it all > broke and haven't found the problem yet. Troubleshooting steps have > been to take out the ssl entirely and try different client settings. > If > I remove the contraints in the proxy config, it proxies ok to the > webpages, and it the constraints are in, I log in ok and then the > browser goes blank with a URL like this in the address bar: > > http://apps.host.name/python?state=0%2F52043b01-976f-464f-8651-ebe295aac2af&code=-_odSdHkDVnID6JhPeKV2QXh_1oub5DDLP2ZLZ6pA_0.ef2bd934-2fd8-48da-a626-106712b687b1 > > The error stack below is from the console of the keycloak proxy. > Refreshing the page, simply returns a different error of "NO STATE > COOKIE". > > Thanks in advance for any assistance, > > kind regards > > Guy > > > ERROR: failed to turn code into token > java.net.ConnectException: Connection refused > at java.net.PlainSocketImpl.socketConnect(Native Method) > at > java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) > at > java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) > at > java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) > at java.net.Socket.connect(Socket.java:589) > at > sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:668) > at > org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:532) > at > org.keycloak.adapters.SniSSLSocketFactory.connectSocket(SniSSLSocketFactory.java:109) > at > org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:409) > at > org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177) > at > org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:144) > at > org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:131) > at > org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611) > at > org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446) > at > org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882) > at > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) > at > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107) > at > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55) > at > org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:107) > at > org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuthenticator.java:314) > at > org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:260) > at > org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:112) > at > org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110) > at > org.keycloak.adapters.undertow.UndertowAuthenticationMechanism.authenticate(UndertowAuthenticationMechanism.java:56) > at > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233) > at > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250) > at > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219) > at > io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121) > at > io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96) > at > io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89) > at > org.keycloak.proxy.ProxyAuthenticationCallHandler.handleRequest(ProxyAuthenticationCallHandler.java:44) > at > org.keycloak.proxy.ConstraintMatcherHandler.handleRequest(ConstraintMatcherHandler.java:89) > at > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at > org.keycloak.adapters.undertow.UndertowPreAuthActionsHandler.handleRequest(UndertowPreAuthActionsHandler.java:54) > at > io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at > io.undertow.server.session.SessionAttachmentHandler.handleRequest(SessionAttachmentHandler.java:68) > at > io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:94) > at > io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > at > io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:232) > at > io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:130) > at > io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:56) > at > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at > org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at > org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:88) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:559) > > May 24, 2016 11:04:30 AM > org.keycloak.adapters.OAuthRequestAuthenticator > checkStateCookie > WARN: No state cookie > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From guybowdler at dorsetnetworks.com Tue May 24 07:34:34 2016 From: guybowdler at dorsetnetworks.com (Guy Bowdler) Date: Tue, 24 May 2016 11:34:34 +0000 Subject: [keycloak-user] redirection error with Keycloak-proxy In-Reply-To: <16b8e67b70d16ff086db00f3c1709851@dorsetnetworks.com> References: <3f56c50382d2333ec4f4435350b07891@dorsetnetworks.com> <16b8e67b70d16ff086db00f3c1709851@dorsetnetworks.com> Message-ID: <2fc15c7eff3cc6c3ac3c5a63fd3fceec@dorsetnetworks.com> Typical, spent two days faffing on this and as soon as I ask the forum, I find it. I repointed the kc proxy "auth-server-url" direct at keycloak and it works fine. Point it at the nginx proxied version of keycloak and it dies. It authenticates, and the user sessions show in the keycloak console, and SSO works, as I can go to another URL and that too shows a session but neither page renders when keyclaok is behind nginx. anyone had a similar experience? On 2016-05-24 11:25, Guy Bowdler wrote: > It might be this, as we have the keycloak instance running behind > another nginx proxy: > > https://issues.jboss.org/browse/KEYCLOAK-2054 > > If anyone can help confirm this is would be a massive help as the fix > isn't due out until June 22 and would save unnecessary troubleshooting > > > > On 2016-05-24 10:48, Guy Bowdler wrote: >> Hi:) >> >> Has anybody seen this error? >> >> I have (http://host.name/appname) --> [KeyCloakProxy:80 --> >> nginx:8080] >> --> [Web apps on different boxes] where [] denotes on same box. >> Namespace is hostname/appname where nginx location directives proxy >> out >> again to different boxes. >> >> I've previously had this working but when I changed the keystore it >> all >> broke and haven't found the problem yet. Troubleshooting steps have >> been to take out the ssl entirely and try different client settings. >> If >> I remove the contraints in the proxy config, it proxies ok to the >> webpages, and it the constraints are in, I log in ok and then the >> browser goes blank with a URL like this in the address bar: >> >> http://apps.host.name/python?state=0%2F52043b01-976f-464f-8651-ebe295aac2af&code=-_odSdHkDVnID6JhPeKV2QXh_1oub5DDLP2ZLZ6pA_0.ef2bd934-2fd8-48da-a626-106712b687b1 >> >> The error stack below is from the console of the keycloak proxy. >> Refreshing the page, simply returns a different error of "NO STATE >> COOKIE". >> >> Thanks in advance for any assistance, >> >> kind regards >> >> Guy >> >> >> ERROR: failed to turn code into token >> java.net.ConnectException: Connection refused >> at java.net.PlainSocketImpl.socketConnect(Native Method) >> at >> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) >> at >> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) >> at >> java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) >> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) >> at java.net.Socket.connect(Socket.java:589) >> at >> sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:668) >> at >> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:532) >> at >> org.keycloak.adapters.SniSSLSocketFactory.connectSocket(SniSSLSocketFactory.java:109) >> at >> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:409) >> at >> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177) >> at >> org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:144) >> at >> org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:131) >> at >> org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611) >> at >> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446) >> at >> org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882) >> at >> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) >> at >> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107) >> at >> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55) >> at >> org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:107) >> at >> org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuthenticator.java:314) >> at >> org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:260) >> at >> org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:112) >> at >> org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110) >> at >> org.keycloak.adapters.undertow.UndertowAuthenticationMechanism.authenticate(UndertowAuthenticationMechanism.java:56) >> at >> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233) >> at >> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250) >> at >> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219) >> at >> io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121) >> at >> io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96) >> at >> io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89) >> at >> org.keycloak.proxy.ProxyAuthenticationCallHandler.handleRequest(ProxyAuthenticationCallHandler.java:44) >> at >> org.keycloak.proxy.ConstraintMatcherHandler.handleRequest(ConstraintMatcherHandler.java:89) >> at >> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) >> at >> org.keycloak.adapters.undertow.UndertowPreAuthActionsHandler.handleRequest(UndertowPreAuthActionsHandler.java:54) >> at >> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) >> at >> io.undertow.server.session.SessionAttachmentHandler.handleRequest(SessionAttachmentHandler.java:68) >> at >> io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:94) >> at >> io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) >> at >> io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:232) >> at >> io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:130) >> at >> io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:56) >> at >> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) >> at >> org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) >> at >> org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:88) >> at org.xnio.nio.WorkerThread.run(WorkerThread.java:559) >> >> May 24, 2016 11:04:30 AM >> org.keycloak.adapters.OAuthRequestAuthenticator >> checkStateCookie >> WARN: No state cookie >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From sthorger at redhat.com Tue May 24 07:49:06 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 24 May 2016 13:49:06 +0200 Subject: [keycloak-user] Keycloak token exchange failure behind loadbalancer and reverse proxy In-Reply-To: References: Message-ID: Did you add ProxyPeerAddressHandler filter? That's required for AJP connector, see http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#proxy-address-forwarding On 24 May 2016 at 11:48, Niels Bertram wrote: > I am scratching my head with a specific setup problem which does not > generate any usable error messages. > > I am running a haproxy as load balancer in a vm in front an apache web > server configured as reverse proxy connecting to the keycloak server via > ajp in another VM. > > client browser (192.168.33.1) > > login.vagrant.v8 (192.168.33.80) aka proxy.vagrant.v8 is haproxy > adds X-Forwarded-For X-Forwarded-Port X-Forwarded-Proto and X-Real-Ip > > kc01.vagrant.v8 (192.168.33.81) apache reverse proxies to > wildfly on ajp port > > > Followed all the setup instructions in the documentation and if I connect > to apache proxying through to keycloak everything works fine. All web > resources are donwloaded fine however when I request a token exchange on > /auth/realms/master/protocol/openid-connect/token I get a 400 response. > The kc server log shows the corect IP address of the originating client and > the request dump from wildfly also shows the correct X-Forwarded-For > header coming in. However the query string remoteAddr=/192.168.33.80:54672 > which I believe is the one sent to the ajp connector shows some half > valid IP address which is that of the load balancer. Did anyone come across > this before? Looks like a bug of some sort. > > The symptom is a endless loop trying to log into the admin panel. > > Cheers > Niels > > > # cat standalone/log/server.log | grep -A 58 '2016-05-24 09:19:27,672' > 2016-05-24 09:19:27,672 WARN [org.keycloak.events] (default task-19) > type=CODE_TO_TOKEN_ERROR, realmId=master, clientId=admin, userId=null, > ipAddress=*192.168.33.1*, error=invalid_client_credentials, > grant_type=authorization_code > 2016-05-24 09:19:27,673 INFO [io.undertow.request.dump] (default task-19) > ----------------------------REQUEST--------------------------- > URI=/auth/realms/master/protocol/openid-connect/token > characterEncoding=null > contentLength=229 > contentType=[application/x-www-form-urlencoded] > > cookie=KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjM5YTVkNTlmLWMyNDYtNDkwZi04ZGZkLTZhYzVhNzgyZDI5ZCIsImNpZCI6InNlY3VyaXR5LWFkbWluLWNvbnNvbGUiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9hZG1pbi9tYXN0ZXIvY29uc29sZS8iLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiOGQ5ZGI4MzctMjY2Ni00NDcxLTk0ZDgtZmFkMmIxMjA3NDQxIiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL3JlYWxtcy9tYXN0ZXIiLCJyZXNwb25zZV90eXBlIjoiY29kZSIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL2FkbWluL21hc3Rlci9jb25zb2xlLyIsInN0YXRlIjoiNTQ4ZDE5ZTUtMjlkMS00NTU2LWFjNjAtYjZjZTM1ZmJiMGU2Iiwibm9uY2UiOiI5OGY3NDFiYS03MmQwLTQ0ZDUtOGQ0ZC1jZTAxNzZhYjMyMmUiLCJyZXNwb25zZV9tb2RlIjoiZnJhZ21lbnQifX0.I0jI4nDhbYtKNrVjdlwjjBe5mtd0a8u6Dm7rQXwLE60 > > cookie=KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJhNjY5OWJkOS00MWQ4LTQyNWYtYjE5Ni04Y2QzNmJiZjBmNjQiLCJleHAiOjE0NjQxMTc1NjcsIm5iZiI6MCwiaWF0IjoxNDY0MDgxNTY3LCJpc3MiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9yZWFsbXMvbWFzdGVyIiwic3ViIjoiY2YyNDg4MTEtNmQ4Mi00N2U3LWJmOWEtN2IxOTdmYjk4OGQwIiwic2Vzc2lvbl9zdGF0ZSI6IjFiYTljODRlLTBlMzctNGE4Mi1hNDg0LWMyNWQyYzRhODBmYyIsInJlc291cmNlX2FjY2VzcyI6e319.E0vEe9XQJ_6IbDC_TEUfumQCJ0fS1_AOYsHh7svyGp16VC89sH9J1FQuLJfHYFVJlDTcE6o2ktLg0fLw2nLIdLOv-WXMseYr0KzudZveiLy1CZbRoPS9w9vlN-_EuXojiz0ORcyh90keUhqW5tMShccHvEaq_wpXOJQ6ITIglsgUXNhlSuEfpEcBy4CCqKQW98bRQiTKQOtoOfgc-Ez1RHR-7esTw-U22P_H-EMk23jI3nwuYGtqOn4Vvqb4-cHOzdyE_xaVWZxeteNKhU-RexfrMaHx1PSy3T796aY7gIljcqkxra-SA1dbOsRBawwlhJwFtojzBHEs1841gJ4bgg > > cookie=KEYCLOAK_SESSION=master/cf248811-6d82-47e7-bf9a-7b197fb988d0/1ba9c84e-0e37-4a82-a484-c25d2c4a80fc > header=Accept=*/* > header=Accept-Language=en-US,en;q=0.8,de;q=0.6 > header=Accept-Encoding=gzip, deflate > header=DNT=1 > header=Origin=https://login.vagrant.v8 > header=X-Original-To=192.168.33.80 > header=User-Agent=Mozilla/5.0 (Windows NT 6.1; WOW64) > AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 > header=X-Forwarded-Proto=https > header=X-Forwarded-Port=443 > header=X-Forwarded-For=192.168.33.1 > header=Content-Length=229 > header=Content-Type=application/x-www-form-urlencoded > > header=Cookie=KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjM5YTVkNTlmLWMyNDYtNDkwZi04ZGZkLTZhYzVhNzgyZDI5ZCIsImNpZCI6InNlY3VyaXR5LWFkbWluLWNvbnNvbGUiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9hZG1pbi9tYXN0ZXIvY29uc29sZS8iLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiOGQ5ZGI4MzctMjY2Ni00NDcxLTk0ZDgtZmFkMmIxMjA3NDQxIiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL3JlYWxtcy9tYXN0ZXIiLCJyZXNwb25zZV90eXBlIjoiY29kZSIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL2FkbWluL21hc3Rlci9jb25zb2xlLyIsInN0YXRlIjoiNTQ4ZDE5ZTUtMjlkMS00NTU2LWFjNjAtYjZjZTM1ZmJiMGU2Iiwibm9uY2UiOiI5OGY3NDFiYS03MmQwLTQ0ZDUtOGQ0ZC1jZTAxNzZhYjMyMmUiLCJyZXNwb25zZV9tb2RlIjoiZnJhZ21lbnQifX0.I0jI4nDhbYtKNrVjdlwjjBe5mtd0a8u6Dm7rQXwLE60; > KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJhNjY5OWJkOS00MWQ4LTQyNWYtYjE5Ni04Y2QzNmJiZjBmNjQiLCJleHAiOjE0NjQxMTc1NjcsIm5iZiI6MCwiaWF0IjoxNDY0MDgxNTY3LCJpc3MiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9yZWFsbXMvbWFzdGVyIiwic3ViIjoiY2YyNDg4MTEtNmQ4Mi00N2U3LWJmOWEtN2IxOTdmYjk4OGQwIiwic2Vzc2lvbl9zdGF0ZSI6IjFiYTljODRlLTBlMzctNGE4Mi1hNDg0LWMyNWQyYzRhODBmYyIsInJlc291cmNlX2FjY2VzcyI6e319.E0vEe9XQJ_6IbDC_TEUfumQCJ0fS1_AOYsHh7svyGp16VC89sH9J1FQuLJfHYFVJlDTcE6o2ktLg0fLw2nLIdLOv-WXMseYr0KzudZveiLy1CZbRoPS9w9vlN-_EuXojiz0ORcyh90keUhqW5tMShccHvEaq_wpXOJQ6ITIglsgUXNhlSuEfpEcBy4CCqKQW98bRQiTKQOtoOfgc-Ez1RHR-7esTw-U22P_H-EMk23jI3nwuYGtqOn4Vvqb4-cHOzdyE_xaVWZxeteNKhU-RexfrMaHx1PSy3T796aY7gIljcqkxra-SA1dbOsRBawwlhJwFtojzBHEs1841gJ4bgg; > KEYCLOAK_SESSION=master/cf248811-6d82-47e7-bf9a-7b197fb988d0/1ba9c84e-0e37-4a82-a484-c25d2c4a80fc > header=Referer= > https://login.vagrant.v8/auth/admin/master/console/ > header=Host=login.vagrant.v8 > locale=[en_US, en, de] > method=POST > protocol=HTTP/1.1 > queryString= > * remoteAddr=/192.168.33.80:54672 * > remoteHost=proxy.vagrant.v8 > scheme=https > host=login.vagrant.v8 > serverPort=443 > --------------------------RESPONSE-------------------------- > contentLength=123 > contentType=application/json > header=X-Powered-By=Undertow/1 > header=Server=WildFly/10 > header=Content-Type=application/json > header=Content-Length=123 > header=Date=Tue, 24 May 2016 09:19:27 GMT > status=400 > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/574d744c/attachment.html From jayapriya.atheesan at gmail.com Tue May 24 08:02:38 2016 From: jayapriya.atheesan at gmail.com (Jayapriya Atheesan) Date: Tue, 24 May 2016 17:32:38 +0530 Subject: [keycloak-user] Resetting password In-Reply-To: <5742a5d9.0cb9420a.b96f6.6132@mx.google.com> References: <5742a5d9.0cb9420a.b96f6.6132@mx.google.com> Message-ID: Hi All, Any help would be appreciated. Thanks, Jayapriya Atheesan On Mon, May 23, 2016 at 12:10 PM, JAYAPRIYA ATHEESAN < jayapriya.atheesan at gmail.com> wrote: > Hi, > > > > When a user clicks on reset password/forget password and enters an email > id which is not registered with keycloak, it does not show any error. > > Is there any option to give an error message to the user saying ?email id > doesn?t exist?. > > Note : We are using keycloak 1.6.0Final. > > > > Thanks, > > Jayapriya Atheesan > > > -- *Regards,* Jayapriya Atheesan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/90ba47be/attachment.html From manuel.herzberg at atos.net Tue May 24 08:21:53 2016 From: manuel.herzberg at atos.net (Herzberg, Manuel) Date: Tue, 24 May 2016 12:21:53 +0000 Subject: [keycloak-user] Keycloak OAuth High CPU usage In-Reply-To: References: Message-ID: Hello, I am evaluating the Keycloak performance. Here my practical experience. My scenario is the same as Vaibhav?s: ? Large amount of token have to be generated. This is done by requesting the Keycloak token REST endpoint via http. The different realms I am using have 1k 2k 3k and 4k keys for signing the tokens. (RSA) Longer keys result to longer runtime to generate these tokens. ? I have more than 10k user each realm. Each request includes a new user. Requests look like this: host1:8080/auth/realms/demo-3072/protocol/openid-connect/token/ with data: username=testuser1&password=password&client_id=customer-portal&grant_type=password ? The response includes 3 tokens(access, refresh and id). In total more than 30 000 token have to be generated and signed. @Stian. You wrote you are able to invoke 10000 token refreshes in under 60 seconds. A token refresh includes access, refresh and id token right? Can you explain us your scenario? How do you get such a high number? Some more results: just signing 3000 Token (800 Byte each) with a 2k key takes me 20 seconds (laptop i5-4310U, 12gb ram). I am doing this outside Keycloak with my own java program, but with the same implementation Keycloak is using. (sign() method in RSAProvider). The Keycloak implementation is signing tokens with RSA. HMAC and ECC are implemented as well as I saw in the code. Changing from RSA to HMAC or ECC is not possible in current release as i experienced. Are there plans to provide this in future? Defining this in a configuration file or via parameters would be nice. Best regards, Manuel Herzberg From: keycloak-user-bounces at lists.jboss.org [mailto:keycloak-user-bounces at lists.jboss.org] On Behalf Of Stian Thorgersen Sent: Tuesday, May 24, 2016 8:31 AM To: Vaibhav Naldurgkar Cc: keycloak-user at lists.jboss.org Subject: Re: [keycloak-user] Keycloak OAuth High CPU usage On 23 May 2016 at 10:02, Vaibhav Naldurgkar > wrote: Yes, the direct access grant is ON for this client. I am trying to understand what you mean by ?not planning on using web based flow?? Could you provide more clarification on this. If you are planning to do the web based flow (authorization code grant flow) you should test with that rather than direct grant. That being said the direct grant should still perform as well. This is what the scenario I am trying to execute and still have high CPU usages for KeyCloak Java process. ? The end point URL /auth/realms/master/protocol/openid-connect/token has been called by Jmeter for 20 concurrent users per seconds to generate the tokens. ? Even if used with crul command like ?curl -X POST -d "=admin&password=admin&password&client_id=HelloTest&grant_type=password" http://localhost:8080/auth/realms/master/protocol/openid-connect/token? , in this case also the CPU utilizations goes around 100%. ? After around 3 seconds of the test, in the output of top command on the KeyCloak server the CPU% for keycloak java process goes beyond 100%. Would it be possible for you to have a quick call for faster fix of this issue. This performance issue is holding to move KeyCloak to use as OAuth provider. If any other way is convenient for you please let me know for further discussion. Your JMeter test is using 20 concurrent threads to send as many requests to the direct grant api as it can. This will obviously cause Keycloak to consume a high percentage of the CPU. Especially if you are running everything on localhost as the network isn't going to be a bottleneck. Neither will the database as Keycloak caches everything in memory. The bottleneck will be the CPU. Authenticating users and obtaining a token requires password hashing as well as signing tokens, both are mainly CPU intensive. As you are using the direct grant api there's also less network traffic. You need to add some reports to your JMeter test so you can see how many requests Keycloak can handle. That way you can find out how many users can be authenticated per-second on your machine. If you only have 500 users remember they won't all login at the same time (seconds). Even if they all login at 9am sharp they will be spread out over 10 minutes or so, which would only be 1.2 logins/second. Thanks, Vaibhav From: Stian Thorgersen [mailto:sthorger at redhat.com] Sent: Monday, May 23, 2016 12:01 PM To: Vaibhav Naldurgkar Cc: keycloak-user at lists.jboss.org Subject: Re: [keycloak-user] Keycloak OAuth High CPU usage You are using direct grant to authenticate a user and obtain a token in the example above. This authenticates and creates a new session for each request. Are you not planning on using web based flow? What do you have password hashing intervals set to? Verifying password is CPU intensive, more than signing tokens. It shouldn't matter that user is stored in RedHat IdM as the user would be cached in Keycloak after first authentication, but it may be an idea to just double check by trying to authenticate to a user in Keycloak and not RH IdM. What results are you actually getting? On 20 May 2016 at 11:27, Vaibhav Naldurgkar > wrote: Hi Stian, After reading your tests results of 10000 token refreshes in under 60 seconds on your laptop, I am sure I am not following correct configuration and the documents are missing for reference. Could you please verify the below steps along with the screen-shots for the steps which I am following for the adding client and testing the Load performance using Jmeter. Please suggest if any changes are needed in the client configuration. In this case we are obtaining the token for user from KeyCloak. In my case the user have been stored on RedHat IdM which has been federated using KeyCloak. Step 1. Create new client called ?LoadTest? , use the Client Protocol as ?Openid-connect?. Used all defaults values post save of the client action. Step 2. Start the load tests using Jmeter and using the path as ?/auth/realms/master/protocol/openid-connect/token? . Used 20 Number of Threads and used Post method. Below is the screen-shot for the step 1 related to Add Client. [cid:image001.png at 01D1B5C6.C96CD540] Below is the screen shot for the load test using Jmeter. In this case the Client ID was used as HelloTest. [cid:image002.png at 01D1B5C6.C96CD540] Http requests. [cid:image003.png at 01D1B5C6.C96CD540] Thanks, Vaibhav From: Stian Thorgersen [mailto:sthorger at redhat.com] Sent: Friday, May 20, 2016 1:01 PM To: Vaibhav Naldurgkar Cc: keycloak-user at lists.jboss.org Subject: Re: [keycloak-user] Keycloak OAuth High CPU usage Can you please elaborate a bit more on how your are testing scenario is? I'm a bit confused to what you are testing when you are talking about generating new tokens. Are you using OIDC or SAML? Are you talking about code->token exchanges, refresh token requests, or what? To test if your hardware is capable to deal with the load you need to test logins (verifying passwords are CPU intensive) as well as obtaining tokens (both code->token, done after login, and refreshing token, done ~1 min or so by active users, but most users won't continuously use the application). 500 users should be no problem at all. As an example with a single thread (which will use a single core) I could invoke 10000 token refreshes in under 60 seconds on my laptop. So a single core on my laptop should be able to handle 500 users. On 20 May 2016 at 08:00, Vaibhav Naldurgkar > wrote: Hi Stian, Thank you for your reply. The new tokens needs to be generated for each user, which is needed from security point of view. The performance tests were also conducted using single Admin user and token for admin user; however in that case the performance was not good. In between 15th to 20th admin token access requests ? the CPU usage of keycloak Java process was crossing 90 to 120% mark. As you have mentioned, Creating tokes are expected to be a bit CPU intensive ? what should be the server configuration in terms of CPU to deal with more than 500 users to use keycloak as OAuth provider. Thanks, Vaibhav From: Stian Thorgersen [mailto:sthorger at redhat.com] Sent: Thursday, May 19, 2016 6:28 PM To: Vaibhav Naldurgkar Cc: keycloak-user at lists.jboss.org Subject: Re: [keycloak-user] Keycloak OAuth High CPU usage Creating tokes are expected to be a bit CPU intensive as they need to be signed. When you say you try to generate tokens for 10-20 users are you doing performance tests and having 10-20 threads generating tokens? It shouldn't make any difference if you have 10 or if you have 200 users, it's the total number of tokens that can be generated that's an issue. Having 200 concurrent users with a access token timeout of 60 seconds should mean that you need to be able to generate roughly 200/60 tokens = 3.3 tokens/sec. On 19 May 2016 at 13:24, Vaibhav Naldurgkar > wrote: Hi All, I am using Keycloak 1.9.3 with default configuration. Keycloak server is installed on RHEL 6.5 virtual image with 4 CPU , 8 GB RAM and java version is jdk1.8.0_73 We are trying to use keycloak as a OAuth provider. But when we try and generate token(http:///auth/realms/master/protocol/openid-connect/token) for more than 10-20 users the server gets too slow and cpu usage goes over 100%. Any pointers on how to improve performance of keycloak OAuth provider. We need to support at least 200 concurrent users. Thanks, Vaibhav DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/b704e1aa/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 101405 bytes Desc: image001.png Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/b704e1aa/attachment-0003.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 11865 bytes Desc: image002.png Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/b704e1aa/attachment-0004.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 18447 bytes Desc: image003.png Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/b704e1aa/attachment-0005.png From haimv at perfectomobile.com Tue May 24 08:27:19 2016 From: haimv at perfectomobile.com (Haim Vana) Date: Tue, 24 May 2016 12:27:19 +0000 Subject: [keycloak-user] How to set realm tokens units programmatically Message-ID: Hi, When I am setting realm tokens programmatically, for example 'Sso Session Idle Timeout', how can I set its units ? This is how I am setting the parameter programmatically: realmRepresentation.setSsoSessionIdleTimeout(120); However I couldn't find how to set the units from minutes to hours, when I am setting the above it is displayed (and act !) as 2 minutes in the UI. Any advice will be appreciated. Thanks, Haim. The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/f3d04bb6/attachment.html From thomas.raehalme at aitiofinland.com Tue May 24 08:36:54 2016 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Tue, 24 May 2016 15:36:54 +0300 Subject: [keycloak-user] Resetting password In-Reply-To: References: <5742a5d9.0cb9420a.b96f6.6132@mx.google.com> Message-ID: Hi! For security reasons I don't think Keycloak should reveal whether or not the account exists. Instead the message shown to the user in response should be something like "If the email address was found, you should soon receive further instructions." Best regards, Thomas On Tue, May 24, 2016 at 3:02 PM, Jayapriya Atheesan < jayapriya.atheesan at gmail.com> wrote: > Hi All, > > Any help would be appreciated. > > Thanks, > Jayapriya Atheesan > > On Mon, May 23, 2016 at 12:10 PM, JAYAPRIYA ATHEESAN < > jayapriya.atheesan at gmail.com> wrote: > >> Hi, >> >> >> >> When a user clicks on reset password/forget password and enters an email >> id which is not registered with keycloak, it does not show any error. >> >> Is there any option to give an error message to the user saying ?email id >> doesn?t exist?. >> >> Note : We are using keycloak 1.6.0Final. >> >> >> >> Thanks, >> >> Jayapriya Atheesan >> >> >> > > > > -- > *Regards,* > Jayapriya Atheesan > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/14ebf058/attachment.html From nielsbne at gmail.com Tue May 24 08:41:04 2016 From: nielsbne at gmail.com (Niels Bertram) Date: Tue, 24 May 2016 22:41:04 +1000 Subject: [keycloak-user] Keycloak token exchange failure behind loadbalancer and reverse proxy In-Reply-To: References: Message-ID: Yes I can confirm the filter is correctly added. I also have all the other required settings configured (hopefully correctly). It works reliably when I target the apache reverse proxy but only falls appart when I load balance through another "hop". I switched on debug on keycloak and can see a bit more details of the failure (logs below). I wonder what "AuthenticationFlowException: Client was not identified by any client authenticator" means. ... ... 2016-05-24 09:59:26,176 DEBUG [org.keycloak.services] (default task-11) AUTHENTICATE CLIENT 2016-05-24 09:59:26,176 DEBUG [org.keycloak.services] (default task-11) client authenticator: client-secret 2016-05-24 09:59:26,179 DEBUG [org.keycloak.services] (default task-11) client authenticator: client-jwt 2016-05-24 09:59:26,180 DEBUG [org.keycloak.services] (default task-11) KC-SERVICES0014: Failed client authentication: org.keycloak.authentication.AuthenticationFlowException: Client was not identified by any client authenticator at org.keycloak.authentication.ClientAuthenticationFlow.processFlow(ClientAuthenticationFlow.java:101) at org.keycloak.authentication.AuthenticationProcessor.authenticateClient(AuthenticationProcessor.java:673) at org.keycloak.protocol.oidc.utils.AuthorizeClientUtil.authorizeClient(AuthorizeClientUtil.java:42) at org.keycloak.protocol.oidc.endpoints.TokenEndpoint.checkClient(TokenEndpoint.java:163) at org.keycloak.protocol.oidc.endpoints.TokenEndpoint.build(TokenEndpoint.java:117) at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107) at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133) at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:88) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) 2016-05-24 09:59:26,180 WARN [org.keycloak.events] (default task-11) type=CODE_TO_TOKEN_ERROR, realmId=master, clientId=admin, userId=null, ipAddress=192.168.33.1, error=invalid_client_credentials, grant_type=authorization_code 2016-05-24 09:59:26,863 DEBUG [org.keycloak.services] (default task-8) replacing relative valid redirect with: https://login.vagrant.v8/auth/admin/master/console/* 2016-05-24 09:59:26,867 DEBUG [org.keycloak.services] (default task-8) AUTHENTICATE 2016-05-24 09:59:26,867 DEBUG [org.keycloak.services] (default task-8) AUTHENTICATE ONLY 2016-05-24 09:59:26,867 DEBUG [org.keycloak.services] (default task-8) processFlow 2016-05-24 09:59:26,868 DEBUG [org.keycloak.services] (default task-8) check execution: auth-cookie requirement: ALTERNATIVE 2016-05-24 09:59:26,868 DEBUG [org.keycloak.services] (default task-8) authenticator: auth-cookie 2016-05-24 09:59:26,868 DEBUG [org.keycloak.services] (default task-8) invoke authenticator.authenticate 2016-05-24 09:59:26,869 DEBUG [org.keycloak.services] (default task-8) token active - active: true, issued-at: 1,464,083,965, not-before: 0 2016-05-24 09:59:26,869 DEBUG [org.keycloak.services] (default task-8) authenticator SUCCESS: auth-cookie 2016-05-24 09:59:26,873 DEBUG [org.keycloak.services] (default task-8) check execution: auth-spnego requirement: DISABLED 2016-05-24 09:59:26,873 DEBUG [org.keycloak.services] (default task-8) execution is processed 2016-05-24 09:59:26,873 DEBUG [org.keycloak.services] (default task-8) check execution: null requirement: ALTERNATIVE 2016-05-24 09:59:26,873 DEBUG [org.keycloak.services] (default task-8) Skip alternative execution 2016-05-24 09:59:26,874 DEBUG [org.keycloak.events] (default task-8) type=LOGIN, realmId=master, clientId=security-admin-console, userId=cf248811-6d82-47e7-bf9a-7b197fb988d0, ipAddress=192.168.33.1, auth_method=openid-connect, auth_type=code, response_type=code, redirect_uri=https://login.vagrant.v8/auth/admin/master/console/, consent=no_consent_required, code_id=8215bbb3-a592-47e0-9c28-c274bccc61b5, response_mode=fragment, username=admin 2016-05-24 09:59:26,891 DEBUG [org.keycloak.services] (default task-8) Create login cookie - name: KEYCLOAK_IDENTITY, path: /auth/realms/master, max-age: -1 2016-05-24 09:59:26,892 DEBUG [org.keycloak.services] (default task-8) redirectAccessCode: state: ae0d05d7-95d9-40a0-9a75-7e4e4fb7830e 2016-05-24 09:59:27,472 DEBUG [org.keycloak.services] (default task-11) AUTHENTICATE CLIENT 2016-05-24 09:59:27,472 DEBUG [org.keycloak.services] (default task-11) client authenticator: client-secret 2016-05-24 09:59:27,474 DEBUG [org.keycloak.services] (default task-11) client authenticator: client-jwt 2016-05-24 09:59:27,474 DEBUG [org.keycloak.services] (default task-11) KC-SERVICES0014: Failed client authentication: org.keycloak.authentication.AuthenticationFlowException: Client was not identified by any client authenticator at org.keycloak.authentication.ClientAuthenticationFlow.processFlow(ClientAuthenticationFlow.java:101) at org.keycloak.authentication.AuthenticationProcessor.authenticateClient(AuthenticationProcessor.java:673) at org.keycloak.protocol.oidc.utils.AuthorizeClientUtil.authorizeClient(AuthorizeClientUtil.java:42) at org.keycloak.protocol.oidc.endpoints.TokenEndpoint.checkClient(TokenEndpoint.java:163) at org.keycloak.protocol.oidc.endpoints.TokenEndpoint.build(TokenEndpoint.java:117) at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107) at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133) at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:88) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) 2016-05-24 09:59:27,478 WARN [org.keycloak.events] (default task-11) type=CODE_TO_TOKEN_ERROR, realmId=master, clientId=admin, userId=null, ipAddress=192.168.33.1, error=invalid_client_credentials, grant_type=authorization_code 2016-05-24 09:59:28,209 DEBUG [org.keycloak.services] (default task-8) replacing relative valid redirect with: https://login.vagrant.v8/auth/admin/master/console/* 2016-05-24 09:59:28,211 DEBUG [org.keycloak.services] (default task-8) AUTHENTICATE 2016-05-24 09:59:28,218 DEBUG [org.keycloak.services] (default task-8) AUTHENTICATE ONLY 2016-05-24 09:59:28,218 DEBUG [org.keycloak.services] (default task-8) processFlow 2016-05-24 09:59:28,219 DEBUG [org.keycloak.services] (default task-8) check execution: auth-cookie requirement: ALTERNATIVE 2016-05-24 09:59:28,219 DEBUG [org.keycloak.services] (default task-8) authenticator: auth-cookie 2016-05-24 09:59:28,219 DEBUG [org.keycloak.services] (default task-8) invoke authenticator.authenticate 2016-05-24 09:59:28,220 DEBUG [org.keycloak.services] (default task-8) token active - active: true, issued-at: 1,464,083,966, not-before: 0 2016-05-24 09:59:28,222 DEBUG [org.keycloak.services] (default task-8) authenticator SUCCESS: auth-cookie 2016-05-24 09:59:28,222 DEBUG [org.keycloak.services] (default task-8) check execution: auth-spnego requirement: DISABLED 2016-05-24 09:59:28,222 DEBUG [org.keycloak.services] (default task-8) execution is processed 2016-05-24 09:59:28,222 DEBUG [org.keycloak.services] (default task-8) check execution: null requirement: ALTERNATIVE 2016-05-24 09:59:28,222 DEBUG [org.keycloak.services] (default task-8) Skip alternative execution 2016-05-24 09:59:28,223 DEBUG [org.keycloak.events] (default task-8) type=LOGIN, realmId=master, clientId=security-admin-console, userId=cf248811-6d82-47e7-bf9a-7b197fb988d0, ipAddress=192.168.33.1, auth_method=openid-connect, auth_type=code, response_type=code, redirect_uri=https://login.vagrant.v8/auth/admin/master/console/, consent=no_consent_required, code_id=7f9dbb5c-651a-4cc4-a248-91637c354fa5, response_mode=fragment, username=admin 2016-05-24 09:59:28,255 DEBUG [org.keycloak.services] (default task-8) Create login cookie - name: KEYCLOAK_IDENTITY, path: /auth/realms/master, max-age: -1 2016-05-24 09:59:28,256 DEBUG [org.keycloak.services] (default task-8) redirectAccessCode: state: 89b303fd-f77e-4b23-8de0-2c517304e671 2016-05-24 09:59:28,612 DEBUG [org.keycloak.services] (default task-11) AUTHENTICATE CLIENT 2016-05-24 09:59:28,612 DEBUG [org.keycloak.services] (default task-11) client authenticator: client-secret 2016-05-24 09:59:28,613 DEBUG [org.keycloak.services] (default task-11) client authenticator: client-jwt 2016-05-24 09:59:28,614 DEBUG [org.keycloak.services] (default task-11) KC-SERVICES0014: Failed client authentication: org.keycloak.authentication.AuthenticationFlowException: Client was not identified by any client authenticator at org.keycloak.authentication.ClientAuthenticationFlow.processFlow(ClientAuthenticationFlow.java:101) at org.keycloak.authentication.AuthenticationProcessor.authenticateClient(AuthenticationProcessor.java:673) at org.keycloak.protocol.oidc.utils.AuthorizeClientUtil.authorizeClient(AuthorizeClientUtil.java:42) at org.keycloak.protocol.oidc.endpoints.TokenEndpoint.checkClient(TokenEndpoint.java:163) at org.keycloak.protocol.oidc.endpoints.TokenEndpoint.build(TokenEndpoint.java:117) at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107) at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133) at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:88) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) 2016-05-24 09:59:28,614 WARN [org.keycloak.events] (default task-11) type=CODE_TO_TOKEN_ERROR, realmId=master, clientId=admin, userId=null, ipAddress=192.168.33.1, error=invalid_client_credentials, grant_type=authorization_code 2016-05-24 09:59:28,692 INFO [io.undertow.request.dump] (default task-11) ----------------------------REQUEST--------------------------- URI=/auth/realms/master/protocol/openid-connect/token characterEncoding=null contentLength=229 contentType=[application/x-www-form-urlencoded] cookie=KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjdmOWRiYjVjLTY1MWEtNGNjNC1hMjQ4LTkxNjM3YzM1NGZhNSIsImNpZCI6InNlY3VyaXR5LWFkbWluLWNvbnNvbGUiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9hZG1pbi9tYXN0ZXIvY29uc29sZS8iLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiYjg3OTM2Y2ItZTg1OC00NDhlLWJmMTAtNGNkYjQzMDFkMTg2IiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL3JlYWxtcy9tYXN0ZXIiLCJyZXNwb25zZV90eXBlIjoiY29kZSIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL2FkbWluL21hc3Rlci9jb25zb2xlLyIsInN0YXRlIjoiODliMzAzZmQtZjc3ZS00YjIzLThkZTAtMmM1MTczMDRlNjcxIiwibm9uY2UiOiI1MzY0YTRhZS0wNzI3LTQwYWItOWEyMi0yN2ExZDQ5NjVmNTkiLCJyZXNwb25zZV9tb2RlIjoiZnJhZ21lbnQifX0.7Xnk589FgD_9RulKC4V48gn-056yVxa_DdIGm4Hpgj8 cookie=KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI5ZjRmNWU3OS02NWYxLTQ0M2ItOGI5YS1hZWI4NzZmYmNkNjIiLCJleHAiOjE0NjQxMTk5NjgsIm5iZiI6MCwiaWF0IjoxNDY0MDgzOTY4LCJpc3MiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9yZWFsbXMvbWFzdGVyIiwic3ViIjoiY2YyNDg4MTEtNmQ4Mi00N2U3LWJmOWEtN2IxOTdmYjk4OGQwIiwic2Vzc2lvbl9zdGF0ZSI6ImQzYjAxY2Q1LWQxNWEtNGQ2OS05MTQ3LWE1YTEzYWI4MjQxNiIsInJlc291cmNlX2FjY2VzcyI6e319.eiDWSR8eeIdX7AKZiWI3e9moUD9ZuD-h88XX31JRMio_FmqSvMgRHcZtkVjjrLnjcmWn7X4jIcITARk-TiywjfAKotkPYodgCyxsmln5LRQeV3SYXltCGWKmsFmq0BsMjQbfstjdR9V9Xh7daiyRNxLGcoYitEEOeKboMjbGwZw11jggaTRifpNYp-M9GtTBvHSJg6RFdmm0QTLeJm9OgOvBzdRlKwGTUcJeqJxuNWgd4XqPS5vbpliDsfuvekC8VFeDB_UGci1hCIEoMy0-tlpwPLP_xGbCd5L8XFKrr0shoGbQlyJjFZB49VtJlHLkd8F15mZQxJ1G9BWj_wKINw cookie=KEYCLOAK_SESSION=master/cf248811-6d82-47e7-bf9a-7b197fb988d0/d3b01cd5-d15a-4d69-9147-a5a13ab82416 header=X-Real-Ip=192.168.33.1 header=Accept-Encoding=gzip, deflate header=DNT=1 header=Origin=https://login.vagrant.v8 header=X-Forwarded-Port=443 header=X-Forwarded-For=192.168.33.1 header=Cookie=KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjdmOWRiYjVjLTY1MWEtNGNjNC1hMjQ4LTkxNjM3YzM1NGZhNSIsImNpZCI6InNlY3VyaXR5LWFkbWluLWNvbnNvbGUiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9hZG1pbi9tYXN0ZXIvY29uc29sZS8iLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiYjg3OTM2Y2ItZTg1OC00NDhlLWJmMTAtNGNkYjQzMDFkMTg2IiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL3JlYWxtcy9tYXN0ZXIiLCJyZXNwb25zZV90eXBlIjoiY29kZSIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL2FkbWluL21hc3Rlci9jb25zb2xlLyIsInN0YXRlIjoiODliMzAzZmQtZjc3ZS00YjIzLThkZTAtMmM1MTczMDRlNjcxIiwibm9uY2UiOiI1MzY0YTRhZS0wNzI3LTQwYWItOWEyMi0yN2ExZDQ5NjVmNTkiLCJyZXNwb25zZV9tb2RlIjoiZnJhZ21lbnQifX0.7Xnk589FgD_9RulKC4V48gn-056yVxa_DdIGm4Hpgj8; KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI5ZjRmNWU3OS02NWYxLTQ0M2ItOGI5YS1hZWI4NzZmYmNkNjIiLCJleHAiOjE0NjQxMTk5NjgsIm5iZiI6MCwiaWF0IjoxNDY0MDgzOTY4LCJpc3MiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9yZWFsbXMvbWFzdGVyIiwic3ViIjoiY2YyNDg4MTEtNmQ4Mi00N2U3LWJmOWEtN2IxOTdmYjk4OGQwIiwic2Vzc2lvbl9zdGF0ZSI6ImQzYjAxY2Q1LWQxNWEtNGQ2OS05MTQ3LWE1YTEzYWI4MjQxNiIsInJlc291cmNlX2FjY2VzcyI6e319.eiDWSR8eeIdX7AKZiWI3e9moUD9ZuD-h88XX31JRMio_FmqSvMgRHcZtkVjjrLnjcmWn7X4jIcITARk-TiywjfAKotkPYodgCyxsmln5LRQeV3SYXltCGWKmsFmq0BsMjQbfstjdR9V9Xh7daiyRNxLGcoYitEEOeKboMjbGwZw11jggaTRifpNYp-M9GtTBvHSJg6RFdmm0QTLeJm9OgOvBzdRlKwGTUcJeqJxuNWgd4XqPS5vbpliDsfuvekC8VFeDB_UGci1hCIEoMy0-tlpwPLP_xGbCd5L8XFKrr0shoGbQlyJjFZB49VtJlHLkd8F15mZQxJ1G9BWj_wKINw; KEYCLOAK_SESSION=master/cf248811-6d82-47e7-bf9a-7b197fb988d0/d3b01cd5-d15a-4d69-9147-a5a13ab82416 header=Referer= https://login.vagrant.v8/auth/admin/master/console/ header=Host=login.vagrant.v8 header=Accept=*/* header=Accept-Language=en-US,en;q=0.8,de;q=0.6 header=X-Original-To=192.168.33.80 header=User-Agent=Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 header=Authorization=Basic YWRtaW46Y2hhbmdlbWU= header=X-Forwarded-Proto=https header=Content-Length=229 header=Content-Type=application/x-www-form-urlencoded locale=[en_US, en, de] method=POST protocol=HTTP/1.1 queryString= remoteAddr=/192.168.33.80:55892 remoteHost=proxy.vagrant.v8 scheme=https host=login.vagrant.v8 serverPort=443 --------------------------RESPONSE-------------------------- contentLength=123 contentType=application/json header=X-Powered-By=Undertow/1 header=Server=WildFly/10 header=Content-Type=application/json header=Content-Length=123 header=Date=Tue, 24 May 2016 09:59:28 GMT status=400 On Tue, May 24, 2016 at 9:49 PM, Stian Thorgersen wrote: > Did you add ProxyPeerAddressHandler filter? That's required for AJP > connector, see > http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#proxy-address-forwarding > > On 24 May 2016 at 11:48, Niels Bertram wrote: > >> I am scratching my head with a specific setup problem which does not >> generate any usable error messages. >> >> I am running a haproxy as load balancer in a vm in front an apache web >> server configured as reverse proxy connecting to the keycloak server via >> ajp in another VM. >> >> client browser (192.168.33.1) >> >> login.vagrant.v8 (192.168.33.80) aka proxy.vagrant.v8 is haproxy >> adds X-Forwarded-For X-Forwarded-Port X-Forwarded-Proto and X-Real-Ip >> >> kc01.vagrant.v8 (192.168.33.81) apache reverse proxies to >> wildfly on ajp port >> >> >> Followed all the setup instructions in the documentation and if I connect >> to apache proxying through to keycloak everything works fine. All web >> resources are donwloaded fine however when I request a token exchange on >> /auth/realms/master/protocol/openid-connect/token I get a 400 response. >> The kc server log shows the corect IP address of the originating client and >> the request dump from wildfly also shows the correct X-Forwarded-For >> header coming in. However the query string remoteAddr=/ >> 192.168.33.80:54672 which I believe is the one sent to the ajp connector >> shows some half valid IP address which is that of the load balancer. Did >> anyone come across this before? Looks like a bug of some sort. >> >> The symptom is a endless loop trying to log into the admin panel. >> >> Cheers >> Niels >> >> >> # cat standalone/log/server.log | grep -A 58 '2016-05-24 09:19:27,672' >> 2016-05-24 09:19:27,672 WARN [org.keycloak.events] (default task-19) >> type=CODE_TO_TOKEN_ERROR, realmId=master, clientId=admin, userId=null, >> ipAddress=*192.168.33.1*, error=invalid_client_credentials, >> grant_type=authorization_code >> 2016-05-24 09:19:27,673 INFO [io.undertow.request.dump] (default task-19) >> ----------------------------REQUEST--------------------------- >> URI=/auth/realms/master/protocol/openid-connect/token >> characterEncoding=null >> contentLength=229 >> contentType=[application/x-www-form-urlencoded] >> >> cookie=KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjM5YTVkNTlmLWMyNDYtNDkwZi04ZGZkLTZhYzVhNzgyZDI5ZCIsImNpZCI6InNlY3VyaXR5LWFkbWluLWNvbnNvbGUiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9hZG1pbi9tYXN0ZXIvY29uc29sZS8iLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiOGQ5ZGI4MzctMjY2Ni00NDcxLTk0ZDgtZmFkMmIxMjA3NDQxIiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL3JlYWxtcy9tYXN0ZXIiLCJyZXNwb25zZV90eXBlIjoiY29kZSIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL2FkbWluL21hc3Rlci9jb25zb2xlLyIsInN0YXRlIjoiNTQ4ZDE5ZTUtMjlkMS00NTU2LWFjNjAtYjZjZTM1ZmJiMGU2Iiwibm9uY2UiOiI5OGY3NDFiYS03MmQwLTQ0ZDUtOGQ0ZC1jZTAxNzZhYjMyMmUiLCJyZXNwb25zZV9tb2RlIjoiZnJhZ21lbnQifX0.I0jI4nDhbYtKNrVjdlwjjBe5mtd0a8u6Dm7rQXwLE60 >> >> cookie=KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJhNjY5OWJkOS00MWQ4LTQyNWYtYjE5Ni04Y2QzNmJiZjBmNjQiLCJleHAiOjE0NjQxMTc1NjcsIm5iZiI6MCwiaWF0IjoxNDY0MDgxNTY3LCJpc3MiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9yZWFsbXMvbWFzdGVyIiwic3ViIjoiY2YyNDg4MTEtNmQ4Mi00N2U3LWJmOWEtN2IxOTdmYjk4OGQwIiwic2Vzc2lvbl9zdGF0ZSI6IjFiYTljODRlLTBlMzctNGE4Mi1hNDg0LWMyNWQyYzRhODBmYyIsInJlc291cmNlX2FjY2VzcyI6e319.E0vEe9XQJ_6IbDC_TEUfumQCJ0fS1_AOYsHh7svyGp16VC89sH9J1FQuLJfHYFVJlDTcE6o2ktLg0fLw2nLIdLOv-WXMseYr0KzudZveiLy1CZbRoPS9w9vlN-_EuXojiz0ORcyh90keUhqW5tMShccHvEaq_wpXOJQ6ITIglsgUXNhlSuEfpEcBy4CCqKQW98bRQiTKQOtoOfgc-Ez1RHR-7esTw-U22P_H-EMk23jI3nwuYGtqOn4Vvqb4-cHOzdyE_xaVWZxeteNKhU-RexfrMaHx1PSy3T796aY7gIljcqkxra-SA1dbOsRBawwlhJwFtojzBHEs1841gJ4bgg >> >> cookie=KEYCLOAK_SESSION=master/cf248811-6d82-47e7-bf9a-7b197fb988d0/1ba9c84e-0e37-4a82-a484-c25d2c4a80fc >> header=Accept=*/* >> header=Accept-Language=en-US,en;q=0.8,de;q=0.6 >> header=Accept-Encoding=gzip, deflate >> header=DNT=1 >> header=Origin=https://login.vagrant.v8 >> header=X-Original-To=192.168.33.80 >> header=User-Agent=Mozilla/5.0 (Windows NT 6.1; WOW64) >> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 >> header=X-Forwarded-Proto=https >> header=X-Forwarded-Port=443 >> header=X-Forwarded-For=192.168.33.1 >> header=Content-Length=229 >> header=Content-Type=application/x-www-form-urlencoded >> >> header=Cookie=KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjM5YTVkNTlmLWMyNDYtNDkwZi04ZGZkLTZhYzVhNzgyZDI5ZCIsImNpZCI6InNlY3VyaXR5LWFkbWluLWNvbnNvbGUiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9hZG1pbi9tYXN0ZXIvY29uc29sZS8iLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiOGQ5ZGI4MzctMjY2Ni00NDcxLTk0ZDgtZmFkMmIxMjA3NDQxIiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL3JlYWxtcy9tYXN0ZXIiLCJyZXNwb25zZV90eXBlIjoiY29kZSIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL2FkbWluL21hc3Rlci9jb25zb2xlLyIsInN0YXRlIjoiNTQ4ZDE5ZTUtMjlkMS00NTU2LWFjNjAtYjZjZTM1ZmJiMGU2Iiwibm9uY2UiOiI5OGY3NDFiYS03MmQwLTQ0ZDUtOGQ0ZC1jZTAxNzZhYjMyMmUiLCJyZXNwb25zZV9tb2RlIjoiZnJhZ21lbnQifX0.I0jI4nDhbYtKNrVjdlwjjBe5mtd0a8u6Dm7rQXwLE60; >> KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJhNjY5OWJkOS00MWQ4LTQyNWYtYjE5Ni04Y2QzNmJiZjBmNjQiLCJleHAiOjE0NjQxMTc1NjcsIm5iZiI6MCwiaWF0IjoxNDY0MDgxNTY3LCJpc3MiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9yZWFsbXMvbWFzdGVyIiwic3ViIjoiY2YyNDg4MTEtNmQ4Mi00N2U3LWJmOWEtN2IxOTdmYjk4OGQwIiwic2Vzc2lvbl9zdGF0ZSI6IjFiYTljODRlLTBlMzctNGE4Mi1hNDg0LWMyNWQyYzRhODBmYyIsInJlc291cmNlX2FjY2VzcyI6e319.E0vEe9XQJ_6IbDC_TEUfumQCJ0fS1_AOYsHh7svyGp16VC89sH9J1FQuLJfHYFVJlDTcE6o2ktLg0fLw2nLIdLOv-WXMseYr0KzudZveiLy1CZbRoPS9w9vlN-_EuXojiz0ORcyh90keUhqW5tMShccHvEaq_wpXOJQ6ITIglsgUXNhlSuEfpEcBy4CCqKQW98bRQiTKQOtoOfgc-Ez1RHR-7esTw-U22P_H-EMk23jI3nwuYGtqOn4Vvqb4-cHOzdyE_xaVWZxeteNKhU-RexfrMaHx1PSy3T796aY7gIljcqkxra-SA1dbOsRBawwlhJwFtojzBHEs1841gJ4bgg; >> KEYCLOAK_SESSION=master/cf248811-6d82-47e7-bf9a-7b197fb988d0/1ba9c84e-0e37-4a82-a484-c25d2c4a80fc >> header=Referer= >> https://login.vagrant.v8/auth/admin/master/console/ >> header=Host=login.vagrant.v8 >> locale=[en_US, en, de] >> method=POST >> protocol=HTTP/1.1 >> queryString= >> * remoteAddr=/192.168.33.80:54672 * >> remoteHost=proxy.vagrant.v8 >> scheme=https >> host=login.vagrant.v8 >> serverPort=443 >> --------------------------RESPONSE-------------------------- >> contentLength=123 >> contentType=application/json >> header=X-Powered-By=Undertow/1 >> header=Server=WildFly/10 >> header=Content-Type=application/json >> header=Content-Length=123 >> header=Date=Tue, 24 May 2016 09:19:27 GMT >> status=400 >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/55f6fbaf/attachment-0001.html From john.d.ament at gmail.com Tue May 24 08:43:39 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Tue, 24 May 2016 12:43:39 +0000 Subject: [keycloak-user] How to set realm tokens units programmatically In-Reply-To: References: Message-ID: I would just expand it out into the proper value, e.g. 2 * 60 * 60 John On Tue, May 24, 2016 at 8:28 AM Haim Vana wrote: > Hi, > > > > When I am setting realm tokens programmatically, for example 'Sso Session > Idle Timeout', how can I set its units ? > > > > This is how I am setting the parameter programmatically: > > *realmRepresentation.setSsoSessionIdleTimeout(120);* > > > > However I couldn't find how to set the units from minutes to hours, when I > am setting the above it is displayed (and act !) as 2 minutes in the UI. > > > > > > Any advice will be appreciated. > > > > > > Thanks, > > Haim. > > > > > > The information contained in this message is proprietary to the sender, > protected from disclosure, and may be privileged. The information is > intended to be conveyed only to the designated recipient(s) of the message. > If the reader of this message is not the intended recipient, you are hereby > notified that any dissemination, use, distribution or copying of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. Thank you. > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/d0c8487f/attachment.html From haimv at perfectomobile.com Tue May 24 08:48:56 2016 From: haimv at perfectomobile.com (Haim Vana) Date: Tue, 24 May 2016 12:48:56 +0000 Subject: [keycloak-user] How to set realm tokens units programmatically In-Reply-To: References: Message-ID: I did, however Keycloak converts it back to minutes. For example 2 * 60 is converted by Keycloak to 2 minutes instead of 2 hours. From: John D. Ament [mailto:john.d.ament at gmail.com] Sent: Tuesday, May 24, 2016 3:44 PM To: Haim Vana ; keycloak-user at lists.jboss.org Subject: Re: [keycloak-user] How to set realm tokens units programmatically I would just expand it out into the proper value, e.g. 2 * 60 * 60 John On Tue, May 24, 2016 at 8:28 AM Haim Vana > wrote: Hi, When I am setting realm tokens programmatically, for example 'Sso Session Idle Timeout', how can I set its units ? This is how I am setting the parameter programmatically: realmRepresentation.setSsoSessionIdleTimeout(120); However I couldn't find how to set the units from minutes to hours, when I am setting the above it is displayed (and act !) as 2 minutes in the UI. Any advice will be appreciated. Thanks, Haim. The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/5ca237f0/attachment.html From john.d.ament at gmail.com Tue May 24 08:51:24 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Tue, 24 May 2016 12:51:24 +0000 Subject: [keycloak-user] How to set realm tokens units programmatically In-Reply-To: References: Message-ID: The value passed in is in seconds. I just checked against what the UI sends to the backend. That's why my example used 2 * 60 * 60 (7200 seconds = 2 hours) John On Tue, May 24, 2016 at 8:50 AM Haim Vana wrote: > I did, however Keycloak converts it back to minutes. > > For example 2 * 60 is converted by Keycloak to 2 minutes instead of 2 > hours. > > > > > > *From:* John D. Ament [mailto:john.d.ament at gmail.com] > *Sent:* Tuesday, May 24, 2016 3:44 PM > *To:* Haim Vana ; keycloak-user at lists.jboss.org > *Subject:* Re: [keycloak-user] How to set realm tokens units > programmatically > > > > I would just expand it out into the proper value, e.g. > > > > 2 * 60 * 60 > > > > John > > On Tue, May 24, 2016 at 8:28 AM Haim Vana > wrote: > > Hi, > > > > When I am setting realm tokens programmatically, for example 'Sso Session > Idle Timeout', how can I set its units ? > > > > This is how I am setting the parameter programmatically: > > *realmRepresentation.setSsoSessionIdleTimeout(120);* > > > > However I couldn't find how to set the units from minutes to hours, when I > am setting the above it is displayed (and act !) as 2 minutes in the UI. > > > > > > Any advice will be appreciated. > > > > > > Thanks, > > Haim. > > > > > > The information contained in this message is proprietary to the sender, > protected from disclosure, and may be privileged. The information is > intended to be conveyed only to the designated recipient(s) of the message. > If the reader of this message is not the intended recipient, you are hereby > notified that any dissemination, use, distribution or copying of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. Thank you. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > The information contained in this message is proprietary to the sender, > protected from disclosure, and may be privileged. The information is > intended to be conveyed only to the designated recipient(s) of the message. > If the reader of this message is not the intended recipient, you are hereby > notified that any dissemination, use, distribution or copying of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. Thank you. > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/07c7fe7f/attachment-0001.html From john.d.ament at gmail.com Tue May 24 08:53:30 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Tue, 24 May 2016 12:53:30 +0000 Subject: [keycloak-user] Keycloak & Forced Authentication Message-ID: Hi, I was wondering if there was any way in Keycloak to force the authentication of a user? >From my application, I may need a user to reverify their credentials. They will likely already have a session with keycloak open, but I need them to re-enter their credentials. Is there a way to do this? Or even an API call I can make with the user's credentials to verify them? Likewise, I need to be able to provide a SAML ForceAuth=true. Is this possible in Keycloak? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/a3dfd197/attachment.html From haimv at perfectomobile.com Tue May 24 08:53:47 2016 From: haimv at perfectomobile.com (Haim Vana) Date: Tue, 24 May 2016 12:53:47 +0000 Subject: [keycloak-user] How to set realm tokens units programmatically In-Reply-To: References: Message-ID: Great ? thanks a lot ? From: John D. Ament [mailto:john.d.ament at gmail.com] Sent: Tuesday, May 24, 2016 3:51 PM To: Haim Vana ; keycloak-user at lists.jboss.org Subject: Re: [keycloak-user] How to set realm tokens units programmatically The value passed in is in seconds. I just checked against what the UI sends to the backend. That's why my example used 2 * 60 * 60 (7200 seconds = 2 hours) John On Tue, May 24, 2016 at 8:50 AM Haim Vana > wrote: I did, however Keycloak converts it back to minutes. For example 2 * 60 is converted by Keycloak to 2 minutes instead of 2 hours. From: John D. Ament [mailto:john.d.ament at gmail.com] Sent: Tuesday, May 24, 2016 3:44 PM To: Haim Vana >; keycloak-user at lists.jboss.org Subject: Re: [keycloak-user] How to set realm tokens units programmatically I would just expand it out into the proper value, e.g. 2 * 60 * 60 John On Tue, May 24, 2016 at 8:28 AM Haim Vana > wrote: Hi, When I am setting realm tokens programmatically, for example 'Sso Session Idle Timeout', how can I set its units ? This is how I am setting the parameter programmatically: realmRepresentation.setSsoSessionIdleTimeout(120); However I couldn't find how to set the units from minutes to hours, when I am setting the above it is displayed (and act !) as 2 minutes in the UI. Any advice will be appreciated. Thanks, Haim. The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/211091fb/attachment.html From bburke at redhat.com Tue May 24 09:43:20 2016 From: bburke at redhat.com (Bill Burke) Date: Tue, 24 May 2016 09:43:20 -0400 Subject: [keycloak-user] Token generation: possibilities to improve performance In-Reply-To: <61D077C6283D454FAFD06F6AC4AB74D723DDFF8E@DEFTHW99EZ1MSX.ww931.my-it-solutions.net> References: <61D077C6283D454FAFD06F6AC4AB74D723DDFF8E@DEFTHW99EZ1MSX.ww931.my-it-solutions.net> Message-ID: <31bfde5a-c56f-473a-de6f-95d15e32bbd9@redhat.com> Are you sure the performance gains are worth less security? What kind of performance are you actually worried about? Network (size of tokens) or CPU (signatures/marshaling/unmarshalling)? If anything, these signatures are only going to get stronger in future releases. On 5/24/16 5:46 AM, Matuszak, Eduard wrote: > Hello > Motivated by considerations on how to improve the performance of the > token generation process I have two questions: > > * I noticed that Keycloak?s token generation via endpoint > ?auth/realms/ccp/protocol/openid-connect/token? generates a triple > of tokens (access-, refresh- and id-token). Is there any > possibility to dispense with the id-token generation? > > * Is there a possibility to cause Keycloak to generate more ?simple? > bearer tokens then complex jwt-tokens? > > Best regards, Eduard Matuszak > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/fd3e08d9/attachment-0001.html From vaibhav_naldurgkar at persistent.com Tue May 24 10:05:26 2016 From: vaibhav_naldurgkar at persistent.com (Vaibhav Naldurgkar) Date: Tue, 24 May 2016 14:05:26 +0000 Subject: [keycloak-user] Keycloak OAuth High CPU usage In-Reply-To: References: Message-ID: Hello, What are the tests results on a Linux VM ? I just done same jmeter tests on AWS m4.xlarge instance; however far behind than the laptop tests results. @Stian ? have you done tests using Linux VM ? Thanks, Vaibhav From: Herzberg, Manuel [mailto:manuel.herzberg at atos.net] Sent: Tuesday, May 24, 2016 5:52 PM To: stian at redhat.com; Vaibhav Naldurgkar Cc: keycloak-user at lists.jboss.org Subject: RE: [keycloak-user] Keycloak OAuth High CPU usage Hello, I am evaluating the Keycloak performance. Here my practical experience. My scenario is the same as Vaibhav?s: ? Large amount of token have to be generated. This is done by requesting the Keycloak token REST endpoint via http. The different realms I am using have 1k 2k 3k and 4k keys for signing the tokens. (RSA) Longer keys result to longer runtime to generate these tokens. ? I have more than 10k user each realm. Each request includes a new user. Requests look like this: host1:8080/auth/realms/demo-3072/protocol/openid-connect/token/ with data: username=testuser1&password=password&client_id=customer-portal&grant_type=password ? The response includes 3 tokens(access, refresh and id). In total more than 30 000 token have to be generated and signed. @Stian. You wrote you are able to invoke 10000 token refreshes in under 60 seconds. A token refresh includes access, refresh and id token right? Can you explain us your scenario? How do you get such a high number? Some more results: just signing 3000 Token (800 Byte each) with a 2k key takes me 20 seconds (laptop i5-4310U, 12gb ram). I am doing this outside Keycloak with my own java program, but with the same implementation Keycloak is using. (sign() method in RSAProvider). The Keycloak implementation is signing tokens with RSA. HMAC and ECC are implemented as well as I saw in the code. Changing from RSA to HMAC or ECC is not possible in current release as i experienced. Are there plans to provide this in future? Defining this in a configuration file or via parameters would be nice. Best regards, Manuel Herzberg From: keycloak-user-bounces at lists.jboss.org [mailto:keycloak-user-bounces at lists.jboss.org] On Behalf Of Stian Thorgersen Sent: Tuesday, May 24, 2016 8:31 AM To: Vaibhav Naldurgkar Cc: keycloak-user at lists.jboss.org Subject: Re: [keycloak-user] Keycloak OAuth High CPU usage On 23 May 2016 at 10:02, Vaibhav Naldurgkar > wrote: Yes, the direct access grant is ON for this client. I am trying to understand what you mean by ?not planning on using web based flow?? Could you provide more clarification on this. If you are planning to do the web based flow (authorization code grant flow) you should test with that rather than direct grant. That being said the direct grant should still perform as well. This is what the scenario I am trying to execute and still have high CPU usages for KeyCloak Java process. ? The end point URL /auth/realms/master/protocol/openid-connect/token has been called by Jmeter for 20 concurrent users per seconds to generate the tokens. ? Even if used with crul command like ?curl -X POST -d "=admin&password=admin&password&client_id=HelloTest&grant_type=password" http://localhost:8080/auth/realms/master/protocol/openid-connect/token? , in this case also the CPU utilizations goes around 100%. ? After around 3 seconds of the test, in the output of top command on the KeyCloak server the CPU% for keycloak java process goes beyond 100%. Would it be possible for you to have a quick call for faster fix of this issue. This performance issue is holding to move KeyCloak to use as OAuth provider. If any other way is convenient for you please let me know for further discussion. Your JMeter test is using 20 concurrent threads to send as many requests to the direct grant api as it can. This will obviously cause Keycloak to consume a high percentage of the CPU. Especially if you are running everything on localhost as the network isn't going to be a bottleneck. Neither will the database as Keycloak caches everything in memory. The bottleneck will be the CPU. Authenticating users and obtaining a token requires password hashing as well as signing tokens, both are mainly CPU intensive. As you are using the direct grant api there's also less network traffic. You need to add some reports to your JMeter test so you can see how many requests Keycloak can handle. That way you can find out how many users can be authenticated per-second on your machine. If you only have 500 users remember they won't all login at the same time (seconds). Even if they all login at 9am sharp they will be spread out over 10 minutes or so, which would only be 1.2 logins/second. Thanks, Vaibhav From: Stian Thorgersen [mailto:sthorger at redhat.com] Sent: Monday, May 23, 2016 12:01 PM To: Vaibhav Naldurgkar Cc: keycloak-user at lists.jboss.org Subject: Re: [keycloak-user] Keycloak OAuth High CPU usage You are using direct grant to authenticate a user and obtain a token in the example above. This authenticates and creates a new session for each request. Are you not planning on using web based flow? What do you have password hashing intervals set to? Verifying password is CPU intensive, more than signing tokens. It shouldn't matter that user is stored in RedHat IdM as the user would be cached in Keycloak after first authentication, but it may be an idea to just double check by trying to authenticate to a user in Keycloak and not RH IdM. What results are you actually getting? On 20 May 2016 at 11:27, Vaibhav Naldurgkar > wrote: Hi Stian, After reading your tests results of 10000 token refreshes in under 60 seconds on your laptop, I am sure I am not following correct configuration and the documents are missing for reference. Could you please verify the below steps along with the screen-shots for the steps which I am following for the adding client and testing the Load performance using Jmeter. Please suggest if any changes are needed in the client configuration. In this case we are obtaining the token for user from KeyCloak. In my case the user have been stored on RedHat IdM which has been federated using KeyCloak. Step 1. Create new client called ?LoadTest? , use the Client Protocol as ?Openid-connect?. Used all defaults values post save of the client action. Step 2. Start the load tests using Jmeter and using the path as ?/auth/realms/master/protocol/openid-connect/token? . Used 20 Number of Threads and used Post method. Below is the screen-shot for the step 1 related to Add Client. [cid:image001.png at 01D1B5F3.69EF35E0] Below is the screen shot for the load test using Jmeter. In this case the Client ID was used as HelloTest. [cid:image002.png at 01D1B5F3.69EF35E0] Http requests. [cid:image003.png at 01D1B5F3.69EF35E0] Thanks, Vaibhav From: Stian Thorgersen [mailto:sthorger at redhat.com] Sent: Friday, May 20, 2016 1:01 PM To: Vaibhav Naldurgkar Cc: keycloak-user at lists.jboss.org Subject: Re: [keycloak-user] Keycloak OAuth High CPU usage Can you please elaborate a bit more on how your are testing scenario is? I'm a bit confused to what you are testing when you are talking about generating new tokens. Are you using OIDC or SAML? Are you talking about code->token exchanges, refresh token requests, or what? To test if your hardware is capable to deal with the load you need to test logins (verifying passwords are CPU intensive) as well as obtaining tokens (both code->token, done after login, and refreshing token, done ~1 min or so by active users, but most users won't continuously use the application). 500 users should be no problem at all. As an example with a single thread (which will use a single core) I could invoke 10000 token refreshes in under 60 seconds on my laptop. So a single core on my laptop should be able to handle 500 users. On 20 May 2016 at 08:00, Vaibhav Naldurgkar > wrote: Hi Stian, Thank you for your reply. The new tokens needs to be generated for each user, which is needed from security point of view. The performance tests were also conducted using single Admin user and token for admin user; however in that case the performance was not good. In between 15th to 20th admin token access requests ? the CPU usage of keycloak Java process was crossing 90 to 120% mark. As you have mentioned, Creating tokes are expected to be a bit CPU intensive ? what should be the server configuration in terms of CPU to deal with more than 500 users to use keycloak as OAuth provider. Thanks, Vaibhav From: Stian Thorgersen [mailto:sthorger at redhat.com] Sent: Thursday, May 19, 2016 6:28 PM To: Vaibhav Naldurgkar Cc: keycloak-user at lists.jboss.org Subject: Re: [keycloak-user] Keycloak OAuth High CPU usage Creating tokes are expected to be a bit CPU intensive as they need to be signed. When you say you try to generate tokens for 10-20 users are you doing performance tests and having 10-20 threads generating tokens? It shouldn't make any difference if you have 10 or if you have 200 users, it's the total number of tokens that can be generated that's an issue. Having 200 concurrent users with a access token timeout of 60 seconds should mean that you need to be able to generate roughly 200/60 tokens = 3.3 tokens/sec. On 19 May 2016 at 13:24, Vaibhav Naldurgkar > wrote: Hi All, I am using Keycloak 1.9.3 with default configuration. Keycloak server is installed on RHEL 6.5 virtual image with 4 CPU , 8 GB RAM and java version is jdk1.8.0_73 We are trying to use keycloak as a OAuth provider. But when we try and generate token(http:///auth/realms/master/protocol/openid-connect/token) for more than 10-20 users the server gets too slow and cpu usage goes over 100%. Any pointers on how to improve performance of keycloak OAuth provider. We need to support at least 200 concurrent users. Thanks, Vaibhav DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/362ec34b/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 101405 bytes Desc: image001.png Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/362ec34b/attachment-0003.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 11865 bytes Desc: image002.png Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/362ec34b/attachment-0004.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 18447 bytes Desc: image003.png Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/362ec34b/attachment-0005.png From bburke at redhat.com Tue May 24 11:12:07 2016 From: bburke at redhat.com (Bill Burke) Date: Tue, 24 May 2016 11:12:07 -0400 Subject: [keycloak-user] Keycloak & Forced Authentication In-Reply-To: References: Message-ID: Our SAML client adapters have no way to force authentication, but the server does support SAML ForceAuth=true. There's a similar thing for OIDC. You could also extend the Cookie authenticator to ignore the cookie check if a certain client is requesting authentication. On 5/24/16 8:53 AM, John D. Ament wrote: > Hi, > > I was wondering if there was any way in Keycloak to force the > authentication of a user? > > From my application, I may need a user to reverify their credentials. > They will likely already have a session with keycloak open, but I need > them to re-enter their credentials. Is there a way to do this? Or > even an API call I can make with the user's credentials to verify them? > > Likewise, I need to be able to provide a SAML ForceAuth=true. Is this > possible in Keycloak? > > John > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/9bdd9ffd/attachment.html From haimv at perfectomobile.com Tue May 24 15:24:04 2016 From: haimv at perfectomobile.com (Haim Vana) Date: Tue, 24 May 2016 19:24:04 +0000 Subject: [keycloak-user] Offline token validation - can it be deployed within a Docker image Message-ID: Hi, We are using offline tokens for internal flows, and we would to create a Docker image with the offline token to be used for example for all developers. However the offline token validation failed on different host (than the one it was generated from). Is there an option to pass the URL validation just for dev ? or overcome it in a different way ? Any advice will be appreciated. Thanks, Haim. The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160524/5f109c07/attachment.html From sthorger at redhat.com Wed May 25 00:56:07 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 25 May 2016 06:56:07 +0200 Subject: [keycloak-user] Access Token from Account Theme In-Reply-To: References: Message-ID: The account management console doesn't actually use a bearer token as it's internal to Keycloak. On 20 May 2016 at 17:48, Chris Hairfield wrote: > Hello, > > We're trying to make a web request from our account.ftl (to upload a > profile photo) and wish to send the access token of the signed in user with > the request to authorize that action. > > Does anyone know how to obtain the access token from within the > account.ftl theme? I'm hoping it's stored in a cookie that we have access > to from our theme's javascript. > > Thanks, > Chris > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/3c227680/attachment.html From sthorger at redhat.com Wed May 25 01:01:41 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 25 May 2016 07:01:41 +0200 Subject: [keycloak-user] Schedule background jobs as user In-Reply-To: References: Message-ID: Did you look at the offline-access-app from our examples? You could use regular login with the adapters, but when the application needs an offline token and doesn't already have one direct the user to the login and include ?scope=offline_access. If the user is already authenticated and the client doesn't require consent no login page will be displayed. On 20 May 2016 at 19:42, Jesse Chahal wrote: > Thanks for the info, looks like I was on the right path. After reading > through the OpenID spec I came across offline tokens and saw that it > was supported by keycloak. I was trying to figure out how to use > offline tokens with the adapter (since it didn't seem possible to set > a flag to enable the scope for this) but based on the above it isn't > possible. Is it possible for a client to request an offline token > using a refresh or access token? The reason I ask is because we cannot > request it using the adapter system that we are currently using. Even > if we could with the adapter system that would mean that for every > single login we would be requesting a offline token instead of a > refresh token (seems like a bad idea). It also seems like a good idea > to only request the offline_token if a user decides to schedule a > offline job with us. We would prefer not having to have the user login > again in order to schedule an offline job. I did some initial tests > using a rest client and it did not seem possible. > > On Thu, May 19, 2016 at 10:34 PM, Stian Thorgersen > wrote: > > This is exactly what offline tokens where created to do. The offline > token > > is not linked to user sessions so it doesn't matter if users login or > not. > > Our adapters doesn't support it properly though so you'd need to create a > > filter or something that sets up the context and principle based on the > > offline token. > > > > On 19 May 2016 at 19:56, Jesse Chahal wrote: > >> > >> So we've done a lot of work on our migration to keycloak but still > >> have a few holes that are using another authentication system. We are > >> using Wildfly10 along with the keycloak subsystem. The last real > >> blocking issues is trying to schedule background tasks on behalf of a > >> user using quartz. We've tried using impersonation role and mocking > >> out the impersonation workflow that a browser does, it was fairly > >> complicated and did not work very well. Service accounts don't seem to > >> fit this scenario either as service accounts seem to be for performing > >> client specific actions. We considered storing offline token's on > >> behalf of users but the thing is users might not log in for years > >> after scheduling their job. We need to set the Context and Principle > >> to be the user who we are performing background tasks on behalf of. Is > >> there a recommended way of doing this that has been tested by others? > >> I'm sure we aren't the only company who schedule tasks on behalf of > >> users. > >> _______________________________________________ > >> keycloak-user mailing list > >> keycloak-user at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/6ff69efe/attachment.html From sthorger at redhat.com Wed May 25 01:05:09 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 25 May 2016 07:05:09 +0200 Subject: [keycloak-user] How to include the keycloak wildfly adapter libraries in the secure war application classpath? In-Reply-To: References: <20160520101013.GA24124@abstractj.org> <20160520125140.GA29687@abstractj.org> Message-ID: The dependencies should be automatically injected into your WAR if it's either secured in standalone.xml or if the auth-method is set to KEYCLOAK. On 21 May 2016 at 05:15, Darrell Wu wrote: > I'm not using the saml client adapters, i'm using the jboss/wildfly adapter > as mention here > > http://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#jboss-adapter > > I have the following in my wildfly 10 standalone.xml file > under entensions > > > > under security subsystem > > > code="org.keycloak.adapters.jboss.KeycloakLoginModule" flag="required"/> > > > > under the keycloak subsystem i have secure my application > > > 1Place > 1Place-reporting > xxxxxxxxKey > removedxxxxxxxxxxx > http://localhost:8180/ > EXTERNAL > xxxxxxxxKey > removedxxxxxxxxxxx > > > The reporting-server-rest.war is in an EAR archive with an ejb jar. The > code with the exception is a stateless session bean(OperatorService ) in > the ejb jar. > It is called by a produces method > > > public class CurrentUserProducer { > > > @Inject > OperatorService operatorService; > > @LoggedInUser > @Produces > public CurrentUser produceCurrentUser() { > return operatorService.getCurrentUser(); > } > } > > > > The OperatorService stateless session bean getCurrentUser method looks > like the following. The exception is occurring on the first line > @Inject > private HttpServletRequest httpRequest; > > public CurrentUser getCurrentUser(){ > KeycloakSecurityContext securityContext = (KeycloakSecurityContext) > httpRequest.getAttribute(KeycloakSecurityContext.class.getName()); > > > a filter in the reporting-server-rest.war archive is injecting the > CurrentUser like so > > @WebFilter(dispatcherTypes = {DispatcherType.REQUEST, > DispatcherType.FORWARD}, urlPatterns = {"/*"}) > public class CurrentUserFilter implements Filter { > > @Inject @LoggedInUser > private CurrentUser currentUser; > > > > I'm getting the following exception in the log > > 14:26:38,444 ERROR [io.undertow.request] (default task-10) UT005023: > Exception handling request to > /reporting-server-rest/widgets/checklistQuestion: > javax.servlet.ServletException: UT010013: Could not instantiate com.one > placeonline.rest.CurrentUserFilter > at > io.undertow.servlet.core.ManagedFilter.createFilter(ManagedFilter.java:76) > at > io.undertow.servlet.core.ManagedFilter.getFilter(ManagedFilter.java:65) > at > io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) > at > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) > at > io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) > at > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at > org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > org.keycloak.adapters.undertow.UndertowAuthenticatedActionsHandler.handleRequest(UndertowAuthenticatedActionsHandler.java:66) > at > io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at > io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) > at > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at > io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) > at > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at > io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at > io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.servlet.handlers.ServletInitialHandler.jrHandle(ServletInitialHandler.java) > at > org.zeroturnaround.javarebel.integration.servlet.undertow.cbp.ServletInitialHandlerCBP.handleRequest(ServletInitialHandlerCBP.java:100) > at > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) > at > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) > at > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) > at > io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > at > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to > construct component instance > at > org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163) > at > org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134) > at > org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88) > at > org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReferenceFactory.getReference(ComponentRegistry.java:149) > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$6.createInstance(UndertowDeploymentInfoService.java:1366) > at > io.undertow.servlet.core.ManagedFilter.createFilter(ManagedFilter.java:74) > ... 37 more > Caused by: javax.ejb.EJBException: WFLYEJB0442: Unexpected Error > at > org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:184) > at > org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) > at > org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) > at > org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at > org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at > org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at > org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at > org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at > org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at > org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at > org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at > org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at > org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at > org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) > at > org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at > org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at > org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at > org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at > org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195) > at > org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at > org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at > org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) > at > com.oneplaceonline.business.users.boundary.OperatorService$$$view14.getCurrentUser(Unknown > Source) > at sun.reflect.GeneratedMethodAccessor89.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:436) > at > org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127) > at > org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) > at > org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:67) > at > org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) > at > com.oneplaceonline.business.users.boundary.OperatorService$Proxy$_$$_Weld$EnterpriseProxy$.getCurrentUser(Unknown > Source) > at > com.oneplaceonline.business.users.boundary.CurrentUserProducer.produceCurrentUser(CurrentUserProducer.java:17) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > at > org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) > at > org.jboss.weld.injection.producer.ProducerMethodProducer.produce(ProducerMethodProducer.java:99) > at > org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:161) > at > org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:181) > at > org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:70) > at > org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) > at > org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) > at > org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742) > at > org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:842) > at > org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92) > at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:378) > at > org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:389) > at > org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:71) > at > org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) > at > org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:73) > at > org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121) > at > org.jboss.as.weld.injection.WeldInjectionContext.inject(WeldInjectionContext.java:39) > at > org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:51) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at > org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at > org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at > org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at > org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at > org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at > org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) > at > org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at > org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at > org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161) > ... 42 more > Caused by: java.lang.NoClassDefFoundError: > org/keycloak/KeycloakSecurityContext > at > com.oneplaceonline.business.users.boundary.OperatorService.getCurrentUser(OperatorService.java:81) > at sun.reflect.GeneratedMethodAccessor89.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at > org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) > at > org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) > at > org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) > at > org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at > org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at > org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at > org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) > at > org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64) > at > org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at > org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at > org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at > org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) > at > org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at > org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) > at > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) > at > org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) > ... 124 more > > Does it have anything to do with the change in 1.9.0 > > http://keycloak.github.io/docs/userguide/keycloak-server/html/Migration_from_older_versions.html#d4e4103 > under > 35.6.3. Migrating to 1.9.0Adapter Subsystems only bring in dependencies > if keycloak is on > > Previously, if you had installed our saml or oidc keycloak subsystem > adapters into Wildfly or JBoss EAP, we would automatically include Keycloak > client jars into EVERY application irregardless if you were using Keycloak > or not. These libraries are now only added to your deployment if you have > keycloak authentication turned on for that adapter (via the subsystem, or > auth-method in web.xml > > Mind you i'm not using saml or oidc adapter > > > > On 21 May 2016 at 00:51, Bruno Oliveira wrote: > >> Do you have the security domain specified like described here: >> >> http://keycloak.github.io/docs/userguide/saml-client-adapter/html/jboss-adapter.html >> >> If possible send some steps to reproduce or the code snippet. >> >> >> On 2016-05-20, Darrell Wu wrote: >> > If it helps I'm using wildfly 10 and have keycloak on a standalone >> server. >> > The authenication works. It just when my app tries to read the security >> > context I get the class not found exception. >> > >> > So what triggers wildfly to include the keycloak modules in my apps >> class >> > path? >> > On 20/05/2016 10:10 pm, "Bruno Oliveira" wrote: >> > >> > > Weird because it was fixed here: >> > > https://issues.jboss.org/browse/KEYCLOAK-2483. Plus, I tested >> > > on WildFly 9.0.2.Final with Keycloak adapter 1.9.4.Final and couldn't >> > > reproduce the issue. >> > > >> > > On 2016-05-20, Darrell Wu wrote: >> > > > Hi, >> > > > >> > > > With the keycloak wildfly adapter for version 1.9.x i've noticed >> that the >> > > > location of the Keycloak Subsystem modules have changed from >> > > > modules\system\layers\base\org\keycloak to >> > > > modules\system\add-ons\keycloak\org\keycloak >> > > > >> > > > Now on my secure war application server I've installed the keycloak >> > > wildfly >> > > > adpater by unzipping the archive and running the adapter-install.cl >> > > script. >> > > > >> > > > Now In my application i'm getting a >> > > > ClassNotFoundException: org.keycloak.KeycloakSecurityContext >> > > > >> > > > when the following is executed >> > > > >> > > > KeycloakSecurityContext securityContext = (KeycloakSecurityContext) >> > > > httpRequest.getAttribute(KeycloakSecurityContext.class.getName()); >> > > > >> > > > Obviously the application isn't loading the keycloak modules in the >> > > > classpath. >> > > > What is the proper way to include the keycloak libraries in my app? >> > > > >> > > > Should my app have a jboss-deployment-structure.xml file or >> should the >> > > > libraries be moved back to modules\system\layers\base\org\keycloak? >> > > > >> > > > Thanks >> > > > >> > > > >> > > > >> > > > -- >> > > > Darrell Wu >> > > > 1Place Limited >> > > > P.O. Box 125152, St Heliers, Auckland 1740, New Zealand >> > > > Level 4, 1 Queen Street, Auckland 1010, New Zealand >> > > > Phone: +64 9 5200612 ext 521 | Mob: +64 21 262 4898 | Fax: +64 9 >> 5246203 >> > > > Email: darrell at 1placeonline.com | Web: www.1placeonline.com >> > > >> > > > _______________________________________________ >> > > > keycloak-user mailing list >> > > > keycloak-user at lists.jboss.org >> > > > https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > >> > > >> > > -- >> > > >> > > abstractj >> > > PGP: 0x84DC9914 >> > > >> >> -- >> >> abstractj >> PGP: 0x84DC9914 >> > > > > -- > Darrell Wu > 1Place Limited > P.O. Box 125152, St Heliers, Auckland 1740, New Zealand > Level 4, 1 Queen Street, Auckland 1010, New Zealand > Phone: +64 9 5200612 ext 521 | Mob: +64 21 262 4898 | Fax: +64 9 5246203 > Email: darrell at 1placeonline.com | Web: www.1placeonline.com > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/8d980b00/attachment-0001.html From sthorger at redhat.com Wed May 25 01:07:52 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 25 May 2016 07:07:52 +0200 Subject: [keycloak-user] custom federation/authentication In-Reply-To: References: Message-ID: The user federation provider is the way to go. Our examples distribution includes an example user federation provider that should help you get started. On 21 May 2016 at 11:07, Simon Gordon wrote: > > > Hello > > Looking for some guidance please - let's say that we want to authenticate > users against an external authenticator (e.g. RADIUS server, or a custom > REST API) and at the time of login, the user does not necessarily have a > profile/account within keycloak. > > My initial scan suggests that we just need to create an Authenticator > Provider - but I'm concerned that since the user account does not > necessarily exist in KC, I can't see how the Authenticator provider will > work. Should I be looking at a userFederation provider instead? Looking at > the server-spi module, I'm not seeing the Interface(s) to implement, so any > pointers gratefuilly received! > > Regards, > > Simon > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/fb648274/attachment.html From sthorger at redhat.com Wed May 25 01:11:07 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 25 May 2016 07:11:07 +0200 Subject: [keycloak-user] Starting Keycloak as a Service(Windows and Linux) In-Reply-To: <04bf01d1b373$9a917550$cfb45ff0$@gmail.com> References: <04bf01d1b373$9a917550$cfb45ff0$@gmail.com> Message-ID: Same way as you would install WildFly 10 as a service. I'm not sure about the steps, but you should be able to find it with a Google search. On 21 May 2016 at 17:15, Paa Kojo Konduah Amos wrote: > Hello All, How do I start Keycloak as a service on Windows and Linux? > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/2db3849b/attachment.html From sthorger at redhat.com Wed May 25 01:14:19 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 25 May 2016 07:14:19 +0200 Subject: [keycloak-user] "You took too long to login" when adding the initial admin user In-Reply-To: References: Message-ID: It sounds like you have an issue with the Infinispan configuration. There's a few threads in the mailing list about setting up clustering on AWS. On 23 May 2016 at 14:49, Riedel, Sven wrote: > Hi, > after enabling sticky sessions on the loadbalancer, the login works. > Cranking up the logs to "debug" told me that the "RestartLoginCookies > client session does not match the code's clientSession". > > The phrasing leads me to believe that the session was not shared in the > infinispans cache among the nodes. I'll still need to figure out if the > cache distribution per se isn't working, or if this was a special case for > commandline generated users. > > Regards, > Sven > > > > Am 2016-05-23 12:59 schrieb "Riedel, Sven" unter : > > >Hi, > >I'm set up keycloak 1.9.4final on AWS as an HA-cluster using JDBC-Ping for > >infinispan group management behind an load balancer. > >Now, when I create a user with the bin/add-user-keycloak.sh script and > >restart keycloak on the respektive instance, I get the message "You took > >too long to login. Login process starting from beginning." on my first try > >to login with the newly created account. On my second try, I just get "An > >error occurred, please login again through your application." > > > >From what I can see, the account is successfully being created in the > >database. The login attempts happen within one minute of restarting the > >keycloak service. In the console log I can see the message > >"type=LOGIN_ERROR, realmId=master, clientId=null, userId=null, > >ipAddress=a.b.c.d, error=expired_code, restart_after_timeout=true" on the > >first attempt and "type=LOGIN_ERROR, realmId=master, clientId=null, > >userId=null, ipAddress=a.b.c.d, error=invalid_code" on the second attempt. > > > >I'm a bit at a loss as to how to proceed, to get the admin user set up > >properly and get the login to work. Any pointers would be appreciated. > > > >Regards, > >Sven > > > > > >-- > >Sven Riedel > >Senior Systemsarchitect > > > >glomex GmbH > >Ein Unternehmen der ProSiebenSat.1 Media SE > > > >Medienallee 4 > >D-85774 Unterf?hring > >Tel. +49 [89] 9507-8167 > >sven.riedel at glomex.com > > > >Gesch?ftsf?hrer: Michael Jaschke, Arnd M?ckenberger > >HRB 224542 AG M?nchen > >USt.-ID.-Nr. DE 218559421 > >St.-Nr. 143/141/71293 > > > > > > > > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/2fd6922c/attachment.html From sthorger at redhat.com Wed May 25 01:16:52 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 25 May 2016 07:16:52 +0200 Subject: [keycloak-user] Disabling unique email restriction in Keycloak In-Reply-To: References: Message-ID: On 23 May 2016 at 18:44, Niels Bertram wrote: > Are you suggesting that the email field will no longer be able to be > populated by the user if the realm is configured to use username only for > login? > Yes, the email field with the unique constraint would only be used for "login email". Then there would be an attribute or another field for contact email. > > In the current form, we would still have to populate the current "email" > field in the user model with a unique email address, which we dont have for > our users. Or at least lets say we don't want to resort to a hack in the > User Federation Provider and add random snippets into the email address > using a fringe feature of the email spec. > Why? The email field is optional, just leave it blank. Then use an attribute as I suggested. > > On Mon, May 23, 2016 at 3:27 PM, Stian Thorgersen > wrote: > >> We've planned to add support for having non-unique email addresses. The >> idea would be to have an option on a realm to configure if login permits >> username/email, username or email. The email field on users would still >> have to have a unique constraint as removing that results in not being able >> to guarantee email uniqueness. Instead we planned to have contact email >> address which would be non-unique. >> >> You can workaround this though as it's already possible to add custom >> attributes (to add contact email) and change the email sender so Keycloak >> supports sending email to contact email attribute if set. >> >> On 23 May 2016 at 05:03, Nidhi Rachora wrote: >> >>> Hi Keycloak Team, >>> >>> I am working on migrating an existing application to Keycloak. In the >>> existing application, unique ?member_ids? are used as usernames and the >>> ?email? field can be duplicate. However on logging into Keycloak, members >>> with duplicate emails are not allowed. So I have identified two areas to >>> work on: >>> >>> Task I) Allow members with unique member ids (who may/ maynot have >>> unique email) to login. >>> Task II) Disable login using email. >>> >>> Solution: >>> So as a solution to the first task, in my CustomUserFederation, I have >>> made the following changes: >>> >>> //Code snippet 1 CustomFederationProvider implements >>> UserFederationProvider{ >>> . . >>> @Override >>> public UserModel getUserByUsername(RealmModel realm, String username) { >>> . . >>> if (apiCustomer.getEmailAddresses() != null && >>> apiCustomer.getEmailAddresses().size() > 0) { >>> // Changed to handle duplicate emails using: Sub-addressing, so email: >>> mailid at domain is saved as mailid+member_id at domain >>> userModel.setEmail( >>> subaddress(apiCustomer.getEmailAddresses().get(0).getEmail(), >>> userModel.getMember_id())); >>> } >>> . . >>> } >>> } >>> >>> //Code snippet 2 >>> CustomUserModelDelegate extends UserModelDelegate { >>> . . >>> @Override >>> public String getEmail() { >>> String email = super.getEmail(); try { >>> // Changed to handle duplicate emails using: Sub-addressing, so while >>> retrieving email: mailid+member_id at domain is processed as mailid at domain >>> >>> email = removeSubaddress(email); >>> } catch (Exception e) { >>> ... >>> } >>> return email; >>> } >>> . . >>> } >>> >>> Now my queries are: >>> >>> 1.) Will my solution of sub-addressing the email resolve the first issue >>> without any side-effects? >>> 2.) How do I disable logging in using emails from Keycloak? >>> >>> Regards, >>> Nidhi Rachora >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/b7e6b705/attachment-0001.html From sthorger at redhat.com Wed May 25 01:18:36 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 25 May 2016 07:18:36 +0200 Subject: [keycloak-user] Monitoring & Collecting Metrics from Keycloak In-Reply-To: References: Message-ID: We don't have any support for metrics at the moment. Until we do, using an event listener to collect the metrics would be the way to go. On 23 May 2016 at 09:33, Sarp Kaya wrote: > Hi all, > > I looked into the user guide but there is no mention of any metrics. For > instance how would I be able to collect metrics for the amount of users > that are logged in per minute, amount of users that could not log in per > minute, amount of incorrect usernames etc. as metrics? > > Is it somehow possible to hook any metric collection library to keycloak > events, or does keycloak have anything to provide metrics? > > Thank you, > Sarp Kaya > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/3dad20e1/attachment.html From sthorger at redhat.com Wed May 25 01:22:05 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 25 May 2016 07:22:05 +0200 Subject: [keycloak-user] Redirection issue with proxy behind keycloak In-Reply-To: References: Message-ID: You need the Host and X-Forwarded-For headers to be included and there's also some config to be done on the Keycloak server (see http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#proxy-address-forwarding ) On 24 May 2016 at 08:46, Aritz Maeztu wrote: > Hi Niels and Scott. First of all, thank you very much for your help. I'm > currently using Zuul (Spring Cloud) as the reverse proxy. All the services > are registered in a discovery service called Eureka and then Zuul looks for > the service id there and performs de redirection. I read about X-Forwarded > headers, but I thought it might result in a security issue if not included, > not that it could affect the redirection process. > > As Scott says, I suppose the Host and the X-Real-Ip headers are the > relevant ones here, so I guess I should instruct Zuul to send them when the > service is addressed (however I wonder why they are not already being sent, > as Zuul is a proxy service, all in all). > Here I include a preview of the first redirection made to the keycloak > login page, which shows the request headers sent to the service /login > endpoint (at port 8081 in localhost): > > https://www.dropbox.com/s/iof9yefytzay6j2/screenshot.PNG?dl=0 > > 24/05/2016 2:08(e)an, Niels Bertram igorleak idatzi zuen: > > Hi Artitz, > > a great way to figure out what is sent from the reverse proxy to your > keycloak server is to use the undertow request dumper. > > From the jboss-cli just add the request dumper filter to your undertow > configuration like this: > > $KC_HOME/bin/jbpss-cli.sh -c > > /subsystem=undertow/configuration=filter/custom-filter=request-dumper:add(class-name=io.undertow.server.handlers.RequestDumpingHandler, > module=io.undertow.core) > > > /subsystem=undertow/server=default-server/host=default-host/filter-ref=request-dumper:add > > /:reload > > given your apache config looks something like this: > > ProxyRequests Off > ProxyPreserveHost On > ProxyVia On > > ProxyPass /auth ajp://127.0.0.1:8009/auth > ProxyPassReverse /auth ajp://127.0.0.1:8009/auth > > > you should see something like that (forwared info is somewhat rubbish in > this example as I am running the hosts on Virtualbox - but you can see this > request was put through 2 proxies from local pc 192.168.33.1 to haproxy on > 192.168.33.80 and then apache reverse proxy on 192.168.33.81 ): > > ============================================================== > 23:47:20,563 INFO [io.undertow.request.dump] (default task-14) > ----------------------------REQUEST--------------------------- > URI=/auth/welcome-content/favicon.ico > characterEncoding=null > contentLength=-1 > contentType=null > header=Accept=*/* > header=Accept-Language=en-US,en;q=0.8,de;q=0.6 > header=Cache-Control=no-cache > header=Accept-Encoding=gzip, deflate, sdch > header=DNT=1 > header=Pragma=no-cache > header=X-Original-To=192.168.33.80 > header=User-Agent=Mozilla/5.0 (Windows NT 6.1; WOW64) > AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 > header=Authorization=Basic > bmljZSB0cnkgYnV0IGFtIG5vdCBmcm9tIHllc3RlcmRheQo= > header=X-Forwarded-Proto=https > header=X-Forwarded-Port=443 > header=X-Forwarded-For=192.168.33.1 > header=Referer=https://login.vagrant.dev/auth/ > header=Host=login.vagrant.dev > locale=[en_US, en, de] > method=GET > protocol=HTTP/1.1 > queryString= > remoteAddr=192.168.33.1:0 > remoteHost=192.168.33.1 > scheme=https > host=login.vagrant.dev > serverPort=443 > --------------------------RESPONSE-------------------------- > contentLength=627 > contentType=application/octet-stream > header=Cache-Control=max-age=2592000 > header=X-Powered-By=Undertow/1 > header=Server=WildFly/10 > > > Hope this helps diagnosing your issue. Niels > > On Tue, May 24, 2016 at 1:20 AM, Aritz Maeztu > wrote: > >> I'm using keycloak to securize some Spring based services (with the >> keycloak spring security adapter). The adapter creates a `/login` endpoint >> in each of the services which redirects to the keycloak login page and then >> redirects back to the service when authentication is done. I also have a >> proxy service which I want to publish in the 80 port and will take care of >> routing all the requests to each service. The proxy performs a plain >> FORWARD to the service, but the problem comes when I securize the service >> with the keycloak adapter. >> >> When I make a request, the adapter redirects to its login endpoint and >> then to the keycloak auth url. When keycloak sends the redirection, the url >> shown in the browser is the one from the service and not the one from the >> proxy. Do I have some choice to tell the adapter I want to redirect back to >> the first requested url? >> >> -- >> Aritz Maeztu Ota?o >> Departamento Desarrollo de Software >> >> >> >> Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra) >> Telf.: 948 21 40 40 >> Fax.: 948 21 40 41 >> Antes de imprimir este e-mail piense bien si es necesario hacerlo: El >> medioambiente es cosa de todos. >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > > -- > Aritz Maeztu Ota?o > Departamento Desarrollo de Software > > > > Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra) > Telf.: 948 21 40 40 > Fax.: 948 21 40 41 > Antes de imprimir este e-mail piense bien si es necesario hacerlo: El > medioambiente es cosa de todos. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/f3ad5f79/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: linkdin.gif Type: image/gif Size: 1295 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/f3ad5f79/attachment-0002.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 2983 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/f3ad5f79/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1295 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/f3ad5f79/attachment-0003.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 2983 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/f3ad5f79/attachment-0003.png From mosheb at perfectomobile.com Wed May 25 01:43:01 2016 From: mosheb at perfectomobile.com (Moshe Ben-Shoham) Date: Wed, 25 May 2016 05:43:01 +0000 Subject: [keycloak-user] How to secure REST APIs with KeyCloak In-Reply-To: References: Message-ID: <98B451C9-266F-484E-9108-90FB8B35663B@perfectomobile.com> Thank you for the detailed answer. Moshe. [http://www.perfectomobile.com/sites/all/themes/perfecto/img/perfecto_email_logo.jpg] Moshe Ben-Shoham R&D Director, System Architecture Phone: +972-3-9260-137 Mobile: +972 54 4324480 Email: mosheb at perfectomobile.com How to Create the Right Mobile & Web Test Strategy: Live Webinar May 26 Build a customized test coverage strategy using 3 free tools! Register to attend! From: Stian Thorgersen > Reply-To: "stian at redhat.com" > Date: Thursday, 19 May 2016 at 10:03 AM To: Moshe Ben-Shoham > Cc: "keycloak-user at lists.jboss.org" > Subject: Re: [keycloak-user] How to secure REST APIs with KeyCloak One option is to allow users to login through the script itself. Take a look at our customer-app-cli in the examples. It has two options one is to show the user a login that the user then opens and copy/pastes the code back to the application, the other is it opens it in a browser and can the script can then read the token directly itself. You can combine this with changing the SSO idle/max configuration for the realm to determine how often a user needs to re-authenticate. You can also combine it with offline token as well if you want the scripts to remain permanently authenticated. Using direct access grants works as well. Rather than adding username/password to the script you should have the script request the username/password, then the script stores the token, not password. Same as above you'd configure SSO idle/max to determine how often users need to re-authenticate, or you can use offline here as well. You're right that this won't support identity brokering, that's only available for the web flow. On 15 May 2016 at 20:59, Moshe Ben-Shoham > wrote: Hi, I?m trying to figure out the best way to secure REST APIs with KeyCloak. The REST APIs are to be invoked by unattended batch processes that are not KeyCloak clients but end-user scripts. I imagine a process in which the user generates a token using some web app and then uses this token in his scripts in order to authenticate when invoking the REST APIs. So far I have found 2 options, but none of them seems like a very good option: (1) Use offline tokens ? according to the docs, offline token are to be used by KeyCloak clients that need to do things on behalf of the user. In my case, it is the end-user that needs the token and not a client. Should I build a dedicated client that will create the offline tokens and give them to the end-user to use? Is this a misuse for offline tokens? (2) Use Direct Access Grants ? seems like in this option, at least in its simplest form, the user needs to pass username and password to get a token. This means users need to keep their password in their scripts (or scripts configuration) and it is bad practice. In addition, what happens when KeyCloak is configured to be an Identity Broker? In this case KeyCloak does not even know how to handle the user/password. Any help is appreciated! The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/535616c6/attachment.html From darrell at 1placeonline.com Wed May 25 01:43:22 2016 From: darrell at 1placeonline.com (Darrell Wu) Date: Wed, 25 May 2016 17:43:22 +1200 Subject: [keycloak-user] How to include the keycloak wildfly adapter libraries in the secure war application classpath? In-Reply-To: References: <20160520101013.GA24124@abstractj.org> <20160520125140.GA29687@abstractj.org> Message-ID: It doesn't seem to work for me. It looks like it looking in the wrong place, If i copy the keycloak libraries to modules\system\layers\base\org\keycloak directory then it works. Also my WAR is within an EAR archive On 25 May 2016 at 17:05, Stian Thorgersen wrote: > The dependencies should be automatically injected into your WAR if it's > either secured in standalone.xml or if the auth-method is set to KEYCLOAK. > > On 21 May 2016 at 05:15, Darrell Wu wrote: > >> I'm not using the saml client adapters, i'm using the jboss/wildfly >> adapter >> as mention here >> >> http://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#jboss-adapter >> >> I have the following in my wildfly 10 standalone.xml file >> under entensions >> >> >> >> under security subsystem >> >> >> > code="org.keycloak.adapters.jboss.KeycloakLoginModule" flag="required"/> >> >> >> >> under the keycloak subsystem i have secure my application >> >> >> 1Place >> 1Place-reporting >> xxxxxxxxKey >> removedxxxxxxxxxxx >> http://localhost:8180/ >> EXTERNAL >> xxxxxxxxKey >> removedxxxxxxxxxxx >> >> >> The reporting-server-rest.war is in an EAR archive with an ejb jar. The >> code with the exception is a stateless session bean(OperatorService ) in >> the ejb jar. >> It is called by a produces method >> >> >> public class CurrentUserProducer { >> >> >> @Inject >> OperatorService operatorService; >> >> @LoggedInUser >> @Produces >> public CurrentUser produceCurrentUser() { >> return operatorService.getCurrentUser(); >> } >> } >> >> >> >> The OperatorService stateless session bean getCurrentUser method looks >> like the following. The exception is occurring on the first line >> @Inject >> private HttpServletRequest httpRequest; >> >> public CurrentUser getCurrentUser(){ >> KeycloakSecurityContext securityContext = (KeycloakSecurityContext) >> httpRequest.getAttribute(KeycloakSecurityContext.class.getName()); >> >> >> a filter in the reporting-server-rest.war archive is injecting the >> CurrentUser like so >> >> @WebFilter(dispatcherTypes = {DispatcherType.REQUEST, >> DispatcherType.FORWARD}, urlPatterns = {"/*"}) >> public class CurrentUserFilter implements Filter { >> >> @Inject @LoggedInUser >> private CurrentUser currentUser; >> >> >> >> I'm getting the following exception in the log >> >> 14:26:38,444 ERROR [io.undertow.request] (default task-10) UT005023: >> Exception handling request to >> /reporting-server-rest/widgets/checklistQuestion: >> javax.servlet.ServletException: UT010013: Could not instantiate com.one >> placeonline.rest.CurrentUserFilter >> at >> io.undertow.servlet.core.ManagedFilter.createFilter(ManagedFilter.java:76) >> at >> io.undertow.servlet.core.ManagedFilter.getFilter(ManagedFilter.java:65) >> at >> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) >> at >> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) >> at >> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) >> at >> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) >> at >> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) >> at >> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at >> org.keycloak.adapters.undertow.UndertowAuthenticatedActionsHandler.handleRequest(UndertowAuthenticatedActionsHandler.java:66) >> at >> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) >> at >> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) >> at >> io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at >> io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) >> at >> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) >> at >> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) >> at >> io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) >> at >> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) >> at >> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) >> at >> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) >> at >> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at >> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at >> org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at >> io.undertow.servlet.handlers.ServletInitialHandler.jrHandle(ServletInitialHandler.java) >> at >> org.zeroturnaround.javarebel.integration.servlet.undertow.cbp.ServletInitialHandlerCBP.handleRequest(ServletInitialHandlerCBP.java:100) >> at >> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) >> at >> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) >> at >> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) >> at >> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) >> at >> io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) >> at >> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:745) >> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to >> construct component instance >> at >> org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163) >> at >> org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134) >> at >> org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88) >> at >> org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReferenceFactory.getReference(ComponentRegistry.java:149) >> at >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$6.createInstance(UndertowDeploymentInfoService.java:1366) >> at >> io.undertow.servlet.core.ManagedFilter.createFilter(ManagedFilter.java:74) >> ... 37 more >> Caused by: javax.ejb.EJBException: WFLYEJB0442: Unexpected Error >> at >> org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:184) >> at >> org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) >> at >> org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) >> at >> org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) >> at >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at >> org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) >> at >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at >> org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) >> at >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at >> org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) >> at >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at >> org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) >> at >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at >> org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66) >> at >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at >> org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) >> at >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at >> org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) >> at >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at >> org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) >> at >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at >> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) >> at >> org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) >> at >> org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) >> at >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at >> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) >> at >> org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) >> at >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at >> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) >> at >> org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195) >> at >> org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) >> at >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at >> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) >> at >> org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) >> at >> com.oneplaceonline.business.users.boundary.OperatorService$$$view14.getCurrentUser(Unknown >> Source) >> at sun.reflect.GeneratedMethodAccessor89.invoke(Unknown Source) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:497) >> at >> org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:436) >> at >> org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127) >> at >> org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) >> at >> org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:67) >> at >> org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) >> at >> com.oneplaceonline.business.users.boundary.OperatorService$Proxy$_$$_Weld$EnterpriseProxy$.getCurrentUser(Unknown >> Source) >> at >> com.oneplaceonline.business.users.boundary.CurrentUserProducer.produceCurrentUser(CurrentUserProducer.java:17) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:497) >> at >> org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) >> at >> org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) >> at >> org.jboss.weld.injection.producer.ProducerMethodProducer.produce(ProducerMethodProducer.java:99) >> at >> org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:161) >> at >> org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:181) >> at >> org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:70) >> at >> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) >> at >> org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) >> at >> org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742) >> at >> org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:842) >> at >> org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92) >> at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:378) >> at >> org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:389) >> at >> org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:71) >> at >> org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) >> at >> org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:73) >> at >> org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121) >> at >> org.jboss.as.weld.injection.WeldInjectionContext.inject(WeldInjectionContext.java:39) >> at >> org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:51) >> at >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at >> org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28) >> at >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at >> org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56) >> at >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at >> org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43) >> at >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at >> org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) >> at >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at >> org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) >> at >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at >> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) >> at >> org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) >> at >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at >> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) >> at >> org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161) >> ... 42 more >> Caused by: java.lang.NoClassDefFoundError: >> org/keycloak/KeycloakSecurityContext >> at >> com.oneplaceonline.business.users.boundary.OperatorService.getCurrentUser(OperatorService.java:81) >> at sun.reflect.GeneratedMethodAccessor89.invoke(Unknown Source) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:497) >> at >> org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) >> at >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at >> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) >> at >> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) >> at >> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) >> at >> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) >> at >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at >> org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) >> at >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at >> org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) >> at >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at >> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) >> at >> org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64) >> at >> org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) >> at >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at >> org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) >> at >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at >> org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) >> at >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at >> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) >> at >> org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) >> at >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at >> org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) >> at >> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >> at >> org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) >> ... 124 more >> >> Does it have anything to do with the change in 1.9.0 >> >> http://keycloak.github.io/docs/userguide/keycloak-server/html/Migration_from_older_versions.html#d4e4103 >> under >> 35.6.3. Migrating to 1.9.0Adapter Subsystems only bring in dependencies >> if keycloak is on >> >> Previously, if you had installed our saml or oidc keycloak subsystem >> adapters into Wildfly or JBoss EAP, we would automatically include Keycloak >> client jars into EVERY application irregardless if you were using Keycloak >> or not. These libraries are now only added to your deployment if you have >> keycloak authentication turned on for that adapter (via the subsystem, or >> auth-method in web.xml >> >> Mind you i'm not using saml or oidc adapter >> >> >> >> On 21 May 2016 at 00:51, Bruno Oliveira wrote: >> >>> Do you have the security domain specified like described here: >>> >>> http://keycloak.github.io/docs/userguide/saml-client-adapter/html/jboss-adapter.html >>> >>> If possible send some steps to reproduce or the code snippet. >>> >>> >>> On 2016-05-20, Darrell Wu wrote: >>> > If it helps I'm using wildfly 10 and have keycloak on a standalone >>> server. >>> > The authenication works. It just when my app tries to read the security >>> > context I get the class not found exception. >>> > >>> > So what triggers wildfly to include the keycloak modules in my apps >>> class >>> > path? >>> > On 20/05/2016 10:10 pm, "Bruno Oliveira" wrote: >>> > >>> > > Weird because it was fixed here: >>> > > https://issues.jboss.org/browse/KEYCLOAK-2483. Plus, I tested >>> > > on WildFly 9.0.2.Final with Keycloak adapter 1.9.4.Final and couldn't >>> > > reproduce the issue. >>> > > >>> > > On 2016-05-20, Darrell Wu wrote: >>> > > > Hi, >>> > > > >>> > > > With the keycloak wildfly adapter for version 1.9.x i've noticed >>> that the >>> > > > location of the Keycloak Subsystem modules have changed from >>> > > > modules\system\layers\base\org\keycloak to >>> > > > modules\system\add-ons\keycloak\org\keycloak >>> > > > >>> > > > Now on my secure war application server I've installed the keycloak >>> > > wildfly >>> > > > adpater by unzipping the archive and running the >>> adapter-install.cl >>> > > script. >>> > > > >>> > > > Now In my application i'm getting a >>> > > > ClassNotFoundException: org.keycloak.KeycloakSecurityContext >>> > > > >>> > > > when the following is executed >>> > > > >>> > > > KeycloakSecurityContext securityContext = (KeycloakSecurityContext) >>> > > > httpRequest.getAttribute(KeycloakSecurityContext.class.getName()); >>> > > > >>> > > > Obviously the application isn't loading the keycloak modules in the >>> > > > classpath. >>> > > > What is the proper way to include the keycloak libraries in my app? >>> > > > >>> > > > Should my app have a jboss-deployment-structure.xml file or >>> should the >>> > > > libraries be moved back to modules\system\layers\base\org\keycloak? >>> > > > >>> > > > Thanks >>> > > > >>> > > > >>> > > > >>> > > > -- >>> > > > Darrell Wu >>> > > > 1Place Limited >>> > > > P.O. Box 125152, St Heliers, Auckland 1740, New Zealand >>> > > > Level 4, 1 Queen Street, Auckland 1010, New Zealand >>> > > > Phone: +64 9 5200612 ext 521 | Mob: +64 21 262 4898 | Fax: +64 9 >>> 5246203 >>> > > > Email: darrell at 1placeonline.com | Web: www.1placeonline.com >>> > > >>> > > > _______________________________________________ >>> > > > keycloak-user mailing list >>> > > > keycloak-user at lists.jboss.org >>> > > > https://lists.jboss.org/mailman/listinfo/keycloak-user >>> > > >>> > > >>> > > -- >>> > > >>> > > abstractj >>> > > PGP: 0x84DC9914 >>> > > >>> >>> -- >>> >>> abstractj >>> PGP: 0x84DC9914 >>> >> >> >> >> -- >> Darrell Wu >> 1Place Limited >> P.O. Box 125152, St Heliers, Auckland 1740, New Zealand >> Level 4, 1 Queen Street, Auckland 1010, New Zealand >> Phone: +64 9 5200612 ext 521 | Mob: +64 21 262 4898 | Fax: +64 9 5246203 >> Email: darrell at 1placeonline.com | Web: www.1placeonline.com >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > -- Darrell Wu 1Place Limited P.O. Box 125152, St Heliers, Auckland 1740, New Zealand Level 4, 1 Queen Street, Auckland 1010, New Zealand Phone: +64 9 5200612 ext 521 | Mob: +64 21 262 4898 | Fax: +64 9 5246203 Email: darrell at 1placeonline.com | Web: www.1placeonline.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/5faa24b4/attachment-0001.html From dadom110 at googlemail.com Wed May 25 01:59:55 2016 From: dadom110 at googlemail.com (da.dom) Date: Wed, 25 May 2016 07:59:55 +0200 Subject: [keycloak-user] EJB Remote Calls and KeyCloak Message-ID: Hi There, i try to use Keycloak to authenticate an EJB Remote Client Call. Setup: I have a working Keycloak Setup for my WebClients. I add to my application server standalone.xml an additional security domain: and configure my ejb sub-system .... My Test Connection: prop.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory"); prop.put(Context.PROVIDER_URL, "http-remoting://localhost:8080"); prop.put("jboss.naming.client.ejb.context", true); prop.put(Context.SECURITY_PRINCIPAL, "admin-user"); prop.put(Context.SECURITY_CREDENTIALS, "123"); fails with: "Invalid User" In Keycloak Server i see the failed login: Errorinvalid_user_credentials auth_method openid-connect grant_type password client_auth_method client-secret username admin-user "Direct Access Grants" is enabeld for that application. Somebody any idea? Or is my setup totally wrong? How whould i use KeyCloak for remote EJB calls? Thanks a lot Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/edaf5dd1/attachment.html From sthorger at redhat.com Wed May 25 02:17:00 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 25 May 2016 08:17:00 +0200 Subject: [keycloak-user] KeyCloak offline tokens and architecture In-Reply-To: References: Message-ID: On 18 May 2016 at 11:53, Haim Vana wrote: > Hi, > We are evaluating KeyCloak to be our SSO server, and we have a few > questions regarding the offline token usage. > > First our high level use case is as follows: > We have multi-tenancy applications, each tenant will have its own realm > (which means the same clients will be defined for each realm). > One of the applications has 3 authentication scenarios: > > 1. User using SDK flow to access the application (by code) > > 2. Offline job > > 3. External micro service (not registered in KeyCloak) that needs to > access our application micro service > > 4. UI login > We thought to use offline token for the first three, and define a single > client for UI and micro services. > For #3 it sounds like a service account would be better. > Does our approach make sense ? specially regarding the realm per tenant > and the fact that we will have to create the same clients for each realm, > The offline token usage for the authentication flows, and the single > client for the UI and micro service. > > Regarding the offline tokens - why are they per client ? is it mean that > when using the client offline token (and getting the real token from > KeyCloak) we will not be able to use it for other client (within the realm) > micro service ? > > Also how can we generate them for each of the following cases (also > described above): > > 1. User - should manually add the token to his code, so we thought to > provide it within the application, however how can we generate the offline > token to already logged in user ? we would like to avoid generating the > offline token to all users and to use separate offline login page. > Just do another redirect to login page and include ?scope=offline. If user is already authenticated the user wouldn't have to login again. > 2. Offline job - the offline job which is cross realms will use > special operator realm, the token will be generated manually by the admin > which will stored it in the file system for the offline job usage, how can > the admin generate this token ? can it be done in the admin console ? if > not I guess we will have to create a service that logs him to the > application and generate the token, is there an alternative ? > If the offline job is not acting on behalf of a user then use a service account instead. > 3. Micro service - it's very similar flow to the offline job only that > the admin will have to create offline token per realm. > Same as above > I hope it's not too much [image: > https://issues.jboss.org/images/icons/emoticons/smile.png] and any advice > will be highly appreciated. > > > > Thanks, > Haim. > > > The information contained in this message is proprietary to the sender, > protected from disclosure, and may be privileged. The information is > intended to be conveyed only to the designated recipient(s) of the message. > If the reader of this message is not the intended recipient, you are hereby > notified that any dissemination, use, distribution or copying of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. Thank you. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/08504f1d/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 752 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/08504f1d/attachment.png From sthorger at redhat.com Wed May 25 02:22:35 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 25 May 2016 08:22:35 +0200 Subject: [keycloak-user] Updating real settings In-Reply-To: References: Message-ID: Importing an existing realm would cause the existing realm to be deleted. You can try partial import instead or alternatively create your own flow using the admin rest api. On 23 May 2016 at 12:05, Alessandro Segatto wrote: > Hi ! I've a production environment with a realm defined for keycloak > clients and a set of users registered in this realm. I'd like to update > realm settings by importing them from the json, but i don't want to delete > / overwrite registered users. I think i can achieve this goal by exporting > the realm with users and then importing it back overwriting realm json with > the new configurations but keeping users json. > Are there any alternative pipelines to achieve this goal ? > Thanks , > > Alessandro > > -- > > Ing. Alessandro Segatto > Software Engineer > Research and Development > > *ESTECO S.p.A.* - AREA Science Park, Padriciano 99 - 34149 Trieste - ITALY > Phone: +39 040 3755548 - Fax: +39 040 3755549 | www.esteco.com > > Pursuant to Legislative Decree No. 196/2003, you are hereby informed that > this message contains confidential information intended only for the use of > the addressee. If you are not the addressee, and have received this message > by mistake, please delete it and immediately notify us. You may not copy or > disseminate this message to anyone. Thank you. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/f94f7995/attachment-0001.html From sthorger at redhat.com Wed May 25 02:28:29 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 25 May 2016 08:28:29 +0200 Subject: [keycloak-user] redirection error with Keycloak-proxy In-Reply-To: <2fc15c7eff3cc6c3ac3c5a63fd3fceec@dorsetnetworks.com> References: <3f56c50382d2333ec4f4435350b07891@dorsetnetworks.com> <16b8e67b70d16ff086db00f3c1709851@dorsetnetworks.com> <2fc15c7eff3cc6c3ac3c5a63fd3fceec@dorsetnetworks.com> Message-ID: For Keycloak server to work behind a reverse proxy you need to make sure the X-Forwarded-For and Host headers are includes, there's also some config you need to do in Keycloak itself. See http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#proxy-address-forwarding On 24 May 2016 at 13:34, Guy Bowdler wrote: > Typical, spent two days faffing on this and as soon as I ask the forum, > I find it. I repointed the kc proxy "auth-server-url" direct at > keycloak and it works fine. Point it at the nginx proxied version of > keycloak and it dies. It authenticates, and the user sessions show in > the keycloak console, and SSO works, as I can go to another URL and that > too shows a session but neither page renders when keyclaok is behind > nginx. > > anyone had a similar experience? > > On 2016-05-24 11:25, Guy Bowdler wrote: > > It might be this, as we have the keycloak instance running behind > > another nginx proxy: > > > > https://issues.jboss.org/browse/KEYCLOAK-2054 > > > > If anyone can help confirm this is would be a massive help as the fix > > isn't due out until June 22 and would save unnecessary troubleshooting > > > > > > > > On 2016-05-24 10:48, Guy Bowdler wrote: > >> Hi:) > >> > >> Has anybody seen this error? > >> > >> I have (http://host.name/appname) --> [KeyCloakProxy:80 --> > >> nginx:8080] > >> --> [Web apps on different boxes] where [] denotes on same box. > >> Namespace is hostname/appname where nginx location directives proxy > >> out > >> again to different boxes. > >> > >> I've previously had this working but when I changed the keystore it > >> all > >> broke and haven't found the problem yet. Troubleshooting steps have > >> been to take out the ssl entirely and try different client settings. > >> If > >> I remove the contraints in the proxy config, it proxies ok to the > >> webpages, and it the constraints are in, I log in ok and then the > >> browser goes blank with a URL like this in the address bar: > >> > >> > http://apps.host.name/python?state=0%2F52043b01-976f-464f-8651-ebe295aac2af&code=-_odSdHkDVnID6JhPeKV2QXh_1oub5DDLP2ZLZ6pA_0.ef2bd934-2fd8-48da-a626-106712b687b1 > >> > >> The error stack below is from the console of the keycloak proxy. > >> Refreshing the page, simply returns a different error of "NO STATE > >> COOKIE". > >> > >> Thanks in advance for any assistance, > >> > >> kind regards > >> > >> Guy > >> > >> > >> ERROR: failed to turn code into token > >> java.net.ConnectException: Connection refused > >> at java.net.PlainSocketImpl.socketConnect(Native Method) > >> at > >> > java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) > >> at > >> > java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) > >> at > >> > java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) > >> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) > >> at java.net.Socket.connect(Socket.java:589) > >> at > >> sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:668) > >> at > >> > org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:532) > >> at > >> > org.keycloak.adapters.SniSSLSocketFactory.connectSocket(SniSSLSocketFactory.java:109) > >> at > >> > org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:409) > >> at > >> > org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:177) > >> at > >> > org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:144) > >> at > >> > org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:131) > >> at > >> > org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:611) > >> at > >> > org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:446) > >> at > >> > org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882) > >> at > >> > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) > >> at > >> > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107) > >> at > >> > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55) > >> at > >> > org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:107) > >> at > >> > org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuthenticator.java:314) > >> at > >> > org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:260) > >> at > >> > org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:112) > >> at > >> > org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110) > >> at > >> > org.keycloak.adapters.undertow.UndertowAuthenticationMechanism.authenticate(UndertowAuthenticationMechanism.java:56) > >> at > >> > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233) > >> at > >> > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250) > >> at > >> > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219) > >> at > >> > io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121) > >> at > >> > io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96) > >> at > >> > io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89) > >> at > >> > org.keycloak.proxy.ProxyAuthenticationCallHandler.handleRequest(ProxyAuthenticationCallHandler.java:44) > >> at > >> > org.keycloak.proxy.ConstraintMatcherHandler.handleRequest(ConstraintMatcherHandler.java:89) > >> at > >> > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > >> at > >> > org.keycloak.adapters.undertow.UndertowPreAuthActionsHandler.handleRequest(UndertowPreAuthActionsHandler.java:54) > >> at > >> > io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > >> at > >> > io.undertow.server.session.SessionAttachmentHandler.handleRequest(SessionAttachmentHandler.java:68) > >> at > >> > io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:94) > >> at > >> io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > >> at > >> > io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:232) > >> at > >> > io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:130) > >> at > >> > io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:56) > >> at > >> > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > >> at > >> > org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > >> at > >> org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:88) > >> at org.xnio.nio.WorkerThread.run(WorkerThread.java:559) > >> > >> May 24, 2016 11:04:30 AM > >> org.keycloak.adapters.OAuthRequestAuthenticator > >> checkStateCookie > >> WARN: No state cookie > >> > >> _______________________________________________ > >> keycloak-user mailing list > >> keycloak-user at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/e3bb10aa/attachment.html From sthorger at redhat.com Wed May 25 02:29:48 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 25 May 2016 08:29:48 +0200 Subject: [keycloak-user] Resetting password In-Reply-To: References: <5742a5d9.0cb9420a.b96f6.6132@mx.google.com> Message-ID: Yep, the result to the user is the same regardless if a user with the email exist. Same with the login screen it display invalid username or password, not just invalid username. On 24 May 2016 at 14:36, Thomas Raehalme wrote: > Hi! > > For security reasons I don't think Keycloak should reveal whether or not > the account exists. Instead the message shown to the user in response > should be something like "If the email address was found, you should soon > receive further instructions." > > Best regards, > Thomas > > > On Tue, May 24, 2016 at 3:02 PM, Jayapriya Atheesan < > jayapriya.atheesan at gmail.com> wrote: > >> Hi All, >> >> Any help would be appreciated. >> >> Thanks, >> Jayapriya Atheesan >> >> On Mon, May 23, 2016 at 12:10 PM, JAYAPRIYA ATHEESAN < >> jayapriya.atheesan at gmail.com> wrote: >> >>> Hi, >>> >>> >>> >>> When a user clicks on reset password/forget password and enters an email >>> id which is not registered with keycloak, it does not show any error. >>> >>> Is there any option to give an error message to the user saying ?email >>> id doesn?t exist?. >>> >>> Note : We are using keycloak 1.6.0Final. >>> >>> >>> >>> Thanks, >>> >>> Jayapriya Atheesan >>> >>> >>> >> >> >> >> -- >> *Regards,* >> Jayapriya Atheesan >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/4721bf34/attachment-0001.html From sthorger at redhat.com Wed May 25 02:39:35 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 25 May 2016 08:39:35 +0200 Subject: [keycloak-user] Keycloak token exchange failure behind loadbalancer and reverse proxy In-Reply-To: References: Message-ID: The message means it's unable to authenticate the client for the code to token exchange. Looking at the request it's a strange one as it looks like you've tried to login to the admin console then the code to token request for some reason includes "Authorization=Basic YWRtaW46Y2hhbmdlbWU=" which is credentials for a user 'admin' with password 'changeme'. Is this being added by your proxy or something? On 24 May 2016 at 14:41, Niels Bertram wrote: > Yes I can confirm the filter is correctly added. I also have all the other > required settings configured (hopefully correctly). It works reliably when > I target the apache reverse proxy but only falls appart when I load balance > through another "hop". I switched on debug on keycloak and can see a bit > more details of the failure (logs below). I wonder what > "AuthenticationFlowException: Client was not identified by any client > authenticator" means. > > > > redirect-socket="proxy-https" enabled="true" /> > proxy-address-forwarding="true" redirect-socket="proxy-https" /> > > > > > > > > > > header-value="WildFly/10"/> > header-value="Undertow/1"/> > class-name="io.undertow.server.handlers.ProxyPeerAddressHandler" > module="io.undertow.core" /> > > > > port-offset="${jboss.socket.binding.port-offset:0}"> > ... > > > > > ... > > > > > 2016-05-24 09:59:26,176 DEBUG [org.keycloak.services] (default task-11) > AUTHENTICATE CLIENT > 2016-05-24 09:59:26,176 DEBUG [org.keycloak.services] (default task-11) > client authenticator: client-secret > 2016-05-24 09:59:26,179 DEBUG [org.keycloak.services] (default task-11) > client authenticator: client-jwt > 2016-05-24 09:59:26,180 DEBUG [org.keycloak.services] (default task-11) > KC-SERVICES0014: Failed client authentication: > org.keycloak.authentication.AuthenticationFlowException: Client was not > identified by any client authenticator > at > org.keycloak.authentication.ClientAuthenticationFlow.processFlow(ClientAuthenticationFlow.java:101) > at > org.keycloak.authentication.AuthenticationProcessor.authenticateClient(AuthenticationProcessor.java:673) > at > org.keycloak.protocol.oidc.utils.AuthorizeClientUtil.authorizeClient(AuthorizeClientUtil.java:42) > at > org.keycloak.protocol.oidc.endpoints.TokenEndpoint.checkClient(TokenEndpoint.java:163) > at > org.keycloak.protocol.oidc.endpoints.TokenEndpoint.build(TokenEndpoint.java:117) > at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) > at > org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) > at > org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) > at > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) > at > org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:88) > at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) > at > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) > at > io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) > at > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at > org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at > io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at > io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) > at > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) > at > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > > 2016-05-24 09:59:26,180 WARN [org.keycloak.events] (default task-11) > type=CODE_TO_TOKEN_ERROR, realmId=master, clientId=admin, userId=null, > ipAddress=192.168.33.1, error=invalid_client_credentials, > grant_type=authorization_code > 2016-05-24 09:59:26,863 DEBUG [org.keycloak.services] (default task-8) > replacing relative valid redirect with: > https://login.vagrant.v8/auth/admin/master/console/* > 2016-05-24 09:59:26,867 DEBUG [org.keycloak.services] (default task-8) > AUTHENTICATE > 2016-05-24 09:59:26,867 DEBUG [org.keycloak.services] (default task-8) > AUTHENTICATE ONLY > 2016-05-24 09:59:26,867 DEBUG [org.keycloak.services] (default task-8) > processFlow > 2016-05-24 09:59:26,868 DEBUG [org.keycloak.services] (default task-8) > check execution: auth-cookie requirement: ALTERNATIVE > 2016-05-24 09:59:26,868 DEBUG [org.keycloak.services] (default task-8) > authenticator: auth-cookie > 2016-05-24 09:59:26,868 DEBUG [org.keycloak.services] (default task-8) > invoke authenticator.authenticate > 2016-05-24 09:59:26,869 DEBUG [org.keycloak.services] (default task-8) > token active - active: true, issued-at: 1,464,083,965, not-before: 0 > 2016-05-24 09:59:26,869 DEBUG [org.keycloak.services] (default task-8) > authenticator SUCCESS: auth-cookie > 2016-05-24 09:59:26,873 DEBUG [org.keycloak.services] (default task-8) > check execution: auth-spnego requirement: DISABLED > 2016-05-24 09:59:26,873 DEBUG [org.keycloak.services] (default task-8) > execution is processed > 2016-05-24 09:59:26,873 DEBUG [org.keycloak.services] (default task-8) > check execution: null requirement: ALTERNATIVE > 2016-05-24 09:59:26,873 DEBUG [org.keycloak.services] (default task-8) > Skip alternative execution > 2016-05-24 09:59:26,874 DEBUG [org.keycloak.events] (default task-8) > type=LOGIN, realmId=master, clientId=security-admin-console, > userId=cf248811-6d82-47e7-bf9a-7b197fb988d0, ipAddress=192.168.33.1, > auth_method=openid-connect, auth_type=code, response_type=code, > redirect_uri=https://login.vagrant.v8/auth/admin/master/console/, > consent=no_consent_required, code_id=8215bbb3-a592-47e0-9c28-c274bccc61b5, > response_mode=fragment, username=admin > 2016-05-24 09:59:26,891 DEBUG [org.keycloak.services] (default task-8) > Create login cookie - name: KEYCLOAK_IDENTITY, path: /auth/realms/master, > max-age: -1 > 2016-05-24 09:59:26,892 DEBUG [org.keycloak.services] (default task-8) > redirectAccessCode: state: ae0d05d7-95d9-40a0-9a75-7e4e4fb7830e > 2016-05-24 09:59:27,472 DEBUG [org.keycloak.services] (default task-11) > AUTHENTICATE CLIENT > 2016-05-24 09:59:27,472 DEBUG [org.keycloak.services] (default task-11) > client authenticator: client-secret > 2016-05-24 09:59:27,474 DEBUG [org.keycloak.services] (default task-11) > client authenticator: client-jwt > 2016-05-24 09:59:27,474 DEBUG [org.keycloak.services] (default task-11) > KC-SERVICES0014: Failed client authentication: > org.keycloak.authentication.AuthenticationFlowException: Client was not > identified by any client authenticator > at > org.keycloak.authentication.ClientAuthenticationFlow.processFlow(ClientAuthenticationFlow.java:101) > at > org.keycloak.authentication.AuthenticationProcessor.authenticateClient(AuthenticationProcessor.java:673) > at > org.keycloak.protocol.oidc.utils.AuthorizeClientUtil.authorizeClient(AuthorizeClientUtil.java:42) > at > org.keycloak.protocol.oidc.endpoints.TokenEndpoint.checkClient(TokenEndpoint.java:163) > at > org.keycloak.protocol.oidc.endpoints.TokenEndpoint.build(TokenEndpoint.java:117) > at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) > at > org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) > at > org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) > at > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) > at > org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:88) > at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) > at > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) > at > io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) > at > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at > org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at > io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at > io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) > at > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) > at > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > > 2016-05-24 09:59:27,478 WARN [org.keycloak.events] (default task-11) > type=CODE_TO_TOKEN_ERROR, realmId=master, clientId=admin, userId=null, > ipAddress=192.168.33.1, error=invalid_client_credentials, > grant_type=authorization_code > 2016-05-24 09:59:28,209 DEBUG [org.keycloak.services] (default task-8) > replacing relative valid redirect with: > https://login.vagrant.v8/auth/admin/master/console/* > 2016-05-24 09:59:28,211 DEBUG [org.keycloak.services] (default task-8) > AUTHENTICATE > 2016-05-24 09:59:28,218 DEBUG [org.keycloak.services] (default task-8) > AUTHENTICATE ONLY > 2016-05-24 09:59:28,218 DEBUG [org.keycloak.services] (default task-8) > processFlow > 2016-05-24 09:59:28,219 DEBUG [org.keycloak.services] (default task-8) > check execution: auth-cookie requirement: ALTERNATIVE > 2016-05-24 09:59:28,219 DEBUG [org.keycloak.services] (default task-8) > authenticator: auth-cookie > 2016-05-24 09:59:28,219 DEBUG [org.keycloak.services] (default task-8) > invoke authenticator.authenticate > 2016-05-24 09:59:28,220 DEBUG [org.keycloak.services] (default task-8) > token active - active: true, issued-at: 1,464,083,966, not-before: 0 > 2016-05-24 09:59:28,222 DEBUG [org.keycloak.services] (default task-8) > authenticator SUCCESS: auth-cookie > 2016-05-24 09:59:28,222 DEBUG [org.keycloak.services] (default task-8) > check execution: auth-spnego requirement: DISABLED > 2016-05-24 09:59:28,222 DEBUG [org.keycloak.services] (default task-8) > execution is processed > 2016-05-24 09:59:28,222 DEBUG [org.keycloak.services] (default task-8) > check execution: null requirement: ALTERNATIVE > 2016-05-24 09:59:28,222 DEBUG [org.keycloak.services] (default task-8) > Skip alternative execution > 2016-05-24 09:59:28,223 DEBUG [org.keycloak.events] (default task-8) > type=LOGIN, realmId=master, clientId=security-admin-console, > userId=cf248811-6d82-47e7-bf9a-7b197fb988d0, ipAddress=192.168.33.1, > auth_method=openid-connect, auth_type=code, response_type=code, > redirect_uri=https://login.vagrant.v8/auth/admin/master/console/, > consent=no_consent_required, code_id=7f9dbb5c-651a-4cc4-a248-91637c354fa5, > response_mode=fragment, username=admin > 2016-05-24 09:59:28,255 DEBUG [org.keycloak.services] (default task-8) > Create login cookie - name: KEYCLOAK_IDENTITY, path: /auth/realms/master, > max-age: -1 > 2016-05-24 09:59:28,256 DEBUG [org.keycloak.services] (default task-8) > redirectAccessCode: state: 89b303fd-f77e-4b23-8de0-2c517304e671 > 2016-05-24 09:59:28,612 DEBUG [org.keycloak.services] (default task-11) > AUTHENTICATE CLIENT > 2016-05-24 09:59:28,612 DEBUG [org.keycloak.services] (default task-11) > client authenticator: client-secret > 2016-05-24 09:59:28,613 DEBUG [org.keycloak.services] (default task-11) > client authenticator: client-jwt > 2016-05-24 09:59:28,614 DEBUG [org.keycloak.services] (default task-11) > KC-SERVICES0014: Failed client authentication: > org.keycloak.authentication.AuthenticationFlowException: Client was not > identified by any client authenticator > at > org.keycloak.authentication.ClientAuthenticationFlow.processFlow(ClientAuthenticationFlow.java:101) > at > org.keycloak.authentication.AuthenticationProcessor.authenticateClient(AuthenticationProcessor.java:673) > at > org.keycloak.protocol.oidc.utils.AuthorizeClientUtil.authorizeClient(AuthorizeClientUtil.java:42) > at > org.keycloak.protocol.oidc.endpoints.TokenEndpoint.checkClient(TokenEndpoint.java:163) > at > org.keycloak.protocol.oidc.endpoints.TokenEndpoint.build(TokenEndpoint.java:117) > at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) > at > org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) > at > org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) > at > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) > at > org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:88) > at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) > at > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) > at > io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) > at > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at > org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at > io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at > io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) > at > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) > at > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > > 2016-05-24 09:59:28,614 WARN [org.keycloak.events] (default task-11) > type=CODE_TO_TOKEN_ERROR, realmId=master, clientId=admin, userId=null, > ipAddress=192.168.33.1, error=invalid_client_credentials, > grant_type=authorization_code > 2016-05-24 09:59:28,692 INFO [io.undertow.request.dump] (default task-11) > ----------------------------REQUEST--------------------------- > URI=/auth/realms/master/protocol/openid-connect/token > characterEncoding=null > contentLength=229 > contentType=[application/x-www-form-urlencoded] > > cookie=KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjdmOWRiYjVjLTY1MWEtNGNjNC1hMjQ4LTkxNjM3YzM1NGZhNSIsImNpZCI6InNlY3VyaXR5LWFkbWluLWNvbnNvbGUiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9hZG1pbi9tYXN0ZXIvY29uc29sZS8iLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiYjg3OTM2Y2ItZTg1OC00NDhlLWJmMTAtNGNkYjQzMDFkMTg2IiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL3JlYWxtcy9tYXN0ZXIiLCJyZXNwb25zZV90eXBlIjoiY29kZSIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL2FkbWluL21hc3Rlci9jb25zb2xlLyIsInN0YXRlIjoiODliMzAzZmQtZjc3ZS00YjIzLThkZTAtMmM1MTczMDRlNjcxIiwibm9uY2UiOiI1MzY0YTRhZS0wNzI3LTQwYWItOWEyMi0yN2ExZDQ5NjVmNTkiLCJyZXNwb25zZV9tb2RlIjoiZnJhZ21lbnQifX0.7Xnk589FgD_9RulKC4V48gn-056yVxa_DdIGm4Hpgj8 > > cookie=KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI5ZjRmNWU3OS02NWYxLTQ0M2ItOGI5YS1hZWI4NzZmYmNkNjIiLCJleHAiOjE0NjQxMTk5NjgsIm5iZiI6MCwiaWF0IjoxNDY0MDgzOTY4LCJpc3MiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9yZWFsbXMvbWFzdGVyIiwic3ViIjoiY2YyNDg4MTEtNmQ4Mi00N2U3LWJmOWEtN2IxOTdmYjk4OGQwIiwic2Vzc2lvbl9zdGF0ZSI6ImQzYjAxY2Q1LWQxNWEtNGQ2OS05MTQ3LWE1YTEzYWI4MjQxNiIsInJlc291cmNlX2FjY2VzcyI6e319.eiDWSR8eeIdX7AKZiWI3e9moUD9ZuD-h88XX31JRMio_FmqSvMgRHcZtkVjjrLnjcmWn7X4jIcITARk-TiywjfAKotkPYodgCyxsmln5LRQeV3SYXltCGWKmsFmq0BsMjQbfstjdR9V9Xh7daiyRNxLGcoYitEEOeKboMjbGwZw11jggaTRifpNYp-M9GtTBvHSJg6RFdmm0QTLeJm9OgOvBzdRlKwGTUcJeqJxuNWgd4XqPS5vbpliDsfuvekC8VFeDB_UGci1hCIEoMy0-tlpwPLP_xGbCd5L8XFKrr0shoGbQlyJjFZB49VtJlHLkd8F15mZQxJ1G9BWj_wKINw > > cookie=KEYCLOAK_SESSION=master/cf248811-6d82-47e7-bf9a-7b197fb988d0/d3b01cd5-d15a-4d69-9147-a5a13ab82416 > header=X-Real-Ip=192.168.33.1 > header=Accept-Encoding=gzip, deflate > header=DNT=1 > header=Origin=https://login.vagrant.v8 > header=X-Forwarded-Port=443 > header=X-Forwarded-For=192.168.33.1 > > header=Cookie=KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjdmOWRiYjVjLTY1MWEtNGNjNC1hMjQ4LTkxNjM3YzM1NGZhNSIsImNpZCI6InNlY3VyaXR5LWFkbWluLWNvbnNvbGUiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9hZG1pbi9tYXN0ZXIvY29uc29sZS8iLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiYjg3OTM2Y2ItZTg1OC00NDhlLWJmMTAtNGNkYjQzMDFkMTg2IiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL3JlYWxtcy9tYXN0ZXIiLCJyZXNwb25zZV90eXBlIjoiY29kZSIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL2FkbWluL21hc3Rlci9jb25zb2xlLyIsInN0YXRlIjoiODliMzAzZmQtZjc3ZS00YjIzLThkZTAtMmM1MTczMDRlNjcxIiwibm9uY2UiOiI1MzY0YTRhZS0wNzI3LTQwYWItOWEyMi0yN2ExZDQ5NjVmNTkiLCJyZXNwb25zZV9tb2RlIjoiZnJhZ21lbnQifX0.7Xnk589FgD_9RulKC4V48gn-056yVxa_DdIGm4Hpgj8; > KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI5ZjRmNWU3OS02NWYxLTQ0M2ItOGI5YS1hZWI4NzZmYmNkNjIiLCJleHAiOjE0NjQxMTk5NjgsIm5iZiI6MCwiaWF0IjoxNDY0MDgzOTY4LCJpc3MiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9yZWFsbXMvbWFzdGVyIiwic3ViIjoiY2YyNDg4MTEtNmQ4Mi00N2U3LWJmOWEtN2IxOTdmYjk4OGQwIiwic2Vzc2lvbl9zdGF0ZSI6ImQzYjAxY2Q1LWQxNWEtNGQ2OS05MTQ3LWE1YTEzYWI4MjQxNiIsInJlc291cmNlX2FjY2VzcyI6e319.eiDWSR8eeIdX7AKZiWI3e9moUD9ZuD-h88XX31JRMio_FmqSvMgRHcZtkVjjrLnjcmWn7X4jIcITARk-TiywjfAKotkPYodgCyxsmln5LRQeV3SYXltCGWKmsFmq0BsMjQbfstjdR9V9Xh7daiyRNxLGcoYitEEOeKboMjbGwZw11jggaTRifpNYp-M9GtTBvHSJg6RFdmm0QTLeJm9OgOvBzdRlKwGTUcJeqJxuNWgd4XqPS5vbpliDsfuvekC8VFeDB_UGci1hCIEoMy0-tlpwPLP_xGbCd5L8XFKrr0shoGbQlyJjFZB49VtJlHLkd8F15mZQxJ1G9BWj_wKINw; > KEYCLOAK_SESSION=master/cf248811-6d82-47e7-bf9a-7b197fb988d0/d3b01cd5-d15a-4d69-9147-a5a13ab82416 > header=Referer= > https://login.vagrant.v8/auth/admin/master/console/ > header=Host=login.vagrant.v8 > header=Accept=*/* > header=Accept-Language=en-US,en;q=0.8,de;q=0.6 > header=X-Original-To=192.168.33.80 > header=User-Agent=Mozilla/5.0 (Windows NT 6.1; WOW64) > AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 > header=Authorization=Basic YWRtaW46Y2hhbmdlbWU= > header=X-Forwarded-Proto=https > header=Content-Length=229 > header=Content-Type=application/x-www-form-urlencoded > locale=[en_US, en, de] > method=POST > protocol=HTTP/1.1 > queryString= > remoteAddr=/192.168.33.80:55892 > remoteHost=proxy.vagrant.v8 > scheme=https > host=login.vagrant.v8 > serverPort=443 > --------------------------RESPONSE-------------------------- > contentLength=123 > contentType=application/json > header=X-Powered-By=Undertow/1 > header=Server=WildFly/10 > header=Content-Type=application/json > header=Content-Length=123 > header=Date=Tue, 24 May 2016 09:59:28 GMT > status=400 > > > On Tue, May 24, 2016 at 9:49 PM, Stian Thorgersen > wrote: > >> Did you add ProxyPeerAddressHandler filter? That's required for AJP >> connector, see >> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#proxy-address-forwarding >> >> On 24 May 2016 at 11:48, Niels Bertram wrote: >> >>> I am scratching my head with a specific setup problem which does not >>> generate any usable error messages. >>> >>> I am running a haproxy as load balancer in a vm in front an apache web >>> server configured as reverse proxy connecting to the keycloak server via >>> ajp in another VM. >>> >>> client browser (192.168.33.1) >>> >>> login.vagrant.v8 (192.168.33.80) aka proxy.vagrant.v8 is haproxy >>> adds X-Forwarded-For X-Forwarded-Port X-Forwarded-Proto and X-Real-Ip >>> >>> kc01.vagrant.v8 (192.168.33.81) apache reverse proxies >>> to wildfly on ajp port >>> >>> >>> Followed all the setup instructions in the documentation and if I >>> connect to apache proxying through to keycloak everything works fine. All >>> web resources are donwloaded fine however when I request a token exchange >>> on /auth/realms/master/protocol/openid-connect/token I get a 400 >>> response. The kc server log shows the corect IP address of the originating >>> client and the request dump from wildfly also shows the correct >>> X-Forwarded-For header coming in. However the query string remoteAddr=/ >>> 192.168.33.80:54672 which I believe is the one sent to the ajp >>> connector shows some half valid IP address which is that of the load >>> balancer. Did anyone come across this before? Looks like a bug of some sort. >>> >>> The symptom is a endless loop trying to log into the admin panel. >>> >>> Cheers >>> Niels >>> >>> >>> # cat standalone/log/server.log | grep -A 58 '2016-05-24 09:19:27,672' >>> 2016-05-24 09:19:27,672 WARN [org.keycloak.events] (default task-19) >>> type=CODE_TO_TOKEN_ERROR, realmId=master, clientId=admin, userId=null, >>> ipAddress=*192.168.33.1*, error=invalid_client_credentials, >>> grant_type=authorization_code >>> 2016-05-24 09:19:27,673 INFO [io.undertow.request.dump] (default >>> task-19) >>> ----------------------------REQUEST--------------------------- >>> URI=/auth/realms/master/protocol/openid-connect/token >>> characterEncoding=null >>> contentLength=229 >>> contentType=[application/x-www-form-urlencoded] >>> >>> cookie=KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjM5YTVkNTlmLWMyNDYtNDkwZi04ZGZkLTZhYzVhNzgyZDI5ZCIsImNpZCI6InNlY3VyaXR5LWFkbWluLWNvbnNvbGUiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9hZG1pbi9tYXN0ZXIvY29uc29sZS8iLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiOGQ5ZGI4MzctMjY2Ni00NDcxLTk0ZDgtZmFkMmIxMjA3NDQxIiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL3JlYWxtcy9tYXN0ZXIiLCJyZXNwb25zZV90eXBlIjoiY29kZSIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL2FkbWluL21hc3Rlci9jb25zb2xlLyIsInN0YXRlIjoiNTQ4ZDE5ZTUtMjlkMS00NTU2LWFjNjAtYjZjZTM1ZmJiMGU2Iiwibm9uY2UiOiI5OGY3NDFiYS03MmQwLTQ0ZDUtOGQ0ZC1jZTAxNzZhYjMyMmUiLCJyZXNwb25zZV9tb2RlIjoiZnJhZ21lbnQifX0.I0jI4nDhbYtKNrVjdlwjjBe5mtd0a8u6Dm7rQXwLE60 >>> >>> cookie=KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJhNjY5OWJkOS00MWQ4LTQyNWYtYjE5Ni04Y2QzNmJiZjBmNjQiLCJleHAiOjE0NjQxMTc1NjcsIm5iZiI6MCwiaWF0IjoxNDY0MDgxNTY3LCJpc3MiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9yZWFsbXMvbWFzdGVyIiwic3ViIjoiY2YyNDg4MTEtNmQ4Mi00N2U3LWJmOWEtN2IxOTdmYjk4OGQwIiwic2Vzc2lvbl9zdGF0ZSI6IjFiYTljODRlLTBlMzctNGE4Mi1hNDg0LWMyNWQyYzRhODBmYyIsInJlc291cmNlX2FjY2VzcyI6e319.E0vEe9XQJ_6IbDC_TEUfumQCJ0fS1_AOYsHh7svyGp16VC89sH9J1FQuLJfHYFVJlDTcE6o2ktLg0fLw2nLIdLOv-WXMseYr0KzudZveiLy1CZbRoPS9w9vlN-_EuXojiz0ORcyh90keUhqW5tMShccHvEaq_wpXOJQ6ITIglsgUXNhlSuEfpEcBy4CCqKQW98bRQiTKQOtoOfgc-Ez1RHR-7esTw-U22P_H-EMk23jI3nwuYGtqOn4Vvqb4-cHOzdyE_xaVWZxeteNKhU-RexfrMaHx1PSy3T796aY7gIljcqkxra-SA1dbOsRBawwlhJwFtojzBHEs1841gJ4bgg >>> >>> cookie=KEYCLOAK_SESSION=master/cf248811-6d82-47e7-bf9a-7b197fb988d0/1ba9c84e-0e37-4a82-a484-c25d2c4a80fc >>> header=Accept=*/* >>> header=Accept-Language=en-US,en;q=0.8,de;q=0.6 >>> header=Accept-Encoding=gzip, deflate >>> header=DNT=1 >>> header=Origin=https://login.vagrant.v8 >>> header=X-Original-To=192.168.33.80 >>> header=User-Agent=Mozilla/5.0 (Windows NT 6.1; WOW64) >>> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 >>> header=X-Forwarded-Proto=https >>> header=X-Forwarded-Port=443 >>> header=X-Forwarded-For=192.168.33.1 >>> header=Content-Length=229 >>> header=Content-Type=application/x-www-form-urlencoded >>> >>> header=Cookie=KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjM5YTVkNTlmLWMyNDYtNDkwZi04ZGZkLTZhYzVhNzgyZDI5ZCIsImNpZCI6InNlY3VyaXR5LWFkbWluLWNvbnNvbGUiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9hZG1pbi9tYXN0ZXIvY29uc29sZS8iLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiOGQ5ZGI4MzctMjY2Ni00NDcxLTk0ZDgtZmFkMmIxMjA3NDQxIiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL3JlYWxtcy9tYXN0ZXIiLCJyZXNwb25zZV90eXBlIjoiY29kZSIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL2FkbWluL21hc3Rlci9jb25zb2xlLyIsInN0YXRlIjoiNTQ4ZDE5ZTUtMjlkMS00NTU2LWFjNjAtYjZjZTM1ZmJiMGU2Iiwibm9uY2UiOiI5OGY3NDFiYS03MmQwLTQ0ZDUtOGQ0ZC1jZTAxNzZhYjMyMmUiLCJyZXNwb25zZV9tb2RlIjoiZnJhZ21lbnQifX0.I0jI4nDhbYtKNrVjdlwjjBe5mtd0a8u6Dm7rQXwLE60; >>> KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJhNjY5OWJkOS00MWQ4LTQyNWYtYjE5Ni04Y2QzNmJiZjBmNjQiLCJleHAiOjE0NjQxMTc1NjcsIm5iZiI6MCwiaWF0IjoxNDY0MDgxNTY3LCJpc3MiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9yZWFsbXMvbWFzdGVyIiwic3ViIjoiY2YyNDg4MTEtNmQ4Mi00N2U3LWJmOWEtN2IxOTdmYjk4OGQwIiwic2Vzc2lvbl9zdGF0ZSI6IjFiYTljODRlLTBlMzctNGE4Mi1hNDg0LWMyNWQyYzRhODBmYyIsInJlc291cmNlX2FjY2VzcyI6e319.E0vEe9XQJ_6IbDC_TEUfumQCJ0fS1_AOYsHh7svyGp16VC89sH9J1FQuLJfHYFVJlDTcE6o2ktLg0fLw2nLIdLOv-WXMseYr0KzudZveiLy1CZbRoPS9w9vlN-_EuXojiz0ORcyh90keUhqW5tMShccHvEaq_wpXOJQ6ITIglsgUXNhlSuEfpEcBy4CCqKQW98bRQiTKQOtoOfgc-Ez1RHR-7esTw-U22P_H-EMk23jI3nwuYGtqOn4Vvqb4-cHOzdyE_xaVWZxeteNKhU-RexfrMaHx1PSy3T796aY7gIljcqkxra-SA1dbOsRBawwlhJwFtojzBHEs1841gJ4bgg; >>> KEYCLOAK_SESSION=master/cf248811-6d82-47e7-bf9a-7b197fb988d0/1ba9c84e-0e37-4a82-a484-c25d2c4a80fc >>> header=Referer= >>> https://login.vagrant.v8/auth/admin/master/console/ >>> header=Host=login.vagrant.v8 >>> locale=[en_US, en, de] >>> method=POST >>> protocol=HTTP/1.1 >>> queryString= >>> * remoteAddr=/192.168.33.80:54672 * >>> remoteHost=proxy.vagrant.v8 >>> scheme=https >>> host=login.vagrant.v8 >>> serverPort=443 >>> --------------------------RESPONSE-------------------------- >>> contentLength=123 >>> contentType=application/json >>> header=X-Powered-By=Undertow/1 >>> header=Server=WildFly/10 >>> header=Content-Type=application/json >>> header=Content-Length=123 >>> header=Date=Tue, 24 May 2016 09:19:27 GMT >>> status=400 >>> >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/7432c5ac/attachment-0001.html From sthorger at redhat.com Wed May 25 02:40:49 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 25 May 2016 08:40:49 +0200 Subject: [keycloak-user] How to set realm tokens units programmatically In-Reply-To: References: Message-ID: The unit is only used in the UI. It automatically guesses the unit based from the time. On 24 May 2016 at 14:53, Haim Vana wrote: > Great ? thanks a lot J > > > > > > *From:* John D. Ament [mailto:john.d.ament at gmail.com] > *Sent:* Tuesday, May 24, 2016 3:51 PM > > *To:* Haim Vana ; keycloak-user at lists.jboss.org > *Subject:* Re: [keycloak-user] How to set realm tokens units > programmatically > > > > The value passed in is in seconds. I just checked against what the UI > sends to the backend. That's why my example used 2 * 60 * 60 (7200 seconds > = 2 hours) > > > > John > > > > On Tue, May 24, 2016 at 8:50 AM Haim Vana > wrote: > > I did, however Keycloak converts it back to minutes. > > For example 2 * 60 is converted by Keycloak to 2 minutes instead of 2 > hours. > > > > > > *From:* John D. Ament [mailto:john.d.ament at gmail.com] > *Sent:* Tuesday, May 24, 2016 3:44 PM > *To:* Haim Vana ; keycloak-user at lists.jboss.org > *Subject:* Re: [keycloak-user] How to set realm tokens units > programmatically > > > > I would just expand it out into the proper value, e.g. > > > > 2 * 60 * 60 > > > > John > > On Tue, May 24, 2016 at 8:28 AM Haim Vana > wrote: > > Hi, > > > > When I am setting realm tokens programmatically, for example 'Sso Session > Idle Timeout', how can I set its units ? > > > > This is how I am setting the parameter programmatically: > > *realmRepresentation.setSsoSessionIdleTimeout(120);* > > > > However I couldn't find how to set the units from minutes to hours, when I > am setting the above it is displayed (and act !) as 2 minutes in the UI. > > > > > > Any advice will be appreciated. > > > > > > Thanks, > > Haim. > > > > > > The information contained in this message is proprietary to the sender, > protected from disclosure, and may be privileged. The information is > intended to be conveyed only to the designated recipient(s) of the message. > If the reader of this message is not the intended recipient, you are hereby > notified that any dissemination, use, distribution or copying of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. Thank you. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > The information contained in this message is proprietary to the sender, > protected from disclosure, and may be privileged. The information is > intended to be conveyed only to the designated recipient(s) of the message. > If the reader of this message is not the intended recipient, you are hereby > notified that any dissemination, use, distribution or copying of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. Thank you. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > The information contained in this message is proprietary to the sender, > protected from disclosure, and may be privileged. The information is > intended to be conveyed only to the designated recipient(s) of the message. > If the reader of this message is not the intended recipient, you are hereby > notified that any dissemination, use, distribution or copying of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. Thank you. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/2629ec44/attachment.html From sthorger at redhat.com Wed May 25 02:41:53 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 25 May 2016 08:41:53 +0200 Subject: [keycloak-user] Offline token validation - can it be deployed within a Docker image In-Reply-To: References: Message-ID: A token (offline or regular) is issued by a specific instance of Keycloak and is bound to the Keycloak servers URL as well as it's keys. So you can't really share a offline token in the way you're doing unless it all uses the same Keycloak server. On 24 May 2016 at 21:24, Haim Vana wrote: > Hi, > > > > We are using offline tokens for internal flows, and we would to create a > Docker image with the offline token to be used for example for all > developers. > > > > However the offline token validation failed on different host (than the > one it was generated from). > > > > Is there an option to pass the URL validation just for dev ? or overcome > it in a different way ? > > > > > > Any advice will be appreciated. > > > > > > Thanks, > > Haim. > The information contained in this message is proprietary to the sender, > protected from disclosure, and may be privileged. The information is > intended to be conveyed only to the designated recipient(s) of the message. > If the reader of this message is not the intended recipient, you are hereby > notified that any dissemination, use, distribution or copying of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. Thank you. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/3de8faf1/attachment.html From sthorger at redhat.com Wed May 25 02:43:19 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 25 May 2016 08:43:19 +0200 Subject: [keycloak-user] How to include the keycloak wildfly adapter libraries in the secure war application classpath? In-Reply-To: References: <20160520101013.GA24124@abstractj.org> <20160520125140.GA29687@abstractj.org> Message-ID: What version of WildFly do you have? On 25 May 2016 at 07:43, Darrell Wu wrote: > It doesn't seem to work for me. It looks like it looking in the wrong > place, If i copy the keycloak libraries to > modules\system\layers\base\org\keycloak directory then it works. Also my > WAR is within an EAR archive > > > On 25 May 2016 at 17:05, Stian Thorgersen wrote: > >> The dependencies should be automatically injected into your WAR if it's >> either secured in standalone.xml or if the auth-method is set to KEYCLOAK. >> >> On 21 May 2016 at 05:15, Darrell Wu wrote: >> >>> I'm not using the saml client adapters, i'm using the jboss/wildfly >>> adapter >>> as mention here >>> >>> http://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#jboss-adapter >>> >>> I have the following in my wildfly 10 standalone.xml file >>> under entensions >>> >>> >>> >>> under security subsystem >>> >>> >>> >> code="org.keycloak.adapters.jboss.KeycloakLoginModule" flag="required"/> >>> >>> >>> >>> under the keycloak subsystem i have secure my application >>> >>> >>> 1Place >>> 1Place-reporting >>> xxxxxxxxKey >>> removedxxxxxxxxxxx >>> http://localhost:8180/ >>> >>> EXTERNAL >>> xxxxxxxxKey >>> removedxxxxxxxxxxx >>> >>> >>> The reporting-server-rest.war is in an EAR archive with an ejb jar. The >>> code with the exception is a stateless session bean(OperatorService ) in >>> the ejb jar. >>> It is called by a produces method >>> >>> >>> public class CurrentUserProducer { >>> >>> >>> @Inject >>> OperatorService operatorService; >>> >>> @LoggedInUser >>> @Produces >>> public CurrentUser produceCurrentUser() { >>> return operatorService.getCurrentUser(); >>> } >>> } >>> >>> >>> >>> The OperatorService stateless session bean getCurrentUser method looks >>> like the following. The exception is occurring on the first line >>> @Inject >>> private HttpServletRequest httpRequest; >>> >>> public CurrentUser getCurrentUser(){ >>> KeycloakSecurityContext securityContext = (KeycloakSecurityContext) >>> httpRequest.getAttribute(KeycloakSecurityContext.class.getName()); >>> >>> >>> a filter in the reporting-server-rest.war archive is injecting the >>> CurrentUser like so >>> >>> @WebFilter(dispatcherTypes = {DispatcherType.REQUEST, >>> DispatcherType.FORWARD}, urlPatterns = {"/*"}) >>> public class CurrentUserFilter implements Filter { >>> >>> @Inject @LoggedInUser >>> private CurrentUser currentUser; >>> >>> >>> >>> I'm getting the following exception in the log >>> >>> 14:26:38,444 ERROR [io.undertow.request] (default task-10) UT005023: >>> Exception handling request to >>> /reporting-server-rest/widgets/checklistQuestion: >>> javax.servlet.ServletException: UT010013: Could not instantiate com.one >>> placeonline.rest.CurrentUserFilter >>> at >>> io.undertow.servlet.core.ManagedFilter.createFilter(ManagedFilter.java:76) >>> at >>> io.undertow.servlet.core.ManagedFilter.getFilter(ManagedFilter.java:65) >>> at >>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) >>> at >>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) >>> at >>> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) >>> at >>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) >>> at >>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) >>> at >>> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) >>> at >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> at >>> org.keycloak.adapters.undertow.UndertowAuthenticatedActionsHandler.handleRequest(UndertowAuthenticatedActionsHandler.java:66) >>> at >>> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) >>> at >>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) >>> at >>> io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) >>> at >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> at >>> io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) >>> at >>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) >>> at >>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) >>> at >>> io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) >>> at >>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) >>> at >>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) >>> at >>> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) >>> at >>> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) >>> at >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> at >>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >>> at >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> at >>> org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) >>> at >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> at >>> io.undertow.servlet.handlers.ServletInitialHandler.jrHandle(ServletInitialHandler.java) >>> at >>> org.zeroturnaround.javarebel.integration.servlet.undertow.cbp.ServletInitialHandlerCBP.handleRequest(ServletInitialHandlerCBP.java:100) >>> at >>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) >>> at >>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) >>> at >>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) >>> at >>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) >>> at >>> io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) >>> at >>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) >>> at >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>> at java.lang.Thread.run(Thread.java:745) >>> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to >>> construct component instance >>> at >>> org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163) >>> at >>> org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134) >>> at >>> org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88) >>> at >>> org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReferenceFactory.getReference(ComponentRegistry.java:149) >>> at >>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$6.createInstance(UndertowDeploymentInfoService.java:1366) >>> at >>> io.undertow.servlet.core.ManagedFilter.createFilter(ManagedFilter.java:74) >>> ... 37 more >>> Caused by: javax.ejb.EJBException: WFLYEJB0442: Unexpected Error >>> at >>> org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:184) >>> at >>> org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) >>> at >>> org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) >>> at >>> org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) >>> at >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>> at >>> org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) >>> at >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>> at >>> org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) >>> at >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>> at >>> org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) >>> at >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>> at >>> org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) >>> at >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>> at >>> org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66) >>> at >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>> at >>> org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) >>> at >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>> at >>> org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) >>> at >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>> at >>> org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) >>> at >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>> at >>> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) >>> at >>> org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) >>> at >>> org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) >>> at >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>> at >>> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) >>> at >>> org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) >>> at >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>> at >>> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) >>> at >>> org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195) >>> at >>> org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) >>> at >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>> at >>> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) >>> at >>> org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) >>> at >>> com.oneplaceonline.business.users.boundary.OperatorService$$$view14.getCurrentUser(Unknown >>> Source) >>> at sun.reflect.GeneratedMethodAccessor89.invoke(Unknown Source) >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.lang.reflect.Method.invoke(Method.java:497) >>> at >>> org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:436) >>> at >>> org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127) >>> at >>> org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) >>> at >>> org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:67) >>> at >>> org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) >>> at >>> com.oneplaceonline.business.users.boundary.OperatorService$Proxy$_$$_Weld$EnterpriseProxy$.getCurrentUser(Unknown >>> Source) >>> at >>> com.oneplaceonline.business.users.boundary.CurrentUserProducer.produceCurrentUser(CurrentUserProducer.java:17) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.lang.reflect.Method.invoke(Method.java:497) >>> at >>> org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) >>> at >>> org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) >>> at >>> org.jboss.weld.injection.producer.ProducerMethodProducer.produce(ProducerMethodProducer.java:99) >>> at >>> org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:161) >>> at >>> org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:181) >>> at >>> org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:70) >>> at >>> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) >>> at >>> org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) >>> at >>> org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742) >>> at >>> org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:842) >>> at >>> org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92) >>> at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:378) >>> at >>> org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:389) >>> at >>> org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:71) >>> at >>> org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) >>> at >>> org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:73) >>> at >>> org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121) >>> at >>> org.jboss.as.weld.injection.WeldInjectionContext.inject(WeldInjectionContext.java:39) >>> at >>> org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:51) >>> at >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>> at >>> org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28) >>> at >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>> at >>> org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56) >>> at >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>> at >>> org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43) >>> at >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>> at >>> org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) >>> at >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>> at >>> org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) >>> at >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>> at >>> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) >>> at >>> org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) >>> at >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>> at >>> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) >>> at >>> org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161) >>> ... 42 more >>> Caused by: java.lang.NoClassDefFoundError: >>> org/keycloak/KeycloakSecurityContext >>> at >>> com.oneplaceonline.business.users.boundary.OperatorService.getCurrentUser(OperatorService.java:81) >>> at sun.reflect.GeneratedMethodAccessor89.invoke(Unknown Source) >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.lang.reflect.Method.invoke(Method.java:497) >>> at >>> org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) >>> at >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>> at >>> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) >>> at >>> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) >>> at >>> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) >>> at >>> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) >>> at >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>> at >>> org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) >>> at >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>> at >>> org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) >>> at >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>> at >>> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) >>> at >>> org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64) >>> at >>> org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) >>> at >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>> at >>> org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) >>> at >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>> at >>> org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) >>> at >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>> at >>> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) >>> at >>> org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) >>> at >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>> at >>> org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) >>> at >>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>> at >>> org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) >>> ... 124 more >>> >>> Does it have anything to do with the change in 1.9.0 >>> >>> http://keycloak.github.io/docs/userguide/keycloak-server/html/Migration_from_older_versions.html#d4e4103 >>> under >>> 35.6.3. Migrating to 1.9.0Adapter Subsystems only bring in dependencies >>> if keycloak is on >>> >>> Previously, if you had installed our saml or oidc keycloak subsystem >>> adapters into Wildfly or JBoss EAP, we would automatically include Keycloak >>> client jars into EVERY application irregardless if you were using Keycloak >>> or not. These libraries are now only added to your deployment if you have >>> keycloak authentication turned on for that adapter (via the subsystem, or >>> auth-method in web.xml >>> >>> Mind you i'm not using saml or oidc adapter >>> >>> >>> >>> On 21 May 2016 at 00:51, Bruno Oliveira wrote: >>> >>>> Do you have the security domain specified like described here: >>>> >>>> http://keycloak.github.io/docs/userguide/saml-client-adapter/html/jboss-adapter.html >>>> >>>> If possible send some steps to reproduce or the code snippet. >>>> >>>> >>>> On 2016-05-20, Darrell Wu wrote: >>>> > If it helps I'm using wildfly 10 and have keycloak on a standalone >>>> server. >>>> > The authenication works. It just when my app tries to read the >>>> security >>>> > context I get the class not found exception. >>>> > >>>> > So what triggers wildfly to include the keycloak modules in my apps >>>> class >>>> > path? >>>> > On 20/05/2016 10:10 pm, "Bruno Oliveira" wrote: >>>> > >>>> > > Weird because it was fixed here: >>>> > > https://issues.jboss.org/browse/KEYCLOAK-2483. Plus, I tested >>>> > > on WildFly 9.0.2.Final with Keycloak adapter 1.9.4.Final and >>>> couldn't >>>> > > reproduce the issue. >>>> > > >>>> > > On 2016-05-20, Darrell Wu wrote: >>>> > > > Hi, >>>> > > > >>>> > > > With the keycloak wildfly adapter for version 1.9.x i've noticed >>>> that the >>>> > > > location of the Keycloak Subsystem modules have changed from >>>> > > > modules\system\layers\base\org\keycloak to >>>> > > > modules\system\add-ons\keycloak\org\keycloak >>>> > > > >>>> > > > Now on my secure war application server I've installed the >>>> keycloak >>>> > > wildfly >>>> > > > adpater by unzipping the archive and running the >>>> adapter-install.cl >>>> > > script. >>>> > > > >>>> > > > Now In my application i'm getting a >>>> > > > ClassNotFoundException: org.keycloak.KeycloakSecurityContext >>>> > > > >>>> > > > when the following is executed >>>> > > > >>>> > > > KeycloakSecurityContext securityContext = >>>> (KeycloakSecurityContext) >>>> > > > httpRequest.getAttribute(KeycloakSecurityContext.class.getName()); >>>> > > > >>>> > > > Obviously the application isn't loading the keycloak modules in >>>> the >>>> > > > classpath. >>>> > > > What is the proper way to include the keycloak libraries in my >>>> app? >>>> > > > >>>> > > > Should my app have a jboss-deployment-structure.xml file or >>>> should the >>>> > > > libraries be moved back to >>>> modules\system\layers\base\org\keycloak? >>>> > > > >>>> > > > Thanks >>>> > > > >>>> > > > >>>> > > > >>>> > > > -- >>>> > > > Darrell Wu >>>> > > > 1Place Limited >>>> > > > P.O. Box 125152, St Heliers, Auckland 1740, New Zealand >>>> > > > Level 4, 1 Queen Street, Auckland 1010, New Zealand >>>> > > > Phone: +64 9 5200612 ext 521 | Mob: +64 21 262 4898 | Fax: +64 9 >>>> 5246203 >>>> > > > Email: darrell at 1placeonline.com | Web: www.1placeonline.com >>>> > > >>>> > > > _______________________________________________ >>>> > > > keycloak-user mailing list >>>> > > > keycloak-user at lists.jboss.org >>>> > > > https://lists.jboss.org/mailman/listinfo/keycloak-user >>>> > > >>>> > > >>>> > > -- >>>> > > >>>> > > abstractj >>>> > > PGP: 0x84DC9914 >>>> > > >>>> >>>> -- >>>> >>>> abstractj >>>> PGP: 0x84DC9914 >>>> >>> >>> >>> >>> -- >>> Darrell Wu >>> 1Place Limited >>> P.O. Box 125152, St Heliers, Auckland 1740, New Zealand >>> Level 4, 1 Queen Street, Auckland 1010, New Zealand >>> Phone: +64 9 5200612 ext 521 | Mob: +64 21 262 4898 | Fax: +64 9 5246203 >>> Email: darrell at 1placeonline.com | Web: www.1placeonline.com >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> >> > > > -- > Darrell Wu > 1Place Limited > P.O. Box 125152, St Heliers, Auckland 1740, New Zealand > Level 4, 1 Queen Street, Auckland 1010, New Zealand > Phone: +64 9 5200612 ext 521 | Mob: +64 21 262 4898 | Fax: +64 9 5246203 > Email: darrell at 1placeonline.com | Web: www.1placeonline.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/3a08be7a/attachment-0001.html From darrell at 1placeonline.com Wed May 25 02:49:52 2016 From: darrell at 1placeonline.com (Darrell Wu) Date: Wed, 25 May 2016 18:49:52 +1200 Subject: [keycloak-user] How to include the keycloak wildfly adapter libraries in the secure war application classpath? In-Reply-To: References: <20160520101013.GA24124@abstractj.org> <20160520125140.GA29687@abstractj.org> Message-ID: I'm using wildfly 10 On Wednesday, 25 May 2016, Stian Thorgersen wrote: > What version of WildFly do you have? > > On 25 May 2016 at 07:43, Darrell Wu > wrote: > >> It doesn't seem to work for me. It looks like it looking in the wrong >> place, If i copy the keycloak libraries to >> modules\system\layers\base\org\keycloak directory then it works. Also my >> WAR is within an EAR archive >> >> >> On 25 May 2016 at 17:05, Stian Thorgersen > > wrote: >> >>> The dependencies should be automatically injected into your WAR if it's >>> either secured in standalone.xml or if the auth-method is set to KEYCLOAK. >>> >>> On 21 May 2016 at 05:15, Darrell Wu >> > wrote: >>> >>>> I'm not using the saml client adapters, i'm using the jboss/wildfly >>>> adapter >>>> as mention here >>>> >>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#jboss-adapter >>>> >>>> I have the following in my wildfly 10 standalone.xml file >>>> under entensions >>>> >>>> >>>> >>>> under security subsystem >>>> >>>> >>>> >>> code="org.keycloak.adapters.jboss.KeycloakLoginModule" flag="required"/> >>>> >>>> >>>> >>>> under the keycloak subsystem i have secure my application >>>> >>>> >>>> 1Place >>>> 1Place-reporting >>>> xxxxxxxxKey >>>> removedxxxxxxxxxxx >>>> http://localhost:8180/ >>>> >>>> EXTERNAL >>>> xxxxxxxxKey >>>> removedxxxxxxxxxxx >>>> >>>> >>>> The reporting-server-rest.war is in an EAR archive with an ejb jar. >>>> The code with the exception is a stateless session bean(OperatorService ) >>>> in the ejb jar. >>>> It is called by a produces method >>>> >>>> >>>> public class CurrentUserProducer { >>>> >>>> >>>> @Inject >>>> OperatorService operatorService; >>>> >>>> @LoggedInUser >>>> @Produces >>>> public CurrentUser produceCurrentUser() { >>>> return operatorService.getCurrentUser(); >>>> } >>>> } >>>> >>>> >>>> >>>> The OperatorService stateless session bean getCurrentUser method >>>> looks like the following. The exception is occurring on the first line >>>> @Inject >>>> private HttpServletRequest httpRequest; >>>> >>>> public CurrentUser getCurrentUser(){ >>>> KeycloakSecurityContext securityContext = (KeycloakSecurityContext) >>>> httpRequest.getAttribute(KeycloakSecurityContext.class.getName()); >>>> >>>> >>>> a filter in the reporting-server-rest.war archive is injecting the >>>> CurrentUser like so >>>> >>>> @WebFilter(dispatcherTypes = {DispatcherType.REQUEST, >>>> DispatcherType.FORWARD}, urlPatterns = {"/*"}) >>>> public class CurrentUserFilter implements Filter { >>>> >>>> @Inject @LoggedInUser >>>> private CurrentUser currentUser; >>>> >>>> >>>> >>>> I'm getting the following exception in the log >>>> >>>> 14:26:38,444 ERROR [io.undertow.request] (default task-10) UT005023: >>>> Exception handling request to >>>> /reporting-server-rest/widgets/checklistQuestion: >>>> javax.servlet.ServletException: UT010013: Could not instantiate com.one >>>> placeonline.rest.CurrentUserFilter >>>> at >>>> io.undertow.servlet.core.ManagedFilter.createFilter(ManagedFilter.java:76) >>>> at >>>> io.undertow.servlet.core.ManagedFilter.getFilter(ManagedFilter.java:65) >>>> at >>>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) >>>> at >>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) >>>> at >>>> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) >>>> at >>>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) >>>> at >>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) >>>> at >>>> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) >>>> at >>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>> at >>>> org.keycloak.adapters.undertow.UndertowAuthenticatedActionsHandler.handleRequest(UndertowAuthenticatedActionsHandler.java:66) >>>> at >>>> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) >>>> at >>>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) >>>> at >>>> io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) >>>> at >>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>> at >>>> io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) >>>> at >>>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) >>>> at >>>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) >>>> at >>>> io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) >>>> at >>>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) >>>> at >>>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) >>>> at >>>> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) >>>> at >>>> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) >>>> at >>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>> at >>>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >>>> at >>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>> at >>>> org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) >>>> at >>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>> at >>>> io.undertow.servlet.handlers.ServletInitialHandler.jrHandle(ServletInitialHandler.java) >>>> at >>>> org.zeroturnaround.javarebel.integration.servlet.undertow.cbp.ServletInitialHandlerCBP.handleRequest(ServletInitialHandlerCBP.java:100) >>>> at >>>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) >>>> at >>>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) >>>> at >>>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) >>>> at >>>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) >>>> at >>>> io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) >>>> at >>>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>>> at java.lang.Thread.run(Thread.java:745) >>>> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to >>>> construct component instance >>>> at >>>> org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163) >>>> at >>>> org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134) >>>> at >>>> org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88) >>>> at >>>> org.jboss.as.ee.component.ComponentRegistry$ComponentManagedReferenceFactory.getReference(ComponentRegistry.java:149) >>>> at >>>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$6.createInstance(UndertowDeploymentInfoService.java:1366) >>>> at >>>> io.undertow.servlet.core.ManagedFilter.createFilter(ManagedFilter.java:74) >>>> ... 37 more >>>> Caused by: javax.ejb.EJBException: WFLYEJB0442: Unexpected Error >>>> at >>>> org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:184) >>>> at >>>> org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:277) >>>> at >>>> org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327) >>>> at >>>> org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) >>>> at >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>>> at >>>> org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) >>>> at >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>>> at >>>> org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) >>>> at >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>>> at >>>> org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) >>>> at >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>>> at >>>> org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) >>>> at >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>>> at >>>> org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66) >>>> at >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>>> at >>>> org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) >>>> at >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>>> at >>>> org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) >>>> at >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>>> at >>>> org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) >>>> at >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>>> at >>>> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) >>>> at >>>> org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636) >>>> at >>>> org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61) >>>> at >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>>> at >>>> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) >>>> at >>>> org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) >>>> at >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>>> at >>>> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) >>>> at >>>> org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195) >>>> at >>>> org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) >>>> at >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>>> at >>>> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) >>>> at >>>> org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73) >>>> at >>>> com.oneplaceonline.business.users.boundary.OperatorService$$$view14.getCurrentUser(Unknown >>>> Source) >>>> at sun.reflect.GeneratedMethodAccessor89.invoke(Unknown Source) >>>> at >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> at java.lang.reflect.Method.invoke(Method.java:497) >>>> at >>>> org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:436) >>>> at >>>> org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127) >>>> at >>>> org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) >>>> at >>>> org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:67) >>>> at >>>> org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) >>>> at >>>> com.oneplaceonline.business.users.boundary.OperatorService$Proxy$_$$_Weld$EnterpriseProxy$.getCurrentUser(Unknown >>>> Source) >>>> at >>>> com.oneplaceonline.business.users.boundary.CurrentUserProducer.produceCurrentUser(CurrentUserProducer.java:17) >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>> at >>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>> at >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> at java.lang.reflect.Method.invoke(Method.java:497) >>>> at >>>> org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) >>>> at >>>> org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78) >>>> at >>>> org.jboss.weld.injection.producer.ProducerMethodProducer.produce(ProducerMethodProducer.java:99) >>>> at >>>> org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:161) >>>> at >>>> org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:181) >>>> at >>>> org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:70) >>>> at >>>> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) >>>> at >>>> org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) >>>> at >>>> org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742) >>>> at >>>> org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:842) >>>> at >>>> org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92) >>>> at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:378) >>>> at >>>> org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:389) >>>> at >>>> org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:71) >>>> at >>>> org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) >>>> at >>>> org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:73) >>>> at >>>> org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121) >>>> at >>>> org.jboss.as.weld.injection.WeldInjectionContext.inject(WeldInjectionContext.java:39) >>>> at >>>> org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:51) >>>> at >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>>> at >>>> org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28) >>>> at >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>>> at >>>> org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56) >>>> at >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>>> at >>>> org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43) >>>> at >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>>> at >>>> org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) >>>> at >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>>> at >>>> org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64) >>>> at >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>>> at >>>> org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356) >>>> at >>>> org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80) >>>> at >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>>> at >>>> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) >>>> at >>>> org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161) >>>> ... 42 more >>>> Caused by: java.lang.NoClassDefFoundError: >>>> org/keycloak/KeycloakSecurityContext >>>> at >>>> com.oneplaceonline.business.users.boundary.OperatorService.getCurrentUser(OperatorService.java:81) >>>> at sun.reflect.GeneratedMethodAccessor89.invoke(Unknown Source) >>>> at >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> at java.lang.reflect.Method.invoke(Method.java:497) >>>> at >>>> org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) >>>> at >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>>> at >>>> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) >>>> at >>>> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) >>>> at >>>> org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) >>>> at >>>> org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) >>>> at >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>>> at >>>> org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) >>>> at >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>>> at >>>> org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47) >>>> at >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>>> at >>>> org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437) >>>> at >>>> org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64) >>>> at >>>> org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83) >>>> at >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>>> at >>>> org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) >>>> at >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>>> at >>>> org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) >>>> at >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>>> at >>>> org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) >>>> at >>>> org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) >>>> at >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>>> at >>>> org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) >>>> at >>>> org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340) >>>> at >>>> org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) >>>> ... 124 more >>>> >>>> Does it have anything to do with the change in 1.9.0 >>>> >>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/Migration_from_older_versions.html#d4e4103 >>>> under >>>> 35.6.3. Migrating to 1.9.0Adapter Subsystems only bring in >>>> dependencies if keycloak is on >>>> >>>> Previously, if you had installed our saml or oidc keycloak subsystem >>>> adapters into Wildfly or JBoss EAP, we would automatically include Keycloak >>>> client jars into EVERY application irregardless if you were using Keycloak >>>> or not. These libraries are now only added to your deployment if you have >>>> keycloak authentication turned on for that adapter (via the subsystem, or >>>> auth-method in web.xml >>>> >>>> Mind you i'm not using saml or oidc adapter >>>> >>>> >>>> >>>> On 21 May 2016 at 00:51, Bruno Oliveira >>> > wrote: >>>> >>>>> Do you have the security domain specified like described here: >>>>> >>>>> http://keycloak.github.io/docs/userguide/saml-client-adapter/html/jboss-adapter.html >>>>> >>>>> If possible send some steps to reproduce or the code snippet. >>>>> >>>>> >>>>> On 2016-05-20, Darrell Wu wrote: >>>>> > If it helps I'm using wildfly 10 and have keycloak on a standalone >>>>> server. >>>>> > The authenication works. It just when my app tries to read the >>>>> security >>>>> > context I get the class not found exception. >>>>> > >>>>> > So what triggers wildfly to include the keycloak modules in my apps >>>>> class >>>>> > path? >>>>> > On 20/05/2016 10:10 pm, "Bruno Oliveira" >>>> > wrote: >>>>> > >>>>> > > Weird because it was fixed here: >>>>> > > https://issues.jboss.org/browse/KEYCLOAK-2483. Plus, I tested >>>>> > > on WildFly 9.0.2.Final with Keycloak adapter 1.9.4.Final and >>>>> couldn't >>>>> > > reproduce the issue. >>>>> > > >>>>> > > On 2016-05-20, Darrell Wu wrote: >>>>> > > > Hi, >>>>> > > > >>>>> > > > With the keycloak wildfly adapter for version 1.9.x i've noticed >>>>> that the >>>>> > > > location of the Keycloak Subsystem modules have changed from >>>>> > > > modules\system\layers\base\org\keycloak to >>>>> > > > modules\system\add-ons\keycloak\org\keycloak >>>>> > > > >>>>> > > > Now on my secure war application server I've installed the >>>>> keycloak >>>>> > > wildfly >>>>> > > > adpater by unzipping the archive and running the >>>>> adapter-install.cl >>>>> > > script. >>>>> > > > >>>>> > > > Now In my application i'm getting a >>>>> > > > ClassNotFoundException: org.keycloak.KeycloakSecurityContext >>>>> > > > >>>>> > > > when the following is executed >>>>> > > > >>>>> > > > KeycloakSecurityContext securityContext = >>>>> (KeycloakSecurityContext) >>>>> > > > >>>>> httpRequest.getAttribute(KeycloakSecurityContext.class.getName()); >>>>> > > > >>>>> > > > Obviously the application isn't loading the keycloak modules in >>>>> the >>>>> > > > classpath. >>>>> > > > What is the proper way to include the keycloak libraries in my >>>>> app? >>>>> > > > >>>>> > > > Should my app have a jboss-deployment-structure.xml file or >>>>> should the >>>>> > > > libraries be moved back to >>>>> modules\system\layers\base\org\keycloak? >>>>> > > > >>>>> > > > Thanks >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > -- >>>>> > > > Darrell Wu >>>>> > > > 1Place Limited >>>>> > > > P.O. Box 125152, St Heliers, Auckland 1740, New Zealand >>>>> > > > Level 4, 1 Queen Street, Auckland 1010, New Zealand >>>>> > > > Phone: +64 9 5200612 ext 521 | Mob: +64 21 262 4898 | Fax: +64 >>>>> 9 5246203 >>>>> > > > Email: darrell at 1placeonline.com >>>>> | Web: >>>>> www.1placeonline.com >>>>> > > >>>>> > > > _______________________________________________ >>>>> > > > keycloak-user mailing list >>>>> > > > keycloak-user at lists.jboss.org >>>>> >>>>> > > > https://lists.jboss.org/mailman/listinfo/keycloak-user >>>>> > > >>>>> > > >>>>> > > -- >>>>> > > >>>>> > > abstractj >>>>> > > PGP: 0x84DC9914 >>>>> > > >>>>> >>>>> -- >>>>> >>>>> abstractj >>>>> PGP: 0x84DC9914 >>>>> >>>> >>>> >>>> >>>> -- >>>> Darrell Wu >>>> 1Place Limited >>>> P.O. Box 125152, St Heliers, Auckland 1740, New Zealand >>>> Level 4, 1 Queen Street, Auckland 1010, New Zealand >>>> Phone: +64 9 5200612 ext 521 | Mob: +64 21 262 4898 | Fax: +64 9 >>>> 5246203 >>>> Email: darrell at 1placeonline.com >>>> | Web: >>>> www.1placeonline.com >>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user at lists.jboss.org >>>> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>> >>> >>> >> >> >> -- >> Darrell Wu >> 1Place Limited >> P.O. Box 125152, St Heliers, Auckland 1740, New Zealand >> Level 4, 1 Queen Street, Auckland 1010, New Zealand >> Phone: +64 9 5200612 ext 521 | Mob: +64 21 262 4898 | Fax: +64 9 5246203 >> Email: darrell at 1placeonline.com >> | Web: >> www.1placeonline.com >> > > -- Darrell Wu 1Place Limited P.O. Box 125152, St Heliers, Auckland 1740, New Zealand Level 4, 1 Queen Street, Auckland 1010, New Zealand Phone: +64 9 5200612 ext 521 | Mob: +64 21 262 4898 | Fax: +64 9 5246203 Email: darrell at 1placeonline.com | Web: www.1placeonline.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/cbda53b4/attachment-0001.html From sthorger at redhat.com Wed May 25 03:09:38 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 25 May 2016 09:09:38 +0200 Subject: [keycloak-user] Keycloak OAuth High CPU usage In-Reply-To: References: Message-ID: I did some tests with Linux VM when investigating how Keycloak scales. I had Keycloak running on a VM that was permitted 50% of a single core and had a throughput of 50 scenarios. Where a scenario includes a login request, a code to token request and a logout request. In our performance lab with a single node and a not particularly beefy machine we're seeing 150+ scenarios/second. On 24 May 2016 at 16:05, Vaibhav Naldurgkar < vaibhav_naldurgkar at persistent.com> wrote: > Hello, > > > > What are the tests results on a Linux VM ? I just done same jmeter tests > on AWS m4.xlarge instance; however far behind than the laptop tests results. > > @Stian ? have you done tests using Linux VM ? > > > > > > Thanks, Vaibhav > > > > *From:* Herzberg, Manuel [mailto:manuel.herzberg at atos.net] > *Sent:* Tuesday, May 24, 2016 5:52 PM > *To:* stian at redhat.com; Vaibhav Naldurgkar > *Cc:* keycloak-user at lists.jboss.org > *Subject:* RE: [keycloak-user] Keycloak OAuth High CPU usage > > > > Hello, > > I am evaluating the Keycloak performance. Here my practical experience. My > scenario is the same as Vaibhav?s: > > > > ? Large amount of token have to be generated. This is done by > requesting the Keycloak token REST endpoint via http. The different realms > I am using have 1k 2k 3k and 4k keys for signing the tokens. (RSA) Longer > keys result to longer runtime to generate these tokens. > > > > ? I have more than 10k user each realm. Each request includes a > new user. > Requests look like this: > host1:8080/auth/realms/demo-3072/protocol/openid-connect/token/ > with data: > > username=testuser1&password=password&client_id=customer-portal&grant_type=password > > > > ? The response includes 3 tokens(access, refresh and id). In > total more than 30 000 token have to be generated and signed. > > > > @Stian. You wrote you are able to invoke 10000 token refreshes in under 60 > seconds. A token refresh includes access, refresh and id token right? Can > you explain us your scenario? How do you get such a high number? > > Some more results: just signing 3000 Token (800 Byte each) with a 2k key > takes me 20 seconds (laptop i5-4310U, 12gb ram). I am doing this outside > Keycloak with my own java program, but with the same implementation > Keycloak is using. (sign() method in RSAProvider). > > The Keycloak implementation is signing tokens with RSA. HMAC and ECC are > implemented as well as I saw in the code. Changing from RSA to HMAC or ECC > is not possible in current release as i experienced. Are there plans to > provide this in future? Defining this in a configuration file or via > parameters would be nice. > > Best regards, Manuel Herzberg > > > > > > *From:* keycloak-user-bounces at lists.jboss.org [ > mailto:keycloak-user-bounces at lists.jboss.org > ] *On Behalf Of *Stian Thorgersen > *Sent:* Tuesday, May 24, 2016 8:31 AM > *To:* Vaibhav Naldurgkar > *Cc:* keycloak-user at lists.jboss.org > *Subject:* Re: [keycloak-user] Keycloak OAuth High CPU usage > > > > > > > > On 23 May 2016 at 10:02, Vaibhav Naldurgkar < > vaibhav_naldurgkar at persistent.com> wrote: > > Yes, the direct access grant is ON for this client. I am trying to > understand what you mean by ?not planning on using web based flow?? Could > you provide more clarification on this. > > > > If you are planning to do the web based flow (authorization code grant > flow) you should test with that rather than direct grant. That being said > the direct grant should still perform as well. > > > > > > This is what the scenario I am trying to execute and still have high CPU > usages for KeyCloak Java process. > > > > ? The end point URL > /auth/realms/master/protocol/openid-connect/token has been called by Jmeter > for 20 concurrent users per seconds to generate the tokens. > > ? Even if used with crul command like ?*curl -X POST -d > "=admin&password=admin&password&client_id=HelloTest&grant_type=password" > http://localhost:8080/auth/realms/master/protocol/openid-connect/token > *? > , in this case also the CPU utilizations goes around 100%. > > ? After around 3 seconds of the test, in the output of top > command on the KeyCloak server the CPU% for keycloak java process goes > beyond 100%. > > > > Would it be possible for you to have a quick call for faster fix of this > issue. This performance issue is holding to move KeyCloak to use as OAuth > provider. If any other way is convenient for you please let me know for > further discussion. > > > > Your JMeter test is using 20 concurrent threads to send as many requests > to the direct grant api as it can. This will obviously cause Keycloak to > consume a high percentage of the CPU. Especially if you are running > everything on localhost as the network isn't going to be a bottleneck. > Neither will the database as Keycloak caches everything in memory. The > bottleneck will be the CPU. > > > > Authenticating users and obtaining a token requires password hashing as > well as signing tokens, both are mainly CPU intensive. As you are using the > direct grant api there's also less network traffic. > > > > You need to add some reports to your JMeter test so you can see how many > requests Keycloak can handle. That way you can find out how many users can > be authenticated per-second on your machine. > > > > If you only have 500 users remember they won't all login at the same time > (seconds). Even if they all login at 9am sharp they will be spread out over > 10 minutes or so, which would only be 1.2 logins/second. > > > > > > Thanks, Vaibhav > > > > > > > > > > *From:* Stian Thorgersen [mailto:sthorger at redhat.com] > *Sent:* Monday, May 23, 2016 12:01 PM > > > *To:* Vaibhav Naldurgkar > *Cc:* keycloak-user at lists.jboss.org > *Subject:* Re: [keycloak-user] Keycloak OAuth High CPU usage > > > > You are using direct grant to authenticate a user and obtain a token in > the example above. This authenticates and creates a new session for each > request. Are you not planning on using web based flow? > > > > What do you have password hashing intervals set to? Verifying password is > CPU intensive, more than signing tokens. > > > > It shouldn't matter that user is stored in RedHat IdM as the user would be > cached in Keycloak after first authentication, but it may be an idea to > just double check by trying to authenticate to a user in Keycloak and not > RH IdM. > > > > What results are you actually getting? > > > > > > > > On 20 May 2016 at 11:27, Vaibhav Naldurgkar < > vaibhav_naldurgkar at persistent.com> wrote: > > Hi Stian, > > > > After reading your tests results of 10000 token refreshes in under 60 > seconds on your laptop, I am sure I am not following correct configuration > and the documents are missing for reference. > > > > Could you please verify the below steps along with the screen-shots for > the steps which I am following for the adding client and testing the Load > performance using Jmeter. Please suggest if any changes are needed in the > client configuration. In this case we are obtaining the token for user from > KeyCloak. > > > > In my case the user have been stored on RedHat IdM which has been > federated using KeyCloak. > > > > > > Step 1. Create new client called ?LoadTest? , use the Client Protocol as > ?Openid-connect?. > > Used all defaults values post save of the client action. > > > > Step 2. Start the load tests using Jmeter and using the path as > *?/auth/realms/master/protocol/openid-connect/token?* . Used 20 Number of > Threads and used Post method. > > > > > > Below is the screen-shot for the step 1 related to Add Client. > > > > > > > > > > Below is the screen shot for the load test using Jmeter. In this case the > Client ID was used as HelloTest. > > > > > > > > Http requests. > > > > > > > > Thanks, Vaibhav > > > > > > *From:* Stian Thorgersen [mailto:sthorger at redhat.com] > *Sent:* Friday, May 20, 2016 1:01 PM > > > *To:* Vaibhav Naldurgkar > *Cc:* keycloak-user at lists.jboss.org > *Subject:* Re: [keycloak-user] Keycloak OAuth High CPU usage > > > > Can you please elaborate a bit more on how your are testing scenario is? > I'm a bit confused to what you are testing when you are talking about > generating new tokens. Are you using OIDC or SAML? Are you talking about > code->token exchanges, refresh token requests, or what? > > > > To test if your hardware is capable to deal with the load you need to test > logins (verifying passwords are CPU intensive) as well as obtaining tokens > (both code->token, done after login, and refreshing token, done ~1 min or > so by active users, but most users won't continuously use the application). > > > > 500 users should be no problem at all. As an example with a single thread > (which will use a single core) I could invoke 10000 token refreshes in > under 60 seconds on my laptop. So a single core on my laptop should be able > to handle 500 users. > > > > On 20 May 2016 at 08:00, Vaibhav Naldurgkar < > vaibhav_naldurgkar at persistent.com> wrote: > > Hi Stian, > > Thank you for your reply. > > > > The new tokens needs to be generated for each user, which is needed from > security point of view. The performance tests were also conducted using > single Admin user and token for admin user; however in that case the > performance was not good. In between 15th to 20th admin token access > requests ? the CPU usage of keycloak Java process was crossing 90 to 120% > mark. > > > > > > As you have mentioned, Creating tokes are expected to be a bit CPU > intensive ? what should be the server configuration in terms of CPU to deal > with more than 500 users to use keycloak as OAuth provider. > > > > > > Thanks, Vaibhav > > > > > > > > *From:* Stian Thorgersen [mailto:sthorger at redhat.com] > *Sent:* Thursday, May 19, 2016 6:28 PM > *To:* Vaibhav Naldurgkar > *Cc:* keycloak-user at lists.jboss.org > *Subject:* Re: [keycloak-user] Keycloak OAuth High CPU usage > > > > Creating tokes are expected to be a bit CPU intensive as they need to be > signed. When you say you try to generate tokens for 10-20 users are you > doing performance tests and having 10-20 threads generating tokens? It > shouldn't make any difference if you have 10 or if you have 200 users, it's > the total number of tokens that can be generated that's an issue. Having > 200 concurrent users with a access token timeout of 60 seconds should mean > that you need to be able to generate roughly 200/60 tokens = 3.3 tokens/sec. > > > > On 19 May 2016 at 13:24, Vaibhav Naldurgkar < > vaibhav_naldurgkar at persistent.com> wrote: > > Hi All, > > > > I am using Keycloak 1.9.3 with default configuration. Keycloak server is > installed on RHEL 6.5 virtual image with 4 CPU , 8 GB RAM and java version > is jdk1.8.0_73 We are trying to use keycloak as a OAuth provider. But when > we try and generate token( > http:///auth/realms/master/protocol/openid-connect/token > ) for more than > 10-20 users the server gets too slow and cpu usage goes over 100%. > > Any pointers on how to improve performance of keycloak OAuth provider. We > need to support at least 200 concurrent users. > > > > > > Thanks, Vaibhav > > DISCLAIMER ========== This e-mail may contain privileged and confidential > information which is the property of Persistent Systems Ltd. It is intended > only for the use of the individual or entity to which it is addressed. If > you are not the intended recipient, you are not authorized to read, retain, > copy, print, distribute or use this message. If you have received this > communication in error, please notify the sender and delete all copies of > this message. Persistent Systems Ltd. does not accept any liability for > virus infected mails. > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > DISCLAIMER ========== This e-mail may contain privileged and confidential > information which is the property of Persistent Systems Ltd. It is intended > only for the use of the individual or entity to which it is addressed. If > you are not the intended recipient, you are not authorized to read, retain, > copy, print, distribute or use this message. If you have received this > communication in error, please notify the sender and delete all copies of > this message. Persistent Systems Ltd. does not accept any liability for > virus infected mails. > > > > DISCLAIMER ========== This e-mail may contain privileged and confidential > information which is the property of Persistent Systems Ltd. It is intended > only for the use of the individual or entity to which it is addressed. If > you are not the intended recipient, you are not authorized to read, retain, > copy, print, distribute or use this message. If you have received this > communication in error, please notify the sender and delete all copies of > this message. Persistent Systems Ltd. does not accept any liability for > virus infected mails. > > > > DISCLAIMER ========== This e-mail may contain privileged and confidential > information which is the property of Persistent Systems Ltd. It is intended > only for the use of the individual or entity to which it is addressed. If > you are not the intended recipient, you are not authorized to read, retain, > copy, print, distribute or use this message. If you have received this > communication in error, please notify the sender and delete all copies of > this message. Persistent Systems Ltd. does not accept any liability for > virus infected mails. > > > > DISCLAIMER ========== This e-mail may contain privileged and confidential > information which is the property of Persistent Systems Ltd. It is intended > only for the use of the individual or entity to which it is addressed. If > you are not the intended recipient, you are not authorized to read, retain, > copy, print, distribute or use this message. If you have received this > communication in error, please notify the sender and delete all copies of > this message. Persistent Systems Ltd. does not accept any liability for > virus infected mails. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/890a3187/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 18447 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/890a3187/attachment-0003.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 11865 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/890a3187/attachment-0004.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 101405 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/890a3187/attachment-0005.png From sthorger at redhat.com Wed May 25 03:11:39 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 25 May 2016 09:11:39 +0200 Subject: [keycloak-user] Keycloak OAuth High CPU usage In-Reply-To: References: Message-ID: On 24 May 2016 at 14:21, Herzberg, Manuel wrote: > Hello, > > I am evaluating the Keycloak performance. Here my practical experience. My > scenario is the same as Vaibhav?s: > > > > ? Large amount of token have to be generated. This is done by > requesting the Keycloak token REST endpoint via http. The different realms > I am using have 1k 2k 3k and 4k keys for signing the tokens. (RSA) Longer > keys result to longer runtime to generate these tokens. > > > > ? I have more than 10k user each realm. Each request includes a > new user. > Requests look like this: > host1:8080/auth/realms/demo-3072/protocol/openid-connect/token/ > with data: > > username=testuser1&password=password&client_id=customer-portal&grant_type=password > > > > ? The response includes 3 tokens(access, refresh and id). In > total more than 30 000 token have to be generated and signed > > > @Stian. You wrote you are able to invoke 10000 token refreshes in under 60 > seconds. A token refresh includes access, refresh and id token right? Can > you explain us your scenario? How do you get such a high number? > > Some more results: just signing 3000 Token (800 Byte each) with a 2k key > takes me 20 seconds (laptop i5-4310U, 12gb ram). I am doing this outside > Keycloak with my own java program, but with the same implementation > Keycloak is using. (sign() method in RSAProvider). > Not much to tell. I did 10000 refresh token requests and it took less than 60 seconds. That's with 2k key sizes and an i7. > > The Keycloak implementation is signing tokens with RSA. HMAC and ECC are > implemented as well as I saw in the code. Changing from RSA to HMAC or ECC > is not possible in current release as i experienced. Are there plans to > provide this in future? Defining this in a configuration file or via > parameters would be nice. > > Best regards, Manuel Herzberg > > > > > > *From:* keycloak-user-bounces at lists.jboss.org [mailto: > keycloak-user-bounces at lists.jboss.org] *On Behalf Of *Stian Thorgersen > *Sent:* Tuesday, May 24, 2016 8:31 AM > > *To:* Vaibhav Naldurgkar > *Cc:* keycloak-user at lists.jboss.org > *Subject:* Re: [keycloak-user] Keycloak OAuth High CPU usage > > > > > > > > On 23 May 2016 at 10:02, Vaibhav Naldurgkar < > vaibhav_naldurgkar at persistent.com> wrote: > > Yes, the direct access grant is ON for this client. I am trying to > understand what you mean by ?not planning on using web based flow?? Could > you provide more clarification on this. > > > > If you are planning to do the web based flow (authorization code grant > flow) you should test with that rather than direct grant. That being said > the direct grant should still perform as well. > > > > > > This is what the scenario I am trying to execute and still have high CPU > usages for KeyCloak Java process. > > > > ? The end point URL > /auth/realms/master/protocol/openid-connect/token has been called by Jmeter > for 20 concurrent users per seconds to generate the tokens. > > ? Even if used with crul command like ?*curl -X POST -d > "=admin&password=admin&password&client_id=HelloTest&grant_type=password" > http://localhost:8080/auth/realms/master/protocol/openid-connect/token > *? > , in this case also the CPU utilizations goes around 100%. > > ? After around 3 seconds of the test, in the output of top > command on the KeyCloak server the CPU% for keycloak java process goes > beyond 100%. > > > > Would it be possible for you to have a quick call for faster fix of this > issue. This performance issue is holding to move KeyCloak to use as OAuth > provider. If any other way is convenient for you please let me know for > further discussion. > > > > Your JMeter test is using 20 concurrent threads to send as many requests > to the direct grant api as it can. This will obviously cause Keycloak to > consume a high percentage of the CPU. Especially if you are running > everything on localhost as the network isn't going to be a bottleneck. > Neither will the database as Keycloak caches everything in memory. The > bottleneck will be the CPU. > > > > Authenticating users and obtaining a token requires password hashing as > well as signing tokens, both are mainly CPU intensive. As you are using the > direct grant api there's also less network traffic. > > > > You need to add some reports to your JMeter test so you can see how many > requests Keycloak can handle. That way you can find out how many users can > be authenticated per-second on your machine. > > > > If you only have 500 users remember they won't all login at the same time > (seconds). Even if they all login at 9am sharp they will be spread out over > 10 minutes or so, which would only be 1.2 logins/second. > > > > > > Thanks, Vaibhav > > > > > > > > > > *From:* Stian Thorgersen [mailto:sthorger at redhat.com] > *Sent:* Monday, May 23, 2016 12:01 PM > > > *To:* Vaibhav Naldurgkar > *Cc:* keycloak-user at lists.jboss.org > *Subject:* Re: [keycloak-user] Keycloak OAuth High CPU usage > > > > You are using direct grant to authenticate a user and obtain a token in > the example above. This authenticates and creates a new session for each > request. Are you not planning on using web based flow? > > > > What do you have password hashing intervals set to? Verifying password is > CPU intensive, more than signing tokens. > > > > It shouldn't matter that user is stored in RedHat IdM as the user would be > cached in Keycloak after first authentication, but it may be an idea to > just double check by trying to authenticate to a user in Keycloak and not > RH IdM. > > > > What results are you actually getting? > > > > > > > > On 20 May 2016 at 11:27, Vaibhav Naldurgkar < > vaibhav_naldurgkar at persistent.com> wrote: > > Hi Stian, > > > > After reading your tests results of 10000 token refreshes in under 60 > seconds on your laptop, I am sure I am not following correct configuration > and the documents are missing for reference. > > > > Could you please verify the below steps along with the screen-shots for > the steps which I am following for the adding client and testing the Load > performance using Jmeter. Please suggest if any changes are needed in the > client configuration. In this case we are obtaining the token for user from > KeyCloak. > > > > In my case the user have been stored on RedHat IdM which has been > federated using KeyCloak. > > > > > > Step 1. Create new client called ?LoadTest? , use the Client Protocol as > ?Openid-connect?. > > Used all defaults values post save of the client action. > > > > Step 2. Start the load tests using Jmeter and using the path as > *?/auth/realms/master/protocol/openid-connect/token?* . Used 20 Number of > Threads and used Post method. > > > > > > Below is the screen-shot for the step 1 related to Add Client. > > > > > > > > > > Below is the screen shot for the load test using Jmeter. In this case the > Client ID was used as HelloTest. > > > > > > > > Http requests. > > > > > > > > Thanks, Vaibhav > > > > > > *From:* Stian Thorgersen [mailto:sthorger at redhat.com] > *Sent:* Friday, May 20, 2016 1:01 PM > > > *To:* Vaibhav Naldurgkar > *Cc:* keycloak-user at lists.jboss.org > *Subject:* Re: [keycloak-user] Keycloak OAuth High CPU usage > > > > Can you please elaborate a bit more on how your are testing scenario is? > I'm a bit confused to what you are testing when you are talking about > generating new tokens. Are you using OIDC or SAML? Are you talking about > code->token exchanges, refresh token requests, or what? > > > > To test if your hardware is capable to deal with the load you need to test > logins (verifying passwords are CPU intensive) as well as obtaining tokens > (both code->token, done after login, and refreshing token, done ~1 min or > so by active users, but most users won't continuously use the application). > > > > 500 users should be no problem at all. As an example with a single thread > (which will use a single core) I could invoke 10000 token refreshes in > under 60 seconds on my laptop. So a single core on my laptop should be able > to handle 500 users. > > > > On 20 May 2016 at 08:00, Vaibhav Naldurgkar < > vaibhav_naldurgkar at persistent.com> wrote: > > Hi Stian, > > Thank you for your reply. > > > > The new tokens needs to be generated for each user, which is needed from > security point of view. The performance tests were also conducted using > single Admin user and token for admin user; however in that case the > performance was not good. In between 15th to 20th admin token access > requests ? the CPU usage of keycloak Java process was crossing 90 to 120% > mark. > > > > > > As you have mentioned, Creating tokes are expected to be a bit CPU > intensive ? what should be the server configuration in terms of CPU to deal > with more than 500 users to use keycloak as OAuth provider. > > > > > > Thanks, Vaibhav > > > > > > > > *From:* Stian Thorgersen [mailto:sthorger at redhat.com] > *Sent:* Thursday, May 19, 2016 6:28 PM > *To:* Vaibhav Naldurgkar > *Cc:* keycloak-user at lists.jboss.org > *Subject:* Re: [keycloak-user] Keycloak OAuth High CPU usage > > > > Creating tokes are expected to be a bit CPU intensive as they need to be > signed. When you say you try to generate tokens for 10-20 users are you > doing performance tests and having 10-20 threads generating tokens? It > shouldn't make any difference if you have 10 or if you have 200 users, it's > the total number of tokens that can be generated that's an issue. Having > 200 concurrent users with a access token timeout of 60 seconds should mean > that you need to be able to generate roughly 200/60 tokens = 3.3 tokens/sec. > > > > On 19 May 2016 at 13:24, Vaibhav Naldurgkar < > vaibhav_naldurgkar at persistent.com> wrote: > > Hi All, > > > > I am using Keycloak 1.9.3 with default configuration. Keycloak server is > installed on RHEL 6.5 virtual image with 4 CPU , 8 GB RAM and java version > is jdk1.8.0_73 We are trying to use keycloak as a OAuth provider. But when > we try and generate token( > http:///auth/realms/master/protocol/openid-connect/token > ) for more than > 10-20 users the server gets too slow and cpu usage goes over 100%. > > Any pointers on how to improve performance of keycloak OAuth provider. We > need to support at least 200 concurrent users. > > > > > > Thanks, Vaibhav > > DISCLAIMER ========== This e-mail may contain privileged and confidential > information which is the property of Persistent Systems Ltd. It is intended > only for the use of the individual or entity to which it is addressed. If > you are not the intended recipient, you are not authorized to read, retain, > copy, print, distribute or use this message. If you have received this > communication in error, please notify the sender and delete all copies of > this message. Persistent Systems Ltd. does not accept any liability for > virus infected mails. > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > DISCLAIMER ========== This e-mail may contain privileged and confidential > information which is the property of Persistent Systems Ltd. It is intended > only for the use of the individual or entity to which it is addressed. If > you are not the intended recipient, you are not authorized to read, retain, > copy, print, distribute or use this message. If you have received this > communication in error, please notify the sender and delete all copies of > this message. Persistent Systems Ltd. does not accept any liability for > virus infected mails. > > > > DISCLAIMER ========== This e-mail may contain privileged and confidential > information which is the property of Persistent Systems Ltd. It is intended > only for the use of the individual or entity to which it is addressed. If > you are not the intended recipient, you are not authorized to read, retain, > copy, print, distribute or use this message. If you have received this > communication in error, please notify the sender and delete all copies of > this message. Persistent Systems Ltd. does not accept any liability for > virus infected mails. > > > > DISCLAIMER ========== This e-mail may contain privileged and confidential > information which is the property of Persistent Systems Ltd. It is intended > only for the use of the individual or entity to which it is addressed. If > you are not the intended recipient, you are not authorized to read, retain, > copy, print, distribute or use this message. If you have received this > communication in error, please notify the sender and delete all copies of > this message. Persistent Systems Ltd. does not accept any liability for > virus infected mails. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/f97abcb7/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 101405 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/f97abcb7/attachment-0003.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 18447 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/f97abcb7/attachment-0004.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 11865 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/f97abcb7/attachment-0005.png From akaya at expedia.com Wed May 25 03:23:01 2016 From: akaya at expedia.com (Sarp Kaya) Date: Wed, 25 May 2016 07:23:01 +0000 Subject: [keycloak-user] SysoutEventListenerProvider example is not working Message-ID: Hello, I have followed the instructions in the provided example (from keycloak-examples-1.9.4.Final.zip). The steps I have done are: 1. ran mvn clean install 2. Copied event-listener-sysout-example.jar file from target to providers directory in keycloak 3. Registered provider in keycloak-server.json 4. Restarted the standalone server I am getting the error below now: 07:12:51,542 INFO [org.keycloak.services] (ServerService Thread Pool -- 55) KC-SERVICES0001: Loading config from /opt/jboss/keycloak/standalone/configuration/keycloak-server.json 07:12:51,946 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 55) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./auth: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./auth: java.lang.RuntimeException: RESTEASY003325: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) at org.jboss.threads.JBossThread.run(JBossThread.java:320) Caused by: java.lang.RuntimeException: RESTEASY003325: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:162) at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209) at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299) at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240) at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231) at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132) at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) ... 6 more Caused by: java.lang.RuntimeException: org.jboss.modules.ModuleNotFoundException: org.keycloak.examples.event-sysout:main at org.keycloak.provider.wildfly.ModuleProviderLoaderFactory.create(ModuleProviderLoaderFactory.java:44) at org.keycloak.provider.ProviderManager.(ProviderManager.java:56) at org.keycloak.services.DefaultKeycloakSessionFactory.init(DefaultKeycloakSessionFactory.java:71) at org.keycloak.services.resources.KeycloakApplication.createSessionFactory(KeycloakApplication.java:225) at org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:77) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150) ... 19 more Caused by: org.jboss.modules.ModuleNotFoundException: org.keycloak.examples.event-sysout:main at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:223) at org.keycloak.provider.wildfly.ModuleProviderLoaderFactory.create(ModuleProviderLoaderFactory.java:40) ... 28 more 07:12:51,976 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "keycloak-server.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./auth" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./auth: java.lang.RuntimeException: RESTEASY003325: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) Caused by: java.lang.RuntimeException: RESTEASY003325: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) Caused by: java.lang.RuntimeException: org.jboss.modules.ModuleNotFoundException: org.keycloak.examples.event-sysout:main Caused by: org.jboss.modules.ModuleNotFoundException: org.keycloak.examples.event-sysout:main"}} Am I missing an unknown step? The readme file only mentions copying the jar file to providers. If not what could be wrong? Kind Regards, Sarp Kaya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/89b02156/attachment.html From sthorger at redhat.com Wed May 25 03:45:14 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 25 May 2016 09:45:14 +0200 Subject: [keycloak-user] SysoutEventListenerProvider example is not working In-Reply-To: References: Message-ID: Looks like you've mixed the instructions. If you copy the jar to providers directory you don't need to register the module, that's only when you're deploying as a module. On 25 May 2016 at 09:23, Sarp Kaya wrote: > Hello, > > I have followed the instructions in the provided example (from > keycloak-examples-1.9.4.Final.zip). The steps I have done are: > > > 1. ran mvn clean install > 2. Copied event-listener-sysout-example.jar file from target to > providers directory in keycloak > 3. Registered provider in keycloak-server.json > 4. Restarted the standalone server > > I am getting the error below now: > > 07:12:51,542 INFO [org.keycloak.services] (ServerService Thread Pool -- > 55) KC-SERVICES0001: Loading config from > /opt/jboss/keycloak/standalone/configuration/keycloak-server.json > 07:12:51,946 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool > -- 55) MSC000001: Failed to start service > jboss.undertow.deployment.default-server.default-host./auth: > org.jboss.msc.service.StartException in service > jboss.undertow.deployment.default-server.default-host./auth: > java.lang.RuntimeException: RESTEASY003325: Failed to construct public > org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > Caused by: java.lang.RuntimeException: RESTEASY003325: Failed to construct > public > org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) > at > org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:162) > at > org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2209) > at > org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:299) > at > org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:240) > at > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:113) > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) > at > io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) > at > org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78) > at > io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) > at > io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:231) > at > io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:132) > at > io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:526) > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:101) > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) > ... 6 more > Caused by: java.lang.RuntimeException: > org.jboss.modules.ModuleNotFoundException: > org.keycloak.examples.event-sysout:main > at > org.keycloak.provider.wildfly.ModuleProviderLoaderFactory.create(ModuleProviderLoaderFactory.java:44) > at > org.keycloak.provider.ProviderManager.(ProviderManager.java:56) > at > org.keycloak.services.DefaultKeycloakSessionFactory.init(DefaultKeycloakSessionFactory.java:71) > at > org.keycloak.services.resources.KeycloakApplication.createSessionFactory(KeycloakApplication.java:225) > at > org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:77) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:423) > at > org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:150) > ... 19 more > Caused by: org.jboss.modules.ModuleNotFoundException: > org.keycloak.examples.event-sysout:main > at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:223) > at > org.keycloak.provider.wildfly.ModuleProviderLoaderFactory.create(ModuleProviderLoaderFactory.java:40) > ... 28 more > > 07:12:51,976 ERROR [org.jboss.as.controller.management-operation] > (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: > ([("deployment" => "keycloak-server.war")]) - failure description: > {"WFLYCTL0080: Failed services" => > {"jboss.undertow.deployment.default-server.default-host./auth" => > "org.jboss.msc.service.StartException in service > jboss.undertow.deployment.default-server.default-host./auth: > java.lang.RuntimeException: RESTEASY003325: Failed to construct public > org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) > Caused by: java.lang.RuntimeException: RESTEASY003325: Failed to > construct public > org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) > Caused by: java.lang.RuntimeException: > org.jboss.modules.ModuleNotFoundException: > org.keycloak.examples.event-sysout:main > Caused by: org.jboss.modules.ModuleNotFoundException: > org.keycloak.examples.event-sysout:main"}} > > > > Am I missing an unknown step? The readme file only mentions copying the > jar file to providers. If not what could be wrong? > > Kind Regards, > Sarp Kaya > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/7b09b686/attachment-0001.html From jayapriya.atheesan at gmail.com Wed May 25 04:02:55 2016 From: jayapriya.atheesan at gmail.com (JAYAPRIYA ATHEESAN) Date: Wed, 25 May 2016 13:32:55 +0530 Subject: [keycloak-user] Resetting password In-Reply-To: References: <5742a5d9.0cb9420a.b96f6.6132@mx.google.com> Message-ID: <57455c4e.445f620a.19e7.44a4@mx.google.com> OK.. Thanks a lot.. Thanks, Jayapriya Atheesan From: Stian Thorgersen [mailto:sthorger at redhat.com] Sent: Wednesday, May 25, 2016 12:00 PM To: Thomas Raehalme Cc: Jayapriya Atheesan; keycloak-user Subject: Re: [keycloak-user] Resetting password Yep, the result to the user is the same regardless if a user with the email exist. Same with the login screen it display invalid username or password, not just invalid username. On 24 May 2016 at 14:36, Thomas Raehalme wrote: Hi! For security reasons I don't think Keycloak should reveal whether or not the account exists. Instead the message shown to the user in response should be something like "If the email address was found, you should soon receive further instructions." Best regards, Thomas On Tue, May 24, 2016 at 3:02 PM, Jayapriya Atheesan wrote: Hi All, Any help would be appreciated. Thanks, Jayapriya Atheesan On Mon, May 23, 2016 at 12:10 PM, JAYAPRIYA ATHEESAN wrote: Hi, When a user clicks on reset password/forget password and enters an email id which is not registered with keycloak, it does not show any error. Is there any option to give an error message to the user saying ?email id doesn?t exist?. Note : We are using keycloak 1.6.0Final. Thanks, Jayapriya Atheesan -- Regards, Jayapriya Atheesan _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/e4344590/attachment.html From nielsbne at gmail.com Wed May 25 04:26:17 2016 From: nielsbne at gmail.com (Niels Bertram) Date: Wed, 25 May 2016 18:26:17 +1000 Subject: [keycloak-user] Keycloak token exchange failure behind loadbalancer and reverse proxy In-Reply-To: References: Message-ID: Interesting point Stian. This header seems to be originating from Chrome browser. I am not quite sure why its added but I also run lastpass chrome plugin which may be too smart for its own good. I also just tried the keycloak master realm login on Internet Explorer and Firefox which both work as expected and the http request dumps on the keycloak server show that these 2 browsers do not add the Basic Auth header. I looked at the below specs and I can see that keycloak assumes the Basic Auth header contains the client credentials which it is then trying to validate. http://openid.net/specs/openid-connect-core-1_0.html#TokenRequest https://tools.ietf.org/html/rfc6749#section-2.3.1 https://tools.ietf.org/html/rfc6749#section-4.1.3 Just wondering if keycloak should ignore the Basic Auth header if the client is configured to be public ?? Afterall client_id should be in the post form and sending a password from a user browser would be insecure in any case. Thanks, Niels On Wed, May 25, 2016 at 4:39 PM, Stian Thorgersen wrote: > The message means it's unable to authenticate the client for the code to > token exchange. > > Looking at the request it's a strange one as it looks like you've tried to > login to the admin console then the code to token request for some reason > includes "Authorization=Basic YWRtaW46Y2hhbmdlbWU=" which is credentials > for a user 'admin' with password 'changeme'. Is this being added by your > proxy or something? > > > On 24 May 2016 at 14:41, Niels Bertram wrote: > >> Yes I can confirm the filter is correctly added. I also have all the >> other required settings configured (hopefully correctly). It works reliably >> when I target the apache reverse proxy but only falls appart when I load >> balance through another "hop". I switched on debug on keycloak and can see >> a bit more details of the failure (logs below). I wonder what >> "AuthenticationFlowException: Client was not identified by any client >> authenticator" means. >> >> >> >> > redirect-socket="proxy-https" enabled="true" /> >> > proxy-address-forwarding="true" redirect-socket="proxy-https" /> >> >> >> >> >> >> >> >> >> >> > header-value="WildFly/10"/> >> > header-value="Undertow/1"/> >> > class-name="io.undertow.server.handlers.ProxyPeerAddressHandler" >> module="io.undertow.core" /> >> >> >> >> > port-offset="${jboss.socket.binding.port-offset:0}"> >> ... >> >> >> >> >> ... >> >> >> >> >> 2016-05-24 09:59:26,176 DEBUG [org.keycloak.services] (default task-11) >> AUTHENTICATE CLIENT >> 2016-05-24 09:59:26,176 DEBUG [org.keycloak.services] (default task-11) >> client authenticator: client-secret >> 2016-05-24 09:59:26,179 DEBUG [org.keycloak.services] (default task-11) >> client authenticator: client-jwt >> 2016-05-24 09:59:26,180 DEBUG [org.keycloak.services] (default task-11) >> KC-SERVICES0014: Failed client authentication: >> org.keycloak.authentication.AuthenticationFlowException: Client was not >> identified by any client authenticator >> at >> org.keycloak.authentication.ClientAuthenticationFlow.processFlow(ClientAuthenticationFlow.java:101) >> at >> org.keycloak.authentication.AuthenticationProcessor.authenticateClient(AuthenticationProcessor.java:673) >> at >> org.keycloak.protocol.oidc.utils.AuthorizeClientUtil.authorizeClient(AuthorizeClientUtil.java:42) >> at >> org.keycloak.protocol.oidc.endpoints.TokenEndpoint.checkClient(TokenEndpoint.java:163) >> at >> org.keycloak.protocol.oidc.endpoints.TokenEndpoint.build(TokenEndpoint.java:117) >> at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:498) >> at >> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) >> at >> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) >> at >> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) >> at >> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) >> at >> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107) >> at >> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133) >> at >> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) >> at >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) >> at >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) >> at >> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) >> at >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) >> at >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >> at >> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) >> at >> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) >> at >> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:88) >> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) >> at >> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) >> at >> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) >> at >> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) >> at >> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) >> at >> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at >> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) >> at >> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at >> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) >> at >> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) >> at >> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) >> at >> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) >> at >> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) >> at >> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at >> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at >> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) >> at >> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) >> at >> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) >> at >> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) >> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) >> at >> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:745) >> >> 2016-05-24 09:59:26,180 WARN [org.keycloak.events] (default task-11) >> type=CODE_TO_TOKEN_ERROR, realmId=master, clientId=admin, userId=null, >> ipAddress=192.168.33.1, error=invalid_client_credentials, >> grant_type=authorization_code >> 2016-05-24 09:59:26,863 DEBUG [org.keycloak.services] (default task-8) >> replacing relative valid redirect with: >> https://login.vagrant.v8/auth/admin/master/console/* >> 2016-05-24 09:59:26,867 DEBUG [org.keycloak.services] (default task-8) >> AUTHENTICATE >> 2016-05-24 09:59:26,867 DEBUG [org.keycloak.services] (default task-8) >> AUTHENTICATE ONLY >> 2016-05-24 09:59:26,867 DEBUG [org.keycloak.services] (default task-8) >> processFlow >> 2016-05-24 09:59:26,868 DEBUG [org.keycloak.services] (default task-8) >> check execution: auth-cookie requirement: ALTERNATIVE >> 2016-05-24 09:59:26,868 DEBUG [org.keycloak.services] (default task-8) >> authenticator: auth-cookie >> 2016-05-24 09:59:26,868 DEBUG [org.keycloak.services] (default task-8) >> invoke authenticator.authenticate >> 2016-05-24 09:59:26,869 DEBUG [org.keycloak.services] (default task-8) >> token active - active: true, issued-at: 1,464,083,965, not-before: 0 >> 2016-05-24 09:59:26,869 DEBUG [org.keycloak.services] (default task-8) >> authenticator SUCCESS: auth-cookie >> 2016-05-24 09:59:26,873 DEBUG [org.keycloak.services] (default task-8) >> check execution: auth-spnego requirement: DISABLED >> 2016-05-24 09:59:26,873 DEBUG [org.keycloak.services] (default task-8) >> execution is processed >> 2016-05-24 09:59:26,873 DEBUG [org.keycloak.services] (default task-8) >> check execution: null requirement: ALTERNATIVE >> 2016-05-24 09:59:26,873 DEBUG [org.keycloak.services] (default task-8) >> Skip alternative execution >> 2016-05-24 09:59:26,874 DEBUG [org.keycloak.events] (default task-8) >> type=LOGIN, realmId=master, clientId=security-admin-console, >> userId=cf248811-6d82-47e7-bf9a-7b197fb988d0, ipAddress=192.168.33.1, >> auth_method=openid-connect, auth_type=code, response_type=code, >> redirect_uri=https://login.vagrant.v8/auth/admin/master/console/, >> consent=no_consent_required, code_id=8215bbb3-a592-47e0-9c28-c274bccc61b5, >> response_mode=fragment, username=admin >> 2016-05-24 09:59:26,891 DEBUG [org.keycloak.services] (default task-8) >> Create login cookie - name: KEYCLOAK_IDENTITY, path: /auth/realms/master, >> max-age: -1 >> 2016-05-24 09:59:26,892 DEBUG [org.keycloak.services] (default task-8) >> redirectAccessCode: state: ae0d05d7-95d9-40a0-9a75-7e4e4fb7830e >> 2016-05-24 09:59:27,472 DEBUG [org.keycloak.services] (default task-11) >> AUTHENTICATE CLIENT >> 2016-05-24 09:59:27,472 DEBUG [org.keycloak.services] (default task-11) >> client authenticator: client-secret >> 2016-05-24 09:59:27,474 DEBUG [org.keycloak.services] (default task-11) >> client authenticator: client-jwt >> 2016-05-24 09:59:27,474 DEBUG [org.keycloak.services] (default task-11) >> KC-SERVICES0014: Failed client authentication: >> org.keycloak.authentication.AuthenticationFlowException: Client was not >> identified by any client authenticator >> at >> org.keycloak.authentication.ClientAuthenticationFlow.processFlow(ClientAuthenticationFlow.java:101) >> at >> org.keycloak.authentication.AuthenticationProcessor.authenticateClient(AuthenticationProcessor.java:673) >> at >> org.keycloak.protocol.oidc.utils.AuthorizeClientUtil.authorizeClient(AuthorizeClientUtil.java:42) >> at >> org.keycloak.protocol.oidc.endpoints.TokenEndpoint.checkClient(TokenEndpoint.java:163) >> at >> org.keycloak.protocol.oidc.endpoints.TokenEndpoint.build(TokenEndpoint.java:117) >> at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:498) >> at >> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) >> at >> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) >> at >> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) >> at >> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) >> at >> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107) >> at >> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133) >> at >> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) >> at >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) >> at >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) >> at >> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) >> at >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) >> at >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >> at >> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) >> at >> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) >> at >> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:88) >> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) >> at >> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) >> at >> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) >> at >> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) >> at >> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) >> at >> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at >> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) >> at >> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at >> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) >> at >> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) >> at >> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) >> at >> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) >> at >> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) >> at >> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at >> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at >> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) >> at >> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) >> at >> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) >> at >> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) >> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) >> at >> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:745) >> >> 2016-05-24 09:59:27,478 WARN [org.keycloak.events] (default task-11) >> type=CODE_TO_TOKEN_ERROR, realmId=master, clientId=admin, userId=null, >> ipAddress=192.168.33.1, error=invalid_client_credentials, >> grant_type=authorization_code >> 2016-05-24 09:59:28,209 DEBUG [org.keycloak.services] (default task-8) >> replacing relative valid redirect with: >> https://login.vagrant.v8/auth/admin/master/console/* >> 2016-05-24 09:59:28,211 DEBUG [org.keycloak.services] (default task-8) >> AUTHENTICATE >> 2016-05-24 09:59:28,218 DEBUG [org.keycloak.services] (default task-8) >> AUTHENTICATE ONLY >> 2016-05-24 09:59:28,218 DEBUG [org.keycloak.services] (default task-8) >> processFlow >> 2016-05-24 09:59:28,219 DEBUG [org.keycloak.services] (default task-8) >> check execution: auth-cookie requirement: ALTERNATIVE >> 2016-05-24 09:59:28,219 DEBUG [org.keycloak.services] (default task-8) >> authenticator: auth-cookie >> 2016-05-24 09:59:28,219 DEBUG [org.keycloak.services] (default task-8) >> invoke authenticator.authenticate >> 2016-05-24 09:59:28,220 DEBUG [org.keycloak.services] (default task-8) >> token active - active: true, issued-at: 1,464,083,966, not-before: 0 >> 2016-05-24 09:59:28,222 DEBUG [org.keycloak.services] (default task-8) >> authenticator SUCCESS: auth-cookie >> 2016-05-24 09:59:28,222 DEBUG [org.keycloak.services] (default task-8) >> check execution: auth-spnego requirement: DISABLED >> 2016-05-24 09:59:28,222 DEBUG [org.keycloak.services] (default task-8) >> execution is processed >> 2016-05-24 09:59:28,222 DEBUG [org.keycloak.services] (default task-8) >> check execution: null requirement: ALTERNATIVE >> 2016-05-24 09:59:28,222 DEBUG [org.keycloak.services] (default task-8) >> Skip alternative execution >> 2016-05-24 09:59:28,223 DEBUG [org.keycloak.events] (default task-8) >> type=LOGIN, realmId=master, clientId=security-admin-console, >> userId=cf248811-6d82-47e7-bf9a-7b197fb988d0, ipAddress=192.168.33.1, >> auth_method=openid-connect, auth_type=code, response_type=code, >> redirect_uri=https://login.vagrant.v8/auth/admin/master/console/, >> consent=no_consent_required, code_id=7f9dbb5c-651a-4cc4-a248-91637c354fa5, >> response_mode=fragment, username=admin >> 2016-05-24 09:59:28,255 DEBUG [org.keycloak.services] (default task-8) >> Create login cookie - name: KEYCLOAK_IDENTITY, path: /auth/realms/master, >> max-age: -1 >> 2016-05-24 09:59:28,256 DEBUG [org.keycloak.services] (default task-8) >> redirectAccessCode: state: 89b303fd-f77e-4b23-8de0-2c517304e671 >> 2016-05-24 09:59:28,612 DEBUG [org.keycloak.services] (default task-11) >> AUTHENTICATE CLIENT >> 2016-05-24 09:59:28,612 DEBUG [org.keycloak.services] (default task-11) >> client authenticator: client-secret >> 2016-05-24 09:59:28,613 DEBUG [org.keycloak.services] (default task-11) >> client authenticator: client-jwt >> 2016-05-24 09:59:28,614 DEBUG [org.keycloak.services] (default task-11) >> KC-SERVICES0014: Failed client authentication: >> org.keycloak.authentication.AuthenticationFlowException: Client was not >> identified by any client authenticator >> at >> org.keycloak.authentication.ClientAuthenticationFlow.processFlow(ClientAuthenticationFlow.java:101) >> at >> org.keycloak.authentication.AuthenticationProcessor.authenticateClient(AuthenticationProcessor.java:673) >> at >> org.keycloak.protocol.oidc.utils.AuthorizeClientUtil.authorizeClient(AuthorizeClientUtil.java:42) >> at >> org.keycloak.protocol.oidc.endpoints.TokenEndpoint.checkClient(TokenEndpoint.java:163) >> at >> org.keycloak.protocol.oidc.endpoints.TokenEndpoint.build(TokenEndpoint.java:117) >> at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:498) >> at >> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) >> at >> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) >> at >> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) >> at >> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) >> at >> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107) >> at >> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133) >> at >> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) >> at >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) >> at >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) >> at >> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) >> at >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) >> at >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >> at >> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) >> at >> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) >> at >> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:88) >> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) >> at >> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) >> at >> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) >> at >> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) >> at >> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) >> at >> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at >> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) >> at >> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at >> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) >> at >> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) >> at >> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) >> at >> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) >> at >> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) >> at >> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at >> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at >> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) >> at >> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) >> at >> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) >> at >> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) >> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) >> at >> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:745) >> >> 2016-05-24 09:59:28,614 WARN [org.keycloak.events] (default task-11) >> type=CODE_TO_TOKEN_ERROR, realmId=master, clientId=admin, userId=null, >> ipAddress=192.168.33.1, error=invalid_client_credentials, >> grant_type=authorization_code >> 2016-05-24 09:59:28,692 INFO [io.undertow.request.dump] (default >> task-11) >> ----------------------------REQUEST--------------------------- >> URI=/auth/realms/master/protocol/openid-connect/token >> characterEncoding=null >> contentLength=229 >> contentType=[application/x-www-form-urlencoded] >> >> cookie=KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjdmOWRiYjVjLTY1MWEtNGNjNC1hMjQ4LTkxNjM3YzM1NGZhNSIsImNpZCI6InNlY3VyaXR5LWFkbWluLWNvbnNvbGUiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9hZG1pbi9tYXN0ZXIvY29uc29sZS8iLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiYjg3OTM2Y2ItZTg1OC00NDhlLWJmMTAtNGNkYjQzMDFkMTg2IiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL3JlYWxtcy9tYXN0ZXIiLCJyZXNwb25zZV90eXBlIjoiY29kZSIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL2FkbWluL21hc3Rlci9jb25zb2xlLyIsInN0YXRlIjoiODliMzAzZmQtZjc3ZS00YjIzLThkZTAtMmM1MTczMDRlNjcxIiwibm9uY2UiOiI1MzY0YTRhZS0wNzI3LTQwYWItOWEyMi0yN2ExZDQ5NjVmNTkiLCJyZXNwb25zZV9tb2RlIjoiZnJhZ21lbnQifX0.7Xnk589FgD_9RulKC4V48gn-056yVxa_DdIGm4Hpgj8 >> >> cookie=KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI5ZjRmNWU3OS02NWYxLTQ0M2ItOGI5YS1hZWI4NzZmYmNkNjIiLCJleHAiOjE0NjQxMTk5NjgsIm5iZiI6MCwiaWF0IjoxNDY0MDgzOTY4LCJpc3MiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9yZWFsbXMvbWFzdGVyIiwic3ViIjoiY2YyNDg4MTEtNmQ4Mi00N2U3LWJmOWEtN2IxOTdmYjk4OGQwIiwic2Vzc2lvbl9zdGF0ZSI6ImQzYjAxY2Q1LWQxNWEtNGQ2OS05MTQ3LWE1YTEzYWI4MjQxNiIsInJlc291cmNlX2FjY2VzcyI6e319.eiDWSR8eeIdX7AKZiWI3e9moUD9ZuD-h88XX31JRMio_FmqSvMgRHcZtkVjjrLnjcmWn7X4jIcITARk-TiywjfAKotkPYodgCyxsmln5LRQeV3SYXltCGWKmsFmq0BsMjQbfstjdR9V9Xh7daiyRNxLGcoYitEEOeKboMjbGwZw11jggaTRifpNYp-M9GtTBvHSJg6RFdmm0QTLeJm9OgOvBzdRlKwGTUcJeqJxuNWgd4XqPS5vbpliDsfuvekC8VFeDB_UGci1hCIEoMy0-tlpwPLP_xGbCd5L8XFKrr0shoGbQlyJjFZB49VtJlHLkd8F15mZQxJ1G9BWj_wKINw >> >> cookie=KEYCLOAK_SESSION=master/cf248811-6d82-47e7-bf9a-7b197fb988d0/d3b01cd5-d15a-4d69-9147-a5a13ab82416 >> header=X-Real-Ip=192.168.33.1 >> header=Accept-Encoding=gzip, deflate >> header=DNT=1 >> header=Origin=https://login.vagrant.v8 >> header=X-Forwarded-Port=443 >> header=X-Forwarded-For=192.168.33.1 >> >> header=Cookie=KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjdmOWRiYjVjLTY1MWEtNGNjNC1hMjQ4LTkxNjM3YzM1NGZhNSIsImNpZCI6InNlY3VyaXR5LWFkbWluLWNvbnNvbGUiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9hZG1pbi9tYXN0ZXIvY29uc29sZS8iLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiYjg3OTM2Y2ItZTg1OC00NDhlLWJmMTAtNGNkYjQzMDFkMTg2IiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL3JlYWxtcy9tYXN0ZXIiLCJyZXNwb25zZV90eXBlIjoiY29kZSIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL2FkbWluL21hc3Rlci9jb25zb2xlLyIsInN0YXRlIjoiODliMzAzZmQtZjc3ZS00YjIzLThkZTAtMmM1MTczMDRlNjcxIiwibm9uY2UiOiI1MzY0YTRhZS0wNzI3LTQwYWItOWEyMi0yN2ExZDQ5NjVmNTkiLCJyZXNwb25zZV9tb2RlIjoiZnJhZ21lbnQifX0.7Xnk589FgD_9RulKC4V48gn-056yVxa_DdIGm4Hpgj8; >> KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI5ZjRmNWU3OS02NWYxLTQ0M2ItOGI5YS1hZWI4NzZmYmNkNjIiLCJleHAiOjE0NjQxMTk5NjgsIm5iZiI6MCwiaWF0IjoxNDY0MDgzOTY4LCJpc3MiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9yZWFsbXMvbWFzdGVyIiwic3ViIjoiY2YyNDg4MTEtNmQ4Mi00N2U3LWJmOWEtN2IxOTdmYjk4OGQwIiwic2Vzc2lvbl9zdGF0ZSI6ImQzYjAxY2Q1LWQxNWEtNGQ2OS05MTQ3LWE1YTEzYWI4MjQxNiIsInJlc291cmNlX2FjY2VzcyI6e319.eiDWSR8eeIdX7AKZiWI3e9moUD9ZuD-h88XX31JRMio_FmqSvMgRHcZtkVjjrLnjcmWn7X4jIcITARk-TiywjfAKotkPYodgCyxsmln5LRQeV3SYXltCGWKmsFmq0BsMjQbfstjdR9V9Xh7daiyRNxLGcoYitEEOeKboMjbGwZw11jggaTRifpNYp-M9GtTBvHSJg6RFdmm0QTLeJm9OgOvBzdRlKwGTUcJeqJxuNWgd4XqPS5vbpliDsfuvekC8VFeDB_UGci1hCIEoMy0-tlpwPLP_xGbCd5L8XFKrr0shoGbQlyJjFZB49VtJlHLkd8F15mZQxJ1G9BWj_wKINw; >> KEYCLOAK_SESSION=master/cf248811-6d82-47e7-bf9a-7b197fb988d0/d3b01cd5-d15a-4d69-9147-a5a13ab82416 >> header=Referer= >> https://login.vagrant.v8/auth/admin/master/console/ >> header=Host=login.vagrant.v8 >> header=Accept=*/* >> header=Accept-Language=en-US,en;q=0.8,de;q=0.6 >> header=X-Original-To=192.168.33.80 >> header=User-Agent=Mozilla/5.0 (Windows NT 6.1; WOW64) >> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 >> header=Authorization=Basic YWRtaW46Y2hhbmdlbWU= >> header=X-Forwarded-Proto=https >> header=Content-Length=229 >> header=Content-Type=application/x-www-form-urlencoded >> locale=[en_US, en, de] >> method=POST >> protocol=HTTP/1.1 >> queryString= >> remoteAddr=/192.168.33.80:55892 >> remoteHost=proxy.vagrant.v8 >> scheme=https >> host=login.vagrant.v8 >> serverPort=443 >> --------------------------RESPONSE-------------------------- >> contentLength=123 >> contentType=application/json >> header=X-Powered-By=Undertow/1 >> header=Server=WildFly/10 >> header=Content-Type=application/json >> header=Content-Length=123 >> header=Date=Tue, 24 May 2016 09:59:28 GMT >> status=400 >> >> >> On Tue, May 24, 2016 at 9:49 PM, Stian Thorgersen >> wrote: >> >>> Did you add ProxyPeerAddressHandler filter? That's required for AJP >>> connector, see >>> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#proxy-address-forwarding >>> >>> On 24 May 2016 at 11:48, Niels Bertram wrote: >>> >>>> I am scratching my head with a specific setup problem which does not >>>> generate any usable error messages. >>>> >>>> I am running a haproxy as load balancer in a vm in front an apache web >>>> server configured as reverse proxy connecting to the keycloak server via >>>> ajp in another VM. >>>> >>>> client browser (192.168.33.1) >>>> >>>> login.vagrant.v8 (192.168.33.80) aka proxy.vagrant.v8 is haproxy >>>> adds X-Forwarded-For X-Forwarded-Port X-Forwarded-Proto and X-Real-Ip >>>> >>>> kc01.vagrant.v8 (192.168.33.81) apache reverse proxies >>>> to wildfly on ajp port >>>> >>>> >>>> Followed all the setup instructions in the documentation and if I >>>> connect to apache proxying through to keycloak everything works fine. All >>>> web resources are donwloaded fine however when I request a token exchange >>>> on /auth/realms/master/protocol/openid-connect/token I get a 400 >>>> response. The kc server log shows the corect IP address of the originating >>>> client and the request dump from wildfly also shows the correct >>>> X-Forwarded-For header coming in. However the query string >>>> remoteAddr=/192.168.33.80:54672 which I believe is the one sent to the >>>> ajp connector shows some half valid IP address which is that of the load >>>> balancer. Did anyone come across this before? Looks like a bug of some sort. >>>> >>>> The symptom is a endless loop trying to log into the admin panel. >>>> >>>> Cheers >>>> Niels >>>> >>>> >>>> # cat standalone/log/server.log | grep -A 58 '2016-05-24 09:19:27,672' >>>> 2016-05-24 09:19:27,672 WARN [org.keycloak.events] (default task-19) >>>> type=CODE_TO_TOKEN_ERROR, realmId=master, clientId=admin, userId=null, >>>> ipAddress=*192.168.33.1*, error=invalid_client_credentials, >>>> grant_type=authorization_code >>>> 2016-05-24 09:19:27,673 INFO [io.undertow.request.dump] (default >>>> task-19) >>>> ----------------------------REQUEST--------------------------- >>>> URI=/auth/realms/master/protocol/openid-connect/token >>>> characterEncoding=null >>>> contentLength=229 >>>> contentType=[application/x-www-form-urlencoded] >>>> >>>> cookie=KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjM5YTVkNTlmLWMyNDYtNDkwZi04ZGZkLTZhYzVhNzgyZDI5ZCIsImNpZCI6InNlY3VyaXR5LWFkbWluLWNvbnNvbGUiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9hZG1pbi9tYXN0ZXIvY29uc29sZS8iLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiOGQ5ZGI4MzctMjY2Ni00NDcxLTk0ZDgtZmFkMmIxMjA3NDQxIiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL3JlYWxtcy9tYXN0ZXIiLCJyZXNwb25zZV90eXBlIjoiY29kZSIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL2FkbWluL21hc3Rlci9jb25zb2xlLyIsInN0YXRlIjoiNTQ4ZDE5ZTUtMjlkMS00NTU2LWFjNjAtYjZjZTM1ZmJiMGU2Iiwibm9uY2UiOiI5OGY3NDFiYS03MmQwLTQ0ZDUtOGQ0ZC1jZTAxNzZhYjMyMmUiLCJyZXNwb25zZV9tb2RlIjoiZnJhZ21lbnQifX0.I0jI4nDhbYtKNrVjdlwjjBe5mtd0a8u6Dm7rQXwLE60 >>>> >>>> cookie=KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJhNjY5OWJkOS00MWQ4LTQyNWYtYjE5Ni04Y2QzNmJiZjBmNjQiLCJleHAiOjE0NjQxMTc1NjcsIm5iZiI6MCwiaWF0IjoxNDY0MDgxNTY3LCJpc3MiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9yZWFsbXMvbWFzdGVyIiwic3ViIjoiY2YyNDg4MTEtNmQ4Mi00N2U3LWJmOWEtN2IxOTdmYjk4OGQwIiwic2Vzc2lvbl9zdGF0ZSI6IjFiYTljODRlLTBlMzctNGE4Mi1hNDg0LWMyNWQyYzRhODBmYyIsInJlc291cmNlX2FjY2VzcyI6e319.E0vEe9XQJ_6IbDC_TEUfumQCJ0fS1_AOYsHh7svyGp16VC89sH9J1FQuLJfHYFVJlDTcE6o2ktLg0fLw2nLIdLOv-WXMseYr0KzudZveiLy1CZbRoPS9w9vlN-_EuXojiz0ORcyh90keUhqW5tMShccHvEaq_wpXOJQ6ITIglsgUXNhlSuEfpEcBy4CCqKQW98bRQiTKQOtoOfgc-Ez1RHR-7esTw-U22P_H-EMk23jI3nwuYGtqOn4Vvqb4-cHOzdyE_xaVWZxeteNKhU-RexfrMaHx1PSy3T796aY7gIljcqkxra-SA1dbOsRBawwlhJwFtojzBHEs1841gJ4bgg >>>> >>>> cookie=KEYCLOAK_SESSION=master/cf248811-6d82-47e7-bf9a-7b197fb988d0/1ba9c84e-0e37-4a82-a484-c25d2c4a80fc >>>> header=Accept=*/* >>>> header=Accept-Language=en-US,en;q=0.8,de;q=0.6 >>>> header=Accept-Encoding=gzip, deflate >>>> header=DNT=1 >>>> header=Origin=https://login.vagrant.v8 >>>> header=X-Original-To=192.168.33.80 >>>> header=User-Agent=Mozilla/5.0 (Windows NT 6.1; WOW64) >>>> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 >>>> header=X-Forwarded-Proto=https >>>> header=X-Forwarded-Port=443 >>>> header=X-Forwarded-For=192.168.33.1 >>>> header=Content-Length=229 >>>> header=Content-Type=application/x-www-form-urlencoded >>>> >>>> header=Cookie=KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjM5YTVkNTlmLWMyNDYtNDkwZi04ZGZkLTZhYzVhNzgyZDI5ZCIsImNpZCI6InNlY3VyaXR5LWFkbWluLWNvbnNvbGUiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9hZG1pbi9tYXN0ZXIvY29uc29sZS8iLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiOGQ5ZGI4MzctMjY2Ni00NDcxLTk0ZDgtZmFkMmIxMjA3NDQxIiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL3JlYWxtcy9tYXN0ZXIiLCJyZXNwb25zZV90eXBlIjoiY29kZSIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL2FkbWluL21hc3Rlci9jb25zb2xlLyIsInN0YXRlIjoiNTQ4ZDE5ZTUtMjlkMS00NTU2LWFjNjAtYjZjZTM1ZmJiMGU2Iiwibm9uY2UiOiI5OGY3NDFiYS03MmQwLTQ0ZDUtOGQ0ZC1jZTAxNzZhYjMyMmUiLCJyZXNwb25zZV9tb2RlIjoiZnJhZ21lbnQifX0.I0jI4nDhbYtKNrVjdlwjjBe5mtd0a8u6Dm7rQXwLE60; >>>> KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJhNjY5OWJkOS00MWQ4LTQyNWYtYjE5Ni04Y2QzNmJiZjBmNjQiLCJleHAiOjE0NjQxMTc1NjcsIm5iZiI6MCwiaWF0IjoxNDY0MDgxNTY3LCJpc3MiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9yZWFsbXMvbWFzdGVyIiwic3ViIjoiY2YyNDg4MTEtNmQ4Mi00N2U3LWJmOWEtN2IxOTdmYjk4OGQwIiwic2Vzc2lvbl9zdGF0ZSI6IjFiYTljODRlLTBlMzctNGE4Mi1hNDg0LWMyNWQyYzRhODBmYyIsInJlc291cmNlX2FjY2VzcyI6e319.E0vEe9XQJ_6IbDC_TEUfumQCJ0fS1_AOYsHh7svyGp16VC89sH9J1FQuLJfHYFVJlDTcE6o2ktLg0fLw2nLIdLOv-WXMseYr0KzudZveiLy1CZbRoPS9w9vlN-_EuXojiz0ORcyh90keUhqW5tMShccHvEaq_wpXOJQ6ITIglsgUXNhlSuEfpEcBy4CCqKQW98bRQiTKQOtoOfgc-Ez1RHR-7esTw-U22P_H-EMk23jI3nwuYGtqOn4Vvqb4-cHOzdyE_xaVWZxeteNKhU-RexfrMaHx1PSy3T796aY7gIljcqkxra-SA1dbOsRBawwlhJwFtojzBHEs1841gJ4bgg; >>>> KEYCLOAK_SESSION=master/cf248811-6d82-47e7-bf9a-7b197fb988d0/1ba9c84e-0e37-4a82-a484-c25d2c4a80fc >>>> header=Referer= >>>> https://login.vagrant.v8/auth/admin/master/console/ >>>> header=Host=login.vagrant.v8 >>>> locale=[en_US, en, de] >>>> method=POST >>>> protocol=HTTP/1.1 >>>> queryString= >>>> * remoteAddr=/192.168.33.80:54672 * >>>> remoteHost=proxy.vagrant.v8 >>>> scheme=https >>>> host=login.vagrant.v8 >>>> serverPort=443 >>>> --------------------------RESPONSE-------------------------- >>>> contentLength=123 >>>> contentType=application/json >>>> header=X-Powered-By=Undertow/1 >>>> header=Server=WildFly/10 >>>> header=Content-Type=application/json >>>> header=Content-Length=123 >>>> header=Date=Tue, 24 May 2016 09:19:27 GMT >>>> status=400 >>>> >>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/b7d567ef/attachment-0001.html From sthorger at redhat.com Wed May 25 05:20:11 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 25 May 2016 11:20:11 +0200 Subject: [keycloak-user] Keycloak token exchange failure behind loadbalancer and reverse proxy In-Reply-To: References: Message-ID: There's something strange going on in your Chrome browser then. It's an XMLHttpRequest after all, not sure I'd call including a basic auth header with user credentials "smart" ;). Maybe try disabling lastpass plugin to check if it's the culprit? In theory we could ignore basic auth header if client is public and client-id query param is included, but then again it's an invalid request so we'd be enabling sending strange requests. On 25 May 2016 at 10:26, Niels Bertram wrote: > Interesting point Stian. This header seems to be originating from Chrome > browser. I am not quite sure why its added but I also run lastpass chrome > plugin which may be too smart for its own good. > > I also just tried the keycloak master realm login on Internet Explorer and > Firefox which both work as expected and the http request dumps on the > keycloak server show that these 2 browsers do not add the Basic Auth header. > > I looked at the below specs and I can see that keycloak assumes the Basic > Auth header contains the client credentials which it is then trying to > validate. > > http://openid.net/specs/openid-connect-core-1_0.html#TokenRequest > https://tools.ietf.org/html/rfc6749#section-2.3.1 > https://tools.ietf.org/html/rfc6749#section-4.1.3 > > Just wondering if keycloak should ignore the Basic Auth header if the > client is configured to be public ?? Afterall client_id should be in the > post form and sending a password from a user browser would be insecure in > any case. > > Thanks, Niels > > > > On Wed, May 25, 2016 at 4:39 PM, Stian Thorgersen > wrote: > >> The message means it's unable to authenticate the client for the code to >> token exchange. >> >> Looking at the request it's a strange one as it looks like you've tried >> to login to the admin console then the code to token request for some >> reason includes "Authorization=Basic YWRtaW46Y2hhbmdlbWU=" which is >> credentials for a user 'admin' with password 'changeme'. Is this being >> added by your proxy or something? >> >> >> On 24 May 2016 at 14:41, Niels Bertram wrote: >> >>> Yes I can confirm the filter is correctly added. I also have all the >>> other required settings configured (hopefully correctly). It works reliably >>> when I target the apache reverse proxy but only falls appart when I load >>> balance through another "hop". I switched on debug on keycloak and can see >>> a bit more details of the failure (logs below). I wonder what >>> "AuthenticationFlowException: Client was not identified by any client >>> authenticator" means. >>> >>> >>> >>> >> redirect-socket="proxy-https" enabled="true" /> >>> >> proxy-address-forwarding="true" redirect-socket="proxy-https" /> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> header-value="WildFly/10"/> >>> >> header-value="Undertow/1"/> >>> >> class-name="io.undertow.server.handlers.ProxyPeerAddressHandler" >>> module="io.undertow.core" /> >>> >>> >>> >>> >> port-offset="${jboss.socket.binding.port-offset:0}"> >>> ... >>> >>> >>> >>> >>> ... >>> >>> >>> >>> >>> 2016-05-24 09:59:26,176 DEBUG [org.keycloak.services] (default task-11) >>> AUTHENTICATE CLIENT >>> 2016-05-24 09:59:26,176 DEBUG [org.keycloak.services] (default task-11) >>> client authenticator: client-secret >>> 2016-05-24 09:59:26,179 DEBUG [org.keycloak.services] (default task-11) >>> client authenticator: client-jwt >>> 2016-05-24 09:59:26,180 DEBUG [org.keycloak.services] (default task-11) >>> KC-SERVICES0014: Failed client authentication: >>> org.keycloak.authentication.AuthenticationFlowException: Client was not >>> identified by any client authenticator >>> at >>> org.keycloak.authentication.ClientAuthenticationFlow.processFlow(ClientAuthenticationFlow.java:101) >>> at >>> org.keycloak.authentication.AuthenticationProcessor.authenticateClient(AuthenticationProcessor.java:673) >>> at >>> org.keycloak.protocol.oidc.utils.AuthorizeClientUtil.authorizeClient(AuthorizeClientUtil.java:42) >>> at >>> org.keycloak.protocol.oidc.endpoints.TokenEndpoint.checkClient(TokenEndpoint.java:163) >>> at >>> org.keycloak.protocol.oidc.endpoints.TokenEndpoint.build(TokenEndpoint.java:117) >>> at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source) >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.lang.reflect.Method.invoke(Method.java:498) >>> at >>> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) >>> at >>> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) >>> at >>> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) >>> at >>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) >>> at >>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107) >>> at >>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133) >>> at >>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) >>> at >>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) >>> at >>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) >>> at >>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) >>> at >>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) >>> at >>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) >>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>> at >>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) >>> at >>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) >>> at >>> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:88) >>> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) >>> at >>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) >>> at >>> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) >>> at >>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) >>> at >>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) >>> at >>> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) >>> at >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> at >>> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) >>> at >>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) >>> at >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> at >>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) >>> at >>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) >>> at >>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) >>> at >>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) >>> at >>> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) >>> at >>> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) >>> at >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> at >>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >>> at >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> at >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> at >>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) >>> at >>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) >>> at >>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) >>> at >>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) >>> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) >>> at >>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) >>> at >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>> at java.lang.Thread.run(Thread.java:745) >>> >>> 2016-05-24 09:59:26,180 WARN [org.keycloak.events] (default task-11) >>> type=CODE_TO_TOKEN_ERROR, realmId=master, clientId=admin, userId=null, >>> ipAddress=192.168.33.1, error=invalid_client_credentials, >>> grant_type=authorization_code >>> 2016-05-24 09:59:26,863 DEBUG [org.keycloak.services] (default task-8) >>> replacing relative valid redirect with: >>> https://login.vagrant.v8/auth/admin/master/console/* >>> 2016-05-24 09:59:26,867 DEBUG [org.keycloak.services] (default task-8) >>> AUTHENTICATE >>> 2016-05-24 09:59:26,867 DEBUG [org.keycloak.services] (default task-8) >>> AUTHENTICATE ONLY >>> 2016-05-24 09:59:26,867 DEBUG [org.keycloak.services] (default task-8) >>> processFlow >>> 2016-05-24 09:59:26,868 DEBUG [org.keycloak.services] (default task-8) >>> check execution: auth-cookie requirement: ALTERNATIVE >>> 2016-05-24 09:59:26,868 DEBUG [org.keycloak.services] (default task-8) >>> authenticator: auth-cookie >>> 2016-05-24 09:59:26,868 DEBUG [org.keycloak.services] (default task-8) >>> invoke authenticator.authenticate >>> 2016-05-24 09:59:26,869 DEBUG [org.keycloak.services] (default task-8) >>> token active - active: true, issued-at: 1,464,083,965, not-before: 0 >>> 2016-05-24 09:59:26,869 DEBUG [org.keycloak.services] (default task-8) >>> authenticator SUCCESS: auth-cookie >>> 2016-05-24 09:59:26,873 DEBUG [org.keycloak.services] (default task-8) >>> check execution: auth-spnego requirement: DISABLED >>> 2016-05-24 09:59:26,873 DEBUG [org.keycloak.services] (default task-8) >>> execution is processed >>> 2016-05-24 09:59:26,873 DEBUG [org.keycloak.services] (default task-8) >>> check execution: null requirement: ALTERNATIVE >>> 2016-05-24 09:59:26,873 DEBUG [org.keycloak.services] (default task-8) >>> Skip alternative execution >>> 2016-05-24 09:59:26,874 DEBUG [org.keycloak.events] (default task-8) >>> type=LOGIN, realmId=master, clientId=security-admin-console, >>> userId=cf248811-6d82-47e7-bf9a-7b197fb988d0, ipAddress=192.168.33.1, >>> auth_method=openid-connect, auth_type=code, response_type=code, >>> redirect_uri=https://login.vagrant.v8/auth/admin/master/console/, >>> consent=no_consent_required, code_id=8215bbb3-a592-47e0-9c28-c274bccc61b5, >>> response_mode=fragment, username=admin >>> 2016-05-24 09:59:26,891 DEBUG [org.keycloak.services] (default task-8) >>> Create login cookie - name: KEYCLOAK_IDENTITY, path: /auth/realms/master, >>> max-age: -1 >>> 2016-05-24 09:59:26,892 DEBUG [org.keycloak.services] (default task-8) >>> redirectAccessCode: state: ae0d05d7-95d9-40a0-9a75-7e4e4fb7830e >>> 2016-05-24 09:59:27,472 DEBUG [org.keycloak.services] (default task-11) >>> AUTHENTICATE CLIENT >>> 2016-05-24 09:59:27,472 DEBUG [org.keycloak.services] (default task-11) >>> client authenticator: client-secret >>> 2016-05-24 09:59:27,474 DEBUG [org.keycloak.services] (default task-11) >>> client authenticator: client-jwt >>> 2016-05-24 09:59:27,474 DEBUG [org.keycloak.services] (default task-11) >>> KC-SERVICES0014: Failed client authentication: >>> org.keycloak.authentication.AuthenticationFlowException: Client was not >>> identified by any client authenticator >>> at >>> org.keycloak.authentication.ClientAuthenticationFlow.processFlow(ClientAuthenticationFlow.java:101) >>> at >>> org.keycloak.authentication.AuthenticationProcessor.authenticateClient(AuthenticationProcessor.java:673) >>> at >>> org.keycloak.protocol.oidc.utils.AuthorizeClientUtil.authorizeClient(AuthorizeClientUtil.java:42) >>> at >>> org.keycloak.protocol.oidc.endpoints.TokenEndpoint.checkClient(TokenEndpoint.java:163) >>> at >>> org.keycloak.protocol.oidc.endpoints.TokenEndpoint.build(TokenEndpoint.java:117) >>> at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source) >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.lang.reflect.Method.invoke(Method.java:498) >>> at >>> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) >>> at >>> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) >>> at >>> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) >>> at >>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) >>> at >>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107) >>> at >>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133) >>> at >>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) >>> at >>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) >>> at >>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) >>> at >>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) >>> at >>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) >>> at >>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) >>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>> at >>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) >>> at >>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) >>> at >>> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:88) >>> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) >>> at >>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) >>> at >>> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) >>> at >>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) >>> at >>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) >>> at >>> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) >>> at >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> at >>> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) >>> at >>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) >>> at >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> at >>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) >>> at >>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) >>> at >>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) >>> at >>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) >>> at >>> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) >>> at >>> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) >>> at >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> at >>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >>> at >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> at >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> at >>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) >>> at >>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) >>> at >>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) >>> at >>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) >>> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) >>> at >>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) >>> at >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>> at java.lang.Thread.run(Thread.java:745) >>> >>> 2016-05-24 09:59:27,478 WARN [org.keycloak.events] (default task-11) >>> type=CODE_TO_TOKEN_ERROR, realmId=master, clientId=admin, userId=null, >>> ipAddress=192.168.33.1, error=invalid_client_credentials, >>> grant_type=authorization_code >>> 2016-05-24 09:59:28,209 DEBUG [org.keycloak.services] (default task-8) >>> replacing relative valid redirect with: >>> https://login.vagrant.v8/auth/admin/master/console/* >>> 2016-05-24 09:59:28,211 DEBUG [org.keycloak.services] (default task-8) >>> AUTHENTICATE >>> 2016-05-24 09:59:28,218 DEBUG [org.keycloak.services] (default task-8) >>> AUTHENTICATE ONLY >>> 2016-05-24 09:59:28,218 DEBUG [org.keycloak.services] (default task-8) >>> processFlow >>> 2016-05-24 09:59:28,219 DEBUG [org.keycloak.services] (default task-8) >>> check execution: auth-cookie requirement: ALTERNATIVE >>> 2016-05-24 09:59:28,219 DEBUG [org.keycloak.services] (default task-8) >>> authenticator: auth-cookie >>> 2016-05-24 09:59:28,219 DEBUG [org.keycloak.services] (default task-8) >>> invoke authenticator.authenticate >>> 2016-05-24 09:59:28,220 DEBUG [org.keycloak.services] (default task-8) >>> token active - active: true, issued-at: 1,464,083,966, not-before: 0 >>> 2016-05-24 09:59:28,222 DEBUG [org.keycloak.services] (default task-8) >>> authenticator SUCCESS: auth-cookie >>> 2016-05-24 09:59:28,222 DEBUG [org.keycloak.services] (default task-8) >>> check execution: auth-spnego requirement: DISABLED >>> 2016-05-24 09:59:28,222 DEBUG [org.keycloak.services] (default task-8) >>> execution is processed >>> 2016-05-24 09:59:28,222 DEBUG [org.keycloak.services] (default task-8) >>> check execution: null requirement: ALTERNATIVE >>> 2016-05-24 09:59:28,222 DEBUG [org.keycloak.services] (default task-8) >>> Skip alternative execution >>> 2016-05-24 09:59:28,223 DEBUG [org.keycloak.events] (default task-8) >>> type=LOGIN, realmId=master, clientId=security-admin-console, >>> userId=cf248811-6d82-47e7-bf9a-7b197fb988d0, ipAddress=192.168.33.1, >>> auth_method=openid-connect, auth_type=code, response_type=code, >>> redirect_uri=https://login.vagrant.v8/auth/admin/master/console/, >>> consent=no_consent_required, code_id=7f9dbb5c-651a-4cc4-a248-91637c354fa5, >>> response_mode=fragment, username=admin >>> 2016-05-24 09:59:28,255 DEBUG [org.keycloak.services] (default task-8) >>> Create login cookie - name: KEYCLOAK_IDENTITY, path: /auth/realms/master, >>> max-age: -1 >>> 2016-05-24 09:59:28,256 DEBUG [org.keycloak.services] (default task-8) >>> redirectAccessCode: state: 89b303fd-f77e-4b23-8de0-2c517304e671 >>> 2016-05-24 09:59:28,612 DEBUG [org.keycloak.services] (default task-11) >>> AUTHENTICATE CLIENT >>> 2016-05-24 09:59:28,612 DEBUG [org.keycloak.services] (default task-11) >>> client authenticator: client-secret >>> 2016-05-24 09:59:28,613 DEBUG [org.keycloak.services] (default task-11) >>> client authenticator: client-jwt >>> 2016-05-24 09:59:28,614 DEBUG [org.keycloak.services] (default task-11) >>> KC-SERVICES0014: Failed client authentication: >>> org.keycloak.authentication.AuthenticationFlowException: Client was not >>> identified by any client authenticator >>> at >>> org.keycloak.authentication.ClientAuthenticationFlow.processFlow(ClientAuthenticationFlow.java:101) >>> at >>> org.keycloak.authentication.AuthenticationProcessor.authenticateClient(AuthenticationProcessor.java:673) >>> at >>> org.keycloak.protocol.oidc.utils.AuthorizeClientUtil.authorizeClient(AuthorizeClientUtil.java:42) >>> at >>> org.keycloak.protocol.oidc.endpoints.TokenEndpoint.checkClient(TokenEndpoint.java:163) >>> at >>> org.keycloak.protocol.oidc.endpoints.TokenEndpoint.build(TokenEndpoint.java:117) >>> at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source) >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.lang.reflect.Method.invoke(Method.java:498) >>> at >>> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) >>> at >>> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) >>> at >>> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) >>> at >>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) >>> at >>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107) >>> at >>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133) >>> at >>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) >>> at >>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) >>> at >>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) >>> at >>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) >>> at >>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) >>> at >>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) >>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>> at >>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) >>> at >>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) >>> at >>> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:88) >>> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) >>> at >>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) >>> at >>> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) >>> at >>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) >>> at >>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) >>> at >>> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) >>> at >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> at >>> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) >>> at >>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) >>> at >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> at >>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) >>> at >>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) >>> at >>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) >>> at >>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) >>> at >>> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) >>> at >>> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) >>> at >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> at >>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >>> at >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> at >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>> at >>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) >>> at >>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) >>> at >>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) >>> at >>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) >>> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) >>> at >>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) >>> at >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>> at java.lang.Thread.run(Thread.java:745) >>> >>> 2016-05-24 09:59:28,614 WARN [org.keycloak.events] (default task-11) >>> type=CODE_TO_TOKEN_ERROR, realmId=master, clientId=admin, userId=null, >>> ipAddress=192.168.33.1, error=invalid_client_credentials, >>> grant_type=authorization_code >>> 2016-05-24 09:59:28,692 INFO [io.undertow.request.dump] (default >>> task-11) >>> ----------------------------REQUEST--------------------------- >>> URI=/auth/realms/master/protocol/openid-connect/token >>> characterEncoding=null >>> contentLength=229 >>> contentType=[application/x-www-form-urlencoded] >>> >>> cookie=KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjdmOWRiYjVjLTY1MWEtNGNjNC1hMjQ4LTkxNjM3YzM1NGZhNSIsImNpZCI6InNlY3VyaXR5LWFkbWluLWNvbnNvbGUiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9hZG1pbi9tYXN0ZXIvY29uc29sZS8iLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiYjg3OTM2Y2ItZTg1OC00NDhlLWJmMTAtNGNkYjQzMDFkMTg2IiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL3JlYWxtcy9tYXN0ZXIiLCJyZXNwb25zZV90eXBlIjoiY29kZSIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL2FkbWluL21hc3Rlci9jb25zb2xlLyIsInN0YXRlIjoiODliMzAzZmQtZjc3ZS00YjIzLThkZTAtMmM1MTczMDRlNjcxIiwibm9uY2UiOiI1MzY0YTRhZS0wNzI3LTQwYWItOWEyMi0yN2ExZDQ5NjVmNTkiLCJyZXNwb25zZV9tb2RlIjoiZnJhZ21lbnQifX0.7Xnk589FgD_9RulKC4V48gn-056yVxa_DdIGm4Hpgj8 >>> >>> cookie=KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI5ZjRmNWU3OS02NWYxLTQ0M2ItOGI5YS1hZWI4NzZmYmNkNjIiLCJleHAiOjE0NjQxMTk5NjgsIm5iZiI6MCwiaWF0IjoxNDY0MDgzOTY4LCJpc3MiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9yZWFsbXMvbWFzdGVyIiwic3ViIjoiY2YyNDg4MTEtNmQ4Mi00N2U3LWJmOWEtN2IxOTdmYjk4OGQwIiwic2Vzc2lvbl9zdGF0ZSI6ImQzYjAxY2Q1LWQxNWEtNGQ2OS05MTQ3LWE1YTEzYWI4MjQxNiIsInJlc291cmNlX2FjY2VzcyI6e319.eiDWSR8eeIdX7AKZiWI3e9moUD9ZuD-h88XX31JRMio_FmqSvMgRHcZtkVjjrLnjcmWn7X4jIcITARk-TiywjfAKotkPYodgCyxsmln5LRQeV3SYXltCGWKmsFmq0BsMjQbfstjdR9V9Xh7daiyRNxLGcoYitEEOeKboMjbGwZw11jggaTRifpNYp-M9GtTBvHSJg6RFdmm0QTLeJm9OgOvBzdRlKwGTUcJeqJxuNWgd4XqPS5vbpliDsfuvekC8VFeDB_UGci1hCIEoMy0-tlpwPLP_xGbCd5L8XFKrr0shoGbQlyJjFZB49VtJlHLkd8F15mZQxJ1G9BWj_wKINw >>> >>> cookie=KEYCLOAK_SESSION=master/cf248811-6d82-47e7-bf9a-7b197fb988d0/d3b01cd5-d15a-4d69-9147-a5a13ab82416 >>> header=X-Real-Ip=192.168.33.1 >>> header=Accept-Encoding=gzip, deflate >>> header=DNT=1 >>> header=Origin=https://login.vagrant.v8 >>> header=X-Forwarded-Port=443 >>> header=X-Forwarded-For=192.168.33.1 >>> >>> header=Cookie=KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjdmOWRiYjVjLTY1MWEtNGNjNC1hMjQ4LTkxNjM3YzM1NGZhNSIsImNpZCI6InNlY3VyaXR5LWFkbWluLWNvbnNvbGUiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9hZG1pbi9tYXN0ZXIvY29uc29sZS8iLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiYjg3OTM2Y2ItZTg1OC00NDhlLWJmMTAtNGNkYjQzMDFkMTg2IiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL3JlYWxtcy9tYXN0ZXIiLCJyZXNwb25zZV90eXBlIjoiY29kZSIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL2FkbWluL21hc3Rlci9jb25zb2xlLyIsInN0YXRlIjoiODliMzAzZmQtZjc3ZS00YjIzLThkZTAtMmM1MTczMDRlNjcxIiwibm9uY2UiOiI1MzY0YTRhZS0wNzI3LTQwYWItOWEyMi0yN2ExZDQ5NjVmNTkiLCJyZXNwb25zZV9tb2RlIjoiZnJhZ21lbnQifX0.7Xnk589FgD_9RulKC4V48gn-056yVxa_DdIGm4Hpgj8; >>> KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI5ZjRmNWU3OS02NWYxLTQ0M2ItOGI5YS1hZWI4NzZmYmNkNjIiLCJleHAiOjE0NjQxMTk5NjgsIm5iZiI6MCwiaWF0IjoxNDY0MDgzOTY4LCJpc3MiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9yZWFsbXMvbWFzdGVyIiwic3ViIjoiY2YyNDg4MTEtNmQ4Mi00N2U3LWJmOWEtN2IxOTdmYjk4OGQwIiwic2Vzc2lvbl9zdGF0ZSI6ImQzYjAxY2Q1LWQxNWEtNGQ2OS05MTQ3LWE1YTEzYWI4MjQxNiIsInJlc291cmNlX2FjY2VzcyI6e319.eiDWSR8eeIdX7AKZiWI3e9moUD9ZuD-h88XX31JRMio_FmqSvMgRHcZtkVjjrLnjcmWn7X4jIcITARk-TiywjfAKotkPYodgCyxsmln5LRQeV3SYXltCGWKmsFmq0BsMjQbfstjdR9V9Xh7daiyRNxLGcoYitEEOeKboMjbGwZw11jggaTRifpNYp-M9GtTBvHSJg6RFdmm0QTLeJm9OgOvBzdRlKwGTUcJeqJxuNWgd4XqPS5vbpliDsfuvekC8VFeDB_UGci1hCIEoMy0-tlpwPLP_xGbCd5L8XFKrr0shoGbQlyJjFZB49VtJlHLkd8F15mZQxJ1G9BWj_wKINw; >>> KEYCLOAK_SESSION=master/cf248811-6d82-47e7-bf9a-7b197fb988d0/d3b01cd5-d15a-4d69-9147-a5a13ab82416 >>> header=Referer= >>> https://login.vagrant.v8/auth/admin/master/console/ >>> header=Host=login.vagrant.v8 >>> header=Accept=*/* >>> header=Accept-Language=en-US,en;q=0.8,de;q=0.6 >>> header=X-Original-To=192.168.33.80 >>> header=User-Agent=Mozilla/5.0 (Windows NT 6.1; WOW64) >>> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 >>> header=Authorization=Basic YWRtaW46Y2hhbmdlbWU= >>> header=X-Forwarded-Proto=https >>> header=Content-Length=229 >>> header=Content-Type=application/x-www-form-urlencoded >>> locale=[en_US, en, de] >>> method=POST >>> protocol=HTTP/1.1 >>> queryString= >>> remoteAddr=/192.168.33.80:55892 >>> remoteHost=proxy.vagrant.v8 >>> scheme=https >>> host=login.vagrant.v8 >>> serverPort=443 >>> --------------------------RESPONSE-------------------------- >>> contentLength=123 >>> contentType=application/json >>> header=X-Powered-By=Undertow/1 >>> header=Server=WildFly/10 >>> header=Content-Type=application/json >>> header=Content-Length=123 >>> header=Date=Tue, 24 May 2016 09:59:28 GMT >>> status=400 >>> >>> >>> On Tue, May 24, 2016 at 9:49 PM, Stian Thorgersen >>> wrote: >>> >>>> Did you add ProxyPeerAddressHandler filter? That's required for AJP >>>> connector, see >>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#proxy-address-forwarding >>>> >>>> On 24 May 2016 at 11:48, Niels Bertram wrote: >>>> >>>>> I am scratching my head with a specific setup problem which does not >>>>> generate any usable error messages. >>>>> >>>>> I am running a haproxy as load balancer in a vm in front an apache web >>>>> server configured as reverse proxy connecting to the keycloak server via >>>>> ajp in another VM. >>>>> >>>>> client browser (192.168.33.1) >>>>> >>>>> login.vagrant.v8 (192.168.33.80) aka proxy.vagrant.v8 is >>>>> haproxy adds X-Forwarded-For X-Forwarded-Port X-Forwarded-Proto >>>>> and X-Real-Ip >>>>> >>>>> kc01.vagrant.v8 (192.168.33.81) apache reverse proxies >>>>> to wildfly on ajp port >>>>> >>>>> >>>>> Followed all the setup instructions in the documentation and if I >>>>> connect to apache proxying through to keycloak everything works fine. All >>>>> web resources are donwloaded fine however when I request a token exchange >>>>> on /auth/realms/master/protocol/openid-connect/token I get a 400 >>>>> response. The kc server log shows the corect IP address of the originating >>>>> client and the request dump from wildfly also shows the correct >>>>> X-Forwarded-For header coming in. However the query string >>>>> remoteAddr=/192.168.33.80:54672 which I believe is the one sent to >>>>> the ajp connector shows some half valid IP address which is that of the >>>>> load balancer. Did anyone come across this before? Looks like a bug of some >>>>> sort. >>>>> >>>>> The symptom is a endless loop trying to log into the admin panel. >>>>> >>>>> Cheers >>>>> Niels >>>>> >>>>> >>>>> # cat standalone/log/server.log | grep -A 58 '2016-05-24 09:19:27,672' >>>>> 2016-05-24 09:19:27,672 WARN [org.keycloak.events] (default task-19) >>>>> type=CODE_TO_TOKEN_ERROR, realmId=master, clientId=admin, userId=null, >>>>> ipAddress=*192.168.33.1*, error=invalid_client_credentials, >>>>> grant_type=authorization_code >>>>> 2016-05-24 09:19:27,673 INFO [io.undertow.request.dump] (default >>>>> task-19) >>>>> ----------------------------REQUEST--------------------------- >>>>> URI=/auth/realms/master/protocol/openid-connect/token >>>>> characterEncoding=null >>>>> contentLength=229 >>>>> contentType=[application/x-www-form-urlencoded] >>>>> >>>>> cookie=KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjM5YTVkNTlmLWMyNDYtNDkwZi04ZGZkLTZhYzVhNzgyZDI5ZCIsImNpZCI6InNlY3VyaXR5LWFkbWluLWNvbnNvbGUiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9hZG1pbi9tYXN0ZXIvY29uc29sZS8iLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiOGQ5ZGI4MzctMjY2Ni00NDcxLTk0ZDgtZmFkMmIxMjA3NDQxIiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL3JlYWxtcy9tYXN0ZXIiLCJyZXNwb25zZV90eXBlIjoiY29kZSIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL2FkbWluL21hc3Rlci9jb25zb2xlLyIsInN0YXRlIjoiNTQ4ZDE5ZTUtMjlkMS00NTU2LWFjNjAtYjZjZTM1ZmJiMGU2Iiwibm9uY2UiOiI5OGY3NDFiYS03MmQwLTQ0ZDUtOGQ0ZC1jZTAxNzZhYjMyMmUiLCJyZXNwb25zZV9tb2RlIjoiZnJhZ21lbnQifX0.I0jI4nDhbYtKNrVjdlwjjBe5mtd0a8u6Dm7rQXwLE60 >>>>> >>>>> cookie=KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJhNjY5OWJkOS00MWQ4LTQyNWYtYjE5Ni04Y2QzNmJiZjBmNjQiLCJleHAiOjE0NjQxMTc1NjcsIm5iZiI6MCwiaWF0IjoxNDY0MDgxNTY3LCJpc3MiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9yZWFsbXMvbWFzdGVyIiwic3ViIjoiY2YyNDg4MTEtNmQ4Mi00N2U3LWJmOWEtN2IxOTdmYjk4OGQwIiwic2Vzc2lvbl9zdGF0ZSI6IjFiYTljODRlLTBlMzctNGE4Mi1hNDg0LWMyNWQyYzRhODBmYyIsInJlc291cmNlX2FjY2VzcyI6e319.E0vEe9XQJ_6IbDC_TEUfumQCJ0fS1_AOYsHh7svyGp16VC89sH9J1FQuLJfHYFVJlDTcE6o2ktLg0fLw2nLIdLOv-WXMseYr0KzudZveiLy1CZbRoPS9w9vlN-_EuXojiz0ORcyh90keUhqW5tMShccHvEaq_wpXOJQ6ITIglsgUXNhlSuEfpEcBy4CCqKQW98bRQiTKQOtoOfgc-Ez1RHR-7esTw-U22P_H-EMk23jI3nwuYGtqOn4Vvqb4-cHOzdyE_xaVWZxeteNKhU-RexfrMaHx1PSy3T796aY7gIljcqkxra-SA1dbOsRBawwlhJwFtojzBHEs1841gJ4bgg >>>>> >>>>> cookie=KEYCLOAK_SESSION=master/cf248811-6d82-47e7-bf9a-7b197fb988d0/1ba9c84e-0e37-4a82-a484-c25d2c4a80fc >>>>> header=Accept=*/* >>>>> header=Accept-Language=en-US,en;q=0.8,de;q=0.6 >>>>> header=Accept-Encoding=gzip, deflate >>>>> header=DNT=1 >>>>> header=Origin=https://login.vagrant.v8 >>>>> header=X-Original-To=192.168.33.80 >>>>> header=User-Agent=Mozilla/5.0 (Windows NT 6.1; WOW64) >>>>> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 >>>>> header=X-Forwarded-Proto=https >>>>> header=X-Forwarded-Port=443 >>>>> header=X-Forwarded-For=192.168.33.1 >>>>> header=Content-Length=229 >>>>> header=Content-Type=application/x-www-form-urlencoded >>>>> >>>>> header=Cookie=KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjM5YTVkNTlmLWMyNDYtNDkwZi04ZGZkLTZhYzVhNzgyZDI5ZCIsImNpZCI6InNlY3VyaXR5LWFkbWluLWNvbnNvbGUiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9hZG1pbi9tYXN0ZXIvY29uc29sZS8iLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiOGQ5ZGI4MzctMjY2Ni00NDcxLTk0ZDgtZmFkMmIxMjA3NDQxIiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL3JlYWxtcy9tYXN0ZXIiLCJyZXNwb25zZV90eXBlIjoiY29kZSIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL2FkbWluL21hc3Rlci9jb25zb2xlLyIsInN0YXRlIjoiNTQ4ZDE5ZTUtMjlkMS00NTU2LWFjNjAtYjZjZTM1ZmJiMGU2Iiwibm9uY2UiOiI5OGY3NDFiYS03MmQwLTQ0ZDUtOGQ0ZC1jZTAxNzZhYjMyMmUiLCJyZXNwb25zZV9tb2RlIjoiZnJhZ21lbnQifX0.I0jI4nDhbYtKNrVjdlwjjBe5mtd0a8u6Dm7rQXwLE60; >>>>> KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJhNjY5OWJkOS00MWQ4LTQyNWYtYjE5Ni04Y2QzNmJiZjBmNjQiLCJleHAiOjE0NjQxMTc1NjcsIm5iZiI6MCwiaWF0IjoxNDY0MDgxNTY3LCJpc3MiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9yZWFsbXMvbWFzdGVyIiwic3ViIjoiY2YyNDg4MTEtNmQ4Mi00N2U3LWJmOWEtN2IxOTdmYjk4OGQwIiwic2Vzc2lvbl9zdGF0ZSI6IjFiYTljODRlLTBlMzctNGE4Mi1hNDg0LWMyNWQyYzRhODBmYyIsInJlc291cmNlX2FjY2VzcyI6e319.E0vEe9XQJ_6IbDC_TEUfumQCJ0fS1_AOYsHh7svyGp16VC89sH9J1FQuLJfHYFVJlDTcE6o2ktLg0fLw2nLIdLOv-WXMseYr0KzudZveiLy1CZbRoPS9w9vlN-_EuXojiz0ORcyh90keUhqW5tMShccHvEaq_wpXOJQ6ITIglsgUXNhlSuEfpEcBy4CCqKQW98bRQiTKQOtoOfgc-Ez1RHR-7esTw-U22P_H-EMk23jI3nwuYGtqOn4Vvqb4-cHOzdyE_xaVWZxeteNKhU-RexfrMaHx1PSy3T796aY7gIljcqkxra-SA1dbOsRBawwlhJwFtojzBHEs1841gJ4bgg; >>>>> KEYCLOAK_SESSION=master/cf248811-6d82-47e7-bf9a-7b197fb988d0/1ba9c84e-0e37-4a82-a484-c25d2c4a80fc >>>>> header=Referer= >>>>> https://login.vagrant.v8/auth/admin/master/console/ >>>>> header=Host=login.vagrant.v8 >>>>> locale=[en_US, en, de] >>>>> method=POST >>>>> protocol=HTTP/1.1 >>>>> queryString= >>>>> * remoteAddr=/192.168.33.80:54672 * >>>>> remoteHost=proxy.vagrant.v8 >>>>> scheme=https >>>>> host=login.vagrant.v8 >>>>> serverPort=443 >>>>> --------------------------RESPONSE-------------------------- >>>>> contentLength=123 >>>>> contentType=application/json >>>>> header=X-Powered-By=Undertow/1 >>>>> header=Server=WildFly/10 >>>>> header=Content-Type=application/json >>>>> header=Content-Length=123 >>>>> header=Date=Tue, 24 May 2016 09:19:27 GMT >>>>> status=400 >>>>> >>>>> >>>>> _______________________________________________ >>>>> keycloak-user mailing list >>>>> keycloak-user at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/15eedd5d/attachment-0001.html From mposolda at redhat.com Wed May 25 07:43:18 2016 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 25 May 2016 13:43:18 +0200 Subject: [keycloak-user] Kerberos token In-Reply-To: References: Message-ID: <57458FD6.2050608@redhat.com> Hi, it seems from the log, that you tried to put Kerberos (SpnegoAuthenticator) to the directAccessGrant flow, is it correct? This won't work. The implementation of SpnegoAuthenticator is supposed to work just for browser based flow when browser is supposed to send HTTP header with SPNEGO token like "Authorization: Negotiate your-spnego-kerberos-token" . It seems that to avoid similar confusions, we should have some filters (or authentication subtypes), which will allow to specify which authenticator is supposed to be used in which flow. I've created JIRA for that https://issues.jboss.org/browse/KEYCLOAK-3043 . If I understand correctly your usecase, you sent username+password to direct grant authentication and you want Keycloak to verify the given username+password against Kerberos right? In this case, you can just use default directGrant flow without any changes. All you need to do is to check the flag " Use Kerberos For Password Authentication" in the configuration of your LDAP federation provider. Marek On 23/05/16 17:51, Gareth Healy wrote: > I am trying to hook up APIMan with KeyCloak using Kerberos and OAuth2. > I am trying to get a token from key cloak using the following URL: > > curl -X POST > http://localhost:29080/auth/realms/freeipa/protocol/openid-connect/token > -H "Content-Type: application/x-www-form-urlencoded" -d > "username=admin" -d 'password=Secret123' -d 'grant_type=password' > -d 'client_id=mapper' -d > 'client_secret=027fbd51-135b-47d6-86cd-7ce541b38984' > > > But, get an exception back: > > > 2016-05-23 14:22:25,676 DEBUG [org.keycloak.services] (default > task-51) AUTHENTICATE CLIENT > 2016-05-23 14:22:25,676 TRACE [org.keycloak.services] (default > task-51) Using executions for client authentication: > [de08b32a-a4a5-469c-91cc-0fbca51e1c2f, > de3db156-dcc2-4346-bf3a-e56e8e10ed5f] > 2016-05-23 14:22:25,676 DEBUG [org.keycloak.services] (default > task-51) client authenticator: client-secret > 2016-05-23 14:22:25,676 DEBUG [org.keycloak.services] (default > task-51) client authenticator SUCCESS: client-secret > 2016-05-23 14:22:25,676 DEBUG [org.keycloak.services] (default > task-51) Client mapper authenticated by client-secret > 2016-05-23 14:22:25,676 TRACE > [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] > (default task-51) Adding cache operation: ADD on > 7ad60b45-4e69-45a4-a995-ee65d9ee47ae > 2016-05-23 14:22:25,676 TRACE > [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] > (default task-51) Adding cache operation: REPLACE on > 7ad60b45-4e69-45a4-a995-ee65d9ee47ae > 2016-05-23 14:22:25,676 TRACE > [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] > (default task-51) Adding cache operation: REPLACE on > 7ad60b45-4e69-45a4-a995-ee65d9ee47ae > 2016-05-23 14:22:25,676 TRACE > [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] > (default task-51) Adding cache operation: REPLACE on > 7ad60b45-4e69-45a4-a995-ee65d9ee47ae > 2016-05-23 14:22:25,676 TRACE > [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] > (default task-51) Adding cache operation: REPLACE on > 7ad60b45-4e69-45a4-a995-ee65d9ee47ae > 2016-05-23 14:22:25,676 TRACE > [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] > (default task-51) Adding cache operation: REPLACE on > 7ad60b45-4e69-45a4-a995-ee65d9ee47ae > 2016-05-23 14:22:25,676 DEBUG [org.keycloak.services] (default > task-51) AUTHENTICATE ONLY > 2016-05-23 14:22:25,676 TRACE > [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] > (default task-51) Adding cache operation: REPLACE on > 7ad60b45-4e69-45a4-a995-ee65d9ee47ae > 2016-05-23 14:22:25,676 DEBUG [org.keycloak.services] (default > task-51) processFlow > 2016-05-23 14:22:25,676 DEBUG [org.keycloak.services] (default > task-51) check execution: direct-grant-validate-username > requirement: REQUIRED > 2016-05-23 14:22:25,676 DEBUG [org.keycloak.services] (default > task-51) authenticator: direct-grant-validate-username > 2016-05-23 14:22:25,676 DEBUG [org.keycloak.services] (default > task-51) invoke authenticator.authenticate > 2016-05-23 14:22:25,676 TRACE > [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] > (default task-51) Adding cache operation: REPLACE on > 7ad60b45-4e69-45a4-a995-ee65d9ee47ae > 2016-05-23 14:22:25,677 TRACE > [org.keycloak.federation.ldap.idm.store.ldap.LDAPIdentityStore] > (default task-51) Using filter for LDAP search: > (&(uid=admin)(objectclass=person)) . Searching in DN: > cn=users,cn=accounts,dc=example,dc=test > 2016-05-23 14:22:25,682 TRACE > [org.keycloak.federation.ldap.idm.store.ldap.LDAPIdentityStore] > (default task-51) Found ldap object and populated with the > attributes. LDAP Object: LDAP Object [ dn: > uid=admin,cn=users,cn=accounts,dc=example,dc=test , uuid: > afc65b08-1e75-11e6-9645-02420a01010f, attributes: {uid=[admin], > gecos=[Administrator], sn=[Administrator], cn=[Administrator], > createTimestamp=[20160520102908Z], > modifyTimestamp=[20160523142225Z]}, readOnly attribute names: > [createtimestamp, modifytimestamp] ] > 2016-05-23 14:22:25,682 TRACE > [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] > (default task-51) Adding cache operation: REPLACE on > 7ad60b45-4e69-45a4-a995-ee65d9ee47ae > 2016-05-23 14:22:25,682 DEBUG [org.keycloak.services] (default > task-51) authenticator SUCCESS: direct-grant-validate-username > 2016-05-23 14:22:25,682 TRACE > [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] > (default task-51) Adding cache operation: REPLACE on > 7ad60b45-4e69-45a4-a995-ee65d9ee47ae > 2016-05-23 14:22:25,682 DEBUG [org.keycloak.services] (default > task-51) check execution: direct-grant-validate-password > requirement: DISABLED > 2016-05-23 14:22:25,682 DEBUG [org.keycloak.services] (default > task-51) execution is processed > 2016-05-23 14:22:25,682 DEBUG [org.keycloak.services] (default > task-51) check execution: auth-spnego requirement: ALTERNATIVE > 2016-05-23 14:22:25,682 DEBUG [org.keycloak.services] (default > task-51) authenticator: auth-spnego > 2016-05-23 14:22:25,682 DEBUG [org.keycloak.services] (default > task-51) invoke authenticator.authenticate > 2016-05-23 14:22:25,682 TRACE [org.keycloak.services] (default > task-51) Sending back WWW-Authenticate: Negotiate > 2016-05-23 14:22:25,682 TRACE > [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] > (default task-51) Adding cache operation: REPLACE on > 7ad60b45-4e69-45a4-a995-ee65d9ee47ae > 2016-05-23 14:22:25,683 ERROR [io.undertow.request] (default > task-51) UT005023: Exception handling request to > /auth/realms/freeipa/protocol/openid-connect/token: > org.jboss.resteasy.spi.UnhandledException: > java.lang.IllegalArgumentException: RESTEASY003715: path was null > at > org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76) > at > org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212) > at > org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:168) > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:411) > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) > at > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) > at > org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:78) > at > io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) > at > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) > at > io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) > at > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at > org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at > io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at > io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) > at > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) > at > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) > at > io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > at > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.IllegalArgumentException: RESTEASY003715: > path was null > at > org.jboss.resteasy.specimpl.ResteasyUriBuilder.path(ResteasyUriBuilder.java:357) > at > org.keycloak.authentication.AuthenticationProcessor$Result.getActionUrl(AuthenticationProcessor.java:478) > at > org.keycloak.authentication.authenticators.browser.SpnegoAuthenticator.optionalChallengeRedirect(SpnegoAuthenticator.java:137) > at > org.keycloak.authentication.authenticators.browser.SpnegoAuthenticator.challengeNegotiation(SpnegoAuthenticator.java:121) > at > org.keycloak.authentication.authenticators.browser.SpnegoAuthenticator.authenticate(SpnegoAuthenticator.java:65) > at > org.keycloak.authentication.DefaultAuthenticationFlow.processFlow(DefaultAuthenticationFlow.java:183) > at > org.keycloak.authentication.AuthenticationProcessor.authenticateOnly(AuthenticationProcessor.java:789) > at > org.keycloak.protocol.oidc.endpoints.TokenEndpoint.buildResourceOwnerPasswordCredentialsGrant(TokenEndpoint.java:379) > at > org.keycloak.protocol.oidc.endpoints.TokenEndpoint.build(TokenEndpoint.java:125) > at sun.reflect.GeneratedMethodAccessor587.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) > at > org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) > at > org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) > ... 37 more > > > Looking in the code, i can see i am missing the "flowPath", but not > sure where this should be set. > > https://github.com/keycloak/keycloak/blob/1.9.x/services/src/main/java/org/keycloak/authentication/authenticators/browser/SpnegoAuthenticator.java#L137 > > https://github.com/keycloak/keycloak/blob/1.9.x/services/src/main/java/org/keycloak/authentication/AuthenticationProcessor.java#L476 > > > Can anyone point me in the right direction please. > > -- > Gareth Healy > UKI Middleware Consultant > Red Hat UK Ltd > 200 Fowler Avenue > Farnborough, Hants > GU14 7JP, UK > > Mobile: +44(0)7818511214 > E-Mail: gahealy at redhat.com > > Registered in England and Wales under Company Registration No. 03798903 > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/d16e1094/attachment-0001.html From nielsbne at gmail.com Wed May 25 08:12:17 2016 From: nielsbne at gmail.com (Niels Bertram) Date: Wed, 25 May 2016 22:12:17 +1000 Subject: [keycloak-user] Keycloak token exchange failure behind loadbalancer and reverse proxy In-Reply-To: References: Message-ID: I tested Chrome without the plugin and it works fine too. I raised a ticket with lastpass as I do agree, there is nothing smart about adding basic auth headers randomly to web requests. RE validating basic auth header when client is public, the section 2.3 in Oauth reads: The authorization server MAY establish a client authentication method with public clients. However, the authorization server MUST NOT rely on public client authentication for the purpose of identifying the client. so I guess it is up to the keycloak project to decide. I have used oauth clients in the past (specifically JavaScript and iOS ones) that required us to provide an empty or "insecure" client secret value. The OAuth servers we connected to never complained about these obviously wrong client credentials. So may be something to consider to ensure compatibilty with non-keycloak OAuth libraries. Cheers, Niels On Wed, May 25, 2016 at 7:20 PM, Stian Thorgersen wrote: > There's something strange going on in your Chrome browser then. It's > an XMLHttpRequest after all, not sure I'd call including a basic auth > header with user credentials "smart" ;). Maybe try disabling lastpass > plugin to check if it's the culprit? > > In theory we could ignore basic auth header if client is public and > client-id query param is included, but then again it's an invalid request > so we'd be enabling sending strange requests. > > On 25 May 2016 at 10:26, Niels Bertram wrote: > >> Interesting point Stian. This header seems to be originating from Chrome >> browser. I am not quite sure why its added but I also run lastpass chrome >> plugin which may be too smart for its own good. >> >> I also just tried the keycloak master realm login on Internet Explorer >> and Firefox which both work as expected and the http request dumps on the >> keycloak server show that these 2 browsers do not add the Basic Auth header. >> >> I looked at the below specs and I can see that keycloak assumes the Basic >> Auth header contains the client credentials which it is then trying to >> validate. >> >> http://openid.net/specs/openid-connect-core-1_0.html#TokenRequest >> https://tools.ietf.org/html/rfc6749#section-2.3.1 >> https://tools.ietf.org/html/rfc6749#section-4.1.3 >> >> Just wondering if keycloak should ignore the Basic Auth header if the >> client is configured to be public ?? Afterall client_id should be in the >> post form and sending a password from a user browser would be insecure in >> any case. >> >> Thanks, Niels >> >> >> >> On Wed, May 25, 2016 at 4:39 PM, Stian Thorgersen >> wrote: >> >>> The message means it's unable to authenticate the client for the code to >>> token exchange. >>> >>> Looking at the request it's a strange one as it looks like you've tried >>> to login to the admin console then the code to token request for some >>> reason includes "Authorization=Basic YWRtaW46Y2hhbmdlbWU=" which is >>> credentials for a user 'admin' with password 'changeme'. Is this being >>> added by your proxy or something? >>> >>> >>> On 24 May 2016 at 14:41, Niels Bertram wrote: >>> >>>> Yes I can confirm the filter is correctly added. I also have all the >>>> other required settings configured (hopefully correctly). It works reliably >>>> when I target the apache reverse proxy but only falls appart when I load >>>> balance through another "hop". I switched on debug on keycloak and can see >>>> a bit more details of the failure (logs below). I wonder what >>>> "AuthenticationFlowException: Client was not identified by any client >>>> authenticator" means. >>>> >>>> >>>> >>>> >>> socket-binding="ajp" redirect-socket="proxy-https" enabled="true" /> >>>> >>> proxy-address-forwarding="true" redirect-socket="proxy-https" /> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> header-value="WildFly/10"/> >>>> >>> header-name="X-Powered-By" header-value="Undertow/1"/> >>>> >>> class-name="io.undertow.server.handlers.ProxyPeerAddressHandler" >>>> module="io.undertow.core" /> >>>> >>>> >>>> >>>> >>> default-interface="public" >>>> port-offset="${jboss.socket.binding.port-offset:0}"> >>>> ... >>>> >>>> >>>> >>>> >>>> ... >>>> >>>> >>>> >>>> >>>> 2016-05-24 09:59:26,176 DEBUG [org.keycloak.services] (default task-11) >>>> AUTHENTICATE CLIENT >>>> 2016-05-24 09:59:26,176 DEBUG [org.keycloak.services] (default task-11) >>>> client authenticator: client-secret >>>> 2016-05-24 09:59:26,179 DEBUG [org.keycloak.services] (default task-11) >>>> client authenticator: client-jwt >>>> 2016-05-24 09:59:26,180 DEBUG [org.keycloak.services] (default task-11) >>>> KC-SERVICES0014: Failed client authentication: >>>> org.keycloak.authentication.AuthenticationFlowException: Client was not >>>> identified by any client authenticator >>>> at >>>> org.keycloak.authentication.ClientAuthenticationFlow.processFlow(ClientAuthenticationFlow.java:101) >>>> at >>>> org.keycloak.authentication.AuthenticationProcessor.authenticateClient(AuthenticationProcessor.java:673) >>>> at >>>> org.keycloak.protocol.oidc.utils.AuthorizeClientUtil.authorizeClient(AuthorizeClientUtil.java:42) >>>> at >>>> org.keycloak.protocol.oidc.endpoints.TokenEndpoint.checkClient(TokenEndpoint.java:163) >>>> at >>>> org.keycloak.protocol.oidc.endpoints.TokenEndpoint.build(TokenEndpoint.java:117) >>>> at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source) >>>> at >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> at java.lang.reflect.Method.invoke(Method.java:498) >>>> at >>>> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) >>>> at >>>> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) >>>> at >>>> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) >>>> at >>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) >>>> at >>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107) >>>> at >>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133) >>>> at >>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) >>>> at >>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) >>>> at >>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) >>>> at >>>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) >>>> at >>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) >>>> at >>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) >>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>>> at >>>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) >>>> at >>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) >>>> at >>>> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:88) >>>> at >>>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) >>>> at >>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) >>>> at >>>> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) >>>> at >>>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) >>>> at >>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) >>>> at >>>> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) >>>> at >>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>> at >>>> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) >>>> at >>>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) >>>> at >>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>> at >>>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) >>>> at >>>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) >>>> at >>>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) >>>> at >>>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) >>>> at >>>> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) >>>> at >>>> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) >>>> at >>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>> at >>>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >>>> at >>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>> at >>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>> at >>>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) >>>> at >>>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) >>>> at >>>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) >>>> at >>>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) >>>> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) >>>> at >>>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>>> at java.lang.Thread.run(Thread.java:745) >>>> >>>> 2016-05-24 09:59:26,180 WARN [org.keycloak.events] (default task-11) >>>> type=CODE_TO_TOKEN_ERROR, realmId=master, clientId=admin, userId=null, >>>> ipAddress=192.168.33.1, error=invalid_client_credentials, >>>> grant_type=authorization_code >>>> 2016-05-24 09:59:26,863 DEBUG [org.keycloak.services] (default task-8) >>>> replacing relative valid redirect with: >>>> https://login.vagrant.v8/auth/admin/master/console/* >>>> 2016-05-24 09:59:26,867 DEBUG [org.keycloak.services] (default task-8) >>>> AUTHENTICATE >>>> 2016-05-24 09:59:26,867 DEBUG [org.keycloak.services] (default task-8) >>>> AUTHENTICATE ONLY >>>> 2016-05-24 09:59:26,867 DEBUG [org.keycloak.services] (default task-8) >>>> processFlow >>>> 2016-05-24 09:59:26,868 DEBUG [org.keycloak.services] (default task-8) >>>> check execution: auth-cookie requirement: ALTERNATIVE >>>> 2016-05-24 09:59:26,868 DEBUG [org.keycloak.services] (default task-8) >>>> authenticator: auth-cookie >>>> 2016-05-24 09:59:26,868 DEBUG [org.keycloak.services] (default task-8) >>>> invoke authenticator.authenticate >>>> 2016-05-24 09:59:26,869 DEBUG [org.keycloak.services] (default task-8) >>>> token active - active: true, issued-at: 1,464,083,965, not-before: 0 >>>> 2016-05-24 09:59:26,869 DEBUG [org.keycloak.services] (default task-8) >>>> authenticator SUCCESS: auth-cookie >>>> 2016-05-24 09:59:26,873 DEBUG [org.keycloak.services] (default task-8) >>>> check execution: auth-spnego requirement: DISABLED >>>> 2016-05-24 09:59:26,873 DEBUG [org.keycloak.services] (default task-8) >>>> execution is processed >>>> 2016-05-24 09:59:26,873 DEBUG [org.keycloak.services] (default task-8) >>>> check execution: null requirement: ALTERNATIVE >>>> 2016-05-24 09:59:26,873 DEBUG [org.keycloak.services] (default task-8) >>>> Skip alternative execution >>>> 2016-05-24 09:59:26,874 DEBUG [org.keycloak.events] (default task-8) >>>> type=LOGIN, realmId=master, clientId=security-admin-console, >>>> userId=cf248811-6d82-47e7-bf9a-7b197fb988d0, ipAddress=192.168.33.1, >>>> auth_method=openid-connect, auth_type=code, response_type=code, >>>> redirect_uri=https://login.vagrant.v8/auth/admin/master/console/, >>>> consent=no_consent_required, code_id=8215bbb3-a592-47e0-9c28-c274bccc61b5, >>>> response_mode=fragment, username=admin >>>> 2016-05-24 09:59:26,891 DEBUG [org.keycloak.services] (default task-8) >>>> Create login cookie - name: KEYCLOAK_IDENTITY, path: /auth/realms/master, >>>> max-age: -1 >>>> 2016-05-24 09:59:26,892 DEBUG [org.keycloak.services] (default task-8) >>>> redirectAccessCode: state: ae0d05d7-95d9-40a0-9a75-7e4e4fb7830e >>>> 2016-05-24 09:59:27,472 DEBUG [org.keycloak.services] (default task-11) >>>> AUTHENTICATE CLIENT >>>> 2016-05-24 09:59:27,472 DEBUG [org.keycloak.services] (default task-11) >>>> client authenticator: client-secret >>>> 2016-05-24 09:59:27,474 DEBUG [org.keycloak.services] (default task-11) >>>> client authenticator: client-jwt >>>> 2016-05-24 09:59:27,474 DEBUG [org.keycloak.services] (default task-11) >>>> KC-SERVICES0014: Failed client authentication: >>>> org.keycloak.authentication.AuthenticationFlowException: Client was not >>>> identified by any client authenticator >>>> at >>>> org.keycloak.authentication.ClientAuthenticationFlow.processFlow(ClientAuthenticationFlow.java:101) >>>> at >>>> org.keycloak.authentication.AuthenticationProcessor.authenticateClient(AuthenticationProcessor.java:673) >>>> at >>>> org.keycloak.protocol.oidc.utils.AuthorizeClientUtil.authorizeClient(AuthorizeClientUtil.java:42) >>>> at >>>> org.keycloak.protocol.oidc.endpoints.TokenEndpoint.checkClient(TokenEndpoint.java:163) >>>> at >>>> org.keycloak.protocol.oidc.endpoints.TokenEndpoint.build(TokenEndpoint.java:117) >>>> at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source) >>>> at >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> at java.lang.reflect.Method.invoke(Method.java:498) >>>> at >>>> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) >>>> at >>>> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) >>>> at >>>> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) >>>> at >>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) >>>> at >>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107) >>>> at >>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133) >>>> at >>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) >>>> at >>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) >>>> at >>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) >>>> at >>>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) >>>> at >>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) >>>> at >>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) >>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>>> at >>>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) >>>> at >>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) >>>> at >>>> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:88) >>>> at >>>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) >>>> at >>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) >>>> at >>>> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) >>>> at >>>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) >>>> at >>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) >>>> at >>>> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) >>>> at >>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>> at >>>> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) >>>> at >>>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) >>>> at >>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>> at >>>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) >>>> at >>>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) >>>> at >>>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) >>>> at >>>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) >>>> at >>>> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) >>>> at >>>> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) >>>> at >>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>> at >>>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >>>> at >>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>> at >>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>> at >>>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) >>>> at >>>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) >>>> at >>>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) >>>> at >>>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) >>>> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) >>>> at >>>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>>> at java.lang.Thread.run(Thread.java:745) >>>> >>>> 2016-05-24 09:59:27,478 WARN [org.keycloak.events] (default task-11) >>>> type=CODE_TO_TOKEN_ERROR, realmId=master, clientId=admin, userId=null, >>>> ipAddress=192.168.33.1, error=invalid_client_credentials, >>>> grant_type=authorization_code >>>> 2016-05-24 09:59:28,209 DEBUG [org.keycloak.services] (default task-8) >>>> replacing relative valid redirect with: >>>> https://login.vagrant.v8/auth/admin/master/console/* >>>> 2016-05-24 09:59:28,211 DEBUG [org.keycloak.services] (default task-8) >>>> AUTHENTICATE >>>> 2016-05-24 09:59:28,218 DEBUG [org.keycloak.services] (default task-8) >>>> AUTHENTICATE ONLY >>>> 2016-05-24 09:59:28,218 DEBUG [org.keycloak.services] (default task-8) >>>> processFlow >>>> 2016-05-24 09:59:28,219 DEBUG [org.keycloak.services] (default task-8) >>>> check execution: auth-cookie requirement: ALTERNATIVE >>>> 2016-05-24 09:59:28,219 DEBUG [org.keycloak.services] (default task-8) >>>> authenticator: auth-cookie >>>> 2016-05-24 09:59:28,219 DEBUG [org.keycloak.services] (default task-8) >>>> invoke authenticator.authenticate >>>> 2016-05-24 09:59:28,220 DEBUG [org.keycloak.services] (default task-8) >>>> token active - active: true, issued-at: 1,464,083,966, not-before: 0 >>>> 2016-05-24 09:59:28,222 DEBUG [org.keycloak.services] (default task-8) >>>> authenticator SUCCESS: auth-cookie >>>> 2016-05-24 09:59:28,222 DEBUG [org.keycloak.services] (default task-8) >>>> check execution: auth-spnego requirement: DISABLED >>>> 2016-05-24 09:59:28,222 DEBUG [org.keycloak.services] (default task-8) >>>> execution is processed >>>> 2016-05-24 09:59:28,222 DEBUG [org.keycloak.services] (default task-8) >>>> check execution: null requirement: ALTERNATIVE >>>> 2016-05-24 09:59:28,222 DEBUG [org.keycloak.services] (default task-8) >>>> Skip alternative execution >>>> 2016-05-24 09:59:28,223 DEBUG [org.keycloak.events] (default task-8) >>>> type=LOGIN, realmId=master, clientId=security-admin-console, >>>> userId=cf248811-6d82-47e7-bf9a-7b197fb988d0, ipAddress=192.168.33.1, >>>> auth_method=openid-connect, auth_type=code, response_type=code, >>>> redirect_uri=https://login.vagrant.v8/auth/admin/master/console/, >>>> consent=no_consent_required, code_id=7f9dbb5c-651a-4cc4-a248-91637c354fa5, >>>> response_mode=fragment, username=admin >>>> 2016-05-24 09:59:28,255 DEBUG [org.keycloak.services] (default task-8) >>>> Create login cookie - name: KEYCLOAK_IDENTITY, path: /auth/realms/master, >>>> max-age: -1 >>>> 2016-05-24 09:59:28,256 DEBUG [org.keycloak.services] (default task-8) >>>> redirectAccessCode: state: 89b303fd-f77e-4b23-8de0-2c517304e671 >>>> 2016-05-24 09:59:28,612 DEBUG [org.keycloak.services] (default task-11) >>>> AUTHENTICATE CLIENT >>>> 2016-05-24 09:59:28,612 DEBUG [org.keycloak.services] (default task-11) >>>> client authenticator: client-secret >>>> 2016-05-24 09:59:28,613 DEBUG [org.keycloak.services] (default task-11) >>>> client authenticator: client-jwt >>>> 2016-05-24 09:59:28,614 DEBUG [org.keycloak.services] (default task-11) >>>> KC-SERVICES0014: Failed client authentication: >>>> org.keycloak.authentication.AuthenticationFlowException: Client was not >>>> identified by any client authenticator >>>> at >>>> org.keycloak.authentication.ClientAuthenticationFlow.processFlow(ClientAuthenticationFlow.java:101) >>>> at >>>> org.keycloak.authentication.AuthenticationProcessor.authenticateClient(AuthenticationProcessor.java:673) >>>> at >>>> org.keycloak.protocol.oidc.utils.AuthorizeClientUtil.authorizeClient(AuthorizeClientUtil.java:42) >>>> at >>>> org.keycloak.protocol.oidc.endpoints.TokenEndpoint.checkClient(TokenEndpoint.java:163) >>>> at >>>> org.keycloak.protocol.oidc.endpoints.TokenEndpoint.build(TokenEndpoint.java:117) >>>> at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source) >>>> at >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> at java.lang.reflect.Method.invoke(Method.java:498) >>>> at >>>> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) >>>> at >>>> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) >>>> at >>>> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) >>>> at >>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) >>>> at >>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107) >>>> at >>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133) >>>> at >>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) >>>> at >>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) >>>> at >>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) >>>> at >>>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) >>>> at >>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) >>>> at >>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) >>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>>> at >>>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) >>>> at >>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) >>>> at >>>> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:88) >>>> at >>>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) >>>> at >>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) >>>> at >>>> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) >>>> at >>>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) >>>> at >>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) >>>> at >>>> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) >>>> at >>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>> at >>>> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) >>>> at >>>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) >>>> at >>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>> at >>>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) >>>> at >>>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) >>>> at >>>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) >>>> at >>>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) >>>> at >>>> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) >>>> at >>>> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) >>>> at >>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>> at >>>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >>>> at >>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>> at >>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>> at >>>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) >>>> at >>>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) >>>> at >>>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) >>>> at >>>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) >>>> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) >>>> at >>>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >>>> at >>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>>> at java.lang.Thread.run(Thread.java:745) >>>> >>>> 2016-05-24 09:59:28,614 WARN [org.keycloak.events] (default task-11) >>>> type=CODE_TO_TOKEN_ERROR, realmId=master, clientId=admin, userId=null, >>>> ipAddress=192.168.33.1, error=invalid_client_credentials, >>>> grant_type=authorization_code >>>> 2016-05-24 09:59:28,692 INFO [io.undertow.request.dump] (default >>>> task-11) >>>> ----------------------------REQUEST--------------------------- >>>> URI=/auth/realms/master/protocol/openid-connect/token >>>> characterEncoding=null >>>> contentLength=229 >>>> contentType=[application/x-www-form-urlencoded] >>>> >>>> cookie=KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjdmOWRiYjVjLTY1MWEtNGNjNC1hMjQ4LTkxNjM3YzM1NGZhNSIsImNpZCI6InNlY3VyaXR5LWFkbWluLWNvbnNvbGUiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9hZG1pbi9tYXN0ZXIvY29uc29sZS8iLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiYjg3OTM2Y2ItZTg1OC00NDhlLWJmMTAtNGNkYjQzMDFkMTg2IiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL3JlYWxtcy9tYXN0ZXIiLCJyZXNwb25zZV90eXBlIjoiY29kZSIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL2FkbWluL21hc3Rlci9jb25zb2xlLyIsInN0YXRlIjoiODliMzAzZmQtZjc3ZS00YjIzLThkZTAtMmM1MTczMDRlNjcxIiwibm9uY2UiOiI1MzY0YTRhZS0wNzI3LTQwYWItOWEyMi0yN2ExZDQ5NjVmNTkiLCJyZXNwb25zZV9tb2RlIjoiZnJhZ21lbnQifX0.7Xnk589FgD_9RulKC4V48gn-056yVxa_DdIGm4Hpgj8 >>>> >>>> cookie=KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI5ZjRmNWU3OS02NWYxLTQ0M2ItOGI5YS1hZWI4NzZmYmNkNjIiLCJleHAiOjE0NjQxMTk5NjgsIm5iZiI6MCwiaWF0IjoxNDY0MDgzOTY4LCJpc3MiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9yZWFsbXMvbWFzdGVyIiwic3ViIjoiY2YyNDg4MTEtNmQ4Mi00N2U3LWJmOWEtN2IxOTdmYjk4OGQwIiwic2Vzc2lvbl9zdGF0ZSI6ImQzYjAxY2Q1LWQxNWEtNGQ2OS05MTQ3LWE1YTEzYWI4MjQxNiIsInJlc291cmNlX2FjY2VzcyI6e319.eiDWSR8eeIdX7AKZiWI3e9moUD9ZuD-h88XX31JRMio_FmqSvMgRHcZtkVjjrLnjcmWn7X4jIcITARk-TiywjfAKotkPYodgCyxsmln5LRQeV3SYXltCGWKmsFmq0BsMjQbfstjdR9V9Xh7daiyRNxLGcoYitEEOeKboMjbGwZw11jggaTRifpNYp-M9GtTBvHSJg6RFdmm0QTLeJm9OgOvBzdRlKwGTUcJeqJxuNWgd4XqPS5vbpliDsfuvekC8VFeDB_UGci1hCIEoMy0-tlpwPLP_xGbCd5L8XFKrr0shoGbQlyJjFZB49VtJlHLkd8F15mZQxJ1G9BWj_wKINw >>>> >>>> cookie=KEYCLOAK_SESSION=master/cf248811-6d82-47e7-bf9a-7b197fb988d0/d3b01cd5-d15a-4d69-9147-a5a13ab82416 >>>> header=X-Real-Ip=192.168.33.1 >>>> header=Accept-Encoding=gzip, deflate >>>> header=DNT=1 >>>> header=Origin=https://login.vagrant.v8 >>>> header=X-Forwarded-Port=443 >>>> header=X-Forwarded-For=192.168.33.1 >>>> >>>> header=Cookie=KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjdmOWRiYjVjLTY1MWEtNGNjNC1hMjQ4LTkxNjM3YzM1NGZhNSIsImNpZCI6InNlY3VyaXR5LWFkbWluLWNvbnNvbGUiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9hZG1pbi9tYXN0ZXIvY29uc29sZS8iLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiYjg3OTM2Y2ItZTg1OC00NDhlLWJmMTAtNGNkYjQzMDFkMTg2IiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL3JlYWxtcy9tYXN0ZXIiLCJyZXNwb25zZV90eXBlIjoiY29kZSIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL2FkbWluL21hc3Rlci9jb25zb2xlLyIsInN0YXRlIjoiODliMzAzZmQtZjc3ZS00YjIzLThkZTAtMmM1MTczMDRlNjcxIiwibm9uY2UiOiI1MzY0YTRhZS0wNzI3LTQwYWItOWEyMi0yN2ExZDQ5NjVmNTkiLCJyZXNwb25zZV9tb2RlIjoiZnJhZ21lbnQifX0.7Xnk589FgD_9RulKC4V48gn-056yVxa_DdIGm4Hpgj8; >>>> KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI5ZjRmNWU3OS02NWYxLTQ0M2ItOGI5YS1hZWI4NzZmYmNkNjIiLCJleHAiOjE0NjQxMTk5NjgsIm5iZiI6MCwiaWF0IjoxNDY0MDgzOTY4LCJpc3MiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9yZWFsbXMvbWFzdGVyIiwic3ViIjoiY2YyNDg4MTEtNmQ4Mi00N2U3LWJmOWEtN2IxOTdmYjk4OGQwIiwic2Vzc2lvbl9zdGF0ZSI6ImQzYjAxY2Q1LWQxNWEtNGQ2OS05MTQ3LWE1YTEzYWI4MjQxNiIsInJlc291cmNlX2FjY2VzcyI6e319.eiDWSR8eeIdX7AKZiWI3e9moUD9ZuD-h88XX31JRMio_FmqSvMgRHcZtkVjjrLnjcmWn7X4jIcITARk-TiywjfAKotkPYodgCyxsmln5LRQeV3SYXltCGWKmsFmq0BsMjQbfstjdR9V9Xh7daiyRNxLGcoYitEEOeKboMjbGwZw11jggaTRifpNYp-M9GtTBvHSJg6RFdmm0QTLeJm9OgOvBzdRlKwGTUcJeqJxuNWgd4XqPS5vbpliDsfuvekC8VFeDB_UGci1hCIEoMy0-tlpwPLP_xGbCd5L8XFKrr0shoGbQlyJjFZB49VtJlHLkd8F15mZQxJ1G9BWj_wKINw; >>>> KEYCLOAK_SESSION=master/cf248811-6d82-47e7-bf9a-7b197fb988d0/d3b01cd5-d15a-4d69-9147-a5a13ab82416 >>>> header=Referer= >>>> https://login.vagrant.v8/auth/admin/master/console/ >>>> header=Host=login.vagrant.v8 >>>> header=Accept=*/* >>>> header=Accept-Language=en-US,en;q=0.8,de;q=0.6 >>>> header=X-Original-To=192.168.33.80 >>>> header=User-Agent=Mozilla/5.0 (Windows NT 6.1; WOW64) >>>> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 >>>> header=Authorization=Basic YWRtaW46Y2hhbmdlbWU= >>>> header=X-Forwarded-Proto=https >>>> header=Content-Length=229 >>>> header=Content-Type=application/x-www-form-urlencoded >>>> locale=[en_US, en, de] >>>> method=POST >>>> protocol=HTTP/1.1 >>>> queryString= >>>> remoteAddr=/192.168.33.80:55892 >>>> remoteHost=proxy.vagrant.v8 >>>> scheme=https >>>> host=login.vagrant.v8 >>>> serverPort=443 >>>> --------------------------RESPONSE-------------------------- >>>> contentLength=123 >>>> contentType=application/json >>>> header=X-Powered-By=Undertow/1 >>>> header=Server=WildFly/10 >>>> header=Content-Type=application/json >>>> header=Content-Length=123 >>>> header=Date=Tue, 24 May 2016 09:59:28 GMT >>>> status=400 >>>> >>>> >>>> On Tue, May 24, 2016 at 9:49 PM, Stian Thorgersen >>>> wrote: >>>> >>>>> Did you add ProxyPeerAddressHandler filter? That's required for AJP >>>>> connector, see >>>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#proxy-address-forwarding >>>>> >>>>> On 24 May 2016 at 11:48, Niels Bertram wrote: >>>>> >>>>>> I am scratching my head with a specific setup problem which does not >>>>>> generate any usable error messages. >>>>>> >>>>>> I am running a haproxy as load balancer in a vm in front an apache >>>>>> web server configured as reverse proxy connecting to the keycloak server >>>>>> via ajp in another VM. >>>>>> >>>>>> client browser (192.168.33.1) >>>>>> >>>>>> login.vagrant.v8 (192.168.33.80) aka proxy.vagrant.v8 is >>>>>> haproxy adds X-Forwarded-For X-Forwarded-Port X-Forwarded-Proto >>>>>> and X-Real-Ip >>>>>> >>>>>> kc01.vagrant.v8 (192.168.33.81) apache reverse >>>>>> proxies to wildfly on ajp port >>>>>> >>>>>> >>>>>> Followed all the setup instructions in the documentation and if I >>>>>> connect to apache proxying through to keycloak everything works fine. All >>>>>> web resources are donwloaded fine however when I request a token exchange >>>>>> on /auth/realms/master/protocol/openid-connect/token I get a 400 >>>>>> response. The kc server log shows the corect IP address of the originating >>>>>> client and the request dump from wildfly also shows the correct >>>>>> X-Forwarded-For header coming in. However the query string >>>>>> remoteAddr=/192.168.33.80:54672 which I believe is the one sent to >>>>>> the ajp connector shows some half valid IP address which is that of the >>>>>> load balancer. Did anyone come across this before? Looks like a bug of some >>>>>> sort. >>>>>> >>>>>> The symptom is a endless loop trying to log into the admin panel. >>>>>> >>>>>> Cheers >>>>>> Niels >>>>>> >>>>>> >>>>>> # cat standalone/log/server.log | grep -A 58 '2016-05-24 09:19:27,672' >>>>>> 2016-05-24 09:19:27,672 WARN [org.keycloak.events] (default task-19) >>>>>> type=CODE_TO_TOKEN_ERROR, realmId=master, clientId=admin, userId=null, >>>>>> ipAddress=*192.168.33.1*, error=invalid_client_credentials, >>>>>> grant_type=authorization_code >>>>>> 2016-05-24 09:19:27,673 INFO [io.undertow.request.dump] (default >>>>>> task-19) >>>>>> ----------------------------REQUEST--------------------------- >>>>>> URI=/auth/realms/master/protocol/openid-connect/token >>>>>> characterEncoding=null >>>>>> contentLength=229 >>>>>> contentType=[application/x-www-form-urlencoded] >>>>>> >>>>>> cookie=KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjM5YTVkNTlmLWMyNDYtNDkwZi04ZGZkLTZhYzVhNzgyZDI5ZCIsImNpZCI6InNlY3VyaXR5LWFkbWluLWNvbnNvbGUiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9hZG1pbi9tYXN0ZXIvY29uc29sZS8iLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiOGQ5ZGI4MzctMjY2Ni00NDcxLTk0ZDgtZmFkMmIxMjA3NDQxIiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL3JlYWxtcy9tYXN0ZXIiLCJyZXNwb25zZV90eXBlIjoiY29kZSIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL2FkbWluL21hc3Rlci9jb25zb2xlLyIsInN0YXRlIjoiNTQ4ZDE5ZTUtMjlkMS00NTU2LWFjNjAtYjZjZTM1ZmJiMGU2Iiwibm9uY2UiOiI5OGY3NDFiYS03MmQwLTQ0ZDUtOGQ0ZC1jZTAxNzZhYjMyMmUiLCJyZXNwb25zZV9tb2RlIjoiZnJhZ21lbnQifX0.I0jI4nDhbYtKNrVjdlwjjBe5mtd0a8u6Dm7rQXwLE60 >>>>>> >>>>>> cookie=KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJhNjY5OWJkOS00MWQ4LTQyNWYtYjE5Ni04Y2QzNmJiZjBmNjQiLCJleHAiOjE0NjQxMTc1NjcsIm5iZiI6MCwiaWF0IjoxNDY0MDgxNTY3LCJpc3MiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9yZWFsbXMvbWFzdGVyIiwic3ViIjoiY2YyNDg4MTEtNmQ4Mi00N2U3LWJmOWEtN2IxOTdmYjk4OGQwIiwic2Vzc2lvbl9zdGF0ZSI6IjFiYTljODRlLTBlMzctNGE4Mi1hNDg0LWMyNWQyYzRhODBmYyIsInJlc291cmNlX2FjY2VzcyI6e319.E0vEe9XQJ_6IbDC_TEUfumQCJ0fS1_AOYsHh7svyGp16VC89sH9J1FQuLJfHYFVJlDTcE6o2ktLg0fLw2nLIdLOv-WXMseYr0KzudZveiLy1CZbRoPS9w9vlN-_EuXojiz0ORcyh90keUhqW5tMShccHvEaq_wpXOJQ6ITIglsgUXNhlSuEfpEcBy4CCqKQW98bRQiTKQOtoOfgc-Ez1RHR-7esTw-U22P_H-EMk23jI3nwuYGtqOn4Vvqb4-cHOzdyE_xaVWZxeteNKhU-RexfrMaHx1PSy3T796aY7gIljcqkxra-SA1dbOsRBawwlhJwFtojzBHEs1841gJ4bgg >>>>>> >>>>>> cookie=KEYCLOAK_SESSION=master/cf248811-6d82-47e7-bf9a-7b197fb988d0/1ba9c84e-0e37-4a82-a484-c25d2c4a80fc >>>>>> header=Accept=*/* >>>>>> header=Accept-Language=en-US,en;q=0.8,de;q=0.6 >>>>>> header=Accept-Encoding=gzip, deflate >>>>>> header=DNT=1 >>>>>> header=Origin=https://login.vagrant.v8 >>>>>> header=X-Original-To=192.168.33.80 >>>>>> header=User-Agent=Mozilla/5.0 (Windows NT 6.1; WOW64) >>>>>> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 >>>>>> header=X-Forwarded-Proto=https >>>>>> header=X-Forwarded-Port=443 >>>>>> header=X-Forwarded-For=192.168.33.1 >>>>>> header=Content-Length=229 >>>>>> header=Content-Type=application/x-www-form-urlencoded >>>>>> >>>>>> header=Cookie=KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjM5YTVkNTlmLWMyNDYtNDkwZi04ZGZkLTZhYzVhNzgyZDI5ZCIsImNpZCI6InNlY3VyaXR5LWFkbWluLWNvbnNvbGUiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9hZG1pbi9tYXN0ZXIvY29uc29sZS8iLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiOGQ5ZGI4MzctMjY2Ni00NDcxLTk0ZDgtZmFkMmIxMjA3NDQxIiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL3JlYWxtcy9tYXN0ZXIiLCJyZXNwb25zZV90eXBlIjoiY29kZSIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL2FkbWluL21hc3Rlci9jb25zb2xlLyIsInN0YXRlIjoiNTQ4ZDE5ZTUtMjlkMS00NTU2LWFjNjAtYjZjZTM1ZmJiMGU2Iiwibm9uY2UiOiI5OGY3NDFiYS03MmQwLTQ0ZDUtOGQ0ZC1jZTAxNzZhYjMyMmUiLCJyZXNwb25zZV9tb2RlIjoiZnJhZ21lbnQifX0.I0jI4nDhbYtKNrVjdlwjjBe5mtd0a8u6Dm7rQXwLE60; >>>>>> KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJhNjY5OWJkOS00MWQ4LTQyNWYtYjE5Ni04Y2QzNmJiZjBmNjQiLCJleHAiOjE0NjQxMTc1NjcsIm5iZiI6MCwiaWF0IjoxNDY0MDgxNTY3LCJpc3MiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9yZWFsbXMvbWFzdGVyIiwic3ViIjoiY2YyNDg4MTEtNmQ4Mi00N2U3LWJmOWEtN2IxOTdmYjk4OGQwIiwic2Vzc2lvbl9zdGF0ZSI6IjFiYTljODRlLTBlMzctNGE4Mi1hNDg0LWMyNWQyYzRhODBmYyIsInJlc291cmNlX2FjY2VzcyI6e319.E0vEe9XQJ_6IbDC_TEUfumQCJ0fS1_AOYsHh7svyGp16VC89sH9J1FQuLJfHYFVJlDTcE6o2ktLg0fLw2nLIdLOv-WXMseYr0KzudZveiLy1CZbRoPS9w9vlN-_EuXojiz0ORcyh90keUhqW5tMShccHvEaq_wpXOJQ6ITIglsgUXNhlSuEfpEcBy4CCqKQW98bRQiTKQOtoOfgc-Ez1RHR-7esTw-U22P_H-EMk23jI3nwuYGtqOn4Vvqb4-cHOzdyE_xaVWZxeteNKhU-RexfrMaHx1PSy3T796aY7gIljcqkxra-SA1dbOsRBawwlhJwFtojzBHEs1841gJ4bgg; >>>>>> KEYCLOAK_SESSION=master/cf248811-6d82-47e7-bf9a-7b197fb988d0/1ba9c84e-0e37-4a82-a484-c25d2c4a80fc >>>>>> header=Referer= >>>>>> https://login.vagrant.v8/auth/admin/master/console/ >>>>>> header=Host=login.vagrant.v8 >>>>>> locale=[en_US, en, de] >>>>>> method=POST >>>>>> protocol=HTTP/1.1 >>>>>> queryString= >>>>>> * remoteAddr=/192.168.33.80:54672 * >>>>>> remoteHost=proxy.vagrant.v8 >>>>>> scheme=https >>>>>> host=login.vagrant.v8 >>>>>> serverPort=443 >>>>>> --------------------------RESPONSE-------------------------- >>>>>> contentLength=123 >>>>>> contentType=application/json >>>>>> header=X-Powered-By=Undertow/1 >>>>>> header=Server=WildFly/10 >>>>>> header=Content-Type=application/json >>>>>> header=Content-Length=123 >>>>>> header=Date=Tue, 24 May 2016 09:19:27 GMT >>>>>> status=400 >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> keycloak-user mailing list >>>>>> keycloak-user at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>>>> >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/776ac741/attachment-0001.html From sthorger at redhat.com Wed May 25 08:18:13 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 25 May 2016 14:18:13 +0200 Subject: [keycloak-user] Keycloak token exchange failure behind loadbalancer and reverse proxy In-Reply-To: References: Message-ID: I don't think this will cause us to be non-compliant with other libraries. If client is public we ignore client-secret query param if it's sent. If basic auth header is included we read the client-id and secret from there. I'm pretty sure that if you included a basic auth header with an actually valid client-id it would work. I assume the other OAuth servers you've used don't have the concept of a "public" client, instead they just rely on you setting a bogus secret. On 25 May 2016 at 14:12, Niels Bertram wrote: > I tested Chrome without the plugin and it works fine too. I raised a > ticket with lastpass as I do agree, there is nothing smart about adding > basic auth headers randomly to web requests. > > RE validating basic auth header when client is public, the section 2.3 > in Oauth reads: > > > The authorization server MAY establish a client authentication method > with public clients. However, the authorization server MUST NOT rely > on public client authentication for the purpose of identifying the > client. > > > so I guess it is up to the keycloak project to decide. I have used oauth > clients in the past (specifically JavaScript and iOS ones) that required us > to provide an empty or "insecure" client secret value. The OAuth servers we > connected to never complained about these obviously wrong client > credentials. So may be something to consider to ensure compatibilty with > non-keycloak OAuth libraries. > > Cheers, > Niels > > > > On Wed, May 25, 2016 at 7:20 PM, Stian Thorgersen > wrote: > >> There's something strange going on in your Chrome browser then. It's >> an XMLHttpRequest after all, not sure I'd call including a basic auth >> header with user credentials "smart" ;). Maybe try disabling lastpass >> plugin to check if it's the culprit? >> >> In theory we could ignore basic auth header if client is public and >> client-id query param is included, but then again it's an invalid request >> so we'd be enabling sending strange requests. >> >> On 25 May 2016 at 10:26, Niels Bertram wrote: >> >>> Interesting point Stian. This header seems to be originating from Chrome >>> browser. I am not quite sure why its added but I also run lastpass chrome >>> plugin which may be too smart for its own good. >>> >>> I also just tried the keycloak master realm login on Internet Explorer >>> and Firefox which both work as expected and the http request dumps on the >>> keycloak server show that these 2 browsers do not add the Basic Auth header. >>> >>> I looked at the below specs and I can see that keycloak assumes the >>> Basic Auth header contains the client credentials which it is then trying >>> to validate. >>> >>> http://openid.net/specs/openid-connect-core-1_0.html#TokenRequest >>> https://tools.ietf.org/html/rfc6749#section-2.3.1 >>> https://tools.ietf.org/html/rfc6749#section-4.1.3 >>> >>> Just wondering if keycloak should ignore the Basic Auth header if the >>> client is configured to be public ?? Afterall client_id should be in the >>> post form and sending a password from a user browser would be insecure in >>> any case. >>> >>> Thanks, Niels >>> >>> >>> >>> On Wed, May 25, 2016 at 4:39 PM, Stian Thorgersen >>> wrote: >>> >>>> The message means it's unable to authenticate the client for the code >>>> to token exchange. >>>> >>>> Looking at the request it's a strange one as it looks like you've tried >>>> to login to the admin console then the code to token request for some >>>> reason includes "Authorization=Basic YWRtaW46Y2hhbmdlbWU=" which is >>>> credentials for a user 'admin' with password 'changeme'. Is this being >>>> added by your proxy or something? >>>> >>>> >>>> On 24 May 2016 at 14:41, Niels Bertram wrote: >>>> >>>>> Yes I can confirm the filter is correctly added. I also have all the >>>>> other required settings configured (hopefully correctly). It works reliably >>>>> when I target the apache reverse proxy but only falls appart when I load >>>>> balance through another "hop". I switched on debug on keycloak and can see >>>>> a bit more details of the failure (logs below). I wonder what >>>>> "AuthenticationFlowException: Client was not identified by any client >>>>> authenticator" means. >>>>> >>>>> >>>>> >>>>> >>>> socket-binding="ajp" redirect-socket="proxy-https" enabled="true" /> >>>>> >>>> proxy-address-forwarding="true" redirect-socket="proxy-https" /> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> header-value="WildFly/10"/> >>>>> >>>> header-name="X-Powered-By" header-value="Undertow/1"/> >>>>> >>>> class-name="io.undertow.server.handlers.ProxyPeerAddressHandler" >>>>> module="io.undertow.core" /> >>>>> >>>>> >>>>> >>>>> >>>> default-interface="public" >>>>> port-offset="${jboss.socket.binding.port-offset:0}"> >>>>> ... >>>>> >>>>> >>>>> >>>>> >>>>> ... >>>>> >>>>> >>>>> >>>>> >>>>> 2016-05-24 09:59:26,176 DEBUG [org.keycloak.services] (default >>>>> task-11) AUTHENTICATE CLIENT >>>>> 2016-05-24 09:59:26,176 DEBUG [org.keycloak.services] (default >>>>> task-11) client authenticator: client-secret >>>>> 2016-05-24 09:59:26,179 DEBUG [org.keycloak.services] (default >>>>> task-11) client authenticator: client-jwt >>>>> 2016-05-24 09:59:26,180 DEBUG [org.keycloak.services] (default >>>>> task-11) KC-SERVICES0014: Failed client authentication: >>>>> org.keycloak.authentication.AuthenticationFlowException: Client was not >>>>> identified by any client authenticator >>>>> at >>>>> org.keycloak.authentication.ClientAuthenticationFlow.processFlow(ClientAuthenticationFlow.java:101) >>>>> at >>>>> org.keycloak.authentication.AuthenticationProcessor.authenticateClient(AuthenticationProcessor.java:673) >>>>> at >>>>> org.keycloak.protocol.oidc.utils.AuthorizeClientUtil.authorizeClient(AuthorizeClientUtil.java:42) >>>>> at >>>>> org.keycloak.protocol.oidc.endpoints.TokenEndpoint.checkClient(TokenEndpoint.java:163) >>>>> at >>>>> org.keycloak.protocol.oidc.endpoints.TokenEndpoint.build(TokenEndpoint.java:117) >>>>> at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source) >>>>> at >>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>> at java.lang.reflect.Method.invoke(Method.java:498) >>>>> at >>>>> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) >>>>> at >>>>> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) >>>>> at >>>>> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) >>>>> at >>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) >>>>> at >>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107) >>>>> at >>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133) >>>>> at >>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) >>>>> at >>>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) >>>>> at >>>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) >>>>> at >>>>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) >>>>> at >>>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) >>>>> at >>>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) >>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>>>> at >>>>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) >>>>> at >>>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) >>>>> at >>>>> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:88) >>>>> at >>>>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) >>>>> at >>>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) >>>>> at >>>>> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) >>>>> at >>>>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) >>>>> at >>>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) >>>>> at >>>>> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) >>>>> at >>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>>> at >>>>> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) >>>>> at >>>>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) >>>>> at >>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>>> at >>>>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) >>>>> at >>>>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) >>>>> at >>>>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) >>>>> at >>>>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) >>>>> at >>>>> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) >>>>> at >>>>> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) >>>>> at >>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>>> at >>>>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >>>>> at >>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>>> at >>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>>> at >>>>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) >>>>> at >>>>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) >>>>> at >>>>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) >>>>> at >>>>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) >>>>> at >>>>> io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) >>>>> at >>>>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) >>>>> at >>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >>>>> at >>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>>>> at java.lang.Thread.run(Thread.java:745) >>>>> >>>>> 2016-05-24 09:59:26,180 WARN [org.keycloak.events] (default task-11) >>>>> type=CODE_TO_TOKEN_ERROR, realmId=master, clientId=admin, userId=null, >>>>> ipAddress=192.168.33.1, error=invalid_client_credentials, >>>>> grant_type=authorization_code >>>>> 2016-05-24 09:59:26,863 DEBUG [org.keycloak.services] (default task-8) >>>>> replacing relative valid redirect with: >>>>> https://login.vagrant.v8/auth/admin/master/console/* >>>>> 2016-05-24 09:59:26,867 DEBUG [org.keycloak.services] (default task-8) >>>>> AUTHENTICATE >>>>> 2016-05-24 09:59:26,867 DEBUG [org.keycloak.services] (default task-8) >>>>> AUTHENTICATE ONLY >>>>> 2016-05-24 09:59:26,867 DEBUG [org.keycloak.services] (default task-8) >>>>> processFlow >>>>> 2016-05-24 09:59:26,868 DEBUG [org.keycloak.services] (default task-8) >>>>> check execution: auth-cookie requirement: ALTERNATIVE >>>>> 2016-05-24 09:59:26,868 DEBUG [org.keycloak.services] (default task-8) >>>>> authenticator: auth-cookie >>>>> 2016-05-24 09:59:26,868 DEBUG [org.keycloak.services] (default task-8) >>>>> invoke authenticator.authenticate >>>>> 2016-05-24 09:59:26,869 DEBUG [org.keycloak.services] (default task-8) >>>>> token active - active: true, issued-at: 1,464,083,965, not-before: 0 >>>>> 2016-05-24 09:59:26,869 DEBUG [org.keycloak.services] (default task-8) >>>>> authenticator SUCCESS: auth-cookie >>>>> 2016-05-24 09:59:26,873 DEBUG [org.keycloak.services] (default task-8) >>>>> check execution: auth-spnego requirement: DISABLED >>>>> 2016-05-24 09:59:26,873 DEBUG [org.keycloak.services] (default task-8) >>>>> execution is processed >>>>> 2016-05-24 09:59:26,873 DEBUG [org.keycloak.services] (default task-8) >>>>> check execution: null requirement: ALTERNATIVE >>>>> 2016-05-24 09:59:26,873 DEBUG [org.keycloak.services] (default task-8) >>>>> Skip alternative execution >>>>> 2016-05-24 09:59:26,874 DEBUG [org.keycloak.events] (default task-8) >>>>> type=LOGIN, realmId=master, clientId=security-admin-console, >>>>> userId=cf248811-6d82-47e7-bf9a-7b197fb988d0, ipAddress=192.168.33.1, >>>>> auth_method=openid-connect, auth_type=code, response_type=code, >>>>> redirect_uri=https://login.vagrant.v8/auth/admin/master/console/, >>>>> consent=no_consent_required, code_id=8215bbb3-a592-47e0-9c28-c274bccc61b5, >>>>> response_mode=fragment, username=admin >>>>> 2016-05-24 09:59:26,891 DEBUG [org.keycloak.services] (default task-8) >>>>> Create login cookie - name: KEYCLOAK_IDENTITY, path: /auth/realms/master, >>>>> max-age: -1 >>>>> 2016-05-24 09:59:26,892 DEBUG [org.keycloak.services] (default task-8) >>>>> redirectAccessCode: state: ae0d05d7-95d9-40a0-9a75-7e4e4fb7830e >>>>> 2016-05-24 09:59:27,472 DEBUG [org.keycloak.services] (default >>>>> task-11) AUTHENTICATE CLIENT >>>>> 2016-05-24 09:59:27,472 DEBUG [org.keycloak.services] (default >>>>> task-11) client authenticator: client-secret >>>>> 2016-05-24 09:59:27,474 DEBUG [org.keycloak.services] (default >>>>> task-11) client authenticator: client-jwt >>>>> 2016-05-24 09:59:27,474 DEBUG [org.keycloak.services] (default >>>>> task-11) KC-SERVICES0014: Failed client authentication: >>>>> org.keycloak.authentication.AuthenticationFlowException: Client was not >>>>> identified by any client authenticator >>>>> at >>>>> org.keycloak.authentication.ClientAuthenticationFlow.processFlow(ClientAuthenticationFlow.java:101) >>>>> at >>>>> org.keycloak.authentication.AuthenticationProcessor.authenticateClient(AuthenticationProcessor.java:673) >>>>> at >>>>> org.keycloak.protocol.oidc.utils.AuthorizeClientUtil.authorizeClient(AuthorizeClientUtil.java:42) >>>>> at >>>>> org.keycloak.protocol.oidc.endpoints.TokenEndpoint.checkClient(TokenEndpoint.java:163) >>>>> at >>>>> org.keycloak.protocol.oidc.endpoints.TokenEndpoint.build(TokenEndpoint.java:117) >>>>> at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source) >>>>> at >>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>> at java.lang.reflect.Method.invoke(Method.java:498) >>>>> at >>>>> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) >>>>> at >>>>> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) >>>>> at >>>>> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) >>>>> at >>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) >>>>> at >>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107) >>>>> at >>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133) >>>>> at >>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) >>>>> at >>>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) >>>>> at >>>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) >>>>> at >>>>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) >>>>> at >>>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) >>>>> at >>>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) >>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>>>> at >>>>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) >>>>> at >>>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) >>>>> at >>>>> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:88) >>>>> at >>>>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) >>>>> at >>>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) >>>>> at >>>>> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) >>>>> at >>>>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) >>>>> at >>>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) >>>>> at >>>>> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) >>>>> at >>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>>> at >>>>> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) >>>>> at >>>>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) >>>>> at >>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>>> at >>>>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) >>>>> at >>>>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) >>>>> at >>>>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) >>>>> at >>>>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) >>>>> at >>>>> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) >>>>> at >>>>> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) >>>>> at >>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>>> at >>>>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >>>>> at >>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>>> at >>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>>> at >>>>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) >>>>> at >>>>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) >>>>> at >>>>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) >>>>> at >>>>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) >>>>> at >>>>> io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) >>>>> at >>>>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) >>>>> at >>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >>>>> at >>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>>>> at java.lang.Thread.run(Thread.java:745) >>>>> >>>>> 2016-05-24 09:59:27,478 WARN [org.keycloak.events] (default task-11) >>>>> type=CODE_TO_TOKEN_ERROR, realmId=master, clientId=admin, userId=null, >>>>> ipAddress=192.168.33.1, error=invalid_client_credentials, >>>>> grant_type=authorization_code >>>>> 2016-05-24 09:59:28,209 DEBUG [org.keycloak.services] (default task-8) >>>>> replacing relative valid redirect with: >>>>> https://login.vagrant.v8/auth/admin/master/console/* >>>>> 2016-05-24 09:59:28,211 DEBUG [org.keycloak.services] (default task-8) >>>>> AUTHENTICATE >>>>> 2016-05-24 09:59:28,218 DEBUG [org.keycloak.services] (default task-8) >>>>> AUTHENTICATE ONLY >>>>> 2016-05-24 09:59:28,218 DEBUG [org.keycloak.services] (default task-8) >>>>> processFlow >>>>> 2016-05-24 09:59:28,219 DEBUG [org.keycloak.services] (default task-8) >>>>> check execution: auth-cookie requirement: ALTERNATIVE >>>>> 2016-05-24 09:59:28,219 DEBUG [org.keycloak.services] (default task-8) >>>>> authenticator: auth-cookie >>>>> 2016-05-24 09:59:28,219 DEBUG [org.keycloak.services] (default task-8) >>>>> invoke authenticator.authenticate >>>>> 2016-05-24 09:59:28,220 DEBUG [org.keycloak.services] (default task-8) >>>>> token active - active: true, issued-at: 1,464,083,966, not-before: 0 >>>>> 2016-05-24 09:59:28,222 DEBUG [org.keycloak.services] (default task-8) >>>>> authenticator SUCCESS: auth-cookie >>>>> 2016-05-24 09:59:28,222 DEBUG [org.keycloak.services] (default task-8) >>>>> check execution: auth-spnego requirement: DISABLED >>>>> 2016-05-24 09:59:28,222 DEBUG [org.keycloak.services] (default task-8) >>>>> execution is processed >>>>> 2016-05-24 09:59:28,222 DEBUG [org.keycloak.services] (default task-8) >>>>> check execution: null requirement: ALTERNATIVE >>>>> 2016-05-24 09:59:28,222 DEBUG [org.keycloak.services] (default task-8) >>>>> Skip alternative execution >>>>> 2016-05-24 09:59:28,223 DEBUG [org.keycloak.events] (default task-8) >>>>> type=LOGIN, realmId=master, clientId=security-admin-console, >>>>> userId=cf248811-6d82-47e7-bf9a-7b197fb988d0, ipAddress=192.168.33.1, >>>>> auth_method=openid-connect, auth_type=code, response_type=code, >>>>> redirect_uri=https://login.vagrant.v8/auth/admin/master/console/, >>>>> consent=no_consent_required, code_id=7f9dbb5c-651a-4cc4-a248-91637c354fa5, >>>>> response_mode=fragment, username=admin >>>>> 2016-05-24 09:59:28,255 DEBUG [org.keycloak.services] (default task-8) >>>>> Create login cookie - name: KEYCLOAK_IDENTITY, path: /auth/realms/master, >>>>> max-age: -1 >>>>> 2016-05-24 09:59:28,256 DEBUG [org.keycloak.services] (default task-8) >>>>> redirectAccessCode: state: 89b303fd-f77e-4b23-8de0-2c517304e671 >>>>> 2016-05-24 09:59:28,612 DEBUG [org.keycloak.services] (default >>>>> task-11) AUTHENTICATE CLIENT >>>>> 2016-05-24 09:59:28,612 DEBUG [org.keycloak.services] (default >>>>> task-11) client authenticator: client-secret >>>>> 2016-05-24 09:59:28,613 DEBUG [org.keycloak.services] (default >>>>> task-11) client authenticator: client-jwt >>>>> 2016-05-24 09:59:28,614 DEBUG [org.keycloak.services] (default >>>>> task-11) KC-SERVICES0014: Failed client authentication: >>>>> org.keycloak.authentication.AuthenticationFlowException: Client was not >>>>> identified by any client authenticator >>>>> at >>>>> org.keycloak.authentication.ClientAuthenticationFlow.processFlow(ClientAuthenticationFlow.java:101) >>>>> at >>>>> org.keycloak.authentication.AuthenticationProcessor.authenticateClient(AuthenticationProcessor.java:673) >>>>> at >>>>> org.keycloak.protocol.oidc.utils.AuthorizeClientUtil.authorizeClient(AuthorizeClientUtil.java:42) >>>>> at >>>>> org.keycloak.protocol.oidc.endpoints.TokenEndpoint.checkClient(TokenEndpoint.java:163) >>>>> at >>>>> org.keycloak.protocol.oidc.endpoints.TokenEndpoint.build(TokenEndpoint.java:117) >>>>> at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source) >>>>> at >>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>> at java.lang.reflect.Method.invoke(Method.java:498) >>>>> at >>>>> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) >>>>> at >>>>> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) >>>>> at >>>>> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) >>>>> at >>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) >>>>> at >>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107) >>>>> at >>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133) >>>>> at >>>>> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) >>>>> at >>>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) >>>>> at >>>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) >>>>> at >>>>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) >>>>> at >>>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) >>>>> at >>>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) >>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>>>> at >>>>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) >>>>> at >>>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) >>>>> at >>>>> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:88) >>>>> at >>>>> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) >>>>> at >>>>> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) >>>>> at >>>>> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) >>>>> at >>>>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) >>>>> at >>>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) >>>>> at >>>>> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) >>>>> at >>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>>> at >>>>> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) >>>>> at >>>>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) >>>>> at >>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>>> at >>>>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) >>>>> at >>>>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) >>>>> at >>>>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) >>>>> at >>>>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) >>>>> at >>>>> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) >>>>> at >>>>> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) >>>>> at >>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>>> at >>>>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >>>>> at >>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>>> at >>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >>>>> at >>>>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) >>>>> at >>>>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) >>>>> at >>>>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) >>>>> at >>>>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) >>>>> at >>>>> io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) >>>>> at >>>>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) >>>>> at >>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >>>>> at >>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>>>> at java.lang.Thread.run(Thread.java:745) >>>>> >>>>> 2016-05-24 09:59:28,614 WARN [org.keycloak.events] (default task-11) >>>>> type=CODE_TO_TOKEN_ERROR, realmId=master, clientId=admin, userId=null, >>>>> ipAddress=192.168.33.1, error=invalid_client_credentials, >>>>> grant_type=authorization_code >>>>> 2016-05-24 09:59:28,692 INFO [io.undertow.request.dump] (default >>>>> task-11) >>>>> ----------------------------REQUEST--------------------------- >>>>> URI=/auth/realms/master/protocol/openid-connect/token >>>>> characterEncoding=null >>>>> contentLength=229 >>>>> contentType=[application/x-www-form-urlencoded] >>>>> >>>>> cookie=KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjdmOWRiYjVjLTY1MWEtNGNjNC1hMjQ4LTkxNjM3YzM1NGZhNSIsImNpZCI6InNlY3VyaXR5LWFkbWluLWNvbnNvbGUiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9hZG1pbi9tYXN0ZXIvY29uc29sZS8iLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiYjg3OTM2Y2ItZTg1OC00NDhlLWJmMTAtNGNkYjQzMDFkMTg2IiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL3JlYWxtcy9tYXN0ZXIiLCJyZXNwb25zZV90eXBlIjoiY29kZSIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL2FkbWluL21hc3Rlci9jb25zb2xlLyIsInN0YXRlIjoiODliMzAzZmQtZjc3ZS00YjIzLThkZTAtMmM1MTczMDRlNjcxIiwibm9uY2UiOiI1MzY0YTRhZS0wNzI3LTQwYWItOWEyMi0yN2ExZDQ5NjVmNTkiLCJyZXNwb25zZV9tb2RlIjoiZnJhZ21lbnQifX0.7Xnk589FgD_9RulKC4V48gn-056yVxa_DdIGm4Hpgj8 >>>>> >>>>> cookie=KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI5ZjRmNWU3OS02NWYxLTQ0M2ItOGI5YS1hZWI4NzZmYmNkNjIiLCJleHAiOjE0NjQxMTk5NjgsIm5iZiI6MCwiaWF0IjoxNDY0MDgzOTY4LCJpc3MiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9yZWFsbXMvbWFzdGVyIiwic3ViIjoiY2YyNDg4MTEtNmQ4Mi00N2U3LWJmOWEtN2IxOTdmYjk4OGQwIiwic2Vzc2lvbl9zdGF0ZSI6ImQzYjAxY2Q1LWQxNWEtNGQ2OS05MTQ3LWE1YTEzYWI4MjQxNiIsInJlc291cmNlX2FjY2VzcyI6e319.eiDWSR8eeIdX7AKZiWI3e9moUD9ZuD-h88XX31JRMio_FmqSvMgRHcZtkVjjrLnjcmWn7X4jIcITARk-TiywjfAKotkPYodgCyxsmln5LRQeV3SYXltCGWKmsFmq0BsMjQbfstjdR9V9Xh7daiyRNxLGcoYitEEOeKboMjbGwZw11jggaTRifpNYp-M9GtTBvHSJg6RFdmm0QTLeJm9OgOvBzdRlKwGTUcJeqJxuNWgd4XqPS5vbpliDsfuvekC8VFeDB_UGci1hCIEoMy0-tlpwPLP_xGbCd5L8XFKrr0shoGbQlyJjFZB49VtJlHLkd8F15mZQxJ1G9BWj_wKINw >>>>> >>>>> cookie=KEYCLOAK_SESSION=master/cf248811-6d82-47e7-bf9a-7b197fb988d0/d3b01cd5-d15a-4d69-9147-a5a13ab82416 >>>>> header=X-Real-Ip=192.168.33.1 >>>>> header=Accept-Encoding=gzip, deflate >>>>> header=DNT=1 >>>>> header=Origin=https://login.vagrant.v8 >>>>> header=X-Forwarded-Port=443 >>>>> header=X-Forwarded-For=192.168.33.1 >>>>> >>>>> header=Cookie=KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjdmOWRiYjVjLTY1MWEtNGNjNC1hMjQ4LTkxNjM3YzM1NGZhNSIsImNpZCI6InNlY3VyaXR5LWFkbWluLWNvbnNvbGUiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9hZG1pbi9tYXN0ZXIvY29uc29sZS8iLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiYjg3OTM2Y2ItZTg1OC00NDhlLWJmMTAtNGNkYjQzMDFkMTg2IiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL3JlYWxtcy9tYXN0ZXIiLCJyZXNwb25zZV90eXBlIjoiY29kZSIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL2FkbWluL21hc3Rlci9jb25zb2xlLyIsInN0YXRlIjoiODliMzAzZmQtZjc3ZS00YjIzLThkZTAtMmM1MTczMDRlNjcxIiwibm9uY2UiOiI1MzY0YTRhZS0wNzI3LTQwYWItOWEyMi0yN2ExZDQ5NjVmNTkiLCJyZXNwb25zZV9tb2RlIjoiZnJhZ21lbnQifX0.7Xnk589FgD_9RulKC4V48gn-056yVxa_DdIGm4Hpgj8; >>>>> KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiI5ZjRmNWU3OS02NWYxLTQ0M2ItOGI5YS1hZWI4NzZmYmNkNjIiLCJleHAiOjE0NjQxMTk5NjgsIm5iZiI6MCwiaWF0IjoxNDY0MDgzOTY4LCJpc3MiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9yZWFsbXMvbWFzdGVyIiwic3ViIjoiY2YyNDg4MTEtNmQ4Mi00N2U3LWJmOWEtN2IxOTdmYjk4OGQwIiwic2Vzc2lvbl9zdGF0ZSI6ImQzYjAxY2Q1LWQxNWEtNGQ2OS05MTQ3LWE1YTEzYWI4MjQxNiIsInJlc291cmNlX2FjY2VzcyI6e319.eiDWSR8eeIdX7AKZiWI3e9moUD9ZuD-h88XX31JRMio_FmqSvMgRHcZtkVjjrLnjcmWn7X4jIcITARk-TiywjfAKotkPYodgCyxsmln5LRQeV3SYXltCGWKmsFmq0BsMjQbfstjdR9V9Xh7daiyRNxLGcoYitEEOeKboMjbGwZw11jggaTRifpNYp-M9GtTBvHSJg6RFdmm0QTLeJm9OgOvBzdRlKwGTUcJeqJxuNWgd4XqPS5vbpliDsfuvekC8VFeDB_UGci1hCIEoMy0-tlpwPLP_xGbCd5L8XFKrr0shoGbQlyJjFZB49VtJlHLkd8F15mZQxJ1G9BWj_wKINw; >>>>> KEYCLOAK_SESSION=master/cf248811-6d82-47e7-bf9a-7b197fb988d0/d3b01cd5-d15a-4d69-9147-a5a13ab82416 >>>>> header=Referer= >>>>> https://login.vagrant.v8/auth/admin/master/console/ >>>>> header=Host=login.vagrant.v8 >>>>> header=Accept=*/* >>>>> header=Accept-Language=en-US,en;q=0.8,de;q=0.6 >>>>> header=X-Original-To=192.168.33.80 >>>>> header=User-Agent=Mozilla/5.0 (Windows NT 6.1; WOW64) >>>>> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 >>>>> header=Authorization=Basic YWRtaW46Y2hhbmdlbWU= >>>>> header=X-Forwarded-Proto=https >>>>> header=Content-Length=229 >>>>> header=Content-Type=application/x-www-form-urlencoded >>>>> locale=[en_US, en, de] >>>>> method=POST >>>>> protocol=HTTP/1.1 >>>>> queryString= >>>>> remoteAddr=/192.168.33.80:55892 >>>>> remoteHost=proxy.vagrant.v8 >>>>> scheme=https >>>>> host=login.vagrant.v8 >>>>> serverPort=443 >>>>> --------------------------RESPONSE-------------------------- >>>>> contentLength=123 >>>>> contentType=application/json >>>>> header=X-Powered-By=Undertow/1 >>>>> header=Server=WildFly/10 >>>>> header=Content-Type=application/json >>>>> header=Content-Length=123 >>>>> header=Date=Tue, 24 May 2016 09:59:28 GMT >>>>> status=400 >>>>> >>>>> >>>>> On Tue, May 24, 2016 at 9:49 PM, Stian Thorgersen >>>> > wrote: >>>>> >>>>>> Did you add ProxyPeerAddressHandler filter? That's required for AJP >>>>>> connector, see >>>>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#proxy-address-forwarding >>>>>> >>>>>> On 24 May 2016 at 11:48, Niels Bertram wrote: >>>>>> >>>>>>> I am scratching my head with a specific setup problem which does not >>>>>>> generate any usable error messages. >>>>>>> >>>>>>> I am running a haproxy as load balancer in a vm in front an apache >>>>>>> web server configured as reverse proxy connecting to the keycloak server >>>>>>> via ajp in another VM. >>>>>>> >>>>>>> client browser (192.168.33.1) >>>>>>> >>>>>>> login.vagrant.v8 (192.168.33.80) aka proxy.vagrant.v8 is >>>>>>> haproxy adds X-Forwarded-For X-Forwarded-Port X-Forwarded-Proto >>>>>>> and X-Real-Ip >>>>>>> >>>>>>> kc01.vagrant.v8 (192.168.33.81) apache reverse >>>>>>> proxies to wildfly on ajp port >>>>>>> >>>>>>> >>>>>>> Followed all the setup instructions in the documentation and if I >>>>>>> connect to apache proxying through to keycloak everything works fine. All >>>>>>> web resources are donwloaded fine however when I request a token exchange >>>>>>> on /auth/realms/master/protocol/openid-connect/token I get a 400 >>>>>>> response. The kc server log shows the corect IP address of the originating >>>>>>> client and the request dump from wildfly also shows the correct >>>>>>> X-Forwarded-For header coming in. However the query string >>>>>>> remoteAddr=/192.168.33.80:54672 which I believe is the one sent to >>>>>>> the ajp connector shows some half valid IP address which is that of the >>>>>>> load balancer. Did anyone come across this before? Looks like a bug of some >>>>>>> sort. >>>>>>> >>>>>>> The symptom is a endless loop trying to log into the admin panel. >>>>>>> >>>>>>> Cheers >>>>>>> Niels >>>>>>> >>>>>>> >>>>>>> # cat standalone/log/server.log | grep -A 58 '2016-05-24 >>>>>>> 09:19:27,672' >>>>>>> 2016-05-24 09:19:27,672 WARN [org.keycloak.events] (default >>>>>>> task-19) type=CODE_TO_TOKEN_ERROR, realmId=master, clientId=admin, >>>>>>> userId=null, ipAddress=*192.168.33.1*, >>>>>>> error=invalid_client_credentials, grant_type=authorization_code >>>>>>> 2016-05-24 09:19:27,673 INFO [io.undertow.request.dump] (default >>>>>>> task-19) >>>>>>> ----------------------------REQUEST--------------------------- >>>>>>> URI=/auth/realms/master/protocol/openid-connect/token >>>>>>> characterEncoding=null >>>>>>> contentLength=229 >>>>>>> contentType=[application/x-www-form-urlencoded] >>>>>>> >>>>>>> cookie=KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjM5YTVkNTlmLWMyNDYtNDkwZi04ZGZkLTZhYzVhNzgyZDI5ZCIsImNpZCI6InNlY3VyaXR5LWFkbWluLWNvbnNvbGUiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9hZG1pbi9tYXN0ZXIvY29uc29sZS8iLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiOGQ5ZGI4MzctMjY2Ni00NDcxLTk0ZDgtZmFkMmIxMjA3NDQxIiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL3JlYWxtcy9tYXN0ZXIiLCJyZXNwb25zZV90eXBlIjoiY29kZSIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL2FkbWluL21hc3Rlci9jb25zb2xlLyIsInN0YXRlIjoiNTQ4ZDE5ZTUtMjlkMS00NTU2LWFjNjAtYjZjZTM1ZmJiMGU2Iiwibm9uY2UiOiI5OGY3NDFiYS03MmQwLTQ0ZDUtOGQ0ZC1jZTAxNzZhYjMyMmUiLCJyZXNwb25zZV9tb2RlIjoiZnJhZ21lbnQifX0.I0jI4nDhbYtKNrVjdlwjjBe5mtd0a8u6Dm7rQXwLE60 >>>>>>> >>>>>>> cookie=KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJhNjY5OWJkOS00MWQ4LTQyNWYtYjE5Ni04Y2QzNmJiZjBmNjQiLCJleHAiOjE0NjQxMTc1NjcsIm5iZiI6MCwiaWF0IjoxNDY0MDgxNTY3LCJpc3MiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9yZWFsbXMvbWFzdGVyIiwic3ViIjoiY2YyNDg4MTEtNmQ4Mi00N2U3LWJmOWEtN2IxOTdmYjk4OGQwIiwic2Vzc2lvbl9zdGF0ZSI6IjFiYTljODRlLTBlMzctNGE4Mi1hNDg0LWMyNWQyYzRhODBmYyIsInJlc291cmNlX2FjY2VzcyI6e319.E0vEe9XQJ_6IbDC_TEUfumQCJ0fS1_AOYsHh7svyGp16VC89sH9J1FQuLJfHYFVJlDTcE6o2ktLg0fLw2nLIdLOv-WXMseYr0KzudZveiLy1CZbRoPS9w9vlN-_EuXojiz0ORcyh90keUhqW5tMShccHvEaq_wpXOJQ6ITIglsgUXNhlSuEfpEcBy4CCqKQW98bRQiTKQOtoOfgc-Ez1RHR-7esTw-U22P_H-EMk23jI3nwuYGtqOn4Vvqb4-cHOzdyE_xaVWZxeteNKhU-RexfrMaHx1PSy3T796aY7gIljcqkxra-SA1dbOsRBawwlhJwFtojzBHEs1841gJ4bgg >>>>>>> >>>>>>> cookie=KEYCLOAK_SESSION=master/cf248811-6d82-47e7-bf9a-7b197fb988d0/1ba9c84e-0e37-4a82-a484-c25d2c4a80fc >>>>>>> header=Accept=*/* >>>>>>> header=Accept-Language=en-US,en;q=0.8,de;q=0.6 >>>>>>> header=Accept-Encoding=gzip, deflate >>>>>>> header=DNT=1 >>>>>>> header=Origin=https://login.vagrant.v8 >>>>>>> header=X-Original-To=192.168.33.80 >>>>>>> header=User-Agent=Mozilla/5.0 (Windows NT 6.1; WOW64) >>>>>>> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 >>>>>>> header=X-Forwarded-Proto=https >>>>>>> header=X-Forwarded-Port=443 >>>>>>> header=X-Forwarded-For=192.168.33.1 >>>>>>> header=Content-Length=229 >>>>>>> header=Content-Type=application/x-www-form-urlencoded >>>>>>> >>>>>>> header=Cookie=KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjM5YTVkNTlmLWMyNDYtNDkwZi04ZGZkLTZhYzVhNzgyZDI5ZCIsImNpZCI6InNlY3VyaXR5LWFkbWluLWNvbnNvbGUiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9hZG1pbi9tYXN0ZXIvY29uc29sZS8iLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiOGQ5ZGI4MzctMjY2Ni00NDcxLTk0ZDgtZmFkMmIxMjA3NDQxIiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL3JlYWxtcy9tYXN0ZXIiLCJyZXNwb25zZV90eXBlIjoiY29kZSIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vbG9naW4udmFncmFudC52OC9hdXRoL2FkbWluL21hc3Rlci9jb25zb2xlLyIsInN0YXRlIjoiNTQ4ZDE5ZTUtMjlkMS00NTU2LWFjNjAtYjZjZTM1ZmJiMGU2Iiwibm9uY2UiOiI5OGY3NDFiYS03MmQwLTQ0ZDUtOGQ0ZC1jZTAxNzZhYjMyMmUiLCJyZXNwb25zZV9tb2RlIjoiZnJhZ21lbnQifX0.I0jI4nDhbYtKNrVjdlwjjBe5mtd0a8u6Dm7rQXwLE60; >>>>>>> KEYCLOAK_IDENTITY=eyJhbGciOiJSUzI1NiJ9.eyJqdGkiOiJhNjY5OWJkOS00MWQ4LTQyNWYtYjE5Ni04Y2QzNmJiZjBmNjQiLCJleHAiOjE0NjQxMTc1NjcsIm5iZiI6MCwiaWF0IjoxNDY0MDgxNTY3LCJpc3MiOiJodHRwczovL2xvZ2luLnZhZ3JhbnQudjgvYXV0aC9yZWFsbXMvbWFzdGVyIiwic3ViIjoiY2YyNDg4MTEtNmQ4Mi00N2U3LWJmOWEtN2IxOTdmYjk4OGQwIiwic2Vzc2lvbl9zdGF0ZSI6IjFiYTljODRlLTBlMzctNGE4Mi1hNDg0LWMyNWQyYzRhODBmYyIsInJlc291cmNlX2FjY2VzcyI6e319.E0vEe9XQJ_6IbDC_TEUfumQCJ0fS1_AOYsHh7svyGp16VC89sH9J1FQuLJfHYFVJlDTcE6o2ktLg0fLw2nLIdLOv-WXMseYr0KzudZveiLy1CZbRoPS9w9vlN-_EuXojiz0ORcyh90keUhqW5tMShccHvEaq_wpXOJQ6ITIglsgUXNhlSuEfpEcBy4CCqKQW98bRQiTKQOtoOfgc-Ez1RHR-7esTw-U22P_H-EMk23jI3nwuYGtqOn4Vvqb4-cHOzdyE_xaVWZxeteNKhU-RexfrMaHx1PSy3T796aY7gIljcqkxra-SA1dbOsRBawwlhJwFtojzBHEs1841gJ4bgg; >>>>>>> KEYCLOAK_SESSION=master/cf248811-6d82-47e7-bf9a-7b197fb988d0/1ba9c84e-0e37-4a82-a484-c25d2c4a80fc >>>>>>> header=Referer= >>>>>>> https://login.vagrant.v8/auth/admin/master/console/ >>>>>>> header=Host=login.vagrant.v8 >>>>>>> locale=[en_US, en, de] >>>>>>> method=POST >>>>>>> protocol=HTTP/1.1 >>>>>>> queryString= >>>>>>> * remoteAddr=/192.168.33.80:54672 >>>>>>> * >>>>>>> remoteHost=proxy.vagrant.v8 >>>>>>> scheme=https >>>>>>> host=login.vagrant.v8 >>>>>>> serverPort=443 >>>>>>> --------------------------RESPONSE-------------------------- >>>>>>> contentLength=123 >>>>>>> contentType=application/json >>>>>>> header=X-Powered-By=Undertow/1 >>>>>>> header=Server=WildFly/10 >>>>>>> header=Content-Type=application/json >>>>>>> header=Content-Length=123 >>>>>>> header=Date=Tue, 24 May 2016 09:19:27 GMT >>>>>>> status=400 >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> keycloak-user mailing list >>>>>>> keycloak-user at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/fb05575c/attachment-0001.html From gahealy at redhat.com Wed May 25 09:02:08 2016 From: gahealy at redhat.com (Gareth Healy) Date: Wed, 25 May 2016 14:02:08 +0100 Subject: [keycloak-user] Kerberos token In-Reply-To: <57458FD6.2050608@redhat.com> References: <57458FD6.2050608@redhat.com> Message-ID: Hi Marek, Thanks for the clarification. Cheers. On Wed, May 25, 2016 at 12:43 PM, Marek Posolda wrote: > Hi, > > it seems from the log, that you tried to put Kerberos > (SpnegoAuthenticator) to the directAccessGrant flow, is it correct? This > won't work. The implementation of SpnegoAuthenticator is supposed to work > just for browser based flow when browser is supposed to send HTTP header > with SPNEGO token like "Authorization: Negotiate > your-spnego-kerberos-token" . > > It seems that to avoid similar confusions, we should have some filters (or > authentication subtypes), which will allow to specify which authenticator > is supposed to be used in which flow. I've created JIRA for that > https://issues.jboss.org/browse/KEYCLOAK-3043 . > > If I understand correctly your usecase, you sent username+password to > direct grant authentication and you want Keycloak to verify the given > username+password against Kerberos right? In this case, you can just use > default directGrant flow without any changes. All you need to do is to > check the flag " Use Kerberos For Password Authentication" in the > configuration of your LDAP federation provider. > > Marek > > > > On 23/05/16 17:51, Gareth Healy wrote: > > I am trying to hook up APIMan with KeyCloak using Kerberos and OAuth2. I > am trying to get a token from key cloak using the following URL: > > curl -X POST > http://localhost:29080/auth/realms/freeipa/protocol/openid-connect/token > -H "Content-Type: application/x-www-form-urlencoded" -d "username=admin" > -d 'password=Secret123' -d 'grant_type=password' -d 'client_id=mapper' -d > 'client_secret=027fbd51-135b-47d6-86cd-7ce541b38984' > > > But, get an exception back: > > > 2016-05-23 14:22:25,676 DEBUG [org.keycloak.services] (default task-51) > AUTHENTICATE CLIENT > 2016-05-23 14:22:25,676 TRACE [org.keycloak.services] (default task-51) > Using executions for client authentication: > [de08b32a-a4a5-469c-91cc-0fbca51e1c2f, de3db156-dcc2-4346-bf3a-e56e8e10ed5f] > 2016-05-23 14:22:25,676 DEBUG [org.keycloak.services] (default task-51) > client authenticator: client-secret > 2016-05-23 14:22:25,676 DEBUG [org.keycloak.services] (default task-51) > client authenticator SUCCESS: client-secret > 2016-05-23 14:22:25,676 DEBUG [org.keycloak.services] (default task-51) > Client mapper authenticated by client-secret > 2016-05-23 14:22:25,676 TRACE > [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] > (default task-51) Adding cache operation: ADD on > 7ad60b45-4e69-45a4-a995-ee65d9ee47ae > 2016-05-23 14:22:25,676 TRACE > [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] > (default task-51) Adding cache operation: REPLACE on > 7ad60b45-4e69-45a4-a995-ee65d9ee47ae > 2016-05-23 14:22:25,676 TRACE > [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] > (default task-51) Adding cache operation: REPLACE on > 7ad60b45-4e69-45a4-a995-ee65d9ee47ae > 2016-05-23 14:22:25,676 TRACE > [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] > (default task-51) Adding cache operation: REPLACE on > 7ad60b45-4e69-45a4-a995-ee65d9ee47ae > 2016-05-23 14:22:25,676 TRACE > [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] > (default task-51) Adding cache operation: REPLACE on > 7ad60b45-4e69-45a4-a995-ee65d9ee47ae > 2016-05-23 14:22:25,676 TRACE > [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] > (default task-51) Adding cache operation: REPLACE on > 7ad60b45-4e69-45a4-a995-ee65d9ee47ae > 2016-05-23 14:22:25,676 DEBUG [org.keycloak.services] (default task-51) > AUTHENTICATE ONLY > 2016-05-23 14:22:25,676 TRACE > [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] > (default task-51) Adding cache operation: REPLACE on > 7ad60b45-4e69-45a4-a995-ee65d9ee47ae > 2016-05-23 14:22:25,676 DEBUG [org.keycloak.services] (default task-51) > processFlow > 2016-05-23 14:22:25,676 DEBUG [org.keycloak.services] (default task-51) > check execution: direct-grant-validate-username requirement: REQUIRED > 2016-05-23 14:22:25,676 DEBUG [org.keycloak.services] (default task-51) > authenticator: direct-grant-validate-username > 2016-05-23 14:22:25,676 DEBUG [org.keycloak.services] (default task-51) > invoke authenticator.authenticate > 2016-05-23 14:22:25,676 TRACE > [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] > (default task-51) Adding cache operation: REPLACE on > 7ad60b45-4e69-45a4-a995-ee65d9ee47ae > 2016-05-23 14:22:25,677 TRACE > [org.keycloak.federation.ldap.idm.store.ldap.LDAPIdentityStore] (default > task-51) Using filter for LDAP search: (&(uid=admin)(objectclass=person)) . > Searching in DN: cn=users,cn=accounts,dc=example,dc=test > 2016-05-23 14:22:25,682 TRACE > [org.keycloak.federation.ldap.idm.store.ldap.LDAPIdentityStore] (default > task-51) Found ldap object and populated with the attributes. LDAP Object: > LDAP Object [ dn: uid=admin,cn=users,cn=accounts,dc=example,dc=test , uuid: > afc65b08-1e75-11e6-9645-02420a01010f, attributes: {uid=[admin], > gecos=[Administrator], sn=[Administrator], cn=[Administrator], > createTimestamp=[20160520102908Z], modifyTimestamp=[20160523142225Z]}, > readOnly attribute names: [createtimestamp, modifytimestamp] ] > 2016-05-23 14:22:25,682 TRACE > [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] > (default task-51) Adding cache operation: REPLACE on > 7ad60b45-4e69-45a4-a995-ee65d9ee47ae > 2016-05-23 14:22:25,682 DEBUG [org.keycloak.services] (default task-51) > authenticator SUCCESS: direct-grant-validate-username > 2016-05-23 14:22:25,682 TRACE > [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] > (default task-51) Adding cache operation: REPLACE on > 7ad60b45-4e69-45a4-a995-ee65d9ee47ae > 2016-05-23 14:22:25,682 DEBUG [org.keycloak.services] (default task-51) > check execution: direct-grant-validate-password requirement: DISABLED > 2016-05-23 14:22:25,682 DEBUG [org.keycloak.services] (default task-51) > execution is processed > 2016-05-23 14:22:25,682 DEBUG [org.keycloak.services] (default task-51) > check execution: auth-spnego requirement: ALTERNATIVE > 2016-05-23 14:22:25,682 DEBUG [org.keycloak.services] (default task-51) > authenticator: auth-spnego > 2016-05-23 14:22:25,682 DEBUG [org.keycloak.services] (default task-51) > invoke authenticator.authenticate > 2016-05-23 14:22:25,682 TRACE [org.keycloak.services] (default task-51) > Sending back WWW-Authenticate: Negotiate > 2016-05-23 14:22:25,682 TRACE > [org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider] > (default task-51) Adding cache operation: REPLACE on > 7ad60b45-4e69-45a4-a995-ee65d9ee47ae > 2016-05-23 14:22:25,683 ERROR [io.undertow.request] (default task-51) > UT005023: Exception handling request to > /auth/realms/freeipa/protocol/openid-connect/token: > org.jboss.resteasy.spi.UnhandledException: > java.lang.IllegalArgumentException: RESTEASY003715: path was null > at > org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76) > at > org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212) > at > org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:168) > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:411) > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) > at > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) > at > org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:78) > at > io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) > at > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) > at > io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) > at > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at > org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at > io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at > io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) > at > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) > at > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) > at > io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > at > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.IllegalArgumentException: RESTEASY003715: path was > null > at > org.jboss.resteasy.specimpl.ResteasyUriBuilder.path(ResteasyUriBuilder.java:357) > at > org.keycloak.authentication.AuthenticationProcessor$Result.getActionUrl(AuthenticationProcessor.java:478) > at > org.keycloak.authentication.authenticators.browser.SpnegoAuthenticator.optionalChallengeRedirect(SpnegoAuthenticator.java:137) > at > org.keycloak.authentication.authenticators.browser.SpnegoAuthenticator.challengeNegotiation(SpnegoAuthenticator.java:121) > at > org.keycloak.authentication.authenticators.browser.SpnegoAuthenticator.authenticate(SpnegoAuthenticator.java:65) > at > org.keycloak.authentication.DefaultAuthenticationFlow.processFlow(DefaultAuthenticationFlow.java:183) > at > org.keycloak.authentication.AuthenticationProcessor.authenticateOnly(AuthenticationProcessor.java:789) > at > org.keycloak.protocol.oidc.endpoints.TokenEndpoint.buildResourceOwnerPasswordCredentialsGrant(TokenEndpoint.java:379) > at > org.keycloak.protocol.oidc.endpoints.TokenEndpoint.build(TokenEndpoint.java:125) > at sun.reflect.GeneratedMethodAccessor587.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) > at > org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) > at > org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) > ... 37 more > > > Looking in the code, i can see i am missing the "flowPath", but not sure > where this should be set. > > > > https://github.com/keycloak/keycloak/blob/1.9.x/services/src/main/java/org/keycloak/authentication/authenticators/browser/SpnegoAuthenticator.java#L137 > > > > https://github.com/keycloak/keycloak/blob/1.9.x/services/src/main/java/org/keycloak/authentication/AuthenticationProcessor.java#L476 > > > Can anyone point me in the right direction please. > > -- > Gareth Healy > UKI Middleware Consultant > Red Hat UK Ltd > 200 Fowler Avenue > Farnborough, Hants > GU14 7JP, UK > > Mobile: +44(0)7818511214 > E-Mail: gahealy at redhat.com > > Registered in England and Wales under Company Registration No. 03798903 > > > _______________________________________________ > keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user > > > -- Gareth Healy UKI Middleware Consultant Red Hat UK Ltd 200 Fowler Avenue Farnborough, Hants GU14 7JP, UK Mobile: +44(0)7818511214 E-Mail: gahealy at redhat.com Registered in England and Wales under Company Registration No. 03798903 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/76371277/attachment-0001.html From Kristiaan.Jansen at planonsoftware.com Wed May 25 09:47:16 2016 From: Kristiaan.Jansen at planonsoftware.com (Kristiaan Jansen) Date: Wed, 25 May 2016 15:47:16 +0200 Subject: [keycloak-user] Kc_idp_hint problems Message-ID: <353F9AF5-39A4-42DC-B965-2B107EE13280@planon-fm.com> Hi all I am trying to get the automatically select an identity provider working but having no succes. What I have tried: https://myurl.com?kc_idp_hint=idpalias1 https://myurl.com/index.kees?kc_idp_hint=idpalias1 I am using key cloak 1.9.2 Authenticate by default is off for all identity providers I have 3 identity providers. The effect I am seeing is that I always get the idp selection page. If I enable Authenticate by default for all identity providers it always redirects to the top idp. Has anybody seen this feature work? Thanks, Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/446d45c8/attachment.html From mposolda at redhat.com Wed May 25 10:47:38 2016 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 25 May 2016 16:47:38 +0200 Subject: [keycloak-user] Retrieve Roles-Groups association from LDAP In-Reply-To: References: Message-ID: <5745BB0A.2020308@redhat.com> Hello, It's possible to sync roles to/from LDAP with usage of role mapper and groups with usage of group mapper. However ATM it's not possible to map the group-role membership from LDAP into Keycloak. For example if you have role mapper configured for roles from "ou=roles,dc=example,dc=com" and you have groups mapper for groups from "ou=groups,dc=example,dc=com" . Then you have LDAP group "cn=group1,ou=groups,dc=example,dc=com" which has member "cn=role1,ou=roles,dc=example,dc=com" . Then in keycloak you won't see that group "group1" has role "role1" as it's member. If you have MSAD, you can use "User Roles Retrieve Strategy" value "LOAD_ROLES_BY_MEMBER_ATTRIBUTE_RECURSIVELY" and then the role of user will be visible in Keycloak even if it's available just recursively. For example "cn=role1,ou=roles,dc=example,dc=com" has member "cn=group1,ou=groups,dc=example,dc=com" and the "cn=group1,ou=groups,dc=example,dc=com" has member "cn=myuser,ou=users,dc=example,dc=com" . then in keycloak you will see that user "myuser" is member of "role1". It will be good to support groups-roles relationship though, feel free to create JIRA for that and add your usecase (ideally with some example snippet of your LDAP tree and how exactly you want membership relationship to be visible in Keycloak based on mappings from your LDAP) Thanks, Marek On 24/05/16 13:07, Harits Elfahmi wrote: > Hello guys, > > We're trying to sync roles and groups from LDAP to Keycloak and vice > versa. > If we attach some keycloak roles to a group, can this association be > synced back to LDAP? How should I config my User Federation Mapper for > Group mapper? > > From what I understand we can set the Membership LDAP Attribute, but I > think this is to associate between groups and users, not groups and > roles. Is it possible to do this, or is the group-roles association > can only be configured from keycloak? > > Thanks > -- > Cheers, > * > * > *Harits* Elfahmi > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/970b5b21/attachment.html From john.d.ament at gmail.com Wed May 25 10:51:24 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Wed, 25 May 2016 14:51:24 +0000 Subject: [keycloak-user] Keycloak & Spring Boot Message-ID: Hi, I was trying to follow the tutorial to add keycloak to a simple spring boot app. https://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#spring-boot-adapter It seems like there's a few steps missing. How do I generate the credential used by the spring boot app? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/025f0b5d/attachment.html From haimv at perfectomobile.com Wed May 25 15:52:32 2016 From: haimv at perfectomobile.com (Haim Vana) Date: Wed, 25 May 2016 19:52:32 +0000 Subject: [keycloak-user] How to get specific client role programmatically Message-ID: Hi, I am using the KeyCloak API to create admin users and update their roles, I am able to add to an admin user all the available client roles, however how can I add a specific one ? This is my code to get all the available client roles: userResource.roles().clientLevel(userRealmClientId).listAvailable() How can I get specific one and not all ? Any advice will be appreciated, Haim. The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/c89fd87f/attachment.html From john.d.ament at gmail.com Wed May 25 16:23:46 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Wed, 25 May 2016 20:23:46 +0000 Subject: [keycloak-user] Keycloak, Multitenancy and Dynamic Configuration Message-ID: Hey, So far, Keycloak seems awesome. Kudos to you guys for getting something working so well. I'm curious about using Keycloak for multienancy. It seems like in theory what I'm looking for should work, but wanted to confirm. I have a multitenant app. The app will dynamically create tenants at runtime, so not configuration pre-deployment. If I'm reading correctly, I just need to build a dynamic KeycloakDeployment at runtime. Is it possible to configure this not off of JSON files? Do I just have to call the setter on the various KeycloakDeployment methods? John -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/481a5588/attachment-0001.html From watson409 at gmail.com Wed May 25 19:23:27 2016 From: watson409 at gmail.com (Brian Watson) Date: Wed, 25 May 2016 19:23:27 -0400 Subject: [keycloak-user] Management of compromising bug tickets Message-ID: Hey all, I love the fact that your backlog is very transparent, and that I can see a list of all tasks completed for a given release. However, I was wondering how you handle tasks for compromising bugs? For instance, one could look in the backlog for a bug that states "If you send '123' to the master realm token endpoint at precisely 6:59am on a Tuesday, and you will be granted an admin token! Please Fix!", and use that information to gain access to the systems of those using Keycloak. Thank you in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160525/dfe6f680/attachment.html From jessec at stytch.com Wed May 25 20:15:45 2016 From: jessec at stytch.com (Jesse Chahal) Date: Wed, 25 May 2016 17:15:45 -0700 Subject: [keycloak-user] How to apply updates to keycloak instances In-Reply-To: References: <87CBA013-76D9-4A1D-B64D-70FF432D8720@smartling.com> <097F53B6-6373-4E88-BF9F-8E1808B6295E@smartling.com> Message-ID: @Stian The approach described sounds similar to liquibase to me but with json and specific to keycloak. I feel like a lot of possible bugs could arise from this approach or at least quite a few feature requests. Would each json file only contain a single change? Would order matter in how they get applied if you put a bunch of json files in this directory at once? Can the same file be applied multiple times? These are the kind of issues I would expect to come up with this type of change management system. When I mentioned write our own tool/script to do it I was kind of thinking of a writing a liquibase like system that calls keycloak's rest api. @ Scott If I would compare the solution you mentioned to one of the options I listed in my original question "I've also considered writing my own updater tool using a scripting language (python/ruby) that calls keycloak's rest api." The worrying thing to me is that there is another piece of code that needs to maintained by our company and requires quite a bit of knowledge of keycloak's rest api. There would probably need to be some serious thought put into the architecture of the tool as well. Without a doubt it does provide the most control. We also live by a different methodology in regards to updating production clusters. From our perspective it is more of an issue to update manually as it becomes much easier to miss a step or in someway screw up if steps are performed manually. I'm not sure what the security implications would be from it occurring automatically, especially if during each step there is thorough testing (including from a security team). For our CI/CD pipeline our goal is to have it so every commit can automagically end up on production without human intervention. Currently we use a combination of an initial realm file to be included on startup and also use jq to modify the keycloak-server.json for new keycloak clusters. We don't need to generate realm or client keys as it is included in the initial realm file. That doesn't work for existing systems backed by a database that cannot be thrown away. That kind of leave me with the original option (and hardest) of "write a proprietary liquibase like system built ontop of keycloaks rest api". This is a hard problem to solve On Mon, May 23, 2016 at 1:49 PM, Anthony Fryer wrote: > Thanks, I'll check it out. > > > On 05:38, Tue, 24/05/2016 Scott Rossillo wrote: >> >> We use Jose4J[0] to create the keys and then jq[1] to modify the realm >> file. >> >> See the first line of code here for a super simple example of how to >> generate realm keys: >> https://bitbucket.org/b_c/jose4j/wiki/JWT%20Examples >> >> PS - this may be doable with Keycloak but Jose4J is very lightweight for >> writing a simple script on a CI server. >> >> [0]: https://bitbucket.org/b_c/jose4j >> [1]: https://stedolan.github.io/jq/ >> >> >> Scott Rossillo >> Smartling | Senior Software Engineer >> srossillo at smartling.com >> >> On May 21, 2016, at 10:20 PM, Anthony Fryer >> wrote: >> >> Hi Scott, >> >> How do you generate the realm keys when creating the new keycloak dev >> instances? Do you use a keycloak api or some other way? I'm interested in >> having a standard realm template that is used to create new realms but would >> need to change the realm keys when importing this template into keycloak. >> >> Cheers, >> >> Anthony >> >> On Sat, May 21, 2016 at 3:43 AM, Scott Rossillo >> wrote: >>> >>> We?re using Keycloak on production, stage/QA, development environments >>> and every developer?s workstation / laptop. >>> >>> While there will always be differing options on how to successfully do >>> change management, we?ve found a very effective method for handling Keycloak >>> provisioning in all environments so that developers don?t need to mess >>> around with. We?re a continuous integration / deployment shop using micro >>> services and everything has to ?just work? ? I?ll give an overview of our >>> process here but please keep in mind a few things: >>> >>> 1. This approach works for us, I?m not saying it?s the best way >>> 2. We do _not_ allow production config changes to be automated due to >>> security implications >>> 3. We're very opinionated in our approach to configuration management and >>> we don?t ever modify 3rd party software databases directly. We always use >>> APIs. >>> >>> We deploy Keycloak to all environments using Docker images. On developer >>> workstations we use Docker Compose to orchestrate bringing up all services a >>> developer may need, including Keycloak. >>> >>> We have 4 docker images for Keycloak: >>> - Keycloak Base >>> \- Keycloak HA >>> \- Keycloak Dev >>> - Keycloak config manager* >>> >>> The base image includes all customizations necessary to bring up a >>> Keycloak instance configured with our modules and themes installed. >>> The HA instance builds off base and configures Keycloak to run as a >>> cluster node. This is used on stage and prod. >>> The dev instance builds off base and includes our realm file. On startup, >>> this instance loads our realm configuration if it?s not already loaded. >>> >>> All docker images are built and published by the CI server and Keycloak >>> HA can be deployed to stage and prod after a clean CI build. >>> >>> Developers are free to add clients for testing, do whatever they want, >>> etc. to their running dev instance. If they want to get back to our stock >>> build, they pull the latest Docker image from our private Docker repo and >>> restart it. >>> >>> Adding clients to stage and prod requires approval and is done by a hand. >>> This is for security reasons. Once a configuration change is detected on >>> stage - say a client is added - our CI server exports the realm from stage, >>> changes the realm keys, and creates a new Keycloak Dev instance with the >>> updated realm file. >>> >>> *A word about configuration management: >>> >>> Obviously, the realm file we generate knows the URLs of staging services, >>> not local or development environment URLs. To overcome this we introduced >>> another Docker based service called the Keycloak configuration manger. It >>> runs on development environments and workstations. It?s responsible for >>> discovering running services and updating Keycloak via its admin endpoints >>> to reflect the proper configuration for the given environment. >>> >>> That?s it. The whole process is automated with the exception of >>> configuration changes to stage and prod which require a security review. >>> >>> Hope this helps. Let me know if you?d like me to elaborate on anything. >>> >>> Best, >>> Scott >>> >>> Scott Rossillo >>> Smartling | Senior Software Engineer >>> srossillo at smartling.com >>> >>> On May 20, 2016, at 1:46 AM, Stian Thorgersen >>> wrote: >>> >>> Firstly, just wanted to highlight that core Keycloak team are devs, not >>> sysadmins/ops guys, so we have limited experience in continuous delivery and >>> maintenance of real production systems. Hence, we'd love input from the >>> community on this. >>> >>> As it stands we don't really have a proper solution. I believe the best >>> you can do at the moment is either using import feature, partial import or >>> admin rest endpoints. Import is not going to work IMO as it requires >>> re-creating the whole realm. Partial import may work, but would work best >>> for new resources rather than modifying existing resources as it does a >>> delete/create operation rather than attempt to modify. With the admin rest >>> endpoints you'd get the best control of what's going on, but obviously that >>> leaves a fair amount of the work. >>> >>> In the future we have an idea of introducing an "import directory" it >>> would be possible to drop json files in here that would add, modify or >>> delete resources (realms, clients, roles, users, whatever). This would allow >>> dropping json files before the server starts and the server would then >>> import on startup. It would also be possible to do this at runtime and new >>> files would be detected at runtime. Finally, we also had an idea of an >>> offline mode to run import of this (it would basically start the server >>> without http listener, import files, then stop, so it could be used in a >>> script/tool). Import is probably not the best name for it, as it would >>> support modify and delete as well as "importing" new things. >>> >>> On 19 May 2016 at 19:53, Jesse Chahal wrote: >>>> >>>> Following some of the best practices for continuous Integration and >>>> continuous delivery there needs to be environments for build, test, >>>> and production. This would mean that following these practices would >>>> require you to have multiple versions of keycloak at different stages >>>> of development cycle. Some of these environments might not have >>>> important persistent data while others might. In order to have builds >>>> transition from one environment to another there may be configuration >>>> changes required for a build to be valid. This is especially true when >>>> new services (openid clients) are being added or "default" accounts. >>>> I'm trying to come up with a scripted way of updating keycloak >>>> instances that are backed up by an RDMS. This may include adding new >>>> clients, adding new users, updating realm config, etc... Originally I >>>> was planning on simply exporting the realm config and importing it >>>> every time keycloak starts. If I enabled the OVERWRITE option I might >>>> overwrite things that I do not want overridden. This is especially >>>> true if there is some config that differ's based on whether it is a >>>> build, test, or production instance. If I don't enable it then it is >>>> only useful for new/blank keycloak environments. I considered using >>>> liquibase but since I do not have control of schema changes created by >>>> the keycloak team I might run into issues with my liquibase file not >>>> being valid after a migration/liquibase update by the keycloak team as >>>> my liquibase file would run after keycloak's does. There might also be >>>> some other unknown issues our liquibase changes conflicting somehow >>>> with keycloak's liquibase changes. I've also considered writing my own >>>> updater tool using a scripting language (python/ruby) that calls >>>> keycloak's rest api. The issues with this mechanism is it feels like I >>>> am recreating the wheel as well as not being able to find good >>>> documentation on keycloak's openid endpoints/url's used for different >>>> oauth2 flows. Even if I did find this documentation it would also >>>> require me to find a good openid client for the scripting language. >>>> This doesn't matter for our normal clients as they simply use the >>>> keycloak subsystems and adapters instead. I've also looked at commonly >>>> used server configuration software such as chef, puppet, and ansible. >>>> I don't see a good solution using any of those tools yet either. What >>>> have other people done for cases like this? Please don't tell me there >>>> is someone who is doing this all manually because that doesn't work in >>>> modern software development. >>>> >>>> - doesn't accidentally delete users >>>> - doesn't accidentally delete clients >>>> - doesn't invalidate sessions (optional) >>>> - works to bring up new, correctly configured, keycloak instances >>>> - handles applying updates to existing keycloak instances >>>> - can handle minor differences between keycloak instances (build, >>>> test, production) when updating >>>> - preferably can work well in rolling deployment scenario's. >>>> -- I hope the keycloak team is taking these into consideration when >>>> doing database migration between 1-2 releases. It would be nice if >>>> they set some specific rules for rolling updates between versions (aka >>>> backwards breaking changes) >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >>> >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> >> > From jessec at stytch.com Wed May 25 20:25:17 2016 From: jessec at stytch.com (Jesse Chahal) Date: Wed, 25 May 2016 17:25:17 -0700 Subject: [keycloak-user] Schedule background jobs as user In-Reply-To: References: Message-ID: I did not look at the example but as you can see from the end of the last email we would very much like to not redirect the user back to the login screen. I assumed this was a possible way of getting an offline_token already as it would be comparable to other applications using similar protocols asking for elevated permissions. Usually those other applications would be using an external identity provider. This starts to reduce the native feel of the authentication system (keycloak) + the application. Our application is a 1st party app (meaning keycloak+app should appear to be a single app) and our UX team is very much against the experience provided by requiring reauthentication to schedule background jobs with ourselves. On Tue, May 24, 2016 at 10:01 PM, Stian Thorgersen wrote: > Did you look at the offline-access-app from our examples? You could use > regular login with the adapters, but when the application needs an offline > token and doesn't already have one direct the user to the login and include > ?scope=offline_access. If the user is already authenticated and the client > doesn't require consent no login page will be displayed. > > On 20 May 2016 at 19:42, Jesse Chahal wrote: >> >> Thanks for the info, looks like I was on the right path. After reading >> through the OpenID spec I came across offline tokens and saw that it >> was supported by keycloak. I was trying to figure out how to use >> offline tokens with the adapter (since it didn't seem possible to set >> a flag to enable the scope for this) but based on the above it isn't >> possible. Is it possible for a client to request an offline token >> using a refresh or access token? The reason I ask is because we cannot >> request it using the adapter system that we are currently using. Even >> if we could with the adapter system that would mean that for every >> single login we would be requesting a offline token instead of a >> refresh token (seems like a bad idea). It also seems like a good idea >> to only request the offline_token if a user decides to schedule a >> offline job with us. We would prefer not having to have the user login >> again in order to schedule an offline job. I did some initial tests >> using a rest client and it did not seem possible. >> >> On Thu, May 19, 2016 at 10:34 PM, Stian Thorgersen >> wrote: >> > This is exactly what offline tokens where created to do. The offline >> > token >> > is not linked to user sessions so it doesn't matter if users login or >> > not. >> > Our adapters doesn't support it properly though so you'd need to create >> > a >> > filter or something that sets up the context and principle based on the >> > offline token. >> > >> > On 19 May 2016 at 19:56, Jesse Chahal wrote: >> >> >> >> So we've done a lot of work on our migration to keycloak but still >> >> have a few holes that are using another authentication system. We are >> >> using Wildfly10 along with the keycloak subsystem. The last real >> >> blocking issues is trying to schedule background tasks on behalf of a >> >> user using quartz. We've tried using impersonation role and mocking >> >> out the impersonation workflow that a browser does, it was fairly >> >> complicated and did not work very well. Service accounts don't seem to >> >> fit this scenario either as service accounts seem to be for performing >> >> client specific actions. We considered storing offline token's on >> >> behalf of users but the thing is users might not log in for years >> >> after scheduling their job. We need to set the Context and Principle >> >> to be the user who we are performing background tasks on behalf of. Is >> >> there a recommended way of doing this that has been tested by others? >> >> I'm sure we aren't the only company who schedule tasks on behalf of >> >> users. >> >> _______________________________________________ >> >> keycloak-user mailing list >> >> keycloak-user at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > >> > > > From thomas.raehalme at aitiofinland.com Thu May 26 00:27:30 2016 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Thu, 26 May 2016 07:27:30 +0300 Subject: [keycloak-user] Keycloak, Multitenancy and Dynamic Configuration In-Reply-To: References: Message-ID: Hi! I did a PoC where I first loaded a template from a generic keycloak.json. Then before actually building the KeycloakDeployment I applied tenant specific changes. Mainly I set tenant specific values for identifiers such as the realm name, keys and secrets. I used the set methods as you presumed. Finally I created a separate KeycloakDeployment for each tenant. This was all part of the KeycloakConfigResolver implementation. Best regards, Thomas On May 25, 2016 23:25, "John D. Ament" wrote: > Hey, > > So far, Keycloak seems awesome. Kudos to you guys for getting something > working so well. > > I'm curious about using Keycloak for multienancy. It seems like in theory > what I'm looking for should work, but wanted to confirm. I have a > multitenant app. The app will dynamically create tenants at runtime, so > not configuration pre-deployment. If I'm reading correctly, I just need to > build a dynamic KeycloakDeployment at runtime. Is it possible to configure > this not off of JSON files? Do I just have to call the setter on the > various KeycloakDeployment methods? > > John > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160526/c73a4c07/attachment-0001.html From sthorger at redhat.com Thu May 26 01:46:50 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 26 May 2016 07:46:50 +0200 Subject: [keycloak-user] Keycloak OAuth High CPU usage In-Reply-To: References: Message-ID: Again, CPU load is expected to be high while having 20 threads send as many requests as they can. It's the total throughput that matters here. There are loads of tuning you can do, but you should be able to get decent numbers without any tuning. On 26 May 2016 at 07:09, Vaibhav Naldurgkar < vaibhav_naldurgkar at persistent.com> wrote: > I still wondering what odd configuration I am following on my RHEL VM > which is not sustaining few user request when checked from the output of > top command. Could you please suggest if there are any Java specific > parameters needs to be tuned for performance improvement. If needed I will > share my configuration files for reference. > > > > Below is the screenshot of top output during one of the load test. > > > > > > > > > > *Thanks, Vaibhav* > > > > > > > > > > > > *From:* Stian Thorgersen [mailto:sthorger at redhat.com] > *Sent:* Wednesday, May 25, 2016 12:40 PM > *To:* Vaibhav Naldurgkar > *Cc:* Herzberg, Manuel; keycloak-user at lists.jboss.org > > *Subject:* Re: [keycloak-user] Keycloak OAuth High CPU usage > > > > I did some tests with Linux VM when investigating how Keycloak scales. I > had Keycloak running on a VM that was permitted 50% of a single core and > had a throughput of 50 scenarios. Where a scenario includes a login > request, a code to token request and a logout request. In our performance > lab with a single node and a not particularly beefy machine we're seeing > 150+ scenarios/second. > > > > On 24 May 2016 at 16:05, Vaibhav Naldurgkar < > vaibhav_naldurgkar at persistent.com> wrote: > > Hello, > > > > What are the tests results on a Linux VM ? I just done same jmeter tests > on AWS m4.xlarge instance; however far behind than the laptop tests results. > > @Stian ? have you done tests using Linux VM ? > > > > > > Thanks, Vaibhav > > > > *From:* Herzberg, Manuel [mailto:manuel.herzberg at atos.net] > *Sent:* Tuesday, May 24, 2016 5:52 PM > *To:* stian at redhat.com; Vaibhav Naldurgkar > *Cc:* keycloak-user at lists.jboss.org > *Subject:* RE: [keycloak-user] Keycloak OAuth High CPU usage > > > > Hello, > > I am evaluating the Keycloak performance. Here my practical experience. My > scenario is the same as Vaibhav?s: > > > > ? Large amount of token have to be generated. This is done by > requesting the Keycloak token REST endpoint via http. The different realms > I am using have 1k 2k 3k and 4k keys for signing the tokens. (RSA) Longer > keys result to longer runtime to generate these tokens. > > > > ? I have more than 10k user each realm. Each request includes a > new user. > Requests look like this: > host1:8080/auth/realms/demo-3072/protocol/openid-connect/token/ > with data: > > username=testuser1&password=password&client_id=customer-portal&grant_type=password > > > > ? The response includes 3 tokens(access, refresh and id). In > total more than 30 000 token have to be generated and signed. > > > > @Stian. You wrote you are able to invoke 10000 token refreshes in under 60 > seconds. A token refresh includes access, refresh and id token right? Can > you explain us your scenario? How do you get such a high number? > > Some more results: just signing 3000 Token (800 Byte each) with a 2k key > takes me 20 seconds (laptop i5-4310U, 12gb ram). I am doing this outside > Keycloak with my own java program, but with the same implementation > Keycloak is using. (sign() method in RSAProvider). > > The Keycloak implementation is signing tokens with RSA. HMAC and ECC are > implemented as well as I saw in the code. Changing from RSA to HMAC or ECC > is not possible in current release as i experienced. Are there plans to > provide this in future? Defining this in a configuration file or via > parameters would be nice. > > Best regards, Manuel Herzberg > > > > > > *From:* keycloak-user-bounces at lists.jboss.org [ > mailto:keycloak-user-bounces at lists.jboss.org > ] *On Behalf Of *Stian Thorgersen > *Sent:* Tuesday, May 24, 2016 8:31 AM > *To:* Vaibhav Naldurgkar > *Cc:* keycloak-user at lists.jboss.org > *Subject:* Re: [keycloak-user] Keycloak OAuth High CPU usage > > > > > > > > On 23 May 2016 at 10:02, Vaibhav Naldurgkar < > vaibhav_naldurgkar at persistent.com> wrote: > > Yes, the direct access grant is ON for this client. I am trying to > understand what you mean by ?not planning on using web based flow?? Could > you provide more clarification on this. > > > > If you are planning to do the web based flow (authorization code grant > flow) you should test with that rather than direct grant. That being said > the direct grant should still perform as well. > > > > > > This is what the scenario I am trying to execute and still have high CPU > usages for KeyCloak Java process. > > > > ? The end point URL > /auth/realms/master/protocol/openid-connect/token has been called by Jmeter > for 20 concurrent users per seconds to generate the tokens. > > ? Even if used with crul command like ?*curl -X POST -d > "=admin&password=admin&password&client_id=HelloTest&grant_type=password" > http://localhost:8080/auth/realms/master/protocol/openid-connect/token > *? > , in this case also the CPU utilizations goes around 100%. > > ? After around 3 seconds of the test, in the output of top > command on the KeyCloak server the CPU% for keycloak java process goes > beyond 100%. > > > > Would it be possible for you to have a quick call for faster fix of this > issue. This performance issue is holding to move KeyCloak to use as OAuth > provider. If any other way is convenient for you please let me know for > further discussion. > > > > Your JMeter test is using 20 concurrent threads to send as many requests > to the direct grant api as it can. This will obviously cause Keycloak to > consume a high percentage of the CPU. Especially if you are running > everything on localhost as the network isn't going to be a bottleneck. > Neither will the database as Keycloak caches everything in memory. The > bottleneck will be the CPU. > > > > Authenticating users and obtaining a token requires password hashing as > well as signing tokens, both are mainly CPU intensive. As you are using the > direct grant api there's also less network traffic. > > > > You need to add some reports to your JMeter test so you can see how many > requests Keycloak can handle. That way you can find out how many users can > be authenticated per-second on your machine. > > > > If you only have 500 users remember they won't all login at the same time > (seconds). Even if they all login at 9am sharp they will be spread out over > 10 minutes or so, which would only be 1.2 logins/second. > > > > > > Thanks, Vaibhav > > > > > > > > > > *From:* Stian Thorgersen [mailto:sthorger at redhat.com] > *Sent:* Monday, May 23, 2016 12:01 PM > > > *To:* Vaibhav Naldurgkar > *Cc:* keycloak-user at lists.jboss.org > *Subject:* Re: [keycloak-user] Keycloak OAuth High CPU usage > > > > You are using direct grant to authenticate a user and obtain a token in > the example above. This authenticates and creates a new session for each > request. Are you not planning on using web based flow? > > > > What do you have password hashing intervals set to? Verifying password is > CPU intensive, more than signing tokens. > > > > It shouldn't matter that user is stored in RedHat IdM as the user would be > cached in Keycloak after first authentication, but it may be an idea to > just double check by trying to authenticate to a user in Keycloak and not > RH IdM. > > > > What results are you actually getting? > > > > > > > > On 20 May 2016 at 11:27, Vaibhav Naldurgkar < > vaibhav_naldurgkar at persistent.com> wrote: > > Hi Stian, > > > > After reading your tests results of 10000 token refreshes in under 60 > seconds on your laptop, I am sure I am not following correct configuration > and the documents are missing for reference. > > > > Could you please verify the below steps along with the screen-shots for > the steps which I am following for the adding client and testing the Load > performance using Jmeter. Please suggest if any changes are needed in the > client configuration. In this case we are obtaining the token for user from > KeyCloak. > > > > In my case the user have been stored on RedHat IdM which has been > federated using KeyCloak. > > > > > > Step 1. Create new client called ?LoadTest? , use the Client Protocol as > ?Openid-connect?. > > Used all defaults values post save of the client action. > > > > Step 2. Start the load tests using Jmeter and using the path as > *?/auth/realms/master/protocol/openid-connect/token?* . Used 20 Number of > Threads and used Post method. > > > > > > Below is the screen-shot for the step 1 related to Add Client. > > > > > > > > > > Below is the screen shot for the load test using Jmeter. In this case the > Client ID was used as HelloTest. > > > > > > > > Http requests. > > > > > > > > Thanks, Vaibhav > > > > > > *From:* Stian Thorgersen [mailto:sthorger at redhat.com] > *Sent:* Friday, May 20, 2016 1:01 PM > > > *To:* Vaibhav Naldurgkar > *Cc:* keycloak-user at lists.jboss.org > *Subject:* Re: [keycloak-user] Keycloak OAuth High CPU usage > > > > Can you please elaborate a bit more on how your are testing scenario is? > I'm a bit confused to what you are testing when you are talking about > generating new tokens. Are you using OIDC or SAML? Are you talking about > code->token exchanges, refresh token requests, or what? > > > > To test if your hardware is capable to deal with the load you need to test > logins (verifying passwords are CPU intensive) as well as obtaining tokens > (both code->token, done after login, and refreshing token, done ~1 min or > so by active users, but most users won't continuously use the application). > > > > 500 users should be no problem at all. As an example with a single thread > (which will use a single core) I could invoke 10000 token refreshes in > under 60 seconds on my laptop. So a single core on my laptop should be able > to handle 500 users. > > > > On 20 May 2016 at 08:00, Vaibhav Naldurgkar < > vaibhav_naldurgkar at persistent.com> wrote: > > Hi Stian, > > Thank you for your reply. > > > > The new tokens needs to be generated for each user, which is needed from > security point of view. The performance tests were also conducted using > single Admin user and token for admin user; however in that case the > performance was not good. In between 15th to 20th admin token access > requests ? the CPU usage of keycloak Java process was crossing 90 to 120% > mark. > > > > > > As you have mentioned, Creating tokes are expected to be a bit CPU > intensive ? what should be the server configuration in terms of CPU to deal > with more than 500 users to use keycloak as OAuth provider. > > > > > > Thanks, Vaibhav > > > > > > > > *From:* Stian Thorgersen [mailto:sthorger at redhat.com] > *Sent:* Thursday, May 19, 2016 6:28 PM > *To:* Vaibhav Naldurgkar > *Cc:* keycloak-user at lists.jboss.org > *Subject:* Re: [keycloak-user] Keycloak OAuth High CPU usage > > > > Creating tokes are expected to be a bit CPU intensive as they need to be > signed. When you say you try to generate tokens for 10-20 users are you > doing performance tests and having 10-20 threads generating tokens? It > shouldn't make any difference if you have 10 or if you have 200 users, it's > the total number of tokens that can be generated that's an issue. Having > 200 concurrent users with a access token timeout of 60 seconds should mean > that you need to be able to generate roughly 200/60 tokens = 3.3 tokens/sec. > > > > On 19 May 2016 at 13:24, Vaibhav Naldurgkar < > vaibhav_naldurgkar at persistent.com> wrote: > > Hi All, > > > > I am using Keycloak 1.9.3 with default configuration. Keycloak server is > installed on RHEL 6.5 virtual image with 4 CPU , 8 GB RAM and java version > is jdk1.8.0_73 We are trying to use keycloak as a OAuth provider. But when > we try and generate token( > http:///auth/realms/master/protocol/openid-connect/token > ) for more than > 10-20 users the server gets too slow and cpu usage goes over 100%. > > Any pointers on how to improve performance of keycloak OAuth provider. We > need to support at least 200 concurrent users. > > > > > > Thanks, Vaibhav > > DISCLAIMER ========== This e-mail may contain privileged and confidential > information which is the property of Persistent Systems Ltd. It is intended > only for the use of the individual or entity to which it is addressed. If > you are not the intended recipient, you are not authorized to read, retain, > copy, print, distribute or use this message. If you have received this > communication in error, please notify the sender and delete all copies of > this message. Persistent Systems Ltd. does not accept any liability for > virus infected mails. > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > DISCLAIMER ========== This e-mail may contain privileged and confidential > information which is the property of Persistent Systems Ltd. It is intended > only for the use of the individual or entity to which it is addressed. If > you are not the intended recipient, you are not authorized to read, retain, > copy, print, distribute or use this message. If you have received this > communication in error, please notify the sender and delete all copies of > this message. Persistent Systems Ltd. does not accept any liability for > virus infected mails. > > > > DISCLAIMER ========== This e-mail may contain privileged and confidential > information which is the property of Persistent Systems Ltd. It is intended > only for the use of the individual or entity to which it is addressed. If > you are not the intended recipient, you are not authorized to read, retain, > copy, print, distribute or use this message. If you have received this > communication in error, please notify the sender and delete all copies of > this message. Persistent Systems Ltd. does not accept any liability for > virus infected mails. > > > > DISCLAIMER ========== This e-mail may contain privileged and confidential > information which is the property of Persistent Systems Ltd. It is intended > only for the use of the individual or entity to which it is addressed. If > you are not the intended recipient, you are not authorized to read, retain, > copy, print, distribute or use this message. If you have received this > communication in error, please notify the sender and delete all copies of > this message. Persistent Systems Ltd. does not accept any liability for > virus infected mails. > > > > DISCLAIMER ========== This e-mail may contain privileged and confidential > information which is the property of Persistent Systems Ltd. It is intended > only for the use of the individual or entity to which it is addressed. If > you are not the intended recipient, you are not authorized to read, retain, > copy, print, distribute or use this message. If you have received this > communication in error, please notify the sender and delete all copies of > this message. Persistent Systems Ltd. does not accept any liability for > virus infected mails. > > > > DISCLAIMER ========== This e-mail may contain privileged and confidential > information which is the property of Persistent Systems Ltd. It is intended > only for the use of the individual or entity to which it is addressed. If > you are not the intended recipient, you are not authorized to read, retain, > copy, print, distribute or use this message. If you have received this > communication in error, please notify the sender and delete all copies of > this message. Persistent Systems Ltd. does not accept any liability for > virus infected mails. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160526/c370a491/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.png Type: image/png Size: 11865 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160526/c370a491/attachment-0004.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.png Type: image/png Size: 18447 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160526/c370a491/attachment-0005.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 28486 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160526/c370a491/attachment-0006.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.png Type: image/png Size: 101405 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160526/c370a491/attachment-0007.png From sthorger at redhat.com Thu May 26 02:11:23 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 26 May 2016 08:11:23 +0200 Subject: [keycloak-user] Schedule background jobs as user In-Reply-To: References: Message-ID: What similar protocols are you referring to? In either case we don't have any support for it and it has to be done through a redirect. As I said there's no re-authentication required since the user is already authenticated. To the user it would just look like they are opening the page to schedule background jobs and no additional UI pages are displayed to them. On 26 May 2016 at 02:25, Jesse Chahal wrote: > I did not look at the example but as you can see from the end of the > last email we would very much like to not redirect the user back to > the login screen. I assumed this was a possible way of getting an > offline_token already as it would be comparable to other applications > using similar protocols asking for elevated permissions. Usually those > other applications would be using an external identity provider. This > starts to reduce the native feel of the authentication system > (keycloak) + the application. Our application is a 1st party app > (meaning keycloak+app should appear to be a single app) and our UX > team is very much against the experience provided by requiring > reauthentication to schedule background jobs with ourselves. > > On Tue, May 24, 2016 at 10:01 PM, Stian Thorgersen > wrote: > > Did you look at the offline-access-app from our examples? You could use > > regular login with the adapters, but when the application needs an > offline > > token and doesn't already have one direct the user to the login and > include > > ?scope=offline_access. If the user is already authenticated and the > client > > doesn't require consent no login page will be displayed. > > > > On 20 May 2016 at 19:42, Jesse Chahal wrote: > >> > >> Thanks for the info, looks like I was on the right path. After reading > >> through the OpenID spec I came across offline tokens and saw that it > >> was supported by keycloak. I was trying to figure out how to use > >> offline tokens with the adapter (since it didn't seem possible to set > >> a flag to enable the scope for this) but based on the above it isn't > >> possible. Is it possible for a client to request an offline token > >> using a refresh or access token? The reason I ask is because we cannot > >> request it using the adapter system that we are currently using. Even > >> if we could with the adapter system that would mean that for every > >> single login we would be requesting a offline token instead of a > >> refresh token (seems like a bad idea). It also seems like a good idea > >> to only request the offline_token if a user decides to schedule a > >> offline job with us. We would prefer not having to have the user login > >> again in order to schedule an offline job. I did some initial tests > >> using a rest client and it did not seem possible. > >> > >> On Thu, May 19, 2016 at 10:34 PM, Stian Thorgersen > > >> wrote: > >> > This is exactly what offline tokens where created to do. The offline > >> > token > >> > is not linked to user sessions so it doesn't matter if users login or > >> > not. > >> > Our adapters doesn't support it properly though so you'd need to > create > >> > a > >> > filter or something that sets up the context and principle based on > the > >> > offline token. > >> > > >> > On 19 May 2016 at 19:56, Jesse Chahal wrote: > >> >> > >> >> So we've done a lot of work on our migration to keycloak but still > >> >> have a few holes that are using another authentication system. We are > >> >> using Wildfly10 along with the keycloak subsystem. The last real > >> >> blocking issues is trying to schedule background tasks on behalf of a > >> >> user using quartz. We've tried using impersonation role and mocking > >> >> out the impersonation workflow that a browser does, it was fairly > >> >> complicated and did not work very well. Service accounts don't seem > to > >> >> fit this scenario either as service accounts seem to be for > performing > >> >> client specific actions. We considered storing offline token's on > >> >> behalf of users but the thing is users might not log in for years > >> >> after scheduling their job. We need to set the Context and Principle > >> >> to be the user who we are performing background tasks on behalf of. > Is > >> >> there a recommended way of doing this that has been tested by others? > >> >> I'm sure we aren't the only company who schedule tasks on behalf of > >> >> users. > >> >> _______________________________________________ > >> >> keycloak-user mailing list > >> >> keycloak-user at lists.jboss.org > >> >> https://lists.jboss.org/mailman/listinfo/keycloak-user > >> > > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160526/8ecb9f98/attachment.html From sthorger at redhat.com Thu May 26 02:16:23 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 26 May 2016 08:16:23 +0200 Subject: [keycloak-user] Management of compromising bug tickets In-Reply-To: References: Message-ID: Security sensitive issues are marked as security sensitive, which means that only the reporter and core team members can view the issue. However, as it's all open source someone can monitor commits and figure out exploits that way. Once we have a supported version of Keycloak ready we'll have a channel to distribute patches to customers prior to disclosing any details and code to the community. On 26 May 2016 at 01:23, Brian Watson wrote: > Hey all, > > I love the fact that your backlog is very transparent, and that I can see > a list of all tasks completed for a given release. > > However, I was wondering how you handle tasks for compromising bugs? For > instance, one could look in the backlog for a bug that states "If you send > '123' to the master realm token endpoint at precisely 6:59am on a Tuesday, > and you will be granted an admin token! Please Fix!", and use that > information to gain access to the systems of those using Keycloak. > > Thank you in advance. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160526/152b183b/attachment.html From sthorger at redhat.com Thu May 26 02:27:14 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 26 May 2016 08:27:14 +0200 Subject: [keycloak-user] How to apply updates to keycloak instances In-Reply-To: References: <87CBA013-76D9-4A1D-B64D-70FF432D8720@smartling.com> <097F53B6-6373-4E88-BF9F-8E1808B6295E@smartling.com> Message-ID: On 26 May 2016 at 02:15, Jesse Chahal wrote: > @Stian > The approach described sounds similar to liquibase to me but with json > and specific to keycloak. I feel like a lot of possible bugs could > arise from this approach or at least quite a few feature requests. > Would each json file only contain a single change? Would order matter > in how they get applied if you put a bunch of json files in this > directory at once? Can the same file be applied multiple times? These > are the kind of issues I would expect to come up with this type of > change management system. When I mentioned write our own tool/script > to do it I was kind of thinking of a writing a liquibase like system > that calls keycloak's rest api. > We haven't figured out all the details, but what you are proposing sounds better. A single document that lists all changes, that can also import other files, sorts out the ordering and we could add same type of ids as Liquibase does to changesets. You could write it to use the rest api, then use a separate db to store what changes have been applied, but would be better if Keycloak deals with loading the changes directly as it can write to the db what changes have been applied. One big issue is what happens if manual changes are done through the admin console. One though (although probably very tricky to get right) is that changes done through the admin console is added to the changeset. > > @ Scott > If I would compare the solution you mentioned to one of the options I > listed in my original question "I've also considered writing my own > updater tool using a scripting language (python/ruby) that calls > keycloak's rest api." The worrying thing to me is that there is > another piece of code that needs to maintained by our company and > requires quite a bit of knowledge of keycloak's rest api. There would > probably need to be some serious thought put into the architecture of > the tool as well. Without a doubt it does provide the most control. We > also live by a different methodology in regards to updating production > clusters. From our perspective it is more of an issue to update > manually as it becomes much easier to miss a step or in someway screw > up if steps are performed manually. I'm not sure what the security > implications would be from it occurring automatically, especially if > during each step there is thorough testing (including from a security > team). For our CI/CD pipeline our goal is to have it so every commit > can automagically end up on production without human intervention. > > Currently we use a combination of an initial realm file to be included > on startup and also use jq to modify the keycloak-server.json for new > keycloak clusters. We don't need to generate realm or client keys as > it is included in the initial realm file. That doesn't work for > existing systems backed by a database that cannot be thrown away. That > kind of leave me with the original option (and hardest) of "write a > proprietary liquibase like system built ontop of keycloaks rest api". > This is a hard problem to solve > Why proprietary? If we can agree on a design we'll happily accept a contribution and maintain it as well. > > On Mon, May 23, 2016 at 1:49 PM, Anthony Fryer > wrote: > > Thanks, I'll check it out. > > > > > > On 05:38, Tue, 24/05/2016 Scott Rossillo > wrote: > >> > >> We use Jose4J[0] to create the keys and then jq[1] to modify the realm > >> file. > >> > >> See the first line of code here for a super simple example of how to > >> generate realm keys: > >> https://bitbucket.org/b_c/jose4j/wiki/JWT%20Examples > >> > >> PS - this may be doable with Keycloak but Jose4J is very lightweight for > >> writing a simple script on a CI server. > >> > >> [0]: https://bitbucket.org/b_c/jose4j > >> [1]: https://stedolan.github.io/jq/ > >> > >> > >> Scott Rossillo > >> Smartling | Senior Software Engineer > >> srossillo at smartling.com > >> > >> On May 21, 2016, at 10:20 PM, Anthony Fryer > >> wrote: > >> > >> Hi Scott, > >> > >> How do you generate the realm keys when creating the new keycloak dev > >> instances? Do you use a keycloak api or some other way? I'm > interested in > >> having a standard realm template that is used to create new realms but > would > >> need to change the realm keys when importing this template into > keycloak. > >> > >> Cheers, > >> > >> Anthony > >> > >> On Sat, May 21, 2016 at 3:43 AM, Scott Rossillo < > srossillo at smartling.com> > >> wrote: > >>> > >>> We?re using Keycloak on production, stage/QA, development environments > >>> and every developer?s workstation / laptop. > >>> > >>> While there will always be differing options on how to successfully do > >>> change management, we?ve found a very effective method for handling > Keycloak > >>> provisioning in all environments so that developers don?t need to mess > >>> around with. We?re a continuous integration / deployment shop using > micro > >>> services and everything has to ?just work? ? I?ll give an overview of > our > >>> process here but please keep in mind a few things: > >>> > >>> 1. This approach works for us, I?m not saying it?s the best way > >>> 2. We do _not_ allow production config changes to be automated due to > >>> security implications > >>> 3. We're very opinionated in our approach to configuration management > and > >>> we don?t ever modify 3rd party software databases directly. We always > use > >>> APIs. > >>> > >>> We deploy Keycloak to all environments using Docker images. On > developer > >>> workstations we use Docker Compose to orchestrate bringing up all > services a > >>> developer may need, including Keycloak. > >>> > >>> We have 4 docker images for Keycloak: > >>> - Keycloak Base > >>> \- Keycloak HA > >>> \- Keycloak Dev > >>> - Keycloak config manager* > >>> > >>> The base image includes all customizations necessary to bring up a > >>> Keycloak instance configured with our modules and themes installed. > >>> The HA instance builds off base and configures Keycloak to run as a > >>> cluster node. This is used on stage and prod. > >>> The dev instance builds off base and includes our realm file. On > startup, > >>> this instance loads our realm configuration if it?s not already loaded. > >>> > >>> All docker images are built and published by the CI server and Keycloak > >>> HA can be deployed to stage and prod after a clean CI build. > >>> > >>> Developers are free to add clients for testing, do whatever they want, > >>> etc. to their running dev instance. If they want to get back to our > stock > >>> build, they pull the latest Docker image from our private Docker repo > and > >>> restart it. > >>> > >>> Adding clients to stage and prod requires approval and is done by a > hand. > >>> This is for security reasons. Once a configuration change is detected > on > >>> stage - say a client is added - our CI server exports the realm from > stage, > >>> changes the realm keys, and creates a new Keycloak Dev instance with > the > >>> updated realm file. > >>> > >>> *A word about configuration management: > >>> > >>> Obviously, the realm file we generate knows the URLs of staging > services, > >>> not local or development environment URLs. To overcome this we > introduced > >>> another Docker based service called the Keycloak configuration manger. > It > >>> runs on development environments and workstations. It?s responsible for > >>> discovering running services and updating Keycloak via its admin > endpoints > >>> to reflect the proper configuration for the given environment. > >>> > >>> That?s it. The whole process is automated with the exception of > >>> configuration changes to stage and prod which require a security > review. > >>> > >>> Hope this helps. Let me know if you?d like me to elaborate on anything. > >>> > >>> Best, > >>> Scott > >>> > >>> Scott Rossillo > >>> Smartling | Senior Software Engineer > >>> srossillo at smartling.com > >>> > >>> On May 20, 2016, at 1:46 AM, Stian Thorgersen > >>> wrote: > >>> > >>> Firstly, just wanted to highlight that core Keycloak team are devs, not > >>> sysadmins/ops guys, so we have limited experience in continuous > delivery and > >>> maintenance of real production systems. Hence, we'd love input from the > >>> community on this. > >>> > >>> As it stands we don't really have a proper solution. I believe the best > >>> you can do at the moment is either using import feature, partial > import or > >>> admin rest endpoints. Import is not going to work IMO as it requires > >>> re-creating the whole realm. Partial import may work, but would work > best > >>> for new resources rather than modifying existing resources as it does a > >>> delete/create operation rather than attempt to modify. With the admin > rest > >>> endpoints you'd get the best control of what's going on, but obviously > that > >>> leaves a fair amount of the work. > >>> > >>> In the future we have an idea of introducing an "import directory" it > >>> would be possible to drop json files in here that would add, modify or > >>> delete resources (realms, clients, roles, users, whatever). This would > allow > >>> dropping json files before the server starts and the server would then > >>> import on startup. It would also be possible to do this at runtime and > new > >>> files would be detected at runtime. Finally, we also had an idea of an > >>> offline mode to run import of this (it would basically start the server > >>> without http listener, import files, then stop, so it could be used in > a > >>> script/tool). Import is probably not the best name for it, as it would > >>> support modify and delete as well as "importing" new things. > >>> > >>> On 19 May 2016 at 19:53, Jesse Chahal wrote: > >>>> > >>>> Following some of the best practices for continuous Integration and > >>>> continuous delivery there needs to be environments for build, test, > >>>> and production. This would mean that following these practices would > >>>> require you to have multiple versions of keycloak at different stages > >>>> of development cycle. Some of these environments might not have > >>>> important persistent data while others might. In order to have builds > >>>> transition from one environment to another there may be configuration > >>>> changes required for a build to be valid. This is especially true when > >>>> new services (openid clients) are being added or "default" accounts. > >>>> I'm trying to come up with a scripted way of updating keycloak > >>>> instances that are backed up by an RDMS. This may include adding new > >>>> clients, adding new users, updating realm config, etc... Originally I > >>>> was planning on simply exporting the realm config and importing it > >>>> every time keycloak starts. If I enabled the OVERWRITE option I might > >>>> overwrite things that I do not want overridden. This is especially > >>>> true if there is some config that differ's based on whether it is a > >>>> build, test, or production instance. If I don't enable it then it is > >>>> only useful for new/blank keycloak environments. I considered using > >>>> liquibase but since I do not have control of schema changes created by > >>>> the keycloak team I might run into issues with my liquibase file not > >>>> being valid after a migration/liquibase update by the keycloak team as > >>>> my liquibase file would run after keycloak's does. There might also be > >>>> some other unknown issues our liquibase changes conflicting somehow > >>>> with keycloak's liquibase changes. I've also considered writing my own > >>>> updater tool using a scripting language (python/ruby) that calls > >>>> keycloak's rest api. The issues with this mechanism is it feels like I > >>>> am recreating the wheel as well as not being able to find good > >>>> documentation on keycloak's openid endpoints/url's used for different > >>>> oauth2 flows. Even if I did find this documentation it would also > >>>> require me to find a good openid client for the scripting language. > >>>> This doesn't matter for our normal clients as they simply use the > >>>> keycloak subsystems and adapters instead. I've also looked at commonly > >>>> used server configuration software such as chef, puppet, and ansible. > >>>> I don't see a good solution using any of those tools yet either. What > >>>> have other people done for cases like this? Please don't tell me there > >>>> is someone who is doing this all manually because that doesn't work in > >>>> modern software development. > >>>> > >>>> - doesn't accidentally delete users > >>>> - doesn't accidentally delete clients > >>>> - doesn't invalidate sessions (optional) > >>>> - works to bring up new, correctly configured, keycloak instances > >>>> - handles applying updates to existing keycloak instances > >>>> - can handle minor differences between keycloak instances (build, > >>>> test, production) when updating > >>>> - preferably can work well in rolling deployment scenario's. > >>>> -- I hope the keycloak team is taking these into consideration when > >>>> doing database migration between 1-2 releases. It would be nice if > >>>> they set some specific rules for rolling updates between versions (aka > >>>> backwards breaking changes) > >>>> _______________________________________________ > >>>> keycloak-user mailing list > >>>> keycloak-user at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user > >>> > >>> > >>> _______________________________________________ > >>> keycloak-user mailing list > >>> keycloak-user at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/keycloak-user > >>> > >>> > >>> > >>> _______________________________________________ > >>> keycloak-user mailing list > >>> keycloak-user at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/keycloak-user > >> > >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160526/dc70c0b8/attachment-0001.html From akaya at expedia.com Thu May 26 03:14:48 2016 From: akaya at expedia.com (Sarp Kaya) Date: Thu, 26 May 2016 07:14:48 +0000 Subject: [keycloak-user] Using dependencies for an SPI provider Message-ID: Hi, I am trying to extend an event listener and the example one works fine, which just prints out every event. However I want to do something more complicated than that. So I added two more dependency on top of keycloak dependencies: com.codahale.metrics:metrics-core and com.readytalk:metrics3-statsd In my IDE I was able to develop fine, then maven packages it fine. I package it by including all the dependencies (so JAR file is like 6 MB), otherwise it won?t have the dependencies (I have tried that and it complained at the runtime saying it doesn?t have the class). Then I start the keycloak service, it starts fine. I get an exception throw like below when I initially use the service (which is when the first event trigger happens): 07:10:01,453 ERROR [io.undertow.request] (default task-6) UT005023: Exception handling request to /auth/realms/master/protocol/openid-connect/auth: org.jboss.resteasy.spi.UnhandledException: java.lang.NoClassDefFoundError: sun/misc/Unsafe at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76) at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212) at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:168) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:411) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:88) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.NoClassDefFoundError: sun/misc/Unsafe at com.codahale.metrics.Striped64.getUnsafe(Striped64.java:330) at com.codahale.metrics.Striped64.(Striped64.java:311) at com.codahale.metrics.EWMA.(EWMA.java:29) at com.codahale.metrics.EWMA.oneMinuteEWMA(EWMA.java:39) at com.codahale.metrics.Meter.(Meter.java:15) at com.codahale.metrics.Meter.(Meter.java:28) at com.codahale.metrics.MetricRegistry$MetricBuilder$3.newMetric(MetricRegistry.java:426) at com.codahale.metrics.MetricRegistry$MetricBuilder$3.newMetric(MetricRegistry.java:423) at com.codahale.metrics.MetricRegistry.getOrAdd(MetricRegistry.java:313) at com.codahale.metrics.MetricRegistry.meter(MetricRegistry.java:134) at com.expedia.keycloak.spi.providers.events.SysoutEventListenerProvider.(SysoutEventListenerProvider.java:22) at com.expedia.keycloak.spi.providers.events.SysoutEventListenerProviderFactory.create(SysoutEventListenerProviderFactory.java:23) at com.expedia.keycloak.spi.providers.events.SysoutEventListenerProviderFactory.create(SysoutEventListenerProviderFactory.java:16) at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:115) at sun.reflect.GeneratedMethodAccessor27.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.resteasy.core.ContextParameterInjector$GenericDelegatingProxy.invoke(ContextParameterInjector.java:56) at com.sun.proxy.$Proxy81.getProvider(Unknown Source) at org.keycloak.events.EventBuilder.(EventBuilder.java:62) at org.keycloak.services.resources.RealmsResource.getProtocol(RealmsResource.java:98) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:79) at org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:58) at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:100) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) ... 37 more Caused by: java.lang.ClassNotFoundException: sun.misc.Unsafe at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ... 66 more I don?t know what could be wrong. When I googled the java.lang.NoClassDefFoundError with Keycloak I found that there was an error with Facebook integration. So I am wondering whether this is something similar and a bug with Keycloak? If not then what have I missed? Kind Regards, Sarp Kaya -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160526/f1c9be2b/attachment.html From sthorger at redhat.com Thu May 26 03:16:33 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 26 May 2016 09:16:33 +0200 Subject: [keycloak-user] Kc_idp_hint problems In-Reply-To: <353F9AF5-39A4-42DC-B965-2B107EE13280@planon-fm.com> References: <353F9AF5-39A4-42DC-B965-2B107EE13280@planon-fm.com> Message-ID: Which adapter are you using? On 25 May 2016 at 15:47, Kristiaan Jansen < Kristiaan.Jansen at planonsoftware.com> wrote: > > Hi all > > I am trying to get the automatically select an identity provider working > but having no succes. > > What I have tried: > https://myurl.com?kc_ idp_hint=idpalias1 > https://myurl.com/index.kees?kc_idp_hint=idpalias1 > > I am using key cloak 1.9.2 > Authenticate by default is off for all identity providers > > I have 3 identity providers. > > The effect I am seeing is that I always get the idp selection page. > If I enable Authenticate by default for all identity providers it always > redirects to the top idp. > > Has anybody seen this feature work? > > Thanks, > Kris > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160526/87f482b3/attachment.html From sthorger at redhat.com Thu May 26 03:21:26 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 26 May 2016 09:21:26 +0200 Subject: [keycloak-user] Using dependencies for an SPI provider In-Reply-To: References: Message-ID: If you need additional dependencies in your provider please deploy it as a module, see docs and examples on how to do that. For the missing class you're module definition would need to include: ... ... On 26 May 2016 at 09:14, Sarp Kaya wrote: > Hi, > > I am trying to extend an event listener and the example one works fine, > which just prints out every event. > However I want to do something more complicated than that. So I added two > more dependency on top of keycloak dependencies: > com.codahale.metrics:metrics-core and com.readytalk:metrics3-statsd > > In my IDE I was able to develop fine, then maven packages it fine. I > package it by including all the dependencies (so JAR file is like 6 MB), > otherwise it won?t have the dependencies (I have tried that and it > complained at the runtime saying it doesn?t have the class). > > Then I start the keycloak service, it starts fine. I get an exception > throw like below when I initially use the service (which is when the first > event trigger happens): > > 07:10:01,453 ERROR [io.undertow.request] (default task-6) UT005023: > Exception handling request to > /auth/realms/master/protocol/openid-connect/auth: > org.jboss.resteasy.spi.UnhandledException: java.lang.NoClassDefFoundError: > sun/misc/Unsafe > at > org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76) > at > org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212) > at > org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:168) > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:411) > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) > at > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) > at > org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:88) > at > io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) > at > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) > at > io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) > at > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at > org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at > io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at > io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) > at > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) > at > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) > at > io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > at > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NoClassDefFoundError: sun/misc/Unsafe > at com.codahale.metrics.Striped64.getUnsafe(Striped64.java:330) > at com.codahale.metrics.Striped64.(Striped64.java:311) > at com.codahale.metrics.EWMA.(EWMA.java:29) > at com.codahale.metrics.EWMA.oneMinuteEWMA(EWMA.java:39) > at com.codahale.metrics.Meter.(Meter.java:15) > at com.codahale.metrics.Meter.(Meter.java:28) > at > com.codahale.metrics.MetricRegistry$MetricBuilder$3.newMetric(MetricRegistry.java:426) > at > com.codahale.metrics.MetricRegistry$MetricBuilder$3.newMetric(MetricRegistry.java:423) > at > com.codahale.metrics.MetricRegistry.getOrAdd(MetricRegistry.java:313) > at > com.codahale.metrics.MetricRegistry.meter(MetricRegistry.java:134) > at > com.expedia.keycloak.spi.providers.events.SysoutEventListenerProvider.(SysoutEventListenerProvider.java:22) > at > com.expedia.keycloak.spi.providers.events.SysoutEventListenerProviderFactory.create(SysoutEventListenerProviderFactory.java:23) > at > com.expedia.keycloak.spi.providers.events.SysoutEventListenerProviderFactory.create(SysoutEventListenerProviderFactory.java:16) > at > org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:115) > at sun.reflect.GeneratedMethodAccessor27.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.jboss.resteasy.core.ContextParameterInjector$GenericDelegatingProxy.invoke(ContextParameterInjector.java:56) > at com.sun.proxy.$Proxy81.getProvider(Unknown Source) > at org.keycloak.events.EventBuilder.(EventBuilder.java:62) > at > org.keycloak.services.resources.RealmsResource.getProtocol(RealmsResource.java:98) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:79) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:58) > at > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:100) > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) > ... 37 more > Caused by: java.lang.ClassNotFoundException: sun.misc.Unsafe > at java.net.URLClassLoader.findClass(URLClassLoader.java:381) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > ... 66 more > > I don?t know what could be wrong. When I googled > the java.lang.NoClassDefFoundError with Keycloak I found that there was an > error with Facebook integration. So I am wondering whether this is > something similar and a bug with Keycloak? If not then what have I missed? > > Kind Regards, > Sarp Kaya > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160526/d85459a3/attachment-0001.html From nidhirachora at gmail.com Thu May 26 04:41:42 2016 From: nidhirachora at gmail.com (Nidhi Rachora) Date: Thu, 26 May 2016 18:41:42 +1000 Subject: [keycloak-user] Disabling unique email restriction in Keycloak In-Reply-To: References: Message-ID: Thank you, that solved the issue. On 5/25/16, Stian Thorgersen wrote: > On 23 May 2016 at 18:44, Niels Bertram wrote: > >> Are you suggesting that the email field will no longer be able to be >> populated by the user if the realm is configured to use username only for >> login? >> > > Yes, the email field with the unique constraint would only be used for > "login email". Then there would be an attribute or another field for > contact email. > > >> >> In the current form, we would still have to populate the current "email" >> field in the user model with a unique email address, which we dont have >> for >> our users. Or at least lets say we don't want to resort to a hack in the >> User Federation Provider and add random snippets into the email address >> using a fringe feature of the email spec. >> > > Why? The email field is optional, just leave it blank. Then use an > attribute as I suggested. > > >> >> On Mon, May 23, 2016 at 3:27 PM, Stian Thorgersen >> wrote: >> >>> We've planned to add support for having non-unique email addresses. The >>> idea would be to have an option on a realm to configure if login permits >>> username/email, username or email. The email field on users would still >>> have to have a unique constraint as removing that results in not being >>> able >>> to guarantee email uniqueness. Instead we planned to have contact email >>> address which would be non-unique. >>> >>> You can workaround this though as it's already possible to add custom >>> attributes (to add contact email) and change the email sender so >>> Keycloak >>> supports sending email to contact email attribute if set. >>> >>> On 23 May 2016 at 05:03, Nidhi Rachora wrote: >>> >>>> Hi Keycloak Team, >>>> >>>> I am working on migrating an existing application to Keycloak. In the >>>> existing application, unique ?member_ids? are used as usernames and the >>>> ?email? field can be duplicate. However on logging into Keycloak, >>>> members >>>> with duplicate emails are not allowed. So I have identified two areas >>>> to >>>> work on: >>>> >>>> Task I) Allow members with unique member ids (who may/ maynot have >>>> unique email) to login. >>>> Task II) Disable login using email. >>>> >>>> Solution: >>>> So as a solution to the first task, in my CustomUserFederation, I have >>>> made the following changes: >>>> >>>> //Code snippet 1 CustomFederationProvider implements >>>> UserFederationProvider{ >>>> . . >>>> @Override >>>> public UserModel getUserByUsername(RealmModel realm, String username) { >>>> . . >>>> if (apiCustomer.getEmailAddresses() != null && >>>> apiCustomer.getEmailAddresses().size() > 0) { >>>> // Changed to handle duplicate emails using: Sub-addressing, so email: >>>> mailid at domain is saved as mailid+member_id at domain >>>> userModel.setEmail( >>>> subaddress(apiCustomer.getEmailAddresses().get(0).getEmail(), >>>> userModel.getMember_id())); >>>> } >>>> . . >>>> } >>>> } >>>> >>>> //Code snippet 2 >>>> CustomUserModelDelegate extends UserModelDelegate { >>>> . . >>>> @Override >>>> public String getEmail() { >>>> String email = super.getEmail(); try { >>>> // Changed to handle duplicate emails using: Sub-addressing, so while >>>> retrieving email: mailid+member_id at domain is processed as mailid at domain >>>> >>>> email = removeSubaddress(email); >>>> } catch (Exception e) { >>>> ... >>>> } >>>> return email; >>>> } >>>> . . >>>> } >>>> >>>> Now my queries are: >>>> >>>> 1.) Will my solution of sub-addressing the email resolve the first >>>> issue >>>> without any side-effects? >>>> 2.) How do I disable logging in using emails from Keycloak? >>>> >>>> Regards, >>>> Nidhi Rachora >>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>> >>> >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> >> > From haimv at perfectomobile.com Thu May 26 04:56:19 2016 From: haimv at perfectomobile.com (Haim Vana) Date: Thu, 26 May 2016 08:56:19 +0000 Subject: [keycloak-user] How to get user id programmatically Message-ID: Hi, How can I get the user id programmatically ? I am trying to user the search API as below, however I am not getting any results although the user exist within the realm. keyCloakClient.realms().realm(realmName).users().search(user.getUserName(), user.getFirstName(), user.getLastName(), user.getEmail(), 1/*pagination offset*/, 1/*max results*/); Any advice will be appreciated. Thanks, Haim. The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160526/5bd89379/attachment.html From mstrukel at redhat.com Thu May 26 06:06:29 2016 From: mstrukel at redhat.com (Marko Strukelj) Date: Thu, 26 May 2016 12:06:29 +0200 Subject: [keycloak-user] How to get user id programmatically In-Reply-To: References: Message-ID: Pagination offset starts from 0, not 1. You can as well put null, null for offset and max results, or -1, -1. On Thu, May 26, 2016 at 10:56 AM, Haim Vana wrote: > Hi, > > > > How can I get the user id programmatically ? I am trying to user the > search API as below, however I am not getting any results although the user > exist within the realm. > > > > keyCloakClient.realms().realm(realmName).users().search(user.getUserName(), > user.getFirstName(), user.getLastName(), user.getEmail(), 1*/*pagination > offset*/*, 1*/*max results*/*); > > > > > > Any advice will be appreciated. > > > > > > Thanks, > > Haim. > > > The information contained in this message is proprietary to the sender, > protected from disclosure, and may be privileged. The information is > intended to be conveyed only to the designated recipient(s) of the message. > If the reader of this message is not the intended recipient, you are hereby > notified that any dissemination, use, distribution or copying of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. Thank you. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160526/d1862be5/attachment.html From haimv at perfectomobile.com Thu May 26 06:13:32 2016 From: haimv at perfectomobile.com (Haim Vana) Date: Thu, 26 May 2016 10:13:32 +0000 Subject: [keycloak-user] How to get user id programmatically In-Reply-To: References: Message-ID: Great ? that was exactly what I was missing. BTW where can I find its documentation ? From: Marko Strukelj [mailto:mstrukel at redhat.com] Sent: Thursday, May 26, 2016 1:06 PM To: Haim Vana Cc: keycloak-user at lists.jboss.org Subject: Re: [keycloak-user] How to get user id programmatically Pagination offset starts from 0, not 1. You can as well put null, null for offset and max results, or -1, -1. On Thu, May 26, 2016 at 10:56 AM, Haim Vana > wrote: Hi, How can I get the user id programmatically ? I am trying to user the search API as below, however I am not getting any results although the user exist within the realm. keyCloakClient.realms().realm(realmName).users().search(user.getUserName(), user.getFirstName(), user.getLastName(), user.getEmail(), 1/*pagination offset*/, 1/*max results*/); Any advice will be appreciated. Thanks, Haim. The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160526/b6f29af2/attachment-0001.html From mstrukel at redhat.com Thu May 26 06:24:24 2016 From: mstrukel at redhat.com (Marko Strukelj) Date: Thu, 26 May 2016 12:24:24 +0200 Subject: [keycloak-user] How to get user id programmatically In-Reply-To: References: Message-ID: There is no documentation for admin-client API at the moment. Admin REST endpoints are documented here: http://keycloak.github.io/docs/rest-api/index.html#_get_users But as you can see, that doc is not great. It's not explained there that for page offset you can pass -1 to mean the same as null or 0. On Thu, May 26, 2016 at 12:13 PM, Haim Vana wrote: > Great ? that was exactly what I was missing. > > > > BTW where can I find its documentation ? > > > > > > *From:* Marko Strukelj [mailto:mstrukel at redhat.com] > *Sent:* Thursday, May 26, 2016 1:06 PM > *To:* Haim Vana > *Cc:* keycloak-user at lists.jboss.org > *Subject:* Re: [keycloak-user] How to get user id programmatically > > > > Pagination offset starts from 0, not 1. You can as well put null, null for > offset and max results, or -1, -1. > > > > On Thu, May 26, 2016 at 10:56 AM, Haim Vana > wrote: > > Hi, > > > > How can I get the user id programmatically ? I am trying to user the > search API as below, however I am not getting any results although the user > exist within the realm. > > > > keyCloakClient.realms().realm(realmName).users().search(user.getUserName(), > user.getFirstName(), user.getLastName(), user.getEmail(), 1*/*pagination > offset*/*, 1*/*max results*/*); > > > > > > Any advice will be appreciated. > > > > > > Thanks, > > Haim. > > > > The information contained in this message is proprietary to the sender, > protected from disclosure, and may be privileged. The information is > intended to be conveyed only to the designated recipient(s) of the message. > If the reader of this message is not the intended recipient, you are hereby > notified that any dissemination, use, distribution or copying of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. Thank you. > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > The information contained in this message is proprietary to the sender, > protected from disclosure, and may be privileged. The information is > intended to be conveyed only to the designated recipient(s) of the message. > If the reader of this message is not the intended recipient, you are hereby > notified that any dissemination, use, distribution or copying of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. Thank you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160526/48d0ba81/attachment.html From haimv at perfectomobile.com Thu May 26 07:16:54 2016 From: haimv at perfectomobile.com (Haim Vana) Date: Thu, 26 May 2016 11:16:54 +0000 Subject: [keycloak-user] How to create the same client (same id) for multiple realms programmatically Message-ID: Hi, I am trying to create the same client for many realms, however it creates it only once, probably because they have the same id, however in UI I am able to create it. Any idea how I can create the same client for different realms programmatically with the same id ? This is my code sample: ClientRepresentation clientRepresentation = new ClientRepresentation(); clientRepresentation.setId(clientId); // Same clientId for all reamls realm.clients().create(clientRepresentation); // Client is created only for first realm Any advice will be appreciated, Haim. The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160526/0cca8a41/attachment.html From haimv at perfectomobile.com Thu May 26 08:54:04 2016 From: haimv at perfectomobile.com (Haim Vana) Date: Thu, 26 May 2016 12:54:04 +0000 Subject: [keycloak-user] How to create the same client (same id) for multiple realms programmatically Message-ID: Any idea regarding the below ? As a workaround how can I update existing client programmatically ? I couldn't find it in the admin API. Thanks again, Haim. From: Haim Vana Sent: Thursday, May 26, 2016 2:17 PM To: keycloak-user at lists.jboss.org Subject: How to create the same client (same id) for multiple realms programmatically Hi, I am trying to create the same client for many realms, however it creates it only once, probably because they have the same id, however in UI I am able to create it. Any idea how I can create the same client for different realms programmatically with the same id ? This is my code sample: ClientRepresentation clientRepresentation = new ClientRepresentation(); clientRepresentation.setId(clientId); // Same clientId for all reamls realm.clients().create(clientRepresentation); // Client is created only for first realm Any advice will be appreciated, Haim. The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160526/e69e8881/attachment-0001.html From jeremy at jeremysimon.com Thu May 26 09:05:03 2016 From: jeremy at jeremysimon.com (Jeremy Simon) Date: Thu, 26 May 2016 09:05:03 -0400 Subject: [keycloak-user] Keycloak & Spring Boot In-Reply-To: References: Message-ID: John, are you looking for the Spring Security UserDetails object? jeremy jeremy at jeremysimon.com www.JeremySimon.com On Wed, May 25, 2016 at 10:51 AM, John D. Ament wrote: > Hi, > > I was trying to follow the tutorial to add keycloak to a simple spring boot > app. > https://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#spring-boot-adapter > > It seems like there's a few steps missing. How do I generate the credential > used by the spring boot app? > > John > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From mposolda at redhat.com Thu May 26 09:16:04 2016 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 26 May 2016 15:16:04 +0200 Subject: [keycloak-user] How to create the same client (same id) for multiple realms programmatically In-Reply-To: References: Message-ID: <5746F714.6050007@redhat.com> You can use for example: RealmResource realm1 =adminClient.realms().realm("realm1"); RealmResource realm2 =adminClient.realms().realm("realm2"); realm1.clients().create(clientRepresentation); realm2.clients().create(clientRepresentation); For update you can take a look at some of our tests, which are updating client. For example this one : https://github.com/mposolda/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/admin/ClientTest.java#L183 Note that you need to know client Id (this is different thant clientId). The easiest is to set it manually in representation before you create client (via client.setId ) like it's done in this test. Marek On 26/05/16 14:54, Haim Vana wrote: > > Any idea regarding the below ? > > As a workaround how can I update existing client programmatically ? I > couldn't find it in the admin API. > > Thanks again, > > Haim. > > *From:*Haim Vana > *Sent:* Thursday, May 26, 2016 2:17 PM > *To:* keycloak-user at lists.jboss.org > *Subject:* How to create the same client (same id) for multiple realms > programmatically > > Hi, > > I am trying to create the same client for many realms, however it > creates it only once, probably because they have the same id, however > in UI I am able to create it. > > Any idea how I can create the same client for different realms > programmatically with the same id ? > > This is my code sample: > > ClientRepresentation clientRepresentation = *new *ClientRepresentation(); clientRepresentation.setId(clientId); // > Same clientId for all reamls > > realm.clients().create(clientRepresentation); // Client is created > only for first realm > > Any advice will be appreciated, > > Haim. > > The information contained in this message is proprietary to the > sender, protected from disclosure, and may be privileged. The > information is intended to be conveyed only to the designated > recipient(s) of the message. If the reader of this message is not the > intended recipient, you are hereby notified that any dissemination, > use, distribution or copying of this communication is strictly > prohibited and may be unlawful. If you have received this > communication in error, please notify us immediately by replying to > the message and deleting it from your computer. Thank you. > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160526/2acbf2e8/attachment.html From mstrukel at redhat.com Thu May 26 09:20:53 2016 From: mstrukel at redhat.com (Marko Strukelj) Date: Thu, 26 May 2016 15:20:53 +0200 Subject: [keycloak-user] How to create the same client (same id) for multiple realms programmatically In-Reply-To: References: Message-ID: The 'realm' variable represents a RealmResource which is locked to a specific realm. If you want to work with another realm you have to get a RealmResource for that realm. For example: Keycloak adminClient = Keycloak.getInstance("http://localhost:8080/auth", MASTER, ADMIN, ADMIN, Constants.ADMIN_CLI_CLIENT_ID); RealmResource realm = adminClient.realms().get("MyRealm"); On Thu, May 26, 2016 at 2:54 PM, Haim Vana wrote: > Any idea regarding the below ? > > > > As a workaround how can I update existing client programmatically ? I > couldn't find it in the admin API. > > > > > > Thanks again, > > Haim. > > > > *From:* Haim Vana > *Sent:* Thursday, May 26, 2016 2:17 PM > *To:* keycloak-user at lists.jboss.org > *Subject:* How to create the same client (same id) for multiple realms > programmatically > > > > Hi, > > > > I am trying to create the same client for many realms, however it creates > it only once, probably because they have the same id, however in UI I am > able to create it. > > > > Any idea how I can create the same client for different realms > programmatically with the same id ? > > > > This is my code sample: > > ClientRepresentation clientRepresentation = *new *ClientRepresentation(); > clientRepresentation.setId(clientId); // Same clientId for all reamls > > realm.clients().create(clientRepresentation); // Client is created only > for first realm > > > > > > Any advice will be appreciated, > > Haim. > The information contained in this message is proprietary to the sender, > protected from disclosure, and may be privileged. The information is > intended to be conveyed only to the designated recipient(s) of the message. > If the reader of this message is not the intended recipient, you are hereby > notified that any dissemination, use, distribution or copying of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. Thank you. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160526/d7c6c42b/attachment-0001.html From john.d.ament at gmail.com Thu May 26 10:22:52 2016 From: john.d.ament at gmail.com (John D. Ament) Date: Thu, 26 May 2016 14:22:52 +0000 Subject: [keycloak-user] Keycloak & Spring Boot In-Reply-To: References: Message-ID: No, I'm referring to this line: keycloak.credentials.secret = 11111111-1111-1111-1111-111111111111 How would I generate something like that? Is it just the value of "secret" on the Credentials tab of a client? John On Thu, May 26, 2016 at 9:05 AM Jeremy Simon wrote: > John, are you looking for the Spring Security UserDetails object? > jeremy > jeremy at jeremysimon.com > www.JeremySimon.com > > > On Wed, May 25, 2016 at 10:51 AM, John D. Ament > wrote: > > Hi, > > > > I was trying to follow the tutorial to add keycloak to a simple spring > boot > > app. > > > https://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#spring-boot-adapter > > > > It seems like there's a few steps missing. How do I generate the > credential > > used by the spring boot app? > > > > John > > > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160526/cebf8f7c/attachment.html From srossillo at smartling.com Thu May 26 13:11:09 2016 From: srossillo at smartling.com (Scott Rossillo) Date: Thu, 26 May 2016 13:11:09 -0400 Subject: [keycloak-user] How to apply updates to keycloak instances In-Reply-To: References: <87CBA013-76D9-4A1D-B64D-70FF432D8720@smartling.com> <097F53B6-6373-4E88-BF9F-8E1808B6295E@smartling.com> Message-ID: <981E7D4A-6A00-47DC-9BD1-166C2C922E3F@smartling.com> I guess it?s a matter of requirements, but with micro service architectures there?s usually some sort of discovery mechanism required to locale services at runtime. Netflix offers Eureka and then there?s etcd from CoreOS that?s being used by Kubernetes. My point is that even if Keycloak devs build some sort of way of picking up changes from the filesystem on startup, that doesn?t solve all use cases. It doesn?t solve issues with Dockerized deployments and it doesn?t solve the issue where services have to be located at runtime. Scott Rossillo Smartling | Senior Software Engineer srossillo at smartling.com > On May 26, 2016, at 2:27 AM, Stian Thorgersen wrote: > > > > On 26 May 2016 at 02:15, Jesse Chahal > wrote: > @Stian > The approach described sounds similar to liquibase to me but with json > and specific to keycloak. I feel like a lot of possible bugs could > arise from this approach or at least quite a few feature requests. > Would each json file only contain a single change? Would order matter > in how they get applied if you put a bunch of json files in this > directory at once? Can the same file be applied multiple times? These > are the kind of issues I would expect to come up with this type of > change management system. When I mentioned write our own tool/script > to do it I was kind of thinking of a writing a liquibase like system > that calls keycloak's rest api. > > We haven't figured out all the details, but what you are proposing sounds better. A single document that lists all changes, that can also import other files, sorts out the ordering and we could add same type of ids as Liquibase does to changesets. > > You could write it to use the rest api, then use a separate db to store what changes have been applied, but would be better if Keycloak deals with loading the changes directly as it can write to the db what changes have been applied. > > One big issue is what happens if manual changes are done through the admin console. One though (although probably very tricky to get right) is that changes done through the admin console is added to the changeset. > > > @ Scott > If I would compare the solution you mentioned to one of the options I > listed in my original question "I've also considered writing my own > updater tool using a scripting language (python/ruby) that calls > keycloak's rest api." The worrying thing to me is that there is > another piece of code that needs to maintained by our company and > requires quite a bit of knowledge of keycloak's rest api. There would > probably need to be some serious thought put into the architecture of > the tool as well. Without a doubt it does provide the most control. We > also live by a different methodology in regards to updating production > clusters. From our perspective it is more of an issue to update > manually as it becomes much easier to miss a step or in someway screw > up if steps are performed manually. I'm not sure what the security > implications would be from it occurring automatically, especially if > during each step there is thorough testing (including from a security > team). For our CI/CD pipeline our goal is to have it so every commit > can automagically end up on production without human intervention. > > Currently we use a combination of an initial realm file to be included > on startup and also use jq to modify the keycloak-server.json for new > keycloak clusters. We don't need to generate realm or client keys as > it is included in the initial realm file. That doesn't work for > existing systems backed by a database that cannot be thrown away. That > kind of leave me with the original option (and hardest) of "write a > proprietary liquibase like system built ontop of keycloaks rest api". > This is a hard problem to solve > > Why proprietary? If we can agree on a design we'll happily accept a contribution and maintain it as well. > > > On Mon, May 23, 2016 at 1:49 PM, Anthony Fryer > wrote: > > Thanks, I'll check it out. > > > > > > On 05:38, Tue, 24/05/2016 Scott Rossillo > wrote: > >> > >> We use Jose4J[0] to create the keys and then jq[1] to modify the realm > >> file. > >> > >> See the first line of code here for a super simple example of how to > >> generate realm keys: > >> https://bitbucket.org/b_c/jose4j/wiki/JWT%20Examples > >> > >> PS - this may be doable with Keycloak but Jose4J is very lightweight for > >> writing a simple script on a CI server. > >> > >> [0]: https://bitbucket.org/b_c/jose4j > >> [1]: https://stedolan.github.io/jq/ > >> > >> > >> Scott Rossillo > >> Smartling | Senior Software Engineer > >> srossillo at smartling.com > >> > >> On May 21, 2016, at 10:20 PM, Anthony Fryer > > >> wrote: > >> > >> Hi Scott, > >> > >> How do you generate the realm keys when creating the new keycloak dev > >> instances? Do you use a keycloak api or some other way? I'm interested in > >> having a standard realm template that is used to create new realms but would > >> need to change the realm keys when importing this template into keycloak. > >> > >> Cheers, > >> > >> Anthony > >> > >> On Sat, May 21, 2016 at 3:43 AM, Scott Rossillo > > >> wrote: > >>> > >>> We?re using Keycloak on production, stage/QA, development environments > >>> and every developer?s workstation / laptop. > >>> > >>> While there will always be differing options on how to successfully do > >>> change management, we?ve found a very effective method for handling Keycloak > >>> provisioning in all environments so that developers don?t need to mess > >>> around with. We?re a continuous integration / deployment shop using micro > >>> services and everything has to ?just work? ? I?ll give an overview of our > >>> process here but please keep in mind a few things: > >>> > >>> 1. This approach works for us, I?m not saying it?s the best way > >>> 2. We do _not_ allow production config changes to be automated due to > >>> security implications > >>> 3. We're very opinionated in our approach to configuration management and > >>> we don?t ever modify 3rd party software databases directly. We always use > >>> APIs. > >>> > >>> We deploy Keycloak to all environments using Docker images. On developer > >>> workstations we use Docker Compose to orchestrate bringing up all services a > >>> developer may need, including Keycloak. > >>> > >>> We have 4 docker images for Keycloak: > >>> - Keycloak Base > >>> \- Keycloak HA > >>> \- Keycloak Dev > >>> - Keycloak config manager* > >>> > >>> The base image includes all customizations necessary to bring up a > >>> Keycloak instance configured with our modules and themes installed. > >>> The HA instance builds off base and configures Keycloak to run as a > >>> cluster node. This is used on stage and prod. > >>> The dev instance builds off base and includes our realm file. On startup, > >>> this instance loads our realm configuration if it?s not already loaded. > >>> > >>> All docker images are built and published by the CI server and Keycloak > >>> HA can be deployed to stage and prod after a clean CI build. > >>> > >>> Developers are free to add clients for testing, do whatever they want, > >>> etc. to their running dev instance. If they want to get back to our stock > >>> build, they pull the latest Docker image from our private Docker repo and > >>> restart it. > >>> > >>> Adding clients to stage and prod requires approval and is done by a hand. > >>> This is for security reasons. Once a configuration change is detected on > >>> stage - say a client is added - our CI server exports the realm from stage, > >>> changes the realm keys, and creates a new Keycloak Dev instance with the > >>> updated realm file. > >>> > >>> *A word about configuration management: > >>> > >>> Obviously, the realm file we generate knows the URLs of staging services, > >>> not local or development environment URLs. To overcome this we introduced > >>> another Docker based service called the Keycloak configuration manger. It > >>> runs on development environments and workstations. It?s responsible for > >>> discovering running services and updating Keycloak via its admin endpoints > >>> to reflect the proper configuration for the given environment. > >>> > >>> That?s it. The whole process is automated with the exception of > >>> configuration changes to stage and prod which require a security review. > >>> > >>> Hope this helps. Let me know if you?d like me to elaborate on anything. > >>> > >>> Best, > >>> Scott > >>> > >>> Scott Rossillo > >>> Smartling | Senior Software Engineer > >>> srossillo at smartling.com > >>> > >>> On May 20, 2016, at 1:46 AM, Stian Thorgersen > > >>> wrote: > >>> > >>> Firstly, just wanted to highlight that core Keycloak team are devs, not > >>> sysadmins/ops guys, so we have limited experience in continuous delivery and > >>> maintenance of real production systems. Hence, we'd love input from the > >>> community on this. > >>> > >>> As it stands we don't really have a proper solution. I believe the best > >>> you can do at the moment is either using import feature, partial import or > >>> admin rest endpoints. Import is not going to work IMO as it requires > >>> re-creating the whole realm. Partial import may work, but would work best > >>> for new resources rather than modifying existing resources as it does a > >>> delete/create operation rather than attempt to modify. With the admin rest > >>> endpoints you'd get the best control of what's going on, but obviously that > >>> leaves a fair amount of the work. > >>> > >>> In the future we have an idea of introducing an "import directory" it > >>> would be possible to drop json files in here that would add, modify or > >>> delete resources (realms, clients, roles, users, whatever). This would allow > >>> dropping json files before the server starts and the server would then > >>> import on startup. It would also be possible to do this at runtime and new > >>> files would be detected at runtime. Finally, we also had an idea of an > >>> offline mode to run import of this (it would basically start the server > >>> without http listener, import files, then stop, so it could be used in a > >>> script/tool). Import is probably not the best name for it, as it would > >>> support modify and delete as well as "importing" new things. > >>> > >>> On 19 May 2016 at 19:53, Jesse Chahal > wrote: > >>>> > >>>> Following some of the best practices for continuous Integration and > >>>> continuous delivery there needs to be environments for build, test, > >>>> and production. This would mean that following these practices would > >>>> require you to have multiple versions of keycloak at different stages > >>>> of development cycle. Some of these environments might not have > >>>> important persistent data while others might. In order to have builds > >>>> transition from one environment to another there may be configuration > >>>> changes required for a build to be valid. This is especially true when > >>>> new services (openid clients) are being added or "default" accounts. > >>>> I'm trying to come up with a scripted way of updating keycloak > >>>> instances that are backed up by an RDMS. This may include adding new > >>>> clients, adding new users, updating realm config, etc... Originally I > >>>> was planning on simply exporting the realm config and importing it > >>>> every time keycloak starts. If I enabled the OVERWRITE option I might > >>>> overwrite things that I do not want overridden. This is especially > >>>> true if there is some config that differ's based on whether it is a > >>>> build, test, or production instance. If I don't enable it then it is > >>>> only useful for new/blank keycloak environments. I considered using > >>>> liquibase but since I do not have control of schema changes created by > >>>> the keycloak team I might run into issues with my liquibase file not > >>>> being valid after a migration/liquibase update by the keycloak team as > >>>> my liquibase file would run after keycloak's does. There might also be > >>>> some other unknown issues our liquibase changes conflicting somehow > >>>> with keycloak's liquibase changes. I've also considered writing my own > >>>> updater tool using a scripting language (python/ruby) that calls > >>>> keycloak's rest api. The issues with this mechanism is it feels like I > >>>> am recreating the wheel as well as not being able to find good > >>>> documentation on keycloak's openid endpoints/url's used for different > >>>> oauth2 flows. Even if I did find this documentation it would also > >>>> require me to find a good openid client for the scripting language. > >>>> This doesn't matter for our normal clients as they simply use the > >>>> keycloak subsystems and adapters instead. I've also looked at commonly > >>>> used server configuration software such as chef, puppet, and ansible. > >>>> I don't see a good solution using any of those tools yet either. What > >>>> have other people done for cases like this? Please don't tell me there > >>>> is someone who is doing this all manually because that doesn't work in > >>>> modern software development. > >>>> > >>>> - doesn't accidentally delete users > >>>> - doesn't accidentally delete clients > >>>> - doesn't invalidate sessions (optional) > >>>> - works to bring up new, correctly configured, keycloak instances > >>>> - handles applying updates to existing keycloak instances > >>>> - can handle minor differences between keycloak instances (build, > >>>> test, production) when updating > >>>> - preferably can work well in rolling deployment scenario's. > >>>> -- I hope the keycloak team is taking these into consideration when > >>>> doing database migration between 1-2 releases. It would be nice if > >>>> they set some specific rules for rolling updates between versions (aka > >>>> backwards breaking changes) > >>>> _______________________________________________ > >>>> keycloak-user mailing list > >>>> keycloak-user at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user > >>> > >>> > >>> _______________________________________________ > >>> keycloak-user mailing list > >>> keycloak-user at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/keycloak-user > >>> > >>> > >>> > >>> _______________________________________________ > >>> keycloak-user mailing list > >>> keycloak-user at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/keycloak-user > >> > >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160526/6303b454/attachment-0001.html From sthorger at redhat.com Thu May 26 13:41:04 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 26 May 2016 19:41:04 +0200 Subject: [keycloak-user] How to apply updates to keycloak instances In-Reply-To: <981E7D4A-6A00-47DC-9BD1-166C2C922E3F@smartling.com> References: <87CBA013-76D9-4A1D-B64D-70FF432D8720@smartling.com> <097F53B6-6373-4E88-BF9F-8E1808B6295E@smartling.com> <981E7D4A-6A00-47DC-9BD1-166C2C922E3F@smartling.com> Message-ID: On 26 May 2016 at 19:11, Scott Rossillo wrote: > I guess it?s a matter of requirements, but with micro service > architectures there?s usually some sort of discovery mechanism required to > locale services at runtime. Netflix offers Eureka and then there?s etcd > from CoreOS that?s being used by Kubernetes. My point is that even if > Keycloak devs build some sort of way of picking up changes from the > filesystem on startup, that doesn?t solve all use cases. > The problem is continuous integration right, and pushing changes from a test environment into production? So you need a reliable way to apply changes to both environments. > > It doesn?t solve issues with Dockerized deployments and it doesn?t solve > the issue where services have to be located at runtime > What are the issues it doesn't solve? > > Scott Rossillo > Smartling | Senior Software Engineer > srossillo at smartling.com > > On May 26, 2016, at 2:27 AM, Stian Thorgersen wrote: > > > > On 26 May 2016 at 02:15, Jesse Chahal wrote: > >> @Stian >> The approach described sounds similar to liquibase to me but with json >> and specific to keycloak. I feel like a lot of possible bugs could >> arise from this approach or at least quite a few feature requests. >> Would each json file only contain a single change? Would order matter >> in how they get applied if you put a bunch of json files in this >> directory at once? Can the same file be applied multiple times? These >> are the kind of issues I would expect to come up with this type of >> change management system. When I mentioned write our own tool/script >> to do it I was kind of thinking of a writing a liquibase like system >> that calls keycloak's rest api. >> > > We haven't figured out all the details, but what you are proposing sounds > better. A single document that lists all changes, that can also import > other files, sorts out the ordering and we could add same type of ids as > Liquibase does to changesets. > > You could write it to use the rest api, then use a separate db to store > what changes have been applied, but would be better if Keycloak deals with > loading the changes directly as it can write to the db what changes have > been applied. > > One big issue is what happens if manual changes are done through the admin > console. One though (although probably very tricky to get right) is that > changes done through the admin console is added to the changeset. > > >> >> @ Scott >> If I would compare the solution you mentioned to one of the options I >> listed in my original question "I've also considered writing my own >> updater tool using a scripting language (python/ruby) that calls >> keycloak's rest api." The worrying thing to me is that there is >> another piece of code that needs to maintained by our company and >> requires quite a bit of knowledge of keycloak's rest api. There would >> probably need to be some serious thought put into the architecture of >> the tool as well. Without a doubt it does provide the most control. We >> also live by a different methodology in regards to updating production >> clusters. From our perspective it is more of an issue to update >> manually as it becomes much easier to miss a step or in someway screw >> up if steps are performed manually. I'm not sure what the security >> implications would be from it occurring automatically, especially if >> during each step there is thorough testing (including from a security >> team). For our CI/CD pipeline our goal is to have it so every commit >> can automagically end up on production without human intervention. >> >> Currently we use a combination of an initial realm file to be included >> on startup and also use jq to modify the keycloak-server.json for new >> keycloak clusters. We don't need to generate realm or client keys as >> it is included in the initial realm file. That doesn't work for >> existing systems backed by a database that cannot be thrown away. That >> kind of leave me with the original option (and hardest) of "write a >> proprietary liquibase like system built ontop of keycloaks rest api". >> This is a hard problem to solve >> > > Why proprietary? If we can agree on a design we'll happily accept a > contribution and maintain it as well. > > >> >> On Mon, May 23, 2016 at 1:49 PM, Anthony Fryer >> wrote: >> > Thanks, I'll check it out. >> > >> > >> > On 05:38, Tue, 24/05/2016 Scott Rossillo >> wrote: >> >> >> >> We use Jose4J[0] to create the keys and then jq[1] to modify the realm >> >> file. >> >> >> >> See the first line of code here for a super simple example of how to >> >> generate realm keys: >> >> https://bitbucket.org/b_c/jose4j/wiki/JWT%20Examples >> >> >> >> PS - this may be doable with Keycloak but Jose4J is very lightweight >> for >> >> writing a simple script on a CI server. >> >> >> >> [0]: https://bitbucket.org/b_c/jose4j >> >> [1]: https://stedolan.github.io/jq/ >> >> >> >> >> >> Scott Rossillo >> >> Smartling | Senior Software Engineer >> >> srossillo at smartling.com >> >> >> >> On May 21, 2016, at 10:20 PM, Anthony Fryer >> >> wrote: >> >> >> >> Hi Scott, >> >> >> >> How do you generate the realm keys when creating the new keycloak dev >> >> instances? Do you use a keycloak api or some other way? I'm >> interested in >> >> having a standard realm template that is used to create new realms but >> would >> >> need to change the realm keys when importing this template into >> keycloak. >> >> >> >> Cheers, >> >> >> >> Anthony >> >> >> >> On Sat, May 21, 2016 at 3:43 AM, Scott Rossillo < >> srossillo at smartling.com> >> >> wrote: >> >>> >> >>> We?re using Keycloak on production, stage/QA, development environments >> >>> and every developer?s workstation / laptop. >> >>> >> >>> While there will always be differing options on how to successfully do >> >>> change management, we?ve found a very effective method for handling >> Keycloak >> >>> provisioning in all environments so that developers don?t need to mess >> >>> around with. We?re a continuous integration / deployment shop using >> micro >> >>> services and everything has to ?just work? ? I?ll give an overview of >> our >> >>> process here but please keep in mind a few things: >> >>> >> >>> 1. This approach works for us, I?m not saying it?s the best way >> >>> 2. We do _not_ allow production config changes to be automated due to >> >>> security implications >> >>> 3. We're very opinionated in our approach to configuration management >> and >> >>> we don?t ever modify 3rd party software databases directly. We always >> use >> >>> APIs. >> >>> >> >>> We deploy Keycloak to all environments using Docker images. On >> developer >> >>> workstations we use Docker Compose to orchestrate bringing up all >> services a >> >>> developer may need, including Keycloak. >> >>> >> >>> We have 4 docker images for Keycloak: >> >>> - Keycloak Base >> >>> \- Keycloak HA >> >>> \- Keycloak Dev >> >>> - Keycloak config manager* >> >>> >> >>> The base image includes all customizations necessary to bring up a >> >>> Keycloak instance configured with our modules and themes installed. >> >>> The HA instance builds off base and configures Keycloak to run as a >> >>> cluster node. This is used on stage and prod. >> >>> The dev instance builds off base and includes our realm file. On >> startup, >> >>> this instance loads our realm configuration if it?s not already >> loaded. >> >>> >> >>> All docker images are built and published by the CI server and >> Keycloak >> >>> HA can be deployed to stage and prod after a clean CI build. >> >>> >> >>> Developers are free to add clients for testing, do whatever they want, >> >>> etc. to their running dev instance. If they want to get back to our >> stock >> >>> build, they pull the latest Docker image from our private Docker repo >> and >> >>> restart it. >> >>> >> >>> Adding clients to stage and prod requires approval and is done by a >> hand. >> >>> This is for security reasons. Once a configuration change is detected >> on >> >>> stage - say a client is added - our CI server exports the realm from >> stage, >> >>> changes the realm keys, and creates a new Keycloak Dev instance with >> the >> >>> updated realm file. >> >>> >> >>> *A word about configuration management: >> >>> >> >>> Obviously, the realm file we generate knows the URLs of staging >> services, >> >>> not local or development environment URLs. To overcome this we >> introduced >> >>> another Docker based service called the Keycloak configuration >> manger. It >> >>> runs on development environments and workstations. It?s responsible >> for >> >>> discovering running services and updating Keycloak via its admin >> endpoints >> >>> to reflect the proper configuration for the given environment. >> >>> >> >>> That?s it. The whole process is automated with the exception of >> >>> configuration changes to stage and prod which require a security >> review. >> >>> >> >>> Hope this helps. Let me know if you?d like me to elaborate on >> anything. >> >>> >> >>> Best, >> >>> Scott >> >>> >> >>> Scott Rossillo >> >>> Smartling | Senior Software Engineer >> >>> srossillo at smartling.com >> >>> >> >>> On May 20, 2016, at 1:46 AM, Stian Thorgersen >> >>> wrote: >> >>> >> >>> Firstly, just wanted to highlight that core Keycloak team are devs, >> not >> >>> sysadmins/ops guys, so we have limited experience in continuous >> delivery and >> >>> maintenance of real production systems. Hence, we'd love input from >> the >> >>> community on this. >> >>> >> >>> As it stands we don't really have a proper solution. I believe the >> best >> >>> you can do at the moment is either using import feature, partial >> import or >> >>> admin rest endpoints. Import is not going to work IMO as it requires >> >>> re-creating the whole realm. Partial import may work, but would work >> best >> >>> for new resources rather than modifying existing resources as it does >> a >> >>> delete/create operation rather than attempt to modify. With the admin >> rest >> >>> endpoints you'd get the best control of what's going on, but >> obviously that >> >>> leaves a fair amount of the work. >> >>> >> >>> In the future we have an idea of introducing an "import directory" it >> >>> would be possible to drop json files in here that would add, modify or >> >>> delete resources (realms, clients, roles, users, whatever). This >> would allow >> >>> dropping json files before the server starts and the server would then >> >>> import on startup. It would also be possible to do this at runtime >> and new >> >>> files would be detected at runtime. Finally, we also had an idea of an >> >>> offline mode to run import of this (it would basically start the >> server >> >>> without http listener, import files, then stop, so it could be used >> in a >> >>> script/tool). Import is probably not the best name for it, as it would >> >>> support modify and delete as well as "importing" new things. >> >>> >> >>> On 19 May 2016 at 19:53, Jesse Chahal wrote: >> >>>> >> >>>> Following some of the best practices for continuous Integration and >> >>>> continuous delivery there needs to be environments for build, test, >> >>>> and production. This would mean that following these practices would >> >>>> require you to have multiple versions of keycloak at different stages >> >>>> of development cycle. Some of these environments might not have >> >>>> important persistent data while others might. In order to have builds >> >>>> transition from one environment to another there may be configuration >> >>>> changes required for a build to be valid. This is especially true >> when >> >>>> new services (openid clients) are being added or "default" accounts. >> >>>> I'm trying to come up with a scripted way of updating keycloak >> >>>> instances that are backed up by an RDMS. This may include adding new >> >>>> clients, adding new users, updating realm config, etc... Originally I >> >>>> was planning on simply exporting the realm config and importing it >> >>>> every time keycloak starts. If I enabled the OVERWRITE option I might >> >>>> overwrite things that I do not want overridden. This is especially >> >>>> true if there is some config that differ's based on whether it is a >> >>>> build, test, or production instance. If I don't enable it then it is >> >>>> only useful for new/blank keycloak environments. I considered using >> >>>> liquibase but since I do not have control of schema changes created >> by >> >>>> the keycloak team I might run into issues with my liquibase file not >> >>>> being valid after a migration/liquibase update by the keycloak team >> as >> >>>> my liquibase file would run after keycloak's does. There might also >> be >> >>>> some other unknown issues our liquibase changes conflicting somehow >> >>>> with keycloak's liquibase changes. I've also considered writing my >> own >> >>>> updater tool using a scripting language (python/ruby) that calls >> >>>> keycloak's rest api. The issues with this mechanism is it feels like >> I >> >>>> am recreating the wheel as well as not being able to find good >> >>>> documentation on keycloak's openid endpoints/url's used for different >> >>>> oauth2 flows. Even if I did find this documentation it would also >> >>>> require me to find a good openid client for the scripting language. >> >>>> This doesn't matter for our normal clients as they simply use the >> >>>> keycloak subsystems and adapters instead. I've also looked at >> commonly >> >>>> used server configuration software such as chef, puppet, and ansible. >> >>>> I don't see a good solution using any of those tools yet either. What >> >>>> have other people done for cases like this? Please don't tell me >> there >> >>>> is someone who is doing this all manually because that doesn't work >> in >> >>>> modern software development. >> >>>> >> >>>> - doesn't accidentally delete users >> >>>> - doesn't accidentally delete clients >> >>>> - doesn't invalidate sessions (optional) >> >>>> - works to bring up new, correctly configured, keycloak instances >> >>>> - handles applying updates to existing keycloak instances >> >>>> - can handle minor differences between keycloak instances (build, >> >>>> test, production) when updating >> >>>> - preferably can work well in rolling deployment scenario's. >> >>>> -- I hope the keycloak team is taking these into consideration when >> >>>> doing database migration between 1-2 releases. It would be nice if >> >>>> they set some specific rules for rolling updates between versions >> (aka >> >>>> backwards breaking changes) >> >>>> _______________________________________________ >> >>>> keycloak-user mailing list >> >>>> keycloak-user at lists.jboss.org >> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >>> >> >>> >> >>> _______________________________________________ >> >>> keycloak-user mailing list >> >>> keycloak-user at lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> keycloak-user mailing list >> >>> keycloak-user at lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> >> >> >> >> >> > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160526/6ab4cca4/attachment-0001.html From srossillo at smartling.com Thu May 26 13:47:26 2016 From: srossillo at smartling.com (Scott Rossillo) Date: Thu, 26 May 2016 13:47:26 -0400 Subject: [keycloak-user] How to apply updates to keycloak instances In-Reply-To: References: <87CBA013-76D9-4A1D-B64D-70FF432D8720@smartling.com> <097F53B6-6373-4E88-BF9F-8E1808B6295E@smartling.com> <981E7D4A-6A00-47DC-9BD1-166C2C922E3F@smartling.com> Message-ID: Stian, that?s fair, it does solve the OP's CI/CD problem when moving in the dev -> stage -> prod direction. Scott Rossillo Smartling | Senior Software Engineer srossillo at smartling.com > On May 26, 2016, at 1:41 PM, Stian Thorgersen wrote: > > > > On 26 May 2016 at 19:11, Scott Rossillo > wrote: > I guess it?s a matter of requirements, but with micro service architectures there?s usually some sort of discovery mechanism required to locale services at runtime. Netflix offers Eureka and then there?s etcd from CoreOS that?s being used by Kubernetes. My point is that even if Keycloak devs build some sort of way of picking up changes from the filesystem on startup, that doesn?t solve all use cases. > > The problem is continuous integration right, and pushing changes from a test environment into production? So you need a reliable way to apply changes to both environments. > > > It doesn?t solve issues with Dockerized deployments and it doesn?t solve the issue where services have to be located at runtime > > What are the issues it doesn't solve? > > > Scott Rossillo > Smartling | Senior Software Engineer > srossillo at smartling.com > >> On May 26, 2016, at 2:27 AM, Stian Thorgersen > wrote: >> >> >> >> On 26 May 2016 at 02:15, Jesse Chahal > wrote: >> @Stian >> The approach described sounds similar to liquibase to me but with json >> and specific to keycloak. I feel like a lot of possible bugs could >> arise from this approach or at least quite a few feature requests. >> Would each json file only contain a single change? Would order matter >> in how they get applied if you put a bunch of json files in this >> directory at once? Can the same file be applied multiple times? These >> are the kind of issues I would expect to come up with this type of >> change management system. When I mentioned write our own tool/script >> to do it I was kind of thinking of a writing a liquibase like system >> that calls keycloak's rest api. >> >> We haven't figured out all the details, but what you are proposing sounds better. A single document that lists all changes, that can also import other files, sorts out the ordering and we could add same type of ids as Liquibase does to changesets. >> >> You could write it to use the rest api, then use a separate db to store what changes have been applied, but would be better if Keycloak deals with loading the changes directly as it can write to the db what changes have been applied. >> >> One big issue is what happens if manual changes are done through the admin console. One though (although probably very tricky to get right) is that changes done through the admin console is added to the changeset. >> >> >> @ Scott >> If I would compare the solution you mentioned to one of the options I >> listed in my original question "I've also considered writing my own >> updater tool using a scripting language (python/ruby) that calls >> keycloak's rest api." The worrying thing to me is that there is >> another piece of code that needs to maintained by our company and >> requires quite a bit of knowledge of keycloak's rest api. There would >> probably need to be some serious thought put into the architecture of >> the tool as well. Without a doubt it does provide the most control. We >> also live by a different methodology in regards to updating production >> clusters. From our perspective it is more of an issue to update >> manually as it becomes much easier to miss a step or in someway screw >> up if steps are performed manually. I'm not sure what the security >> implications would be from it occurring automatically, especially if >> during each step there is thorough testing (including from a security >> team). For our CI/CD pipeline our goal is to have it so every commit >> can automagically end up on production without human intervention. >> >> Currently we use a combination of an initial realm file to be included >> on startup and also use jq to modify the keycloak-server.json for new >> keycloak clusters. We don't need to generate realm or client keys as >> it is included in the initial realm file. That doesn't work for >> existing systems backed by a database that cannot be thrown away. That >> kind of leave me with the original option (and hardest) of "write a >> proprietary liquibase like system built ontop of keycloaks rest api". >> This is a hard problem to solve >> >> Why proprietary? If we can agree on a design we'll happily accept a contribution and maintain it as well. >> >> >> On Mon, May 23, 2016 at 1:49 PM, Anthony Fryer > wrote: >> > Thanks, I'll check it out. >> > >> > >> > On 05:38, Tue, 24/05/2016 Scott Rossillo > wrote: >> >> >> >> We use Jose4J[0] to create the keys and then jq[1] to modify the realm >> >> file. >> >> >> >> See the first line of code here for a super simple example of how to >> >> generate realm keys: >> >> https://bitbucket.org/b_c/jose4j/wiki/JWT%20Examples >> >> >> >> PS - this may be doable with Keycloak but Jose4J is very lightweight for >> >> writing a simple script on a CI server. >> >> >> >> [0]: https://bitbucket.org/b_c/jose4j >> >> [1]: https://stedolan.github.io/jq/ >> >> >> >> >> >> Scott Rossillo >> >> Smartling | Senior Software Engineer >> >> srossillo at smartling.com >> >> >> >> On May 21, 2016, at 10:20 PM, Anthony Fryer > >> >> wrote: >> >> >> >> Hi Scott, >> >> >> >> How do you generate the realm keys when creating the new keycloak dev >> >> instances? Do you use a keycloak api or some other way? I'm interested in >> >> having a standard realm template that is used to create new realms but would >> >> need to change the realm keys when importing this template into keycloak. >> >> >> >> Cheers, >> >> >> >> Anthony >> >> >> >> On Sat, May 21, 2016 at 3:43 AM, Scott Rossillo > >> >> wrote: >> >>> >> >>> We?re using Keycloak on production, stage/QA, development environments >> >>> and every developer?s workstation / laptop. >> >>> >> >>> While there will always be differing options on how to successfully do >> >>> change management, we?ve found a very effective method for handling Keycloak >> >>> provisioning in all environments so that developers don?t need to mess >> >>> around with. We?re a continuous integration / deployment shop using micro >> >>> services and everything has to ?just work? ? I?ll give an overview of our >> >>> process here but please keep in mind a few things: >> >>> >> >>> 1. This approach works for us, I?m not saying it?s the best way >> >>> 2. We do _not_ allow production config changes to be automated due to >> >>> security implications >> >>> 3. We're very opinionated in our approach to configuration management and >> >>> we don?t ever modify 3rd party software databases directly. We always use >> >>> APIs. >> >>> >> >>> We deploy Keycloak to all environments using Docker images. On developer >> >>> workstations we use Docker Compose to orchestrate bringing up all services a >> >>> developer may need, including Keycloak. >> >>> >> >>> We have 4 docker images for Keycloak: >> >>> - Keycloak Base >> >>> \- Keycloak HA >> >>> \- Keycloak Dev >> >>> - Keycloak config manager* >> >>> >> >>> The base image includes all customizations necessary to bring up a >> >>> Keycloak instance configured with our modules and themes installed. >> >>> The HA instance builds off base and configures Keycloak to run as a >> >>> cluster node. This is used on stage and prod. >> >>> The dev instance builds off base and includes our realm file. On startup, >> >>> this instance loads our realm configuration if it?s not already loaded. >> >>> >> >>> All docker images are built and published by the CI server and Keycloak >> >>> HA can be deployed to stage and prod after a clean CI build. >> >>> >> >>> Developers are free to add clients for testing, do whatever they want, >> >>> etc. to their running dev instance. If they want to get back to our stock >> >>> build, they pull the latest Docker image from our private Docker repo and >> >>> restart it. >> >>> >> >>> Adding clients to stage and prod requires approval and is done by a hand. >> >>> This is for security reasons. Once a configuration change is detected on >> >>> stage - say a client is added - our CI server exports the realm from stage, >> >>> changes the realm keys, and creates a new Keycloak Dev instance with the >> >>> updated realm file. >> >>> >> >>> *A word about configuration management: >> >>> >> >>> Obviously, the realm file we generate knows the URLs of staging services, >> >>> not local or development environment URLs. To overcome this we introduced >> >>> another Docker based service called the Keycloak configuration manger. It >> >>> runs on development environments and workstations. It?s responsible for >> >>> discovering running services and updating Keycloak via its admin endpoints >> >>> to reflect the proper configuration for the given environment. >> >>> >> >>> That?s it. The whole process is automated with the exception of >> >>> configuration changes to stage and prod which require a security review. >> >>> >> >>> Hope this helps. Let me know if you?d like me to elaborate on anything. >> >>> >> >>> Best, >> >>> Scott >> >>> >> >>> Scott Rossillo >> >>> Smartling | Senior Software Engineer >> >>> srossillo at smartling.com >> >>> >> >>> On May 20, 2016, at 1:46 AM, Stian Thorgersen > >> >>> wrote: >> >>> >> >>> Firstly, just wanted to highlight that core Keycloak team are devs, not >> >>> sysadmins/ops guys, so we have limited experience in continuous delivery and >> >>> maintenance of real production systems. Hence, we'd love input from the >> >>> community on this. >> >>> >> >>> As it stands we don't really have a proper solution. I believe the best >> >>> you can do at the moment is either using import feature, partial import or >> >>> admin rest endpoints. Import is not going to work IMO as it requires >> >>> re-creating the whole realm. Partial import may work, but would work best >> >>> for new resources rather than modifying existing resources as it does a >> >>> delete/create operation rather than attempt to modify. With the admin rest >> >>> endpoints you'd get the best control of what's going on, but obviously that >> >>> leaves a fair amount of the work. >> >>> >> >>> In the future we have an idea of introducing an "import directory" it >> >>> would be possible to drop json files in here that would add, modify or >> >>> delete resources (realms, clients, roles, users, whatever). This would allow >> >>> dropping json files before the server starts and the server would then >> >>> import on startup. It would also be possible to do this at runtime and new >> >>> files would be detected at runtime. Finally, we also had an idea of an >> >>> offline mode to run import of this (it would basically start the server >> >>> without http listener, import files, then stop, so it could be used in a >> >>> script/tool). Import is probably not the best name for it, as it would >> >>> support modify and delete as well as "importing" new things. >> >>> >> >>> On 19 May 2016 at 19:53, Jesse Chahal > wrote: >> >>>> >> >>>> Following some of the best practices for continuous Integration and >> >>>> continuous delivery there needs to be environments for build, test, >> >>>> and production. This would mean that following these practices would >> >>>> require you to have multiple versions of keycloak at different stages >> >>>> of development cycle. Some of these environments might not have >> >>>> important persistent data while others might. In order to have builds >> >>>> transition from one environment to another there may be configuration >> >>>> changes required for a build to be valid. This is especially true when >> >>>> new services (openid clients) are being added or "default" accounts. >> >>>> I'm trying to come up with a scripted way of updating keycloak >> >>>> instances that are backed up by an RDMS. This may include adding new >> >>>> clients, adding new users, updating realm config, etc... Originally I >> >>>> was planning on simply exporting the realm config and importing it >> >>>> every time keycloak starts. If I enabled the OVERWRITE option I might >> >>>> overwrite things that I do not want overridden. This is especially >> >>>> true if there is some config that differ's based on whether it is a >> >>>> build, test, or production instance. If I don't enable it then it is >> >>>> only useful for new/blank keycloak environments. I considered using >> >>>> liquibase but since I do not have control of schema changes created by >> >>>> the keycloak team I might run into issues with my liquibase file not >> >>>> being valid after a migration/liquibase update by the keycloak team as >> >>>> my liquibase file would run after keycloak's does. There might also be >> >>>> some other unknown issues our liquibase changes conflicting somehow >> >>>> with keycloak's liquibase changes. I've also considered writing my own >> >>>> updater tool using a scripting language (python/ruby) that calls >> >>>> keycloak's rest api. The issues with this mechanism is it feels like I >> >>>> am recreating the wheel as well as not being able to find good >> >>>> documentation on keycloak's openid endpoints/url's used for different >> >>>> oauth2 flows. Even if I did find this documentation it would also >> >>>> require me to find a good openid client for the scripting language. >> >>>> This doesn't matter for our normal clients as they simply use the >> >>>> keycloak subsystems and adapters instead. I've also looked at commonly >> >>>> used server configuration software such as chef, puppet, and ansible. >> >>>> I don't see a good solution using any of those tools yet either. What >> >>>> have other people done for cases like this? Please don't tell me there >> >>>> is someone who is doing this all manually because that doesn't work in >> >>>> modern software development. >> >>>> >> >>>> - doesn't accidentally delete users >> >>>> - doesn't accidentally delete clients >> >>>> - doesn't invalidate sessions (optional) >> >>>> - works to bring up new, correctly configured, keycloak instances >> >>>> - handles applying updates to existing keycloak instances >> >>>> - can handle minor differences between keycloak instances (build, >> >>>> test, production) when updating >> >>>> - preferably can work well in rolling deployment scenario's. >> >>>> -- I hope the keycloak team is taking these into consideration when >> >>>> doing database migration between 1-2 releases. It would be nice if >> >>>> they set some specific rules for rolling updates between versions (aka >> >>>> backwards breaking changes) >> >>>> _______________________________________________ >> >>>> keycloak-user mailing list >> >>>> keycloak-user at lists.jboss.org >> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >>> >> >>> >> >>> _______________________________________________ >> >>> keycloak-user mailing list >> >>> keycloak-user at lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> keycloak-user mailing list >> >>> keycloak-user at lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> >> >> >> >> >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160526/6ffedd1c/attachment-0001.html From haimv at perfectomobile.com Thu May 26 14:20:07 2016 From: haimv at perfectomobile.com (Haim Vana) Date: Thu, 26 May 2016 18:20:07 +0000 Subject: [keycloak-user] How to create the same client (same id) for multiple realms programmatically In-Reply-To: <5746F714.6050007@redhat.com> References: <5746F714.6050007@redhat.com> Message-ID: Thanks for your reply. My problem was that I have used setId instead of setClientId. From: Marek Posolda [mailto:mposolda at redhat.com] Sent: Thursday, May 26, 2016 4:16 PM To: Haim Vana ; keycloak-user at lists.jboss.org Subject: Re: [keycloak-user] How to create the same client (same id) for multiple realms programmatically You can use for example: RealmResource realm1 = adminClient.realms().realm("realm1"); RealmResource realm2 = adminClient.realms().realm("realm2"); realm1.clients().create(clientRepresentation); realm2.clients().create(clientRepresentation); For update you can take a look at some of our tests, which are updating client. For example this one : https://github.com/mposolda/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/admin/ClientTest.java#L183 Note that you need to know client Id (this is different thant clientId). The easiest is to set it manually in representation before you create client (via client.setId ) like it's done in this test. Marek On 26/05/16 14:54, Haim Vana wrote: Any idea regarding the below ? As a workaround how can I update existing client programmatically ? I couldn't find it in the admin API. Thanks again, Haim. From: Haim Vana Sent: Thursday, May 26, 2016 2:17 PM To: keycloak-user at lists.jboss.org Subject: How to create the same client (same id) for multiple realms programmatically Hi, I am trying to create the same client for many realms, however it creates it only once, probably because they have the same id, however in UI I am able to create it. Any idea how I can create the same client for different realms programmatically with the same id ? This is my code sample: ClientRepresentation clientRepresentation = new ClientRepresentation(); clientRepresentation.setId(clientId); // Same clientId for all reamls realm.clients().create(clientRepresentation); // Client is created only for first realm Any advice will be appreciated, Haim. The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160526/2ce6363b/attachment.html From hr.stoyanov at peruncs.com Thu May 26 15:10:45 2016 From: hr.stoyanov at peruncs.com (Hristo Stoyanov) Date: Thu, 26 May 2016 19:10:45 +0000 Subject: [keycloak-user] Is KC a good fit for your business case? Message-ID: Hi all, I wanted to share my thought process of fitting KC against a very common use case. Perhaps this would lead to better docs (so other can avoid this process or ask the same questions in this forum) Use case: Build a fictious "Utlimate Produce Store Web App" SaaS application for produce store management. Basically, a produce store owner wants to register his/her store, link it to credit ard/bank account, and add other staffers under the store registration. It boils down to two roles per store registartion: 1. admins - can add/delete staffers, store credit cards and everything a staffer can do. 2. staffers - limited store management activites. Here is how I look at KC for utilizing it for this kind of SaaS app: 1. Map each produce store to a separate Realm. Register store admin users with "manage users" realm-level built-in role. ================== A. pros a1 Leverage almost all of UI of KC a2 there is some "multi-tenancy" section of the documentation, but it is not clear if the one can dynamically assign/remove realm to a WAR app. B. cons b1 Nothing in the KC suggest that realms can be created dynamically. There is lots of xml/json configurations that go into specific places, and with each realm b2 WAR app files need to have the realm hard-coded in the web.xml b2 No attributes for realms? There are attributes for users and groups, but not for clients,roles,realms. (Someone explain the thought process here...) b3 How does KC scales with 1000s of realms? b4 Realms can not share users (A store staffer can work at two stores, I suppose, and a manager can have several stores) b5 Produce store manager will see "user federation" in the menu that would confuse them a lot! 2. Map each produce store to a KC client. All under the same realm "Utlimate Produce Store Web App" =================== A. pros a1. It looks like clients can be created dynamically without json/xml configuration. a2. There are "cleint templates" which can make the process even simpler. a3. The admin console has search for clients, which suggests that this approach may scale - e.g. having 1000s of clients a4. Via the KC Events, one can detect when a new user registers under the realm and automatically create a client(produce store) for him/her. a5. A user can work in one or more stores (clients) B. cons b1. There is no admin console at the client level in KC to be leveraged. This would need to be developed from scratch. b2. Clients do not have attributes. A workaround is to create a surrogate group in each client, solely for the purpose of storing produce store attributes (e.g credit card) b3. UI for adding/removing people to store registration needs to be developed from scratch. Nothing out-of-the-box. 3. Map each produce store to a group. Have a single client "Utlimate Produce Store Web App" under a bogus realm. ==================== A. pros a1. Groups have attributes. There can even be a hierarchy of them for more sophisticated arrangements. a2. Each store can have specific group hierarchy. a3. A user can work in one or more stores (clients) B. cons b1. Virtually no usefull KC out-of-the-box UI for managing groups on per-group bases. You cant really give store owners realm-level priviledges b2. The realm admin console does not look like optimized for serch managaement of large number of groups I do not know if I am on the right track and would have to spend significant time reading KC docs and Java sources to figure out A/ if KC is a good choice, and B/ if so, which appoach is best for such a common SaaS business case. The point here is that the KC documentation should discuss such business scenarious a lot more and help solution architects decide quickly the 2 most important questions: - Is KC right for my web/mobile app needs. - If so, how do I map KC concepts to my business domain withouth making costly mistakes. /Hristo Stoyanov -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160526/be885448/attachment-0001.html From sthorger at redhat.com Thu May 26 15:13:55 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 26 May 2016 21:13:55 +0200 Subject: [keycloak-user] Keycloak 1.9.5.Final Released Message-ID: Keycloak 1.9.5.Final has just been released. There's one change worth highlighting in this release. We've increased the default password hashing intervals to 20000. Yes, you read that right. We've actually recommended using 20000 for a while now, but the default was only 1. This is a clear trade-off between performance and how secure passwords are stored. With 1 password hashing interval it takes less than 1 ms to hash a password, while with 20000 it takes tens of ms. For the full list of resolved issues check out JIRA and to download the release go to the Keycloak homepage . -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160526/03afc21d/attachment.html From robin1233 at gmail.com Thu May 26 15:59:10 2016 From: robin1233 at gmail.com (robinfernandes .) Date: Thu, 26 May 2016 15:59:10 -0400 Subject: [keycloak-user] SAML Mappers Message-ID: Hi All, I am trying to connect Shibboleth IdP as an external IdP with Keycloak acting as an SP. I get the email of the user with friendly name as "mail" back in the SAML assertions. I want to set this as my username for this user in Keycloak. I am attaching a screenshot of my configurations for the mappers which is not working. Maybe someone might have resolved this already or know how to solve it? Thanks, Robin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160526/412cee36/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: keycloak-mappers.JPG Type: image/jpeg Size: 33806 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160526/412cee36/attachment-0001.jpe From mposolda at redhat.com Thu May 26 16:34:07 2016 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 26 May 2016 22:34:07 +0200 Subject: [keycloak-user] SAML Mappers In-Reply-To: References: Message-ID: <57475DBF.4060009@redhat.com> I am not sure at 100% and didn't try, but it seems that what you need is mapper of type "Username template importer" (corresponding Java class is org.keycloak.broker.saml.mappers.UsernameTemplateMapper ) and you configure the template attribute with value: ATTRIBUTE.mail Hope it helps, Marek On 26/05/16 21:59, robinfernandes . wrote: > Hi All, > > I am trying to connect Shibboleth IdP as an external IdP with Keycloak > acting as an SP. > I get the email of the user with friendly name as "mail" back in the > SAML assertions. I want to set this as my username for this user in > Keycloak. > > I am attaching a screenshot of my configurations for the mappers which > is not working. Maybe someone might have resolved this already or know > how to solve it? > > Thanks, > Robin > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160526/296e4200/attachment.html From fabricio.milone at shinetech.com Thu May 26 19:39:06 2016 From: fabricio.milone at shinetech.com (Fabricio Milone) Date: Fri, 27 May 2016 09:39:06 +1000 Subject: [keycloak-user] Non Browser based TOTP setup Message-ID: Hi all, I am trying to find a way to setup a (optional) TOTP for an specific user using an endpoint, but I couldn't find anything like that in the documentation. Is that even possible? is it something that you will include at some point in your roadmap? The scenario is a native mobile app using keycloak through endpoints (registration, login, logout, etc). I know that's not the way you recommend, but sadly I cannot change that. TOTP is currently working if I set it up using the account management console and I'm trying to re use those calls, but they use cookies included in the requests and that model just doesn't fit on my requirements. I'd really appreciate a little guidance if it is possible to create an SPI (I have some already) to do such task. Thanks in advance, Regards, Fab -- *Fabricio Milone* Developer *Shine Consulting * 30/600 Bourke Street Melbourne VIC 3000 T: 03 8488 9939 M: 04 3200 4006 www.shinetech.com *a* passion for excellence -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160527/efacee54/attachment.html From sthorger at redhat.com Fri May 27 01:33:09 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 27 May 2016 07:33:09 +0200 Subject: [keycloak-user] Non Browser based TOTP setup In-Reply-To: References: Message-ID: Do you have login working without OTP? That would be the first step and it sounds like you may not have that working based on you're looking at account management console. You should use direct grant api (what OIDC calls resource owner credential grant). Take a look at http://keycloak.github.io/docs/userguide/keycloak-server/html/direct-access-grants.html . Also, seriously reconsider how you're doing this implementation. For a better user experience I would strongly recommend using an external user agent. This is what is recommended by OAuth/OIDC specs as well as by us. On 27 May 2016 at 01:39, Fabricio Milone wrote: > Hi all, > > I am trying to find a way to setup a (optional) TOTP for an specific user > using an endpoint, but I couldn't find anything like that in the > documentation. Is that even possible? is it something that you will include > at some point in your roadmap? > > The scenario is a native mobile app using keycloak through endpoints > (registration, login, logout, etc). I know that's not the way you > recommend, but sadly I cannot change that. > > TOTP is currently working if I set it up using the account management > console and I'm trying to re use those calls, but they use cookies included > in the requests and that model just doesn't fit on my requirements. > > I'd really appreciate a little guidance if it is possible to create an SPI > (I have some already) to do such task. > > Thanks in advance, > > Regards, > Fab > > -- > *Fabricio Milone* > Developer > > *Shine Consulting * > > 30/600 Bourke Street > > Melbourne VIC 3000 > > T: 03 8488 9939 > > M: 04 3200 4006 > > > www.shinetech.com *a* passion for excellence > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160527/baaa4b0b/attachment.html From sthorger at redhat.com Fri May 27 02:04:52 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 27 May 2016 08:04:52 +0200 Subject: [keycloak-user] Is KC a good fit for your business case? In-Reply-To: References: Message-ID: I'm not sure what type of documentation you have in mind, but one thought we had in the past was to create blueprints for various architectures. Correct me if I'm wrong, but I wouldn't think a SaaS application like this would be that common and it also comes with a lot of nuances that drastically changes how you setup things. So maybe in this type of situations it's better to ask on the user forum or contact Red Hat sales to get some support? Based on your questions (or cons) below you've not included near details to give you any exact advice. It also sounds like you have a fairly advanced use-case. A few comments though: * It doesn't sound like you should use realms as they are designed to be fully isolated from each other. Although you can use identity brokering to allow users from one realm to authenticate to another realm. * We're aware that the admin endpoints/console doesn't allow more fine grained authorization. Hence you're not able to create admins that can only manage a subset of users and clients. * Keycloak is not a datastore. It sounds like you want to store attributes against a realm and/or clients that really don't belong there. Realms store configuration data specific to Keycloak and same with clients. You need an application level database for your produce store for those details. As an educated guess from your pros/cons (a list of requirements would have been better): * Use a single realm * Use a client per produce store * Use a group or roles to associate users with produce stores. Do you have users that are admins in one store and staff in another? Probably not, so you could have two roles (admin, staff) and one group per produce store * Use the multi tenancy support in the adapter to select the correct client for the produce store (I assume based on a URL or something) * Store details about produce store in your produce store application, not in Keycloak. This includes safely storing credit card details, which needs to be encrypted in your produce store database * For user management you'd need to create your own application as we don't have a way to allow admins to only manage a subset of users. That is planned for the future, but it's going to be a while until we get to it On 26 May 2016 at 21:10, Hristo Stoyanov wrote: > Hi all, > I wanted to share my thought process of fitting KC against a very common > use case. > Perhaps this would lead to better docs (so other can avoid this process or > ask the same questions in this forum) > > Use case: > Build a fictious "Utlimate Produce Store Web App" SaaS application for > produce store management. Basically, > a produce store owner wants to register his/her store, link it to credit > ard/bank account, > and add other staffers under the store registration. It boils down to two > roles per store registartion: > 1. admins - can add/delete staffers, store credit cards and everything a > staffer can do. > 2. staffers - limited store management activites. > > Here is how I look at KC for utilizing it for this kind of SaaS app: > > 1. Map each produce store to a separate Realm. Register store admin users > with "manage users" realm-level built-in role. > ================== > A. pros > a1 Leverage almost all of UI of KC > a2 there is some "multi-tenancy" section of the documentation, but it > is not clear if the one can dynamically assign/remove realm to a WAR app. > B. cons > b1 Nothing in the KC suggest that realms can be created dynamically. > There is lots of xml/json configurations that go into specific places, and > with each realm > b2 WAR app files need to have the realm hard-coded in the web.xml > b2 No attributes for realms? There are attributes for users and groups, > but not for clients,roles,realms. (Someone explain the thought process > here...) > b3 How does KC scales with 1000s of realms? > b4 Realms can not share users (A store staffer can work at two stores, > I suppose, and a manager can have several stores) > b5 Produce store manager will see "user federation" in the menu that > would confuse them a lot! > > > 2. Map each produce store to a KC client. All under the same realm > "Utlimate Produce Store Web App" > =================== > A. pros > a1. It looks like clients can be created dynamically without json/xml > configuration. > a2. There are "cleint templates" which can make the process even > simpler. > a3. The admin console has search for clients, which suggests that this > approach may scale - e.g. having 1000s of clients > a4. Via the KC Events, one can detect when a new user registers under > the realm and automatically create a client(produce store) for him/her. > a5. A user can work in one or more stores (clients) > B. cons > b1. There is no admin console at the client level in KC to be > leveraged. This would need to be developed from scratch. > b2. Clients do not have attributes. A workaround is to create a > surrogate group in each client, solely for the purpose of storing produce > store attributes (e.g credit card) > b3. UI for adding/removing people to store registration needs to be > developed from scratch. Nothing out-of-the-box. > > > 3. Map each produce store to a group. Have a single client "Utlimate > Produce Store Web App" under a bogus realm. > ==================== > A. pros > a1. Groups have attributes. There can even be a hierarchy of them for > more sophisticated arrangements. > a2. Each store can have specific group hierarchy. > a3. A user can work in one or more stores (clients) > B. cons > b1. Virtually no usefull KC out-of-the-box UI for managing groups on > per-group bases. You cant really give store owners realm-level priviledges > b2. The realm admin console does not look like optimized for serch > managaement of large number of groups > > I do not know if I am on the right track and would have to spend > significant time reading KC docs and Java sources to figure out > A/ if KC is a good choice, and B/ if so, which appoach is best for such a > common SaaS business case. > > The point here is that the KC documentation should discuss such business > scenarious a lot more and help solution architects decide > quickly the 2 most important questions: > - Is KC right for my web/mobile app needs. > - If so, how do I map KC concepts to my business domain withouth making > costly mistakes. > > /Hristo Stoyanov > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160527/754dd6fd/attachment-0001.html From fabricio.milone at shinetech.com Fri May 27 02:10:51 2016 From: fabricio.milone at shinetech.com (Fabricio Milone) Date: Fri, 27 May 2016 16:10:51 +1000 Subject: [keycloak-user] Non Browser based TOTP setup In-Reply-To: References: Message-ID: Hi Stian, I do have a working direct grants flow. I also have some SPIs to complete the entire set of functionality that was requested. Sadly, I cannot modify those requirements and it is not possible to use the browser based login (I would love to, really!). What I did today was I created some SPIs under /auth/realms/realm/that allows me to get the following - otp image base64 url encoded. - otp secret and code another endpoint that using those parameters plus a code from the authenticator, set up the otp to the specified user and finally an endpoint to check if otp is enabled and remove it from the account. I'm testing it right now and seems to be working pretty well. I think that resolved my issues so far, unless I find something odd in the next days :) Thanks, Regards, Fab On 27 May 2016 at 15:33, Stian Thorgersen wrote: > Do you have login working without OTP? That would be the first step and it > sounds like you may not have that working based on you're looking at > account management console. You should use direct grant api (what OIDC > calls resource owner credential grant). Take a look at > http://keycloak.github.io/docs/userguide/keycloak-server/html/direct-access-grants.html > . > > Also, seriously reconsider how you're doing this implementation. For a > better user experience I would strongly recommend using an external user > agent. This is what is recommended by OAuth/OIDC specs as well as by us. > > On 27 May 2016 at 01:39, Fabricio Milone > wrote: > >> Hi all, >> >> I am trying to find a way to setup a (optional) TOTP for an specific user >> using an endpoint, but I couldn't find anything like that in the >> documentation. Is that even possible? is it something that you will include >> at some point in your roadmap? >> > >> The scenario is a native mobile app using keycloak through endpoints >> (registration, login, logout, etc). I know that's not the way you >> recommend, but sadly I cannot change that. >> > >> TOTP is currently working if I set it up using the account management >> console and I'm trying to re use those calls, but they use cookies included >> in the requests and that model just doesn't fit on my requirements. >> >> I'd really appreciate a little guidance if it is possible to create an >> SPI (I have some already) to do such task. >> >> Thanks in advance, >> >> Regards, >> Fab >> >> -- >> *Fabricio Milone* >> Developer >> >> *Shine Consulting * >> >> 30/600 Bourke Street >> >> Melbourne VIC 3000 >> >> T: 03 8488 9939 >> >> M: 04 3200 4006 >> >> >> www.shinetech.com *a* passion for excellence >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > -- *Fabricio Milone* Developer *Shine Consulting * 30/600 Bourke Street Melbourne VIC 3000 T: 03 8488 9939 M: 04 3200 4006 www.shinetech.com *a* passion for excellence -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160527/a46a3691/attachment.html From sthorger at redhat.com Fri May 27 02:19:13 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 27 May 2016 08:19:13 +0200 Subject: [keycloak-user] How to apply updates to keycloak instances In-Reply-To: References: <87CBA013-76D9-4A1D-B64D-70FF432D8720@smartling.com> <097F53B6-6373-4E88-BF9F-8E1808B6295E@smartling.com> <981E7D4A-6A00-47DC-9BD1-166C2C922E3F@smartling.com> Message-ID: Can you give me some examples of issues around Dockerized deployments and services that are located at runtime (do you mean services that are provisioned at runtime?)? On 26 May 2016 at 19:47, Scott Rossillo wrote: > Stian, that?s fair, it does solve the OP's CI/CD problem when moving in > the dev -> stage -> prod direction. > > Scott Rossillo > Smartling | Senior Software Engineer > srossillo at smartling.com > > On May 26, 2016, at 1:41 PM, Stian Thorgersen wrote: > > > > On 26 May 2016 at 19:11, Scott Rossillo wrote: > >> I guess it?s a matter of requirements, but with micro service >> architectures there?s usually some sort of discovery mechanism required to >> locale services at runtime. Netflix offers Eureka and then there?s etcd >> from CoreOS that?s being used by Kubernetes. My point is that even if >> Keycloak devs build some sort of way of picking up changes from the >> filesystem on startup, that doesn?t solve all use cases. >> > > The problem is continuous integration right, and pushing changes from a > test environment into production? So you need a reliable way to apply > changes to both environments. > > >> >> It doesn?t solve issues with Dockerized deployments and it doesn?t solve >> the issue where services have to be located at runtime >> > > What are the issues it doesn't solve? > > >> >> Scott Rossillo >> Smartling | Senior Software Engineer >> srossillo at smartling.com >> >> On May 26, 2016, at 2:27 AM, Stian Thorgersen >> wrote: >> >> >> >> On 26 May 2016 at 02:15, Jesse Chahal wrote: >> >>> @Stian >>> The approach described sounds similar to liquibase to me but with json >>> and specific to keycloak. I feel like a lot of possible bugs could >>> arise from this approach or at least quite a few feature requests. >>> Would each json file only contain a single change? Would order matter >>> in how they get applied if you put a bunch of json files in this >>> directory at once? Can the same file be applied multiple times? These >>> are the kind of issues I would expect to come up with this type of >>> change management system. When I mentioned write our own tool/script >>> to do it I was kind of thinking of a writing a liquibase like system >>> that calls keycloak's rest api. >>> >> >> We haven't figured out all the details, but what you are proposing sounds >> better. A single document that lists all changes, that can also import >> other files, sorts out the ordering and we could add same type of ids as >> Liquibase does to changesets. >> >> You could write it to use the rest api, then use a separate db to store >> what changes have been applied, but would be better if Keycloak deals with >> loading the changes directly as it can write to the db what changes have >> been applied. >> >> One big issue is what happens if manual changes are done through the >> admin console. One though (although probably very tricky to get right) is >> that changes done through the admin console is added to the changeset. >> >> >>> >>> @ Scott >>> If I would compare the solution you mentioned to one of the options I >>> listed in my original question "I've also considered writing my own >>> updater tool using a scripting language (python/ruby) that calls >>> keycloak's rest api." The worrying thing to me is that there is >>> another piece of code that needs to maintained by our company and >>> requires quite a bit of knowledge of keycloak's rest api. There would >>> probably need to be some serious thought put into the architecture of >>> the tool as well. Without a doubt it does provide the most control. We >>> also live by a different methodology in regards to updating production >>> clusters. From our perspective it is more of an issue to update >>> manually as it becomes much easier to miss a step or in someway screw >>> up if steps are performed manually. I'm not sure what the security >>> implications would be from it occurring automatically, especially if >>> during each step there is thorough testing (including from a security >>> team). For our CI/CD pipeline our goal is to have it so every commit >>> can automagically end up on production without human intervention. >>> >>> Currently we use a combination of an initial realm file to be included >>> on startup and also use jq to modify the keycloak-server.json for new >>> keycloak clusters. We don't need to generate realm or client keys as >>> it is included in the initial realm file. That doesn't work for >>> existing systems backed by a database that cannot be thrown away. That >>> kind of leave me with the original option (and hardest) of "write a >>> proprietary liquibase like system built ontop of keycloaks rest api". >>> This is a hard problem to solve >>> >> >> Why proprietary? If we can agree on a design we'll happily accept a >> contribution and maintain it as well. >> >> >>> >>> On Mon, May 23, 2016 at 1:49 PM, Anthony Fryer >>> wrote: >>> > Thanks, I'll check it out. >>> > >>> > >>> > On 05:38, Tue, 24/05/2016 Scott Rossillo >>> wrote: >>> >> >>> >> We use Jose4J[0] to create the keys and then jq[1] to modify the realm >>> >> file. >>> >> >>> >> See the first line of code here for a super simple example of how to >>> >> generate realm keys: >>> >> https://bitbucket.org/b_c/jose4j/wiki/JWT%20Examples >>> >> >>> >> PS - this may be doable with Keycloak but Jose4J is very lightweight >>> for >>> >> writing a simple script on a CI server. >>> >> >>> >> [0]: https://bitbucket.org/b_c/jose4j >>> >> [1]: https://stedolan.github.io/jq/ >>> >> >>> >> >>> >> Scott Rossillo >>> >> Smartling | Senior Software Engineer >>> >> srossillo at smartling.com >>> >> >>> >> On May 21, 2016, at 10:20 PM, Anthony Fryer >>> >> wrote: >>> >> >>> >> Hi Scott, >>> >> >>> >> How do you generate the realm keys when creating the new keycloak dev >>> >> instances? Do you use a keycloak api or some other way? I'm >>> interested in >>> >> having a standard realm template that is used to create new realms >>> but would >>> >> need to change the realm keys when importing this template into >>> keycloak. >>> >> >>> >> Cheers, >>> >> >>> >> Anthony >>> >> >>> >> On Sat, May 21, 2016 at 3:43 AM, Scott Rossillo < >>> srossillo at smartling.com> >>> >> wrote: >>> >>> >>> >>> We?re using Keycloak on production, stage/QA, development >>> environments >>> >>> and every developer?s workstation / laptop. >>> >>> >>> >>> While there will always be differing options on how to successfully >>> do >>> >>> change management, we?ve found a very effective method for handling >>> Keycloak >>> >>> provisioning in all environments so that developers don?t need to >>> mess >>> >>> around with. We?re a continuous integration / deployment shop using >>> micro >>> >>> services and everything has to ?just work? ? I?ll give an overview >>> of our >>> >>> process here but please keep in mind a few things: >>> >>> >>> >>> 1. This approach works for us, I?m not saying it?s the best way >>> >>> 2. We do _not_ allow production config changes to be automated due to >>> >>> security implications >>> >>> 3. We're very opinionated in our approach to configuration >>> management and >>> >>> we don?t ever modify 3rd party software databases directly. We >>> always use >>> >>> APIs. >>> >>> >>> >>> We deploy Keycloak to all environments using Docker images. On >>> developer >>> >>> workstations we use Docker Compose to orchestrate bringing up all >>> services a >>> >>> developer may need, including Keycloak. >>> >>> >>> >>> We have 4 docker images for Keycloak: >>> >>> - Keycloak Base >>> >>> \- Keycloak HA >>> >>> \- Keycloak Dev >>> >>> - Keycloak config manager* >>> >>> >>> >>> The base image includes all customizations necessary to bring up a >>> >>> Keycloak instance configured with our modules and themes installed. >>> >>> The HA instance builds off base and configures Keycloak to run as a >>> >>> cluster node. This is used on stage and prod. >>> >>> The dev instance builds off base and includes our realm file. On >>> startup, >>> >>> this instance loads our realm configuration if it?s not already >>> loaded. >>> >>> >>> >>> All docker images are built and published by the CI server and >>> Keycloak >>> >>> HA can be deployed to stage and prod after a clean CI build. >>> >>> >>> >>> Developers are free to add clients for testing, do whatever they >>> want, >>> >>> etc. to their running dev instance. If they want to get back to our >>> stock >>> >>> build, they pull the latest Docker image from our private Docker >>> repo and >>> >>> restart it. >>> >>> >>> >>> Adding clients to stage and prod requires approval and is done by a >>> hand. >>> >>> This is for security reasons. Once a configuration change is >>> detected on >>> >>> stage - say a client is added - our CI server exports the realm from >>> stage, >>> >>> changes the realm keys, and creates a new Keycloak Dev instance with >>> the >>> >>> updated realm file. >>> >>> >>> >>> *A word about configuration management: >>> >>> >>> >>> Obviously, the realm file we generate knows the URLs of staging >>> services, >>> >>> not local or development environment URLs. To overcome this we >>> introduced >>> >>> another Docker based service called the Keycloak configuration >>> manger. It >>> >>> runs on development environments and workstations. It?s responsible >>> for >>> >>> discovering running services and updating Keycloak via its admin >>> endpoints >>> >>> to reflect the proper configuration for the given environment. >>> >>> >>> >>> That?s it. The whole process is automated with the exception of >>> >>> configuration changes to stage and prod which require a security >>> review. >>> >>> >>> >>> Hope this helps. Let me know if you?d like me to elaborate on >>> anything. >>> >>> >>> >>> Best, >>> >>> Scott >>> >>> >>> >>> Scott Rossillo >>> >>> Smartling | Senior Software Engineer >>> >>> srossillo at smartling.com >>> >>> >>> >>> On May 20, 2016, at 1:46 AM, Stian Thorgersen >>> >>> wrote: >>> >>> >>> >>> Firstly, just wanted to highlight that core Keycloak team are devs, >>> not >>> >>> sysadmins/ops guys, so we have limited experience in continuous >>> delivery and >>> >>> maintenance of real production systems. Hence, we'd love input from >>> the >>> >>> community on this. >>> >>> >>> >>> As it stands we don't really have a proper solution. I believe the >>> best >>> >>> you can do at the moment is either using import feature, partial >>> import or >>> >>> admin rest endpoints. Import is not going to work IMO as it requires >>> >>> re-creating the whole realm. Partial import may work, but would work >>> best >>> >>> for new resources rather than modifying existing resources as it >>> does a >>> >>> delete/create operation rather than attempt to modify. With the >>> admin rest >>> >>> endpoints you'd get the best control of what's going on, but >>> obviously that >>> >>> leaves a fair amount of the work. >>> >>> >>> >>> In the future we have an idea of introducing an "import directory" it >>> >>> would be possible to drop json files in here that would add, modify >>> or >>> >>> delete resources (realms, clients, roles, users, whatever). This >>> would allow >>> >>> dropping json files before the server starts and the server would >>> then >>> >>> import on startup. It would also be possible to do this at runtime >>> and new >>> >>> files would be detected at runtime. Finally, we also had an idea of >>> an >>> >>> offline mode to run import of this (it would basically start the >>> server >>> >>> without http listener, import files, then stop, so it could be used >>> in a >>> >>> script/tool). Import is probably not the best name for it, as it >>> would >>> >>> support modify and delete as well as "importing" new things. >>> >>> >>> >>> On 19 May 2016 at 19:53, Jesse Chahal wrote: >>> >>>> >>> >>>> Following some of the best practices for continuous Integration and >>> >>>> continuous delivery there needs to be environments for build, test, >>> >>>> and production. This would mean that following these practices would >>> >>>> require you to have multiple versions of keycloak at different >>> stages >>> >>>> of development cycle. Some of these environments might not have >>> >>>> important persistent data while others might. In order to have >>> builds >>> >>>> transition from one environment to another there may be >>> configuration >>> >>>> changes required for a build to be valid. This is especially true >>> when >>> >>>> new services (openid clients) are being added or "default" accounts. >>> >>>> I'm trying to come up with a scripted way of updating keycloak >>> >>>> instances that are backed up by an RDMS. This may include adding new >>> >>>> clients, adding new users, updating realm config, etc... Originally >>> I >>> >>>> was planning on simply exporting the realm config and importing it >>> >>>> every time keycloak starts. If I enabled the OVERWRITE option I >>> might >>> >>>> overwrite things that I do not want overridden. This is especially >>> >>>> true if there is some config that differ's based on whether it is a >>> >>>> build, test, or production instance. If I don't enable it then it is >>> >>>> only useful for new/blank keycloak environments. I considered using >>> >>>> liquibase but since I do not have control of schema changes created >>> by >>> >>>> the keycloak team I might run into issues with my liquibase file not >>> >>>> being valid after a migration/liquibase update by the keycloak team >>> as >>> >>>> my liquibase file would run after keycloak's does. There might also >>> be >>> >>>> some other unknown issues our liquibase changes conflicting somehow >>> >>>> with keycloak's liquibase changes. I've also considered writing my >>> own >>> >>>> updater tool using a scripting language (python/ruby) that calls >>> >>>> keycloak's rest api. The issues with this mechanism is it feels >>> like I >>> >>>> am recreating the wheel as well as not being able to find good >>> >>>> documentation on keycloak's openid endpoints/url's used for >>> different >>> >>>> oauth2 flows. Even if I did find this documentation it would also >>> >>>> require me to find a good openid client for the scripting language. >>> >>>> This doesn't matter for our normal clients as they simply use the >>> >>>> keycloak subsystems and adapters instead. I've also looked at >>> commonly >>> >>>> used server configuration software such as chef, puppet, and >>> ansible. >>> >>>> I don't see a good solution using any of those tools yet either. >>> What >>> >>>> have other people done for cases like this? Please don't tell me >>> there >>> >>>> is someone who is doing this all manually because that doesn't work >>> in >>> >>>> modern software development. >>> >>>> >>> >>>> - doesn't accidentally delete users >>> >>>> - doesn't accidentally delete clients >>> >>>> - doesn't invalidate sessions (optional) >>> >>>> - works to bring up new, correctly configured, keycloak instances >>> >>>> - handles applying updates to existing keycloak instances >>> >>>> - can handle minor differences between keycloak instances (build, >>> >>>> test, production) when updating >>> >>>> - preferably can work well in rolling deployment scenario's. >>> >>>> -- I hope the keycloak team is taking these into consideration when >>> >>>> doing database migration between 1-2 releases. It would be nice if >>> >>>> they set some specific rules for rolling updates between versions >>> (aka >>> >>>> backwards breaking changes) >>> >>>> _______________________________________________ >>> >>>> keycloak-user mailing list >>> >>>> keycloak-user at lists.jboss.org >>> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> keycloak-user mailing list >>> >>> keycloak-user at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> keycloak-user mailing list >>> >>> keycloak-user at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> >>> >> >>> >> >>> > >>> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160527/fa33c777/attachment-0001.html From sthorger at redhat.com Fri May 27 02:24:20 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 27 May 2016 08:24:20 +0200 Subject: [keycloak-user] How to create the same client (same id) for multiple realms programmatically In-Reply-To: References: <5746F714.6050007@redhat.com> Message-ID: Do you not get a error when trying to create it the second time with the same id? If not please create a jira. On 26 May 2016 at 20:20, Haim Vana wrote: > Thanks for your reply. > > > > My problem was that I have used setId instead of setClientId. > > > > *From:* Marek Posolda [mailto:mposolda at redhat.com] > *Sent:* Thursday, May 26, 2016 4:16 PM > *To:* Haim Vana ; keycloak-user at lists.jboss.org > *Subject:* Re: [keycloak-user] How to create the same client (same id) > for multiple realms programmatically > > > > You can use for example: > > RealmResource realm1 = *adminClient*.realms().realm(*"realm1"*); > > RealmResource realm2 = *adminClient*.realms().realm(*"realm2"*); > > realm1.clients().create(clientRepresentation); > > realm2.clients().create(clientRepresentation); > > > > > For update you can take a look at some of our tests, which are updating > client. For example this one : > https://github.com/mposolda/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/admin/ClientTest.java#L183 > > Note that you need to know client Id (this is different thant clientId). > The easiest is to set it manually in representation before you create > client (via client.setId ) like it's done in this test. > > Marek > > On 26/05/16 14:54, Haim Vana wrote: > > Any idea regarding the below ? > > > > As a workaround how can I update existing client programmatically ? I > couldn't find it in the admin API. > > > > > > Thanks again, > > Haim. > > > > *From:* Haim Vana > *Sent:* Thursday, May 26, 2016 2:17 PM > *To:* keycloak-user at lists.jboss.org > *Subject:* How to create the same client (same id) for multiple realms > programmatically > > > > Hi, > > > > I am trying to create the same client for many realms, however it creates > it only once, probably because they have the same id, however in UI I am > able to create it. > > > > Any idea how I can create the same client for different realms > programmatically with the same id ? > > > > This is my code sample: > > ClientRepresentation clientRepresentation = *new *ClientRepresentation(); > > clientRepresentation.setId(clientId); // Same clientId for all reamls > > realm.clients().create(clientRepresentation); // Client is created only > for first realm > > > > > > Any advice will be appreciated, > > Haim. > > The information contained in this message is proprietary to the sender, > protected from disclosure, and may be privileged. The information is > intended to be conveyed only to the designated recipient(s) of the message. > If the reader of this message is not the intended recipient, you are hereby > notified that any dissemination, use, distribution or copying of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. Thank you. > > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > The information contained in this message is proprietary to the sender, > protected from disclosure, and may be privileged. The information is > intended to be conveyed only to the designated recipient(s) of the message. > If the reader of this message is not the intended recipient, you are hereby > notified that any dissemination, use, distribution or copying of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. Thank you. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160527/c690f172/attachment.html From akaya at expedia.com Fri May 27 02:38:14 2016 From: akaya at expedia.com (Sarp Kaya) Date: Fri, 27 May 2016 06:38:14 +0000 Subject: [keycloak-user] Using dependencies for an SPI provider In-Reply-To: References: Message-ID: Hi Stian, Thanks for the response. How do you know that it belongs to sun.jdk module? I googled but I couldn?t find anything in regards to that. I managed to get through all the issues, the last stage is adding the log and now I am stuck again. I?m asking how you find the module name because now I am getting Caused by: java.lang.NoClassDefFoundError: org/jboss/logging/Logger error. I tried adding " > Date: Thursday, May 26, 2016 at 5:21 PM To: Abdullah Sarp Kaya > Cc: "keycloak-user at lists.jboss.org" > Subject: Re: [keycloak-user] Using dependencies for an SPI provider If you need additional dependencies in your provider please deploy it as a module, see docs and examples on how to do that. For the missing class you're module definition would need to include: ... ... On 26 May 2016 at 09:14, Sarp Kaya > wrote: Hi, I am trying to extend an event listener and the example one works fine, which just prints out every event. However I want to do something more complicated than that. So I added two more dependency on top of keycloak dependencies: com.codahale.metrics:metrics-core and com.readytalk:metrics3-statsd In my IDE I was able to develop fine, then maven packages it fine. I package it by including all the dependencies (so JAR file is like 6 MB), otherwise it won?t have the dependencies (I have tried that and it complained at the runtime saying it doesn?t have the class). Then I start the keycloak service, it starts fine. I get an exception throw like below when I initially use the service (which is when the first event trigger happens): 07:10:01,453 ERROR [io.undertow.request] (default task-6) UT005023: Exception handling request to /auth/realms/master/protocol/openid-connect/auth: org.jboss.resteasy.spi.UnhandledException: java.lang.NoClassDefFoundError: sun/misc/Unsafe at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76) at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212) at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:168) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:411) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:88) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.NoClassDefFoundError: sun/misc/Unsafe at com.codahale.metrics.Striped64.getUnsafe(Striped64.java:330) at com.codahale.metrics.Striped64.(Striped64.java:311) at com.codahale.metrics.EWMA.(EWMA.java:29) at com.codahale.metrics.EWMA.oneMinuteEWMA(EWMA.java:39) at com.codahale.metrics.Meter.(Meter.java:15) at com.codahale.metrics.Meter.(Meter.java:28) at com.codahale.metrics.MetricRegistry$MetricBuilder$3.newMetric(MetricRegistry.java:426) at com.codahale.metrics.MetricRegistry$MetricBuilder$3.newMetric(MetricRegistry.java:423) at com.codahale.metrics.MetricRegistry.getOrAdd(MetricRegistry.java:313) at com.codahale.metrics.MetricRegistry.meter(MetricRegistry.java:134) at com.expedia.keycloak.spi.providers.events.SysoutEventListenerProvider.(SysoutEventListenerProvider.java:22) at com.expedia.keycloak.spi.providers.events.SysoutEventListenerProviderFactory.create(SysoutEventListenerProviderFactory.java:23) at com.expedia.keycloak.spi.providers.events.SysoutEventListenerProviderFactory.create(SysoutEventListenerProviderFactory.java:16) at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:115) at sun.reflect.GeneratedMethodAccessor27.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.resteasy.core.ContextParameterInjector$GenericDelegatingProxy.invoke(ContextParameterInjector.java:56) at com.sun.proxy.$Proxy81.getProvider(Unknown Source) at org.keycloak.events.EventBuilder.(EventBuilder.java:62) at org.keycloak.services.resources.RealmsResource.getProtocol(RealmsResource.java:98) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:79) at org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:58) at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:100) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) ... 37 more Caused by: java.lang.ClassNotFoundException: sun.misc.Unsafe at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ... 66 more I don?t know what could be wrong. When I googled the java.lang.NoClassDefFoundError with Keycloak I found that there was an error with Facebook integration. So I am wondering whether this is something similar and a bug with Keycloak? If not then what have I missed? Kind Regards, Sarp Kaya _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160527/bc929ac5/attachment-0001.html From sthorger at redhat.com Fri May 27 02:53:07 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 27 May 2016 08:53:07 +0200 Subject: [keycloak-user] Using dependencies for an SPI provider In-Reply-To: References: Message-ID: If you get a NoClassDefFoundError doing a search for "wildfly module NoClassDefFoundError " usually gives you the details you need. I've also got a script that searches through modules directory for a jar with a specific class name, but only use that as a last resort. In case you're on a Linux box I've attached it for you. You can run the script by opening a shell in $KEYCLOAK_HOME/modules then run: # searchjar org/jboss/logging/Logger or # searchjar org.jboss.logging.Logger In this case I actually found the module needed easier with the searchjar script, it's org.jboss.logging you want, not org.jboss.logging.jboss-logging. On 27 May 2016 at 08:38, Sarp Kaya wrote: > Hi Stian, > > Thanks for the response. How do you know that it belongs to sun.jdk > module? I googled but I couldn?t find anything in regards to that. > > I managed to get through all the issues, the last stage is adding the log > and now I am stuck again. I?m asking how you find the module name because > now I am getting Caused by: java.lang.NoClassDefFoundError: > org/jboss/logging/Logger error. > > I tried adding > Date: Thursday, May 26, 2016 at 5:21 PM > To: Abdullah Sarp Kaya > Cc: "keycloak-user at lists.jboss.org" > Subject: Re: [keycloak-user] Using dependencies for an SPI provider > > If you need additional dependencies in your provider please deploy it as a > module, see docs and examples on how to do that. For the missing class > you're module definition would need to include: > > ... > > > > > > > > ... > > On 26 May 2016 at 09:14, Sarp Kaya wrote: > >> Hi, >> >> I am trying to extend an event listener and the example one works fine, >> which just prints out every event. >> However I want to do something more complicated than that. So I added two >> more dependency on top of keycloak dependencies: >> com.codahale.metrics:metrics-core and com.readytalk:metrics3-statsd >> >> In my IDE I was able to develop fine, then maven packages it fine. I >> package it by including all the dependencies (so JAR file is like 6 MB), >> otherwise it won?t have the dependencies (I have tried that and it >> complained at the runtime saying it doesn?t have the class). >> >> Then I start the keycloak service, it starts fine. I get an exception >> throw like below when I initially use the service (which is when the first >> event trigger happens): >> >> 07:10:01,453 ERROR [io.undertow.request] (default task-6) UT005023: >> Exception handling request to >> /auth/realms/master/protocol/openid-connect/auth: >> org.jboss.resteasy.spi.UnhandledException: java.lang.NoClassDefFoundError: >> sun/misc/Unsafe >> at >> org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76) >> at >> org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212) >> at >> org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:168) >> at >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:411) >> at >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202) >> at >> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) >> at >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) >> at >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >> at >> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) >> at >> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) >> at >> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:88) >> at >> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) >> at >> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) >> at >> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) >> at >> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) >> at >> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) >> at >> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at >> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) >> at >> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at >> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) >> at >> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) >> at >> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) >> at >> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) >> at >> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) >> at >> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at >> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> at >> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) >> at >> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) >> at >> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) >> at >> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) >> at >> io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) >> at >> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:745) >> Caused by: java.lang.NoClassDefFoundError: sun/misc/Unsafe >> at com.codahale.metrics.Striped64.getUnsafe(Striped64.java:330) >> at com.codahale.metrics.Striped64.(Striped64.java:311) >> at com.codahale.metrics.EWMA.(EWMA.java:29) >> at com.codahale.metrics.EWMA.oneMinuteEWMA(EWMA.java:39) >> at com.codahale.metrics.Meter.(Meter.java:15) >> at com.codahale.metrics.Meter.(Meter.java:28) >> at >> com.codahale.metrics.MetricRegistry$MetricBuilder$3.newMetric(MetricRegistry.java:426) >> at >> com.codahale.metrics.MetricRegistry$MetricBuilder$3.newMetric(MetricRegistry.java:423) >> at >> com.codahale.metrics.MetricRegistry.getOrAdd(MetricRegistry.java:313) >> at >> com.codahale.metrics.MetricRegistry.meter(MetricRegistry.java:134) >> at >> com.expedia.keycloak.spi.providers.events.SysoutEventListenerProvider.(SysoutEventListenerProvider.java:22) >> at >> com.expedia.keycloak.spi.providers.events.SysoutEventListenerProviderFactory.create(SysoutEventListenerProviderFactory.java:23) >> at >> com.expedia.keycloak.spi.providers.events.SysoutEventListenerProviderFactory.create(SysoutEventListenerProviderFactory.java:16) >> at >> org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:115) >> at sun.reflect.GeneratedMethodAccessor27.invoke(Unknown Source) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:498) >> at >> org.jboss.resteasy.core.ContextParameterInjector$GenericDelegatingProxy.invoke(ContextParameterInjector.java:56) >> at com.sun.proxy.$Proxy81.getProvider(Unknown Source) >> at org.keycloak.events.EventBuilder.(EventBuilder.java:62) >> at >> org.keycloak.services.resources.RealmsResource.getProtocol(RealmsResource.java:98) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:498) >> at >> org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:79) >> at >> org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:58) >> at >> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:100) >> at >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:395) >> ... 37 more >> Caused by: java.lang.ClassNotFoundException: sun.misc.Unsafe >> at java.net.URLClassLoader.findClass(URLClassLoader.java:381) >> at java.lang.ClassLoader.loadClass(ClassLoader.java:424) >> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) >> ... 66 more >> >> I don?t know what could be wrong. When I googled >> the java.lang.NoClassDefFoundError with Keycloak I found that there was an >> error with Facebook integration. So I am wondering whether this is >> something similar and a bug with Keycloak? If not then what have I missed? >> >> Kind Regards, >> Sarp Kaya >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160527/0ba5e0c5/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: searchjar Type: application/octet-stream Size: 374 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160527/0ba5e0c5/attachment-0001.obj From haimv at perfectomobile.com Fri May 27 03:02:51 2016 From: haimv at perfectomobile.com (Haim Vana) Date: Fri, 27 May 2016 07:02:51 +0000 Subject: [keycloak-user] How to create the same client (same id) for multiple realms programmatically In-Reply-To: References: <5746F714.6050007@redhat.com> , Message-ID: <7l5jkwwlier47ro5c1dsdqcg.1464332607708@email.android.com> There is an exception in the server log, but it is not thrown, so I am not getting it in my code. -------- Original message -------- From: Stian Thorgersen Date: 5/27/16 09:24 (GMT+02:00) To: Haim Vana Cc: Marek Posolda , keycloak-user at lists.jboss.org Subject: Re: [keycloak-user] How to create the same client (same id) for multiple realms programmatically Do you not get a error when trying to create it the second time with the same id? If not please create a jira. On 26 May 2016 at 20:20, Haim Vana > wrote: Thanks for your reply. My problem was that I have used setId instead of setClientId. From: Marek Posolda [mailto:mposolda at redhat.com] Sent: Thursday, May 26, 2016 4:16 PM To: Haim Vana >; keycloak-user at lists.jboss.org Subject: Re: [keycloak-user] How to create the same client (same id) for multiple realms programmatically You can use for example: RealmResource realm1 = adminClient.realms().realm("realm1"); RealmResource realm2 = adminClient.realms().realm("realm2"); realm1.clients().create(clientRepresentation); realm2.clients().create(clientRepresentation); For update you can take a look at some of our tests, which are updating client. For example this one : https://github.com/mposolda/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/admin/ClientTest.java#L183 Note that you need to know client Id (this is different thant clientId). The easiest is to set it manually in representation before you create client (via client.setId ) like it's done in this test. Marek On 26/05/16 14:54, Haim Vana wrote: Any idea regarding the below ? As a workaround how can I update existing client programmatically ? I couldn't find it in the admin API. Thanks again, Haim. From: Haim Vana Sent: Thursday, May 26, 2016 2:17 PM To: keycloak-user at lists.jboss.org Subject: How to create the same client (same id) for multiple realms programmatically Hi, I am trying to create the same client for many realms, however it creates it only once, probably because they have the same id, however in UI I am able to create it. Any idea how I can create the same client for different realms programmatically with the same id ? This is my code sample: ClientRepresentation clientRepresentation = new ClientRepresentation(); clientRepresentation.setId(clientId); // Same clientId for all reamls realm.clients().create(clientRepresentation); // Client is created only for first realm Any advice will be appreciated, Haim. The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160527/0850f38e/attachment.html From palermo at pobox.com Fri May 27 08:13:16 2016 From: palermo at pobox.com (Bruno Palermo) Date: Fri, 27 May 2016 09:13:16 -0300 Subject: [keycloak-user] NPM keycloak-js Message-ID: Hi, I'm trying to install 'keycloak-js' package using NPM but the only version available is 1.8.0-cr.3. https://www.npmjs.com/package/keycloak-js Any expected updates? Thanks, Bruno -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160527/3541b4ac/attachment.html From lball at redhat.com Fri May 27 09:14:25 2016 From: lball at redhat.com (Lance Ball) Date: Fri, 27 May 2016 09:14:25 -0400 Subject: [keycloak-user] NPM keycloak-js In-Reply-To: References: Message-ID: Bruno I don't know when an update is expected, but there is this: https://issues.jboss.org/browse/KEYCLOAK-2378 Lance On Fri, May 27, 2016 at 8:13 AM, Bruno Palermo wrote: > Hi, > > I'm trying to install 'keycloak-js' package using NPM but the only version > available is 1.8.0-cr.3. > > https://www.npmjs.com/package/keycloak-js > > Any expected updates? > > Thanks, > Bruno > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160527/c1ce1b7a/attachment-0001.html From palermo at pobox.com Fri May 27 09:35:45 2016 From: palermo at pobox.com (Bruno Palermo) Date: Fri, 27 May 2016 10:35:45 -0300 Subject: [keycloak-user] NPM keycloak-js In-Reply-To: References: , Message-ID: Thanks! From: lball at redhat.com Date: Fri, 27 May 2016 09:14:25 -0400 Subject: Re: [keycloak-user] NPM keycloak-js To: palermo at pobox.com CC: keycloak-user at lists.jboss.org Bruno I don't know when an update is expected, but there is this: https://issues.jboss.org/browse/KEYCLOAK-2378 Lance On Fri, May 27, 2016 at 8:13 AM, Bruno Palermo wrote: Hi, I'm trying to install 'keycloak-js' package using NPM but the only version available is 1.8.0-cr.3. https://www.npmjs.com/package/keycloak-js Any expected updates? Thanks, Bruno _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160527/59631014/attachment.html From mposolda at redhat.com Fri May 27 13:19:18 2016 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 27 May 2016 19:19:18 +0200 Subject: [keycloak-user] Token generation: possibilities to improve performance In-Reply-To: <31bfde5a-c56f-473a-de6f-95d15e32bbd9@redhat.com> References: <61D077C6283D454FAFD06F6AC4AB74D723DDFF8E@DEFTHW99EZ1MSX.ww931.my-it-solutions.net> <31bfde5a-c56f-473a-de6f-95d15e32bbd9@redhat.com> Message-ID: <57488196.60104@redhat.com> Regarding this, I wonder if we should add support for ECDSA based signatures as an alternative to RSA? Just went through some interesting blog [1] , which mentions that 256-bits ECDSA has around 9.5 times better performance of signature generation than 2048-bits RSA. The time of signature verification seems to be slightly worse for ECDSA (see second comment), however there is also increased security (256-ECDSA is equivalient of 3248 RSA according to blog). Maybe it's something we can look at? Also the optional flag to skip IDToken generation will be good too IMO. AFAIK the point of IDToken is the compliance with OIDC specification. However in case of Keycloak accessToken usually contains all the info like IDToken (+ some more) and it's the accessToken, which is used in REST endpoints. So with regards to that, most of the Keycloak-secured applications can live just with access+refresh token and don't need ID Token at all. So if just 2 tokens needs to be signed instead of 3, we have performance gain "for free" (no decrease of security, just one less useless token). [1] https://blog.cloudflare.com/ecdsa-the-digital-signature-algorithm-of-a-better-internet/ Marek On 24/05/16 15:43, Bill Burke wrote: > Are you sure the performance gains are worth less security? What kind > of performance are you actually worried about? Network (size of > tokens) or CPU (signatures/marshaling/unmarshalling)? If anything, > these signatures are only going to get stronger in future releases. > > On 5/24/16 5:46 AM, Matuszak, Eduard wrote: >> Hello >> Motivated by considerations on how to improve the performance of the >> token generation process I have two questions: >> >> * I noticed that Keycloak?s token generation via endpoint >> ?auth/realms/ccp/protocol/openid-connect/token? generates a >> triple of tokens (access-, refresh- and id-token). Is there any >> possibility to dispense with the id-token generation? >> >> * Is there a possibility to cause Keycloak to generate more >> ?simple? bearer tokens then complex jwt-tokens? >> >> Best regards, Eduard Matuszak >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160527/11f8ffc8/attachment.html From moon_s_yim at hotmail.com Fri May 27 14:50:50 2016 From: moon_s_yim at hotmail.com (Moon S.Yim) Date: Fri, 27 May 2016 11:50:50 -0700 Subject: [keycloak-user] Keycloak 1.5 HA clustering failure Message-ID: Hello keycloak users, Not sure this is a correct way to ask question in User Forum. We're using keyclock 1.5 for production as single node, it works well. We're trying to make HA clustering with 2 nodes, but doesn't work. just following keycloak user guide (http://keycloak.github.io/docs/userguide/keycloak-server/pdf/keycloak-reference-guide-en-US.pdf) Chapter 29. Clustering. how to start is /opt/keycloak-1.5.0.Final/keycloak/bin/standalone.sh --server-config=standalone-keycloak-ha.xml -Djboss.bind.address=`hostname -i` & or /opt/keycloak-1.5.0.Final/keycloak/bin/standalone.sh --server-config=standalone-keycloak-ha.xml -Djboss.bind.address=`hostname -i` -bpublic=`hostname -i` -bprivate=`hostname -i` & standalone-keycloak-ha.xml or standalone-ha.xml, the same results. keyclock process is up and running on 2 nodes, but no log for clustering when it starts up. and Admin console login is failed. 18:02:59,625 WARN [org.keycloak.events] (default task-21) type=CODE_TO_TOKEN_ERROR, realmId=master, clientId=security-admin-console, userId=null, ipAddress=10.x.x.113, error=invalid_code, code_id=c4f010be-9747-4b8a-a7be-e44f9bc1e3bf, client_auth_method=client-secret 18:03:51,482 WARN [org.keycloak.events] (default task-6) type=LOGIN_ERROR, realmId=master, clientId=null, userId=null, ipAddress=10.x.x.113, error=invalid_code my questions for HA clustering is 1) how 2 nodes recognize each other? there is no configuration for that except sessions cache of infinispan/Keycloak container 2) any good example of standalone-keycloak-ha.xml for 2 nodes clustering. Thanks Best Regards, MoonY -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160527/1b7b07dc/attachment.html From bburke at redhat.com Fri May 27 17:42:34 2016 From: bburke at redhat.com (Bill Burke) Date: Fri, 27 May 2016 17:42:34 -0400 Subject: [keycloak-user] Keycloak 1.5 HA clustering failure In-Reply-To: References: Message-ID: <4ffcee03-52c8-ae9b-7632-6f65985dfe76@redhat.com> Upgrade to 1.9.5. A lot of changes have happened since 1.5....A lot...We don't support community versions that old. Commercial support will be based off of 1.9.x branch. On 5/27/16 2:50 PM, Moon S.Yim wrote: > Hello keycloak users, > Not sure this is a correct way to ask question in User Forum. > > We're using keyclock 1.5 for production as single node, it works well. > We're trying to make HA clustering with 2 nodes, but doesn't work. > just following keycloak user guide > (http://keycloak.github.io/docs/userguide/keycloak-server/pdf/keycloak-reference-guide-en-US.pdf) > Chapter 29. Clustering. > how to start is > /opt/keycloak-1.5.0.Final/keycloak/bin/standalone.sh > --server-config=standalone-keycloak-ha.xml > -Djboss.bind.address=`hostname -i` & > or > /opt/keycloak-1.5.0.Final/keycloak/bin/standalone.sh > --server-config=standalone-keycloak-ha.xml > -Djboss.bind.address=`hostname -i` -bpublic=`hostname -i` > -bprivate=`hostname -i` & > > standalone-keycloak-ha.xml or standalone-ha.xml, the same results. > > keyclock process is up and running on 2 nodes, but no log for > clustering when it starts up. > and Admin console login is failed. > > 18:02:59,625 WARN [org.keycloak.events] (default task-21) > type=CODE_TO_TOKEN_ERROR, realmId=master, > clientId=security-admin-console, userId=null, ipAddress=10.x.x.113, > error=invalid_code, code_id=c4f010be-9747-4b8a-a7be-e44f9bc1e3bf, > client_auth_method=client-secret > 18:03:51,482 WARN [org.keycloak.events] (default task-6) > type=LOGIN_ERROR, realmId=master, clientId=null, userId=null, > ipAddress=10.x.x.113, error=invalid_code > > my questions for HA clustering is > 1) how 2 nodes recognize each other? there is no configuration for > that except sessions cache of infinispan/Keycloak container > 2) any good example of standalone-keycloak-ha.xml for 2 nodes clustering. > > > Thanks > Best Regards, MoonY > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------ > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160527/3c7552ca/attachment-0001.html From bruno at abstractj.org Fri May 27 18:15:00 2016 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 27 May 2016 22:15:00 +0000 Subject: [keycloak-user] Token generation: possibilities to improve performance In-Reply-To: <57488196.60104@redhat.com> References: <61D077C6283D454FAFD06F6AC4AB74D723DDFF8E@DEFTHW99EZ1MSX.ww931.my-it-solutions.net> <31bfde5a-c56f-473a-de6f-95d15e32bbd9@redhat.com> <57488196.60104@redhat.com> Message-ID: +1 about ECDSA, I'd be interested to help on it. On Fri, May 27, 2016 at 2:19 PM Marek Posolda wrote: > Regarding this, I wonder if we should add support for ECDSA based > signatures as an alternative to RSA? Just went through some interesting > blog [1] , which mentions that 256-bits ECDSA has around 9.5 times better > performance of signature generation than 2048-bits RSA. The time of > signature verification seems to be slightly worse for ECDSA (see second > comment), however there is also increased security (256-ECDSA is > equivalient of 3248 RSA according to blog). Maybe it's something we can > look at? > > Also the optional flag to skip IDToken generation will be good too IMO. > AFAIK the point of IDToken is the compliance with OIDC specification. > However in case of Keycloak accessToken usually contains all the info like > IDToken (+ some more) and it's the accessToken, which is used in REST > endpoints. So with regards to that, most of the Keycloak-secured > applications can live just with access+refresh token and don't need ID > Token at all. So if just 2 tokens needs to be signed instead of 3, we have > performance gain "for free" (no decrease of security, just one less useless > token). > > [1] > https://blog.cloudflare.com/ecdsa-the-digital-signature-algorithm-of-a-better-internet/ > > > Marek > > > On 24/05/16 15:43, Bill Burke wrote: > > Are you sure the performance gains are worth less security? What kind of > performance are you actually worried about? Network (size of tokens) or > CPU (signatures/marshaling/unmarshalling)? If anything, these signatures > are only going to get stronger in future releases. > > On 5/24/16 5:46 AM, Matuszak, Eduard wrote: > > Hello > > Motivated by considerations on how to improve the performance of the token > generation process I have two questions: > > > - I noticed that Keycloak?s token generation via endpoint > ?auth/realms/ccp/protocol/openid-connect/token? generates a triple of > tokens (access-, refresh- and id-token). Is there any possibility to > dispense with the id-token generation? > > > > - Is there a possibility to cause Keycloak to generate more ?simple? > bearer tokens then complex jwt-tokens? > > > > Best regards, Eduard Matuszak > > > > _______________________________________________ > keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > _______________________________________________ > keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160527/02cb7518/attachment.html From palermo at pobox.com Sun May 29 18:48:09 2016 From: palermo at pobox.com (Bruno Palermo) Date: Sun, 29 May 2016 19:48:09 -0300 Subject: [keycloak-user] Terms and Conditions In-Reply-To: <57424DFB.9010200@redhat.com> References: , <57424DFB.9010200@redhat.com> Message-ID: Stan, For now I'm using a static page outside Keycloak. As for the script I will have a look at the admin client API. Also would be an interested option to force the user to accept the terms before creating an account, just using a regular checkbox on the registration form. Right now I`m doing client side validation using JQuery. Any suggestion for the server side validation? Thanks, Bruno Date: Sun, 22 May 2016 20:25:31 -0400 From: ssilvert at redhat.com To: keycloak-user at lists.jboss.org Subject: Re: [keycloak-user] Terms and Conditions On 5/20/2016 7:24 PM, Bruno Palermo wrote: Hi, It's possible to link directly to the terms and conditions page? What's the URL? You could create your own static page, but it doesn't sound like that's what you want. But linking to the middle of a login flow doesn't make much sense either. In case there's an update to terms, is possible to add the required action to accept the terms again to all users? This is probably what you want. It should be fairly easy to write a script for adding the required action to all users. Are you familiar with the admin client? It might be a nice addition to the admin UI if we allow you to assign a required action to all users. Something to think about for a 2.x feature. Thanks, Bruno _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160529/8d651b32/attachment.html From christian.lange at atos.net Sun May 29 20:06:03 2016 From: christian.lange at atos.net (Lange, Christian) Date: Mon, 30 May 2016 00:06:03 +0000 Subject: [keycloak-user] Keycloak 1.9.5.Final Released In-Reply-To: References: Message-ID: <099F7BF03F87B847B98088A5CEA5BA341E87FE00@DEFTHW99EZ1MSX.ww931.my-it-solutions.net> Hello Stian, (Hello Developers,) I wonder if you think about switching from SHA256 as the default hash algorithm to SHA512. Nowadays most of the servers are equipped with 64Bit CPUs and SHA512 can actually benefit from that architecture (under good conditions 1/3x faster than SHA256). Correct me if I'm wrong but as far as I know it's not possible to select the algorithms without some custom code changes. Best regards, Christian ________________________________________ Von: keycloak-user-bounces at lists.jboss.org [keycloak-user-bounces at lists.jboss.org]" im Auftrag von "Stian Thorgersen [sthorger at redhat.com] Gesendet: Donnerstag, 26. Mai 2016 21:13 An: keycloak-user; keycloak-dev Betreff: [keycloak-user] Keycloak 1.9.5.Final Released Keycloak 1.9.5.Final has just been released. There's one change worth highlighting in this release. We've increased the default password hashing intervals to 20000. Yes, you read that right. We've actually recommended using 20000 for a while now, but the default was only 1. This is a clear trade-off between performance and how secure passwords are stored. With 1 password hashing interval it takes less than 1 ms to hash a password, while with 20000 it takes tens of ms. For the full list of resolved issues check out JIRA and to download the release go to the Keycloak homepage. From sthorger at redhat.com Mon May 30 01:22:47 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 30 May 2016 07:22:47 +0200 Subject: [keycloak-user] Keycloak 1.9.5.Final Released In-Reply-To: <099F7BF03F87B847B98088A5CEA5BA341E87FE00@DEFTHW99EZ1MSX.ww931.my-it-solutions.net> References: <099F7BF03F87B847B98088A5CEA5BA341E87FE00@DEFTHW99EZ1MSX.ww931.my-it-solutions.net> Message-ID: There's 3 places this would be relevant: session codes (used during authentication), OpenID Connect and SAML. Only SAML currently supports configuring to SHA512. It's not currently on the road-map to add for the others, but feel free to create a JIRA issue to request this. On 30 May 2016 at 02:06, Lange, Christian wrote: > Hello Stian, (Hello Developers,) > > I wonder if you think about switching from SHA256 as the default hash > algorithm to SHA512. > Nowadays most of the servers are equipped with 64Bit CPUs and SHA512 can > actually benefit from that architecture (under good conditions 1/3x faster > than SHA256). > > Correct me if I'm wrong but as far as I know it's not possible to select > the algorithms without some custom code changes. > > Best regards, > Christian > > ________________________________________ > Von: keycloak-user-bounces at lists.jboss.org [ > keycloak-user-bounces at lists.jboss.org]" im Auftrag von "Stian > Thorgersen [sthorger at redhat.com] > Gesendet: Donnerstag, 26. Mai 2016 21:13 > An: keycloak-user; keycloak-dev > Betreff: [keycloak-user] Keycloak 1.9.5.Final Released > > Keycloak 1.9.5.Final has just been released. There's one change worth > highlighting in this release. We've increased the default password hashing > intervals to 20000. Yes, you read that right. We've actually recommended > using 20000 for a while now, but the default was only 1. This is a clear > trade-off between performance and how secure passwords are stored. With 1 > password hashing interval it takes less than 1 ms to hash a password, while > with 20000 it takes tens of ms. > > For the full list of resolved issues check out JIRA< > https://issues.jboss.org/issues/?jql=project%20%3D%20keycloak%20and%20fixVersion%20%3D%201.9.5.Final> > and to download the release go to the Keycloak homepage< > http://www.keycloak.org/downloads>. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/601e1b0b/attachment-0001.html From sthorger at redhat.com Mon May 30 01:52:47 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 30 May 2016 07:52:47 +0200 Subject: [keycloak-user] Terms and Conditions In-Reply-To: References: <57424DFB.9010200@redhat.com> Message-ID: You could also use the realm resource SPI [1] to add a static page for the terms and conditions. For server-side validation you can use a custom registration flow [2] [1] https://github.com/keycloak/keycloak/blob/master/server-spi/src/main/java/org/keycloak/services/resource/RealmResourceProvider.java [2] http://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html#d4e3969 On 30 May 2016 at 00:48, Bruno Palermo wrote: > Stan, > > For now I'm using a static page outside Keycloak. As for the script I will > have a look at the admin client API. > Also would be an interested option to force the user to accept the terms > before creating an account, just using a regular checkbox on the > registration form. > Right now I`m doing client side validation using JQuery. Any suggestion > for the server side validation? > > Thanks, > Bruno > > ------------------------------ > Date: Sun, 22 May 2016 20:25:31 -0400 > From: ssilvert at redhat.com > To: keycloak-user at lists.jboss.org > Subject: Re: [keycloak-user] Terms and Conditions > > > On 5/20/2016 7:24 PM, Bruno Palermo wrote: > > Hi, > > It's possible to link directly to the terms and conditions page? What's > the URL? > > You could create your own static page, but it doesn't sound like that's > what you want. But linking to the middle of a login flow doesn't make much > sense either. > > In case there's an update to terms, is possible to add the required action > to accept the terms again to all users? > > This is probably what you want. It should be fairly easy to write a > script for adding the required action to all users. Are you familiar with > the admin client? > > It might be a nice addition to the admin UI if we allow you to assign a > required action to all users. Something to think about for a 2.x feature. > > > Thanks, > Bruno > > > _______________________________________________ > keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user > > > > _______________________________________________ keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/8ffc6fa4/attachment.html From sthorger at redhat.com Mon May 30 02:02:44 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 30 May 2016 08:02:44 +0200 Subject: [keycloak-user] Token generation: possibilities to improve performance In-Reply-To: <57488196.60104@redhat.com> References: <61D077C6283D454FAFD06F6AC4AB74D723DDFF8E@DEFTHW99EZ1MSX.ww931.my-it-solutions.net> <31bfde5a-c56f-473a-de6f-95d15e32bbd9@redhat.com> <57488196.60104@redhat.com> Message-ID: Create a JIRA for ECDSA. I don't think we could/should change the default, but could be a configuration option for clients. Looking at OpenID Connect spec it looks like ID token should always be generated in token response [1]. However, it should not be generated in refresh [2] response. [1] http://openid.net/specs/openid-connect-core-1_0.html#rfc.section.3.1.3.3 [2] http://openid.net/specs/openid-connect-core-1_0.html#rfc.section.12.2 On 27 May 2016 at 19:19, Marek Posolda wrote: > Regarding this, I wonder if we should add support for ECDSA based > signatures as an alternative to RSA? Just went through some interesting > blog [1] , which mentions that 256-bits ECDSA has around 9.5 times better > performance of signature generation than 2048-bits RSA. The time of > signature verification seems to be slightly worse for ECDSA (see second > comment), however there is also increased security (256-ECDSA is > equivalient of 3248 RSA according to blog). Maybe it's something we can > look at? > > Also the optional flag to skip IDToken generation will be good too IMO. > AFAIK the point of IDToken is the compliance with OIDC specification. > However in case of Keycloak accessToken usually contains all the info like > IDToken (+ some more) and it's the accessToken, which is used in REST > endpoints. So with regards to that, most of the Keycloak-secured > applications can live just with access+refresh token and don't need ID > Token at all. So if just 2 tokens needs to be signed instead of 3, we have > performance gain "for free" (no decrease of security, just one less useless > token). > > [1] > https://blog.cloudflare.com/ecdsa-the-digital-signature-algorithm-of-a-better-internet/ > > Marek > > > On 24/05/16 15:43, Bill Burke wrote: > > Are you sure the performance gains are worth less security? What kind of > performance are you actually worried about? Network (size of tokens) or > CPU (signatures/marshaling/unmarshalling)? If anything, these signatures > are only going to get stronger in future releases. > > On 5/24/16 5:46 AM, Matuszak, Eduard wrote: > > Hello > > Motivated by considerations on how to improve the performance of the token > generation process I have two questions: > > > - I noticed that Keycloak?s token generation via endpoint > ?auth/realms/ccp/protocol/openid-connect/token? generates a triple of > tokens (access-, refresh- and id-token). Is there any possibility to > dispense with the id-token generation? > > > > - Is there a possibility to cause Keycloak to generate more ?simple? > bearer tokens then complex jwt-tokens? > > > > Best regards, Eduard Matuszak > > > > _______________________________________________ > keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > _______________________________________________ > keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/cae70af7/attachment.html From sthorger at redhat.com Mon May 30 02:04:04 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 30 May 2016 08:04:04 +0200 Subject: [keycloak-user] How to create the same client (same id) for multiple realms programmatically In-Reply-To: <7l5jkwwlier47ro5c1dsdqcg.1464332607708@email.android.com> References: <5746F714.6050007@redhat.com> <7l5jkwwlier47ro5c1dsdqcg.1464332607708@email.android.com> Message-ID: What's the status code for the response? It should be 409. On 27 May 2016 at 09:02, Haim Vana wrote: > There is an exception in the server log, but it is not thrown, so I am not > getting it in my code. > > > > -------- Original message -------- > From: Stian Thorgersen > Date: 5/27/16 09:24 (GMT+02:00) > To: Haim Vana > Cc: Marek Posolda , keycloak-user at lists.jboss.org > Subject: Re: [keycloak-user] How to create the same client (same id) for > multiple realms programmatically > > Do you not get a error when trying to create it the second time with the > same id? If not please create a jira. > > On 26 May 2016 at 20:20, Haim Vana wrote: > >> Thanks for your reply. >> >> >> >> My problem was that I have used setId instead of setClientId. >> >> >> >> *From:* Marek Posolda [mailto:mposolda at redhat.com] >> *Sent:* Thursday, May 26, 2016 4:16 PM >> *To:* Haim Vana ; keycloak-user at lists.jboss.org >> *Subject:* Re: [keycloak-user] How to create the same client (same id) >> for multiple realms programmatically >> >> >> >> You can use for example: >> >> RealmResource realm1 = *adminClient*.realms().realm(*"realm1"*); >> >> RealmResource realm2 = *adminClient*.realms().realm(*"realm2"*); >> >> realm1.clients().create(clientRepresentation); >> >> realm2.clients().create(clientRepresentation); >> >> >> >> >> For update you can take a look at some of our tests, which are updating >> client. For example this one : >> https://github.com/mposolda/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/admin/ClientTest.java#L183 >> >> Note that you need to know client Id (this is different thant clientId). >> The easiest is to set it manually in representation before you create >> client (via client.setId ) like it's done in this test. >> >> Marek >> >> On 26/05/16 14:54, Haim Vana wrote: >> >> Any idea regarding the below ? >> >> >> >> As a workaround how can I update existing client programmatically ? I >> couldn't find it in the admin API. >> >> >> >> >> >> Thanks again, >> >> Haim. >> >> >> >> *From:* Haim Vana >> *Sent:* Thursday, May 26, 2016 2:17 PM >> *To:* keycloak-user at lists.jboss.org >> *Subject:* How to create the same client (same id) for multiple realms >> programmatically >> >> >> >> Hi, >> >> >> >> I am trying to create the same client for many realms, however it creates >> it only once, probably because they have the same id, however in UI I am >> able to create it. >> >> >> >> Any idea how I can create the same client for different realms >> programmatically with the same id ? >> >> >> >> This is my code sample: >> >> ClientRepresentation clientRepresentation = *new *ClientRepresentation(); >> >> clientRepresentation.setId(clientId); // Same clientId for all reamls >> >> realm.clients().create(clientRepresentation); // Client is created only >> for first realm >> >> >> >> >> >> Any advice will be appreciated, >> >> Haim. >> >> The information contained in this message is proprietary to the sender, >> protected from disclosure, and may be privileged. The information is >> intended to be conveyed only to the designated recipient(s) of the message. >> If the reader of this message is not the intended recipient, you are hereby >> notified that any dissemination, use, distribution or copying of this >> communication is strictly prohibited and may be unlawful. If you have >> received this communication in error, please notify us immediately by >> replying to the message and deleting it from your computer. Thank you. >> >> >> _______________________________________________ >> >> keycloak-user mailing list >> >> keycloak-user at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> >> The information contained in this message is proprietary to the sender, >> protected from disclosure, and may be privileged. The information is >> intended to be conveyed only to the designated recipient(s) of the message. >> If the reader of this message is not the intended recipient, you are hereby >> notified that any dissemination, use, distribution or copying of this >> communication is strictly prohibited and may be unlawful. If you have >> received this communication in error, please notify us immediately by >> replying to the message and deleting it from your computer. Thank you. >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > The information contained in this message is proprietary to the sender, > protected from disclosure, and may be privileged. The information is > intended to be conveyed only to the designated recipient(s) of the message. > If the reader of this message is not the intended recipient, you are hereby > notified that any dissemination, use, distribution or copying of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. Thank you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/05515c77/attachment-0001.html From haimv at perfectomobile.com Mon May 30 02:58:38 2016 From: haimv at perfectomobile.com (Haim Vana) Date: Mon, 30 May 2016 06:58:38 +0000 Subject: [keycloak-user] How to get specific client role programmatically In-Reply-To: References: Message-ID: Any idea regarding the below ? From: keycloak-user-bounces at lists.jboss.org [mailto:keycloak-user-bounces at lists.jboss.org] On Behalf Of Haim Vana Sent: Wednesday, May 25, 2016 10:53 PM To: keycloak-user at lists.jboss.org Subject: [keycloak-user] How to get specific client role programmatically Hi, I am using the KeyCloak API to create admin users and update their roles, I am able to add to an admin user all the available client roles, however how can I add a specific one ? This is my code to get all the available client roles: userResource.roles().clientLevel(userRealmClientId).listAvailable() How can I get specific one and not all ? Any advice will be appreciated, Haim. The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/9b26151c/attachment.html From jannik.huels at googlemail.com Mon May 30 03:04:35 2016 From: jannik.huels at googlemail.com (=?utf-8?Q?Jannik_H=C3=BCls?=) Date: Mon, 30 May 2016 09:04:35 +0200 Subject: [keycloak-user] keycloak openid connect session management Message-ID: Hi guys, I am using keycloak together with mod_auth_openidc and ran into some trouble. I want to use the login-status-iframe endpoint but it seems to be not working (at least for my configuration). The aim is to use a federated logout: 1. Login via an app protected by mod_auth_openidc 2. Open keycloak admin 3. Destroy the session 4. Refresh the app ?> User is still logged in. So mod_auth_openidc supports the OpenID Connect Session Management via iframe and as I saw in keycloaks code a iframe endpoint is available. So: - Is the OpenID Connect session management via iframe already working in keycloak? I was wondering that the endpoint is not mentioned in the openID connect well-known configuration. - What is the correct origin value that should be presented when calling the iframe endpoint? I call: /protocol/openid-connect/login-status-iframe.html?client_id=&origin= - Is there any documentation available regarding the iframe endpoint? I suggested that I have to include the above link into the iframe src attribute? Is this correct? Bests Jannik -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/70cd7a67/attachment.html From sthorger at redhat.com Mon May 30 03:25:40 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 30 May 2016 09:25:40 +0200 Subject: [keycloak-user] keycloak openid connect session management In-Reply-To: References: Message-ID: On 30 May 2016 at 09:04, Jannik H?ls wrote: > Hi guys, > > I am using keycloak together with mod_auth_openidc and ran into some > trouble. I want to use the login-status-iframe endpoint but it seems to be > not working (at least for my configuration). > The aim is to use a federated logout: > > 1. Login via an app protected by mod_auth_openidc > 2. Open keycloak admin > 3. Destroy the session > 4. Refresh the app ?> User is still logged in. > > So mod_auth_openidc supports the OpenID Connect Session Management via > iframe and as I saw in keycloaks code a iframe endpoint is available. So: > > - Is the OpenID Connect session management via iframe already working in > keycloak? I was wondering that the endpoint is not mentioned in the openID > connect well-known configuration. > I don't think there's a standard way to mention this endpoint in .well-known. Would make sense though. > - What is the correct origin value that should be presented when calling > the iframe endpoint? > > I call: > url>/protocol/openid-connect/login-status-iframe.html?client_id=&origin= > > - Is there any documentation available regarding the iframe endpoint? I > suggested that I have to include the above link into the iframe src > attribute? Is this correct? > Afraid there's no docs for this endpoint at the moment and it's currently only used by our JavaScript adapter. You can look at how our JavaScript adapter includes this. Basically you need to add an iframe with the above src attribute, but also add a mechanism that sends messages to the embedded iframe to poll the session state. > > > Bests > Jannik > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/ef62c372/attachment.html From sthorger at redhat.com Mon May 30 03:27:10 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 30 May 2016 09:27:10 +0200 Subject: [keycloak-user] How to get specific client role programmatically In-Reply-To: References: Message-ID: To get a specific role for a client you need to get the client, then the role from that client. It's not available through the user resource. On 30 May 2016 at 08:58, Haim Vana wrote: > Any idea regarding the below ? > > > > *From:* keycloak-user-bounces at lists.jboss.org [mailto: > keycloak-user-bounces at lists.jboss.org] *On Behalf Of *Haim Vana > *Sent:* Wednesday, May 25, 2016 10:53 PM > *To:* keycloak-user at lists.jboss.org > *Subject:* [keycloak-user] How to get specific client role > programmatically > > > > Hi, > > > > I am using the KeyCloak API to create admin users and update their roles, > I am able to add to an admin user all the available client roles, however > how can I add a specific one ? > > > > This is my code to get all the available client roles: > > userResource.roles().clientLevel(userRealmClientId).listAvailable() > > > > How can I get specific one and not all ? > > > > > > Any advice will be appreciated, > > Haim. > > > > The information contained in this message is proprietary to the sender, > protected from disclosure, and may be privileged. The information is > intended to be conveyed only to the designated recipient(s) of the message. > If the reader of this message is not the intended recipient, you are hereby > notified that any dissemination, use, distribution or copying of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. Thank you. > The information contained in this message is proprietary to the sender, > protected from disclosure, and may be privileged. The information is > intended to be conveyed only to the designated recipient(s) of the message. > If the reader of this message is not the intended recipient, you are hereby > notified that any dissemination, use, distribution or copying of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. Thank you. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/35906a8a/attachment-0001.html From mposolda at redhat.com Mon May 30 05:13:44 2016 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 30 May 2016 11:13:44 +0200 Subject: [keycloak-user] Token generation: possibilities to improve performance In-Reply-To: References: <61D077C6283D454FAFD06F6AC4AB74D723DDFF8E@DEFTHW99EZ1MSX.ww931.my-it-solutions.net> <31bfde5a-c56f-473a-de6f-95d15e32bbd9@redhat.com> <57488196.60104@redhat.com> Message-ID: <574C0448.6090108@redhat.com> On 30/05/16 08:02, Stian Thorgersen wrote: > Create a JIRA for ECDSA. I don't think we could/should change the > default, but could be a configuration option for clients. Added https://issues.jboss.org/browse/KEYCLOAK-3057 with fix version 2.0.0.CR1 for now. > > Looking at OpenID Connect spec it looks like ID token should always be > generated in token response [1]. However, it should not be generated > in refresh [2] response. > > [1] > http://openid.net/specs/openid-connect-core-1_0.html#rfc.section.3.1.3.3 > [2] http://openid.net/specs/openid-connect-core-1_0.html#rfc.section.12.2 hmm... I am reading 12.2 that refresh response "might not" contain ID Token, hence it's nothing bad if it contains it. So looks we are currently specs compliant if we have IDToken in both code-to-token response and refresh response. What I mean is, that flag for skip IDToken generation might be just optional and disabled by default. So by default, IDToken is available and all the communication is OIDC compliant. However if someone doesn't need IDToken and wants to save some performance, he may skip the IDToken generation. A week before, I've tried some JProfiler testing of login-logout test and token generation was the main CPU consumption (I still had just 1 hashIteration during this profiling, with 20000 it will be likely very different though). I saw 40% of CPU time in TokenManager$AccessTokenResponseBuilder.build()due there are 3 tokens signature here. The option to reduce it from 3 to 2 might slightly improve some CPU cycles "for free" (security won't be reduced). Marek > On 27 May 2016 at 19:19, Marek Posolda > wrote: > > Regarding this, I wonder if we should add support for ECDSA based > signatures as an alternative to RSA? Just went through some > interesting blog [1] , which mentions that 256-bits ECDSA has > around 9.5 times better performance of signature generation than > 2048-bits RSA. The time of signature verification seems to be > slightly worse for ECDSA (see second comment), however there is > also increased security (256-ECDSA is equivalient of 3248 RSA > according to blog). Maybe it's something we can look at? > > Also the optional flag to skip IDToken generation will be good too > IMO. AFAIK the point of IDToken is the compliance with OIDC > specification. However in case of Keycloak accessToken usually > contains all the info like IDToken (+ some more) and it's the > accessToken, which is used in REST endpoints. So with regards to > that, most of the Keycloak-secured applications can live just with > access+refresh token and don't need ID Token at all. So if just 2 > tokens needs to be signed instead of 3, we have performance gain > "for free" (no decrease of security, just one less useless token). > > [1] > https://blog.cloudflare.com/ecdsa-the-digital-signature-algorithm-of-a-better-internet/ > > Marek > > > On 24/05/16 15:43, Bill Burke wrote: >> Are you sure the performance gains are worth less security? What >> kind of performance are you actually worried about? Network >> (size of tokens) or CPU (signatures/marshaling/unmarshalling)? >> If anything, these signatures are only going to get stronger in >> future releases. >> >> On 5/24/16 5:46 AM, Matuszak, Eduard wrote: >>> Hello >>> Motivated by considerations on how to improve the performance of >>> the token generation process I have two questions: >>> >>> * I noticed that Keycloak?s token generation via endpoint >>> ?auth/realms/ccp/protocol/openid-connect/token? generates a >>> triple of tokens (access-, refresh- and id-token). Is there >>> any possibility to dispense with the id-token generation? >>> >>> * Is there a possibility to cause Keycloak to generate more >>> ?simple? bearer tokens then complex jwt-tokens? >>> >>> Best regards, Eduard Matuszak >>> >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/7c84a2a2/attachment.html From Kristiaan.Jansen at planonsoftware.com Mon May 30 05:37:01 2016 From: Kristiaan.Jansen at planonsoftware.com (Kristiaan Jansen) Date: Mon, 30 May 2016 09:37:01 +0000 Subject: [keycloak-user] Hide idp selection page Message-ID: Hi I would like to hide the idp's on the main login of the key cloak. Senario: I have multiple idp's and key cloak infront of that as a SP. I am automatically letting the different groups go to the right idp with kc_idp_hint. But if a group goes to the sp url by accident I don't want a the full list of all the IDP's to be visible. Is there a way to achieve this in key cloak? IdpA(key cloak)---| | idpB(key cloak)---|----SP(key cloak)idp--- mywebaplication(tomcat). | ipdC(key cloak)---| Thanks, Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/41aaf698/attachment.html From sthorger at redhat.com Mon May 30 05:51:26 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 30 May 2016 11:51:26 +0200 Subject: [keycloak-user] Token generation: possibilities to improve performance In-Reply-To: <574C0448.6090108@redhat.com> References: <61D077C6283D454FAFD06F6AC4AB74D723DDFF8E@DEFTHW99EZ1MSX.ww931.my-it-solutions.net> <31bfde5a-c56f-473a-de6f-95d15e32bbd9@redhat.com> <57488196.60104@redhat.com> <574C0448.6090108@redhat.com> Message-ID: On 30 May 2016 at 11:13, Marek Posolda wrote: > On 30/05/16 08:02, Stian Thorgersen wrote: > > Create a JIRA for ECDSA. I don't think we could/should change the > default, but could be a configuration option for clients. > > Added https://issues.jboss.org/browse/KEYCLOAK-3057 with fix version > 2.0.0.CR1 for now. > > > Looking at OpenID Connect spec it looks like ID token should always be > generated in token response [1]. However, it should not be generated in > refresh [2] response. > > [1] > > http://openid.net/specs/openid-connect-core-1_0.html#rfc.section.3.1.3.3 > [2] > > http://openid.net/specs/openid-connect-core-1_0.html#rfc.section.12.2 > > hmm... I am reading 12.2 that refresh response "might not" contain ID > Token, hence it's nothing bad if it contains it. So looks we are currently > specs compliant if we have IDToken in both code-to-token response and > refresh response. > > What I mean is, that flag for skip IDToken generation might be just > optional and disabled by default. So by default, IDToken is available and > all the communication is OIDC compliant. However if someone doesn't need > IDToken and wants to save some performance, he may skip the IDToken > generation. > > A week before, I've tried some JProfiler testing of login-logout test and > token generation was the main CPU consumption (I still had just 1 > hashIteration during this profiling, with 20000 it will be likely very > different though). I saw 40% of CPU time in TokenManager$ > AccessTokenResponseBuilder.build() due there are 3 tokens signature here. > The option to reduce it from 3 to 2 might slightly improve some CPU cycles > "for free" (security won't be reduced). > I'd argue that we should just include ID token from the authorization response, while never in the refresh response. That results in better performance without the need for a config option. > > > Marek > > > On 27 May 2016 at 19:19, Marek Posolda wrote: > >> Regarding this, I wonder if we should add support for ECDSA based >> signatures as an alternative to RSA? Just went through some interesting >> blog [1] , which mentions that 256-bits ECDSA has around 9.5 times better >> performance of signature generation than 2048-bits RSA. The time of >> signature verification seems to be slightly worse for ECDSA (see second >> comment), however there is also increased security (256-ECDSA is >> equivalient of 3248 RSA according to blog). Maybe it's something we can >> look at? >> >> Also the optional flag to skip IDToken generation will be good too IMO. >> AFAIK the point of IDToken is the compliance with OIDC specification. >> However in case of Keycloak accessToken usually contains all the info like >> IDToken (+ some more) and it's the accessToken, which is used in REST >> endpoints. So with regards to that, most of the Keycloak-secured >> applications can live just with access+refresh token and don't need ID >> Token at all. So if just 2 tokens needs to be signed instead of 3, we have >> performance gain "for free" (no decrease of security, just one less useless >> token). >> >> [1] >> https://blog.cloudflare.com/ecdsa-the-digital-signature-algorithm-of-a-better-internet/ >> >> Marek >> >> >> On 24/05/16 15:43, Bill Burke wrote: >> >> Are you sure the performance gains are worth less security? What kind of >> performance are you actually worried about? Network (size of tokens) or >> CPU (signatures/marshaling/unmarshalling)? If anything, these signatures >> are only going to get stronger in future releases. >> >> On 5/24/16 5:46 AM, Matuszak, Eduard wrote: >> >> Hello >> >> Motivated by considerations on how to improve the performance of the >> token generation process I have two questions: >> >> >> - I noticed that Keycloak?s token generation via endpoint >> ?auth/realms/ccp/protocol/openid-connect/token? generates a triple of >> tokens (access-, refresh- and id-token). Is there any possibility to >> dispense with the id-token generation? >> >> >> >> - Is there a possibility to cause Keycloak to generate more ?simple? >> bearer tokens then complex jwt-tokens? >> >> >> >> Best regards, Eduard Matuszak >> >> >> >> _______________________________________________ >> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user >> >> >> >> >> _______________________________________________ >> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user >> >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/f0c0b153/attachment-0001.html From mposolda at redhat.com Mon May 30 05:57:49 2016 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 30 May 2016 11:57:49 +0200 Subject: [keycloak-user] How to create the same client (same id) for multiple realms programmatically In-Reply-To: References: <5746F714.6050007@redhat.com> <7l5jkwwlier47ro5c1dsdqcg.1464332607708@email.android.com> Message-ID: <574C0E9D.7040000@redhat.com> Maybe someone already mentions it before. IMO the returning "Response" from the create methods on admin client is one of the biggest limitation of current admin-client. For example if we change ClientResources method: @POST @Consumes(MediaType.APPLICATION_JSON) public Response create(ClientRepresentation clientRepresentation); to something like: @POST @Consumes(MediaType.APPLICATION_JSON) @Produces(MediaType.APPLICATION_JSON) public ClientRepresentation create(ClientRepresentation clientRepresentation); then the advantages will be: - You won't need to parse the ID of newly created client from the URI location and call additional GET request to retrieve newly created client (You usually want newly created client when you are creating it) - In case the error happened, the exception will be thrown on client-side too. With the "Response" object, the exception is not thrown on client-side but you are supposed to manually check the status code. This may be confusing for users, who are not so familiar with the admin client. When exception is thrown on client-side, it's crystal clear that something bad happened and client wasn't successfully created on server side. Are there any disadvantages? The only one I see is, that POST responses from server will need to return the representation of created object, but that's maybe rather advantage (as you don't need to call additional GET request, which in 95% of cases you need). Marek On 30/05/16 08:04, Stian Thorgersen wrote: > What's the status code for the response? It should be 409. > > On 27 May 2016 at 09:02, Haim Vana > wrote: > > There is an exception in the server log, but it is not thrown, so > I am not getting it in my code. > > > > -------- Original message -------- > From: Stian Thorgersen > > Date: 5/27/16 09:24 (GMT+02:00) > To: Haim Vana > > Cc: Marek Posolda >, keycloak-user at lists.jboss.org > > Subject: Re: [keycloak-user] How to create the same client (same > id) for multiple realms programmatically > > Do you not get a error when trying to create it the second time > with the same id? If not please create a jira. > > On 26 May 2016 at 20:20, Haim Vana > wrote: > > Thanks for your reply. > > My problem was that I have used setId instead of setClientId. > > *From:*Marek Posolda [mailto:mposolda at redhat.com > ] > *Sent:* Thursday, May 26, 2016 4:16 PM > *To:* Haim Vana >; > keycloak-user at lists.jboss.org > > *Subject:* Re: [keycloak-user] How to create the same client > (same id) for multiple realms programmatically > > You can use for example: > > RealmResource realm1 = *adminClient*.realms().realm(*"realm1"*); > > RealmResource realm2 = *adminClient*.realms().realm(*"realm2"*); > > realm1.clients().create(clientRepresentation); > > realm2.clients().create(clientRepresentation); > > > For update you can take a look at some of our tests, which are > updating client. For example this one : > https://github.com/mposolda/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/admin/ClientTest.java#L183 > > Note that you need to know client Id (this is different thant > clientId). The easiest is to set it manually in representation > before you create client (via client.setId ) like it's done in > this test. > > Marek > > On 26/05/16 14:54, Haim Vana wrote: > > Any idea regarding the below ? > > As a workaround how can I update existing client > programmatically ? I couldn't find it in the admin API. > > Thanks again, > > Haim. > > *From:*Haim Vana > *Sent:* Thursday, May 26, 2016 2:17 PM > *To:* keycloak-user at lists.jboss.org > > *Subject:* How to create the same client (same id) for > multiple realms programmatically > > Hi, > > I am trying to create the same client for many realms, > however it creates it only once, probably because they > have the same id, however in UI I am able to create it. > > Any idea how I can create the same client for different > realms programmatically with the same id ? > > This is my code sample: > > ClientRepresentation clientRepresentation = *new *ClientRepresentation(); > > clientRepresentation.setId(clientId); // Same clientId for > all reamls > > realm.clients().create(clientRepresentation); // Client is > created only for first realm > > Any advice will be appreciated, > > Haim. > > The information contained in this message is proprietary > to the sender, protected from disclosure, and may be > privileged. The information is intended to be conveyed > only to the designated recipient(s) of the message. If the > reader of this message is not the intended recipient, you > are hereby notified that any dissemination, use, > distribution or copying of this communication is strictly > prohibited and may be unlawful. If you have received this > communication in error, please notify us immediately by > replying to the message and deleting it from your > computer. Thank you. > > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > The information contained in this message is proprietary to > the sender, protected from disclosure, and may be privileged. > The information is intended to be conveyed only to the > designated recipient(s) of the message. If the reader of this > message is not the intended recipient, you are hereby notified > that any dissemination, use, distribution or copying of this > communication is strictly prohibited and may be unlawful. If > you have received this communication in error, please notify > us immediately by replying to the message and deleting it from > your computer. Thank you. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > The information contained in this message is proprietary to the > sender, protected from disclosure, and may be privileged. The > information is intended to be conveyed only to the designated > recipient(s) of the message. If the reader of this message is not > the intended recipient, you are hereby notified that any > dissemination, use, distribution or copying of this communication > is strictly prohibited and may be unlawful. If you have received > this communication in error, please notify us immediately by > replying to the message and deleting it from your computer. Thank > you. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/562b9e3e/attachment-0001.html From mposolda at redhat.com Mon May 30 06:03:20 2016 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 30 May 2016 12:03:20 +0200 Subject: [keycloak-user] Token generation: possibilities to improve performance In-Reply-To: References: <61D077C6283D454FAFD06F6AC4AB74D723DDFF8E@DEFTHW99EZ1MSX.ww931.my-it-solutions.net> <31bfde5a-c56f-473a-de6f-95d15e32bbd9@redhat.com> <57488196.60104@redhat.com> <574C0448.6090108@redhat.com> Message-ID: <574C0FE8.5090003@redhat.com> On 30/05/16 11:51, Stian Thorgersen wrote: > > > On 30 May 2016 at 11:13, Marek Posolda > wrote: > > On 30/05/16 08:02, Stian Thorgersen wrote: >> Create a JIRA for ECDSA. I don't think we could/should change the >> default, but could be a configuration option for clients. > Added https://issues.jboss.org/browse/KEYCLOAK-3057 with fix > version 2.0.0.CR1 for now. >> >> Looking at OpenID Connect spec it looks like ID token should >> always be generated in token response [1]. However, it should not >> be generated in refresh [2] response. >> >> [1] >> http://openid.net/specs/openid-connect-core-1_0.html#rfc.section.3.1.3.3 >> [2] >> http://openid.net/specs/openid-connect-core-1_0.html#rfc.section.12.2 > hmm... I am reading 12.2 that refresh response "might not" contain > ID Token, hence it's nothing bad if it contains it. So looks we > are currently specs compliant if we have IDToken in both > code-to-token response and refresh response. > > What I mean is, that flag for skip IDToken generation might be > just optional and disabled by default. So by default, IDToken is > available and all the communication is OIDC compliant. However if > someone doesn't need IDToken and wants to save some performance, > he may skip the IDToken generation. > > A week before, I've tried some JProfiler testing of login-logout > test and token generation was the main CPU consumption (I still > had just 1 hashIteration during this profiling, with 20000 it will > be likely very different though). I saw 40% of CPU time in > TokenManager$AccessTokenResponseBuilder.build()due there are 3 > tokens signature here. The option to reduce it from 3 to 2 might > slightly improve some CPU cycles "for free" (security won't be > reduced). > > > I'd argue that we should just include ID token from the authorization > response, while never in the refresh response. That results in better > performance without the need for a config option. Won't that break compatibility for some client applications, which actually use IDToken and rely on the fact that it's properly refreshed every time? Among other things, IDToken contains fields like "exp" , which might then contain expired value as it won't be updated during refreshes. Not sure if users won't be confused due to this. Marek > > > > Marek > > >> On 27 May 2016 at 19:19, Marek Posolda > > wrote: >> >> Regarding this, I wonder if we should add support for ECDSA >> based signatures as an alternative to RSA? Just went through >> some interesting blog [1] , which mentions that 256-bits >> ECDSA has around 9.5 times better performance of signature >> generation than 2048-bits RSA. The time of signature >> verification seems to be slightly worse for ECDSA (see second >> comment), however there is also increased security (256-ECDSA >> is equivalient of 3248 RSA according to blog). Maybe it's >> something we can look at? >> >> Also the optional flag to skip IDToken generation will be >> good too IMO. AFAIK the point of IDToken is the compliance >> with OIDC specification. However in case of Keycloak >> accessToken usually contains all the info like IDToken (+ >> some more) and it's the accessToken, which is used in REST >> endpoints. So with regards to that, most of the >> Keycloak-secured applications can live just with >> access+refresh token and don't need ID Token at all. So if >> just 2 tokens needs to be signed instead of 3, we have >> performance gain "for free" (no decrease of security, just >> one less useless token). >> >> [1] >> https://blog.cloudflare.com/ecdsa-the-digital-signature-algorithm-of-a-better-internet/ >> >> Marek >> >> >> On 24/05/16 15:43, Bill Burke wrote: >>> Are you sure the performance gains are worth less security? >>> What kind of performance are you actually worried about? >>> Network (size of tokens) or CPU >>> (signatures/marshaling/unmarshalling)? If anything, these >>> signatures are only going to get stronger in future releases. >>> >>> On 5/24/16 5:46 AM, Matuszak, Eduard wrote: >>>> Hello >>>> Motivated by considerations on how to improve the >>>> performance of the token generation process I have two >>>> questions: >>>> >>>> * I noticed that Keycloak?s token generation via endpoint >>>> ?auth/realms/ccp/protocol/openid-connect/token? >>>> generates a triple of tokens (access-, refresh- and >>>> id-token). Is there any possibility to dispense with >>>> the id-token generation? >>>> >>>> * Is there a possibility to cause Keycloak to generate >>>> more ?simple? bearer tokens then complex jwt-tokens? >>>> >>>> Best regards, Eduard Matuszak >>>> >>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user at lists.jboss.org >>>> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >>> >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/f576bd4d/attachment.html From amaeztu at tesicnor.com Mon May 30 07:28:21 2016 From: amaeztu at tesicnor.com (Aritz Maeztu) Date: Mon, 30 May 2016 13:28:21 +0200 Subject: [keycloak-user] Redirection issue with proxy behind keycloak In-Reply-To: References: Message-ID: <03225e22-5a31-d3c5-4285-69e355e1950e@tesicnor.com> I've done all the traceability from the proxy server till the login page is displayed: First step, /organization/organizations is requested, so the proxy server knows it has to be forwarded to the 8083 port (the one for the organization service). That's the first request received by my application's Tomcat: 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 START TIME =30-may-2016 13:01:18 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 requestURI=/organizations 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 authType=null 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 characterEncoding=UTF-8 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 contentLength=-1 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 contentType=null 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 contextPath= 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=accept-language=es-ES,es;q=0.8 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=x-forwarded-host=mies-057:8765 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=x-forwarded-prefix=/organization 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=upgrade-insecure-requests=1 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=accept-encoding=gzip 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=accept=text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=user-agent=Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=netflix.nfhttpclient.version=1.0 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=x-netflix-httpclientname=organization 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=host=mies-057:8083 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=connection=Keep-Alive 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 locale=es_ES 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 method=GET 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 pathInfo=null 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 protocol=HTTP/1.1 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 queryString=null 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 remoteAddr=192.168.56.1 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 remoteHost=192.168.56.1 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 remoteUser=null 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 requestedSessionId=null 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 scheme=http 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 serverName=mies-057 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 serverPort=8083 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 servletPath=/organizations 2016-05-30 13:01:18.891 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 isSecure=false 2016-05-30 13:01:18.891 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 ------------------=-------------------------------------------- Here x-forwarded-host is mies-057:8765 (the proxy server) and x-forwarded-prefix is /organization. So the original request is kept in the headers. Well, now my service (8083) tries to check for authorization via the /sso/login endpoint from the keycloak spring security adapter: 2016-05-30 13:01:18.892 DEBUG 18096 --- [nio-8083-exec-9] o.k.a.s.management.HttpSessionManager : Session created: CDCA7AD4439DE94BD0B3B5803DAA0752 2016-05-30 13:01:18.892 DEBUG 18096 --- [nio-8083-exec-9] k.a.s.a.KeycloakAuthenticationEntryPoint : Redirecting to login URI /sso/login 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 ------------------=-------------------------------------------- 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 authType=null 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 contentType=null 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=X-Content-Type-Options=nosniff 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=X-XSS-Protection=1; mode=block 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=Cache-Control=no-cache, no-store, max-age=0, must-revalidate 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=Pragma=no-cache 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=Expires=0 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=X-Frame-Options=DENY 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=Set-Cookie=JSESSIONID=CDCA7AD4439DE94BD0B3B5803DAA0752; Path=/; HttpOnly 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=Location=http://mies-057:8083/sso/login 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 remoteUser=null 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 status=302 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 END TIME =30-may-2016 13:01:18 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 =============================================================== 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 START TIME =30-may-2016 13:01:18 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 requestURI=/sso/login 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 authType=null 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 characterEncoding=UTF-8 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 contentLength=-1 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 contentType=null 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 contextPath= 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 cookie=JSESSIONID=CDCA7AD4439DE94BD0B3B5803DAA0752 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 header=host=mies-057:8083 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 header=connection=keep-alive 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 header=accept=text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 header=upgrade-insecure-requests=1 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 header=user-agent=Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 header=accept-encoding=gzip, deflate, sdch 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 header=accept-language=es-ES,es;q=0.8 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 header=cookie=JSESSIONID=CDCA7AD4439DE94BD0B3B5803DAA0752 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 locale=es_ES 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 method=GET 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 pathInfo=null 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 protocol=HTTP/1.1 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 queryString=null 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 remoteAddr=192.168.56.1 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 remoteHost=192.168.56.1 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 remoteUser=null 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 requestedSessionId=CDCA7AD4439DE94BD0B3B5803DAA0752 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 scheme=http 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 serverName=mies-057 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 serverPort=8083 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 servletPath=/sso/login 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 isSecure=false 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 ------------------=-------------------------------------------- 2016-05-30 13:01:18.904 DEBUG 18096 --- [io-8083-exec-10] o.k.adapters.PreAuthActionsHandler : adminRequest http://mies-057:8083/sso/login 2016-05-30 13:01:18.904 DEBUG 18096 --- [io-8083-exec-10] f.KeycloakAuthenticationProcessingFilter : Request is to process authentication 2016-05-30 13:01:18.904 DEBUG 18096 --- [io-8083-exec-10] f.KeycloakAuthenticationProcessingFilter : Attempting Keycloak authentication 2016-05-30 13:01:18.904 TRACE 18096 --- [io-8083-exec-10] o.k.adapters.RequestAuthenticator : --> authenticate() 2016-05-30 13:01:18.904 TRACE 18096 --- [io-8083-exec-10] o.k.adapters.RequestAuthenticator : try bearer 2016-05-30 13:01:18.904 TRACE 18096 --- [io-8083-exec-10] o.k.adapters.RequestAuthenticator : try oauth 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] o.k.a.s.token.SpringSecurityTokenStore : Checking if org.keycloak.adapters.springsecurity.authentication.SpringSecurityRequestAuthenticator at d328c2d is cached 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] o.k.adapters.OAuthRequestAuthenticator : there was no code 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] o.k.adapters.OAuthRequestAuthenticator : redirecting to auth server 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] o.k.adapters.OAuthRequestAuthenticator : callback uri: http://mies-057:8083/sso/login 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] f.KeycloakAuthenticationProcessingFilter : Auth outcome: NOT_ATTEMPTED 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] o.k.adapters.OAuthRequestAuthenticator : Sending redirect to login page: http://mies-057.tesicnor.com:8080/auth/realms/master/protocol/openid-connect/auth?response_type=code&client_id=organization&redirect_uri=http%3A%2F%2Fmies-057%3A8083%2Fsso%2Flogin&state=1%2F21d709ec-1e69-41c5-ac6d-c705f8ce3907&login=true As it's shown in the logs, the X-forwarded logs are not kept by the keycloak adapter (look at the lines below k.a.s.a.KeycloakAuthenticationEntryPoint : Redirecting to login URI /sso/login). So could it be the proxy server itself being properly configured but the keycloak adapter losing the original headers while performing the redirection? I've also set up the request dumper in the undertow server as Niels suggested, but obviously, X-forwarded headers are not reaching the keycloak server.. Thanks for your time, again ;-) 25/05/2016 7:22(e)an, Stian Thorgersen igorleak idatzi zuen: > You need the Host and X-Forwarded-For headers to be included and > there's also some config to be done on the Keycloak server (see > http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#proxy-address-forwarding) > > On 24 May 2016 at 08:46, Aritz Maeztu > wrote: > > Hi Niels and Scott. First of all, thank you very much for your > help. I'm currently using Zuul (Spring Cloud) as the reverse > proxy. All the services are registered in a discovery service > called Eureka and then Zuul looks for the service id there and > performs de redirection. I read about X-Forwarded headers, but I > thought it might result in a security issue if not included, not > that it could affect the redirection process. > > As Scott says, I suppose the Host and the X-Real-Ip headers are > the relevant ones here, so I guess I should instruct Zuul to send > them when the service is addressed (however I wonder why they are > not already being sent, as Zuul is a proxy service, all in all). > > Here I include a preview of the first redirection made to the > keycloak login page, which shows the request headers sent to the > service /login endpoint (at port 8081 in localhost): > > https://www.dropbox.com/s/iof9yefytzay6j2/screenshot.PNG?dl=0 > > 24/05/2016 2:08(e)an, Niels Bertram igorleak idatzi zuen: >> Hi Artitz, >> >> a great way to figure out what is sent from the reverse proxy to >> your keycloak server is to use the undertow request dumper. >> >> From the jboss-cli just add the request dumper filter to your >> undertow configuration like this: >> >> $KC_HOME/bin/jbpss-cli.sh -c >> >> /subsystem=undertow/configuration=filter/custom-filter=request-dumper:add(class-name=io.undertow.server.handlers.RequestDumpingHandler, >> module=io.undertow.core) >> >> /subsystem=undertow/server=default-server/host=default-host/filter-ref=request-dumper:add >> >> /:reload >> >> given your apache config looks something like this: >> >> ProxyRequests Off >> ProxyPreserveHost On >> ProxyVia On >> >> ProxyPass /auth ajp://127.0.0.1:8009/auth >> >> ProxyPassReverse /auth ajp://127.0.0.1:8009/auth >> >> >> >> you should see something like that (forwared info is somewhat >> rubbish in this example as I am running the hosts on Virtualbox - >> but you can see this request was put through 2 proxies from local >> pc 192.168.33.1 to haproxy on 192.168.33.80 and then apache >> reverse proxy on 192.168.33.81 ): >> >> ============================================================== >> 23:47:20,563 INFO [io.undertow.request.dump] (default task-14) >> ----------------------------REQUEST--------------------------- >> URI=/auth/welcome-content/favicon.ico >> characterEncoding=null >> contentLength=-1 >> contentType=null >> header=Accept=*/* >> header=Accept-Language=en-US,en;q=0.8,de;q=0.6 >> header=Cache-Control=no-cache >> header=Accept-Encoding=gzip, deflate, sdch >> header=DNT=1 >> header=Pragma=no-cache >> header=X-Original-To=192.168.33.80 >> header=User-Agent=Mozilla/5.0 (Windows NT 6.1; WOW64) >> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 >> Safari/537.36 >> header=Authorization=Basic >> bmljZSB0cnkgYnV0IGFtIG5vdCBmcm9tIHllc3RlcmRheQo= >> header=X-Forwarded-Proto=https >> header=X-Forwarded-Port=443 >> header=X-Forwarded-For=192.168.33.1 >> header=Referer=https://login.vagrant.dev/auth/ >> header=Host=login.vagrant.dev >> locale=[en_US, en, de] >> method=GET >> protocol=HTTP/1.1 >> queryString= >> remoteAddr=192.168.33.1:0 >> remoteHost=192.168.33.1 >> scheme=https >> host=login.vagrant.dev >> serverPort=443 >> --------------------------RESPONSE-------------------------- >> contentLength=627 >> contentType=application/octet-stream >> header=Cache-Control=max-age=2592000 >> header=X-Powered-By=Undertow/1 >> header=Server=WildFly/10 >> >> >> Hope this helps diagnosing your issue. Niels >> >> On Tue, May 24, 2016 at 1:20 AM, Aritz Maeztu >> > wrote: >> >> I'm using keycloak to securize some Spring based services >> (with the keycloak spring security adapter). The adapter >> creates a `/login` endpoint in each of the services which >> redirects to the keycloak login page and then redirects back >> to the service when authentication is done. I also have a >> proxy service which I want to publish in the 80 port and will >> take care of routing all the requests to each service. The >> proxy performs a plain FORWARD to the service, but the >> problem comes when I securize the service with the keycloak >> adapter. >> >> When I make a request, the adapter redirects to its login >> endpoint and then to the keycloak auth url. When keycloak >> sends the redirection, the url shown in the browser is the >> one from the service and not the one from the proxy. Do I >> have some choice to tell the adapter I want to redirect back >> to the first requested url? >> >> >> -- >> Aritz Maeztu Ota?o >> Departamento Desarrollo de Software >> >> >> >> Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra) >> Telf.: 948 21 40 40 >> Fax.: 948 21 40 41 >> >> Antes de imprimir este e-mail piense bien si es necesario >> hacerlo: El medioambiente es cosa de todos. >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> > > -- > Aritz Maeztu Ota?o > Departamento Desarrollo de Software > > > > Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra) > Telf.: 948 21 40 40 > Fax.: 948 21 40 41 > > Antes de imprimir este e-mail piense bien si es necesario hacerlo: > El medioambiente es cosa de todos. > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > -- Aritz Maeztu Ota?o Departamento Desarrollo de Software Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra) Telf.: 948 21 40 40 Fax.: 948 21 40 41 Antes de imprimir este e-mail piense bien si es necesario hacerlo: El medioambiente es cosa de todos. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/1d2d3e70/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1295 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/1d2d3e70/attachment-0003.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 2983 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/1d2d3e70/attachment-0003.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1295 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/1d2d3e70/attachment-0004.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 2983 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/1d2d3e70/attachment-0004.png -------------- next part -------------- A non-text attachment was scrubbed... Name: linkdin.gif Type: image/gif Size: 1295 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/1d2d3e70/attachment-0005.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 2983 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/1d2d3e70/attachment-0005.png From palermo at pobox.com Mon May 30 08:42:41 2016 From: palermo at pobox.com (Bruno Palermo) Date: Mon, 30 May 2016 09:42:41 -0300 Subject: [keycloak-user] Terms and Conditions In-Reply-To: References: , <57424DFB.9010200@redhat.com>, , Message-ID: Stian, For the custom registration flow is pretty clear how to deploy. But for the realm resource, how it should be done? Thanks, Bruno Date: Mon, 30 May 2016 07:52:47 +0200 Subject: Re: [keycloak-user] Terms and Conditions From: sthorger at redhat.com To: palermo at pobox.com CC: keycloak-user at lists.jboss.org You could also use the realm resource SPI [1] to add a static page for the terms and conditions. For server-side validation you can use a custom registration flow [2] [1] https://github.com/keycloak/keycloak/blob/master/server-spi/src/main/java/org/keycloak/services/resource/RealmResourceProvider.java[2] http://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html#d4e3969 On 30 May 2016 at 00:48, Bruno Palermo wrote: Stan, For now I'm using a static page outside Keycloak. As for the script I will have a look at the admin client API. Also would be an interested option to force the user to accept the terms before creating an account, just using a regular checkbox on the registration form. Right now I`m doing client side validation using JQuery. Any suggestion for the server side validation? Thanks, Bruno Date: Sun, 22 May 2016 20:25:31 -0400 From: ssilvert at redhat.com To: keycloak-user at lists.jboss.org Subject: Re: [keycloak-user] Terms and Conditions On 5/20/2016 7:24 PM, Bruno Palermo wrote: Hi, It's possible to link directly to the terms and conditions page? What's the URL? You could create your own static page, but it doesn't sound like that's what you want. But linking to the middle of a login flow doesn't make much sense either. In case there's an update to terms, is possible to add the required action to accept the terms again to all users? This is probably what you want. It should be fairly easy to write a script for adding the required action to all users. Are you familiar with the admin client? It might be a nice addition to the admin UI if we allow you to assign a required action to all users. Something to think about for a 2.x feature. Thanks, Bruno _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/9fdb5bf2/attachment.html From amaeztu at tesicnor.com Mon May 30 09:08:08 2016 From: amaeztu at tesicnor.com (Aritz Maeztu) Date: Mon, 30 May 2016 15:08:08 +0200 Subject: [keycloak-user] Fwd: Re: Redirection issue with proxy behind keycloak In-Reply-To: <03225e22-5a31-d3c5-4285-69e355e1950e@tesicnor.com> References: <03225e22-5a31-d3c5-4285-69e355e1950e@tesicnor.com> Message-ID: <5e1b50b9-b7d0-5b2e-b16c-4df98da6f485@tesicnor.com> -------- Birbidalitako mezua -------- Gaia: Re: [keycloak-user] Redirection issue with proxy behind keycloak Data: Mon, 30 May 2016 13:28:21 +0200 Nork: Aritz Maeztu Nori: stian at redhat.com CC: Niels Bertram , keycloak-user , Scott Rossillo I've done all the traceability from the proxy server till the login page is displayed: First step, /organization/organizations is requested, so the proxy server knows it has to be forwarded to the 8083 port (the one for the organization service). That's the first request received by my application's Tomcat: 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 START TIME =30-may-2016 13:01:18 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 requestURI=/organizations 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 authType=null 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 characterEncoding=UTF-8 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 contentLength=-1 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 contentType=null 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 contextPath= 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=accept-language=es-ES,es;q=0.8 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=x-forwarded-host=mies-057:8765 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=x-forwarded-prefix=/organization 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=upgrade-insecure-requests=1 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=accept-encoding=gzip 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=accept=text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=user-agent=Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=netflix.nfhttpclient.version=1.0 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=x-netflix-httpclientname=organization 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=host=mies-057:8083 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=connection=Keep-Alive 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 locale=es_ES 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 method=GET 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 pathInfo=null 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 protocol=HTTP/1.1 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 queryString=null 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 remoteAddr=192.168.56.1 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 remoteHost=192.168.56.1 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 remoteUser=null 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 requestedSessionId=null 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 scheme=http 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 serverName=mies-057 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 serverPort=8083 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 servletPath=/organizations 2016-05-30 13:01:18.891 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 isSecure=false 2016-05-30 13:01:18.891 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 ------------------=-------------------------------------------- Here x-forwarded-host is mies-057:8765 (the proxy server) and x-forwarded-prefix is /organization. So the original request is kept in the headers. Well, now my service (8083) tries to check for authorization via the /sso/login endpoint from the keycloak spring security adapter: 2016-05-30 13:01:18.892 DEBUG 18096 --- [nio-8083-exec-9] o.k.a.s.management.HttpSessionManager : Session created: CDCA7AD4439DE94BD0B3B5803DAA0752 2016-05-30 13:01:18.892 DEBUG 18096 --- [nio-8083-exec-9] k.a.s.a.KeycloakAuthenticationEntryPoint : Redirecting to login URI /sso/login 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 ------------------=-------------------------------------------- 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 authType=null 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 contentType=null 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=X-Content-Type-Options=nosniff 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=X-XSS-Protection=1; mode=block 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=Cache-Control=no-cache, no-store, max-age=0, must-revalidate 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=Pragma=no-cache 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=Expires=0 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=X-Frame-Options=DENY 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=Set-Cookie=JSESSIONID=CDCA7AD4439DE94BD0B3B5803DAA0752; Path=/; HttpOnly 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=Location=http://mies-057:8083/sso/login 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 remoteUser=null 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 status=302 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 END TIME =30-may-2016 13:01:18 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 =============================================================== 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 START TIME =30-may-2016 13:01:18 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 requestURI=/sso/login 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 authType=null 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 characterEncoding=UTF-8 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 contentLength=-1 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 contentType=null 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 contextPath= 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 cookie=JSESSIONID=CDCA7AD4439DE94BD0B3B5803DAA0752 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 header=host=mies-057:8083 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 header=connection=keep-alive 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 header=accept=text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 header=upgrade-insecure-requests=1 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 header=user-agent=Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 header=accept-encoding=gzip, deflate, sdch 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 header=accept-language=es-ES,es;q=0.8 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 header=cookie=JSESSIONID=CDCA7AD4439DE94BD0B3B5803DAA0752 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 locale=es_ES 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 method=GET 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 pathInfo=null 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 protocol=HTTP/1.1 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 queryString=null 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 remoteAddr=192.168.56.1 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 remoteHost=192.168.56.1 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 remoteUser=null 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 requestedSessionId=CDCA7AD4439DE94BD0B3B5803DAA0752 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 scheme=http 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 serverName=mies-057 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 serverPort=8083 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 servletPath=/sso/login 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 isSecure=false 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 ------------------=-------------------------------------------- 2016-05-30 13:01:18.904 DEBUG 18096 --- [io-8083-exec-10] o.k.adapters.PreAuthActionsHandler : adminRequest http://mies-057:8083/sso/login 2016-05-30 13:01:18.904 DEBUG 18096 --- [io-8083-exec-10] f.KeycloakAuthenticationProcessingFilter : Request is to process authentication 2016-05-30 13:01:18.904 DEBUG 18096 --- [io-8083-exec-10] f.KeycloakAuthenticationProcessingFilter : Attempting Keycloak authentication 2016-05-30 13:01:18.904 TRACE 18096 --- [io-8083-exec-10] o.k.adapters.RequestAuthenticator : --> authenticate() 2016-05-30 13:01:18.904 TRACE 18096 --- [io-8083-exec-10] o.k.adapters.RequestAuthenticator : try bearer 2016-05-30 13:01:18.904 TRACE 18096 --- [io-8083-exec-10] o.k.adapters.RequestAuthenticator : try oauth 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] o.k.a.s.token.SpringSecurityTokenStore : Checking if org.keycloak.adapters.springsecurity.authentication.SpringSecurityRequestAuthenticator at d328c2d is cached 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] o.k.adapters.OAuthRequestAuthenticator : there was no code 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] o.k.adapters.OAuthRequestAuthenticator : redirecting to auth server 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] o.k.adapters.OAuthRequestAuthenticator : callback uri: http://mies-057:8083/sso/login 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] f.KeycloakAuthenticationProcessingFilter : Auth outcome: NOT_ATTEMPTED 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] o.k.adapters.OAuthRequestAuthenticator : Sending redirect to login page: http://mies-057.tesicnor.com:8080/auth/realms/master/protocol/openid-connect/auth?response_type=code&client_id=organization&redirect_uri=http%3A%2F%2Fmies-057%3A8083%2Fsso%2Flogin&state=1%2F21d709ec-1e69-41c5-ac6d-c705f8ce3907&login=true As it's shown in the logs, the X-forwarded logs are not kept by the keycloak adapter (look at the lines below k.a.s.a.KeycloakAuthenticationEntryPoint : Redirecting to login URI /sso/login). So could it be the proxy server itself being properly configured but the keycloak adapter losing the original headers while performing the redirection? I've also set up the request dumper in the undertow server as Niels suggested, but obviously, X-forwarded headers are not reaching the keycloak server.. Thanks for your time, again ;-) 25/05/2016 7:22(e)an, Stian Thorgersen igorleak idatzi zuen: > You need the Host and X-Forwarded-For headers to be included and > there's also some config to be done on the Keycloak server (see > http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#proxy-address-forwarding) > > On 24 May 2016 at 08:46, Aritz Maeztu > wrote: > > Hi Niels and Scott. First of all, thank you very much for your > help. I'm currently using Zuul (Spring Cloud) as the reverse > proxy. All the services are registered in a discovery service > called Eureka and then Zuul looks for the service id there and > performs de redirection. I read about X-Forwarded headers, but I > thought it might result in a security issue if not included, not > that it could affect the redirection process. > > As Scott says, I suppose the Host and the X-Real-Ip headers are > the relevant ones here, so I guess I should instruct Zuul to send > them when the service is addressed (however I wonder why they are > not already being sent, as Zuul is a proxy service, all in all). > > Here I include a preview of the first redirection made to the > keycloak login page, which shows the request headers sent to the > service /login endpoint (at port 8081 in localhost): > > https://www.dropbox.com/s/iof9yefytzay6j2/screenshot.PNG?dl=0 > > 24/05/2016 2:08(e)an, Niels Bertram igorleak idatzi zuen: >> Hi Artitz, >> >> a great way to figure out what is sent from the reverse proxy to >> your keycloak server is to use the undertow request dumper. >> >> From the jboss-cli just add the request dumper filter to your >> undertow configuration like this: >> >> $KC_HOME/bin/jbpss-cli.sh -c >> >> /subsystem=undertow/configuration=filter/custom-filter=request-dumper:add(class-name=io.undertow.server.handlers.RequestDumpingHandler, >> module=io.undertow.core) >> >> /subsystem=undertow/server=default-server/host=default-host/filter-ref=request-dumper:add >> >> /:reload >> >> given your apache config looks something like this: >> >> ProxyRequests Off >> ProxyPreserveHost On >> ProxyVia On >> >> ProxyPass /auth ajp://127.0.0.1:8009/auth >> >> ProxyPassReverse /auth ajp://127.0.0.1:8009/auth >> >> >> >> you should see something like that (forwared info is somewhat >> rubbish in this example as I am running the hosts on Virtualbox - >> but you can see this request was put through 2 proxies from local >> pc 192.168.33.1 to haproxy on 192.168.33.80 and then apache >> reverse proxy on 192.168.33.81 ): >> >> ============================================================== >> 23:47:20,563 INFO [io.undertow.request.dump] (default task-14) >> ----------------------------REQUEST--------------------------- >> URI=/auth/welcome-content/favicon.ico >> characterEncoding=null >> contentLength=-1 >> contentType=null >> header=Accept=*/* >> header=Accept-Language=en-US,en;q=0.8,de;q=0.6 >> header=Cache-Control=no-cache >> header=Accept-Encoding=gzip, deflate, sdch >> header=DNT=1 >> header=Pragma=no-cache >> header=X-Original-To=192.168.33.80 >> header=User-Agent=Mozilla/5.0 (Windows NT 6.1; WOW64) >> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 >> Safari/537.36 >> header=Authorization=Basic >> bmljZSB0cnkgYnV0IGFtIG5vdCBmcm9tIHllc3RlcmRheQo= >> header=X-Forwarded-Proto=https >> header=X-Forwarded-Port=443 >> header=X-Forwarded-For=192.168.33.1 >> header=Referer=https://login.vagrant.dev/auth/ >> header=Host=login.vagrant.dev >> locale=[en_US, en, de] >> method=GET >> protocol=HTTP/1.1 >> queryString= >> remoteAddr=192.168.33.1:0 >> remoteHost=192.168.33.1 >> scheme=https >> host=login.vagrant.dev >> serverPort=443 >> --------------------------RESPONSE-------------------------- >> contentLength=627 >> contentType=application/octet-stream >> header=Cache-Control=max-age=2592000 >> header=X-Powered-By=Undertow/1 >> header=Server=WildFly/10 >> >> >> Hope this helps diagnosing your issue. Niels >> >> On Tue, May 24, 2016 at 1:20 AM, Aritz Maeztu >> wrote: >> >> I'm using keycloak to securize some Spring based services >> (with the keycloak spring security adapter). The adapter >> creates a `/login` endpoint in each of the services which >> redirects to the keycloak login page and then redirects back >> to the service when authentication is done. I also have a >> proxy service which I want to publish in the 80 port and will >> take care of routing all the requests to each service. The >> proxy performs a plain FORWARD to the service, but the >> problem comes when I securize the service with the keycloak >> adapter. >> >> When I make a request, the adapter redirects to its login >> endpoint and then to the keycloak auth url. When keycloak >> sends the redirection, the url shown in the browser is the >> one from the service and not the one from the proxy. Do I >> have some choice to tell the adapter I want to redirect back >> to the first requested url? >> >> >> -- >> Aritz Maeztu Ota?o >> Departamento Desarrollo de Software >> >> >> >> Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra) >> Telf.: 948 21 40 40 >> Fax.: 948 21 40 41 >> >> Antes de imprimir este e-mail piense bien si es necesario >> hacerlo: El medioambiente es cosa de todos. >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> > > -- > Aritz Maeztu Ota?o > Departamento Desarrollo de Software > > > > Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra) > Telf.: 948 21 40 40 > Fax.: 948 21 40 41 > > Antes de imprimir este e-mail piense bien si es necesario hacerlo: > El medioambiente es cosa de todos. > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > -- Aritz Maeztu Ota?o Departamento Desarrollo de Software Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra) Telf.: 948 21 40 40 Fax.: 948 21 40 41 Antes de imprimir este e-mail piense bien si es necesario hacerlo: El medioambiente es cosa de todos. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/a4ad21df/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1295 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/a4ad21df/attachment-0003.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 2983 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/a4ad21df/attachment-0003.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1295 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/a4ad21df/attachment-0004.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 2983 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/a4ad21df/attachment-0004.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1295 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/a4ad21df/attachment-0005.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 2983 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/a4ad21df/attachment-0005.png From palermo at pobox.com Mon May 30 12:23:56 2016 From: palermo at pobox.com (Bruno Palermo) Date: Mon, 30 May 2016 13:23:56 -0300 Subject: [keycloak-user] Terms and Conditions In-Reply-To: References: , <57424DFB.9010200@redhat.com>, , Message-ID: Stian, I could find the example implementation here: https://github.com/keycloak/keycloak/blob/master/examples/providers/rest/src/main/java/org/keycloak/examples/rest/HelloResourceProvider.java But how can I return an freemarker template? Thanks! Date: Mon, 30 May 2016 07:52:47 +0200 Subject: Re: [keycloak-user] Terms and Conditions From: sthorger at redhat.com To: palermo at pobox.com CC: keycloak-user at lists.jboss.org You could also use the realm resource SPI [1] to add a static page for the terms and conditions. For server-side validation you can use a custom registration flow [2] [1] https://github.com/keycloak/keycloak/blob/master/server-spi/src/main/java/org/keycloak/services/resource/RealmResourceProvider.java[2] http://keycloak.github.io/docs/userguide/keycloak-server/html/auth_spi.html#d4e3969 On 30 May 2016 at 00:48, Bruno Palermo wrote: Stan, For now I'm using a static page outside Keycloak. As for the script I will have a look at the admin client API. Also would be an interested option to force the user to accept the terms before creating an account, just using a regular checkbox on the registration form. Right now I`m doing client side validation using JQuery. Any suggestion for the server side validation? Thanks, Bruno Date: Sun, 22 May 2016 20:25:31 -0400 From: ssilvert at redhat.com To: keycloak-user at lists.jboss.org Subject: Re: [keycloak-user] Terms and Conditions On 5/20/2016 7:24 PM, Bruno Palermo wrote: Hi, It's possible to link directly to the terms and conditions page? What's the URL? You could create your own static page, but it doesn't sound like that's what you want. But linking to the middle of a login flow doesn't make much sense either. In case there's an update to terms, is possible to add the required action to accept the terms again to all users? This is probably what you want. It should be fairly easy to write a script for adding the required action to all users. Are you familiar with the admin client? It might be a nice addition to the admin UI if we allow you to assign a required action to all users. Something to think about for a 2.x feature. Thanks, Bruno _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/58e13ad7/attachment.html From sthorger at redhat.com Mon May 30 14:23:04 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 30 May 2016 20:23:04 +0200 Subject: [keycloak-user] Hide idp selection page In-Reply-To: References: Message-ID: You can do this by creating a custom theme and overiding login.ftl On 30 May 2016 at 11:37, Kristiaan Jansen < Kristiaan.Jansen at planonsoftware.com> wrote: > Hi > > I would like to hide the idp?s on the main login of the key cloak. > > Senario: > I have multiple idp?s and key cloak infront of that as a SP. > I am automatically letting the different groups go to the right idp with > kc_idp_hint. > But if a group goes to the sp url by accident I don?t want a the full list > of all the IDP?s to be visible. > > Is there a way to achieve this in key cloak? > > IdpA(key cloak)???| > | > idpB(key cloak)???|????SP(key cloak)idp??? mywebaplication(tomcat). > | > ipdC(key cloak)???| > > Thanks, > Kris > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/8aaddf4f/attachment.html From sthorger at redhat.com Mon May 30 14:24:30 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 30 May 2016 20:24:30 +0200 Subject: [keycloak-user] How to create the same client (same id) for multiple realms programmatically In-Reply-To: <574C0E9D.7040000@redhat.com> References: <5746F714.6050007@redhat.com> <7l5jkwwlier47ro5c1dsdqcg.1464332607708@email.android.com> <574C0E9D.7040000@redhat.com> Message-ID: +1 Not the correct thread for it though ;) On 30 May 2016 at 11:57, Marek Posolda wrote: > Maybe someone already mentions it before. IMO the returning "Response" > from the create methods on admin client is one of the biggest limitation of > current admin-client. For example if we change ClientResources method: > > @POST at Consumes(MediaType.APPLICATION_JSON)public Response create(ClientRepresentation clientRepresentation); > > > to something like: > > @POST at Consumes(MediaType.APPLICATION_JSON)@Produces(MediaType.APPLICATION_JSON)public ClientRepresentation create(ClientRepresentation clientRepresentation); > > > > > then the advantages will be: > - You won't need to parse the ID of newly created client from the URI > location and call additional GET request to retrieve newly created client > (You usually want newly created client when you are creating it) > - In case the error happened, the exception will be thrown on client-side > too. With the "Response" object, the exception is not thrown on client-side > but you are supposed to manually check the status code. This may be > confusing for users, who are not so familiar with the admin client. When > exception is thrown on client-side, it's crystal clear that something bad > happened and client wasn't successfully created on server side. > > Are there any disadvantages? The only one I see is, that POST responses > from server will need to return the representation of created object, but > that's maybe rather advantage (as you don't need to call additional GET > request, which in 95% of cases you need). > > Marek > > > On 30/05/16 08:04, Stian Thorgersen wrote: > > What's the status code for the response? It should be 409. > > On 27 May 2016 at 09:02, Haim Vana wrote: > >> There is an exception in the server log, but it is not thrown, so I am >> not getting it in my code. >> >> >> >> -------- Original message -------- >> From: Stian Thorgersen < sthorger at redhat.com> >> Date: 5/27/16 09:24 (GMT+02:00) >> To: Haim Vana >> Cc: Marek Posolda , keycloak-user at lists.jboss.org >> Subject: Re: [keycloak-user] How to create the same client (same id) for >> multiple realms programmatically >> >> Do you not get a error when trying to create it the second time with the >> same id? If not please create a jira. >> >> On 26 May 2016 at 20:20, Haim Vana < >> haimv at perfectomobile.com> wrote: >> >>> Thanks for your reply. >>> >>> >>> >>> My problem was that I have used setId instead of setClientId. >>> >>> >>> >>> *From:* Marek Posolda [mailto: mposolda at redhat.com] >>> >>> *Sent:* Thursday, May 26, 2016 4:16 PM >>> *To:* Haim Vana < haimv at perfectomobile.com>; >>> keycloak-user at lists.jboss.org >>> *Subject:* Re: [keycloak-user] How to create the same client (same id) >>> for multiple realms programmatically >>> >>> >>> >>> You can use for example: >>> >>> RealmResource realm1 = *adminClient*.realms().realm(*"realm1"*); >>> >>> RealmResource realm2 = *adminClient*.realms().realm(*"realm2"*); >>> >>> realm1.clients().create(clientRepresentation); >>> >>> realm2.clients().create(clientRepresentation); >>> >>> >>> >>> >>> For update you can take a look at some of our tests, which are updating >>> client. For example this one : >>> https://github.com/mposolda/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/admin/ClientTest.java#L183 >>> >>> Note that you need to know client Id (this is different thant clientId). >>> The easiest is to set it manually in representation before you create >>> client (via client.setId ) like it's done in this test. >>> >>> Marek >>> >>> On 26/05/16 14:54, Haim Vana wrote: >>> >>> Any idea regarding the below ? >>> >>> >>> >>> As a workaround how can I update existing client programmatically ? I >>> couldn't find it in the admin API. >>> >>> >>> >>> >>> >>> Thanks again, >>> >>> Haim. >>> >>> >>> >>> *From:* Haim Vana >>> *Sent:* Thursday, May 26, 2016 2:17 PM >>> *To:* keycloak-user at lists.jboss.org >>> *Subject:* How to create the same client (same id) for multiple realms >>> programmatically >>> >>> >>> >>> Hi, >>> >>> >>> >>> I am trying to create the same client for many realms, however it >>> creates it only once, probably because they have the same id, however in UI >>> I am able to create it. >>> >>> >>> >>> Any idea how I can create the same client for different realms >>> programmatically with the same id ? >>> >>> >>> >>> This is my code sample: >>> >>> ClientRepresentation clientRepresentation = *new *ClientRepresentation(); >>> >>> clientRepresentation.setId(clientId); // Same clientId for all reamls >>> >>> realm.clients().create(clientRepresentation); // Client is created only >>> for first realm >>> >>> >>> >>> >>> >>> Any advice will be appreciated, >>> >>> Haim. >>> >>> The information contained in this message is proprietary to the sender, >>> protected from disclosure, and may be privileged. The information is >>> intended to be conveyed only to the designated recipient(s) of the message. >>> If the reader of this message is not the intended recipient, you are hereby >>> notified that any dissemination, use, distribution or copying of this >>> communication is strictly prohibited and may be unlawful. If you have >>> received this communication in error, please notify us immediately by >>> replying to the message and deleting it from your computer. Thank you. >>> >>> >>> _______________________________________________ >>> >>> keycloak-user mailing list >>> >>> keycloak-user at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >>> >>> The information contained in this message is proprietary to the sender, >>> protected from disclosure, and may be privileged. The information is >>> intended to be conveyed only to the designated recipient(s) of the message. >>> If the reader of this message is not the intended recipient, you are hereby >>> notified that any dissemination, use, distribution or copying of this >>> communication is strictly prohibited and may be unlawful. If you have >>> received this communication in error, please notify us immediately by >>> replying to the message and deleting it from your computer. Thank you. >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> >> The information contained in this message is proprietary to the sender, >> protected from disclosure, and may be privileged. The information is >> intended to be conveyed only to the designated recipient(s) of the message. >> If the reader of this message is not the intended recipient, you are hereby >> notified that any dissemination, use, distribution or copying of this >> communication is strictly prohibited and may be unlawful. If you have >> received this communication in error, please notify us immediately by >> replying to the message and deleting it from your computer. Thank you. >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/0c51d31e/attachment-0001.html From ivan at akvo.org Mon May 30 14:53:45 2016 From: ivan at akvo.org (=?UTF-8?Q?Iv=c3=a1n_Perdomo?=) Date: Mon, 30 May 2016 20:53:45 +0200 Subject: [keycloak-user] Undertow adapter Message-ID: <5e8fbf0b-f405-117f-8f47-044f4677ea2d@akvo.org> Hi, I was wondering what's the status of the Undertow adapter. I see that there is some code in the repository [1], but is not documented in the docs. My intention is to know if I can make it work with Immutant web [2] [1] https://github.com/keycloak/keycloak/tree/1.9.5.Final/adapters/oidc/undertow [2] http://immutant.org/documentation/current/apidoc/guide-web.html Thanks, -- Iv?n -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/6af401d5/attachment.bin From sthorger at redhat.com Mon May 30 15:03:19 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 30 May 2016 21:03:19 +0200 Subject: [keycloak-user] Undertow adapter In-Reply-To: <5e8fbf0b-f405-117f-8f47-044f4677ea2d@akvo.org> References: <5e8fbf0b-f405-117f-8f47-044f4677ea2d@akvo.org> Message-ID: The Undertow adapter is the basis for our WildFly adapter so should in theory work. On 30 May 2016 at 20:53, Iv?n Perdomo wrote: > Hi, > > I was wondering what's the status of the Undertow adapter. I see that > there is some code in the repository [1], but is not documented in the > docs. > > My intention is to know if I can make it work with Immutant web [2] > > > [1] > > https://github.com/keycloak/keycloak/tree/1.9.5.Final/adapters/oidc/undertow > [2] http://immutant.org/documentation/current/apidoc/guide-web.html > > Thanks, > > -- > Iv?n > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/8af5bcd2/attachment.html From sthorger at redhat.com Mon May 30 15:04:49 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 30 May 2016 21:04:49 +0200 Subject: [keycloak-user] Token generation: possibilities to improve performance In-Reply-To: <574C0FE8.5090003@redhat.com> References: <61D077C6283D454FAFD06F6AC4AB74D723DDFF8E@DEFTHW99EZ1MSX.ww931.my-it-solutions.net> <31bfde5a-c56f-473a-de6f-95d15e32bbd9@redhat.com> <57488196.60104@redhat.com> <574C0448.6090108@redhat.com> <574C0FE8.5090003@redhat.com> Message-ID: On 30 May 2016 at 12:03, Marek Posolda wrote: > On 30/05/16 11:51, Stian Thorgersen wrote: > > > > On 30 May 2016 at 11:13, Marek Posolda wrote: > >> On 30/05/16 08:02, Stian Thorgersen wrote: >> >> Create a JIRA for ECDSA. I don't think we could/should change the >> default, but could be a configuration option for clients. >> >> Added https://issues.jboss.org/browse/KEYCLOAK-3057 with fix version >> 2.0.0.CR1 for now. >> >> >> Looking at OpenID Connect spec it looks like ID token should always be >> generated in token response [1]. However, it should not be generated in >> refresh [2] response. >> >> [1] >> >> http://openid.net/specs/openid-connect-core-1_0.html#rfc.section.3.1.3.3 >> [2] >> >> http://openid.net/specs/openid-connect-core-1_0.html#rfc.section.12.2 >> >> hmm... I am reading 12.2 that refresh response "might not" contain ID >> Token, hence it's nothing bad if it contains it. So looks we are currently >> specs compliant if we have IDToken in both code-to-token response and >> refresh response. >> >> What I mean is, that flag for skip IDToken generation might be just >> optional and disabled by default. So by default, IDToken is available and >> all the communication is OIDC compliant. However if someone doesn't need >> IDToken and wants to save some performance, he may skip the IDToken >> generation. >> >> A week before, I've tried some JProfiler testing of login-logout test and >> token generation was the main CPU consumption (I still had just 1 >> hashIteration during this profiling, with 20000 it will be likely very >> different though). I saw 40% of CPU time in TokenManager$ >> AccessTokenResponseBuilder.build() due there are 3 tokens signature >> here. The option to reduce it from 3 to 2 might slightly improve some CPU >> cycles "for free" (security won't be reduced). >> > > I'd argue that we should just include ID token from the authorization > response, while never in the refresh response. That results in better > performance without the need for a config option. > > Won't that break compatibility for some client applications, which > actually use IDToken and rely on the fact that it's properly refreshed > every time? Among other things, IDToken contains fields like "exp" , which > might then contain expired value as it won't be updated during refreshes. > Not sure if users won't be confused due to this. > Surely the exp for an IDToken should be set to the session expiration and not to the expiration of access token though? Do we even update the profile details in the token or just fill it with whatever was there before? > > > Marek > > > >> >> >> Marek >> >> >> On 27 May 2016 at 19:19, Marek Posolda < >> mposolda at redhat.com> wrote: >> >>> Regarding this, I wonder if we should add support for ECDSA based >>> signatures as an alternative to RSA? Just went through some interesting >>> blog [1] , which mentions that 256-bits ECDSA has around 9.5 times better >>> performance of signature generation than 2048-bits RSA. The time of >>> signature verification seems to be slightly worse for ECDSA (see second >>> comment), however there is also increased security (256-ECDSA is >>> equivalient of 3248 RSA according to blog). Maybe it's something we can >>> look at? >>> >>> Also the optional flag to skip IDToken generation will be good too IMO. >>> AFAIK the point of IDToken is the compliance with OIDC specification. >>> However in case of Keycloak accessToken usually contains all the info like >>> IDToken (+ some more) and it's the accessToken, which is used in REST >>> endpoints. So with regards to that, most of the Keycloak-secured >>> applications can live just with access+refresh token and don't need ID >>> Token at all. So if just 2 tokens needs to be signed instead of 3, we have >>> performance gain "for free" (no decrease of security, just one less useless >>> token). >>> >>> [1] >>> https://blog.cloudflare.com/ecdsa-the-digital-signature-algorithm-of-a-better-internet/ >>> >>> Marek >>> >>> >>> On 24/05/16 15:43, Bill Burke wrote: >>> >>> Are you sure the performance gains are worth less security? What kind >>> of performance are you actually worried about? Network (size of tokens) or >>> CPU (signatures/marshaling/unmarshalling)? If anything, these signatures >>> are only going to get stronger in future releases. >>> >>> On 5/24/16 5:46 AM, Matuszak, Eduard wrote: >>> >>> Hello >>> >>> Motivated by considerations on how to improve the performance of the >>> token generation process I have two questions: >>> >>> >>> - I noticed that Keycloak?s token generation via endpoint >>> ?auth/realms/ccp/protocol/openid-connect/token? generates a triple of >>> tokens (access-, refresh- and id-token). Is there any possibility to >>> dispense with the id-token generation? >>> >>> >>> >>> - Is there a possibility to cause Keycloak to generate more ?simple? >>> bearer tokens then complex jwt-tokens? >>> >>> >>> >>> Best regards, Eduard Matuszak >>> >>> >>> >>> _______________________________________________ >>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user >>> >>> >>> >>> >>> _______________________________________________ >>> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user >>> >>> >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/d67a9308/attachment-0001.html From haimv at perfectomobile.com Mon May 30 15:21:59 2016 From: haimv at perfectomobile.com (Haim Vana) Date: Mon, 30 May 2016 19:21:59 +0000 Subject: [keycloak-user] How to get specific client role programmatically In-Reply-To: References: Message-ID: But the ClientRepresentation doesn?t have any getRole method, so should I do it ? Here is my code: ClientRepresentation clientRepresentation = masterRealm.clients().findByClientId(realmName + "-realm").get(0); Thanks, Haim. From: Stian Thorgersen [mailto:sthorger at redhat.com] Sent: Monday, May 30, 2016 10:27 AM To: Haim Vana Cc: keycloak-user at lists.jboss.org Subject: Re: [keycloak-user] How to get specific client role programmatically To get a specific role for a client you need to get the client, then the role from that client. It's not available through the user resource. On 30 May 2016 at 08:58, Haim Vana > wrote: Any idea regarding the below ? From: keycloak-user-bounces at lists.jboss.org [mailto:keycloak-user-bounces at lists.jboss.org] On Behalf Of Haim Vana Sent: Wednesday, May 25, 2016 10:53 PM To: keycloak-user at lists.jboss.org Subject: [keycloak-user] How to get specific client role programmatically Hi, I am using the KeyCloak API to create admin users and update their roles, I am able to add to an admin user all the available client roles, however how can I add a specific one ? This is my code to get all the available client roles: userResource.roles().clientLevel(userRealmClientId).listAvailable() How can I get specific one and not all ? Any advice will be appreciated, Haim. The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user The information contained in this message is proprietary to the sender, protected from disclosure, and may be privileged. The information is intended to be conveyed only to the designated recipient(s) of the message. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/1925819d/attachment.html From rsoares at redhat.com Mon May 30 15:42:17 2016 From: rsoares at redhat.com (Rafael T. C. Soares) Date: Mon, 30 May 2016 16:42:17 -0300 Subject: [keycloak-user] dotNet integration Message-ID: <574C9799.6090407@redhat.com> Hi all. What are the options available to integrate/secure dotNet apps with Keycloak today? Is there any plan to provide a Keycloak adapter for dotNet? Can someone give some insight on this kind of integration? Thanks in advance. -- ___ Rafael T. C. Soares From thomas.darimont at googlemail.com Mon May 30 16:05:09 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Mon, 30 May 2016 22:05:09 +0200 Subject: [keycloak-user] dotNet integration In-Reply-To: <574C9799.6090407@redhat.com> References: <574C9799.6090407@redhat.com> Message-ID: Hello Rafael, from what kind of app do you want to authenticate with keycloak? Recent asp.net / mvc versions ship with support for OpenID Connect (OIDC) See: https://leastprivilege.com/2015/07/22/the-state-of-security-in-asp-net-5-and-mvc-6-oauth-2-0-openid-connect-and-identityserver/ Cheers, Thomas 2016-05-30 21:42 GMT+02:00 Rafael T. C. Soares : > Hi all. > > What are the options available to integrate/secure dotNet apps with > Keycloak today? > Is there any plan to provide a Keycloak adapter for dotNet? > > Can someone give some insight on this kind of integration? > Thanks in advance. > > -- > ___ > Rafael T. C. Soares > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/3431aca6/attachment-0001.html From thomas.darimont at googlemail.com Mon May 30 16:20:55 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Mon, 30 May 2016 22:20:55 +0200 Subject: [keycloak-user] dotNet integration In-Reply-To: References: <574C9799.6090407@redhat.com> Message-ID: small addition: You could also have a look at the client examples [1] of the .Net IdentityServer [0] project: Keycloak could also be registered as an Identity Provider in the IdentityServer. Cheers, Thomas [0] https://github.com/IdentityServer/IdentityServer3 [1] https://github.com/IdentityServer/IdentityServer3.Samples/tree/master/source/Clients 2016-05-30 22:05 GMT+02:00 Thomas Darimont : > Hello Rafael, > > from what kind of app do you want to authenticate with keycloak? > Recent asp.net / mvc versions ship with support for OpenID Connect (OIDC) > See: > > https://leastprivilege.com/2015/07/22/the-state-of-security-in-asp-net-5-and-mvc-6-oauth-2-0-openid-connect-and-identityserver/ > > Cheers, > Thomas > > 2016-05-30 21:42 GMT+02:00 Rafael T. C. Soares : > >> Hi all. >> >> What are the options available to integrate/secure dotNet apps with >> Keycloak today? >> Is there any plan to provide a Keycloak adapter for dotNet? >> >> Can someone give some insight on this kind of integration? >> Thanks in advance. >> >> -- >> ___ >> Rafael T. C. Soares >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/0c97eee9/attachment.html From rsoares at redhat.com Mon May 30 16:24:12 2016 From: rsoares at redhat.com (Rafael T. C. Soares) Date: Mon, 30 May 2016 17:24:12 -0300 Subject: [keycloak-user] dotNet integration In-Reply-To: References: <574C9799.6090407@redhat.com> Message-ID: <574CA16C.8010307@redhat.com> Hi Thomas! I'm not a dotNet guy but I would like to implement a simple demo to prove this integration. I would like to demo a simple SSO between two simple web apps using the Keycloak as the Auth/SSO Server. The first app is an ordinary Java web app deployed in IBM WAS (for this one I'll use the Keycloak servlet filter adapter) The second app is a very simple dotNet web app. The dotNet guys whom I'm in contact for this demo are using MVC version 4.5 (C# and ASP.net) and an IIS 7.5 Web server. I'll take a look on this blog post. I appreciate any additional info on this subject. tnx ___ Rafael T. C. Soares On 05/30/2016 05:05 PM, Thomas Darimont wrote: > Hello Rafael, > > from what kind of app do you want to authenticate with keycloak? > Recent asp.net / mvc versions ship with support for > OpenID Connect (OIDC) > See: > https://leastprivilege.com/2015/07/22/the-state-of-security-in-asp-net-5-and-mvc-6-oauth-2-0-openid-connect-and-identityserver/ > > Cheers, > Thomas > > 2016-05-30 21:42 GMT+02:00 Rafael T. C. Soares >: > > Hi all. > > What are the options available to integrate/secure dotNet apps with > Keycloak today? > Is there any plan to provide a Keycloak adapter for dotNet? > > Can someone give some insight on this kind of integration? > Thanks in advance. > > -- > ___ > Rafael T. C. Soares > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/ac4c4e19/attachment.html From lists at zopyx.com Tue May 31 00:56:10 2016 From: lists at zopyx.com (Andreas Jung) Date: Mon, 30 May 2016 21:56:10 -0700 Subject: [keycloak-user] URL/Auth of REST API Message-ID: Hi there, currently evaluating Keyclock and its REST API in particular. I am running standalone.sh and created an 'admin' user with password 'admin' My expectation was that the following URL call would work: wget http://admin:admin at localhost:8080/auth/admin/realms --2016-05-30 21:52:34-- http://admin: *password*@localhost:8080/auth/admin/realms Resolving localhost... ::1, 127.0.0.1, fe80::1 Connecting to localhost|::1|:8080... failed: Connection refused. Connecting to localhost|127.0.0.1|:8080... connected. HTTP request sent, awaiting response... 401 Unauthorized Unknown authentication scheme. Username/Password Authentication Failed. ...but it does not...any insight? Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160530/34741281/attachment.html From sthorger at redhat.com Tue May 31 01:05:44 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 31 May 2016 07:05:44 +0200 Subject: [keycloak-user] dotNet integration In-Reply-To: <574CA16C.8010307@redhat.com> References: <574C9799.6090407@redhat.com> <574CA16C.8010307@redhat.com> Message-ID: I've not tried this myself, but there's https://github.com/dylanplecki/KeycloakOwinAuthentication/wiki On 30 May 2016 at 22:24, Rafael T. C. Soares wrote: > Hi Thomas! > > I'm not a dotNet guy but I would like to implement a simple demo to prove > this integration. > I would like to demo a simple SSO between two simple web apps using the > Keycloak as the Auth/SSO Server. > > The first app is an ordinary Java web app deployed in IBM WAS (for this > one I'll use the Keycloak servlet filter adapter) > The second app is a very simple dotNet web app. > > The dotNet guys whom I'm in contact for this demo are using MVC version > 4.5 (C# and ASP.net) and an IIS 7.5 Web server. > > I'll take a look on this blog post. I appreciate any additional info on > this subject. > > tnx > > ___ > Rafael T. C. Soares > > On 05/30/2016 05:05 PM, Thomas Darimont wrote: > > Hello Rafael, > > from what kind of app do you want to authenticate with keycloak? > Recent asp.net / mvc versions ship with support for OpenID Connect (OIDC) > See: > > https://leastprivilege.com/2015/07/22/the-state-of-security-in-asp-net-5-and-mvc-6-oauth-2-0-openid-connect-and-identityserver/ > > Cheers, > Thomas > > 2016-05-30 21:42 GMT+02:00 Rafael T. C. Soares : > >> Hi all. >> >> What are the options available to integrate/secure dotNet apps with >> Keycloak today? >> Is there any plan to provide a Keycloak adapter for dotNet? >> >> Can someone give some insight on this kind of integration? >> Thanks in advance. >> >> -- >> ___ >> Rafael T. C. Soares >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/e8915279/attachment.html From sthorger at redhat.com Tue May 31 01:11:48 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 31 May 2016 07:11:48 +0200 Subject: [keycloak-user] URL/Auth of REST API In-Reply-To: References: Message-ID: You need a bearer token to invoke it. Take a look at http://keycloak.github.io/docs/userguide/keycloak-server/html/direct-access-grants.html / http://keycloak.github.io/docs/userguide/keycloak-server/html/admin-rest-api.html . On 31 May 2016 at 06:56, Andreas Jung wrote: > Hi there, > > currently evaluating Keyclock and its REST API in particular. > > I am running standalone.sh and created an 'admin' user with password > 'admin' > > My expectation was that the following URL call would work: > > wget http://admin:admin at localhost:8080/auth/admin/realms > > --2016-05-30 21:52:34-- http://admin: > *password*@localhost:8080/auth/admin/realms > > Resolving localhost... ::1, 127.0.0.1, fe80::1 > > Connecting to localhost|::1|:8080... failed: Connection refused. > > Connecting to localhost|127.0.0.1|:8080... connected. > > HTTP request sent, awaiting response... 401 Unauthorized > > Unknown authentication scheme. > > > Username/Password Authentication Failed. > > > ...but it does not...any insight? > > > Andreas > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/b41eb847/attachment-0001.html From sthorger at redhat.com Tue May 31 01:15:08 2016 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 31 May 2016 07:15:08 +0200 Subject: [keycloak-user] Fwd: Re: Redirection issue with proxy behind keycloak In-Reply-To: <5e1b50b9-b7d0-5b2e-b16c-4df98da6f485@tesicnor.com> References: <03225e22-5a31-d3c5-4285-69e355e1950e@tesicnor.com> <5e1b50b9-b7d0-5b2e-b16c-4df98da6f485@tesicnor.com> Message-ID: Where is your app deployed? If it's on WildFly you can follow the same steps used to configure reverse proxy for Keycloak Server to configure WildFly. Check if getRequestURL returns the correct URL in your app. On 30 May 2016 at 15:08, Aritz Maeztu wrote: > > > > -------- Birbidalitako mezua -------- > Gaia: Re: [keycloak-user] Redirection issue with proxy behind keycloak > Data: Mon, 30 May 2016 13:28:21 +0200 > Nork: Aritz Maeztu > Nori: stian at redhat.com > CC: Niels Bertram , > keycloak-user > , Scott Rossillo > > > > I've done all the traceability from the proxy server till the login page > is displayed: > > First step, /organization/organizations is requested, so the proxy server > knows it has to be forwarded to the 8083 port (the one for the organization > service). That's the first request received by my application's Tomcat: > > 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 START > TIME =30-may-2016 13:01:18 > 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > requestURI=/organizations > 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > authType=null > 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > characterEncoding=UTF-8 > 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > contentLength=-1 > 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > contentType=null > 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > contextPath= > 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=accept-language=es-ES,es;q=0.8 > 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=x-forwarded-host=mies-057:8765 > 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=x-forwarded-prefix=/organization > 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=upgrade-insecure-requests=1 > 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=accept-encoding=gzip > 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=accept=text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 > 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=user-agent=Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 > (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 > 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=netflix.nfhttpclient.version=1.0 > 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=x-netflix-httpclientname=organization > 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=host=mies-057:8083 > 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=connection=Keep-Alive > 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > locale=es_ES > 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > method=GET > 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > pathInfo=null > 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > protocol=HTTP/1.1 > 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > queryString=null > 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > remoteAddr=192.168.56.1 > 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > remoteHost=192.168.56.1 > 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > remoteUser=null > 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > requestedSessionId=null > 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > scheme=http > 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > serverName=mies-057 > 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > serverPort=8083 > 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > servletPath=/organizations > 2016-05-30 13:01:18.891 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > isSecure=false > 2016-05-30 13:01:18.891 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > ------------------=-------------------------------------------- > > Here x-forwarded-host is mies-057:8765 (the proxy server) and > x-forwarded-prefix is /organization. So the original request is kept in the > headers. Well, now my service (8083) tries to check for authorization via > the /sso/login endpoint from the keycloak spring security adapter: > > 2016-05-30 13:01:18.892 DEBUG 18096 --- [nio-8083-exec-9] > o.k.a.s.management.HttpSessionManager : Session created: > CDCA7AD4439DE94BD0B3B5803DAA0752 > 2016-05-30 13:01:18.892 DEBUG 18096 --- [nio-8083-exec-9] > k.a.s.a.KeycloakAuthenticationEntryPoint : Redirecting to login URI > /sso/login > 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > ------------------=-------------------------------------------- > 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > authType=null > 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > contentType=null > 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=X-Content-Type-Options=nosniff > 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=X-XSS-Protection=1; mode=block > 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=Cache-Control=no-cache, no-store, max-age=0, must-revalidate > 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=Pragma=no-cache > 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=Expires=0 > 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=X-Frame-Options=DENY > 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=Set-Cookie=JSESSIONID=CDCA7AD4439DE94BD0B3B5803DAA0752; Path=/; > HttpOnly > 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=Location= > http://mies-057:8083/sso/login > 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > remoteUser=null > 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > status=302 > 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 END > TIME =30-may-2016 13:01:18 > 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > =============================================================== > 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 START > TIME =30-may-2016 13:01:18 > 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > requestURI=/sso/login > 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > authType=null > 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > characterEncoding=UTF-8 > 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > contentLength=-1 > 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > contentType=null > 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > contextPath= > 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-10 > cookie=JSESSIONID=CDCA7AD4439DE94BD0B3B5803DAA0752 > 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-10 header=host=mies-057:8083 > 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-10 header=connection=keep-alive > 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-10 > header=accept=text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 > 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-10 header=upgrade-insecure-requests=1 > 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-10 header=user-agent=Mozilla/5.0 (Windows NT > 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 > Safari/537.36 > 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-10 header=accept-encoding=gzip, deflate, sdch > 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-10 header=accept-language=es-ES,es;q=0.8 > 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-10 > header=cookie=JSESSIONID=CDCA7AD4439DE94BD0B3B5803DAA0752 > 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-10 locale=es_ES > 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-10 method=GET > 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > pathInfo=null > 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > protocol=HTTP/1.1 > 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > queryString=null > 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > remoteAddr=192.168.56.1 > 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > remoteHost=192.168.56.1 > 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > remoteUser=null > 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > requestedSessionId=CDCA7AD4439DE94BD0B3B5803DAA0752 > 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-10 scheme=http > 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > serverName=mies-057 > 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > serverPort=8083 > 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > servletPath=/sso/login > 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > isSecure=false > 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > ------------------=-------------------------------------------- > 2016-05-30 13:01:18.904 DEBUG 18096 --- [io-8083-exec-10] > o.k.adapters.PreAuthActionsHandler : adminRequest > http://mies-057:8083/sso/login > 2016-05-30 13:01:18.904 DEBUG 18096 --- [io-8083-exec-10] > f.KeycloakAuthenticationProcessingFilter : Request is to process > authentication > 2016-05-30 13:01:18.904 DEBUG 18096 --- [io-8083-exec-10] > f.KeycloakAuthenticationProcessingFilter : Attempting Keycloak > authentication > 2016-05-30 13:01:18.904 TRACE 18096 --- [io-8083-exec-10] > o.k.adapters.RequestAuthenticator : --> authenticate() > 2016-05-30 13:01:18.904 TRACE 18096 --- [io-8083-exec-10] > o.k.adapters.RequestAuthenticator : try bearer > 2016-05-30 13:01:18.904 TRACE 18096 --- [io-8083-exec-10] > o.k.adapters.RequestAuthenticator : try oauth > 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] > o.k.a.s.token.SpringSecurityTokenStore : Checking if > org.keycloak.adapters.springsecurity.authentication.SpringSecurityRequestAuthenticator at d328c2d > is cached > 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] > o.k.adapters.OAuthRequestAuthenticator : there was no code > 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] > o.k.adapters.OAuthRequestAuthenticator : redirecting to auth server > 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] > o.k.adapters.OAuthRequestAuthenticator : callback uri: > http://mies-057:8083/sso/login > 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] > f.KeycloakAuthenticationProcessingFilter : Auth outcome: NOT_ATTEMPTED > 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] > o.k.adapters.OAuthRequestAuthenticator : Sending redirect to login page: > http://mies-057.tesicnor.com:8080/auth/realms/master/protocol/openid-connect/auth?response_type=code&client_id=organization&redirect_uri=http%3A%2F%2Fmies-057%3A8083%2Fsso%2Flogin&state=1%2F21d709ec-1e69-41c5-ac6d-c705f8ce3907&login=true > > As it's shown in the logs, the X-forwarded logs are not kept by the > keycloak adapter (look at the lines below k.a.s.a.KeycloakAuthenticationEntryPoint > : Redirecting to login URI /sso/login). So could it be the proxy server > itself being properly configured but the keycloak adapter losing the > original headers while performing the redirection? > > I've also set up the request dumper in the undertow server as Niels > suggested, but obviously, X-forwarded headers are not reaching the keycloak > server.. > > Thanks for your time, again ;-) > > > > 25/05/2016 7:22(e)an, Stian Thorgersen igorleak idatzi zuen: > > You need the Host and X-Forwarded-For headers to be included and there's > also some config to be done on the Keycloak server (see > http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#proxy-address-forwarding > ) > > On 24 May 2016 at 08:46, Aritz Maeztu wrote: > >> Hi Niels and Scott. First of all, thank you very much for your help. I'm >> currently using Zuul (Spring Cloud) as the reverse proxy. All the services >> are registered in a discovery service called Eureka and then Zuul looks for >> the service id there and performs de redirection. I read about X-Forwarded >> headers, but I thought it might result in a security issue if not included, >> not that it could affect the redirection process. >> >> As Scott says, I suppose the Host and the X-Real-Ip headers are the >> relevant ones here, so I guess I should instruct Zuul to send them when the >> service is addressed (however I wonder why they are not already being sent, >> as Zuul is a proxy service, all in all). >> Here I include a preview of the first redirection made to the keycloak >> login page, which shows the request headers sent to the service /login >> endpoint (at port 8081 in localhost): >> >> https://www.dropbox.com/s/iof9yefytzay6j2/screenshot.PNG?dl=0 >> >> 24/05/2016 2:08(e)an, Niels Bertram igorleak idatzi zuen: >> >> Hi Artitz, >> >> a great way to figure out what is sent from the reverse proxy to your >> keycloak server is to use the undertow request dumper. >> >> From the jboss-cli just add the request dumper filter to your undertow >> configuration like this: >> >> $KC_HOME/bin/jbpss-cli.sh -c >> >> /subsystem=undertow/configuration=filter/custom-filter=request-dumper:add(class-name=io.undertow.server.handlers.RequestDumpingHandler, >> module=io.undertow.core) >> >> >> /subsystem=undertow/server=default-server/host=default-host/filter-ref=request-dumper:add >> >> /:reload >> >> given your apache config looks something like this: >> >> ProxyRequests Off >> ProxyPreserveHost On >> ProxyVia On >> >> ProxyPass /auth ajp://127.0.0.1:8009/auth >> ProxyPassReverse /auth ajp://127.0.0.1:8009/auth >> >> >> you should see something like that (forwared info is somewhat rubbish in >> this example as I am running the hosts on Virtualbox - but you can see this >> request was put through 2 proxies from local pc 192.168.33.1 to haproxy on >> 192.168.33.80 and then apache reverse proxy on 192.168.33.81 ): >> >> ============================================================== >> 23:47:20,563 INFO [io.undertow.request.dump] (default task-14) >> ----------------------------REQUEST--------------------------- >> URI=/auth/welcome-content/favicon.ico >> characterEncoding=null >> contentLength=-1 >> contentType=null >> header=Accept=*/* >> header=Accept-Language=en-US,en;q=0.8,de;q=0.6 >> header=Cache-Control=no-cache >> header=Accept-Encoding=gzip, deflate, sdch >> header=DNT=1 >> header=Pragma=no-cache >> header=X-Original-To=192.168.33.80 >> header=User-Agent=Mozilla/5.0 (Windows NT 6.1; WOW64) >> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 >> header=Authorization=Basic >> bmljZSB0cnkgYnV0IGFtIG5vdCBmcm9tIHllc3RlcmRheQo= >> header=X-Forwarded-Proto=https >> header=X-Forwarded-Port=443 >> header=X-Forwarded-For=192.168.33.1 >> header=Referer= >> https://login.vagrant.dev/auth/ >> header=Host=login.vagrant.dev >> locale=[en_US, en, de] >> method=GET >> protocol=HTTP/1.1 >> queryString= >> remoteAddr=192.168.33.1:0 >> remoteHost=192.168.33.1 >> scheme=https >> host=login.vagrant.dev >> serverPort=443 >> --------------------------RESPONSE-------------------------- >> contentLength=627 >> contentType=application/octet-stream >> header=Cache-Control=max-age=2592000 >> header=X-Powered-By=Undertow/1 >> header=Server=WildFly/10 >> >> >> Hope this helps diagnosing your issue. Niels >> >> On Tue, May 24, 2016 at 1:20 AM, Aritz Maeztu < >> amaeztu at tesicnor.com> wrote: >> >>> I'm using keycloak to securize some Spring based services (with the >>> keycloak spring security adapter). The adapter creates a `/login` endpoint >>> in each of the services which redirects to the keycloak login page and then >>> redirects back to the service when authentication is done. I also have a >>> proxy service which I want to publish in the 80 port and will take care of >>> routing all the requests to each service. The proxy performs a plain >>> FORWARD to the service, but the problem comes when I securize the service >>> with the keycloak adapter. >>> >>> When I make a request, the adapter redirects to its login endpoint and >>> then to the keycloak auth url. When keycloak sends the redirection, the url >>> shown in the browser is the one from the service and not the one from the >>> proxy. Do I have some choice to tell the adapter I want to redirect back to >>> the first requested url? >>> >>> -- >>> Aritz Maeztu Ota?o >>> Departamento Desarrollo de Software >>> >>> >>> >>> Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra) >>> Telf.: 948 21 40 40 >>> Fax.: 948 21 40 41 >>> Antes de imprimir este e-mail piense bien si es necesario hacerlo: El >>> medioambiente es cosa de todos. >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> >> >> -- >> Aritz Maeztu Ota?o >> Departamento Desarrollo de Software >> >> >> >> Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra) >> Telf.: 948 21 40 40 >> Fax.: 948 21 40 41 >> Antes de imprimir este e-mail piense bien si es necesario hacerlo: El >> medioambiente es cosa de todos. >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > > -- > Aritz Maeztu Ota?o > Departamento Desarrollo de Software > > > > Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra) > Telf.: 948 21 40 40 > Fax.: 948 21 40 41 > Antes de imprimir este e-mail piense bien si es necesario hacerlo: El > medioambiente es cosa de todos. > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/cfbaf2cb/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 2983 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/cfbaf2cb/attachment-0003.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 2983 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/cfbaf2cb/attachment-0004.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1295 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/cfbaf2cb/attachment-0003.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 2983 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/cfbaf2cb/attachment-0005.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1295 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/cfbaf2cb/attachment-0004.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1295 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/cfbaf2cb/attachment-0005.gif From mposolda at redhat.com Tue May 31 02:59:44 2016 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 31 May 2016 08:59:44 +0200 Subject: [keycloak-user] Token generation: possibilities to improve performance In-Reply-To: References: <61D077C6283D454FAFD06F6AC4AB74D723DDFF8E@DEFTHW99EZ1MSX.ww931.my-it-solutions.net> <31bfde5a-c56f-473a-de6f-95d15e32bbd9@redhat.com> <57488196.60104@redhat.com> <574C0448.6090108@redhat.com> <574C0FE8.5090003@redhat.com> Message-ID: <574D3660.6060807@redhat.com> On 30/05/16 21:04, Stian Thorgersen wrote: > > > On 30 May 2016 at 12:03, Marek Posolda > wrote: > > On 30/05/16 11:51, Stian Thorgersen wrote: >> >> >> On 30 May 2016 at 11:13, Marek Posolda > > wrote: >> >> On 30/05/16 08:02, Stian Thorgersen wrote: >>> Create a JIRA for ECDSA. I don't think we could/should >>> change the default, but could be a configuration option for >>> clients. >> Added https://issues.jboss.org/browse/KEYCLOAK-3057 with fix >> version 2.0.0.CR1 for now. >>> >>> Looking at OpenID Connect spec it looks like ID token should >>> always be generated in token response [1]. However, it >>> should not be generated in refresh [2] response. >>> >>> [1] >>> http://openid.net/specs/openid-connect-core-1_0.html#rfc.section.3.1.3.3 >>> [2] >>> http://openid.net/specs/openid-connect-core-1_0.html#rfc.section.12.2 >> hmm... I am reading 12.2 that refresh response "might not" >> contain ID Token, hence it's nothing bad if it contains it. >> So looks we are currently specs compliant if we have IDToken >> in both code-to-token response and refresh response. >> >> What I mean is, that flag for skip IDToken generation might >> be just optional and disabled by default. So by default, >> IDToken is available and all the communication is OIDC >> compliant. However if someone doesn't need IDToken and wants >> to save some performance, he may skip the IDToken generation. >> >> A week before, I've tried some JProfiler testing of >> login-logout test and token generation was the main CPU >> consumption (I still had just 1 hashIteration during this >> profiling, with 20000 it will be likely very different >> though). I saw 40% of CPU time in >> TokenManager$AccessTokenResponseBuilder.build()due there are >> 3 tokens signature here. The option to reduce it from 3 to 2 >> might slightly improve some CPU cycles "for free" (security >> won't be reduced). >> >> >> I'd argue that we should just include ID token from the >> authorization response, while never in the refresh response. That >> results in better performance without the need for a config option. > Won't that break compatibility for some client applications, which > actually use IDToken and rely on the fact that it's properly > refreshed every time? Among other things, IDToken contains fields > like "exp" , which might then contain expired value as it won't > be updated during refreshes. Not sure if users won't be confused > due to this. > > > Surely the exp for an IDToken should be set to the session expiration > and not to the expiration of access token though? Do we even update > the profile details in the token or just fill it with whatever was > there before? That's not what we are doing now. Right now, all IDToken claims (including expiration) are copied from accessToken. So IDToken expiration is by default defacto just 5 minutes or so. And all the claims are always updated during refresh. So if we don't refresh IDToken we lost this and IDToken will always contain claims from the time of login. Not sure if it's too bad or not, however some client apps, which use IDToken (like our demo for example) might be confused that IDToken will still contain old values after refresh... Marek > > Marek > >> >> >> Marek >> >> >>> On 27 May 2016 at 19:19, Marek Posolda >> > wrote: >>> >>> Regarding this, I wonder if we should add support for >>> ECDSA based signatures as an alternative to RSA? Just >>> went through some interesting blog [1] , which mentions >>> that 256-bits ECDSA has around 9.5 times better >>> performance of signature generation than 2048-bits RSA. >>> The time of signature verification seems to be slightly >>> worse for ECDSA (see second comment), however there is >>> also increased security (256-ECDSA is equivalient of >>> 3248 RSA according to blog). Maybe it's something we can >>> look at? >>> >>> Also the optional flag to skip IDToken generation will >>> be good too IMO. AFAIK the point of IDToken is the >>> compliance with OIDC specification. However in case of >>> Keycloak accessToken usually contains all the info like >>> IDToken (+ some more) and it's the accessToken, which is >>> used in REST endpoints. So with regards to that, most of >>> the Keycloak-secured applications can live just with >>> access+refresh token and don't need ID Token at all. So >>> if just 2 tokens needs to be signed instead of 3, we >>> have performance gain "for free" (no decrease of >>> security, just one less useless token). >>> >>> [1] >>> https://blog.cloudflare.com/ecdsa-the-digital-signature-algorithm-of-a-better-internet/ >>> >>> Marek >>> >>> >>> On 24/05/16 15:43, Bill Burke wrote: >>>> Are you sure the performance gains are worth less >>>> security? What kind of performance are you actually >>>> worried about? Network (size of tokens) or CPU >>>> (signatures/marshaling/unmarshalling)? If anything, >>>> these signatures are only going to get stronger in >>>> future releases. >>>> >>>> On 5/24/16 5:46 AM, Matuszak, Eduard wrote: >>>>> Hello >>>>> Motivated by considerations on how to improve the >>>>> performance of the token generation process I have two >>>>> questions: >>>>> >>>>> * I noticed that Keycloak?s token generation via >>>>> endpoint >>>>> ?auth/realms/ccp/protocol/openid-connect/token? >>>>> generates a triple of tokens (access-, refresh- >>>>> and id-token). Is there any possibility to >>>>> dispense with the id-token generation? >>>>> >>>>> * Is there a possibility to cause Keycloak to >>>>> generate more ?simple? bearer tokens then complex >>>>> jwt-tokens? >>>>> >>>>> Best regards, Eduard Matuszak >>>>> >>>>> >>>>> _______________________________________________ >>>>> keycloak-user mailing list >>>>> keycloak-user at lists.jboss.org >>>>> >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>> >>>> >>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user at lists.jboss.org >>>> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/8c2a511b/attachment-0001.html From amaeztu at tesicnor.com Tue May 31 03:13:12 2016 From: amaeztu at tesicnor.com (Aritz Maeztu) Date: Tue, 31 May 2016 09:13:12 +0200 Subject: [keycloak-user] Fwd: Re: Redirection issue with proxy behind keycloak In-Reply-To: References: <03225e22-5a31-d3c5-4285-69e355e1950e@tesicnor.com> <5e1b50b9-b7d0-5b2e-b16c-4df98da6f485@tesicnor.com> Message-ID: <7a45ae5d-cf0f-a5d5-0ab5-1df8ee8aa9da@tesicnor.com> I've got some Spring Boot application instances with embeded Tomcat servlet containers. Tomcat has a similar system to Wildfly for request dumpering, that's what I have enabled for getting the trace below. In short words that's the behaviour I'm able to see: 1. Zuul Proxy (Spring Boot in Tomcat) -> Organization Service (8083 port) : A forward request where X-forwarded headers are included 2. Organization Service (localhost:8083) : Looks for a token and if it's not available, the keycloak adapter redirects to the /sso/login of the same service (Here the traceability from the proxy gets losts) 3. localhost:8083/sso/login: Redirects to the keycloak wildfly server, saving the requested url 4. Keycloak login: The user performs the authentication and the redirectUri is localhost:8083/sso/login. Later on, the login endpoint redirects the user to the url requested in point 2, not the first one from the proxy. I only have this problem when my organization service needs to verify the token (or a token doesn't exist) using the keycloak adapter. When the /sso/login endpoint is not requested, everything is working properly. Hope I've explained it well! 31/05/2016 7:15(e)an, Stian Thorgersen igorleak idatzi zuen: > Where is your app deployed? If it's on WildFly you can follow the same > steps used to configure reverse proxy for Keycloak Server to configure > WildFly. Check if getRequestURL returns the correct URL in your app. > > On 30 May 2016 at 15:08, Aritz Maeztu > wrote: > > > > > -------- Birbidalitako mezua -------- > Gaia: Re: [keycloak-user] Redirection issue with proxy behind > keycloak > Data: Mon, 30 May 2016 13:28:21 +0200 > Nork: Aritz Maeztu > > Nori: stian at redhat.com > CC: Niels Bertram > , keycloak-user > > , Scott Rossillo > > > > > I've done all the traceability from the proxy server till the > login page is displayed: > > First step, /organization/organizations is requested, so the proxy > server knows it has to be forwarded to the 8083 port (the one for > the organization service). That's the first request received by my > application's Tomcat: > > 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > START TIME =30-may-2016 13:01:18 > 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > requestURI=/organizations > 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-9 authType=null > 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > characterEncoding=UTF-8 > 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-9 contentLength=-1 > 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-9 contentType=null > 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-9 contextPath= > 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=accept-language=es-ES,es;q=0.8 > 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=x-forwarded-host=mies-057:8765 > 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=x-forwarded-prefix=/organization > 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=upgrade-insecure-requests=1 > 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=accept-encoding=gzip > 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=accept=text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 > 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=user-agent=Mozilla/5.0 (Windows NT 6.1; WOW64) > AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 > Safari/537.36 > 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=netflix.nfhttpclient.version=1.0 > 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=x-netflix-httpclientname=organization > 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=host=mies-057:8083 > 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=connection=Keep-Alive > 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-9 locale=es_ES > 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-9 method=GET > 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-9 pathInfo=null > 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-9 protocol=HTTP/1.1 > 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-9 queryString=null > 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > remoteAddr=192.168.56.1 > 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > remoteHost=192.168.56.1 > 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-9 remoteUser=null > 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > requestedSessionId=null > 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-9 scheme=http > 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-9 serverName=mies-057 > 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-9 serverPort=8083 > 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > servletPath=/organizations > 2016-05-30 13:01:18.891 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-9 isSecure=false > 2016-05-30 13:01:18.891 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > ------------------=-------------------------------------------- > > Here x-forwarded-host is mies-057:8765 (the proxy server) and > x-forwarded-prefix is /organization. So the original request is > kept in the headers. Well, now my service (8083) tries to check > for authorization via the /sso/login endpoint from the keycloak > spring security adapter: > > 2016-05-30 13:01:18.892 DEBUG 18096 --- [nio-8083-exec-9] > o.k.a.s.management.HttpSessionManager : Session created: > CDCA7AD4439DE94BD0B3B5803DAA0752 > 2016-05-30 13:01:18.892 DEBUG 18096 --- [nio-8083-exec-9] > k.a.s.a.KeycloakAuthenticationEntryPoint : Redirecting to login > URI /sso/login > 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > ------------------=-------------------------------------------- > 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-9 authType=null > 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-9 contentType=null > 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=X-Content-Type-Options=nosniff > 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=X-XSS-Protection=1; mode=block > 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=Cache-Control=no-cache, no-store, max-age=0, must-revalidate > 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=Pragma=no-cache > 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=Expires=0 > 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=X-Frame-Options=DENY > 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=Set-Cookie=JSESSIONID=CDCA7AD4439DE94BD0B3B5803DAA0752; > Path=/; HttpOnly > 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > header=Location=http://mies-057:8083/sso/login > 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-9 remoteUser=null > 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-9 status=302 > 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > END TIME =30-may-2016 13:01:18 > 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 > =============================================================== > 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > START TIME =30-may-2016 13:01:18 > 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > requestURI=/sso/login > 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-10 authType=null > 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > characterEncoding=UTF-8 > 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-10 contentLength=-1 > 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-10 contentType=null > 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-10 contextPath= > 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > cookie=JSESSIONID=CDCA7AD4439DE94BD0B3B5803DAA0752 > 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > header=host=mies-057:8083 > 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > header=connection=keep-alive > 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > header=accept=text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 > 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > header=upgrade-insecure-requests=1 > 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > header=user-agent=Mozilla/5.0 (Windows NT 6.1; WOW64) > AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 > Safari/537.36 > 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > header=accept-encoding=gzip, deflate, sdch > 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > header=accept-language=es-ES,es;q=0.8 > 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > header=cookie=JSESSIONID=CDCA7AD4439DE94BD0B3B5803DAA0752 > 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-10 locale=es_ES > 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-10 method=GET > 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-10 pathInfo=null > 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > protocol=HTTP/1.1 > 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-10 queryString=null > 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > remoteAddr=192.168.56.1 > 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > remoteHost=192.168.56.1 > 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-10 remoteUser=null > 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > requestedSessionId=CDCA7AD4439DE94BD0B3B5803DAA0752 > 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-10 scheme=http > 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > serverName=mies-057 > 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-10 serverPort=8083 > 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > servletPath=/sso/login > 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : > http-nio-8083-exec-10 isSecure=false > 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] > o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 > ------------------=-------------------------------------------- > 2016-05-30 13:01:18.904 DEBUG 18096 --- [io-8083-exec-10] > o.k.adapters.PreAuthActionsHandler : adminRequest > http://mies-057:8083/sso/login > 2016-05-30 13:01:18.904 DEBUG 18096 --- [io-8083-exec-10] > f.KeycloakAuthenticationProcessingFilter : Request is to process > authentication > 2016-05-30 13:01:18.904 DEBUG 18096 --- [io-8083-exec-10] > f.KeycloakAuthenticationProcessingFilter : Attempting Keycloak > authentication > 2016-05-30 13:01:18.904 TRACE 18096 --- [io-8083-exec-10] > o.k.adapters.RequestAuthenticator : --> authenticate() > 2016-05-30 13:01:18.904 TRACE 18096 --- [io-8083-exec-10] > o.k.adapters.RequestAuthenticator : try bearer > 2016-05-30 13:01:18.904 TRACE 18096 --- [io-8083-exec-10] > o.k.adapters.RequestAuthenticator : try oauth > 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] > o.k.a.s.token.SpringSecurityTokenStore : Checking if > org.keycloak.adapters.springsecurity.authentication.SpringSecurityRequestAuthenticator at d328c2d > is cached > 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] > o.k.adapters.OAuthRequestAuthenticator : there was no code > 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] > o.k.adapters.OAuthRequestAuthenticator : redirecting to auth server > 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] > o.k.adapters.OAuthRequestAuthenticator : callback uri: > http://mies-057:8083/sso/login > 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] > f.KeycloakAuthenticationProcessingFilter : Auth outcome: NOT_ATTEMPTED > 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] > o.k.adapters.OAuthRequestAuthenticator : Sending redirect to > login page: > http://mies-057.tesicnor.com:8080/auth/realms/master/protocol/openid-connect/auth?response_type=code&client_id=organization&redirect_uri=http%3A%2F%2Fmies-057%3A8083%2Fsso%2Flogin&state=1%2F21d709ec-1e69-41c5-ac6d-c705f8ce3907&login=true > > As it's shown in the logs, the X-forwarded logs are not kept by > the keycloak adapter (look at the lines below > k.a.s.a.KeycloakAuthenticationEntryPoint : Redirecting to login > URI /sso/login). So could it be the proxy server itself being > properly configured but the keycloak adapter losing the original > headers while performing the redirection? > > I've also set up the request dumper in the undertow server as > Niels suggested, but obviously, X-forwarded headers are not > reaching the keycloak server.. > > Thanks for your time, again ;-) > > > > 25/05/2016 7:22(e)an, Stian Thorgersen igorleak idatzi zuen: >> You need the Host and X-Forwarded-For headers to be included and >> there's also some config to be done on the Keycloak server (see >> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#proxy-address-forwarding) >> >> On 24 May 2016 at 08:46, Aritz Maeztu > > wrote: >> >> Hi Niels and Scott. First of all, thank you very much for >> your help. I'm currently using Zuul (Spring Cloud) as the >> reverse proxy. All the services are registered in a discovery >> service called Eureka and then Zuul looks for the service id >> there and performs de redirection. I read about X-Forwarded >> headers, but I thought it might result in a security issue if >> not included, not that it could affect the redirection process. >> >> As Scott says, I suppose the Host and the X-Real-Ip headers >> are the relevant ones here, so I guess I should instruct Zuul >> to send them when the service is addressed (however I wonder >> why they are not already being sent, as Zuul is a proxy >> service, all in all). >> >> Here I include a preview of the first redirection made to the >> keycloak login page, which shows the request headers sent to >> the service /login endpoint (at port 8081 in localhost): >> >> https://www.dropbox.com/s/iof9yefytzay6j2/screenshot.PNG?dl=0 >> >> 24/05/2016 2:08(e)an, Niels Bertram igorleak idatzi zuen: >>> Hi Artitz, >>> >>> a great way to figure out what is sent from the reverse >>> proxy to your keycloak server is to use the undertow request >>> dumper. >>> >>> From the jboss-cli just add the request dumper filter to >>> your undertow configuration like this: >>> >>> $KC_HOME/bin/jbpss-cli.sh -c >>> >>> /subsystem=undertow/configuration=filter/custom-filter=request-dumper:add(class-name=io.undertow.server.handlers.RequestDumpingHandler, >>> module=io.undertow.core) >>> >>> /subsystem=undertow/server=default-server/host=default-host/filter-ref=request-dumper:add >>> >>> /:reload >>> >>> given your apache config looks something like this: >>> >>> ProxyRequests Off >>> ProxyPreserveHost On >>> ProxyVia On >>> >>> ProxyPass /auth ajp://127.0.0.1:8009/auth >>> >>> ProxyPassReverse /auth ajp://127.0.0.1:8009/auth >>> >>> >>> >>> you should see something like that (forwared info is >>> somewhat rubbish in this example as I am running the hosts >>> on Virtualbox - but you can see this request was put through >>> 2 proxies from local pc 192.168.33.1 to haproxy on >>> 192.168.33.80 and then apache reverse proxy on 192.168.33.81 ): >>> >>> ============================================================== >>> 23:47:20,563 INFO [io.undertow.request.dump] (default task-14) >>> ----------------------------REQUEST--------------------------- >>> URI=/auth/welcome-content/favicon.ico >>> characterEncoding=null >>> contentLength=-1 >>> contentType=null >>> header=Accept=*/* >>> header=Accept-Language=en-US,en;q=0.8,de;q=0.6 >>> header=Cache-Control=no-cache >>> header=Accept-Encoding=gzip, deflate, sdch >>> header=DNT=1 >>> header=Pragma=no-cache >>> header=X-Original-To=192.168.33.80 >>> header=User-Agent=Mozilla/5.0 (Windows NT 6.1; WOW64) >>> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 >>> Safari/537.36 >>> header=Authorization=Basic >>> bmljZSB0cnkgYnV0IGFtIG5vdCBmcm9tIHllc3RlcmRheQo= >>> header=X-Forwarded-Proto=https >>> header=X-Forwarded-Port=443 >>> header=X-Forwarded-For=192.168.33.1 >>> header=Referer=https://login.vagrant.dev/auth/ >>> header=Host=login.vagrant.dev >>> locale=[en_US, en, de] >>> method=GET >>> protocol=HTTP/1.1 >>> queryString= >>> remoteAddr=192.168.33.1:0 >>> remoteHost=192.168.33.1 >>> scheme=https >>> host=login.vagrant.dev >>> serverPort=443 >>> --------------------------RESPONSE-------------------------- >>> contentLength=627 >>> contentType=application/octet-stream >>> header=Cache-Control=max-age=2592000 >>> header=X-Powered-By=Undertow/1 >>> header=Server=WildFly/10 >>> >>> >>> Hope this helps diagnosing your issue. Niels >>> >>> On Tue, May 24, 2016 at 1:20 AM, Aritz Maeztu >>> > wrote: >>> >>> I'm using keycloak to securize some Spring based >>> services (with the keycloak spring security adapter). >>> The adapter creates a `/login` endpoint in each of the >>> services which redirects to the keycloak login page and >>> then redirects back to the service when authentication >>> is done. I also have a proxy service which I want to >>> publish in the 80 port and will take care of routing all >>> the requests to each service. The proxy performs a plain >>> FORWARD to the service, but the problem comes when I >>> securize the service with the keycloak adapter. >>> >>> When I make a request, the adapter redirects to its >>> login endpoint and then to the keycloak auth url. When >>> keycloak sends the redirection, the url shown in the >>> browser is the one from the service and not the one from >>> the proxy. Do I have some choice to tell the adapter I >>> want to redirect back to the first requested url? >>> >>> >>> -- >>> Aritz Maeztu Ota?o >>> Departamento Desarrollo de Software >>> >>> >>> >>> >>> Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain >>> (Navarra) >>> Telf.: 948 21 40 40 >>> Fax.: 948 21 40 41 >>> >>> Antes de imprimir este e-mail piense bien si es >>> necesario hacerlo: El medioambiente es cosa de todos. >>> >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >>> >> >> -- >> Aritz Maeztu Ota?o >> Departamento Desarrollo de Software >> >> >> >> Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra) >> Telf.: 948 21 40 40 >> Fax.: 948 21 40 41 >> >> Antes de imprimir este e-mail piense bien si es necesario >> hacerlo: El medioambiente es cosa de todos. >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> > > -- > Aritz Maeztu Ota?o > Departamento Desarrollo de Software > > > > Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra) > Telf.: 948 21 40 40 > Fax.: 948 21 40 41 > > Antes de imprimir este e-mail piense bien si es necesario hacerlo: > El medioambiente es cosa de todos. > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > -- Aritz Maeztu Ota?o Departamento Desarrollo de Software Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra) Telf.: 948 21 40 40 Fax.: 948 21 40 41 Antes de imprimir este e-mail piense bien si es necesario hacerlo: El medioambiente es cosa de todos. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/2cadf2a5/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1295 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/2cadf2a5/attachment-0004.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 2983 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/2cadf2a5/attachment-0004.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1295 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/2cadf2a5/attachment-0005.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 2983 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/2cadf2a5/attachment-0005.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 1295 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/2cadf2a5/attachment-0006.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 2983 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/2cadf2a5/attachment-0006.png -------------- next part -------------- A non-text attachment was scrubbed... Name: linkdin.gif Type: image/gif Size: 1295 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/2cadf2a5/attachment-0007.gif -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 2983 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/2cadf2a5/attachment-0007.png From bystrik.horvath at gmail.com Tue May 31 04:50:12 2016 From: bystrik.horvath at gmail.com (Bystrik Horvath) Date: Tue, 31 May 2016 10:50:12 +0200 Subject: [keycloak-user] Async request/response processing at Keycloak Message-ID: Hello community, I found that (since 1.9.2?) there's RealmResourceProvider that gives me the possibility to provide own REST endpoint. After implementing the endpoint using async capabilty of jax-rs, I'm getting exception like: UT010026: Async is not supported for this request, as not all filters or Servlets were marked as supporting async. How is it possible to tweak Keycloak (I'm currently on 1.9.3) to asynchronously respond to my requests in implementation of RealmResourceProvider? Thank you for any comment on this. Best regards, Bystrik -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/cc810feb/attachment.html From dev at sgordon.totalise.co.uk Tue May 31 05:32:29 2016 From: dev at sgordon.totalise.co.uk (Simon Gordon) Date: 31 May 2016 10:32:29 +0100 Subject: [keycloak-user] keycloak catridge and extra modules Message-ID: Hey all Another simple one from me I think! I'm looking to add a userFederation provider, plus a new theme. I am using the keycloak cartridge, which is very convenient - but maybe I should resort to a .war to add modules? Or is there a way to add modules to the keycloak cartridge? Thanks, Simon From thomas.raehalme at aitiofinland.com Tue May 31 06:01:42 2016 From: thomas.raehalme at aitiofinland.com (Thomas Raehalme) Date: Tue, 31 May 2016 13:01:42 +0300 Subject: [keycloak-user] Swedish translation Message-ID: Hi! We need to translate Keycloak user interface (excluding admin console) to the Swedish language. I was wondering if anyone has already done the translation and would be willing to share it? We have already translated Keycloak to Finnish and hope to share the translation with the community in the near future. Best regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/3ee46b64/attachment.html From okie.othsam at gmail.com Tue May 31 06:30:50 2016 From: okie.othsam at gmail.com (Okie Oth) Date: Tue, 31 May 2016 12:30:50 +0200 Subject: [keycloak-user] keycloak-admin-client and realm initialization Message-ID: <574D67DA.6010502@gmail.com> Hello, I'm a keycloak newbie and try to write a tool that initialize my keycloak installation. Some parts work fine but I can't do deeper initializations. For instance I can create a new user group but if I want to assign some realm roles for the new created group nothing happens. I checked the results with the normal Keycloak webfrontend. Here is my sample code: ... GroupRepresentation gr = new GroupRepresentation(); gr.setName("myGroup"); List realmRoleList=new ArrayList(); realmRoleList.add("test"); gr.setRealmRoles(realmRoleList); realmResource.groups().add(gr); ... // now the group 'myGroup' exists but no roles are assigned. Any advice or help is welcome Kind regards Eiko From okie.othsam at gmail.com Tue May 31 07:33:14 2016 From: okie.othsam at gmail.com (Okie Oth) Date: Tue, 31 May 2016 13:33:14 +0200 Subject: [keycloak-user] keycloak-admin-client and realm initialization In-Reply-To: <574D6F70.7060403@redhat.com> References: <574D67DA.6010502@gmail.com> <574D6F70.7060403@redhat.com> Message-ID: <574D767A.9010905@gmail.com> Thank you for the response :) I had the same idea and so I grab the existing realm roles from the server before I create the new group. A realm role with the desired name exists and I try to add it with ID and name in setRealmRoles. I also try to add a group at first, grab the group list from server and update the group with new (but existing) realm roles. With wireshark I sniff the content that goes to the rest service and it contains my data. The response was HTTP-State 202 (no data). I test my code against final version 1.9.4 and 1.9.5. The keycloak server runs in standalone mode in a Ubuntu 14.04 VM and uses Postgresql as backend. Beside the groups I got a similar effect if I create a new user. I can create the user, but he has no assigned group. Cheers Am 31.05.2016 um 13:03 schrieb Stan Silvert: > I suspect your problem is that the roles don't exist yet. You need to > create the role as a realm role before you assign it to a group. > > realmResource.roles().create(myRole); > > On 5/31/2016 6:30 AM, Okie Oth wrote: >> Hello, >> I'm a keycloak newbie and try to write a tool that initialize my >> keycloak installation. Some parts work fine but I can't do deeper >> initializations. For instance I can create a new user group but if I >> want to assign some realm roles for the new created group nothing >> happens. >> >> I checked the results with the normal Keycloak webfrontend. >> >> Here is my sample code: >> ... >> GroupRepresentation gr = new GroupRepresentation(); >> gr.setName("myGroup"); >> List realmRoleList=new ArrayList(); >> realmRoleList.add("test"); >> gr.setRealmRoles(realmRoleList); >> realmResource.groups().add(gr); >> ... >> // now the group 'myGroup' exists but no roles are assigned. >> >> Any advice or help is welcome >> >> Kind regards >> Eiko >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > From mposolda at redhat.com Tue May 31 08:17:27 2016 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 31 May 2016 14:17:27 +0200 Subject: [keycloak-user] How to create the same client (same id) for multiple realms programmatically In-Reply-To: References: <5746F714.6050007@redhat.com> <7l5jkwwlier47ro5c1dsdqcg.1464332607708@email.android.com> <574C0E9D.7040000@redhat.com> Message-ID: <574D80D7.4030608@redhat.com> Yeah, I am sorry to misuse this thread :-) It just came to my mind when Haim mentioned, that exception is not thrown in his code, even if creation of client model obviously failed. Marek On 30/05/16 20:24, Stian Thorgersen wrote: > +1 Not the correct thread for it though ;) > > On 30 May 2016 at 11:57, Marek Posolda > wrote: > > Maybe someone already mentions it before. IMO the returning > "Response" from the create methods on admin client is one of the > biggest limitation of current admin-client. For example if we > change ClientResources method: > > @POST @Consumes(MediaType.APPLICATION_JSON) > public Response create(ClientRepresentation clientRepresentation); > > to something like: > > @POST @Consumes(MediaType.APPLICATION_JSON) > @Produces(MediaType.APPLICATION_JSON) > public ClientRepresentation create(ClientRepresentation clientRepresentation); > > > > then the advantages will be: > - You won't need to parse the ID of newly created client from the > URI location and call additional GET request to retrieve newly > created client (You usually want newly created client when you are > creating it) > - In case the error happened, the exception will be thrown on > client-side too. With the "Response" object, the exception is not > thrown on client-side but you are supposed to manually check the > status code. This may be confusing for users, who are not so > familiar with the admin client. When exception is thrown on > client-side, it's crystal clear that something bad happened and > client wasn't successfully created on server side. > > Are there any disadvantages? The only one I see is, that POST > responses from server will need to return the representation of > created object, but that's maybe rather advantage (as you don't > need to call additional GET request, which in 95% of cases you need). > > Marek > > > On 30/05/16 08:04, Stian Thorgersen wrote: >> What's the status code for the response? It should be 409. >> >> On 27 May 2016 at 09:02, Haim Vana > > wrote: >> >> There is an exception in the server log, but it is not >> thrown, so I am not getting it in my code. >> >> >> >> -------- Original message -------- >> From: Stian Thorgersen > > >> Date: 5/27/16 09:24 (GMT+02:00) >> To: Haim Vana > > >> Cc: Marek Posolda > >, keycloak-user at lists.jboss.org >> >> Subject: Re: [keycloak-user] How to create the same client >> (same id) for multiple realms programmatically >> >> Do you not get a error when trying to create it the second >> time with the same id? If not please create a jira. >> >> On 26 May 2016 at 20:20, Haim Vana > > wrote: >> >> Thanks for your reply. >> >> My problem was that I have used setId instead of setClientId. >> >> *From:*Marek Posolda [mailto:mposolda at redhat.com >> ] >> *Sent:* Thursday, May 26, 2016 4:16 PM >> *To:* Haim Vana > >; >> keycloak-user at lists.jboss.org >> >> *Subject:* Re: [keycloak-user] How to create the same >> client (same id) for multiple realms programmatically >> >> You can use for example: >> >> RealmResource realm1 = *adminClient*.realms().realm(*"realm1"*); >> >> RealmResource realm2 = *adminClient*.realms().realm(*"realm2"*); >> >> realm1.clients().create(clientRepresentation); >> >> realm2.clients().create(clientRepresentation); >> >> >> For update you can take a look at some of our tests, >> which are updating client. For example this one : >> https://github.com/mposolda/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/admin/ClientTest.java#L183 >> >> Note that you need to know client Id (this is different >> thant clientId). The easiest is to set it manually in >> representation before you create client (via client.setId >> ) like it's done in this test. >> >> Marek >> >> On 26/05/16 14:54, Haim Vana wrote: >> >> Any idea regarding the below ? >> >> As a workaround how can I update existing client >> programmatically ? I couldn't find it in the admin API. >> >> Thanks again, >> >> Haim. >> >> *From:*Haim Vana >> *Sent:* Thursday, May 26, 2016 2:17 PM >> *To:* keycloak-user at lists.jboss.org >> >> *Subject:* How to create the same client (same id) >> for multiple realms programmatically >> >> Hi, >> >> I am trying to create the same client for many >> realms, however it creates it only once, probably >> because they have the same id, however in UI I am >> able to create it. >> >> Any idea how I can create the same client for >> different realms programmatically with the same id ? >> >> This is my code sample: >> >> ClientRepresentation clientRepresentation = *new *ClientRepresentation(); >> >> clientRepresentation.setId(clientId); // Same >> clientId for all reamls >> >> realm.clients().create(clientRepresentation); // >> Client is created only for first realm >> >> Any advice will be appreciated, >> >> Haim. >> >> The information contained in this message is >> proprietary to the sender, protected from disclosure, >> and may be privileged. The information is intended to >> be conveyed only to the designated recipient(s) of >> the message. If the reader of this message is not the >> intended recipient, you are hereby notified that any >> dissemination, use, distribution or copying of this >> communication is strictly prohibited and may be >> unlawful. If you have received this communication in >> error, please notify us immediately by replying to >> the message and deleting it from your computer. Thank >> you. >> >> >> _______________________________________________ >> >> keycloak-user mailing list >> >> keycloak-user at lists.jboss.org >> >> >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> The information contained in this message is proprietary >> to the sender, protected from disclosure, and may be >> privileged. The information is intended to be conveyed >> only to the designated recipient(s) of the message. If >> the reader of this message is not the intended recipient, >> you are hereby notified that any dissemination, use, >> distribution or copying of this communication is strictly >> prohibited and may be unlawful. If you have received this >> communication in error, please notify us immediately by >> replying to the message and deleting it from your >> computer. Thank you. >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> >> The information contained in this message is proprietary to >> the sender, protected from disclosure, and may be privileged. >> The information is intended to be conveyed only to the >> designated recipient(s) of the message. If the reader of this >> message is not the intended recipient, you are hereby >> notified that any dissemination, use, distribution or copying >> of this communication is strictly prohibited and may be >> unlawful. If you have received this communication in error, >> please notify us immediately by replying to the message and >> deleting it from your computer. Thank you. >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/d0504037/attachment-0001.html From emil.posmyk at gmail.com Tue May 31 08:19:46 2016 From: emil.posmyk at gmail.com (Emil Posmyk) Date: Tue, 31 May 2016 14:19:46 +0200 Subject: [keycloak-user] KC 1.9.4 Error during Message-ID: Hello I'm reciving error when I try login to our application: ClientProtocolException: URI does not specify a valid host name: https:/auth/realms/Brandpath/protocol/openid-connect/token Http protocol is working fine, no errors, but using https I recive each time uri without host name. Auth page is working fine. What can cause that error ? 14:59:22,937 ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-2) failed to turn code into token: org.apache.http.client.ClientProtocolException: URI does not specify a valid host name: https:/auth/realms/Brandpath/protocol/openid-connect/token [Server:ms-server1] at org.apache.http.impl.client.CloseableHttpClient.determineTarget(CloseableHttpClient.java:94) [Server:ms-server1] at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) [Server:ms-server1] at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107) [Server:ms-server1] at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55) [Server:ms-server1] at org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:107) [Server:ms-server1] at org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuthenticator.java:314) [Server:ms-server1] at org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:260) [Server:ms-server1] at org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:112) [Server:ms-server1] at org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110) [Server:ms-server1] at org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92) [Server:ms-server1] at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233) [Server:ms-server1] at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250) [Server:ms-server1] at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219) [Server:ms-server1] at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121) [Server:ms-server1] at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96) [Server:ms-server1] at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89) [Server:ms-server1] at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55) [Server:ms-server1] at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) [Server:ms-server1] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [Server:ms-server1] at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [Server:ms-server1] at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) [Server:ms-server1] at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) [Server:ms-server1] at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [Server:ms-server1] at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) [Server:ms-server1] at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) [Server:ms-server1] at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) [Server:ms-server1] at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) [Server:ms-server1] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [Server:ms-server1] at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) [Server:ms-server1] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [Server:ms-server1] at org.wildfly.mod_cluster.undertow.metric.RunningRequestsHttpHandler.handleRequest(RunningRequestsHttpHandler.java:69) [Server:ms-server1] at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) [Server:ms-server1] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [Server:ms-server1] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) [Server:ms-server1] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) [Server:ms-server1] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) [Server:ms-server1] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) [Server:ms-server1] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) [Server:ms-server1] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) [Server:ms-server1] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [Server:ms-server1] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [Server:ms-server1] at java.lang.Thread.run(Thread.java:745) *regards* *--* *Emil Posmyk* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/67f4ada7/attachment.html From mposolda at redhat.com Tue May 31 08:23:31 2016 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 31 May 2016 14:23:31 +0200 Subject: [keycloak-user] keycloak-admin-client and realm initialization In-Reply-To: <574D767A.9010905@gmail.com> References: <574D67DA.6010502@gmail.com> <574D6F70.7060403@redhat.com> <574D767A.9010905@gmail.com> Message-ID: <574D8243.9020603@redhat.com> There is separate endpoint for creating new group role mappings or user role mappings. For example see this code snippet in the test how to do it for users: https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/admin/UserTest.java#L791-L798 For groups it is similar endpoint. Marek On 31/05/16 13:33, Okie Oth wrote: > Thank you for the response :) > I had the same idea and so I grab the existing realm roles from the > server before I create the new group. A realm role with the desired name > exists and I try to add it with ID and name in setRealmRoles. > > I also try to add a group at first, grab the group list from server and > update the group with new (but existing) realm roles. With wireshark I > sniff the content that goes to the rest service and it contains my data. > > The response was HTTP-State 202 (no data). > > I test my code against final version 1.9.4 and 1.9.5. The keycloak > server runs in standalone mode in a Ubuntu 14.04 VM and uses Postgresql > as backend. > > Beside the groups I got a similar effect if I create a new user. I can > create the user, but he has no assigned group. > > Cheers > > Am 31.05.2016 um 13:03 schrieb Stan Silvert: >> I suspect your problem is that the roles don't exist yet. You need to >> create the role as a realm role before you assign it to a group. >> >> realmResource.roles().create(myRole); >> >> On 5/31/2016 6:30 AM, Okie Oth wrote: >>> Hello, >>> I'm a keycloak newbie and try to write a tool that initialize my >>> keycloak installation. Some parts work fine but I can't do deeper >>> initializations. For instance I can create a new user group but if I >>> want to assign some realm roles for the new created group nothing >>> happens. >>> >>> I checked the results with the normal Keycloak webfrontend. >>> >>> Here is my sample code: >>> ... >>> GroupRepresentation gr = new GroupRepresentation(); >>> gr.setName("myGroup"); >>> List realmRoleList=new ArrayList(); >>> realmRoleList.add("test"); >>> gr.setRealmRoles(realmRoleList); >>> realmResource.groups().add(gr); >>> ... >>> // now the group 'myGroup' exists but no roles are assigned. >>> >>> Any advice or help is welcome >>> >>> Kind regards >>> Eiko >>> >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From mposolda at redhat.com Tue May 31 08:26:19 2016 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 31 May 2016 14:26:19 +0200 Subject: [keycloak-user] KC 1.9.4 Error during In-Reply-To: References: Message-ID: <574D82EB.7050504@redhat.com> How is "auth-server-url" in your keycloak.json configured? If you're using relative URI, then you can maybe try to use absolute URI and see if it help? Marek On 31/05/16 14:19, Emil Posmyk wrote: > Hello > > I'm reciving error when I try login to our application: > ClientProtocolException: URI does not specify a valid host name: > https:/auth/realms/Brandpath/protocol/openid-connect/token > Http protocol is working fine, no errors, but using https I recive > each time uri without host name. > Auth page is working fine. > > What can cause that error ? > > > 14:59:22,937 ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] > (default task-2) failed to turn code into token: > org.apache.http.client.ClientProtocolException: URI does not specify a > valid host name: > https:/auth/realms/Brandpath/protocol/openid-connect/token > [Server:ms-server1] at > org.apache.http.impl.client.CloseableHttpClient.determineTarget(CloseableHttpClient.java:94) > [Server:ms-server1] at > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) > [Server:ms-server1] at > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107) > [Server:ms-server1] at > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55) > [Server:ms-server1] at > org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:107) > [Server:ms-server1] at > org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuthenticator.java:314) > [Server:ms-server1] at > org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:260) > [Server:ms-server1] at > org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:112) > [Server:ms-server1] at > org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110) > [Server:ms-server1] at > org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92) > [Server:ms-server1] at > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233) > [Server:ms-server1] at > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250) > [Server:ms-server1] at > io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219) > [Server:ms-server1] at > io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121) > [Server:ms-server1] at > io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96) > [Server:ms-server1] at > io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89) > [Server:ms-server1] at > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55) > [Server:ms-server1] at > io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) > [Server:ms-server1] at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > [Server:ms-server1] at > io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) > [Server:ms-server1] at > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > [Server:ms-server1] at > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > [Server:ms-server1] at > io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) > [Server:ms-server1] at > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > [Server:ms-server1] at > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > [Server:ms-server1] at > io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > [Server:ms-server1] at > io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > [Server:ms-server1] at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > [Server:ms-server1] at > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > [Server:ms-server1] at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > [Server:ms-server1] at > org.wildfly.mod_cluster.undertow.metric.RunningRequestsHttpHandler.handleRequest(RunningRequestsHttpHandler.java:69) > [Server:ms-server1] at > org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) > [Server:ms-server1] at > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > [Server:ms-server1] at > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) > [Server:ms-server1] at > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) > [Server:ms-server1] at > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > [Server:ms-server1] at > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) > [Server:ms-server1] at > io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > [Server:ms-server1] at > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) > [Server:ms-server1] at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [Server:ms-server1] at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [Server:ms-server1] at java.lang.Thread.run(Thread.java:745) > > / > regards/ > /--/ > /Emil Posmyk > / > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/c4af3807/attachment-0001.html From mposolda at redhat.com Tue May 31 08:36:34 2016 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 31 May 2016 14:36:34 +0200 Subject: [keycloak-user] Async request/response processing at Keycloak In-Reply-To: References: Message-ID: <574D8552.8060508@redhat.com> Maybe it will help if you put it to KEYCLOAK_HOME/modules/systems/add-ons/keycloak/org/keycloak/keycloak-server-subsystem/main/server-war/WEB-INF/web.xml to Keycloak Session Management Filter? Feel free to create JIRA for it (and mention if it helps or not. If it helps, then we know that it's sufficient to add it to that filter, so it will be easy work to fix). Marek On 31/05/16 10:50, Bystrik Horvath wrote: > Hello community, > > I found that (since 1.9.2?) there's RealmResourceProvider that gives > me the possibility to provide own REST endpoint. After implementing > the endpoint using async capabilty of jax-rs, I'm getting exception like: > UT010026: Async is not supported for this request, as not all filters > or Servlets were marked as supporting async. > > How is it possible to tweak Keycloak (I'm currently on 1.9.3) to > asynchronously respond to my requests in implementation of > RealmResourceProvider? > > Thank you for any comment on this. > > Best regards, > Bystrik > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/76bdc88e/attachment.html From mposolda at redhat.com Tue May 31 08:37:21 2016 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 31 May 2016 14:37:21 +0200 Subject: [keycloak-user] Async request/response processing at Keycloak In-Reply-To: <574D8552.8060508@redhat.com> References: <574D8552.8060508@redhat.com> Message-ID: <574D8581.9040105@redhat.com> Sorry, I meant to put: true to that filter. Marek On 31/05/16 14:36, Marek Posolda wrote: > Maybe it will help if you put it to > KEYCLOAK_HOME/modules/systems/add-ons/keycloak/org/keycloak/keycloak-server-subsystem/main/server-war/WEB-INF/web.xml > to Keycloak Session Management Filter? Feel free to create JIRA for it > (and mention if it helps or not. If it helps, then we know that it's > sufficient to add it to that filter, so it will be easy work to fix). > > Marek > > > On 31/05/16 10:50, Bystrik Horvath wrote: >> Hello community, >> >> I found that (since 1.9.2?) there's RealmResourceProvider that gives >> me the possibility to provide own REST endpoint. After implementing >> the endpoint using async capabilty of jax-rs, I'm getting exception >> like: >> UT010026: Async is not supported for this request, as not all filters >> or Servlets were marked as supporting async. >> >> How is it possible to tweak Keycloak (I'm currently on 1.9.3) to >> asynchronously respond to my requests in implementation of >> RealmResourceProvider? >> >> Thank you for any comment on this. >> >> Best regards, >> Bystrik >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/dff127ce/attachment.html From mposolda at redhat.com Tue May 31 09:05:10 2016 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 31 May 2016 15:05:10 +0200 Subject: [keycloak-user] KC 1.9.4 Error during In-Reply-To: References: <574D82EB.7050504@redhat.com> Message-ID: <574D8C06.2050600@redhat.com> Does your keycloak server have certificate signed by known CA authority or are you using some self-signed? If you have self-signed, you also need to configure truststore. See http://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#adapter-config and especially properties related to truststore. Marek On 31/05/16 15:00, Emil Posmyk wrote: > sorry, i forgot to finish title > > { > "realm": "Brandpath", > "realm-public-key": "key.....", > "auth-server-url": "https://sabdev_oms.brandpath.net/auth", > "ssl-required": "external", > "resource": "oms-web", > "credentials": { > "secret": "secret" > }, > "use-resource-role-mappings": true > } > > > > regards > /--/ > /Emil Posmyk > > / > > 2016-05-31 14:26 GMT+02:00 Marek Posolda >: > > How is "auth-server-url" in your keycloak.json configured? If > you're using relative URI, then you can maybe try to use absolute > URI and see if it help? > > Marek > > > On 31/05/16 14:19, Emil Posmyk wrote: >> Hello >> >> I'm reciving error when I try login to our application: >> ClientProtocolException: URI does not specify a valid host name: >> https:/auth/realms/Brandpath/protocol/openid-connect/token >> Http protocol is working fine, no errors, but using https I >> recive each time uri without host name. >> Auth page is working fine. >> >> What can cause that error ? >> >> >> 14:59:22,937 ERROR >> [org.keycloak.adapters.OAuthRequestAuthenticator] (default >> task-2) failed to turn code into token: >> org.apache.http.client.ClientProtocolException: URI does not >> specify a valid host name: >> https:/auth/realms/Brandpath/protocol/openid-connect/token >> [Server:ms-server1] at >> org.apache.http.impl.client.CloseableHttpClient.determineTarget(CloseableHttpClient.java:94) >> [Server:ms-server1] at >> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) >> [Server:ms-server1] at >> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107) >> [Server:ms-server1] at >> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55) >> [Server:ms-server1] at >> org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:107) >> [Server:ms-server1] at >> org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuthenticator.java:314) >> [Server:ms-server1] at >> org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:260) >> [Server:ms-server1] at >> org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:112) >> [Server:ms-server1] at >> org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110) >> [Server:ms-server1] at >> org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92) >> [Server:ms-server1] at >> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233) >> [Server:ms-server1] at >> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250) >> [Server:ms-server1] at >> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219) >> [Server:ms-server1] at >> io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121) >> [Server:ms-server1] at >> io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96) >> [Server:ms-server1] at >> io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89) >> [Server:ms-server1] at >> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55) >> [Server:ms-server1] at >> io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) >> [Server:ms-server1] at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> [Server:ms-server1] at >> io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) >> [Server:ms-server1] at >> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) >> [Server:ms-server1] at >> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) >> [Server:ms-server1] at >> io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) >> [Server:ms-server1] at >> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) >> [Server:ms-server1] at >> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) >> [Server:ms-server1] at >> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) >> [Server:ms-server1] at >> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) >> [Server:ms-server1] at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> [Server:ms-server1] at >> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >> [Server:ms-server1] at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> [Server:ms-server1] at >> org.wildfly.mod_cluster.undertow.metric.RunningRequestsHttpHandler.handleRequest(RunningRequestsHttpHandler.java:69) >> [Server:ms-server1] at >> org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) >> [Server:ms-server1] at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> [Server:ms-server1] at >> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) >> [Server:ms-server1] at >> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) >> [Server:ms-server1] at >> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) >> [Server:ms-server1] at >> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) >> [Server:ms-server1] at >> io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) >> [Server:ms-server1] at >> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) >> [Server:ms-server1] at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >> [Server:ms-server1] at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> [Server:ms-server1] at java.lang.Thread.run(Thread.java:745) >> >> / >> regards/ >> /--/ >> /Emil Posmyk >> / >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/1892eff5/attachment-0001.html From bystrik.horvath at gmail.com Tue May 31 09:49:02 2016 From: bystrik.horvath at gmail.com (Bystrik Horvath) Date: Tue, 31 May 2016 15:49:02 +0200 Subject: [keycloak-user] Async request/response processing at Keycloak In-Reply-To: <574D8581.9040105@redhat.com> References: <574D8552.8060508@redhat.com> <574D8581.9040105@redhat.com> Message-ID: Hi Marek, thank you for the advice. It helped me. Just small correction - the web.xml is located in /modules/system/layers/keycloak/org/keycloak/keycloak-server-subsystem/main/server-war/WEB-INF/web.xml (in my Keycloak 1.9.3.Final). The filter definition looks then like follows: Keycloak Session Management org.keycloak.services.filters.KeycloakSessionServletFilter true Before applying the filter settings I found a small trick how to do the same by putting two lines in the code: ServletRequestContext context = ServletRequestContext.current(); context.setAsyncSupported(true); Anyway, I will create a JIRA for this. Thank you&Best regards, Bystrik On Tue, May 31, 2016 at 2:37 PM, Marek Posolda wrote: > Sorry, I meant to put: > > true > > to that filter. > > Marek > > > On 31/05/16 14:36, Marek Posolda wrote: > > Maybe it will help if you put it to > KEYCLOAK_HOME/modules/systems/add-ons/keycloak/org/keycloak/keycloak-server-subsystem/main/server-war/WEB-INF/web.xml > to Keycloak Session Management Filter? Feel free to create JIRA for it (and > mention if it helps or not. If it helps, then we know that it's sufficient > to add it to that filter, so it will be easy work to fix). > > Marek > > > On 31/05/16 10:50, Bystrik Horvath wrote: > > Hello community, > > I found that (since 1.9.2?) there's RealmResourceProvider that gives me > the possibility to provide own REST endpoint. After implementing the > endpoint using async capabilty of jax-rs, I'm getting exception like: > UT010026: Async is not supported for this request, as not all filters or > Servlets were marked as supporting async. > > How is it possible to tweak Keycloak (I'm currently on 1.9.3) to > asynchronously respond to my requests in implementation of > RealmResourceProvider? > > Thank you for any comment on this. > > Best regards, > Bystrik > > > _______________________________________________ > keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/f6a589eb/attachment.html From bystrik.horvath at gmail.com Tue May 31 10:12:05 2016 From: bystrik.horvath at gmail.com (Bystrik Horvath) Date: Tue, 31 May 2016 16:12:05 +0200 Subject: [keycloak-user] Async request/response processing at Keycloak In-Reply-To: References: <574D8552.8060508@redhat.com> <574D8581.9040105@redhat.com> Message-ID: https://issues.jboss.org/browse/KEYCLOAK-3062 On Tue, May 31, 2016 at 3:49 PM, Bystrik Horvath wrote: > Hi Marek, > > thank you for the advice. It helped me. Just small correction - the > web.xml is located > in /modules/system/layers/keycloak/org/keycloak/keycloak-server-subsystem/main/server-war/WEB-INF/web.xml > (in my Keycloak 1.9.3.Final). The filter definition looks then like follows: > > > Keycloak Session Management > > org.keycloak.services.filters.KeycloakSessionServletFilter > true > > > Before applying the filter settings I found a small trick how to do the > same by putting two lines in the code: > > ServletRequestContext context = ServletRequestContext.current(); > context.setAsyncSupported(true); > > Anyway, I will create a JIRA for this. > > Thank you&Best regards, > > Bystrik > > > On Tue, May 31, 2016 at 2:37 PM, Marek Posolda > wrote: > >> Sorry, I meant to put: >> >> true >> >> to that filter. >> >> Marek >> >> >> On 31/05/16 14:36, Marek Posolda wrote: >> >> Maybe it will help if you put it to >> KEYCLOAK_HOME/modules/systems/add-ons/keycloak/org/keycloak/keycloak-server-subsystem/main/server-war/WEB-INF/web.xml >> to Keycloak Session Management Filter? Feel free to create JIRA for it (and >> mention if it helps or not. If it helps, then we know that it's sufficient >> to add it to that filter, so it will be easy work to fix). >> >> Marek >> >> >> On 31/05/16 10:50, Bystrik Horvath wrote: >> >> Hello community, >> >> I found that (since 1.9.2?) there's RealmResourceProvider that gives me >> the possibility to provide own REST endpoint. After implementing the >> endpoint using async capabilty of jax-rs, I'm getting exception like: >> UT010026: Async is not supported for this request, as not all filters or >> Servlets were marked as supporting async. >> >> How is it possible to tweak Keycloak (I'm currently on 1.9.3) to >> asynchronously respond to my requests in implementation of >> RealmResourceProvider? >> >> Thank you for any comment on this. >> >> Best regards, >> Bystrik >> >> >> _______________________________________________ >> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/ce734a2f/attachment.html From okie.othsam at gmail.com Tue May 31 10:17:12 2016 From: okie.othsam at gmail.com (Okie Oth) Date: Tue, 31 May 2016 16:17:12 +0200 Subject: [keycloak-user] keycloak-admin-client and realm initialization In-Reply-To: <574D8243.9020603@redhat.com> References: <574D67DA.6010502@gmail.com> <574D6F70.7060403@redhat.com> <574D767A.9010905@gmail.com> <574D8243.9020603@redhat.com> Message-ID: <574D9CE8.50307@gmail.com> Hello Marek, that's it, now it works :) Thank you. Eiko Am 31.05.2016 um 14:23 schrieb Marek Posolda: > There is separate endpoint for creating new group role mappings or > user role mappings. For example see this code snippet in the test how > to do it for users: > https://github.com/keycloak/keycloak/blob/master/testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/admin/UserTest.java#L791-L798 > > > For groups it is similar endpoint. > > Marek > > On 31/05/16 13:33, Okie Oth wrote: >> Thank you for the response :) >> I had the same idea and so I grab the existing realm roles from the >> server before I create the new group. A realm role with the desired name >> exists and I try to add it with ID and name in setRealmRoles. >> >> I also try to add a group at first, grab the group list from server and >> update the group with new (but existing) realm roles. With wireshark I >> sniff the content that goes to the rest service and it contains my data. >> >> The response was HTTP-State 202 (no data). >> >> I test my code against final version 1.9.4 and 1.9.5. The keycloak >> server runs in standalone mode in a Ubuntu 14.04 VM and uses Postgresql >> as backend. >> >> Beside the groups I got a similar effect if I create a new user. I can >> create the user, but he has no assigned group. >> >> Cheers >> >> Am 31.05.2016 um 13:03 schrieb Stan Silvert: >>> I suspect your problem is that the roles don't exist yet. You need to >>> create the role as a realm role before you assign it to a group. >>> >>> realmResource.roles().create(myRole); >>> >>> On 5/31/2016 6:30 AM, Okie Oth wrote: >>>> Hello, >>>> I'm a keycloak newbie and try to write a tool that initialize my >>>> keycloak installation. Some parts work fine but I can't do deeper >>>> initializations. For instance I can create a new user group but if I >>>> want to assign some realm roles for the new created group nothing >>>> happens. >>>> >>>> I checked the results with the normal Keycloak webfrontend. >>>> >>>> Here is my sample code: >>>> ... >>>> GroupRepresentation gr = new GroupRepresentation(); >>>> gr.setName("myGroup"); >>>> List realmRoleList=new ArrayList(); >>>> realmRoleList.add("test"); >>>> gr.setRealmRoles(realmRoleList); >>>> realmResource.groups().add(gr); >>>> ... >>>> // now the group 'myGroup' exists but no roles are assigned. >>>> >>>> Any advice or help is welcome >>>> >>>> Kind regards >>>> Eiko >>>> >>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > From g.orciuch at gmail.com Tue May 31 10:21:08 2016 From: g.orciuch at gmail.com (Gregory Orciuch) Date: Tue, 31 May 2016 16:21:08 +0200 Subject: [keycloak-user] KC 1.9.4 Error during In-Reply-To: <574D8C06.2050600@redhat.com> References: <574D82EB.7050504@redhat.com> <574D8C06.2050600@redhat.com> Message-ID: Hi, I dont get it. How the truststore/keystore properties are related to not having hostname in the returned URL ? truststore is usually taken by java low level SSL stack (unless KeyCloak using own ssl stack) and even if wrong it does produce PKIX exception which is not in Emil's stack trace. I suspect the underscore "_" in the "auth-server-url" or, the name is not resolved by DNS from KeyCloak server perspective. BR, Gregory 2016-05-31 15:05 GMT+02:00 Marek Posolda : > Does your keycloak server have certificate signed by known CA authority or > are you using some self-signed? If you have self-signed, you also need to > configure truststore. See > http://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#adapter-config > and especially properties related to truststore. > > Marek > > On 31/05/16 15:00, Emil Posmyk wrote: > > sorry, i forgot to finish title > > { > "realm": "Brandpath", > "realm-public-key": "key.....", > "auth-server-url": "https://sabdev_oms.brandpath.net/auth", > "ssl-required": "external", > "resource": "oms-web", > "credentials": { > "secret": "secret" > }, > "use-resource-role-mappings": true > } > > > > regards > *--* > > > *Emil Posmyk * > > 2016-05-31 14:26 GMT+02:00 Marek Posolda : > >> How is "auth-server-url" in your keycloak.json configured? If you're >> using relative URI, then you can maybe try to use absolute URI and see if >> it help? >> >> Marek >> >> >> On 31/05/16 14:19, Emil Posmyk wrote: >> >> Hello >> >> I'm reciving error when I try login to our application: >> ClientProtocolException: URI does not specify a valid host name: >> >> https:/auth/realms/Brandpath/protocol/openid-connect/token >> Http protocol is working fine, no errors, but using https I recive each >> time uri without host name. >> Auth page is working fine. >> >> What can cause that error ? >> >> >> 14:59:22,937 ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] >> (default task-2) failed to turn code into token: >> org.apache.http.client.ClientProtocolException: URI does not specify a >> valid host name: >> >> https:/auth/realms/Brandpath/protocol/openid-connect/token >> [Server:ms-server1] at >> org.apache.http.impl.client.CloseableHttpClient.determineTarget(CloseableHttpClient.java:94) >> [Server:ms-server1] at >> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) >> [Server:ms-server1] at >> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107) >> [Server:ms-server1] at >> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55) >> [Server:ms-server1] at >> org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:107) >> [Server:ms-server1] at >> org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuthenticator.java:314) >> [Server:ms-server1] at >> org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:260) >> [Server:ms-server1] at >> org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:112) >> [Server:ms-server1] at >> org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110) >> [Server:ms-server1] at >> org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92) >> [Server:ms-server1] at >> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233) >> [Server:ms-server1] at >> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250) >> [Server:ms-server1] at >> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219) >> [Server:ms-server1] at >> io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121) >> [Server:ms-server1] at >> io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96) >> [Server:ms-server1] at >> io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89) >> [Server:ms-server1] at >> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55) >> [Server:ms-server1] at >> io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) >> [Server:ms-server1] at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> [Server:ms-server1] at >> io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) >> [Server:ms-server1] at >> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) >> [Server:ms-server1] at >> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) >> [Server:ms-server1] at >> io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) >> [Server:ms-server1] at >> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) >> [Server:ms-server1] at >> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) >> [Server:ms-server1] at >> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) >> [Server:ms-server1] at >> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) >> [Server:ms-server1] at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> [Server:ms-server1] at >> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >> [Server:ms-server1] at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> [Server:ms-server1] at >> org.wildfly.mod_cluster.undertow.metric.RunningRequestsHttpHandler.handleRequest(RunningRequestsHttpHandler.java:69) >> [Server:ms-server1] at >> org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) >> [Server:ms-server1] at >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> [Server:ms-server1] at >> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284) >> [Server:ms-server1] at >> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) >> [Server:ms-server1] at >> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) >> [Server:ms-server1] at >> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) >> [Server:ms-server1] at >> io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) >> [Server:ms-server1] at >> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793) >> [Server:ms-server1] at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >> [Server:ms-server1] at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> [Server:ms-server1] at java.lang.Thread.run(Thread.java:745) >> >> >> * regards* >> *--* >> >> *Emil Posmyk * >> >> >> _______________________________________________ >> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user >> >> >> > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/c533d7f5/attachment-0001.html From jdillon at redhat.com Tue May 31 11:01:43 2016 From: jdillon at redhat.com (Jim Dillon) Date: Tue, 31 May 2016 11:01:43 -0400 Subject: [keycloak-user] Keycloak integration with REST service Message-ID: Hello, I'm looking into Keycloak for a consulting engagement. The idea is to use Keycloak for SSO on multiple front end applications in order to secure many REST APIs. Some of the front end applications will be mobile and others will be browser base. Keycloak easily handled both effortlessly in a simple demo I created. Initially the client was looking for Active Directory integration, but now has decided to look into integrating with a REST service for authentication / group information. This brings up a few initial questions: 1. How would one go about integrating with this REST Service? - The user would need to be authenticated with usename / password retrieved from the REST Service. - The Password is encrypted. - New users would need to be "created" via the REST Service as well. (The REST Service is really an interface for an oracle table. So new users ultimately would need to be inserted into this table.) 2. I assume that Keycloak still needs its own database for operation, but could this database be configured to not include password storage for users? Thank you, jim *Red Hat Consulting* jdillon at redhat.com || 540.420.3639 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/373a9e0d/attachment.html From psilva at redhat.com Tue May 31 13:08:03 2016 From: psilva at redhat.com (Pedro Igor Silva) Date: Tue, 31 May 2016 13:08:03 -0400 (EDT) Subject: [keycloak-user] Async request/response processing at Keycloak In-Reply-To: References: <574D8552.8060508@redhat.com> <574D8581.9040105@redhat.com> Message-ID: <694086856.12892867.1464714483395.JavaMail.zimbra@redhat.com> We already have async support from https://github.com/keycloak/keycloak/pull/2617. Those changes are related with the fine-grained authorization services, which are currently implemented using async support. Wondering if you can try it out and see if we are missing something. ----- Original Message ----- From: "Bystrik Horvath" To: "Marek Posolda" Cc: "keycloak-user" Sent: Tuesday, May 31, 2016 11:12:05 AM Subject: Re: [keycloak-user] Async request/response processing at Keycloak https://issues.jboss.org/browse/KEYCLOAK-3062 On Tue, May 31, 2016 at 3:49 PM, Bystrik Horvath < bystrik.horvath at gmail.com > wrote: Hi Marek, thank you for the advice. It helped me. Just small correction - the web.xml is located in /modules/system/layers/keycloak/org/keycloak/keycloak-server-subsystem/main/server-war/WEB-INF/web.xml (in my Keycloak 1.9.3.Final). The filter definition looks then like follows: Keycloak Session Management org.keycloak.services.filters.KeycloakSessionServletFilter true Before applying the filter settings I found a small trick how to do the same by putting two lines in the code: ServletRequestContext context = ServletRequestContext.current(); context.setAsyncSupported(true); Anyway,?I will create a JIRA for this. Thank you&Best regards, Bystrik On Tue, May 31, 2016 at 2:37 PM, Marek Posolda < mposolda at redhat.com > wrote: Sorry, I meant to put: true to that filter. Marek On 31/05/16 14:36, Marek Posolda wrote: Maybe it will help if you put it to KEYCLOAK_HOME/modules/systems/add-ons/keycloak/org/keycloak/keycloak-server-subsystem/main/server-war/WEB-INF/web.xml to Keycloak Session Management Filter? Feel free to create JIRA for it (and mention if it helps or not. If it helps, then we know that it's sufficient to add it to that filter, so it will be easy work to fix). Marek On 31/05/16 10:50, Bystrik Horvath wrote: Hello community, I found that (since 1.9.2?) there's RealmResourceProvider that gives me the possibility to provide own REST endpoint. After implementing the endpoint using async capabilty of jax-rs, I'm getting exception like: UT010026: Async is not supported for this request, as not all filters or Servlets were marked as supporting async. How is it possible to tweak Keycloak (I'm currently on 1.9.3) to asynchronously respond to my requests in implementation of RealmResourceProvider ? Thank you for any comment on this. Best regards, Bystrik _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user _______________________________________________ keycloak-user mailing list keycloak-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user From srossillo at smartling.com Tue May 31 14:14:33 2016 From: srossillo at smartling.com (Scott Rossillo) Date: Tue, 31 May 2016 14:14:33 -0400 Subject: [keycloak-user] Fwd: Re: Redirection issue with proxy behind keycloak In-Reply-To: <7a45ae5d-cf0f-a5d5-0ab5-1df8ee8aa9da@tesicnor.com> References: <03225e22-5a31-d3c5-4285-69e355e1950e@tesicnor.com> <5e1b50b9-b7d0-5b2e-b16c-4df98da6f485@tesicnor.com> <7a45ae5d-cf0f-a5d5-0ab5-1df8ee8aa9da@tesicnor.com> Message-ID: Hi Artiz, So just to be clear, which Keycloak adapter are you using? The Spring Boot Adapter or the Spring Security Adapter? Scott Rossillo Smartling | Senior Software Engineer srossillo at smartling.com > On May 31, 2016, at 3:13 AM, Aritz Maeztu wrote: > > I've got some Spring Boot application instances with embeded Tomcat servlet containers. Tomcat has a similar system to Wildfly for request dumpering, that's what I have enabled for getting the trace below. In short words that's the behaviour I'm able to see: > > 1. Zuul Proxy (Spring Boot in Tomcat) -> Organization Service (8083 port) : A forward request where X-forwarded headers are included > > 2. Organization Service (localhost:8083) : Looks for a token and if it's not available, the keycloak adapter redirects to the /sso/login of the same service (Here the traceability from the proxy gets losts) > > 3. localhost:8083/sso/login: Redirects to the keycloak wildfly server, saving the requested url > > 4. Keycloak login: The user performs the authentication and the redirectUri is localhost:8083/sso/login. Later on, the login endpoint redirects the user to the url requested in point 2, not the first one from the proxy. > > I only have this problem when my organization service needs to verify the token (or a token doesn't exist) using the keycloak adapter. When the /sso/login endpoint is not requested, everything is working properly. Hope I've explained it well! > > > 31/05/2016 7:15(e)an, Stian Thorgersen igorleak idatzi zuen: >> Where is your app deployed? If it's on WildFly you can follow the same steps used to configure reverse proxy for Keycloak Server to configure WildFly. Check if getRequestURL returns the correct URL in your app. >> >> On 30 May 2016 at 15:08, Aritz Maeztu > wrote: >> >> >> >> >> -------- Birbidalitako mezua -------- >> Gaia: Re: [keycloak-user] Redirection issue with proxy behind keycloak >> Data: Mon, 30 May 2016 13:28:21 +0200 >> Nork: Aritz Maeztu >> Nori: stian at redhat.com >> CC: Niels Bertram , keycloak-user , Scott Rossillo >> >> >> I've done all the traceability from the proxy server till the login page is displayed: >> >> First step, /organization/organizations is requested, so the proxy server knows it has to be forwarded to the 8083 port (the one for the organization service). That's the first request received by my application's Tomcat: >> >> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 START TIME =30-may-2016 13:01:18 >> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 requestURI=/organizations >> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 authType=null >> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 characterEncoding=UTF-8 >> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 contentLength=-1 >> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 contentType=null >> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 contextPath= >> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=accept-language=es-ES,es;q=0.8 >> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=x-forwarded-host=mies-057:8765 >> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=x-forwarded-prefix=/organization >> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=upgrade-insecure-requests=1 >> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=accept-encoding=gzip >> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=accept=text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 >> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=user-agent=Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 >> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=netflix.nfhttpclient.version=1.0 >> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=x-netflix-httpclientname=organization >> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=host=mies-057:8083 >> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=connection=Keep-Alive >> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 locale=es_ES >> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 method=GET >> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 pathInfo=null >> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 protocol=HTTP/1.1 >> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 queryString=null >> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 remoteAddr=192.168.56.1 >> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 remoteHost=192.168.56.1 >> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 remoteUser=null >> 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 requestedSessionId=null >> 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 scheme=http >> 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 serverName=mies-057 >> 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 serverPort=8083 >> 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 servletPath=/organizations >> 2016-05-30 13:01:18.891 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 isSecure=false >> 2016-05-30 13:01:18.891 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 ------------------=-------------------------------------------- >> >> Here x-forwarded-host is mies-057:8765 (the proxy server) and x-forwarded-prefix is /organization. So the original request is kept in the headers. Well, now my service (8083) tries to check for authorization via the /sso/login endpoint from the keycloak spring security adapter: >> >> 2016-05-30 13:01:18.892 DEBUG 18096 --- [nio-8083-exec-9] o.k.a.s.management.HttpSessionManager : Session created: CDCA7AD4439DE94BD0B3B5803DAA0752 >> 2016-05-30 13:01:18.892 DEBUG 18096 --- [nio-8083-exec-9] k.a.s.a.KeycloakAuthenticationEntryPoint : Redirecting to login URI /sso/login >> 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 ------------------=-------------------------------------------- >> 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 authType=null >> 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 contentType=null >> 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=X-Content-Type-Options=nosniff >> 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=X-XSS-Protection=1; mode=block >> 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=Cache-Control=no-cache, no-store, max-age=0, must-revalidate >> 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=Pragma=no-cache >> 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=Expires=0 >> 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=X-Frame-Options=DENY >> 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=Set-Cookie=JSESSIONID=CDCA7AD4439DE94BD0B3B5803DAA0752; Path=/; HttpOnly >> 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=Location=http://mies-057:8083/sso/login >> 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 remoteUser=null >> 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 status=302 >> 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 END TIME =30-may-2016 13:01:18 >> 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 =============================================================== >> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 START TIME =30-may-2016 13:01:18 >> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 requestURI=/sso/login >> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 authType=null >> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 characterEncoding=UTF-8 >> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 contentLength=-1 >> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 contentType=null >> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 contextPath= >> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 cookie=JSESSIONID=CDCA7AD4439DE94BD0B3B5803DAA0752 >> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 header=host=mies-057:8083 >> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 header=connection=keep-alive >> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 header=accept=text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 >> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 header=upgrade-insecure-requests=1 >> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 header=user-agent=Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 >> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 header=accept-encoding=gzip, deflate, sdch >> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 header=accept-language=es-ES,es;q=0.8 >> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 header=cookie=JSESSIONID=CDCA7AD4439DE94BD0B3B5803DAA0752 >> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 locale=es_ES >> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 method=GET >> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 pathInfo=null >> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 protocol=HTTP/1.1 >> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 queryString=null >> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 remoteAddr=192.168.56.1 >> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 remoteHost=192.168.56.1 >> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 remoteUser=null >> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 requestedSessionId=CDCA7AD4439DE94BD0B3B5803DAA0752 >> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 scheme=http >> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 serverName=mies-057 >> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 serverPort=8083 >> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 servletPath=/sso/login >> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 isSecure=false >> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 ------------------=-------------------------------------------- >> 2016-05-30 13:01:18.904 DEBUG 18096 --- [io-8083-exec-10] o.k.adapters.PreAuthActionsHandler : adminRequest http://mies-057:8083/sso/login >> 2016-05-30 13:01:18.904 DEBUG 18096 --- [io-8083-exec-10] f.KeycloakAuthenticationProcessingFilter : Request is to process authentication >> 2016-05-30 13:01:18.904 DEBUG 18096 --- [io-8083-exec-10] f.KeycloakAuthenticationProcessingFilter : Attempting Keycloak authentication >> 2016-05-30 13:01:18.904 TRACE 18096 --- [io-8083-exec-10] o.k.adapters.RequestAuthenticator : --> authenticate() >> 2016-05-30 13:01:18.904 TRACE 18096 --- [io-8083-exec-10] o.k.adapters.RequestAuthenticator : try bearer >> 2016-05-30 13:01:18.904 TRACE 18096 --- [io-8083-exec-10] o.k.adapters.RequestAuthenticator : try oauth >> 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] o.k.a.s.token.SpringSecurityTokenStore : Checking if org.keycloak.adapters.springsecurity.authentication.SpringSecurityRequestAuthenticator at d328c2d is cached >> 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] o.k.adapters.OAuthRequestAuthenticator : there was no code >> 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] o.k.adapters.OAuthRequestAuthenticator : redirecting to auth server >> 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] o.k.adapters.OAuthRequestAuthenticator : callback uri: http://mies-057:8083/sso/login >> 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] f.KeycloakAuthenticationProcessingFilter : Auth outcome: NOT_ATTEMPTED >> 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] o.k.adapters.OAuthRequestAuthenticator : Sending redirect to login page: http://mies-057.tesicnor.com:8080/auth/realms/master/protocol/openid-connect/auth?response_type=code&client_id=organization&redirect_uri=http%3A%2F%2Fmies-057%3A8083%2Fsso%2Flogin&state=1%2F21d709ec-1e69-41c5-ac6d-c705f8ce3907&login=true >> As it's shown in the logs, the X-forwarded logs are not kept by the keycloak adapter (look at the lines below k.a.s.a.KeycloakAuthenticationEntryPoint : Redirecting to login URI /sso/login). So could it be the proxy server itself being properly configured but the keycloak adapter losing the original headers while performing the redirection? >> >> I've also set up the request dumper in the undertow server as Niels suggested, but obviously, X-forwarded headers are not reaching the keycloak server.. >> >> Thanks for your time, again ;-) >> >> >> >> >> 25/05/2016 7:22(e)an, Stian Thorgersen igorleak idatzi zuen: >>> You need the Host and X-Forwarded-For headers to be included and there's also some config to be done on the Keycloak server (see http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#proxy-address-forwarding ) >>> >>> On 24 May 2016 at 08:46, Aritz Maeztu < amaeztu at tesicnor.com > wrote: >>> Hi Niels and Scott. First of all, thank you very much for your help. I'm currently using Zuul (Spring Cloud) as the reverse proxy. All the services are registered in a discovery service called Eureka and then Zuul looks for the service id there and performs de redirection. I read about X-Forwarded headers, but I thought it might result in a security issue if not included, not that it could affect the redirection process. >>> >>> As Scott says, I suppose the Host and the X-Real-Ip headers are the relevant ones here, so I guess I should instruct Zuul to send them when the service is addressed (however I wonder why they are not already being sent, as Zuul is a proxy service, all in all). >>> >>> Here I include a preview of the first redirection made to the keycloak login page, which shows the request headers sent to the service /login endpoint (at port 8081 in localhost): >>> >>> https://www.dropbox.com/s/iof9yefytzay6j2/screenshot.PNG?dl=0 >>> >>> 24/05/2016 2:08(e)an, Niels Bertram igorleak idatzi zuen: >>>> Hi Artitz, >>>> >>>> a great way to figure out what is sent from the reverse proxy to your keycloak server is to use the undertow request dumper. >>>> >>>> From the jboss-cli just add the request dumper filter to your undertow configuration like this: >>>> >>>> $KC_HOME/bin/jbpss-cli.sh -c >>>> >>>> /subsystem=undertow/configuration=filter/custom-filter=request-dumper:add(class-name=io.undertow.server.handlers.RequestDumpingHandler, module=io.undertow.core) >>>> >>>> /subsystem=undertow/server=default-server/host=default-host/filter-ref=request-dumper:add >>>> >>>> /:reload >>>> >>>> given your apache config looks something like this: >>>> >>>> ProxyRequests Off >>>> ProxyPreserveHost On >>>> ProxyVia On >>>> >>>> ProxyPass /auth ajp://127.0.0.1:8009/auth >>>> ProxyPassReverse /auth ajp://127.0.0.1:8009/auth >>>> >>>> >>>> you should see something like that (forwared info is somewhat rubbish in this example as I am running the hosts on Virtualbox - but you can see this request was put through 2 proxies from local pc 192.168.33.1 to haproxy on 192.168.33.80 and then apache reverse proxy on 192.168.33.81 ): >>>> >>>> ============================================================== >>>> 23:47:20,563 INFO [io.undertow.request.dump] (default task-14) >>>> ----------------------------REQUEST--------------------------- >>>> URI=/auth/welcome-content/favicon.ico >>>> characterEncoding=null >>>> contentLength=-1 >>>> contentType=null >>>> header=Accept=*/* >>>> header=Accept-Language=en-US,en;q=0.8,de;q=0.6 >>>> header=Cache-Control=no-cache >>>> header=Accept-Encoding=gzip, deflate, sdch >>>> header=DNT=1 >>>> header=Pragma=no-cache >>>> header=X-Original-To=192.168.33.80 >>>> header=User-Agent=Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 >>>> header=Authorization=Basic bmljZSB0cnkgYnV0IGFtIG5vdCBmcm9tIHllc3RlcmRheQo= >>>> header=X-Forwarded-Proto=https >>>> header=X-Forwarded-Port=443 >>>> header=X-Forwarded-For=192.168.33.1 >>>> header=Referer= https://login.vagrant.dev/auth/ >>>> header=Host=login.vagrant.dev >>>> locale=[en_US, en, de] >>>> method=GET >>>> protocol=HTTP/1.1 >>>> queryString= >>>> remoteAddr=192.168.33.1:0 >>>> remoteHost=192.168.33.1 >>>> scheme=https >>>> host=login.vagrant.dev >>>> serverPort=443 >>>> --------------------------RESPONSE-------------------------- >>>> contentLength=627 >>>> contentType=application/octet-stream >>>> header=Cache-Control=max-age=2592000 >>>> header=X-Powered-By=Undertow/1 >>>> header=Server=WildFly/10 >>>> >>>> >>>> Hope this helps diagnosing your issue. Niels >>>> >>>> On Tue, May 24, 2016 at 1:20 AM, Aritz Maeztu < amaeztu at tesicnor.com > wrote: >>>> I'm using keycloak to securize some Spring based services (with the keycloak spring security adapter). The adapter creates a `/login` endpoint in each of the services which redirects to the keycloak login page and then redirects back to the service when authentication is done. I also have a proxy service which I want to publish in the 80 port and will take care of routing all the requests to each service. The proxy performs a plain FORWARD to the service, but the problem comes when I securize the service with the keycloak adapter. >>>> >>>> When I make a request, the adapter redirects to its login endpoint and then to the keycloak auth url. When keycloak sends the redirection, the url shown in the browser is the one from the service and not the one from the proxy. Do I have some choice to tell the adapter I want to redirect back to the first requested url? >>>> >>>> >>>> -- >>>> Aritz Maeztu Ota?o >>>> Departamento Desarrollo de Software >>>> >>>> Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra) >>>> Telf.: 948 21 40 40 >>>> Fax.: 948 21 40 41 >>>> >>>> Antes de imprimir este e-mail piense bien si es necesario hacerlo: El medioambiente es cosa de todos. >>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>> >>> >>> -- >>> Aritz Maeztu Ota?o >>> Departamento Desarrollo de Software >>> >>> Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra) >>> Telf.: 948 21 40 40 >>> Fax.: 948 21 40 41 >>> >>> Antes de imprimir este e-mail piense bien si es necesario hacerlo: El medioambiente es cosa de todos. >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> >> -- >> Aritz Maeztu Ota?o >> Departamento Desarrollo de Software >> >> Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra) >> Telf.: 948 21 40 40 >> Fax.: 948 21 40 41 >> >> Antes de imprimir este e-mail piense bien si es necesario hacerlo: El medioambiente es cosa de todos. >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> > > -- > Aritz Maeztu Ota?o > Departamento Desarrollo de Software > > Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra) > Telf.: 948 21 40 40 > Fax.: 948 21 40 41 > > Antes de imprimir este e-mail piense bien si es necesario hacerlo: El medioambiente es cosa de todos. > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/9fdd956f/attachment-0001.html From amaeztu at tesicnor.com Tue May 31 16:00:04 2016 From: amaeztu at tesicnor.com (Aritz Maeztu) Date: Tue, 31 May 2016 22:00:04 +0200 Subject: [keycloak-user] Fwd: Re: Redirection issue with proxy behind keycloak In-Reply-To: References: <03225e22-5a31-d3c5-4285-69e355e1950e@tesicnor.com> <5e1b50b9-b7d0-5b2e-b16c-4df98da6f485@tesicnor.com> <7a45ae5d-cf0f-a5d5-0ab5-1df8ee8aa9da@tesicnor.com> Message-ID: <895342cc-a03d-caff-ffa3-281cf9a25499@tesicnor.com> Hello Scott, I've got the spring security and tomcat keycloak adapters both as a project dependency for each service (as I'm running the services in Tomcat 8 embedded servers). Basically I want to base my security in Spring Security, that's why I chose this adapter over the Spring Boot adapter. As the behaviour states, a redirection is made first to the /sso/login endpoint, then other one to the keycloak authorization server. The question is, as a redirection is a mere instruction stated from the server to the browser, which chances do I have to send the original x-forwarded headers to the keycloak authorization server, so that it can make the redirection to the url requested at the very beginning (to the reverse proxy)? I could implement a playground scenario for you if you happen to require it. Many thanks 31/05/2016 20:14(e)an, Scott Rossillo igorleak idatzi zuen: > Hi Artiz, > > So just to be clear, which Keycloak adapter are you using? The Spring > Boot Adapter or the Spring Security Adapter? > > Scott Rossillo > Smartling | Senior Software Engineer > srossillo at smartling.com > >> On May 31, 2016, at 3:13 AM, Aritz Maeztu > > wrote: >> >> I've got some Spring Boot application instances with embeded Tomcat >> servlet containers. Tomcat has a similar system to Wildfly for >> request dumpering, that's what I have enabled for getting the trace >> below. In short words that's the behaviour I'm able to see: >> >> 1. Zuul Proxy (Spring Boot in Tomcat) -> Organization Service (8083 >> port) : A forward request where X-forwarded headers are included >> >> 2. Organization Service (localhost:8083) : Looks for a token and if >> it's not available, the keycloak adapter redirects to the /sso/login >> of the same service (Here the traceability from the proxy gets losts) >> >> 3. localhost:8083/sso/login: Redirects to the keycloak wildfly >> server, saving the requested url >> >> 4. Keycloak login: The user performs the authentication and the >> redirectUri is localhost:8083/sso/login. Later on, the login endpoint >> redirects the user to the url requested in point 2, not the first one >> from the proxy. >> >> I only have this problem when my organization service needs to verify >> the token (or a token doesn't exist) using the keycloak adapter. When >> the /sso/login endpoint is not requested, everything is working >> properly. Hope I've explained it well! >> >> >> 31/05/2016 7:15(e)an, Stian Thorgersen igorleak idatzi zuen: >>> Where is your app deployed? If it's on WildFly you can follow the >>> same steps used to configure reverse proxy for Keycloak Server to >>> configure WildFly. Check if getRequestURL returns the correct URL in >>> your app. >>> >>> On 30 May 2016 at 15:08, Aritz Maeztu>> >wrote: >>> >>> >>> >>> >>> -------- Birbidalitako mezua -------- >>> Gaia: Re: [keycloak-user] Redirection issue with proxy behind >>> keycloak >>> Data: Mon, 30 May 2016 13:28:21 +0200 >>> Nork: Aritz Maeztu >>> >>> Nori: stian at redhat.com >>> CC: Niels Bertram >>> , >>> keycloak-user >>> , Scott >>> Rossillo >>> >>> >>> >>> I've done all the traceability from the proxy server till the >>> login page is displayed: >>> >>> First step, /organization/organizations is requested, so the >>> proxy server knows it has to be forwarded to the 8083 port (the >>> one for the organization service). That's the first request >>> received by my application's Tomcat: >>> >>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 START >>> TIME =30-may-2016 13:01:18 >>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> requestURI=/organizations >>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> authType=null >>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> characterEncoding=UTF-8 >>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> contentLength=-1 >>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> contentType=null >>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> contextPath= >>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> header=accept-language=es-ES,es;q=0.8 >>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> header=x-forwarded-host=mies-057:8765 >>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> header=x-forwarded-prefix=/organization >>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> header=upgrade-insecure-requests=1 >>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> header=accept-encoding=gzip >>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> header=accept=text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 >>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> header=user-agent=Mozilla/5.0 (Windows NT 6.1; WOW64) >>> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 >>> Safari/537.36 >>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> header=netflix.nfhttpclient.version=1.0 >>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> header=x-netflix-httpclientname=organization >>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> header=host=mies-057:8083 >>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> header=connection=Keep-Alive >>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> locale=es_ES >>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 method=GET >>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> pathInfo=null >>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> protocol=HTTP/1.1 >>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> queryString=null >>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> remoteAddr=192.168.56.1 >>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> remoteHost=192.168.56.1 >>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> remoteUser=null >>> 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> requestedSessionId=null >>> 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 scheme=http >>> 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> serverName=mies-057 >>> 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> serverPort=8083 >>> 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> servletPath=/organizations >>> 2016-05-30 13:01:18.891 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> isSecure=false >>> 2016-05-30 13:01:18.891 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> ------------------=-------------------------------------------- >>> >>> Here x-forwarded-host is mies-057:8765 (the proxy server) and >>> x-forwarded-prefix is /organization. So the original request is >>> kept in the headers. Well, now my service (8083) tries to check >>> for authorization via the /sso/login endpoint from the keycloak >>> spring security adapter: >>> >>> 2016-05-30 13:01:18.892 DEBUG 18096 --- [nio-8083-exec-9] >>> o.k.a.s.management.HttpSessionManager : Session created: >>> CDCA7AD4439DE94BD0B3B5803DAA0752 >>> 2016-05-30 13:01:18.892 DEBUG 18096 --- [nio-8083-exec-9] >>> k.a.s.a.KeycloakAuthenticationEntryPoint : Redirecting to login >>> URI /sso/login >>> 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> ------------------=-------------------------------------------- >>> 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> authType=null >>> 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> contentType=null >>> 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> header=X-Content-Type-Options=nosniff >>> 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> header=X-XSS-Protection=1; mode=block >>> 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> header=Cache-Control=no-cache, no-store, max-age=0, must-revalidate >>> 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> header=Pragma=no-cache >>> 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> header=Expires=0 >>> 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> header=X-Frame-Options=DENY >>> 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> header=Set-Cookie=JSESSIONID=CDCA7AD4439DE94BD0B3B5803DAA0752; >>> Path=/; HttpOnly >>> 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> header=Location=http://mies-057:8083/sso/login >>> 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> remoteUser=null >>> 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 status=302 >>> 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 END >>> TIME =30-may-2016 13:01:18 >>> 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 >>> =============================================================== >>> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 START >>> TIME =30-may-2016 13:01:18 >>> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 >>> requestURI=/sso/login >>> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 >>> authType=null >>> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 >>> characterEncoding=UTF-8 >>> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 >>> contentLength=-1 >>> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 >>> contentType=null >>> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 >>> contextPath= >>> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 >>> cookie=JSESSIONID=CDCA7AD4439DE94BD0B3B5803DAA0752 >>> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 >>> header=host=mies-057:8083 >>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 >>> header=connection=keep-alive >>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 >>> header=accept=text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 >>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 >>> header=upgrade-insecure-requests=1 >>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 >>> header=user-agent=Mozilla/5.0 (Windows NT 6.1; WOW64) >>> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 >>> Safari/537.36 >>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 >>> header=accept-encoding=gzip, deflate, sdch >>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 >>> header=accept-language=es-ES,es;q=0.8 >>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 >>> header=cookie=JSESSIONID=CDCA7AD4439DE94BD0B3B5803DAA0752 >>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 >>> locale=es_ES >>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 method=GET >>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 >>> pathInfo=null >>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 >>> protocol=HTTP/1.1 >>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 >>> queryString=null >>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 >>> remoteAddr=192.168.56.1 >>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 >>> remoteHost=192.168.56.1 >>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 >>> remoteUser=null >>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 >>> requestedSessionId=CDCA7AD4439DE94BD0B3B5803DAA0752 >>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 >>> scheme=http >>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 >>> serverName=mies-057 >>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 >>> serverPort=8083 >>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 >>> servletPath=/sso/login >>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 >>> isSecure=false >>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] >>> o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 >>> ------------------=-------------------------------------------- >>> 2016-05-30 13:01:18.904 DEBUG 18096 --- [io-8083-exec-10] >>> o.k.adapters.PreAuthActionsHandler : >>> adminRequesthttp://mies-057:8083/sso/login >>> 2016-05-30 13:01:18.904 DEBUG 18096 --- [io-8083-exec-10] >>> f.KeycloakAuthenticationProcessingFilter : Request is to process >>> authentication >>> 2016-05-30 13:01:18.904 DEBUG 18096 --- [io-8083-exec-10] >>> f.KeycloakAuthenticationProcessingFilter : Attempting Keycloak >>> authentication >>> 2016-05-30 13:01:18.904 TRACE 18096 --- [io-8083-exec-10] >>> o.k.adapters.RequestAuthenticator : --> authenticate() >>> 2016-05-30 13:01:18.904 TRACE 18096 --- [io-8083-exec-10] >>> o.k.adapters.RequestAuthenticator : try bearer >>> 2016-05-30 13:01:18.904 TRACE 18096 --- [io-8083-exec-10] >>> o.k.adapters.RequestAuthenticator : try oauth >>> 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] >>> o.k.a.s.token.SpringSecurityTokenStore : Checking if >>> org.keycloak.adapters.springsecurity.authentication.SpringSecurityRequestAuthenticator at d328c2d >>> is cached >>> 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] >>> o.k.adapters.OAuthRequestAuthenticator : there was no code >>> 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] >>> o.k.adapters.OAuthRequestAuthenticator : redirecting to auth server >>> 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] >>> o.k.adapters.OAuthRequestAuthenticator : callback >>> uri:http://mies-057:8083/sso/login >>> 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] >>> f.KeycloakAuthenticationProcessingFilter : Auth outcome: >>> NOT_ATTEMPTED >>> 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] >>> o.k.adapters.OAuthRequestAuthenticator : Sending redirect to >>> login >>> page:http://mies-057.tesicnor.com:8080/auth/realms/master/protocol/openid-connect/auth?response_type=code&client_id=organization&redirect_uri=http%3A%2F%2Fmies-057%3A8083%2Fsso%2Flogin&state=1%2F21d709ec-1e69-41c5-ac6d-c705f8ce3907&login=true >>> >>> As it's shown in the logs, the X-forwarded logs are not kept by >>> the keycloak adapter (look at the lines >>> belowk.a.s.a.KeycloakAuthenticationEntryPoint : Redirecting to >>> login URI /sso/login). So could it be the proxy server itself >>> being properly configured but the keycloak adapter losing the >>> original headers while performing the redirection? >>> >>> I've also set up the request dumper in the undertow server as >>> Niels suggested, but obviously, X-forwarded headers are not >>> reaching the keycloak server.. >>> >>> Thanks for your time, again ;-) >>> >>> >>> >>> 25/05/2016 7:22(e)an, Stian Thorgersen igorleak idatzi zuen: >>>> You need the Host and X-Forwarded-For headers to be included >>>> and there's also some config to be done on the Keycloak server >>>> (see >>>> http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#proxy-address-forwarding) >>>> >>>> On 24 May 2016 at 08:46, Aritz Maeztuwrote: >>>> >>>> Hi Niels and Scott. First of all, thank you very much for >>>> your help. I'm currently using Zuul (Spring Cloud) as the >>>> reverse proxy. All the services are registered in a >>>> discovery service called Eureka and then Zuul looks for the >>>> service id there and performs de redirection. I read >>>> aboutX-Forwarded headers, but I thought it might result in >>>> a security issue if not included, not that it could affect >>>> the redirection process. >>>> >>>> As Scott says, I suppose the Host and the X-Real-Ip headers >>>> are the relevant ones here, so I guess I should instruct >>>> Zuul to send them when the service is addressed (however I >>>> wonder why they are not already being sent, as Zuul is a >>>> proxy service, all in all). >>>> >>>> Here I include a preview of the first redirection made to >>>> the keycloak login page, which shows the request headers >>>> sent to the service /login endpoint (at port 8081 in >>>> localhost): >>>> >>>> https://www.dropbox.com/s/iof9yefytzay6j2/screenshot.PNG?dl=0 >>>> >>>> 24/05/2016 2:08(e)an, Niels Bertram igorleak idatzi zuen: >>>>> Hi Artitz, >>>>> >>>>> a great way to figure out what is sent from the reverse >>>>> proxy to your keycloak server is to use the undertow >>>>> request dumper. >>>>> >>>>> From the jboss-cli just add the request dumper filter to >>>>> your undertow configuration like this: >>>>> >>>>> $KC_HOME/bin/jbpss-cli.sh -c >>>>> >>>>> /subsystem=undertow/configuration=filter/custom-filter=request-dumper:add(class-name=io.undertow.server.handlers.RequestDumpingHandler, >>>>> module=io.undertow.core) >>>>> >>>>> /subsystem=undertow/server=default-server/host=default-host/filter-ref=request-dumper:add >>>>> >>>>> /:reload >>>>> >>>>> given your apache config looks something like this: >>>>> >>>>> ProxyRequests Off >>>>> ProxyPreserveHost On >>>>> ProxyVia On >>>>> >>>>> ProxyPass /auth ajp://127.0.0.1:8009/auth >>>>> >>>>> ProxyPassReverse /auth ajp://127.0.0.1:8009/auth >>>>> >>>>> >>>>> >>>>> you should see something like that (forwared info is >>>>> somewhat rubbish in this example as I am running the hosts >>>>> on Virtualbox - but you can see this request was put >>>>> through 2 proxies from local pc 192.168.33.1 to haproxy on >>>>> 192.168.33.80 and then apache reverse proxy on >>>>> 192.168.33.81 ): >>>>> >>>>> ============================================================== >>>>> 23:47:20,563 INFO [io.undertow.request.dump] (default >>>>> task-14) >>>>> ----------------------------REQUEST--------------------------- >>>>> URI=/auth/welcome-content/favicon.ico >>>>> characterEncoding=null >>>>> contentLength=-1 >>>>> contentType=null >>>>> header=Accept=*/* >>>>> header=Accept-Language=en-US,en;q=0.8,de;q=0.6 >>>>> header=Cache-Control=no-cache >>>>> header=Accept-Encoding=gzip, deflate, sdch >>>>> header=DNT=1 >>>>> header=Pragma=no-cache >>>>> header=X-Original-To=192.168.33.80 >>>>> header=User-Agent=Mozilla/5.0 (Windows NT 6.1; WOW64) >>>>> AppleWebKit/537.36 (KHTML, like Gecko) >>>>> Chrome/50.0.2661.102 Safari/537.36 >>>>> header=Authorization=Basic >>>>> bmljZSB0cnkgYnV0IGFtIG5vdCBmcm9tIHllc3RlcmRheQo= >>>>> header=X-Forwarded-Proto=https >>>>> header=X-Forwarded-Port=443 >>>>> header=X-Forwarded-For=192.168.33.1 >>>>> header=Referer=https://login.vagrant.dev/auth/ >>>>> header=Host=login.vagrant.dev >>>>> locale=[en_US, en, de] >>>>> method=GET >>>>> protocol=HTTP/1.1 >>>>> queryString= >>>>> remoteAddr=192.168.33.1:0 >>>>> remoteHost=192.168.33.1 >>>>> scheme=https >>>>> host=login.vagrant.dev >>>>> serverPort=443 >>>>> --------------------------RESPONSE-------------------------- >>>>> contentLength=627 >>>>> contentType=application/octet-stream >>>>> header=Cache-Control=max-age=2592000 >>>>> header=X-Powered-By=Undertow/1 >>>>> header=Server=WildFly/10 >>>>> >>>>> >>>>> Hope this helps diagnosing your issue. Niels >>>>> >>>>> On Tue, May 24, 2016 at 1:20 AM, Aritz >>>>> Maeztuwrote: >>>>> >>>>> I'm using keycloak to securize some Spring based >>>>> services (with the keycloak spring security adapter). >>>>> The adapter creates a `/login` endpoint in each of the >>>>> services which redirects to the keycloak login page >>>>> and then redirects back to the service when >>>>> authentication is done. I also have a proxy service >>>>> which I want to publish in the 80 port and will take >>>>> care of routing all the requests to each service. The >>>>> proxy performs a plain FORWARD to the service, but the >>>>> problem comes when I securize the service with the >>>>> keycloak adapter. >>>>> >>>>> When I make a request, the adapter redirects to its >>>>> login endpoint and then to the keycloak auth url. When >>>>> keycloak sends the redirection, the url shown in the >>>>> browser is the one from the service and not the one >>>>> from the proxy. Do I have some choice to tell the >>>>> adapter I want to redirect back to the first requested >>>>> url? >>>>> >>>>> >>>>> -- >>>>> Aritz Maeztu Ota?o >>>>> Departamento Desarrollo de Software >>>> Attachment.gif> >>>>> >>>>> >>>>> >>>>> >>>>> Pol. Ind. Mocholi.C/Rio Elorz, Nave 13E31110 Noain >>>>> (Navarra) >>>>> Telf.: 948 21 40 40 >>>>> Fax.: 948 21 40 41 >>>>> >>>>> Antes de imprimir este e-mail piense bien si es >>>>> necesario hacerlo: El medioambiente es cosa de todos. >>>>> >>>>> >>>>> _______________________________________________ >>>>> keycloak-user mailing list >>>>> keycloak-user at lists.jboss.org >>>>> >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>>> >>>>> >>>> >>>> -- >>>> Aritz Maeztu Ota?o >>>> Departamento Desarrollo de Software >>>> >>>> >>>> >>>> >>>> Pol. Ind. Mocholi.C/Rio Elorz, Nave 13E31110 Noain (Navarra) >>>> Telf.: 948 21 40 40 >>>> Fax.: 948 21 40 41 >>>> >>>> Antes de imprimir este e-mail piense bien si es necesario >>>> hacerlo: El medioambiente es cosa de todos. >>>> >>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user at lists.jboss.org >>>> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>> >>>> >>> >>> -- >>> Aritz Maeztu Ota?o >>> Departamento Desarrollo de Software >>> >>> >>> >>> Pol. Ind. Mocholi.C/Rio Elorz, Nave 13E31110 Noain (Navarra) >>> Telf.: 948 21 40 40 >>> Fax.: 948 21 40 41 >>> >>> Antes de imprimir este e-mail piense bien si es necesario >>> hacerlo: El medioambiente es cosa de todos. >>> >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >>> >> >> -- >> Aritz Maeztu Ota?o >> Departamento Desarrollo de Software >> >> >> >> Pol. Ind. Mocholi.C/Rio Elorz, Nave 13E31110 Noain (Navarra) >> Telf.: 948 21 40 40 >> Fax.: 948 21 40 41 >> >> Antes de imprimir este e-mail piense bien si es necesario hacerlo: El >> medioambiente es cosa de todos. >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > --- El software de antivirus Avast ha analizado este correo electr?nico en busca de virus. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/dc9b64a4/attachment-0001.html From srossillo at smartling.com Tue May 31 16:56:55 2016 From: srossillo at smartling.com (Scott Rossillo) Date: Tue, 31 May 2016 16:56:55 -0400 Subject: [keycloak-user] Fwd: Re: Redirection issue with proxy behind keycloak In-Reply-To: <895342cc-a03d-caff-ffa3-281cf9a25499@tesicnor.com> References: <03225e22-5a31-d3c5-4285-69e355e1950e@tesicnor.com> <5e1b50b9-b7d0-5b2e-b16c-4df98da6f485@tesicnor.com> <7a45ae5d-cf0f-a5d5-0ab5-1df8ee8aa9da@tesicnor.com> <895342cc-a03d-caff-ffa3-281cf9a25499@tesicnor.com> Message-ID: <11921D36-82CD-4B90-8E65-4C3209D5DE52@smartling.com> Hi Artiz, If you?re using the Tomcat adapter and Spring Security adapter together, they may be interfering with each other. I?m not saying this is the problem you?re having but I?d avoid using both adapters together. Please also take a look at this Stack Overflow answer[0] related to redirect issues. If none of this helps I?ll try to debug with Eureka and Zuul. [0]: http://stackoverflow.com/questions/33543672/keycloak-redirects-me-to-my-index-url-instead-of-to-the-requested-one?answertab=votes#tab-top Scott Rossillo Smartling | Senior Software Engineer srossillo at smartling.com > On May 31, 2016, at 4:00 PM, Aritz Maeztu wrote: > > Hello Scott, > > I've got the spring security and tomcat keycloak adapters both as a project dependency for each service (as I'm running the services in Tomcat 8 embedded servers). Basically I want to base my security in Spring Security, that's why I chose this adapter over the Spring Boot adapter. > > As the behaviour states, a redirection is made first to the /sso/login endpoint, then other one to the keycloak authorization server. The question is, as a redirection is a mere instruction stated from the server to the browser, which chances do I have to send the original x-forwarded headers to the keycloak authorization server, so that it can make the redirection to the url requested at the very beginning (to the reverse proxy)? > > I could implement a playground scenario for you if you happen to require it. > > Many thanks > > 31/05/2016 20:14(e)an, Scott Rossillo igorleak idatzi zuen: >> Hi Artiz, >> >> So just to be clear, which Keycloak adapter are you using? The Spring Boot Adapter or the Spring Security Adapter? >> >> Scott Rossillo >> Smartling | Senior Software Engineer >> srossillo at smartling.com >> >>> On May 31, 2016, at 3:13 AM, Aritz Maeztu < amaeztu at tesicnor.com > wrote: >>> >>> I've got some Spring Boot application instances with embeded Tomcat servlet containers. Tomcat has a similar system to Wildfly for request dumpering, that's what I have enabled for getting the trace below. In short words that's the behaviour I'm able to see: >>> 1. Zuul Proxy (Spring Boot in Tomcat) -> Organization Service (8083 port) : A forward request where X-forwarded headers are included >>> >>> 2. Organization Service (localhost:8083) : Looks for a token and if it's not available, the keycloak adapter redirects to the /sso/login of the same service (Here the traceability from the proxy gets losts) >>> >>> 3. localhost:8083/sso/login: Redirects to the keycloak wildfly server, saving the requested url >>> 4. Keycloak login: The user performs the authentication and the redirectUri is localhost:8083/sso/login. Later on, the login endpoint redirects the user to the url requested in point 2, not the first one from the proxy. >>> >>> I only have this problem when my organization service needs to verify the token (or a token doesn't exist) using the keycloak adapter. When the /sso/login endpoint is not requested, everything is working properly. Hope I've explained it well! >>> >>> 31/05/2016 7:15(e)an, Stian Thorgersen igorleak idatzi zuen: >>>> Where is your app deployed? If it's on WildFly you can follow the same steps used to configure reverse proxy for Keycloak Server to configure WildFly. Check if getRequestURL returns the correct URL in your app. >>>> >>>> On 30 May 2016 at 15:08, Aritz Maeztu > wrote: >>>> >>>> >>>> >>>> -------- Birbidalitako mezua -------- >>>> Gaia: Re: [keycloak-user] Redirection issue with proxy behind keycloak >>>> Data: Mon, 30 May 2016 13:28:21 +0200 >>>> Nork: Aritz Maeztu >>>> Nori: stian at redhat.com >>>> CC: Niels Bertram , keycloak-user , Scott Rossillo >>>> >>>> >>>> I've done all the traceability from the proxy server till the login page is displayed: >>>> >>>> First step, /organization/organizations is requested, so the proxy server knows it has to be forwarded to the 8083 port (the one for the organization service). That's the first request received by my application's Tomcat: >>>> >>>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 START TIME =30-may-2016 13:01:18 >>>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 requestURI=/organizations >>>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 authType=null >>>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 characterEncoding=UTF-8 >>>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 contentLength=-1 >>>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 contentType=null >>>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 contextPath= >>>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=accept-language=es-ES,es;q=0.8 >>>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=x-forwarded-host=mies-057:8765 >>>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=x-forwarded-prefix=/organization >>>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=upgrade-insecure-requests=1 >>>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=accept-encoding=gzip >>>> 2016-05-30 13:01:18.888 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=accept=text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 >>>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=user-agent=Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 >>>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=netflix.nfhttpclient.version=1.0 >>>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=x-netflix-httpclientname=organization >>>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=host=mies-057:8083 >>>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=connection=Keep-Alive >>>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 locale=es_ES >>>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 method=GET >>>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 pathInfo=null >>>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 protocol=HTTP/1.1 >>>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 queryString=null >>>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 remoteAddr=192.168.56.1 >>>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 remoteHost=192.168.56.1 >>>> 2016-05-30 13:01:18.889 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 remoteUser=null >>>> 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 requestedSessionId=null >>>> 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 scheme=http >>>> 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 serverName=mies-057 >>>> 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 serverPort=8083 >>>> 2016-05-30 13:01:18.890 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 servletPath=/organizations >>>> 2016-05-30 13:01:18.891 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 isSecure=false >>>> 2016-05-30 13:01:18.891 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 ------------------=-------------------------------------------- >>>> >>>> Here x-forwarded-host is mies-057:8765 (the proxy server) and x-forwarded-prefix is /organization. So the original request is kept in the headers. Well, now my service (8083) tries to check for authorization via the /sso/login endpoint from the keycloak spring security adapter: >>>> 2016-05-30 13:01:18.892 DEBUG 18096 --- [nio-8083-exec-9] o.k.a.s.management.HttpSessionManager : Session created: CDCA7AD4439DE94BD0B3B5803DAA0752 >>>> 2016-05-30 13:01:18.892 DEBUG 18096 --- [nio-8083-exec-9] k.a.s.a.KeycloakAuthenticationEntryPoint : Redirecting to login URI /sso/login >>>> 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 ------------------=-------------------------------------------- >>>> 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 authType=null >>>> 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 contentType=null >>>> 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=X-Content-Type-Options=nosniff >>>> 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=X-XSS-Protection=1; mode=block >>>> 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=Cache-Control=no-cache, no-store, max-age=0, must-revalidate >>>> 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=Pragma=no-cache >>>> 2016-05-30 13:01:18.892 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=Expires=0 >>>> 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=X-Frame-Options=DENY >>>> 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=Set-Cookie=JSESSIONID=CDCA7AD4439DE94BD0B3B5803DAA0752; Path=/; HttpOnly >>>> 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 header=Location= http://mies-057:8083/sso/login >>>> 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 remoteUser=null >>>> 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 status=302 >>>> 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 END TIME =30-may-2016 13:01:18 >>>> 2016-05-30 13:01:18.893 INFO 18096 --- [nio-8083-exec-9] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-9 =============================================================== >>>> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 START TIME =30-may-2016 13:01:18 >>>> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 requestURI=/sso/login >>>> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 authType=null >>>> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 characterEncoding=UTF-8 >>>> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 contentLength=-1 >>>> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 contentType=null >>>> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 contextPath= >>>> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 cookie=JSESSIONID=CDCA7AD4439DE94BD0B3B5803DAA0752 >>>> 2016-05-30 13:01:18.902 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 header=host=mies-057:8083 >>>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 header=connection=keep-alive >>>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 header=accept=text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 >>>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 header=upgrade-insecure-requests=1 >>>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 header=user-agent=Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 >>>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 header=accept-encoding=gzip, deflate, sdch >>>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 header=accept-language=es-ES,es;q=0.8 >>>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 header=cookie=JSESSIONID=CDCA7AD4439DE94BD0B3B5803DAA0752 >>>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 locale=es_ES >>>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 method=GET >>>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 pathInfo=null >>>> 2016-05-30 13:01:18.903 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 protocol=HTTP/1.1 >>>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 queryString=null >>>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 remoteAddr=192.168.56.1 >>>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 remoteHost=192.168.56.1 >>>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 remoteUser=null >>>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 requestedSessionId=CDCA7AD4439DE94BD0B3B5803DAA0752 >>>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 scheme=http >>>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 serverName=mies-057 >>>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 serverPort=8083 >>>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 servletPath=/sso/login >>>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 isSecure=false >>>> 2016-05-30 13:01:18.904 INFO 18096 --- [io-8083-exec-10] o.a.c.filters.RequestDumperFilter : http-nio-8083-exec-10 ------------------=-------------------------------------------- >>>> 2016-05-30 13:01:18.904 DEBUG 18096 --- [io-8083-exec-10] o.k.adapters.PreAuthActionsHandler : adminRequest http://mies-057:8083/sso/login >>>> 2016-05-30 13:01:18.904 DEBUG 18096 --- [io-8083-exec-10] f.KeycloakAuthenticationProcessingFilter : Request is to process authentication >>>> 2016-05-30 13:01:18.904 DEBUG 18096 --- [io-8083-exec-10] f.KeycloakAuthenticationProcessingFilter : Attempting Keycloak authentication >>>> 2016-05-30 13:01:18.904 TRACE 18096 --- [io-8083-exec-10] o.k.adapters.RequestAuthenticator : --> authenticate() >>>> 2016-05-30 13:01:18.904 TRACE 18096 --- [io-8083-exec-10] o.k.adapters.RequestAuthenticator : try bearer >>>> 2016-05-30 13:01:18.904 TRACE 18096 --- [io-8083-exec-10] o.k.adapters.RequestAuthenticator : try oauth >>>> 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] o.k.a.s.token.SpringSecurityTokenStore : Checking if org.keycloak.adapters.springsecurity.authentication.SpringSecurityRequestAuthenticator at d328c2d is cached >>>> 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] o.k.adapters.OAuthRequestAuthenticator : there was no code >>>> 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] o.k.adapters.OAuthRequestAuthenticator : redirecting to auth server >>>> 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] o.k.adapters.OAuthRequestAuthenticator : callback uri: http://mies-057:8083/sso/login >>>> 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] f.KeycloakAuthenticationProcessingFilter : Auth outcome: NOT_ATTEMPTED >>>> 2016-05-30 13:01:18.905 DEBUG 18096 --- [io-8083-exec-10] o.k.adapters.OAuthRequestAuthenticator : Sending redirect to login page: http://mies-057.tesicnor.com:8080/auth/realms/master/protocol/openid-connect/auth?response_type=code&client_id=organization&redirect_uri=http%3A%2F%2Fmies-057%3A8083%2Fsso%2Flogin&state=1%2F21d709ec-1e69-41c5-ac6d-c705f8ce3907&login=true >>>> As it's shown in the logs, the X-forwarded logs are not kept by the keycloak adapter (look at the lines below k.a.s.a.KeycloakAuthenticationEntryPoint : Redirecting to login URI /sso/login). So could it be the proxy server itself being properly configured but the keycloak adapter losing the original headers while performing the redirection? >>>> >>>> I've also set up the request dumper in the undertow server as Niels suggested, but obviously, X-forwarded headers are not reaching the keycloak server.. >>>> >>>> Thanks for your time, again ;-) >>>> >>>> >>>> 25/05/2016 7:22(e)an, Stian Thorgersen igorleak idatzi zuen: >>>>> You need the Host and X-Forwarded-For headers to be included and there's also some config to be done on the Keycloak server (see http://keycloak.github.io/docs/userguide/keycloak-server/html/server-installation.html#proxy-address-forwarding ) >>>>> >>>>> On 24 May 2016 at 08:46, Aritz Maeztu < amaeztu at tesicnor.com > wrote: >>>>> Hi Niels and Scott. First of all, thank you very much for your help. I'm currently using Zuul (Spring Cloud) as the reverse proxy. All the services are registered in a discovery service called Eureka and then Zuul looks for the service id there and performs de redirection. I read about X-Forwarded headers, but I thought it might result in a security issue if not included, not that it could affect the redirection process. >>>>> >>>>> As Scott says, I suppose the Host and the X-Real-Ip headers are the relevant ones here, so I guess I should instruct Zuul to send them when the service is addressed (however I wonder why they are not already being sent, as Zuul is a proxy service, all in all). >>>>> >>>>> Here I include a preview of the first redirection made to the keycloak login page, which shows the request headers sent to the service /login endpoint (at port 8081 in localhost): >>>>> >>>>> https://www.dropbox.com/s/iof9yefytzay6j2/screenshot.PNG?dl=0 >>>>> >>>>> 24/05/2016 2:08(e)an, Niels Bertram igorleak idatzi zuen: >>>>>> Hi Artitz, >>>>>> >>>>>> a great way to figure out what is sent from the reverse proxy to your keycloak server is to use the undertow request dumper. >>>>>> >>>>>> From the jboss-cli just add the request dumper filter to your undertow configuration like this: >>>>>> >>>>>> $KC_HOME/bin/jbpss-cli.sh -c >>>>>> >>>>>> /subsystem=undertow/configuration=filter/custom-filter=request-dumper:add(class-name=io.undertow.server.handlers.RequestDumpingHandler, module=io.undertow.core) >>>>>> >>>>>> /subsystem=undertow/server=default-server/host=default-host/filter-ref=request-dumper:add >>>>>> >>>>>> /:reload >>>>>> >>>>>> given your apache config looks something like this: >>>>>> >>>>>> ProxyRequests Off >>>>>> ProxyPreserveHost On >>>>>> ProxyVia On >>>>>> >>>>>> ProxyPass /auth ajp://127.0.0.1:8009/auth >>>>>> ProxyPassReverse /auth ajp://127.0.0.1:8009/auth >>>>>> >>>>>> >>>>>> you should see something like that (forwared info is somewhat rubbish in this example as I am running the hosts on Virtualbox - but you can see this request was put through 2 proxies from local pc 192.168.33.1 to haproxy on 192.168.33.80 and then apache reverse proxy on 192.168.33.81 ): >>>>>> >>>>>> ============================================================== >>>>>> 23:47:20,563 INFO [io.undertow.request.dump] (default task-14) >>>>>> ----------------------------REQUEST--------------------------- >>>>>> URI=/auth/welcome-content/favicon.ico >>>>>> characterEncoding=null >>>>>> contentLength=-1 >>>>>> contentType=null >>>>>> header=Accept=*/* >>>>>> header=Accept-Language=en-US,en;q=0.8,de;q=0.6 >>>>>> header=Cache-Control=no-cache >>>>>> header=Accept-Encoding=gzip, deflate, sdch >>>>>> header=DNT=1 >>>>>> header=Pragma=no-cache >>>>>> header=X-Original-To=192.168.33.80 >>>>>> header=User-Agent=Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 >>>>>> header=Authorization=Basic bmljZSB0cnkgYnV0IGFtIG5vdCBmcm9tIHllc3RlcmRheQo= >>>>>> header=X-Forwarded-Proto=https >>>>>> header=X-Forwarded-Port=443 >>>>>> header=X-Forwarded-For=192.168.33.1 >>>>>> header=Referer= https://login.vagrant.dev/auth/ >>>>>> header=Host=login.vagrant.dev >>>>>> locale=[en_US, en, de] >>>>>> method=GET >>>>>> protocol=HTTP/1.1 >>>>>> queryString= >>>>>> remoteAddr=192.168.33.1:0 >>>>>> remoteHost=192.168.33.1 >>>>>> scheme=https >>>>>> host=login.vagrant.dev >>>>>> serverPort=443 >>>>>> --------------------------RESPONSE-------------------------- >>>>>> contentLength=627 >>>>>> contentType=application/octet-stream >>>>>> header=Cache-Control=max-age=2592000 >>>>>> header=X-Powered-By=Undertow/1 >>>>>> header=Server=WildFly/10 >>>>>> >>>>>> >>>>>> Hope this helps diagnosing your issue. Niels >>>>>> >>>>>> On Tue, May 24, 2016 at 1:20 AM, Aritz Maeztu < amaeztu at tesicnor.com > wrote: >>>>>> I'm using keycloak to securize some Spring based services (with the keycloak spring security adapter). The adapter creates a `/login` endpoint in each of the services which redirects to the keycloak login page and then redirects back to the service when authentication is done. I also have a proxy service which I want to publish in the 80 port and will take care of routing all the requests to each service. The proxy performs a plain FORWARD to the service, but the problem comes when I securize the service with the keycloak adapter. >>>>>> When I make a request, the adapter redirects to its login endpoint and then to the keycloak auth url. When keycloak sends the redirection, the url shown in the browser is the one from the service and not the one from the proxy. Do I have some choice to tell the adapter I want to redirect back to the first requested url? >>>>>> >>>>>> >>>>>> -- >>>>>> Aritz Maeztu Ota?o >>>>>> Departamento Desarrollo de Software >>>>>> >>>>>> Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra) >>>>>> Telf.: 948 21 40 40 >>>>>> Fax.: 948 21 40 41 >>>>>> Antes de imprimir este e-mail piense bien si es necesario hacerlo: El medioambiente es cosa de todos. >>>>>> >>>>>> _______________________________________________ >>>>>> keycloak-user mailing list >>>>>> keycloak-user at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>>>> >>>>> >>>>> -- >>>>> Aritz Maeztu Ota?o >>>>> Departamento Desarrollo de Software >>>>> >>>>> Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra) >>>>> Telf.: 948 21 40 40 >>>>> Fax.: 948 21 40 41 >>>>> Antes de imprimir este e-mail piense bien si es necesario hacerlo: El medioambiente es cosa de todos. >>>>> _______________________________________________ >>>>> keycloak-user mailing list >>>>> keycloak-user at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>>> >>>> >>>> -- >>>> Aritz Maeztu Ota?o >>>> Departamento Desarrollo de Software >>>> >>>> Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra) >>>> Telf.: 948 21 40 40 >>>> Fax.: 948 21 40 41 >>>> Antes de imprimir este e-mail piense bien si es necesario hacerlo: El medioambiente es cosa de todos. >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>> >>> >>> -- >>> Aritz Maeztu Ota?o >>> Departamento Desarrollo de Software >>> >>> Pol. Ind. Mocholi. C/Rio Elorz, Nave 13E 31110 Noain (Navarra) >>> Telf.: 948 21 40 40 >>> Fax.: 948 21 40 41 >>> Antes de imprimir este e-mail piense bien si es necesario hacerlo: El medioambiente es cosa de todos._______________________________________________ >>> keycloak-user mailing list >>> keycloak-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > El software de antivirus Avast ha analizado este correo electr?nico en busca de virus. > www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/2ce9673f/attachment-0001.html From mike.love at symbiotics.co.za Tue May 31 21:19:40 2016 From: mike.love at symbiotics.co.za (Mike Love) Date: Wed, 1 Jun 2016 03:19:40 +0200 Subject: [keycloak-user] Keycloak integration with REST service Message-ID: Hi Jim, I would suggest that you achieve this integration using a custom User Federation Provider. You would need to implement UserFederationProviderFactory & UserFederationProvider I have an outstanding blog to write re implementing a custom user federation provider. If you need additional assistance, let me know and I will try to prioritise this Regards, Mike -- www.symbiotics.co.za ******************************************************************************** This email and any accompanying attachments may contain confidential and proprietary information. This information is private and protected by law and, accordingly, if you are not the intended recipient, you are requested to delete this entire communication immediately and are notified that any disclosure, copying or distribution of or taking any action based on this information is prohibited. Emails cannot be guaranteed to be secure or free of errors or viruses. The sender does not accept any liability or responsibility for any interception, corruption, destruction, loss, late arrival or incompleteness of or tampering or interference with any of the information contained in this email or for its incorrect delivery or non-delivery for whatsoever reason or for its effect on any electronic device of the recipient. ******************************************************************************** From jdillon at redhat.com Tue May 31 21:20:51 2016 From: jdillon at redhat.com (Jim Dillon) Date: Tue, 31 May 2016 21:20:51 -0400 Subject: [keycloak-user] Keycloak integration with REST service Message-ID: It looks like a custom User Federation Provider in needs to be created in order to access a REST Service for user information and an Authentication Provider to authenticate against a REST Service. I've looked at the example User Federation Provider that uses a static file and the Authentication Provider examples which enforce secret question / answer flow. I have a better understanding of what needs to be accomplished, but I'm still quite a ways from where I need to be. Can anyone point me in the direction of an example User Federation Provider and / or an Authentication Provider that uses a REST Service? (Google hasn't found any examples for me.) Is there more documentation to be found on these subjects other than the inline code comments, User Manual, and github based docs? Could I possibly be making it more difficult than it is, do I simply need to substitute http requests for file i/o in the User Federation Provider example? The Flow (as I understand it, please confirm / correct as needed): 1. User lands on Keycloak login page and initiates login 2. User does not exist in Keycloak 3. REST API is asked to authenticate via Authentication Provider SPI 4. User is authenticated 5. REST API is asked for user information to create user in Keycloak (part of this process would need to decrypt the existing password and then encrypt it using Keycloak's "default" method.) 6. User is created in Keycloak and any further authentication / authorization logic will remain "in house" Thank you for your time, jim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160531/637ae7b9/attachment.html From thomas.darimont at googlemail.com Tue May 31 23:55:46 2016 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Wed, 1 Jun 2016 05:55:46 +0200 Subject: [keycloak-user] Keycloak integration with REST service In-Reply-To: References: Message-ID: Hi Jim, take a look at this https://github.com/Smartling/keycloak-user-migration-provider/blob/master/README.md And this https://tech.smartling.com/migrate-to-keycloak-with-zero-downtime-8dcab9e7cb2c#.xlbmubrto Cheers, Thomas Am 01.06.2016 3:20 vorm. schrieb "Mike Love" : > Hi Jim, > > I would suggest that you achieve this integration using a custom User > Federation Provider. > > You would need to implement UserFederationProviderFactory & > UserFederationProvider > > I have an outstanding blog to write re implementing a custom user > federation provider. > If you need additional assistance, let me know and I will try to > prioritise this > > > Regards, > Mike > > > > -- > > > www.symbiotics.co.za > > ******************************************************************************** > This email and any accompanying attachments may contain confidential and > proprietary information. This information is private and protected by law > and, accordingly, if you are not the intended recipient, you are requested > to delete this entire communication immediately and are notified that any > disclosure, copying or distribution of or taking any action based on this > information is prohibited. > > Emails cannot be guaranteed to be secure or free of errors or viruses. The > sender does not accept any liability or responsibility for any > interception, corruption, destruction, loss, late arrival or incompleteness > of or tampering or interference with any of the information contained in > this email or for its incorrect delivery or non-delivery for whatsoever > reason or for its effect on any electronic device of the recipient. > > > ******************************************************************************** > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160601/8f885d96/attachment.html