From iain.clarke at empala.com Fri Jun 1 02:21:30 2018 From: iain.clarke at empala.com (iain.clarke at empala.com) Date: Thu, 31 May 2018 23:21:30 -0700 Subject: [keycloak-dev] Looking for implementation assistance In-Reply-To: <041f01d3f970$21c37f70$654a7e50$@empala.com> References: <041f01d3f970$21c37f70$654a7e50$@empala.com> Message-ID: <042a01d3f970$c8ddd170$5a997450$@empala.com> We need help! We are creating a new Node.JS platform and looking to use Keycloak. We have a POC up and running, but I'm looking for an implementation specialist who can help with fixing some connection issues and help install a clustered 'Prod ready' install, with the correct config. Installing in Amazon ECS Containers preferred. Is there a list somewhere of approved partners/implementors who we can create an opportunity together? Thanks, Iain From pdrozd at redhat.com Fri Jun 1 04:33:01 2018 From: pdrozd at redhat.com (Pavel Drozd) Date: Fri, 1 Jun 2018 10:33:01 +0200 Subject: [keycloak-dev] Testing with mocking libraries? In-Reply-To: <84bfae42-15d7-439e-ed41-e40d87a8bb7c@redhat.com> References: <84bfae42-15d7-439e-ed41-e40d87a8bb7c@redhat.com> Message-ID: <5B1104BD.6060804@redhat.com> I don't like mocks for many reasons, but this PR seems to me reasonable. It's hard to setup and test the social IDPs in general. But if we allow using mocks I have same concern as Marek, I'm afraid that the mocks will be used everywhere. If we will be able to limit mocks usage for specific areas like social logins, it's acceptable for me. Pavel Dne 31.5.2018 v 08:38 Marek Posolda napsal(a): > Not sure. I am not strongly against it, but I afraid that if we > introduce some mocks support, people (especially from community) will > start to test with mocks everywhere and add them to all PRs (even to > those which could be easily tested properly). Not sure if it's better > alternative to skip automated test at all instead of test with mocks? > > But for this one, I guess we can likely extend our social test with an > account from hosted domain and hence test it properly? > > Marek > > > On 30/05/18 09:19, Stian Thorgersen wrote: >> At the moment our testing strategy is only with functional or integration >> level tests. Both with the full server up and running and primarily testing >> through public APIs. >> >> Now here comes the question should we also allow testing through a mocking >> library like Mockito? >> >> In general I'm against mocking libraries. At best you end up with something >> that may work, but you're not guaranteed that it actually works. They also >> have a very big maintenance cost when any changes are made to the codebase. >> >> However, take a look at https://github.com/keycloak/keycloak/pull/5215 for >> example. It is a contribution to add support for the hd param to the Google >> login. Not sure how else we could test this without a mocking library. >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From vramik at redhat.com Fri Jun 1 04:53:11 2018 From: vramik at redhat.com (Vlasta Ramik) Date: Fri, 1 Jun 2018 10:53:11 +0200 Subject: [keycloak-dev] Testing with mocking libraries? In-Reply-To: <5B1104BD.6060804@redhat.com> References: <84bfae42-15d7-439e-ed41-e40d87a8bb7c@redhat.com> <5B1104BD.6060804@redhat.com> Message-ID: <0f1186da-cf07-cead-f25c-fb4a97518e21@redhat.com> +1 On 06/01/2018 10:33 AM, Pavel Drozd wrote: > I don't like mocks for many reasons, but this PR seems to me reasonable. > It's hard to setup and test the social IDPs in general. But if we allow > using mocks I have same concern as Marek, I'm afraid that the mocks will > be used everywhere. > > If we will be able to limit mocks usage for specific areas like social > logins, it's acceptable for me. > > Pavel > > Dne 31.5.2018 v 08:38 Marek Posolda napsal(a): >> Not sure. I am not strongly against it, but I afraid that if we >> introduce some mocks support, people (especially from community) will >> start to test with mocks everywhere and add them to all PRs (even to >> those which could be easily tested properly). Not sure if it's better >> alternative to skip automated test at all instead of test with mocks? >> >> But for this one, I guess we can likely extend our social test with an >> account from hosted domain and hence test it properly? >> >> Marek >> >> >> On 30/05/18 09:19, Stian Thorgersen wrote: >>> At the moment our testing strategy is only with functional or integration >>> level tests. Both with the full server up and running and primarily testing >>> through public APIs. >>> >>> Now here comes the question should we also allow testing through a mocking >>> library like Mockito? >>> >>> In general I'm against mocking libraries. At best you end up with something >>> that may work, but you're not guaranteed that it actually works. They also >>> have a very big maintenance cost when any changes are made to the codebase. >>> >>> However, take a look at https://github.com/keycloak/keycloak/pull/5215 for >>> example. It is a contribution to add support for the hd param to the Google >>> login. Not sure how else we could test this without a mocking library. >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Fri Jun 1 05:18:40 2018 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 1 Jun 2018 11:18:40 +0200 Subject: [keycloak-dev] Testing with mocking libraries? In-Reply-To: References: <84bfae42-15d7-439e-ed41-e40d87a8bb7c@redhat.com> Message-ID: <3b8d21e0-7897-ddee-c8b6-34c742d9a512@redhat.com> For IDP, I am not sure how would Mocked IDP help? We already have lots of test coverage for Identity brokering for OIDC and SAML. The social providers usually implements OAuth/OIDC and there are just small differences between them. But those small differences and the fact that social providers are out of our control, is exactly the reason why we need to test with real providers instead of mocks IMO. For example Facebook can do some backwards incompatible change (EG. require new parameter in their login flow), which will break the social login with Facebook. And if we test with mock instead of real facebook, we won't detect it. For this PR, Google can also decide to change the semantics of "hd" and send different value of it (or stop sending "hd" at all) and we won't detect it if we test it with mocks. Marek Dne 31.5.2018 v 21:46 Anil Saldanha napsal(a): > Agree. I had forgotten about Arquillian. > > On May 31, 2018, at 2:09 PM, Stian Thorgersen > wrote: > >> >> >> On 31 May 2018 at 20:48, Anil Saldanha > > wrote: >> >> You need both sets of testing to maintain the long term quality >> of a security project like Keycloak. :-) >> >> >> By using Arquillian we are actually able to test Keycloak very >> extensively without the need for Mocking through functional testing. >> I would suggest you review how extensive coverage we already have >> completely without any use of mocking and almost no basic unit >> testing at all. >> >> The problem I see is really only down to the difficulty of writing >> integration testing in some cases, especially when there are many >> configuration options. That's where it may be useful to mock the >> system being integrated with, but through mocking http calls, not >> Java method calls. >> >> >> I agree on the mocked IDP approach being more effective. >> >> On Thu, May 31, 2018 at 1:20 PM, Stian Thorgersen >> > wrote: >> >> With regards to Identity Brokering and Social Login one >> potentially better way to do it would be to have a mocked >> IdP. At least then you are testing the actual HTTP calls and >> it's much closer to a real scenario than doing junit tests >> with mocks and only testing parts of the code base. >> >> On 31 May 2018 at 18:08, Anil Saldanha >> > wrote: >> >> I am sorry I have not looked at your integration tests.? >> So I may be wrong here. >> >> One area that I feel that you need lots of integration >> tests is in the "Identity Brokering" feature.? You have >> way too many permutations and combinations (with >> authentication flows) that without proper integration >> tests/mocks, you will not do proper justice to the value >> of KC/RH-SSO. >> >> On Thu, May 31, 2018 at 10:17 AM, Bill Burke >> > wrote: >> >> Never liked mocks either as they are just opinionated >> warped >> perceptions of reality. ?But there are cases where I >> think we need >> them off the top of my head: >> >> * Openshift integration >> * Social logins. >> >> Openshift we just won't have the infrastructure for >> it.? Social login >> tests require accounts which we won't want to share >> the logins for in >> a public CI.? We need something in public CI so that >> we can catch at >> least some potential problems and that we can easily >> try to reproduce >> in local IDE environments.? Mocks wouldn't be a >> replacement for real >> integration testing, just a stop gap. >> >> >> >> On Thu, May 31, 2018 at 10:44 AM, Anil Saldanha >> > > wrote: >> > You really have to test your core logic (with no >> server set up) using >> > integration tests with mocking libraries. One way >> to test out all the >> > possible preconditions to your logic. >> > >> > You will be doing a service to your customers and >> users by shielding them >> > from those nasty exceptions (NPEs) that happen in >> an integration platform >> > such as KeyCloak/RH-SSO. :-) >> > >> > /me wearing a user/customer hat >> > >> > On Thu, May 31, 2018 at 1:38 AM, Marek Posolda >> > wrote: >> > >> >> Not sure. I am not strongly against it, but I >> afraid that if we >> >> introduce some mocks support, people (especially >> from community) will >> >> start to test with mocks everywhere and add them >> to all PRs (even to >> >> those which could be easily tested properly). Not >> sure if it's better >> >> alternative to skip automated test at all instead >> of test with mocks? >> >> >> >> But for this one, I guess we can likely extend our >> social test with an >> >> account from hosted domain and hence test it properly? >> >> >> >> Marek >> >> >> >> >> >> On 30/05/18 09:19, Stian Thorgersen wrote: >> >> > At the moment our testing strategy is only with >> functional or integration >> >> > level tests. Both with the full server up and >> running and primarily >> >> testing >> >> > through public APIs. >> >> > >> >> > Now here comes the question should we also allow >> testing through a >> >> mocking >> >> > library like Mockito? >> >> > >> >> > In general I'm against mocking libraries. At >> best you end up with >> >> something >> >> > that may work, but you're not guaranteed that it >> actually works. They >> >> also >> >> > have a very big maintenance cost when any >> changes are made to the >> >> codebase. >> >> > >> >> > However, take a look at >> https://github.com/keycloak/keycloak/pull/5215 >> >> >> for >> >> > example. It is a contribution to add support for >> the hd param to the >> >> Google >> >> > login. Not sure how else we could test this >> without a mocking library. >> >> > _______________________________________________ >> >> > keycloak-dev mailing list >> >> > keycloak-dev at lists.jboss.org >> >> >> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> >> >> >> _______________________________________________ >> >> keycloak-dev mailing list >> >> keycloak-dev at lists.jboss.org >> >> >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> > _______________________________________________ >> > keycloak-dev mailing list >> > keycloak-dev at lists.jboss.org >> >> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> >> -- >> Bill Burke >> Red Hat >> >> >> >> >> From sthorger at redhat.com Fri Jun 1 06:21:13 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 1 Jun 2018 12:21:13 +0200 Subject: [keycloak-dev] Keycloak Feature development: Integrate ext. IdP to keycloak (like Google, facebook) In-Reply-To: <404712E7-238F-464F-9D51-2D9534087736@syntlogo.de> References: <404712E7-238F-464F-9D51-2D9534087736@syntlogo.de> Message-ID: I very much doubt, but haven't checked thoroughly, that there would be a need to obtain any permission from Amazon to permit login with Amazon. It's a public service they offer. With regards to implementation. The implementation is fairly straightforward. What can be more work is documentation and testing. For a contribution we would require both the code as well as documentation update on how to configure on Amazon side as well as proper integration tests added to SocialLoginTest. We also need to be able to register (for free) a user account that we can use to run SocialLoginTest in our CI. You would have to extend the SocialLoginTest, but we can create the account once the PR is ready, but please confirm if Amazon would enable us to create a suitable account to use for testing. On 1 June 2018 at 03:57, Ansari, Hasebullah wrote: > Hello all, > > My name is Haseb Ansari and by profession I?m an IT > Specialist / Java Developer working for a German based company called > Syntlogo GmbH. For the last one a half years I?ve been playing with > Keycloak right from version 1.9.8.Final to 4.0.0.Beta1. For one of our > (company?s) usecase, I?ve already integrated an external IdP(IdP really > famous in Germany but not globally) through Keycloak SPI. With my > experience so far, I?d now like to make a small contribution to Keycloak, > an integration of an external identity provider i.e. ?Login with Amazon?. > Before proceeding further, I?d like to have suggestion from you guys > whether I?ll have to consider some points like ?do we need permission from > Amazon?? or any other data protection stuff? > > Let me know about any detailed points I?ll have to consider while > implementing > > > Cheers, > > ____________________________________________________________ > ______________________________________________________________ > Besuchen Sie LOGIN MASTER ? Die L?sung f?r die > Benutzerverwaltung f?r das Web. > ____________________________________________________________ > ______________________________________________________________ > Hasebullah A Ansari > Master of Engineering in IT, Heidelberg > > IT Specialist / Java Entwickler > Syntlogo GmbH > Mercedesstra?e 1 > D-71063 Sindelfingen > > Email: hasebullah.ansari at syntlogo.de syntlogo.de> > Mobile: +49 151 168 39585 > Website: www.syntlogo.de > > Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene > Empf?nger sein, so bitten wir Sie h?flichst, diesen Umstand > unverz?glich dem Absender mitzuteilen und die Nachricht zu l?schen. Jede > nicht genehmigte Weiterverbreitung oder Vervielf?ltigung > ist nicht gestattet. Da wir Echtheit und Vollst?ndigkeit des > Nachrichteninhalts nicht garantieren k?nnen, sind die vorstehenden > Ausf?hrungen rechtlich nicht bindend. Eine Haftung hierf?r wird daher > ausgeschlossen. > > This message is confidential. If you are not the intended recipient, we > kindly ask you to inform the sender and delete the information. > Any unauthorised dissemination or copying hereof is prohibited. As we > cannot guarantee the genuineness or completeness of the information > contained in this message, the statements set forth above are not legally > binding. Accordingly, we cannot accept liability therefore. > > Stuttgart HRB 245317, Gesch?ftsf?hrer Dr. G. Baruzzi, USt-ID: DE 219566705 > ____________________________________________________________ > ______________________________________________________________ > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From jack.coady at cantab.net Sun Jun 3 14:51:41 2018 From: jack.coady at cantab.net (Jack C) Date: Sun, 3 Jun 2018 19:51:41 +0100 Subject: [keycloak-dev] KEYCLOAK-7409 Detect existing IdP session Message-ID: I have a Keycloak realm that I'm using from my application via OpenID. Some users are already signed in to one of its' Identity Providers, but don't have a Keycloak session. I'd like to seamlessly sign them in to the application without going through a Keycloak login screen. I think that a '&prompt=none&kc_idp_hint=idp'request from the application should pass you through to a '&prompt=none' request on the IdP. I've managed to build some of the code and I'm looking at changing e.g. AuthorizationEndpointBase to allow that kind of "passive" redirect but not other challenges. Does this sound like a good plan? I've never tried making this kind of change before - any general advice? I've seen this document. My request on JIRA KEYCLOAK-7409 Someone else's older request mentioning this strategy From takashi.norimatsu.ws at hitachi.com Mon Jun 4 00:51:13 2018 From: takashi.norimatsu.ws at hitachi.com (=?utf-8?B?5LmX5p2+6ZqG5b+XIC8gTk9SSU1BVFNV77yMVEFLQVNISQ==?=) Date: Mon, 4 Jun 2018 04:51:13 +0000 Subject: [keycloak-dev] JWS signatures using PS256 or ES256 algorithms for signing Message-ID: Hello, Therefore, I would like to contribute this SPI. As you said, I will issue a separate PR for it. I would be happy if you and keycloak core contributors give some advice when my encountering problems. Best regards, Takashi Norimatsu Hitachi Ltd., ---------- From: Stian Thorgersen Sent: Wednesday, May 30, 2018 4:35 PM To: ???? / NORIMATSU?TAKASHI Cc: keycloak-dev at lists.jboss.org Subject: [!]Re: Re: [keycloak-dev] JWS signatures using PS256 or ES256 algorithms for signing On 30 May 2018 at 07:49, ???? / NORIMATSU?TAKASHI wrote: Hello, Thank you for your comments. I think it might be better to determine which kind of Token Signature Provider be used by not parsing JWS, for example, looking up Client or Realm settings. This PR might have impacts on keycloak's performance because it has parsed JWS to determine it every time keycloak receives JWS Token. On the server-side that is easy. On the adapter side that would probably require adding a property to keycloak.json to set the algorithm. In either case it should probably default to RSA for existing realms at least, but we could consider setting it to?ES256 for new realms. ? As for existing Key Provider, I've already implemented ECDSA Key Provider (for only signing) in this PR. Therefore, I could contribute it. As for Token Signature SPI, I agree with you. I hope I would like to implement this SPI's provider for ES256 at first and PS256 in the future. I think it is the best way that keycloak's core committers design and implement this Token Signature SPI. However, if they do not have yet such a plan to do that at this time and in the future, I would like to give some ideas on Token Signature SPI. How do you think about that? We don't currently have any plans on implementing this SPI and where holding off on it until we started work on adding?ES256. The ideal here may be that someone from the core team work on the SPI and refactoring of RSA provider, then you can update the PR for?ES256. Unless you feel that you may be able to contribute that as well? If so I would prefer a separate PR for the SPI and refactoring. ? Best regards, Takashi Norimatsu Hitachi Ltd., From: Stian Thorgersen Sent: Tuesday, May 29, 2018 4:40 PM To: ???? / NORIMATSU?TAKASHI Cc: mailto:keycloak-dev at lists.jboss.org Subject: [!]Re: [keycloak-dev] JWS signatures using PS256 or ES256 algorithms for signing Hi, I haven't had time to look at your PR in detail yet, but the way it should work is: * We need to add a Token Signature SPI that can sign and validate token signatures * RSA signing should be refactored into a?Token Signature provider * Realm should have a default signing algorithm. Admin console should allow admins to select from any supported algorithm by listing?TokenSignatureSPI providers * Clients should be able to override the signing algorithm * When verifying signatures in the Keycloak server we should check what the method is for the client (or realm if client doesn't override) and only allow that specific algorithm and nothing else * We may want to consider adding an option to client adapters to specify the expected signing algorithm as well * We also need additional key providers. It looks like you've already added this * We need to make sure that keys are only used for the correct purpose (correct algorithm and if it's for signing or encrypting). I think this is already covered though On 25 May 2018 at 05:26, ???? / NORIMATSU?TAKASHI wrote: I'd like to use more secure JWS signature algorithm in the environment where the high security level is required such as the financial industry. According to the following RFCs, RSASSA-PSS to which PS256 follows is recommended on behalf of RSASSA-PKCS1-v1_5 to which RS256 follows. https://clicktime.symantec.com/a/1/fIIShrle28DIlWvWduZOOVGDLk3xC_-rnn6V7E4iCwU=?d=qD974XExkF_PSJatwmk2bkmKzmCEK4bUj1071dkYHm1WZZzwUbxiM1jYIwjNfIaPMa6OvKfTajEvX2i1cq8fDtIykRMRvNFkvnN1Lqudb_8Y7-UzcOZklB-BRLzaQtNG8nECjDAWBAF3q31mUL7TuRlg63KF0b6wk28KatIosqBcS9XCk1W29haCLNVy0ZhjzPrmG-q1AhlqQWxxyOhGOsl0gj-ttNSpvVo3UUYpdbupv3xjuNq8STct1RfEeDb1PapTQ-p6Az0EyGzxZYZx105TB7x7akAiOimqTmvLPicIaTF9bv_nMWKDmDZG2CLvlgHUyiIk10BN8YL248j8oq9huzNqjrGHekoB2crsClnSHfL_Iv5m5YzUD2HRy7-iom9hKmhY_uw0AO3bofW4Ra9XuwhO2ncvbLyQO_yPscAFfOPYuEpg0-doUfviAQtBcn8IC0fyTQ%3D%3D&u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc3447%23section-8 However, according to the following RFC, ES256 is "Recommended+" while PS256 is "Optional". https://clicktime.symantec.com/a/1/s_2w8zdHH2DoCkMCU7h9NMxUrcVZyNjiGxV6Meq8vTM=?d=qD974XExkF_PSJatwmk2bkmKzmCEK4bUj1071dkYHm1WZZzwUbxiM1jYIwjNfIaPMa6OvKfTajEvX2i1cq8fDtIykRMRvNFkvnN1Lqudb_8Y7-UzcOZklB-BRLzaQtNG8nECjDAWBAF3q31mUL7TuRlg63KF0b6wk28KatIosqBcS9XCk1W29haCLNVy0ZhjzPrmG-q1AhlqQWxxyOhGOsl0gj-ttNSpvVo3UUYpdbupv3xjuNq8STct1RfEeDb1PapTQ-p6Az0EyGzxZYZx105TB7x7akAiOimqTmvLPicIaTF9bv_nMWKDmDZG2CLvlgHUyiIk10BN8YL248j8oq9huzNqjrGHekoB2crsClnSHfL_Iv5m5YzUD2HRy7-iom9hKmhY_uw0AO3bofW4Ra9XuwhO2ncvbLyQO_yPscAFfOPYuEpg0-doUfviAQtBcn8IC0fyTQ%3D%3D&u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc7518%23section-3.1 Moreover, it is said that Elliptic Curve based algorithms have an advantage against RSA base algorithms in volume of its computation. Therefore, I've tried to make keycloak support ES256 JWS signature along with existing RS256 one. I've found that it seemed to be relatively easy to implement software components for ES256 JWS signature such as Signature Provider and Key Provider. However, it seemed to be difficult to implement codes actually calling these providers. The reasons is as follows. * a lot of places have called these singing and verifying providers. * such the places have been hard-coded in RSA algorithm specific. To deal with them, the following ideas have hit on me 1. replace RSA algorithm specific codes with signature algorithm independent codes. 2. re-design JWS signing and verifying scheme on high level. I'm not familiar with keycloak internals, so I've implemented ES256 JWS signature support on #1 basis experimentally. I'm not sure whether this way is appropriate or not. I'm very happy if keycloak specialists consider #2 or review my implementation based on #1. I've issued PR as WIP. Please refer to the following in detail. https://clicktime.symantec.com/a/1/G-XuERmswRIcQ_MQA72oK1EJuT0Y48iac1LbbsWkrOU=?d=qD974XExkF_PSJatwmk2bkmKzmCEK4bUj1071dkYHm1WZZzwUbxiM1jYIwjNfIaPMa6OvKfTajEvX2i1cq8fDtIykRMRvNFkvnN1Lqudb_8Y7-UzcOZklB-BRLzaQtNG8nECjDAWBAF3q31mUL7TuRlg63KF0b6wk28KatIosqBcS9XCk1W29haCLNVy0ZhjzPrmG-q1AhlqQWxxyOhGOsl0gj-ttNSpvVo3UUYpdbupv3xjuNq8STct1RfEeDb1PapTQ-p6Az0EyGzxZYZx105TB7x7akAiOimqTmvLPicIaTF9bv_nMWKDmDZG2CLvlgHUyiIk10BN8YL248j8oq9huzNqjrGHekoB2crsClnSHfL_Iv5m5YzUD2HRy7-iom9hKmhY_uw0AO3bofW4Ra9XuwhO2ncvbLyQO_yPscAFfOPYuEpg0-doUfviAQtBcn8IC0fyTQ%3D%3D&u=https%3A%2F%2Fgithub.com%2Fkeycloak%2Fkeycloak%2Fpull%2F5225 Best regards, Takashi Norimatsu Hitachi Ltd., _______________________________________________ keycloak-dev mailing list mailto:mailto:keycloak-dev at lists.jboss.org https://clicktime.symantec.com/a/1/LBlgE63-JxZCbiegUCPqUTy7Oeq2A8tzZfOiWvp-KfM=?d=qD974XExkF_PSJatwmk2bkmKzmCEK4bUj1071dkYHm1WZZzwUbxiM1jYIwjNfIaPMa6OvKfTajEvX2i1cq8fDtIykRMRvNFkvnN1Lqudb_8Y7-UzcOZklB-BRLzaQtNG8nECjDAWBAF3q31mUL7TuRlg63KF0b6wk28KatIosqBcS9XCk1W29haCLNVy0ZhjzPrmG-q1AhlqQWxxyOhGOsl0gj-ttNSpvVo3UUYpdbupv3xjuNq8STct1RfEeDb1PapTQ-p6Az0EyGzxZYZx105TB7x7akAiOimqTmvLPicIaTF9bv_nMWKDmDZG2CLvlgHUyiIk10BN8YL248j8oq9huzNqjrGHekoB2crsClnSHfL_Iv5m5YzUD2HRy7-iom9hKmhY_uw0AO3bofW4Ra9XuwhO2ncvbLyQO_yPscAFfOPYuEpg0-doUfviAQtBcn8IC0fyTQ%3D%3D&u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev From mposolda at redhat.com Mon Jun 4 05:22:05 2018 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 4 Jun 2018 11:22:05 +0200 Subject: [keycloak-dev] Testing with mocking libraries? In-Reply-To: References: <84bfae42-15d7-439e-ed41-e40d87a8bb7c@redhat.com> <3b8d21e0-7897-ddee-c8b6-34c742d9a512@redhat.com> Message-ID: Dne 1.6.2018 v 14:48 Bill Burke napsal(a): > On Fri, Jun 1, 2018 at 5:18 AM, Marek Posolda wrote: >> For IDP, I am not sure how would Mocked IDP help? We already have lots of >> test coverage for Identity brokering for OIDC and SAML. The social providers >> usually implements OAuth/OIDC and there are just small differences between >> them. But those small differences and the fact that social providers are out >> of our control, is exactly the reason why we need to test with real >> providers instead of mocks IMO. >> > IDP mocks are not a replacement for real testing. Just something that > would run in public CI, that way at least there's something to catch > issues like when/if brokering gets refactored again. AFAIK the longer-term plan is to run social tests on every PR, to catch regressions by testing with real social providers. So maybe it's better to rather wait until we have that rather then introduce mocks now? Also anyone from community should be able to run social tests based on our README. The important is, that someone could run it just for single provider, which he is interested in (EG. Google for this PR) and is not required to create the account+application in all social providers, which we support. But I hope the social tests already support this now. Marek > > Bill From Matt.Domsch at quest.com Mon Jun 4 14:19:03 2018 From: Matt.Domsch at quest.com (Matt Domsch (mdomsch)) Date: Mon, 4 Jun 2018 18:19:03 +0000 Subject: [keycloak-dev] session caching questions In-Reply-To: References: Message-ID: While we're at it, shouldn't the realm, user, and key caches all be invalidation caches too, with a limit on the number of objects in each? The objects are persisted to disk. In our case, I've got >85k user records, and suspect that the user cache is growing unbounded, hence I'm seeing steadily increasing memory usage. Thanks, Matt -- Matt Domsch Executive Director & Senior Distinguished Engineer Quest | Engineering Matt.Domsch at quest.com Mobile 512.981.6486 -----Original Message----- From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Matt Domsch (mdomsch) Sent: Thursday, May 31, 2018 4:06 PM To: keycloak-dev at lists.jboss.org Subject: [keycloak-dev] session caching questions CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. In our deployments, we have need for the individual nodes in our standalone-ha cluster to be able to be stopped and restarted at any time, without loss of user sessions. We deploy into AWS Elastic Beanstalk, and join the "new" nodes into the existing JGroups cluster of "old" nodes, switch CNAMEs, then shut down the "old" nodes. The default suggested model of using for the session and clientSession caches fails in this scenario, as sessions stored only in memory on the "old" nodes are lost. As such, we've switched to for most of the caches. Does this make sense? Are most people using Keycloak running >10 nodes per cluster such that replicated cache doesn't make sense for performance reasons? If not, can the example standalone-ha.xml be adjusted to use replicated-cache? When items are placed into the caches, it seems that they are not put() with a lifetime or expiry time associated with them. This has led us to run into out-of-memory issues as the sizes of these caches grows without bound. We've added expiration times in the XML config to adjust for maximum lifetimes based on the longest session timeouts across all realms. This seems not ideal. It would be better to put() including the current active session timeouts for the realm for the object from which it originates. We cannot evict items in the sessions and clientSessions caches as they are not persisted to disk. The Offline variants are persisted to disk, so evicting these seem OK. Should this then be an invalidation-cache rather than a replicated-cache? XML snippet: Thanks, Matt -- Matt Domsch Executive Director & Senior Distinguished Engineer Quest | Engineering Matt.Domsch at quest.com Mobile 512.981.6486 _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From srossillo at smartling.com Mon Jun 4 16:48:38 2018 From: srossillo at smartling.com (Scott Rossillo) Date: Mon, 4 Jun 2018 16:48:38 -0400 Subject: [keycloak-dev] session caching questions In-Reply-To: References: Message-ID: Hi Matt, I?m not an active Keycloak dev but we used to run our Keycloak cluster on AWS Beanstalk. My advice would be to not use AWS Beanstalk for Keycloak. AWS Beanstalk is OK for simple applications but we had to write custom Beanstalk hooks to get Infinspan to behave correctly. I would suggest using AWS Elastic Cluster Service (ECS) and if you don?t want to manage the instances use Fargate instead of EC2. Just to be clear: this isn?t a criticism of either Keycloak / WildFily / Infinispan or AWS Beanstalk. It?s just advice from another engineer who has experience with the combination of these two products. Since moving to to ECS we haven?t had any issues with the cache during deployments. As for your suggested configuration: I don?t think the user, realm and key caches should be changed. These caches are not an issue during deployments and they reduce DB load significantly the way they?re configured out of the box. Best, Scott Scott Rossillo Smartling | Senior Software Engineer srossillo at smartling.com > On Jun 4, 2018, at 2:19 PM, Matt Domsch (mdomsch) wrote: > > While we're at it, shouldn't the realm, user, and key caches all be invalidation caches too, with a limit on the number of objects in each? The objects are persisted to disk. In our case, I've got >85k user records, and suspect that the user cache is growing unbounded, hence I'm seeing steadily increasing memory usage. > > Thanks, > Matt > > > -- > Matt Domsch > Executive Director & Senior Distinguished Engineer > Quest | Engineering > Matt.Domsch at quest.com > Mobile 512.981.6486 > > -----Original Message----- > From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Matt Domsch (mdomsch) > Sent: Thursday, May 31, 2018 4:06 PM > To: keycloak-dev at lists.jboss.org > Subject: [keycloak-dev] session caching questions > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > In our deployments, we have need for the individual nodes in our standalone-ha cluster to be able to be stopped and restarted at any time, without loss of user sessions. We deploy into AWS Elastic Beanstalk, and join the "new" nodes into the existing JGroups cluster of "old" nodes, switch CNAMEs, then shut down the "old" nodes. The default suggested model of using for the session and clientSession caches fails in this scenario, as sessions stored only in memory on the "old" nodes are lost. As such, we've switched to for most of the caches. Does this make sense? Are most people using Keycloak running >10 nodes per cluster such that replicated cache doesn't make sense for performance reasons? If not, can the example standalone-ha.xml be adjusted to use replicated-cache? > > When items are placed into the caches, it seems that they are not put() with a lifetime or expiry time associated with them. This has led us to run into out-of-memory issues as the sizes of these caches grows without bound. We've added expiration times in the XML config to adjust for maximum lifetimes based on the longest session timeouts across all realms. This seems not ideal. It would be better to put() including the current active session timeouts for the realm for the object from which it originates. > > We cannot evict items in the sessions and clientSessions caches as they are not persisted to disk. The Offline variants are persisted to disk, so evicting these seem OK. Should this then be an invalidation-cache rather than a replicated-cache? > > > XML snippet: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > Matt > > -- > Matt Domsch > Executive Director & Senior Distinguished Engineer Quest | Engineering Matt.Domsch at quest.com > Mobile 512.981.6486 > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Tue Jun 5 06:49:35 2018 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 5 Jun 2018 12:49:35 +0200 Subject: [keycloak-dev] Client scopes PR rebased, Documentation added Message-ID: <192e966e-6a07-aac8-5b56-46c170ee4d40@redhat.com> I've did a rebase of client scopes PR [1] against latest master. Also did the documentation for it in the PR [2] . Anyone has a time to review? TBH I hope it's sorted soon as it changes 291 files, so there is quite a chance for the conflict with every other PR send. And rebasing (which I already did 2 or 3 times) is quite a pain ;) [1] https://github.com/keycloak/keycloak/pull/5076 [2] https://github.com/keycloak/keycloak-documentation/pull/389 Marek From bburke at redhat.com Tue Jun 5 10:22:34 2018 From: bburke at redhat.com (Bill Burke) Date: Tue, 5 Jun 2018 10:22:34 -0400 Subject: [keycloak-dev] Client scopes PR rebased, Documentation added In-Reply-To: <192e966e-6a07-aac8-5b56-46c170ee4d40@redhat.com> References: <192e966e-6a07-aac8-5b56-46c170ee4d40@redhat.com> Message-ID: I'll take a look this afternoon, my time. On Tue, Jun 5, 2018 at 6:49 AM, Marek Posolda wrote: > I've did a rebase of client scopes PR [1] against latest master. Also > did the documentation for it in the PR [2] . > > Anyone has a time to review? TBH I hope it's sorted soon as it changes > 291 files, so there is quite a chance for the conflict with every other > PR send. And rebasing (which I already did 2 or 3 times) is quite a pain ;) > > [1] https://github.com/keycloak/keycloak/pull/5076 > [2] https://github.com/keycloak/keycloak-documentation/pull/389 > > Marek > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Bill Burke Red Hat From sthorger at redhat.com Tue Jun 5 14:12:15 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 5 Jun 2018 20:12:15 +0200 Subject: [keycloak-dev] KEYCLOAK-2606 - Browsertab-Support for Cordova In-Reply-To: References: <176FD46C-C9F5-481F-B2B7-DC87586FE11A@cofinpro.de> Message-ID: Sorry for the late response, but the first approach seems good to me. I would assume the app developer would have to configure the universal link for the app, but also configure it in the Keycloak adapter right so it knows what URL to handle? Or can it just handle it without knowing the exact link? I would assume changes needed to apps to switch between the "old mode" and the new mode with system browsers in either case so not to worried if it requires some changes for existing users. On 30 May 2018 at 10:26, Gregor Tudan wrote: > > >> Figuring out the callback wasn?t to hard either - now the last missing >> piece is parsing the callback. Here we have the option of registering a >> universal link inside the Keycloak adapter which opens the app, or leaving >> this to the developer and provide a public method for it (like >> processCallback). >> >> I?m not quiet sure on these options, what are your thoughts on this? >> > > Could you elaborate a bit on this please? > > > Sure - The way those native browser tabs work is that the app requests to > open a site, but has no access to what happens inside the browser. After > the login is done, the browser redirects back into the app by using > universal links. These URLs have be registered in the app, so the browser > knows that it should pass those requests back. From there, we can get the > oauth params (state and code) and fetch the token. > > The question is: should we implement this kind of callback logic inside > the adapter, or should we provide the user a method for completing the > login process upon redirecting? > > If we do this in the adapter, we would need to make some assumptions on > the Cordova-Plugin being used and how the link is set up. I don?t think > that?s a bad thing, but we would need to document how to setup the app so > that the redirect works. This would also fit nicely in the current API of > the adapter. > > The other option would be to leave it up to the user to handle the > redirect and offer a callback for finishing the authorization. This would > basically boil down to a method that takes the code and the state params > (like processCallback in the current adapter). This would kind of break the > API of the adapter, as the login method will behave differently for this > native adapter. > > To summarize: doing more stuff in the adapter would simplify things for > the developer, but might not work for existing apps - i.e. if they use a > different plugin for handling universal links. > > I suggest starting with first option (handling redirects in the adapter) > to get started - universal links don?t seem to be to widely used, so most > apps shouldn?t run into problems with us picking a plugin for them. Maybe > we can add another option to the adapter for manual redirect-handling later > on. > For the first approach I assume the app developer would have to pick a From thomas.darimont at googlemail.com Tue Jun 5 15:33:07 2018 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Tue, 5 Jun 2018 20:33:07 +0100 Subject: [keycloak-dev] PKCE support for Keycloak Adapters (OAuthRequestAuthenticator) In-Reply-To: References: Message-ID: Hello, I gave it another spin and tested it with a whole bunch of browsers - Windows (IE11, Edge, Firefox, Chrome) - Linux (Chrome, Firefox) Current changes: (Added IE11 Support) https://github.com/keycloak/keycloak/compare/master...thomasdarimont:poc/keycloak-js-pkce-support?expand=0 If you want to give it a try, you could use the js-console example from https://github.com/keycloak/keycloak/blob/master/examples/js-console/src/main/webapp/index.html and just copy the keycloak.js with the PKCE support into the webapp folder an include the script from there. In the initOptions for Keycloak, just add "pkceMethod: 'S256'", e.g.: var initOptions = { responseMode: 'fragment', flow: 'standard', pkceMethod: 'S256' }; If you look at your browser dev-tools, you should now see, code_challenge and code_challenge_method parameters added to your /auth url. Additionally a code_verifier parameter should be sent with the /token POST request. Some additional remarks: In order to support IE11 I had to use the window.msCrypto APIs and I added a fallback if even that is not available. Currently the generated code_verifier is stored in localStorage similar to the 'kc-callback-...' values. I think that localStorage is not the best place to store a temporary secret ... I'm open to alternatives. The PKCE code_verifier is generated and stored in localStorage when building the auth URL, where either the plain value or an url-safe base64 encoded sha256 has of the code_verifier is used as the code_challenge, depending on the chosen method. Instead of localStorage one could probably also just use sessionStorage, which would have the advantage of automatic deletion when the tab / browser is closed. The two included libraries could be embedded / scoped into the keycloak JS scope to not interfere with other included versions of the libraries. Cheers, Thomas On Thu, May 31, 2018 at 1:09 PM Thomas Darimont < thomas.darimont at googlemail.com> wrote: > Hi folks, > > I've got a working PoC for PKCE support in the Keycloak JS adapter that > supports `plain` and `S256` code_challenge_methods. > Works very well with Keycloak 4.0.0.beta3 and Keycloak 3.4.3.Final. > Perhaps this could serve as a base for a real PR. > > I needed to use two small js libraries to have proper support for sha256 > and base64 encoding for Unit8Arrays in order to > produce a codeChallenge in the same way the Keycloak server does it, for > details see commit. > > Branch: > https://github.com/thomasdarimont/keycloak/tree/poc/keycloak-js-pkce-support > Commit: > https://github.com/thomasdarimont/keycloak/commit/f05066d430f6504246f7e518a124aef2ef5195b8 > > Looks like this would solve the issue > https://issues.jboss.org/browse/KEYCLOAK-1033 (which would probably need > to be renamed). > > Cheers, > Thomas > > On Wed, May 30, 2018 at 11:57 PM Thomas Darimont < > thomas.darimont at googlemail.com> wrote: > >> Good point. Yes the main use case for PKCE are public clients / native >> apps. >> >> However the recently published OAuth 2.0 Security Best Current Practice >> (Draft 06 2018) [1] states: >> " >> 2.1. Protecting redirect-based flows >> ... >> Clients shall use PKCE [RFC7636] in order to (with the help of the >> authorization server) detect and prevent attempts to inject (replay) >> authorization codes into the authorization response. The PKCE >> challenges must be transaction-specific and securely bound to the >> user agent, in which the transaction was started. OpenID Connect >> clients may use the "nonce" parameter of the OpenID Connect >> authentication request as specified in [OpenID] in conjunction with >> the corresponding ID Token claim for the same purpose. >> >> Note: although PKCE so far was recommended as mechanism to protect >> native apps, this advice applies to all kinds of OAuth clients, >> including web applications. >> " >> The last "Note" section was what inspired me to look into PKCE support >> for server-side adapters as well. >> But I generally agree that this is probably better suited for the JS / >> CLI/ keycloak-installed adapters. >> >> [1] https://tools.ietf.org/html/draft-ietf-oauth-security-topics-06 >> >> On Wed, May 30, 2018 at 8:38 AM Stian Thorgersen >> wrote: >> >>> As PKCE is aimed at public clients why is there a need to add support >>> for this to the Java adapters? Makes more sense to add this to the >>> JavaScript adapter and CLI/desktop adapter. >>> >>> On 30 May 2018 at 07:47, ???? / NORIMATSU?TAKASHI < >>> takashi.norimatsu.ws at hitachi.com> wrote: >>> >>>> Hello, >>>> >>>> I've encountered the same problem and gave up. >>>> >>>> At that time, the naive idea had hit on me. >>>> * prepare some concurrently accessible singleton (line >>>> KeycloakDeployment) from OAuthRequestAuthenticator >>>> * store generated codeVerifier on it with state parameter value as its >>>> key. >>>> >>>> But, considering the nature of codeVerifier, the followings are >>>> required for such the store >>>> * codeVerifier should be treated the same secure levels as client >>>> credentials >>>> * codeVerifier should be short-lived and deleted after its life the >>>> same as Authorization Code >>>> >>>> Therefore, It might be better to create an tentative instance whose >>>> lifetime is between issuing Authorization Code Request and issuing Token >>>> Request. And, it should be identified and only accessible from the session >>>> instance who issued Authorization Code Request. >>>> >>>> However, I'm afraid it might be difficult to accomplish it in generic >>>> fashion. We need to implement the above each type of client adapter. >>>> >>>> Best regards, >>>> Takashi Norimatsu >>>> Hitachi Ltd., >>>> >>>> -----Original Message----- >>>> From: keycloak-dev-bounces at lists.jboss.org < >>>> keycloak-dev-bounces at lists.jboss.org> On Behalf Of Thomas Darimont >>>> Sent: Wednesday, May 30, 2018 9:02 AM >>>> To: keycloak-dev >>>> Subject: [!][keycloak-dev] PKCE support for Keycloak Adapters >>>> (OAuthRequestAuthenticator) >>>> >>>> Hi there, >>>> >>>> I was recently playing with the PKCE support in Keycloak (server) which >>>> worked quite well. >>>> However the support for client / adapters seems to be quite limited at >>>> the moment... >>>> >>>> I think support for PKCE to all? java adapters could be added quite >>>> easily >>>> - I could provide a >>>> PR but I'm currently stuck with finding a generic way to store the >>>> codeVerifier generated for the login redirect for later retrival for the >>>> code2token exchange. >>>> >>>> Do you have any recommendations for this? >>>> >>>> I created the following JIRA issue (with some comments) to track this: >>>> >>>> https://clicktime.symantec.com/a/1/bkUjActRvyW1Ds3zoQSu7mjr4Nabixm_1YJAW4-UxEM=?d=d5OUWVTwLT2kMkuISm5qn8WHJTBcSVkENKzaB0Z2mA-PX8kp40LeKyOrcMpyKd841kYgP2EXaDDWYa0qu-AFLCtVLO4LvMfUJgUhu3xFwONMPy78dypmmmeEalkcYLU4XY3LcstbfVAoE0jRdEXXMyYStWwO95V_98pfhIYFlYFIHgapXJsFfGrldL8-siYGhinjnCn_AWyuyqrwhvBY582Dr3Pn9k4YZfsudBwcSJkErQKzyYEKfMhwz4ix7EAa-hvQ6rGHFdSza3jf1cMjsR4Xio667eNtirL9ruV4Z-FFQhamJMSJGb2o8rR52iEuGTp_28Vivk5HiwYx5XhZ4Bm9_dhN2eNeWT396bZQJwC7tDetr6UPVrPiMn6aTLdGMu6Wr-byBNvnEFmqxCB0Cx1tPxQkO4DVWKF4_iWgxZ6sW49k87BqaRTp3ktECRXNJ-CA04UZQbL7w-uPYlxvyvNNl408bCn5LpYf8w%3D%3D&u=https%3A%2F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-7467 >>>> >>>> Cheers, >>>> Thomas >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> >>>> https://clicktime.symantec.com/a/1/Xn2ffdZIVPL_UA8_cnNApcirkcZZdsnyb6SpUdKiO-s=?d=d5OUWVTwLT2kMkuISm5qn8WHJTBcSVkENKzaB0Z2mA-PX8kp40LeKyOrcMpyKd841kYgP2EXaDDWYa0qu-AFLCtVLO4LvMfUJgUhu3xFwONMPy78dypmmmeEalkcYLU4XY3LcstbfVAoE0jRdEXXMyYStWwO95V_98pfhIYFlYFIHgapXJsFfGrldL8-siYGhinjnCn_AWyuyqrwhvBY582Dr3Pn9k4YZfsudBwcSJkErQKzyYEKfMhwz4ix7EAa-hvQ6rGHFdSza3jf1cMjsR4Xio667eNtirL9ruV4Z-FFQhamJMSJGb2o8rR52iEuGTp_28Vivk5HiwYx5XhZ4Bm9_dhN2eNeWT396bZQJwC7tDetr6UPVrPiMn6aTLdGMu6Wr-byBNvnEFmqxCB0Cx1tPxQkO4DVWKF4_iWgxZ6sW49k87BqaRTp3ktECRXNJ-CA04UZQbL7w-uPYlxvyvNNl408bCn5LpYf8w%3D%3D&u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >>> From mposolda at redhat.com Tue Jun 5 16:13:23 2018 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 5 Jun 2018 22:13:23 +0200 Subject: [keycloak-dev] Improve "Logout all" for the realm? Message-ID: Hi, when you click on tab "Sessions", you can see the screen with the: - counts of Active Sessions - counts of Offline Sessions - Button "Logout All" See the screenshot how the screen currently looks like: https://pasteboard.co/HowNZ2I.png We have the JIRA https://issues.jboss.org/browse/KEYCLOAK-7055 and the PR with the discussion https://github.com/keycloak/keycloak/pull/5126 . In shortcut, JIRA and PR points few issues: 1) There is no way to logout all active sessions only (Keep the offline sessions) 2) There is no way to logout all offline sessions only (Keep the active sessions) 3) When you click on the button, there is no confirmation dialog. It seems that "Logout all" is quite an important step and confirmation should be there. 4) When you click on the button, it will do something between. All active sessions are cleared from infinispan, but offline sessions are NOT cleared. There is just realm notBefore policy updated, which indirectly invalidates the offline sessions, but they are still kept in infinispan and DB, which itself is a bug IMO. So how to address all the issues? I can see something like this: - Instead of 1 button, have 3 buttons (Logout all active sessions, Logout all offline sessions, Logout all) - All the buttons will display confirmation dialog - The "Logout all" will also update notBefore policy like it's done now. It will clear all the "Active" and "Offline" sessions from infinispan. This will be displayed in the confirmation dialog. So confirmation for "Logout all" will be like: "Do you want to logout all active sessions and offline sessions and update realm notBefore policy?" The other 2 buttons won't update not-before policy (we can't do that unless we have separate not-before for active sessions and for offline sessions, but I vote to not do that considering the required complexity of this). - The message for "Logout all" will be sent to all the clients with adminUrl (which is already done). One related issue is, that currently we don't have a way to notify client applications that offline sessions were invalidated. I was thinking if we could have a way to register some listener for various? adapter events (Logout all, logout all active/offline sessions, logout single active/offline session)? Client application can listen to the events and do something (EG. remove saved offline token from it's DB). WDYT? Marek From sthorger at redhat.com Wed Jun 6 02:28:21 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 6 Jun 2018 08:28:21 +0200 Subject: [keycloak-dev] Improve "Logout all" for the realm? In-Reply-To: References: Message-ID: On 5 June 2018 at 22:13, Marek Posolda wrote: > Hi, > > when you click on tab "Sessions", you can see the screen with the: > - counts of Active Sessions > - counts of Offline Sessions > - Button "Logout All" > > See the screenshot how the screen currently looks like: > https://pasteboard.co/HowNZ2I.png > > We have the JIRA https://issues.jboss.org/browse/KEYCLOAK-7055 and the > PR with the discussion https://github.com/keycloak/keycloak/pull/5126 . > In shortcut, JIRA and PR points few issues: > 1) There is no way to logout all active sessions only (Keep the offline > sessions) > > 2) There is no way to logout all offline sessions only (Keep the active > sessions) > > 3) When you click on the button, there is no confirmation dialog. It > seems that "Logout all" is quite an important step and confirmation > should be there. > > 4) When you click on the button, it will do something between. All > active sessions are cleared from infinispan, but offline sessions are > NOT cleared. There is just realm notBefore policy updated, which > indirectly invalidates the offline sessions, but they are still kept in > infinispan and DB, which itself is a bug IMO. > > So how to address all the issues? I can see something like this: > - Instead of 1 button, have 3 buttons (Logout all active sessions, > Logout all offline sessions, Logout all) > Sounds good, but might look a bit messy with those long labels and 3 buttons. Do we need 3 buttons? Or is "Logout active" and "Logout offline" sufficient? Do we have a better term for non-offline than active? > > - All the buttons will display confirmation dialog > +1 > > - The "Logout all" will also update notBefore policy like it's done now. > It will clear all the "Active" and "Offline" sessions from infinispan. > This will be displayed in the confirmation dialog. So confirmation for > "Logout all" will be like: "Do you want to logout all active sessions > and offline sessions and update realm notBefore policy?" The other 2 > buttons won't update not-before policy (we can't do that unless we have > separate not-before for active sessions and for offline sessions, but I > vote to not do that considering the required complexity of this). > Should it also clear sessions from the DB? > > - The message for "Logout all" will be sent to all the clients with > adminUrl (which is already done). > > One related issue is, that currently we don't have a way to notify > client applications that offline sessions were invalidated. I was > thinking if we could have a way to register some listener for various > adapter events (Logout all, logout all active/offline sessions, logout > single active/offline session)? Client application can listen to the > events and do something (EG. remove saved offline token from it's DB). > I'm not to keen on more bespoke logout protocols. Have we studied the OIDC backchannel/frontchannel specs yet? Is there a way to do this in a standard way? > > WDYT? > Marek > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From mposolda at redhat.com Wed Jun 6 02:48:10 2018 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 6 Jun 2018 08:48:10 +0200 Subject: [keycloak-dev] Improve "Logout all" for the realm? In-Reply-To: References: Message-ID: <1f813634-1834-382f-bd57-bb54668a8f4a@redhat.com> On 06/06/18 08:28, Stian Thorgersen wrote: > > > On 5 June 2018 at 22:13, Marek Posolda > wrote: > > Hi, > > when you click on tab "Sessions", you can see the screen with the: > - counts of Active Sessions > - counts of Offline Sessions > - Button "Logout All" > > See the screenshot how the screen currently looks like: > https://pasteboard.co/HowNZ2I.png > > We have the JIRA https://issues.jboss.org/browse/KEYCLOAK-7055 > and the > PR with the discussion > https://github.com/keycloak/keycloak/pull/5126 > . > In shortcut, JIRA and PR points few issues: > 1) There is no way to logout all active sessions only (Keep the > offline > sessions) > > 2) There is no way to logout all offline sessions only (Keep the > active > sessions) > > 3) When you click on the button, there is no confirmation dialog. It > seems that "Logout all" is quite an important step and confirmation > should be there. > > 4) When you click on the button, it will do something between. All > active sessions are cleared from infinispan, but offline sessions are > NOT cleared. There is just realm notBefore policy updated, which > indirectly invalidates the offline sessions, but they are still > kept in > infinispan and DB, which itself is a bug IMO. > > So how to address all the issues? I can see something like this: > - Instead of 1 button, have 3 buttons (Logout all active sessions, > Logout all offline sessions, Logout all) > > > Sounds good, but might look a bit messy with those long labels and 3 > buttons. Do we need 3 buttons? Or is "Logout active" and "Logout > offline" sufficient? Do we have a better term for non-offline than active? The thing is, that with "Logout active" and "Logout offline", you can't update notBefore policy. If you update it, you always effectively invalidate both kind of sessions. I was also thinking about keep the single button, but once confirmation dialog is displayed, you will have 3 checkboxes in it (push not-before, logout active, logout offline) and all checked by default. When you uncheck "logout active" or "logout offline", it will also automatically uncheck "push not-before" . In other words, "push not-before" always require both other checkboxes checked due the reason above. Is it better regarding usability? I am not sure as admin won't see that "Logout all" has more options until he clicks on it and dialog is displayed? > > > - All the buttons will display confirmation dialog > > > +1 > > > - The "Logout all" will also update notBefore policy like it's > done now. > It will clear all the "Active" and "Offline" sessions from > infinispan. > This will be displayed in the confirmation dialog. So confirmation > for > "Logout all" will be like: "Do you want to logout all active sessions > and offline sessions and update realm notBefore policy?" The other 2 > buttons won't update not-before policy (we can't do that unless we > have > separate not-before for active sessions and for offline sessions, > but I > vote to not do that considering the required complexity of this). > > > Should it also clear sessions from the DB? Yes > > > - The message for "Logout all" will be sent to all the clients with > adminUrl (which is already done). > > One related issue is, that currently we don't have a way to notify > client applications that offline sessions were invalidated. I was > thinking if we could have a way to register some listener for various > adapter events (Logout all, logout all active/offline sessions, > logout > single active/offline session)? Client application can listen to the > events and do something (EG. remove saved offline token from it's DB). > > > I'm not to keen on more bespoke logout protocols. Have we studied the > OIDC backchannel/frontchannel specs yet? Is there a way to do this in > a standard way? Ok, true. I've looked at the specs some time ago, we already partially implement something from them. I remember front-channel logout specs contains some interesting usage of iframes (You will display single HTML page with the iframes, where each iframe contains the URL to logout single client). Is it pretty interesting stuff and seems to be much less error-prone than chain-of-redirects approach, which SAML Front-channel logout uses. I've proposed to support iframes for SAML Front-channel logout too some time ago on this list. I think Bill and Hynek liked it. We just need to implement those things :) Marek > > > WDYT? > Marek > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > From sblanc at redhat.com Wed Jun 6 03:07:26 2018 From: sblanc at redhat.com (Sebastien Blanc) Date: Wed, 6 Jun 2018 09:07:26 +0200 Subject: [keycloak-dev] Improve "Logout all" for the realm? In-Reply-To: References: Message-ID: On Wed, Jun 6, 2018 at 8:28 AM, Stian Thorgersen wrote: > On 5 June 2018 at 22:13, Marek Posolda wrote: > > > Hi, > > > > when you click on tab "Sessions", you can see the screen with the: > > - counts of Active Sessions > > - counts of Offline Sessions > > - Button "Logout All" > > > > See the screenshot how the screen currently looks like: > > https://pasteboard.co/HowNZ2I.png > > > > We have the JIRA https://issues.jboss.org/browse/KEYCLOAK-7055 and the > > PR with the discussion https://github.com/keycloak/keycloak/pull/5126 . > > In shortcut, JIRA and PR points few issues: > > 1) There is no way to logout all active sessions only (Keep the offline > > sessions) > > > > 2) There is no way to logout all offline sessions only (Keep the active > > sessions) > > > > 3) When you click on the button, there is no confirmation dialog. It > > seems that "Logout all" is quite an important step and confirmation > > should be there. > > > > 4) When you click on the button, it will do something between. All > > active sessions are cleared from infinispan, but offline sessions are > > NOT cleared. There is just realm notBefore policy updated, which > > indirectly invalidates the offline sessions, but they are still kept in > > infinispan and DB, which itself is a bug IMO. > > > > So how to address all the issues? I can see something like this: > > - Instead of 1 button, have 3 buttons (Logout all active sessions, > > Logout all offline sessions, Logout all) > > > > Sounds good, but might look a bit messy with those long labels and 3 > buttons. Do we need 3 buttons? Or is "Logout active" and "Logout offline" > sufficient? Do we have a better term for non-offline than active? > > > > > > - All the buttons will display confirmation dialog > > > > +1 > > > > > > - The "Logout all" will also update notBefore policy like it's done now. > > It will clear all the "Active" and "Offline" sessions from infinispan. > > This will be displayed in the confirmation dialog. So confirmation for > > "Logout all" will be like: "Do you want to logout all active sessions > > and offline sessions and update realm notBefore policy?" The other 2 > > buttons won't update not-before policy (we can't do that unless we have > > separate not-before for active sessions and for offline sessions, but I > > vote to not do that considering the required complexity of this). > > > > Should it also clear sessions from the DB? > > > > > > - The message for "Logout all" will be sent to all the clients with > > adminUrl (which is already done). > > > > One related issue is, that currently we don't have a way to notify > > client applications that offline sessions were invalidated. I was > > thinking if we could have a way to register some listener for various > > adapter events (Logout all, logout all active/offline sessions, logout > > single active/offline session)? Client application can listen to the > > events and do something (EG. remove saved offline token from it's DB). > > > > I'm not to keen on more bespoke logout protocols. Have we studied the OIDC > backchannel/frontchannel specs yet? Is there a way to do this in a standard > way? > Apparently even the spec is not clear about this, the suggest that they should be a "signal" (a particular claim ?) to indicate if the offline should be revoked as well. "Refresh tokens issued with the offline_access property normally SHOULD NOT be revoked. NOTE: An open issue for the specification is whether to define an additional optional parameter in the logout token, probably as a value in the event-specific parameters JSON object, that explicitly signals that offline_access refresh tokens are also to be revoked." http://openid.net/specs/openid-connect-backchannel-1_0.html#Backchannel BTW , are we currently using a Logout Token as specified in the specs ? > > > > > WDYT? > > Marek > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From mposolda at redhat.com Wed Jun 6 03:16:20 2018 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 6 Jun 2018 09:16:20 +0200 Subject: [keycloak-dev] session caching questions In-Reply-To: References: Message-ID: On 31/05/18 23:06, Matt Domsch (mdomsch) wrote: > In our deployments, we have need for the individual nodes in our standalone-ha cluster to be able to be stopped and restarted at any time, without loss of user sessions. We deploy into AWS Elastic Beanstalk, and join the "new" nodes into the existing JGroups cluster of "old" nodes, switch CNAMEs, then shut down the "old" nodes. The default suggested model of using for the session and clientSession caches fails in this scenario, as sessions stored only in memory on the "old" nodes are lost. As such, we've switched to for most of the caches. Does this make sense? Are most people using Keycloak running >10 nodes per cluster such that replicated cache doesn't make sense for performance reasons? If not, can the example standalone-ha.xml be adjusted to use replicated-cache? You can keep the distributed-cache, but increase the count of owners to 2 or more instead of default 1. Maybe we can clarify this more clearly in the docs... Replicated-cache is defacto just distributed cache with owners == count-of-nodes-in-cluster . It is safe that data won't be ever lost (unless you stop whole cluster), but memory consumption and performance is not ideal. > > When items are placed into the caches, it seems that they are not put() with a lifetime or expiry time associated with them. This has led us to run into out-of-memory issues as the sizes of these caches grows without bound. We've added expiration times in the XML config to adjust for maximum lifetimes based on the longest session timeouts across all realms. This seems not ideal. It would be better to put() including the current active session timeouts for the realm for the object from which it originates. The configuration in the standalone.xml looks like this, so there should be eviction enabled by default on the caches. By default it's like this: ??????????????? ??????????????????? ??????????????? ??????????????? ??????????????????? ??????????????? Did you change the default configuration and removed the eviction or expiration by accident? > > We cannot evict items in the sessions and clientSessions caches as they are not persisted to disk. The Offline variants are persisted to disk, so evicting these seem OK. Should this then be an invalidation-cache rather than a replicated-cache? We have background thread in KEycloak, which automatically removes all the expired userSessions and clientSessions. Expired depends on "Max Session Lifespan" (10 hours by default) and "Max Idle Lifespan (30 minutes by default). Marek > > > XML snippet: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > Matt > > -- > Matt Domsch > Executive Director & Senior Distinguished Engineer > Quest | Engineering > Matt.Domsch at quest.com > Mobile 512.981.6486 > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From hmlnarik at redhat.com Wed Jun 6 04:03:15 2018 From: hmlnarik at redhat.com (Hynek Mlnarik) Date: Wed, 6 Jun 2018 10:03:15 +0200 Subject: [keycloak-dev] Testing with mocking libraries? In-Reply-To: References: <84bfae42-15d7-439e-ed41-e40d87a8bb7c@redhat.com> <3b8d21e0-7897-ddee-c8b6-34c742d9a512@redhat.com> Message-ID: To answer the original question whether to mock or not to mock, I wouldn't object allowing those in unit tests (which we have not that many though until now there's no need to them and I hope we can preserve this state). I'd rather not introduce those in integration tests because of maintenance costs. The biggest issue I see with mocks is that one needs to be extra careful to return exactly what's expected from the specification/counterparty. Since social providers can change without prior notice, our mocked IdPs might give us false impression that we're testing them. Furthermore, such mocks would be rather complex, and would require non-trivial maintenance. I'm hence biased against mock IdPs and prefer the tests with real IdPs as mentioned by Marek. On Mon, Jun 4, 2018 at 11:22 AM, Marek Posolda wrote: > Dne 1.6.2018 v 14:48 Bill Burke napsal(a): > > On Fri, Jun 1, 2018 at 5:18 AM, Marek Posolda > wrote: > >> For IDP, I am not sure how would Mocked IDP help? We already have lots > of > >> test coverage for Identity brokering for OIDC and SAML. The social > providers > >> usually implements OAuth/OIDC and there are just small differences > between > >> them. But those small differences and the fact that social providers > are out > >> of our control, is exactly the reason why we need to test with real > >> providers instead of mocks IMO. > >> > > IDP mocks are not a replacement for real testing. Just something that > > would run in public CI, that way at least there's something to catch > > issues like when/if brokering gets refactored again. > AFAIK the longer-term plan is to run social tests on every PR, to catch > regressions by testing with real social providers. So maybe it's better > to rather wait until we have that rather then introduce mocks now? > > Also anyone from community should be able to run social tests based on > our README. The important is, that someone could run it just for single > provider, which he is interested in (EG. Google for this PR) and is not > required to create the account+application in all social providers, > which we support. But I hope the social tests already support this now. > > Marek > > > > Bill > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- --Hynek From mposolda at redhat.com Wed Jun 6 04:11:58 2018 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 6 Jun 2018 10:11:58 +0200 Subject: [keycloak-dev] PKCE support for Keycloak Adapters (OAuthRequestAuthenticator) In-Reply-To: References: Message-ID: Hi Thomas, I think it is great and will be good to support this in our javascript adapter OOTB. Few comments: - In keycloak.js, we use "createUUID()" function to generate "nonce" and "state" . IMO it will be good if all the things (nonce, state, codeVerifier...) are generated through same mechanism. I guess that we can use "window.crypto" or "window.msCrypto", but if none of them is available, then just fallback to what is currently used in "createUUID()" ? Also change the current generating of "nonce" and "state" to this as I suppose that "window.crypto" or "window.msCrypto" are safer alternatives than our current "createUUID()" ? - I have same concern as you about localStorage, but don't have any better alternative... No idea if sessionStorage is better. - We should document what browsers supports it. I guess that due to fallback for crypto/msCrypto, the "plain" method shouldn't be an issue for any browser as codeVerifier will be always generated just fine? But I guess that S256, which requires this "Uint8Array" stuff may have compatibility issues? Or am I wrong here? The issue is, that people can still use very old browsers (For example Windows XP with IE6) and not sure how bad it is if those people with old browsers can't authenticate... Marek On 05/06/18 21:33, Thomas Darimont wrote: > Hello, > > I gave it another spin and tested it with a whole bunch of browsers > - Windows (IE11, Edge, Firefox, Chrome) > - Linux (Chrome, Firefox) > > Current changes: (Added IE11 Support) > https://github.com/keycloak/keycloak/compare/master...thomasdarimont:poc/keycloak-js-pkce-support?expand=0 > > If you want to give it a try, you could use the js-console example from > > https://github.com/keycloak/keycloak/blob/master/examples/js-console/src/main/webapp/index.html > and just copy the keycloak.js with the PKCE support into the webapp folder > an include the script from there. > > In the initOptions for Keycloak, just add "pkceMethod: 'S256'", e.g.: > > var initOptions = { > responseMode: 'fragment', > flow: 'standard', > pkceMethod: 'S256' > }; > > If you look at your browser dev-tools, you should now see, code_challenge > and code_challenge_method parameters added to your > /auth url. Additionally a code_verifier parameter should be sent with the > /token POST request. > > Some additional remarks: > > In order to support IE11 I had to use the window.msCrypto APIs and I added > a fallback if even that is not available. > Currently the generated code_verifier is stored in localStorage similar to > the 'kc-callback-...' values. > I think that localStorage is not the best place to store a temporary secret > ... I'm open to alternatives. > > The PKCE code_verifier is generated and stored in localStorage when > building the auth URL, where either > the plain value or an url-safe base64 encoded sha256 has of the > code_verifier is used as the code_challenge, depending on the chosen method. > Instead of localStorage one could probably also just use sessionStorage, > which would have the advantage of automatic deletion when the tab / browser > is closed. > > The two included libraries could be embedded / scoped into the keycloak JS > scope to not interfere with other included versions of the libraries. > > Cheers, > Thomas > > On Thu, May 31, 2018 at 1:09 PM Thomas Darimont < > thomas.darimont at googlemail.com> wrote: > >> Hi folks, >> >> I've got a working PoC for PKCE support in the Keycloak JS adapter that >> supports `plain` and `S256` code_challenge_methods. >> Works very well with Keycloak 4.0.0.beta3 and Keycloak 3.4.3.Final. >> Perhaps this could serve as a base for a real PR. >> >> I needed to use two small js libraries to have proper support for sha256 >> and base64 encoding for Unit8Arrays in order to >> produce a codeChallenge in the same way the Keycloak server does it, for >> details see commit. >> >> Branch: >> https://github.com/thomasdarimont/keycloak/tree/poc/keycloak-js-pkce-support >> Commit: >> https://github.com/thomasdarimont/keycloak/commit/f05066d430f6504246f7e518a124aef2ef5195b8 >> >> Looks like this would solve the issue >> https://issues.jboss.org/browse/KEYCLOAK-1033 (which would probably need >> to be renamed). >> >> Cheers, >> Thomas >> >> On Wed, May 30, 2018 at 11:57 PM Thomas Darimont < >> thomas.darimont at googlemail.com> wrote: >> >>> Good point. Yes the main use case for PKCE are public clients / native >>> apps. >>> >>> However the recently published OAuth 2.0 Security Best Current Practice >>> (Draft 06 2018) [1] states: >>> " >>> 2.1. Protecting redirect-based flows >>> ... >>> Clients shall use PKCE [RFC7636] in order to (with the help of the >>> authorization server) detect and prevent attempts to inject (replay) >>> authorization codes into the authorization response. The PKCE >>> challenges must be transaction-specific and securely bound to the >>> user agent, in which the transaction was started. OpenID Connect >>> clients may use the "nonce" parameter of the OpenID Connect >>> authentication request as specified in [OpenID] in conjunction with >>> the corresponding ID Token claim for the same purpose. >>> >>> Note: although PKCE so far was recommended as mechanism to protect >>> native apps, this advice applies to all kinds of OAuth clients, >>> including web applications. >>> " >>> The last "Note" section was what inspired me to look into PKCE support >>> for server-side adapters as well. >>> But I generally agree that this is probably better suited for the JS / >>> CLI/ keycloak-installed adapters. >>> >>> [1] https://tools.ietf.org/html/draft-ietf-oauth-security-topics-06 >>> >>> On Wed, May 30, 2018 at 8:38 AM Stian Thorgersen >>> wrote: >>> >>>> As PKCE is aimed at public clients why is there a need to add support >>>> for this to the Java adapters? Makes more sense to add this to the >>>> JavaScript adapter and CLI/desktop adapter. >>>> >>>> On 30 May 2018 at 07:47, ???? / NORIMATSU?TAKASHI < >>>> takashi.norimatsu.ws at hitachi.com> wrote: >>>> >>>>> Hello, >>>>> >>>>> I've encountered the same problem and gave up. >>>>> >>>>> At that time, the naive idea had hit on me. >>>>> * prepare some concurrently accessible singleton (line >>>>> KeycloakDeployment) from OAuthRequestAuthenticator >>>>> * store generated codeVerifier on it with state parameter value as its >>>>> key. >>>>> >>>>> But, considering the nature of codeVerifier, the followings are >>>>> required for such the store >>>>> * codeVerifier should be treated the same secure levels as client >>>>> credentials >>>>> * codeVerifier should be short-lived and deleted after its life the >>>>> same as Authorization Code >>>>> >>>>> Therefore, It might be better to create an tentative instance whose >>>>> lifetime is between issuing Authorization Code Request and issuing Token >>>>> Request. And, it should be identified and only accessible from the session >>>>> instance who issued Authorization Code Request. >>>>> >>>>> However, I'm afraid it might be difficult to accomplish it in generic >>>>> fashion. We need to implement the above each type of client adapter. >>>>> >>>>> Best regards, >>>>> Takashi Norimatsu >>>>> Hitachi Ltd., >>>>> >>>>> -----Original Message----- >>>>> From: keycloak-dev-bounces at lists.jboss.org < >>>>> keycloak-dev-bounces at lists.jboss.org> On Behalf Of Thomas Darimont >>>>> Sent: Wednesday, May 30, 2018 9:02 AM >>>>> To: keycloak-dev >>>>> Subject: [!][keycloak-dev] PKCE support for Keycloak Adapters >>>>> (OAuthRequestAuthenticator) >>>>> >>>>> Hi there, >>>>> >>>>> I was recently playing with the PKCE support in Keycloak (server) which >>>>> worked quite well. >>>>> However the support for client / adapters seems to be quite limited at >>>>> the moment... >>>>> >>>>> I think support for PKCE to all? java adapters could be added quite >>>>> easily >>>>> - I could provide a >>>>> PR but I'm currently stuck with finding a generic way to store the >>>>> codeVerifier generated for the login redirect for later retrival for the >>>>> code2token exchange. >>>>> >>>>> Do you have any recommendations for this? >>>>> >>>>> I created the following JIRA issue (with some comments) to track this: >>>>> >>>>> https://clicktime.symantec.com/a/1/bkUjActRvyW1Ds3zoQSu7mjr4Nabixm_1YJAW4-UxEM=?d=d5OUWVTwLT2kMkuISm5qn8WHJTBcSVkENKzaB0Z2mA-PX8kp40LeKyOrcMpyKd841kYgP2EXaDDWYa0qu-AFLCtVLO4LvMfUJgUhu3xFwONMPy78dypmmmeEalkcYLU4XY3LcstbfVAoE0jRdEXXMyYStWwO95V_98pfhIYFlYFIHgapXJsFfGrldL8-siYGhinjnCn_AWyuyqrwhvBY582Dr3Pn9k4YZfsudBwcSJkErQKzyYEKfMhwz4ix7EAa-hvQ6rGHFdSza3jf1cMjsR4Xio667eNtirL9ruV4Z-FFQhamJMSJGb2o8rR52iEuGTp_28Vivk5HiwYx5XhZ4Bm9_dhN2eNeWT396bZQJwC7tDetr6UPVrPiMn6aTLdGMu6Wr-byBNvnEFmqxCB0Cx1tPxQkO4DVWKF4_iWgxZ6sW49k87BqaRTp3ktECRXNJ-CA04UZQbL7w-uPYlxvyvNNl408bCn5LpYf8w%3D%3D&u=https%3A%2F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-7467 >>>>> >>>>> Cheers, >>>>> Thomas >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev at lists.jboss.org >>>>> >>>>> https://clicktime.symantec.com/a/1/Xn2ffdZIVPL_UA8_cnNApcirkcZZdsnyb6SpUdKiO-s=?d=d5OUWVTwLT2kMkuISm5qn8WHJTBcSVkENKzaB0Z2mA-PX8kp40LeKyOrcMpyKd841kYgP2EXaDDWYa0qu-AFLCtVLO4LvMfUJgUhu3xFwONMPy78dypmmmeEalkcYLU4XY3LcstbfVAoE0jRdEXXMyYStWwO95V_98pfhIYFlYFIHgapXJsFfGrldL8-siYGhinjnCn_AWyuyqrwhvBY582Dr3Pn9k4YZfsudBwcSJkErQKzyYEKfMhwz4ix7EAa-hvQ6rGHFdSza3jf1cMjsR4Xio667eNtirL9ruV4Z-FFQhamJMSJGb2o8rR52iEuGTp_28Vivk5HiwYx5XhZ4Bm9_dhN2eNeWT396bZQJwC7tDetr6UPVrPiMn6aTLdGMu6Wr-byBNvnEFmqxCB0Cx1tPxQkO4DVWKF4_iWgxZ6sW49k87BqaRTp3ktECRXNJ-CA04UZQbL7w-uPYlxvyvNNl408bCn5LpYf8w%3D%3D&u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev >>>>> >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From hmlnarik at redhat.com Wed Jun 6 04:25:01 2018 From: hmlnarik at redhat.com (Hynek Mlnarik) Date: Wed, 6 Jun 2018 10:25:01 +0200 Subject: [keycloak-dev] Improve "Logout all" for the realm? Message-ID: On Wed, Jun 6, 2018 at 8:48 AM, Marek Posolda wrote: > On 06/06/18 08:28, Stian Thorgersen wrote: > > > > > > On 5 June 2018 at 22:13, Marek Posolda > > wrote: > > > > Hi, > > > > when you click on tab "Sessions", you can see the screen with the: > > - counts of Active Sessions > > - counts of Offline Sessions > > - Button "Logout All" > > > > See the screenshot how the screen currently looks like: > > https://pasteboard.co/HowNZ2I.png > > > > > We have the JIRA https://issues.jboss.org/browse/KEYCLOAK-7055 > > and the > > PR with the discussion > > https://github.com/keycloak/keycloak/pull/5126 > > . > > In shortcut, JIRA and PR points few issues: > > 1) There is no way to logout all active sessions only (Keep the > > offline > > sessions) > > > > 2) There is no way to logout all offline sessions only (Keep the > > active > > sessions) > > > > 3) When you click on the button, there is no confirmation dialog. It > > seems that "Logout all" is quite an important step and confirmation > > should be there. > > > > 4) When you click on the button, it will do something between. All > > active sessions are cleared from infinispan, but offline sessions are > > NOT cleared. There is just realm notBefore policy updated, which > > indirectly invalidates the offline sessions, but they are still > > kept in > > infinispan and DB, which itself is a bug IMO. > > > > So how to address all the issues? I can see something like this: > > - Instead of 1 button, have 3 buttons (Logout all active sessions, > > Logout all offline sessions, Logout all) > > > > > > Sounds good, but might look a bit messy with those long labels and 3 > > buttons. Do we need 3 buttons? Or is "Logout active" and "Logout > > offline" sufficient? Do we have a better term for non-offline than > active? > The thing is, that with "Logout active" and "Logout offline", you can't > update notBefore policy. If you update it, you always effectively > invalidate both kind of sessions. > > I was also thinking about keep the single button, but once confirmation > dialog is displayed, you will have 3 checkboxes in it (push not-before, > logout active, logout offline) and all checked by default. When you > uncheck "logout active" or "logout offline", it will also automatically > uncheck "push not-before" . In other words, "push not-before" always > require both other checkboxes checked due the reason above. > > Is it better regarding usability? I am not sure as admin won't see that > "Logout all" has more options until he clicks on it and dialog is > displayed? > I'd prefer this suggestion with checkboxes. > > > > > > - All the buttons will display confirmation dialog > > > > > > +1 > > > > - The "Logout all" will also update notBefore policy like it's > > done now. > > It will clear all the "Active" and "Offline" sessions from > > infinispan. > > This will be displayed in the confirmation dialog. So confirmation > > for > > "Logout all" will be like: "Do you want to logout all active sessions > > and offline sessions and update realm notBefore policy?" The other 2 > > buttons won't update not-before policy (we can't do that unless we > > have > > separate not-before for active sessions and for offline sessions, > > but I > > vote to not do that considering the required complexity of this). > +1 for not separating not-before for offline and active. > > > > > > Should it also clear sessions from the DB? > Yes > > > > > > - The message for "Logout all" will be sent to all the clients with > > adminUrl (which is already done). > > > > One related issue is, that currently we don't have a way to notify > > client applications that offline sessions were invalidated. I was > > thinking if we could have a way to register some listener for various > > adapter events (Logout all, logout all active/offline sessions, > > logout > > single active/offline session)? Client application can listen to the > > events and do something (EG. remove saved offline token from it's > DB). > > > > > > I'm not to keen on more bespoke logout protocols. Have we studied the > > OIDC backchannel/frontchannel specs yet? Is there a way to do this in > > a standard way? > Ok, true. I've looked at the specs some time ago, we already partially > implement something from them. > > I remember front-channel logout specs contains some interesting usage of > iframes (You will display single HTML page with the iframes, where each > iframe contains the URL to logout single client). Is it pretty > interesting stuff and seems to be much less error-prone than > chain-of-redirects approach, which SAML Front-channel logout uses. I've > proposed to support iframes for SAML Front-channel logout too some time > ago on this list. I think Bill and Hynek liked it. We just need to > implement those things :) > Yup, it would make things (a) parallel - hence faster, (b) less error-prone since redirect back to Keycloak is currently needed in SAML frontchannel logout and if some application fails to do that, the subsequent applications are not logged out. SAML frontchannel logout via iframes was almost implemented during cross-dc work but then abandoned because of time. The JIRA for that is [1] and contains the link to initial implementation. Just note that the implementation did not consider OIDC frontchannel logout draft and needs to be adjusted accordingly. --Hynek [1] https://issues.jboss.org/browse/KEYCLOAK-5449 From sblanc at redhat.com Wed Jun 6 04:55:24 2018 From: sblanc at redhat.com (Sebastien Blanc) Date: Wed, 6 Jun 2018 10:55:24 +0200 Subject: [keycloak-dev] Spring Security 5.1 - Resource Server support In-Reply-To: References: Message-ID: Josh, Thomas, I'm finally back from traveling and conferences and I'm trying to catch up a bit. Josh thanks for pointing to all the relevant tickets, I will track them. Thomas, does anything needs to happen on the KC Adapter side ? It's just to open tickets on our side so we can track it. Sebi On Tue, May 15, 2018 at 6:04 PM, Josh Cummings wrote: > Thomas, Sebi - > > Thanks for the feedback. > > I took your sample, Thomas, and was able to get it to work with our new > resource server code (which is not yet integrated with > @EnableResourceServer), though I will still check and see what might be the > problem with the existing support. I've got a partially-working sample > here, if you'd like to take a look: https://github.com/ > jzheaux/spring-security-oauth2-resource-server/blob/ > master/samples/boot/oauth2/resource-server/keycloak-with-client > > - Role extraction: Right now, you are already following the recommended > approach listed here in the documentation: https://docs. > spring.io/spring-security/site/docs/5.0.5.RELEASE/reference/htmlsingle/# > oauth2login-advanced-map-authorities-oauth2userservice It sounds like you > might be looking for something more targeted at extracting authorities from > an OidcUserRequest? I've just added a ticket with some of my thoughts: > https://github.com/spring-projects/spring-security/issues/5349 > > Since I think that the use case might be a little different on the > resource server side, I added a separate ticket for that: > https://github.com/jzheaux/spring-security-oauth2- > resource-server/issues/37 > > (If it's not too confusing, you can add tickets specifically related to > Resource Server to that dedicated repo) > > - Propagating logout to Keycloak: Thanks, added: https://github.com/ > spring-projects/spring-security/issues/5350 > > - Explicit configuration and Handling of access: You can track progress on > these two here: > https://github.com/spring-projects/spring-security/issues/4413 > https://github.com/spring-projects/spring-security/issues/4371 > > Regarding multi-tenancy, we don't have specific plans, though I did look > through your TenantAwareJwtDecoder and will continue thinking about this. > I've added a ticket to get the discussion started: https://github.com/ > spring-projects/spring-security/issues/5351 > > Josh > > On Fri, May 11, 2018 at 7:02 AM, Thomas Darimont < > thomas.darimont at googlemail.com> wrote: > >> Hi Josh, Hi Sebi, >> >> having proper support for OAuth2 @EnableResourceServer in Spring >> Security 5 would be very useful. >> It would also be great if an application could use SSO and Enable >> ResourceServer at the same time. >> >> I tried this with Spring Boot 2 and Spring Security 5 but I couldn't get >> it to work. >> >> I build a demo application that uses SSO based on the OpenID Connect >> from the latest >> Spring Security 5 in a Spring Boot 2 app without the need for a Keycloak-adapter >> library >> with very little custom code for making the integration work. >> Perhaps the example can help you to identify some gaps in the current >> Spring Security OAuth2 / OIDC APIs. >> The sources can be found here: https://github.com/thomasdarimont >> /spring-boot-2-keycloak-oauth-example >> >> Here are some things that I either had to add or that are currently not >> possible without more infrastructure plumbing: >> >> - Extracting and mapping of Keycloak roles to Spring Security roles. >> Would be great to have a dedicated API for this - needed to do some >> plumbing here. >> See: https://github.com/thomasdarimont/spring-boot-2-keycloak-oauth >> -example/blob/master/src/main/java/demo/SpringBoot2App.java#L155 >> >> - Propagating logout to Keycloak >> Could use the standardized OIDC "end_session_endpoint" from the >> .well-known/openid-configuration endpoint. >> See: https://github.com/thomasdarimont/spring-boot-2-keycloak-oauth >> -example/blob/master/src/main/java/demo/SpringBoot2App.java#L205 >> >> - Explicit configuration for oauth/oidc provider endpoints. >> Would be great to just use the wellknon endpoint (http://localhost:8080/ >> auth/realms/${realm}/.well-known/openid-configuration) >> This would ease configuration quite significantly. >> See: https://github.com/thomasdarimont/spring-boot-2-keycloak-oauth >> -example/blob/master/src/main/resources/application.yml#L23 >> >> - Handling of access / refresh token for service calls (currently missing) >> Currently spring security (tested with 5.0.4.RELEASE) does only extracts >> the IDToken / AccessToken from the OidcUserRequest >> but not the refresh token. This would be necessary to retrieve new >> AccessTokens for prolonged service interactions. >> >> Another topic is multi-tenancy support. For the example app mentioned >> above I have a special branch called feature/multi-tenancy >> that demonstrates a PoC of a hostname based approach for supporting >> multiple realms / tenants. >> Some of this is keycloak specific but I think this could be generalized >> to a degree where the Keycloak specific parts could be reduced >> to just a few lines of code / configuration. >> >> - Configuration >> See: https://github.com/thomasdarimont/spring-boot-2-keycloak-oauth >> -example/blob/feature/mulit-tenancy/src/main/resources/application.yml >> #L29 >> - Tenant selection >> See: https://github.com/thomasdarimont/spring-boot-2-keycloak-oauth >> -example/blob/feature/mulit-tenancy/src/main/java/demo/Spr >> ingBoot2App.java#L127 >> >> Cheers, >> Thomas >> >> Am Di., 8. Mai 2018 um 23:54 Uhr schrieb Sebastien Blanc < >> sblanc at redhat.com>: >> >>> Hi Josh ! >>> >>> Thanks for pinging us about this ! We really appreciate your offer to >>> collaborate. I will try ASAP playing with the new Spring Sec and share my >>> findings with you. >>> >>> Seb >>> >>> >>> Le mar. 8 mai 2018 ? 13:28, Josh Cummings a >>> ?crit : >>> >>> > Hi, >>> > >>> > I'm not sure if you already know, but the Spring Security Team is >>> > re-writing its support for OAuth2. We are planning on releasing initial >>> > Resource Server support in 5.1 this September. >>> > >>> > I'd love to collaborate with you guys, especially while you are in >>> beta, to >>> > see if what we are writing is complementary to your goals. Perhaps we >>> can >>> > help remove some of your boilerplate, etc., say from your Spring >>> Security >>> > adapter. >>> > >>> > https://github.com/jzheaux/spring-security-oauth2-resource-server >>> > >>> > This is sort of a sandbox repo for Spring Security's new Resource >>> Server >>> > support. >>> > >>> > Would love your feedback. I'll be updating the repo with some >>> integrated >>> > Keycloak samples in the next few days. >>> > >>> > Thanks, >>> > Josh >>> > >>> > -- >>> > Josh Cummings >>> > >>> > Software Engineer | Teacher | Pi Fanatic | >>> > https://www.linkedin.com/in/jzheaux | http://tech.joshuacummings.com >>> > >>> > _______________________________________________ >>> > keycloak-dev mailing list >>> > keycloak-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> > >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> > > > -- > Josh Cummings > > Software Engineer | Teacher | Pi Fanatic | https://www.linkedin.com/in/ > jzheaux | http://tech.joshuacummings.com | > @jzheaux > From hmlnarik at redhat.com Wed Jun 6 07:00:37 2018 From: hmlnarik at redhat.com (Hynek Mlnarik) Date: Wed, 6 Jun 2018 13:00:37 +0200 Subject: [keycloak-dev] Hosted domain for Google logins In-Reply-To: <2F976BA2-6E9F-44A7-AF17-49A3F3AD5A81@yieldlab.de> References: <0C91AD97-E639-4EB0-A166-5C476950E3C3@yieldlab.de> <2F976BA2-6E9F-44A7-AF17-49A3F3AD5A81@yieldlab.de> Message-ID: The issue has been fixed in latest master. On Sat, May 19, 2018 at 11:02 AM, Steffen Kreutz wrote: > Hi Thomas, > > unfortunately this didn?t work for me so I filed a bug report at > https://issues.jboss.org/browse/KEYCLOAK-7377 browse/KEYCLOAK-7377>. > > I added 'Locale.setDefault(Locale.ENGLISH);' to the ?initParser? method > of the test. > > Best, > > Steffen > > > Am 19.05.2018 um 10:45 schrieb Thomas Darimont < > thomas.darimont at googlemail.com>: > > > > Hello Steffen, > > > > maven forks a new jvm for tests, so you have to explicitly pass the jvm > arguments / system properties > > in the configuration of the surefire test plugin, see: > > http://maven.apache.org/surefire/maven-surefire-plugin/examples/system- > properties.html plugin/examples/system-properties.html> > > > > Would probably be a good idea to add the -Duser.country=EN > -Duser.language=en > > to the surefire plugin config in the Keycloak build for more stable > tests. > > > > E.g: > > > > > > > > org.apache.maven. > plugins > > maven-surefire- > plugin > > > > -Duser.country=EN > -Duser.language=en > > > > > > > > > > > > Cheers, > > Thomas > > > > Am Fr., 18. Mai 2018 um 22:58 Uhr schrieb Steffen Kreutz < > s.kreutz at yieldlab.de >: > > Hey Keycloak Devs, > > > > we would like to restrict access to accounts that are managed by our > company and therefore need to send the ?hd? to Google?s auth endpoint. I > saw that there is already a JIRA issue for that topic under > https://issues.jboss.org/browse/KEYCLOAK-5289 browse/KEYCLOAK-5289> https://issues.jboss.org/browse/KEYCLOAK-5289>>. If you agree, I would > like to take over it because I already implemented the change in our fork. > You can find the changes under https://github.com/yieldlab/ > keycloak/tree/hosted-domain-parameter-for-google-identity-provider < > https://github.com/yieldlab/keycloak/tree/hosted-domain- > parameter-for-google-identity-provider> keycloak/tree/hosted-domain-parameter-for-google-identity-provider < > https://github.com/yieldlab/keycloak/tree/hosted-domain- > parameter-for-google-identity-provider>>. > > > > Unfortunately the existing tests fail on my machine and therefore I > don?t want to create a PR yet. I think this is because my system?s locale > is German. The summary of the failing test is > > > > Failed tests: > > SAMLParserTest.testInvalidEndElement > > Expected: (an instance of org.keycloak.saml.common.exceptions.ParsingException > and exception with message a string containing "The element type > \"NameIDFormat\" must be terminated by the matching end-tag > \"\".") > > but: exception with message a string containing "The element type > \"NameIDFormat\" must be terminated by the matching end-tag > \"\"." message was "javax.xml.stream.XMLStreamException: > ParseError at [row,col]:[31,11] > > Message: Elementtyp "NameIDFormat" muss mit dem entsprechenden Endtag > "" beendet werden." > > > > This comes because the exception?s message is translated to German but > the test matches only the english version. Do you know about this? And what > can I do (without changing my system?s locale) to pass the test? I already > tried to pass '-Duser.country=DE -Duser.language=de? to Maven and the Maven > Surefire Plugin but it didn?t help. > > > > Best regards, > > > > Steffen Kreutz > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev < > https://lists.jboss.org/mailman/listinfo/keycloak-dev> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- --Hynek From sthorger at redhat.com Wed Jun 6 09:22:51 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 6 Jun 2018 15:22:51 +0200 Subject: [keycloak-dev] Testing with mocking libraries? In-Reply-To: References: <84bfae42-15d7-439e-ed41-e40d87a8bb7c@redhat.com> <3b8d21e0-7897-ddee-c8b6-34c742d9a512@redhat.com> Message-ID: I think we're in agreement here that the ideal is to do proper integration tests. Rather than open the doors for mocks (java based or http based) we should attempt to do it proper. For Google I'm not sure how realistic that is as the hd param probably requires an corporate account rather than a freebie account that we are using today for testing. We should investigate that first though. On 6 June 2018 at 10:03, Hynek Mlnarik wrote: > To answer the original question whether to mock or not to mock, I wouldn't > object allowing those in unit tests (which we have not that many though > until now there's no need to them and I hope we can preserve this state). > I'd rather not introduce those in integration tests because of maintenance > costs. > > The biggest issue I see with mocks is that one needs to be extra careful to > return exactly what's expected from the specification/counterparty. > Since social > providers can change without prior notice, our mocked IdPs might give us > false impression that we're testing them. Furthermore, such mocks would be > rather complex, and would require non-trivial maintenance. I'm hence biased > against mock IdPs and prefer the tests with real IdPs as mentioned by > Marek. > > > On Mon, Jun 4, 2018 at 11:22 AM, Marek Posolda > wrote: > > > Dne 1.6.2018 v 14:48 Bill Burke napsal(a): > > > On Fri, Jun 1, 2018 at 5:18 AM, Marek Posolda > > wrote: > > >> For IDP, I am not sure how would Mocked IDP help? We already have lots > > of > > >> test coverage for Identity brokering for OIDC and SAML. The social > > providers > > >> usually implements OAuth/OIDC and there are just small differences > > between > > >> them. But those small differences and the fact that social providers > > are out > > >> of our control, is exactly the reason why we need to test with real > > >> providers instead of mocks IMO. > > >> > > > IDP mocks are not a replacement for real testing. Just something that > > > would run in public CI, that way at least there's something to catch > > > issues like when/if brokering gets refactored again. > > AFAIK the longer-term plan is to run social tests on every PR, to catch > > regressions by testing with real social providers. So maybe it's better > > to rather wait until we have that rather then introduce mocks now? > > > > Also anyone from community should be able to run social tests based on > > our README. The important is, that someone could run it just for single > > provider, which he is interested in (EG. Google for this PR) and is not > > required to create the account+application in all social providers, > > which we support. But I hope the social tests already support this now. > > > > Marek > > > > > > Bill > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > -- > > --Hynek > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From s.kreutz at yieldlab.de Wed Jun 6 09:45:19 2018 From: s.kreutz at yieldlab.de (Steffen Kreutz) Date: Wed, 6 Jun 2018 15:45:19 +0200 Subject: [keycloak-dev] Testing with mocking libraries? In-Reply-To: References: <84bfae42-15d7-439e-ed41-e40d87a8bb7c@redhat.com> <3b8d21e0-7897-ddee-c8b6-34c742d9a512@redhat.com> Message-ID: You are right. Managing accounts with a custom domain requires a G Suite subscription which starts at 5$/month. > Am 06.06.2018 um 15:22 schrieb Stian Thorgersen : > > I think we're in agreement here that the ideal is to do proper integration > tests. Rather than open the doors for mocks (java based or http based) we > should attempt to do it proper. For Google I'm not sure how realistic that > is as the hd param probably requires an corporate account rather than a > freebie account that we are using today for testing. We should investigate > that first though. > > On 6 June 2018 at 10:03, Hynek Mlnarik wrote: > >> To answer the original question whether to mock or not to mock, I wouldn't >> object allowing those in unit tests (which we have not that many though >> until now there's no need to them and I hope we can preserve this state). >> I'd rather not introduce those in integration tests because of maintenance >> costs. >> >> The biggest issue I see with mocks is that one needs to be extra careful to >> return exactly what's expected from the specification/counterparty. >> Since social >> providers can change without prior notice, our mocked IdPs might give us >> false impression that we're testing them. Furthermore, such mocks would be >> rather complex, and would require non-trivial maintenance. I'm hence biased >> against mock IdPs and prefer the tests with real IdPs as mentioned by >> Marek. >> >> >> On Mon, Jun 4, 2018 at 11:22 AM, Marek Posolda >> wrote: >> >>> Dne 1.6.2018 v 14:48 Bill Burke napsal(a): >>>> On Fri, Jun 1, 2018 at 5:18 AM, Marek Posolda >>> wrote: >>>>> For IDP, I am not sure how would Mocked IDP help? We already have lots >>> of >>>>> test coverage for Identity brokering for OIDC and SAML. The social >>> providers >>>>> usually implements OAuth/OIDC and there are just small differences >>> between >>>>> them. But those small differences and the fact that social providers >>> are out >>>>> of our control, is exactly the reason why we need to test with real >>>>> providers instead of mocks IMO. >>>>> >>>> IDP mocks are not a replacement for real testing. Just something that >>>> would run in public CI, that way at least there's something to catch >>>> issues like when/if brokering gets refactored again. >>> AFAIK the longer-term plan is to run social tests on every PR, to catch >>> regressions by testing with real social providers. So maybe it's better >>> to rather wait until we have that rather then introduce mocks now? >>> >>> Also anyone from community should be able to run social tests based on >>> our README. The important is, that someone could run it just for single >>> provider, which he is interested in (EG. Google for this PR) and is not >>> required to create the account+application in all social providers, >>> which we support. But I hope the social tests already support this now. >>> >>> Marek >>>> >>>> Bill >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> >> >> -- >> >> --Hynek >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Wed Jun 6 10:17:55 2018 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 6 Jun 2018 16:17:55 +0200 Subject: [keycloak-dev] Testing with mocking libraries? In-Reply-To: References: <84bfae42-15d7-439e-ed41-e40d87a8bb7c@redhat.com> <3b8d21e0-7897-ddee-c8b6-34c742d9a512@redhat.com> Message-ID: +1 for investigate. I hope the contributor can help us with clarifying it and write the test? Maybe the test for this will need to be in separate class, so it's possible to test it separately from the other Google IDP stuff, which can be tested with free account. And the other contributors to Google IDP, which don't have corporate account, won't be blocked. But I suppose that for our CI, we can test with "redhat.com" domain account? Marek On 06/06/18 15:22, Stian Thorgersen wrote: > I think we're in agreement here that the ideal is to do proper > integration tests. Rather than open the doors for mocks (java based or > http based) we should attempt to do it proper. For Google I'm not sure > how realistic that is as the hd param probably requires an corporate > account rather than a freebie account that we are using today for > testing. We should investigate that first though. > > On 6 June 2018 at 10:03, Hynek Mlnarik > wrote: > > To answer the original question whether to mock or not to mock, I > wouldn't > object allowing those in unit tests (which we have not that many > though > until now there's no need to them and I hope we can preserve this > state). > I'd rather not introduce those in integration tests because of > maintenance > costs. > > The biggest issue I see with mocks is that one needs to be extra > careful to > return exactly what's expected from the specification/counterparty. > Since social > providers? can change without prior notice, our mocked IdPs might > give us > false impression that we're testing them. Furthermore, such mocks > would be > rather complex, and would require non-trivial maintenance. I'm > hence biased > against mock IdPs and prefer the tests with real IdPs as mentioned > by Marek. > > > On Mon, Jun 4, 2018 at 11:22 AM, Marek Posolda > > wrote: > > > Dne 1.6.2018 v 14:48 Bill Burke napsal(a): > > > On Fri, Jun 1, 2018 at 5:18 AM, Marek Posolda > > > > wrote: > > >> For IDP, I am not sure how would Mocked IDP help? We already > have lots > > of > > >> test coverage for Identity brokering for OIDC and SAML. The > social > > providers > > >> usually implements OAuth/OIDC and there are just small > differences > > between > > >> them. But those small differences and the fact that social > providers > > are out > > >> of our control, is exactly the reason why we need to test > with real > > >> providers instead of mocks IMO. > > >> > > > IDP mocks are not a replacement for real testing.? Just > something that > > > would run in public CI, that way at least there's something to > catch > > > issues like when/if brokering gets refactored again. > > AFAIK the longer-term plan is to run social tests on every PR, > to catch > > regressions by testing with real social providers. So maybe it's > better > > to rather wait until we have that rather then introduce mocks now? > > > > Also anyone from community should be able to run social tests > based on > > our README. The important is, that someone could run it just for > single > > provider, which he is interested in (EG. Google for this PR) and > is not > > required to create the account+application in all social providers, > > which we support. But I hope the social tests already support > this now. > > > > Marek > > > > > > Bill > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > -- > > --Hynek > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > From s.kreutz at yieldlab.de Thu Jun 7 04:11:18 2018 From: s.kreutz at yieldlab.de (Steffen Kreutz) Date: Thu, 7 Jun 2018 10:11:18 +0200 Subject: [keycloak-dev] Testing with mocking libraries? In-Reply-To: References: <84bfae42-15d7-439e-ed41-e40d87a8bb7c@redhat.com> <3b8d21e0-7897-ddee-c8b6-34c742d9a512@redhat.com> Message-ID: <09743259-2A19-4DAA-BC08-C7440896B88F@yieldlab.de> I will remove the unit tests and mocking stuff from the PR and create integration tests. Would it be sufficient to test if logging in succeeds for an account with a valid domain and accordingly fails for an account with an invalid domain? Or should I somehow test if the token contains the hd param. > Am 06.06.2018 um 16:17 schrieb Marek Posolda : > > +1 for investigate. I hope the contributor can help us with clarifying > it and write the test? > > Maybe the test for this will need to be in separate class, so it's > possible to test it separately from the other Google IDP stuff, which > can be tested with free account. And the other contributors to Google > IDP, which don't have corporate account, won't be blocked. > > But I suppose that for our CI, we can test with "redhat.com" domain account? > > Marek > > > On 06/06/18 15:22, Stian Thorgersen wrote: >> I think we're in agreement here that the ideal is to do proper >> integration tests. Rather than open the doors for mocks (java based or >> http based) we should attempt to do it proper. For Google I'm not sure >> how realistic that is as the hd param probably requires an corporate >> account rather than a freebie account that we are using today for >> testing. We should investigate that first though. >> >> On 6 June 2018 at 10:03, Hynek Mlnarik > > wrote: >> >> To answer the original question whether to mock or not to mock, I >> wouldn't >> object allowing those in unit tests (which we have not that many >> though >> until now there's no need to them and I hope we can preserve this >> state). >> I'd rather not introduce those in integration tests because of >> maintenance >> costs. >> >> The biggest issue I see with mocks is that one needs to be extra >> careful to >> return exactly what's expected from the specification/counterparty. >> Since social >> providers can change without prior notice, our mocked IdPs might >> give us >> false impression that we're testing them. Furthermore, such mocks >> would be >> rather complex, and would require non-trivial maintenance. I'm >> hence biased >> against mock IdPs and prefer the tests with real IdPs as mentioned >> by Marek. >> >> >> On Mon, Jun 4, 2018 at 11:22 AM, Marek Posolda >> > wrote: >> >>> Dne 1.6.2018 v 14:48 Bill Burke napsal(a): >>>> On Fri, Jun 1, 2018 at 5:18 AM, Marek Posolda >> > >>> wrote: >>>>> For IDP, I am not sure how would Mocked IDP help? We already >> have lots >>> of >>>>> test coverage for Identity brokering for OIDC and SAML. The >> social >>> providers >>>>> usually implements OAuth/OIDC and there are just small >> differences >>> between >>>>> them. But those small differences and the fact that social >> providers >>> are out >>>>> of our control, is exactly the reason why we need to test >> with real >>>>> providers instead of mocks IMO. >>>>> >>>> IDP mocks are not a replacement for real testing. Just >> something that >>>> would run in public CI, that way at least there's something to >> catch >>>> issues like when/if brokering gets refactored again. >>> AFAIK the longer-term plan is to run social tests on every PR, >> to catch >>> regressions by testing with real social providers. So maybe it's >> better >>> to rather wait until we have that rather then introduce mocks now? >>> >>> Also anyone from community should be able to run social tests >> based on >>> our README. The important is, that someone could run it just for >> single >>> provider, which he is interested in (EG. Google for this PR) and >> is not >>> required to create the account+application in all social providers, >>> which we support. But I hope the social tests already support >> this now. >>> >>> Marek >>>> >>>> Bill >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >>> >> >> >> >> -- >> >> --Hynek >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From s.kreutz at yieldlab.de Thu Jun 7 06:33:08 2018 From: s.kreutz at yieldlab.de (Steffen Kreutz) Date: Thu, 7 Jun 2018 12:33:08 +0200 Subject: [keycloak-dev] Testing with mocking libraries? In-Reply-To: <09743259-2A19-4DAA-BC08-C7440896B88F@yieldlab.de> References: <84bfae42-15d7-439e-ed41-e40d87a8bb7c@redhat.com> <3b8d21e0-7897-ddee-c8b6-34c742d9a512@redhat.com> <09743259-2A19-4DAA-BC08-C7440896B88F@yieldlab.de> Message-ID: <354F561E-87D0-429D-B449-4CB23FEDE1F0@yieldlab.de> I updated the PR with the SocialLoginTest (https://github.com/keycloak/keycloak/pull/5215/files#diff-d1c89a9cccb653905cf757d2dcb67841 ). Please tell me if this is done correctly. Best, Steffen > Am 07.06.2018 um 10:11 schrieb Steffen Kreutz : > > I will remove the unit tests and mocking stuff from the PR and create integration tests. > > Would it be sufficient to test if logging in succeeds for an account with a valid domain and accordingly fails for an account with an invalid domain? Or should I somehow test if the token contains the hd param. > > >> Am 06.06.2018 um 16:17 schrieb Marek Posolda : >> >> +1 for investigate. I hope the contributor can help us with clarifying >> it and write the test? >> >> Maybe the test for this will need to be in separate class, so it's >> possible to test it separately from the other Google IDP stuff, which >> can be tested with free account. And the other contributors to Google >> IDP, which don't have corporate account, won't be blocked. >> >> But I suppose that for our CI, we can test with "redhat.com" domain account? >> >> Marek >> >> >> On 06/06/18 15:22, Stian Thorgersen wrote: >>> I think we're in agreement here that the ideal is to do proper >>> integration tests. Rather than open the doors for mocks (java based or >>> http based) we should attempt to do it proper. For Google I'm not sure >>> how realistic that is as the hd param probably requires an corporate >>> account rather than a freebie account that we are using today for >>> testing. We should investigate that first though. >>> >>> On 6 June 2018 at 10:03, Hynek Mlnarik >> > wrote: >>> >>> To answer the original question whether to mock or not to mock, I >>> wouldn't >>> object allowing those in unit tests (which we have not that many >>> though >>> until now there's no need to them and I hope we can preserve this >>> state). >>> I'd rather not introduce those in integration tests because of >>> maintenance >>> costs. >>> >>> The biggest issue I see with mocks is that one needs to be extra >>> careful to >>> return exactly what's expected from the specification/counterparty. >>> Since social >>> providers can change without prior notice, our mocked IdPs might >>> give us >>> false impression that we're testing them. Furthermore, such mocks >>> would be >>> rather complex, and would require non-trivial maintenance. I'm >>> hence biased >>> against mock IdPs and prefer the tests with real IdPs as mentioned >>> by Marek. >>> >>> >>> On Mon, Jun 4, 2018 at 11:22 AM, Marek Posolda >>> > wrote: >>> >>>> Dne 1.6.2018 v 14:48 Bill Burke napsal(a): >>>>> On Fri, Jun 1, 2018 at 5:18 AM, Marek Posolda >>> > >>>> wrote: >>>>>> For IDP, I am not sure how would Mocked IDP help? We already >>> have lots >>>> of >>>>>> test coverage for Identity brokering for OIDC and SAML. The >>> social >>>> providers >>>>>> usually implements OAuth/OIDC and there are just small >>> differences >>>> between >>>>>> them. But those small differences and the fact that social >>> providers >>>> are out >>>>>> of our control, is exactly the reason why we need to test >>> with real >>>>>> providers instead of mocks IMO. >>>>>> >>>>> IDP mocks are not a replacement for real testing. Just >>> something that >>>>> would run in public CI, that way at least there's something to >>> catch >>>>> issues like when/if brokering gets refactored again. >>>> AFAIK the longer-term plan is to run social tests on every PR, >>> to catch >>>> regressions by testing with real social providers. So maybe it's >>> better >>>> to rather wait until we have that rather then introduce mocks now? >>>> >>>> Also anyone from community should be able to run social tests >>> based on >>>> our README. The important is, that someone could run it just for >>> single >>>> provider, which he is interested in (EG. Google for this PR) and >>> is not >>>> required to create the account+application in all social providers, >>>> which we support. But I hope the social tests already support >>> this now. >>>> >>>> Marek >>>>> >>>>> Bill >>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>>> >>> >>> >>> >>> -- >>> >>> --Hynek >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Thu Jun 7 15:20:25 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 7 Jun 2018 21:20:25 +0200 Subject: [keycloak-dev] Testing with mocking libraries? In-Reply-To: <09743259-2A19-4DAA-BC08-C7440896B88F@yieldlab.de> References: <84bfae42-15d7-439e-ed41-e40d87a8bb7c@redhat.com> <3b8d21e0-7897-ddee-c8b6-34c742d9a512@redhat.com> <09743259-2A19-4DAA-BC08-C7440896B88F@yieldlab.de> Message-ID: On 7 June 2018 at 10:11, Steffen Kreutz wrote: > I will remove the unit tests and mocking stuff from the PR and create > integration tests. > Great, thanks > > Would it be sufficient to test if logging in succeeds for an account with > a valid domain and accordingly fails for an account with an invalid domain? > Or should I somehow test if the token contains the hd param. > Your code already checks if the hd param in the token matches the requested hd though doesn't it? So testing valid/invalid domain seems sufficient to me. > > > > Am 06.06.2018 um 16:17 schrieb Marek Posolda : > > > > +1 for investigate. I hope the contributor can help us with clarifying > > it and write the test? > > > > Maybe the test for this will need to be in separate class, so it's > > possible to test it separately from the other Google IDP stuff, which > > can be tested with free account. And the other contributors to Google > > IDP, which don't have corporate account, won't be blocked. > > > > But I suppose that for our CI, we can test with "redhat.com" domain > account? > > > > Marek > > > > > > On 06/06/18 15:22, Stian Thorgersen wrote: > >> I think we're in agreement here that the ideal is to do proper > >> integration tests. Rather than open the doors for mocks (java based or > >> http based) we should attempt to do it proper. For Google I'm not sure > >> how realistic that is as the hd param probably requires an corporate > >> account rather than a freebie account that we are using today for > >> testing. We should investigate that first though. > >> > >> On 6 June 2018 at 10:03, Hynek Mlnarik >> > wrote: > >> > >> To answer the original question whether to mock or not to mock, I > >> wouldn't > >> object allowing those in unit tests (which we have not that many > >> though > >> until now there's no need to them and I hope we can preserve this > >> state). > >> I'd rather not introduce those in integration tests because of > >> maintenance > >> costs. > >> > >> The biggest issue I see with mocks is that one needs to be extra > >> careful to > >> return exactly what's expected from the specification/counterparty. > >> Since social > >> providers can change without prior notice, our mocked IdPs might > >> give us > >> false impression that we're testing them. Furthermore, such mocks > >> would be > >> rather complex, and would require non-trivial maintenance. I'm > >> hence biased > >> against mock IdPs and prefer the tests with real IdPs as mentioned > >> by Marek. > >> > >> > >> On Mon, Jun 4, 2018 at 11:22 AM, Marek Posolda > >> > wrote: > >> > >>> Dne 1.6.2018 v 14:48 Bill Burke napsal(a): > >>>> On Fri, Jun 1, 2018 at 5:18 AM, Marek Posolda > >> > > >>> wrote: > >>>>> For IDP, I am not sure how would Mocked IDP help? We already > >> have lots > >>> of > >>>>> test coverage for Identity brokering for OIDC and SAML. The > >> social > >>> providers > >>>>> usually implements OAuth/OIDC and there are just small > >> differences > >>> between > >>>>> them. But those small differences and the fact that social > >> providers > >>> are out > >>>>> of our control, is exactly the reason why we need to test > >> with real > >>>>> providers instead of mocks IMO. > >>>>> > >>>> IDP mocks are not a replacement for real testing. Just > >> something that > >>>> would run in public CI, that way at least there's something to > >> catch > >>>> issues like when/if brokering gets refactored again. > >>> AFAIK the longer-term plan is to run social tests on every PR, > >> to catch > >>> regressions by testing with real social providers. So maybe it's > >> better > >>> to rather wait until we have that rather then introduce mocks now? > >>> > >>> Also anyone from community should be able to run social tests > >> based on > >>> our README. The important is, that someone could run it just for > >> single > >>> provider, which he is interested in (EG. Google for this PR) and > >> is not > >>> required to create the account+application in all social providers, > >>> which we support. But I hope the social tests already support > >> this now. > >>> > >>> Marek > >>>> > >>>> Bill > >>> > >>> > >>> _______________________________________________ > >>> keycloak-dev mailing list > >>> keycloak-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >>> > >> > >> > >> > >> -- > >> > >> --Hynek > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >> > >> > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From s.kreutz at yieldlab.de Thu Jun 7 15:52:37 2018 From: s.kreutz at yieldlab.de (Steffen Kreutz) Date: Thu, 7 Jun 2018 21:52:37 +0200 Subject: [keycloak-dev] Testing with mocking libraries? In-Reply-To: References: <84bfae42-15d7-439e-ed41-e40d87a8bb7c@redhat.com> <3b8d21e0-7897-ddee-c8b6-34c742d9a512@redhat.com> <09743259-2A19-4DAA-BC08-C7440896B88F@yieldlab.de> Message-ID: Yes, this must be done inside the identity provider when Google sends the token because attackers might intercept the request and change the hd parameter. Unfortunately the integration tests failed randomly on Travis without showing any output. In my first run it were TESTS=server-group4 and TESTS=old and in the second TESTS=server-group1, TESTS=server-group2 and TESTS=server-group4. Could this be related to my changes? Best, Steffen Stian Thorgersen schrieb am Do., 7. Juni 2018, 21:20: > > > On 7 June 2018 at 10:11, Steffen Kreutz wrote: > >> I will remove the unit tests and mocking stuff from the PR and create >> integration tests. >> > > Great, thanks > > >> >> Would it be sufficient to test if logging in succeeds for an account with >> a valid domain and accordingly fails for an account with an invalid domain? >> Or should I somehow test if the token contains the hd param. >> > > Your code already checks if the hd param in the token matches the > requested hd though doesn't it? So testing valid/invalid domain seems > sufficient to me. > > >> >> >> > Am 06.06.2018 um 16:17 schrieb Marek Posolda : >> > >> > +1 for investigate. I hope the contributor can help us with clarifying >> > it and write the test? >> > >> > Maybe the test for this will need to be in separate class, so it's >> > possible to test it separately from the other Google IDP stuff, which >> > can be tested with free account. And the other contributors to Google >> > IDP, which don't have corporate account, won't be blocked. >> > >> > But I suppose that for our CI, we can test with "redhat.com" domain >> account? >> > >> > Marek >> > >> > >> > On 06/06/18 15:22, Stian Thorgersen wrote: >> >> I think we're in agreement here that the ideal is to do proper >> >> integration tests. Rather than open the doors for mocks (java based or >> >> http based) we should attempt to do it proper. For Google I'm not sure >> >> how realistic that is as the hd param probably requires an corporate >> >> account rather than a freebie account that we are using today for >> >> testing. We should investigate that first though. >> >> >> >> On 6 June 2018 at 10:03, Hynek Mlnarik > >> > wrote: >> >> >> >> To answer the original question whether to mock or not to mock, I >> >> wouldn't >> >> object allowing those in unit tests (which we have not that many >> >> though >> >> until now there's no need to them and I hope we can preserve this >> >> state). >> >> I'd rather not introduce those in integration tests because of >> >> maintenance >> >> costs. >> >> >> >> The biggest issue I see with mocks is that one needs to be extra >> >> careful to >> >> return exactly what's expected from the specification/counterparty. >> >> Since social >> >> providers can change without prior notice, our mocked IdPs might >> >> give us >> >> false impression that we're testing them. Furthermore, such mocks >> >> would be >> >> rather complex, and would require non-trivial maintenance. I'm >> >> hence biased >> >> against mock IdPs and prefer the tests with real IdPs as mentioned >> >> by Marek. >> >> >> >> >> >> On Mon, Jun 4, 2018 at 11:22 AM, Marek Posolda >> >> > wrote: >> >> >> >>> Dne 1.6.2018 v 14:48 Bill Burke napsal(a): >> >>>> On Fri, Jun 1, 2018 at 5:18 AM, Marek Posolda >> >> > >> >>> wrote: >> >>>>> For IDP, I am not sure how would Mocked IDP help? We already >> >> have lots >> >>> of >> >>>>> test coverage for Identity brokering for OIDC and SAML. The >> >> social >> >>> providers >> >>>>> usually implements OAuth/OIDC and there are just small >> >> differences >> >>> between >> >>>>> them. But those small differences and the fact that social >> >> providers >> >>> are out >> >>>>> of our control, is exactly the reason why we need to test >> >> with real >> >>>>> providers instead of mocks IMO. >> >>>>> >> >>>> IDP mocks are not a replacement for real testing. Just >> >> something that >> >>>> would run in public CI, that way at least there's something to >> >> catch >> >>>> issues like when/if brokering gets refactored again. >> >>> AFAIK the longer-term plan is to run social tests on every PR, >> >> to catch >> >>> regressions by testing with real social providers. So maybe it's >> >> better >> >>> to rather wait until we have that rather then introduce mocks now? >> >>> >> >>> Also anyone from community should be able to run social tests >> >> based on >> >>> our README. The important is, that someone could run it just for >> >> single >> >>> provider, which he is interested in (EG. Google for this PR) and >> >> is not >> >>> required to create the account+application in all social providers, >> >>> which we support. But I hope the social tests already support >> >> this now. >> >>> >> >>> Marek >> >>>> >> >>>> Bill >> >>> >> >>> >> >>> _______________________________________________ >> >>> keycloak-dev mailing list >> >>> keycloak-dev at lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >>> >> >> >> >> >> >> >> >> -- >> >> >> >> --Hynek >> >> _______________________________________________ >> >> keycloak-dev mailing list >> >> keycloak-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> >> >> >> >> > >> > _______________________________________________ >> > keycloak-dev mailing list >> > keycloak-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > From sthorger at redhat.com Fri Jun 8 02:01:56 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 8 Jun 2018 08:01:56 +0200 Subject: [keycloak-dev] Testing with mocking libraries? In-Reply-To: References: <84bfae42-15d7-439e-ed41-e40d87a8bb7c@redhat.com> <3b8d21e0-7897-ddee-c8b6-34c742d9a512@redhat.com> <09743259-2A19-4DAA-BC08-C7440896B88F@yieldlab.de> Message-ID: Looks like a temporary connection issue as it was failing before running any tests. I've rescheduled the tests. Can you provide some details on what we need to run the SocialLoginTest now? On 7 June 2018 at 21:52, Steffen Kreutz wrote: > Yes, this must be done inside the identity provider when Google sends the > token because attackers might intercept the request and change the hd > parameter. > > Unfortunately the integration tests failed randomly on Travis without > showing any output. In my first run it were TESTS=server-group4 and > TESTS=old and in the second TESTS=server-group1, TESTS=server-group2 and TESTS=server-group4. > Could this be related to my changes? > > Best, > > Steffen > > > Stian Thorgersen schrieb am Do., 7. Juni 2018, > 21:20: > >> >> >> On 7 June 2018 at 10:11, Steffen Kreutz wrote: >> >>> I will remove the unit tests and mocking stuff from the PR and create >>> integration tests. >>> >> >> Great, thanks >> >> >>> >>> Would it be sufficient to test if logging in succeeds for an account >>> with a valid domain and accordingly fails for an account with an invalid >>> domain? Or should I somehow test if the token contains the hd param. >>> >> >> Your code already checks if the hd param in the token matches the >> requested hd though doesn't it? So testing valid/invalid domain seems >> sufficient to me. >> >> >>> >>> >>> > Am 06.06.2018 um 16:17 schrieb Marek Posolda : >>> > >>> > +1 for investigate. I hope the contributor can help us with clarifying >>> > it and write the test? >>> > >>> > Maybe the test for this will need to be in separate class, so it's >>> > possible to test it separately from the other Google IDP stuff, which >>> > can be tested with free account. And the other contributors to Google >>> > IDP, which don't have corporate account, won't be blocked. >>> > >>> > But I suppose that for our CI, we can test with "redhat.com" domain >>> account? >>> > >>> > Marek >>> > >>> > >>> > On 06/06/18 15:22, Stian Thorgersen wrote: >>> >> I think we're in agreement here that the ideal is to do proper >>> >> integration tests. Rather than open the doors for mocks (java based >>> or >>> >> http based) we should attempt to do it proper. For Google I'm not >>> sure >>> >> how realistic that is as the hd param probably requires an corporate >>> >> account rather than a freebie account that we are using today for >>> >> testing. We should investigate that first though. >>> >> >>> >> On 6 June 2018 at 10:03, Hynek Mlnarik >> >> > wrote: >>> >> >>> >> To answer the original question whether to mock or not to mock, I >>> >> wouldn't >>> >> object allowing those in unit tests (which we have not that many >>> >> though >>> >> until now there's no need to them and I hope we can preserve this >>> >> state). >>> >> I'd rather not introduce those in integration tests because of >>> >> maintenance >>> >> costs. >>> >> >>> >> The biggest issue I see with mocks is that one needs to be extra >>> >> careful to >>> >> return exactly what's expected from the specification/counterparty. >>> >> Since social >>> >> providers can change without prior notice, our mocked IdPs might >>> >> give us >>> >> false impression that we're testing them. Furthermore, such mocks >>> >> would be >>> >> rather complex, and would require non-trivial maintenance. I'm >>> >> hence biased >>> >> against mock IdPs and prefer the tests with real IdPs as mentioned >>> >> by Marek. >>> >> >>> >> >>> >> On Mon, Jun 4, 2018 at 11:22 AM, Marek Posolda >>> >> > wrote: >>> >> >>> >>> Dne 1.6.2018 v 14:48 Bill Burke napsal(a): >>> >>>> On Fri, Jun 1, 2018 at 5:18 AM, Marek Posolda >>> >> > >>> >>> wrote: >>> >>>>> For IDP, I am not sure how would Mocked IDP help? We already >>> >> have lots >>> >>> of >>> >>>>> test coverage for Identity brokering for OIDC and SAML. The >>> >> social >>> >>> providers >>> >>>>> usually implements OAuth/OIDC and there are just small >>> >> differences >>> >>> between >>> >>>>> them. But those small differences and the fact that social >>> >> providers >>> >>> are out >>> >>>>> of our control, is exactly the reason why we need to test >>> >> with real >>> >>>>> providers instead of mocks IMO. >>> >>>>> >>> >>>> IDP mocks are not a replacement for real testing. Just >>> >> something that >>> >>>> would run in public CI, that way at least there's something to >>> >> catch >>> >>>> issues like when/if brokering gets refactored again. >>> >>> AFAIK the longer-term plan is to run social tests on every PR, >>> >> to catch >>> >>> regressions by testing with real social providers. So maybe it's >>> >> better >>> >>> to rather wait until we have that rather then introduce mocks now? >>> >>> >>> >>> Also anyone from community should be able to run social tests >>> >> based on >>> >>> our README. The important is, that someone could run it just for >>> >> single >>> >>> provider, which he is interested in (EG. Google for this PR) and >>> >> is not >>> >>> required to create the account+application in all social providers, >>> >>> which we support. But I hope the social tests already support >>> >> this now. >>> >>> >>> >>> Marek >>> >>>> >>> >>>> Bill >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> keycloak-dev mailing list >>> >>> keycloak-dev at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> >>> >> --Hynek >>> >> _______________________________________________ >>> >> keycloak-dev mailing list >>> >> keycloak-dev at lists.jboss.org >>> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >>> >> >>> >> >>> > >>> > _______________________________________________ >>> > keycloak-dev mailing list >>> > keycloak-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> From s.kreutz at yieldlab.de Fri Jun 8 02:21:47 2018 From: s.kreutz at yieldlab.de (Steffen Kreutz) Date: Fri, 8 Jun 2018 08:21:47 +0200 Subject: [keycloak-dev] Testing with mocking libraries? In-Reply-To: References: <84bfae42-15d7-439e-ed41-e40d87a8bb7c@redhat.com> <3b8d21e0-7897-ddee-c8b6-34c742d9a512@redhat.com> <09743259-2A19-4DAA-BC08-C7440896B88F@yieldlab.de> Message-ID: <76738D1C-C8A5-423D-90CD-BCC632D87759@yieldlab.de> Sorry I forgot that. First you need a G Suite account with a custom domain. If you have that you need to configure the account in social.properties. This is what I used: common.username=steffen at example.com common.password=iiQGV9xZ3muF6NK7 common.profile.firstName=Steffen common.profile.lastName=Kreutz common.profile.email=steffen at example.com google-hosted-domain.clientId= google-hosted-domain.clientSecret= google-hosted-domain.hostedDomain=example.com > Am 08.06.2018 um 08:01 schrieb Stian Thorgersen : > > Looks like a temporary connection issue as it was failing before running any tests. I've rescheduled the tests. Can you provide some details on what we need to run the SocialLoginTest now? > > On 7 June 2018 at 21:52, Steffen Kreutz > wrote: > Yes, this must be done inside the identity provider when Google sends the token because attackers might intercept the request and change the hd parameter. > > Unfortunately the integration tests failed randomly on Travis without showing any output. In my first run it were TESTS=server-group4 and TESTS=old and in the second TESTS=server-group1, TESTS=server-group2 and TESTS=server-group4. Could this be related to my changes? > > Best, > > Steffen > > > Stian Thorgersen > schrieb am Do., 7. Juni 2018, 21:20: > > > On 7 June 2018 at 10:11, Steffen Kreutz > wrote: > I will remove the unit tests and mocking stuff from the PR and create integration tests. > > Great, thanks > > > Would it be sufficient to test if logging in succeeds for an account with a valid domain and accordingly fails for an account with an invalid domain? Or should I somehow test if the token contains the hd param. > > Your code already checks if the hd param in the token matches the requested hd though doesn't it? So testing valid/invalid domain seems sufficient to me. > > > > > Am 06.06.2018 um 16:17 schrieb Marek Posolda >: > > > > +1 for investigate. I hope the contributor can help us with clarifying > > it and write the test? > > > > Maybe the test for this will need to be in separate class, so it's > > possible to test it separately from the other Google IDP stuff, which > > can be tested with free account. And the other contributors to Google > > IDP, which don't have corporate account, won't be blocked. > > > > But I suppose that for our CI, we can test with "redhat.com " domain account? > > > > Marek > > > > > > On 06/06/18 15:22, Stian Thorgersen wrote: > >> I think we're in agreement here that the ideal is to do proper > >> integration tests. Rather than open the doors for mocks (java based or > >> http based) we should attempt to do it proper. For Google I'm not sure > >> how realistic that is as the hd param probably requires an corporate > >> account rather than a freebie account that we are using today for > >> testing. We should investigate that first though. > >> > >> On 6 June 2018 at 10:03, Hynek Mlnarik > >> >> wrote: > >> > >> To answer the original question whether to mock or not to mock, I > >> wouldn't > >> object allowing those in unit tests (which we have not that many > >> though > >> until now there's no need to them and I hope we can preserve this > >> state). > >> I'd rather not introduce those in integration tests because of > >> maintenance > >> costs. > >> > >> The biggest issue I see with mocks is that one needs to be extra > >> careful to > >> return exactly what's expected from the specification/counterparty. > >> Since social > >> providers can change without prior notice, our mocked IdPs might > >> give us > >> false impression that we're testing them. Furthermore, such mocks > >> would be > >> rather complex, and would require non-trivial maintenance. I'm > >> hence biased > >> against mock IdPs and prefer the tests with real IdPs as mentioned > >> by Marek. > >> > >> > >> On Mon, Jun 4, 2018 at 11:22 AM, Marek Posolda > >> >> wrote: > >> > >>> Dne 1.6.2018 v 14:48 Bill Burke napsal(a): > >>>> On Fri, Jun 1, 2018 at 5:18 AM, Marek Posolda > >> >> > >>> wrote: > >>>>> For IDP, I am not sure how would Mocked IDP help? We already > >> have lots > >>> of > >>>>> test coverage for Identity brokering for OIDC and SAML. The > >> social > >>> providers > >>>>> usually implements OAuth/OIDC and there are just small > >> differences > >>> between > >>>>> them. But those small differences and the fact that social > >> providers > >>> are out > >>>>> of our control, is exactly the reason why we need to test > >> with real > >>>>> providers instead of mocks IMO. > >>>>> > >>>> IDP mocks are not a replacement for real testing. Just > >> something that > >>>> would run in public CI, that way at least there's something to > >> catch > >>>> issues like when/if brokering gets refactored again. > >>> AFAIK the longer-term plan is to run social tests on every PR, > >> to catch > >>> regressions by testing with real social providers. So maybe it's > >> better > >>> to rather wait until we have that rather then introduce mocks now? > >>> > >>> Also anyone from community should be able to run social tests > >> based on > >>> our README. The important is, that someone could run it just for > >> single > >>> provider, which he is interested in (EG. Google for this PR) and > >> is not > >>> required to create the account+application in all social providers, > >>> which we support. But I hope the social tests already support > >> this now. > >>> > >>> Marek > >>>> > >>>> Bill > >>> > >>> > >>> _______________________________________________ > >>> keycloak-dev mailing list > >>> keycloak-dev at lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > >>> > >> > >> > >> > >> -- > >> > >> --Hynek > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > >> > >> > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > From mposolda at redhat.com Fri Jun 8 10:24:26 2018 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 8 Jun 2018 16:24:26 +0200 Subject: [keycloak-dev] Client scopes PR rebased, Documentation added In-Reply-To: References: <192e966e-6a07-aac8-5b56-46c170ee4d40@redhat.com> Message-ID: <67580bc0-c0d8-6c05-e57c-77dea94efc31@redhat.com> Thanks Bill, Vlasta and Matthew for the review and re-check databases. ClientScopes PR is in master as well as documentation is in docs master. Summary of the changes in this old email: http://lists.jboss.org/pipermail/keycloak-dev/2018-March/010528.html Marek On 05/06/18 16:22, Bill Burke wrote: > I'll take a look this afternoon, my time. > > On Tue, Jun 5, 2018 at 6:49 AM, Marek Posolda wrote: >> I've did a rebase of client scopes PR [1] against latest master. Also >> did the documentation for it in the PR [2] . >> >> Anyone has a time to review? TBH I hope it's sorted soon as it changes >> 291 files, so there is quite a chance for the conflict with every other >> PR send. And rebasing (which I already did 2 or 3 times) is quite a pain ;) >> >> [1] https://github.com/keycloak/keycloak/pull/5076 >> [2] https://github.com/keycloak/keycloak-documentation/pull/389 >> >> Marek >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > From mposolda at redhat.com Fri Jun 8 10:28:26 2018 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 8 Jun 2018 16:28:26 +0200 Subject: [keycloak-dev] Client scopes PR rebased, Documentation added In-Reply-To: <67580bc0-c0d8-6c05-e57c-77dea94efc31@redhat.com> References: <192e966e-6a07-aac8-5b56-46c170ee4d40@redhat.com> <67580bc0-c0d8-6c05-e57c-77dea94efc31@redhat.com> Message-ID: Forgot to add, there is still some more work planned for this: - Better support for Audience parameter - Convert roles to be added to the OIDC access token with the protocolMapper - Improvements related to consent screen (ordering capability, check/uncheck scopes) - Scope parameter support for token exchange - Groups support - Client scopes inheritance See the epic for more details: https://issues.jboss.org/browse/KEYCLOAK-6600 If you have any ideas for improvements or if you find any bugs/regressions caused by introducing clientScopes, feel free to reply here or create JIRA and assign to me. Thanks, Marek On 08/06/18 16:24, Marek Posolda wrote: > Thanks Bill, Vlasta and Matthew for the review and re-check databases. > > ClientScopes PR is in master as well as documentation is in docs > master. Summary of the changes in this old email: > http://lists.jboss.org/pipermail/keycloak-dev/2018-March/010528.html > > Marek > > On 05/06/18 16:22, Bill Burke wrote: >> I'll take a look this afternoon, my time. >> >> On Tue, Jun 5, 2018 at 6:49 AM, Marek Posolda >> wrote: >>> I've did a rebase of client scopes PR [1] against latest master. Also >>> did the documentation for it in the PR [2] . >>> >>> Anyone has a time to review? TBH I hope it's sorted soon as it changes >>> 291 files, so there is quite a chance for the conflict with every other >>> PR send. And rebasing (which I already did 2 or 3 times) is quite a >>> pain ;) >>> >>> [1] https://github.com/keycloak/keycloak/pull/5076 >>> [2] https://github.com/keycloak/keycloak-documentation/pull/389 >>> >>> Marek >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> > From thomas.darimont at googlemail.com Fri Jun 8 13:35:13 2018 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Fri, 8 Jun 2018 18:35:13 +0100 Subject: [keycloak-dev] PKCE support for Keycloak Adapters (OAuthRequestAuthenticator) In-Reply-To: References: Message-ID: Hi Marek, thanks for your helpful feedback! I extracted the generateRandomData() function from the generateCodeVerifier() function, which could be reused for state and UUID generation. I also added a fallback in case Uint8Array isn't available. I created a PR with the current implementation for KEYCLOAK-1033 (the issue subject should be adapted to this) https://github.com/keycloak/keycloak/pull/5255 What's the best way to implement an automated for this? Cheers, Thomas On Wed, Jun 6, 2018 at 9:12 AM Marek Posolda wrote: > Hi Thomas, > > I think it is great and will be good to support this in our javascript > adapter OOTB. > > Few comments: > - In keycloak.js, we use "createUUID()" function to generate "nonce" and > "state" . IMO it will be good if all the things (nonce, state, > codeVerifier...) are generated through same mechanism. I guess that we > can use "window.crypto" or "window.msCrypto", but if none of them is > available, then just fallback to what is currently used in > "createUUID()" ? Also change the current generating of "nonce" and > "state" to this as I suppose that "window.crypto" or "window.msCrypto" > are safer alternatives than our current "createUUID()" ? > > - I have same concern as you about localStorage, but don't have any > better alternative... No idea if sessionStorage is better. > > - We should document what browsers supports it. I guess that due to > fallback for crypto/msCrypto, the "plain" method shouldn't be an issue > for any browser as codeVerifier will be always generated just fine? But > I guess that S256, which requires this "Uint8Array" stuff may have > compatibility issues? Or am I wrong here? The issue is, that people can > still use very old browsers (For example Windows XP with IE6) and not > sure how bad it is if those people with old browsers can't authenticate... > > Marek > > > On 05/06/18 21:33, Thomas Darimont wrote: > > Hello, > > > > I gave it another spin and tested it with a whole bunch of browsers > > - Windows (IE11, Edge, Firefox, Chrome) > > - Linux (Chrome, Firefox) > > > > Current changes: (Added IE11 Support) > > > https://github.com/keycloak/keycloak/compare/master...thomasdarimont:poc/keycloak-js-pkce-support?expand=0 > > > > If you want to give it a try, you could use the js-console example from > > > > > https://github.com/keycloak/keycloak/blob/master/examples/js-console/src/main/webapp/index.html > > and just copy the keycloak.js with the PKCE support into the webapp > folder > > an include the script from there. > > > > In the initOptions for Keycloak, just add "pkceMethod: 'S256'", e.g.: > > > > var initOptions = { > > responseMode: 'fragment', > > flow: 'standard', > > pkceMethod: 'S256' > > }; > > > > If you look at your browser dev-tools, you should now see, code_challenge > > and code_challenge_method parameters added to your > > /auth url. Additionally a code_verifier parameter should be sent with the > > /token POST request. > > > > Some additional remarks: > > > > In order to support IE11 I had to use the window.msCrypto APIs and I > added > > a fallback if even that is not available. > > Currently the generated code_verifier is stored in localStorage similar > to > > the 'kc-callback-...' values. > > I think that localStorage is not the best place to store a temporary > secret > > ... I'm open to alternatives. > > > > The PKCE code_verifier is generated and stored in localStorage when > > building the auth URL, where either > > the plain value or an url-safe base64 encoded sha256 has of the > > code_verifier is used as the code_challenge, depending on the chosen > method. > > Instead of localStorage one could probably also just use sessionStorage, > > which would have the advantage of automatic deletion when the tab / > browser > > is closed. > > > > The two included libraries could be embedded / scoped into the keycloak > JS > > scope to not interfere with other included versions of the libraries. > > > > Cheers, > > Thomas > > > > On Thu, May 31, 2018 at 1:09 PM Thomas Darimont < > > thomas.darimont at googlemail.com> wrote: > > > >> Hi folks, > >> > >> I've got a working PoC for PKCE support in the Keycloak JS adapter that > >> supports `plain` and `S256` code_challenge_methods. > >> Works very well with Keycloak 4.0.0.beta3 and Keycloak 3.4.3.Final. > >> Perhaps this could serve as a base for a real PR. > >> > >> I needed to use two small js libraries to have proper support for sha256 > >> and base64 encoding for Unit8Arrays in order to > >> produce a codeChallenge in the same way the Keycloak server does it, for > >> details see commit. > >> > >> Branch: > >> > https://github.com/thomasdarimont/keycloak/tree/poc/keycloak-js-pkce-support > >> Commit: > >> > https://github.com/thomasdarimont/keycloak/commit/f05066d430f6504246f7e518a124aef2ef5195b8 > >> > >> Looks like this would solve the issue > >> https://issues.jboss.org/browse/KEYCLOAK-1033 (which would probably > need > >> to be renamed). > >> > >> Cheers, > >> Thomas > >> > >> On Wed, May 30, 2018 at 11:57 PM Thomas Darimont < > >> thomas.darimont at googlemail.com> wrote: > >> > >>> Good point. Yes the main use case for PKCE are public clients / native > >>> apps. > >>> > >>> However the recently published OAuth 2.0 Security Best Current Practice > >>> (Draft 06 2018) [1] states: > >>> " > >>> 2.1. Protecting redirect-based flows > >>> ... > >>> Clients shall use PKCE [RFC7636] in order to (with the help of the > >>> authorization server) detect and prevent attempts to inject > (replay) > >>> authorization codes into the authorization response. The PKCE > >>> challenges must be transaction-specific and securely bound to the > >>> user agent, in which the transaction was started. OpenID Connect > >>> clients may use the "nonce" parameter of the OpenID Connect > >>> authentication request as specified in [OpenID] in conjunction with > >>> the corresponding ID Token claim for the same purpose. > >>> > >>> Note: although PKCE so far was recommended as mechanism to protect > >>> native apps, this advice applies to all kinds of OAuth clients, > >>> including web applications. > >>> " > >>> The last "Note" section was what inspired me to look into PKCE support > >>> for server-side adapters as well. > >>> But I generally agree that this is probably better suited for the JS / > >>> CLI/ keycloak-installed adapters. > >>> > >>> [1] https://tools.ietf.org/html/draft-ietf-oauth-security-topics-06 > >>> > >>> On Wed, May 30, 2018 at 8:38 AM Stian Thorgersen > >>> wrote: > >>> > >>>> As PKCE is aimed at public clients why is there a need to add support > >>>> for this to the Java adapters? Makes more sense to add this to the > >>>> JavaScript adapter and CLI/desktop adapter. > >>>> > >>>> On 30 May 2018 at 07:47, ???? / NORIMATSU?TAKASHI < > >>>> takashi.norimatsu.ws at hitachi.com> wrote: > >>>> > >>>>> Hello, > >>>>> > >>>>> I've encountered the same problem and gave up. > >>>>> > >>>>> At that time, the naive idea had hit on me. > >>>>> * prepare some concurrently accessible singleton (line > >>>>> KeycloakDeployment) from OAuthRequestAuthenticator > >>>>> * store generated codeVerifier on it with state parameter value as > its > >>>>> key. > >>>>> > >>>>> But, considering the nature of codeVerifier, the followings are > >>>>> required for such the store > >>>>> * codeVerifier should be treated the same secure levels as client > >>>>> credentials > >>>>> * codeVerifier should be short-lived and deleted after its life the > >>>>> same as Authorization Code > >>>>> > >>>>> Therefore, It might be better to create an tentative instance whose > >>>>> lifetime is between issuing Authorization Code Request and issuing > Token > >>>>> Request. And, it should be identified and only accessible from the > session > >>>>> instance who issued Authorization Code Request. > >>>>> > >>>>> However, I'm afraid it might be difficult to accomplish it in generic > >>>>> fashion. We need to implement the above each type of client adapter. > >>>>> > >>>>> Best regards, > >>>>> Takashi Norimatsu > >>>>> Hitachi Ltd., > >>>>> > >>>>> -----Original Message----- > >>>>> From: keycloak-dev-bounces at lists.jboss.org < > >>>>> keycloak-dev-bounces at lists.jboss.org> On Behalf Of Thomas Darimont > >>>>> Sent: Wednesday, May 30, 2018 9:02 AM > >>>>> To: keycloak-dev > >>>>> Subject: [!][keycloak-dev] PKCE support for Keycloak Adapters > >>>>> (OAuthRequestAuthenticator) > >>>>> > >>>>> Hi there, > >>>>> > >>>>> I was recently playing with the PKCE support in Keycloak (server) > which > >>>>> worked quite well. > >>>>> However the support for client / adapters seems to be quite limited > at > >>>>> the moment... > >>>>> > >>>>> I think support for PKCE to all? java adapters could be added quite > >>>>> easily > >>>>> - I could provide a > >>>>> PR but I'm currently stuck with finding a generic way to store the > >>>>> codeVerifier generated for the login redirect for later retrival for > the > >>>>> code2token exchange. > >>>>> > >>>>> Do you have any recommendations for this? > >>>>> > >>>>> I created the following JIRA issue (with some comments) to track > this: > >>>>> > >>>>> > https://clicktime.symantec.com/a/1/bkUjActRvyW1Ds3zoQSu7mjr4Nabixm_1YJAW4-UxEM=?d=d5OUWVTwLT2kMkuISm5qn8WHJTBcSVkENKzaB0Z2mA-PX8kp40LeKyOrcMpyKd841kYgP2EXaDDWYa0qu-AFLCtVLO4LvMfUJgUhu3xFwONMPy78dypmmmeEalkcYLU4XY3LcstbfVAoE0jRdEXXMyYStWwO95V_98pfhIYFlYFIHgapXJsFfGrldL8-siYGhinjnCn_AWyuyqrwhvBY582Dr3Pn9k4YZfsudBwcSJkErQKzyYEKfMhwz4ix7EAa-hvQ6rGHFdSza3jf1cMjsR4Xio667eNtirL9ruV4Z-FFQhamJMSJGb2o8rR52iEuGTp_28Vivk5HiwYx5XhZ4Bm9_dhN2eNeWT396bZQJwC7tDetr6UPVrPiMn6aTLdGMu6Wr-byBNvnEFmqxCB0Cx1tPxQkO4DVWKF4_iWgxZ6sW49k87BqaRTp3ktECRXNJ-CA04UZQbL7w-uPYlxvyvNNl408bCn5LpYf8w%3D%3D&u=https%3A%2F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-7467 > >>>>> > >>>>> Cheers, > >>>>> Thomas > >>>>> _______________________________________________ > >>>>> keycloak-dev mailing list > >>>>> keycloak-dev at lists.jboss.org > >>>>> > >>>>> > https://clicktime.symantec.com/a/1/Xn2ffdZIVPL_UA8_cnNApcirkcZZdsnyb6SpUdKiO-s=?d=d5OUWVTwLT2kMkuISm5qn8WHJTBcSVkENKzaB0Z2mA-PX8kp40LeKyOrcMpyKd841kYgP2EXaDDWYa0qu-AFLCtVLO4LvMfUJgUhu3xFwONMPy78dypmmmeEalkcYLU4XY3LcstbfVAoE0jRdEXXMyYStWwO95V_98pfhIYFlYFIHgapXJsFfGrldL8-siYGhinjnCn_AWyuyqrwhvBY582Dr3Pn9k4YZfsudBwcSJkErQKzyYEKfMhwz4ix7EAa-hvQ6rGHFdSza3jf1cMjsR4Xio667eNtirL9ruV4Z-FFQhamJMSJGb2o8rR52iEuGTp_28Vivk5HiwYx5XhZ4Bm9_dhN2eNeWT396bZQJwC7tDetr6UPVrPiMn6aTLdGMu6Wr-byBNvnEFmqxCB0Cx1tPxQkO4DVWKF4_iWgxZ6sW49k87BqaRTp3ktECRXNJ-CA04UZQbL7w-uPYlxvyvNNl408bCn5LpYf8w%3D%3D&u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev > >>>>> > >>>>> _______________________________________________ > >>>>> keycloak-dev mailing list > >>>>> keycloak-dev at lists.jboss.org > >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>>> > >>>> > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > From Gregor.Tudan at cofinpro.de Sat Jun 9 17:52:56 2018 From: Gregor.Tudan at cofinpro.de (Gregor Tudan) Date: Sat, 9 Jun 2018 21:52:56 +0000 Subject: [keycloak-dev] KEYCLOAK-2606 - Browsertab-Support for Cordova In-Reply-To: References: <176FD46C-C9F5-481F-B2B7-DC87586FE11A@cofinpro.de> Message-ID: Hi Stian, I?ve created a first version and submitted it as pull-request, so we can review it. https://github.com/keycloak/keycloak/pull/5256 It relies on the following plugins: * browsertab: https://github.com/google/cordova-plugin-browsertab * universal-links: https://github.com/nordnet/cordova-universal-links-plugin While the first works really well, the second is a bit of mess and looks abandoned. Sadly, it is still the best plugin for deep-linking into apps around if you don?t want to add branch.io as third party service. It still works, but the future of the plugin is unclear. Other plugins only provide custom-url-stlye links, which are deprecated since iOS 9. Sadly Universal-Links are not without problems either (at least on iOS), as they don?t really work with redirects: i.e. clicking on the login-button in the form takes you straight to the app, but hitting the ?open? button on the keyboard won?t - this is a problem which all oauth libraries are facing, so I guess there isn?t much we can do about it: https://www.google.com/search?q=universal+links+redirect+site%3Aforums.developer.apple.com I have to do some more testing to see how well this works on Android. The first attempts looked promising. - Gregor Am 05.06.2018 um 20:12 schrieb Stian Thorgersen >: Sorry for the late response, but the first approach seems good to me. I would assume the app developer would have to configure the universal link for the app, but also configure it in the Keycloak adapter right so it knows what URL to handle? Or can it just handle it without knowing the exact link? I would assume changes needed to apps to switch between the "old mode" and the new mode with system browsers in either case so not to worried if it requires some changes for existing users. On 30 May 2018 at 10:26, Gregor Tudan > wrote: Figuring out the callback wasn?t to hard either - now the last missing piece is parsing the callback. Here we have the option of registering a universal link inside the Keycloak adapter which opens the app, or leaving this to the developer and provide a public method for it (like processCallback). I?m not quiet sure on these options, what are your thoughts on this? Could you elaborate a bit on this please? Sure - The way those native browser tabs work is that the app requests to open a site, but has no access to what happens inside the browser. After the login is done, the browser redirects back into the app by using universal links. These URLs have be registered in the app, so the browser knows that it should pass those requests back. From there, we can get the oauth params (state and code) and fetch the token. The question is: should we implement this kind of callback logic inside the adapter, or should we provide the user a method for completing the login process upon redirecting? If we do this in the adapter, we would need to make some assumptions on the Cordova-Plugin being used and how the link is set up. I don?t think that?s a bad thing, but we would need to document how to setup the app so that the redirect works. This would also fit nicely in the current API of the adapter. The other option would be to leave it up to the user to handle the redirect and offer a callback for finishing the authorization. This would basically boil down to a method that takes the code and the state params (like processCallback in the current adapter). This would kind of break the API of the adapter, as the login method will behave differently for this native adapter. To summarize: doing more stuff in the adapter would simplify things for the developer, but might not work for existing apps - i.e. if they use a different plugin for handling universal links. I suggest starting with first option (handling redirects in the adapter) to get started - universal links don?t seem to be to widely used, so most apps shouldn?t run into problems with us picking a plugin for them. Maybe we can add another option to the adapter for manual redirect-handling later on. For the first approach I assume the app developer would have to pick a From sthorger at redhat.com Tue Jun 12 11:32:58 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 12 Jun 2018 17:32:58 +0200 Subject: [keycloak-dev] KEYCLOAK-2606 - Browsertab-Support for Cordova In-Reply-To: References: <176FD46C-C9F5-481F-B2B7-DC87586FE11A@cofinpro.de> Message-ID: Sounds good. I'm not able to review this work properly at the moment as I have too much stuff on my plate, but will find others that can. I'm very pleased to see this and look forward to getting it in. I've been wanting it for a long time, but couldn't find the time to work on it. On Sat, 9 Jun 2018, 23:53 Gregor Tudan, wrote: > Hi Stian, > > I?ve created a first version and submitted it as pull-request, so we can > review it. https://github.com/keycloak/keycloak/pull/5256 > > It relies on the following plugins: > > - browsertab: https://github.com/google/cordova-plugin-browsertab > - universal-links: > https://github.com/nordnet/cordova-universal-links-plugin > > While the first works really well, the second is a bit of mess and looks > abandoned. Sadly, it is still the best plugin for deep-linking into apps > around if you don?t want to add branch.io as third party service. It > still works, but the future of the plugin is unclear. Other plugins only > provide custom-url-stlye links, which are deprecated since iOS 9. > > Sadly Universal-Links are not without problems either (at least on iOS), > as they don?t really work with redirects: i.e. clicking on the login-button > in the form takes you straight to the app, but hitting the ?open? button on > the keyboard won?t - this is a problem which all oauth libraries are > facing, so I guess there isn?t much we can do about it: > https://www.google.com/search?q=universal+links+redirect+site%3Aforums.developer.apple.com > > > I have to do some more testing to see how well this works on Android. The > first attempts looked promising. > > - Gregor > > Am 05.06.2018 um 20:12 schrieb Stian Thorgersen : > > Sorry for the late response, but the first approach seems good to me. I > would assume the app developer would have to configure the universal link > for the app, but also configure it in the Keycloak adapter right so it > knows what URL to handle? Or can it just handle it without knowing the > exact link? I would assume changes needed to apps to switch between the > "old mode" and the new mode with system browsers in either case so not to > worried if it requires some changes for existing users. > > On 30 May 2018 at 10:26, Gregor Tudan wrote: > >> >> >>> Figuring out the callback wasn?t to hard either - now the last missing >>> piece is parsing the callback. Here we have the option of registering a >>> universal link inside the Keycloak adapter which opens the app, or leaving >>> this to the developer and provide a public method for it (like >>> processCallback). >>> >>> I?m not quiet sure on these options, what are your thoughts on this? >>> >> >> Could you elaborate a bit on this please? >> >> >> Sure - The way those native browser tabs work is that the app requests to >> open a site, but has no access to what happens inside the browser. After >> the login is done, the browser redirects back into the app by using >> universal links. These URLs have be registered in the app, so the browser >> knows that it should pass those requests back. From there, we can get the >> oauth params (state and code) and fetch the token. >> >> The question is: should we implement this kind of callback logic inside >> the adapter, or should we provide the user a method for completing the >> login process upon redirecting? >> >> If we do this in the adapter, we would need to make some assumptions on >> the Cordova-Plugin being used and how the link is set up. I don?t think >> that?s a bad thing, but we would need to document how to setup the app so >> that the redirect works. This would also fit nicely in the current API of >> the adapter. >> >> The other option would be to leave it up to the user to handle the >> redirect and offer a callback for finishing the authorization. This would >> basically boil down to a method that takes the code and the state params >> (like processCallback in the current adapter). This would kind of break the >> API of the adapter, as the login method will behave differently for this >> native adapter. >> >> To summarize: doing more stuff in the adapter would simplify things for >> the developer, but might not work for existing apps - i.e. if they use a >> different plugin for handling universal links. >> >> I suggest starting with first option (handling redirects in the adapter) >> to get started - universal links don?t seem to be to widely used, so most >> apps shouldn?t run into problems with us picking a plugin for them. Maybe >> we can add another option to the adapter for manual redirect-handling later >> on. >> > > For the first approach I assume the app developer would have to pick a > > > From sthorger at redhat.com Tue Jun 12 11:35:13 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 12 Jun 2018 17:35:13 +0200 Subject: [keycloak-dev] PKCE support for Keycloak Adapters (OAuthRequestAuthenticator) In-Reply-To: References: Message-ID: There's a JavaScript adapter test in the base testsuite. On my phone now so can't find the correct name. Probably called JavaScriptAdapterTest or something like that. On Fri, 8 Jun 2018, 18:35 Thomas Darimont, wrote: > Hi Marek, > > thanks for your helpful feedback! > I extracted the generateRandomData() function from the > generateCodeVerifier() function, which could be > reused for state and UUID generation. I also added a fallback in case > Uint8Array isn't available. > > I created a PR with the current implementation for KEYCLOAK-1033 (the > issue subject should be adapted to this) > https://github.com/keycloak/keycloak/pull/5255 > > What's the best way to implement an automated for this? > > Cheers, > Thomas > > On Wed, Jun 6, 2018 at 9:12 AM Marek Posolda wrote: > >> Hi Thomas, >> >> I think it is great and will be good to support this in our javascript >> adapter OOTB. >> >> Few comments: >> - In keycloak.js, we use "createUUID()" function to generate "nonce" and >> "state" . IMO it will be good if all the things (nonce, state, >> codeVerifier...) are generated through same mechanism. I guess that we >> can use "window.crypto" or "window.msCrypto", but if none of them is >> available, then just fallback to what is currently used in >> "createUUID()" ? Also change the current generating of "nonce" and >> "state" to this as I suppose that "window.crypto" or "window.msCrypto" >> are safer alternatives than our current "createUUID()" ? >> >> - I have same concern as you about localStorage, but don't have any >> better alternative... No idea if sessionStorage is better. >> >> - We should document what browsers supports it. I guess that due to >> fallback for crypto/msCrypto, the "plain" method shouldn't be an issue >> for any browser as codeVerifier will be always generated just fine? But >> I guess that S256, which requires this "Uint8Array" stuff may have >> compatibility issues? Or am I wrong here? The issue is, that people can >> still use very old browsers (For example Windows XP with IE6) and not >> sure how bad it is if those people with old browsers can't authenticate... >> >> Marek >> >> >> On 05/06/18 21:33, Thomas Darimont wrote: >> > Hello, >> > >> > I gave it another spin and tested it with a whole bunch of browsers >> > - Windows (IE11, Edge, Firefox, Chrome) >> > - Linux (Chrome, Firefox) >> > >> > Current changes: (Added IE11 Support) >> > >> https://github.com/keycloak/keycloak/compare/master...thomasdarimont:poc/keycloak-js-pkce-support?expand=0 >> > >> > If you want to give it a try, you could use the js-console example from >> > >> > >> https://github.com/keycloak/keycloak/blob/master/examples/js-console/src/main/webapp/index.html >> > and just copy the keycloak.js with the PKCE support into the webapp >> folder >> > an include the script from there. >> > >> > In the initOptions for Keycloak, just add "pkceMethod: 'S256'", e.g.: >> > >> > var initOptions = { >> > responseMode: 'fragment', >> > flow: 'standard', >> > pkceMethod: 'S256' >> > }; >> > >> > If you look at your browser dev-tools, you should now see, >> code_challenge >> > and code_challenge_method parameters added to your >> > /auth url. Additionally a code_verifier parameter should be sent with >> the >> > /token POST request. >> > >> > Some additional remarks: >> > >> > In order to support IE11 I had to use the window.msCrypto APIs and I >> added >> > a fallback if even that is not available. >> > Currently the generated code_verifier is stored in localStorage similar >> to >> > the 'kc-callback-...' values. >> > I think that localStorage is not the best place to store a temporary >> secret >> > ... I'm open to alternatives. >> > >> > The PKCE code_verifier is generated and stored in localStorage when >> > building the auth URL, where either >> > the plain value or an url-safe base64 encoded sha256 has of the >> > code_verifier is used as the code_challenge, depending on the chosen >> method. >> > Instead of localStorage one could probably also just use sessionStorage, >> > which would have the advantage of automatic deletion when the tab / >> browser >> > is closed. >> > >> > The two included libraries could be embedded / scoped into the keycloak >> JS >> > scope to not interfere with other included versions of the libraries. >> > >> > Cheers, >> > Thomas >> > >> > On Thu, May 31, 2018 at 1:09 PM Thomas Darimont < >> > thomas.darimont at googlemail.com> wrote: >> > >> >> Hi folks, >> >> >> >> I've got a working PoC for PKCE support in the Keycloak JS adapter that >> >> supports `plain` and `S256` code_challenge_methods. >> >> Works very well with Keycloak 4.0.0.beta3 and Keycloak 3.4.3.Final. >> >> Perhaps this could serve as a base for a real PR. >> >> >> >> I needed to use two small js libraries to have proper support for >> sha256 >> >> and base64 encoding for Unit8Arrays in order to >> >> produce a codeChallenge in the same way the Keycloak server does it, >> for >> >> details see commit. >> >> >> >> Branch: >> >> >> https://github.com/thomasdarimont/keycloak/tree/poc/keycloak-js-pkce-support >> >> Commit: >> >> >> https://github.com/thomasdarimont/keycloak/commit/f05066d430f6504246f7e518a124aef2ef5195b8 >> >> >> >> Looks like this would solve the issue >> >> https://issues.jboss.org/browse/KEYCLOAK-1033 (which would probably >> need >> >> to be renamed). >> >> >> >> Cheers, >> >> Thomas >> >> >> >> On Wed, May 30, 2018 at 11:57 PM Thomas Darimont < >> >> thomas.darimont at googlemail.com> wrote: >> >> >> >>> Good point. Yes the main use case for PKCE are public clients / native >> >>> apps. >> >>> >> >>> However the recently published OAuth 2.0 Security Best Current >> Practice >> >>> (Draft 06 2018) [1] states: >> >>> " >> >>> 2.1. Protecting redirect-based flows >> >>> ... >> >>> Clients shall use PKCE [RFC7636] in order to (with the help of the >> >>> authorization server) detect and prevent attempts to inject >> (replay) >> >>> authorization codes into the authorization response. The PKCE >> >>> challenges must be transaction-specific and securely bound to the >> >>> user agent, in which the transaction was started. OpenID Connect >> >>> clients may use the "nonce" parameter of the OpenID Connect >> >>> authentication request as specified in [OpenID] in conjunction >> with >> >>> the corresponding ID Token claim for the same purpose. >> >>> >> >>> Note: although PKCE so far was recommended as mechanism to protect >> >>> native apps, this advice applies to all kinds of OAuth clients, >> >>> including web applications. >> >>> " >> >>> The last "Note" section was what inspired me to look into PKCE support >> >>> for server-side adapters as well. >> >>> But I generally agree that this is probably better suited for the JS / >> >>> CLI/ keycloak-installed adapters. >> >>> >> >>> [1] https://tools.ietf.org/html/draft-ietf-oauth-security-topics-06 >> >>> >> >>> On Wed, May 30, 2018 at 8:38 AM Stian Thorgersen > > >> >>> wrote: >> >>> >> >>>> As PKCE is aimed at public clients why is there a need to add support >> >>>> for this to the Java adapters? Makes more sense to add this to the >> >>>> JavaScript adapter and CLI/desktop adapter. >> >>>> >> >>>> On 30 May 2018 at 07:47, ???? / NORIMATSU?TAKASHI < >> >>>> takashi.norimatsu.ws at hitachi.com> wrote: >> >>>> >> >>>>> Hello, >> >>>>> >> >>>>> I've encountered the same problem and gave up. >> >>>>> >> >>>>> At that time, the naive idea had hit on me. >> >>>>> * prepare some concurrently accessible singleton (line >> >>>>> KeycloakDeployment) from OAuthRequestAuthenticator >> >>>>> * store generated codeVerifier on it with state parameter value as >> its >> >>>>> key. >> >>>>> >> >>>>> But, considering the nature of codeVerifier, the followings are >> >>>>> required for such the store >> >>>>> * codeVerifier should be treated the same secure levels as client >> >>>>> credentials >> >>>>> * codeVerifier should be short-lived and deleted after its life the >> >>>>> same as Authorization Code >> >>>>> >> >>>>> Therefore, It might be better to create an tentative instance whose >> >>>>> lifetime is between issuing Authorization Code Request and issuing >> Token >> >>>>> Request. And, it should be identified and only accessible from the >> session >> >>>>> instance who issued Authorization Code Request. >> >>>>> >> >>>>> However, I'm afraid it might be difficult to accomplish it in >> generic >> >>>>> fashion. We need to implement the above each type of client adapter. >> >>>>> >> >>>>> Best regards, >> >>>>> Takashi Norimatsu >> >>>>> Hitachi Ltd., >> >>>>> >> >>>>> -----Original Message----- >> >>>>> From: keycloak-dev-bounces at lists.jboss.org < >> >>>>> keycloak-dev-bounces at lists.jboss.org> On Behalf Of Thomas Darimont >> >>>>> Sent: Wednesday, May 30, 2018 9:02 AM >> >>>>> To: keycloak-dev >> >>>>> Subject: [!][keycloak-dev] PKCE support for Keycloak Adapters >> >>>>> (OAuthRequestAuthenticator) >> >>>>> >> >>>>> Hi there, >> >>>>> >> >>>>> I was recently playing with the PKCE support in Keycloak (server) >> which >> >>>>> worked quite well. >> >>>>> However the support for client / adapters seems to be quite limited >> at >> >>>>> the moment... >> >>>>> >> >>>>> I think support for PKCE to all? java adapters could be added quite >> >>>>> easily >> >>>>> - I could provide a >> >>>>> PR but I'm currently stuck with finding a generic way to store the >> >>>>> codeVerifier generated for the login redirect for later retrival >> for the >> >>>>> code2token exchange. >> >>>>> >> >>>>> Do you have any recommendations for this? >> >>>>> >> >>>>> I created the following JIRA issue (with some comments) to track >> this: >> >>>>> >> >>>>> >> https://clicktime.symantec.com/a/1/bkUjActRvyW1Ds3zoQSu7mjr4Nabixm_1YJAW4-UxEM=?d=d5OUWVTwLT2kMkuISm5qn8WHJTBcSVkENKzaB0Z2mA-PX8kp40LeKyOrcMpyKd841kYgP2EXaDDWYa0qu-AFLCtVLO4LvMfUJgUhu3xFwONMPy78dypmmmeEalkcYLU4XY3LcstbfVAoE0jRdEXXMyYStWwO95V_98pfhIYFlYFIHgapXJsFfGrldL8-siYGhinjnCn_AWyuyqrwhvBY582Dr3Pn9k4YZfsudBwcSJkErQKzyYEKfMhwz4ix7EAa-hvQ6rGHFdSza3jf1cMjsR4Xio667eNtirL9ruV4Z-FFQhamJMSJGb2o8rR52iEuGTp_28Vivk5HiwYx5XhZ4Bm9_dhN2eNeWT396bZQJwC7tDetr6UPVrPiMn6aTLdGMu6Wr-byBNvnEFmqxCB0Cx1tPxQkO4DVWKF4_iWgxZ6sW49k87BqaRTp3ktECRXNJ-CA04UZQbL7w-uPYlxvyvNNl408bCn5LpYf8w%3D%3D&u=https%3A%2F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-7467 >> >>>>> >> >>>>> Cheers, >> >>>>> Thomas >> >>>>> _______________________________________________ >> >>>>> keycloak-dev mailing list >> >>>>> keycloak-dev at lists.jboss.org >> >>>>> >> >>>>> >> https://clicktime.symantec.com/a/1/Xn2ffdZIVPL_UA8_cnNApcirkcZZdsnyb6SpUdKiO-s=?d=d5OUWVTwLT2kMkuISm5qn8WHJTBcSVkENKzaB0Z2mA-PX8kp40LeKyOrcMpyKd841kYgP2EXaDDWYa0qu-AFLCtVLO4LvMfUJgUhu3xFwONMPy78dypmmmeEalkcYLU4XY3LcstbfVAoE0jRdEXXMyYStWwO95V_98pfhIYFlYFIHgapXJsFfGrldL8-siYGhinjnCn_AWyuyqrwhvBY582Dr3Pn9k4YZfsudBwcSJkErQKzyYEKfMhwz4ix7EAa-hvQ6rGHFdSza3jf1cMjsR4Xio667eNtirL9ruV4Z-FFQhamJMSJGb2o8rR52iEuGTp_28Vivk5HiwYx5XhZ4Bm9_dhN2eNeWT396bZQJwC7tDetr6UPVrPiMn6aTLdGMu6Wr-byBNvnEFmqxCB0Cx1tPxQkO4DVWKF4_iWgxZ6sW49k87BqaRTp3ktECRXNJ-CA04UZQbL7w-uPYlxvyvNNl408bCn5LpYf8w%3D%3D&u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev >> >>>>> >> >>>>> _______________________________________________ >> >>>>> keycloak-dev mailing list >> >>>>> keycloak-dev at lists.jboss.org >> >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >>>>> >> >>>> >> > _______________________________________________ >> > keycloak-dev mailing list >> > keycloak-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> From thomas.darimont at googlemail.com Tue Jun 12 13:23:25 2018 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Tue, 12 Jun 2018 18:23:25 +0100 Subject: [keycloak-dev] PKCE support for Keycloak Adapters (OAuthRequestAuthenticator) In-Reply-To: References: Message-ID: Thanks, I found it, updated the PR with tests for PKCE methods 'S256' and 'plain'. One thing left is to properly isolate the two support libraries - which register the `sha256` and `base64js` in global scope. One caveat here is that this might break existing apps / integrations which are currently using other objects with those names. To work around this issue, one could try to register those functions in a custom root object like "Keycloak.libs" instead of window, and then use Keycloak.libs.sha256... and Keycloak.libs.base64js... Stian Thorgersen schrieb am Di., 12. Juni 2018, 17:35: > There's a JavaScript adapter test in the base testsuite. On my phone now > so can't find the correct name. Probably called JavaScriptAdapterTest or > something like that. > > On Fri, 8 Jun 2018, 18:35 Thomas Darimont, > wrote: > >> Hi Marek, >> >> thanks for your helpful feedback! >> I extracted the generateRandomData() function from the >> generateCodeVerifier() function, which could be >> reused for state and UUID generation. I also added a fallback in case >> Uint8Array isn't available. >> >> I created a PR with the current implementation for KEYCLOAK-1033 (the >> issue subject should be adapted to this) >> https://github.com/keycloak/keycloak/pull/5255 >> >> What's the best way to implement an automated for this? >> >> Cheers, >> Thomas >> >> On Wed, Jun 6, 2018 at 9:12 AM Marek Posolda wrote: >> >>> Hi Thomas, >>> >>> I think it is great and will be good to support this in our javascript >>> adapter OOTB. >>> >>> Few comments: >>> - In keycloak.js, we use "createUUID()" function to generate "nonce" and >>> "state" . IMO it will be good if all the things (nonce, state, >>> codeVerifier...) are generated through same mechanism. I guess that we >>> can use "window.crypto" or "window.msCrypto", but if none of them is >>> available, then just fallback to what is currently used in >>> "createUUID()" ? Also change the current generating of "nonce" and >>> "state" to this as I suppose that "window.crypto" or "window.msCrypto" >>> are safer alternatives than our current "createUUID()" ? >>> >>> - I have same concern as you about localStorage, but don't have any >>> better alternative... No idea if sessionStorage is better. >>> >>> - We should document what browsers supports it. I guess that due to >>> fallback for crypto/msCrypto, the "plain" method shouldn't be an issue >>> for any browser as codeVerifier will be always generated just fine? But >>> I guess that S256, which requires this "Uint8Array" stuff may have >>> compatibility issues? Or am I wrong here? The issue is, that people can >>> still use very old browsers (For example Windows XP with IE6) and not >>> sure how bad it is if those people with old browsers can't >>> authenticate... >>> >>> Marek >>> >>> >>> On 05/06/18 21:33, Thomas Darimont wrote: >>> > Hello, >>> > >>> > I gave it another spin and tested it with a whole bunch of browsers >>> > - Windows (IE11, Edge, Firefox, Chrome) >>> > - Linux (Chrome, Firefox) >>> > >>> > Current changes: (Added IE11 Support) >>> > >>> https://github.com/keycloak/keycloak/compare/master...thomasdarimont:poc/keycloak-js-pkce-support?expand=0 >>> > >>> > If you want to give it a try, you could use the js-console example from >>> > >>> > >>> https://github.com/keycloak/keycloak/blob/master/examples/js-console/src/main/webapp/index.html >>> > and just copy the keycloak.js with the PKCE support into the webapp >>> folder >>> > an include the script from there. >>> > >>> > In the initOptions for Keycloak, just add "pkceMethod: 'S256'", e.g.: >>> > >>> > var initOptions = { >>> > responseMode: 'fragment', >>> > flow: 'standard', >>> > pkceMethod: 'S256' >>> > }; >>> > >>> > If you look at your browser dev-tools, you should now see, >>> code_challenge >>> > and code_challenge_method parameters added to your >>> > /auth url. Additionally a code_verifier parameter should be sent with >>> the >>> > /token POST request. >>> > >>> > Some additional remarks: >>> > >>> > In order to support IE11 I had to use the window.msCrypto APIs and I >>> added >>> > a fallback if even that is not available. >>> > Currently the generated code_verifier is stored in localStorage >>> similar to >>> > the 'kc-callback-...' values. >>> > I think that localStorage is not the best place to store a temporary >>> secret >>> > ... I'm open to alternatives. >>> > >>> > The PKCE code_verifier is generated and stored in localStorage when >>> > building the auth URL, where either >>> > the plain value or an url-safe base64 encoded sha256 has of the >>> > code_verifier is used as the code_challenge, depending on the chosen >>> method. >>> > Instead of localStorage one could probably also just use >>> sessionStorage, >>> > which would have the advantage of automatic deletion when the tab / >>> browser >>> > is closed. >>> > >>> > The two included libraries could be embedded / scoped into the >>> keycloak JS >>> > scope to not interfere with other included versions of the libraries. >>> > >>> > Cheers, >>> > Thomas >>> > >>> > On Thu, May 31, 2018 at 1:09 PM Thomas Darimont < >>> > thomas.darimont at googlemail.com> wrote: >>> > >>> >> Hi folks, >>> >> >>> >> I've got a working PoC for PKCE support in the Keycloak JS adapter >>> that >>> >> supports `plain` and `S256` code_challenge_methods. >>> >> Works very well with Keycloak 4.0.0.beta3 and Keycloak 3.4.3.Final. >>> >> Perhaps this could serve as a base for a real PR. >>> >> >>> >> I needed to use two small js libraries to have proper support for >>> sha256 >>> >> and base64 encoding for Unit8Arrays in order to >>> >> produce a codeChallenge in the same way the Keycloak server does it, >>> for >>> >> details see commit. >>> >> >>> >> Branch: >>> >> >>> https://github.com/thomasdarimont/keycloak/tree/poc/keycloak-js-pkce-support >>> >> Commit: >>> >> >>> https://github.com/thomasdarimont/keycloak/commit/f05066d430f6504246f7e518a124aef2ef5195b8 >>> >> >>> >> Looks like this would solve the issue >>> >> https://issues.jboss.org/browse/KEYCLOAK-1033 (which would probably >>> need >>> >> to be renamed). >>> >> >>> >> Cheers, >>> >> Thomas >>> >> >>> >> On Wed, May 30, 2018 at 11:57 PM Thomas Darimont < >>> >> thomas.darimont at googlemail.com> wrote: >>> >> >>> >>> Good point. Yes the main use case for PKCE are public clients / >>> native >>> >>> apps. >>> >>> >>> >>> However the recently published OAuth 2.0 Security Best Current >>> Practice >>> >>> (Draft 06 2018) [1] states: >>> >>> " >>> >>> 2.1. Protecting redirect-based flows >>> >>> ... >>> >>> Clients shall use PKCE [RFC7636] in order to (with the help of the >>> >>> authorization server) detect and prevent attempts to inject >>> (replay) >>> >>> authorization codes into the authorization response. The PKCE >>> >>> challenges must be transaction-specific and securely bound to the >>> >>> user agent, in which the transaction was started. OpenID Connect >>> >>> clients may use the "nonce" parameter of the OpenID Connect >>> >>> authentication request as specified in [OpenID] in conjunction >>> with >>> >>> the corresponding ID Token claim for the same purpose. >>> >>> >>> >>> Note: although PKCE so far was recommended as mechanism to protect >>> >>> native apps, this advice applies to all kinds of OAuth clients, >>> >>> including web applications. >>> >>> " >>> >>> The last "Note" section was what inspired me to look into PKCE >>> support >>> >>> for server-side adapters as well. >>> >>> But I generally agree that this is probably better suited for the JS >>> / >>> >>> CLI/ keycloak-installed adapters. >>> >>> >>> >>> [1] https://tools.ietf.org/html/draft-ietf-oauth-security-topics-06 >>> >>> >>> >>> On Wed, May 30, 2018 at 8:38 AM Stian Thorgersen < >>> sthorger at redhat.com> >>> >>> wrote: >>> >>> >>> >>>> As PKCE is aimed at public clients why is there a need to add >>> support >>> >>>> for this to the Java adapters? Makes more sense to add this to the >>> >>>> JavaScript adapter and CLI/desktop adapter. >>> >>>> >>> >>>> On 30 May 2018 at 07:47, ???? / NORIMATSU?TAKASHI < >>> >>>> takashi.norimatsu.ws at hitachi.com> wrote: >>> >>>> >>> >>>>> Hello, >>> >>>>> >>> >>>>> I've encountered the same problem and gave up. >>> >>>>> >>> >>>>> At that time, the naive idea had hit on me. >>> >>>>> * prepare some concurrently accessible singleton (line >>> >>>>> KeycloakDeployment) from OAuthRequestAuthenticator >>> >>>>> * store generated codeVerifier on it with state parameter value as >>> its >>> >>>>> key. >>> >>>>> >>> >>>>> But, considering the nature of codeVerifier, the followings are >>> >>>>> required for such the store >>> >>>>> * codeVerifier should be treated the same secure levels as client >>> >>>>> credentials >>> >>>>> * codeVerifier should be short-lived and deleted after its life the >>> >>>>> same as Authorization Code >>> >>>>> >>> >>>>> Therefore, It might be better to create an tentative instance whose >>> >>>>> lifetime is between issuing Authorization Code Request and issuing >>> Token >>> >>>>> Request. And, it should be identified and only accessible from the >>> session >>> >>>>> instance who issued Authorization Code Request. >>> >>>>> >>> >>>>> However, I'm afraid it might be difficult to accomplish it in >>> generic >>> >>>>> fashion. We need to implement the above each type of client >>> adapter. >>> >>>>> >>> >>>>> Best regards, >>> >>>>> Takashi Norimatsu >>> >>>>> Hitachi Ltd., >>> >>>>> >>> >>>>> -----Original Message----- >>> >>>>> From: keycloak-dev-bounces at lists.jboss.org < >>> >>>>> keycloak-dev-bounces at lists.jboss.org> On Behalf Of Thomas Darimont >>> >>>>> Sent: Wednesday, May 30, 2018 9:02 AM >>> >>>>> To: keycloak-dev >>> >>>>> Subject: [!][keycloak-dev] PKCE support for Keycloak Adapters >>> >>>>> (OAuthRequestAuthenticator) >>> >>>>> >>> >>>>> Hi there, >>> >>>>> >>> >>>>> I was recently playing with the PKCE support in Keycloak (server) >>> which >>> >>>>> worked quite well. >>> >>>>> However the support for client / adapters seems to be quite >>> limited at >>> >>>>> the moment... >>> >>>>> >>> >>>>> I think support for PKCE to all? java adapters could be added quite >>> >>>>> easily >>> >>>>> - I could provide a >>> >>>>> PR but I'm currently stuck with finding a generic way to store the >>> >>>>> codeVerifier generated for the login redirect for later retrival >>> for the >>> >>>>> code2token exchange. >>> >>>>> >>> >>>>> Do you have any recommendations for this? >>> >>>>> >>> >>>>> I created the following JIRA issue (with some comments) to track >>> this: >>> >>>>> >>> >>>>> >>> https://clicktime.symantec.com/a/1/bkUjActRvyW1Ds3zoQSu7mjr4Nabixm_1YJAW4-UxEM=?d=d5OUWVTwLT2kMkuISm5qn8WHJTBcSVkENKzaB0Z2mA-PX8kp40LeKyOrcMpyKd841kYgP2EXaDDWYa0qu-AFLCtVLO4LvMfUJgUhu3xFwONMPy78dypmmmeEalkcYLU4XY3LcstbfVAoE0jRdEXXMyYStWwO95V_98pfhIYFlYFIHgapXJsFfGrldL8-siYGhinjnCn_AWyuyqrwhvBY582Dr3Pn9k4YZfsudBwcSJkErQKzyYEKfMhwz4ix7EAa-hvQ6rGHFdSza3jf1cMjsR4Xio667eNtirL9ruV4Z-FFQhamJMSJGb2o8rR52iEuGTp_28Vivk5HiwYx5XhZ4Bm9_dhN2eNeWT396bZQJwC7tDetr6UPVrPiMn6aTLdGMu6Wr-byBNvnEFmqxCB0Cx1tPxQkO4DVWKF4_iWgxZ6sW49k87BqaRTp3ktECRXNJ-CA04UZQbL7w-uPYlxvyvNNl408bCn5LpYf8w%3D%3D&u=https%3A%2F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-7467 >>> >>>>> >>> >>>>> Cheers, >>> >>>>> Thomas >>> >>>>> _______________________________________________ >>> >>>>> keycloak-dev mailing list >>> >>>>> keycloak-dev at lists.jboss.org >>> >>>>> >>> >>>>> >>> https://clicktime.symantec.com/a/1/Xn2ffdZIVPL_UA8_cnNApcirkcZZdsnyb6SpUdKiO-s=?d=d5OUWVTwLT2kMkuISm5qn8WHJTBcSVkENKzaB0Z2mA-PX8kp40LeKyOrcMpyKd841kYgP2EXaDDWYa0qu-AFLCtVLO4LvMfUJgUhu3xFwONMPy78dypmmmeEalkcYLU4XY3LcstbfVAoE0jRdEXXMyYStWwO95V_98pfhIYFlYFIHgapXJsFfGrldL8-siYGhinjnCn_AWyuyqrwhvBY582Dr3Pn9k4YZfsudBwcSJkErQKzyYEKfMhwz4ix7EAa-hvQ6rGHFdSza3jf1cMjsR4Xio667eNtirL9ruV4Z-FFQhamJMSJGb2o8rR52iEuGTp_28Vivk5HiwYx5XhZ4Bm9_dhN2eNeWT396bZQJwC7tDetr6UPVrPiMn6aTLdGMu6Wr-byBNvnEFmqxCB0Cx1tPxQkO4DVWKF4_iWgxZ6sW49k87BqaRTp3ktECRXNJ-CA04UZQbL7w-uPYlxvyvNNl408bCn5LpYf8w%3D%3D&u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev >>> >>>>> >>> >>>>> _______________________________________________ >>> >>>>> keycloak-dev mailing list >>> >>>>> keycloak-dev at lists.jboss.org >>> >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>>>> >>> >>>> >>> > _______________________________________________ >>> > keycloak-dev mailing list >>> > keycloak-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> From thomas.darimont at googlemail.com Tue Jun 12 16:23:27 2018 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Tue, 12 Jun 2018 21:23:27 +0100 Subject: [keycloak-dev] PKCE support for Keycloak Adapters (OAuthRequestAuthenticator) In-Reply-To: References: Message-ID: ... just gave this a spin - could look like this: https://gist.github.com/thomasdarimont/fe2dd4c6551d3b586a21ac6947d5ea49/revisions?diff=split Cheers, Thomas On Tue, Jun 12, 2018 at 6:23 PM Thomas Darimont < thomas.darimont at googlemail.com> wrote: > Thanks, I found it, updated the PR with tests for PKCE methods 'S256' and > 'plain'. > One thing left is to properly isolate the two support libraries - which > register > the `sha256` and `base64js` in global scope. > > One caveat here is that this might break existing apps / integrations > which are currently > using other objects with those names. > To work around this issue, one could try to register those functions in a > custom root object > like "Keycloak.libs" instead of window, and then use Keycloak.libs.sha256... > and Keycloak.libs.base64js... > > Stian Thorgersen schrieb am Di., 12. Juni 2018, > 17:35: > >> There's a JavaScript adapter test in the base testsuite. On my phone now >> so can't find the correct name. Probably called JavaScriptAdapterTest or >> something like that. >> >> On Fri, 8 Jun 2018, 18:35 Thomas Darimont, < >> thomas.darimont at googlemail.com> wrote: >> >>> Hi Marek, >>> >>> thanks for your helpful feedback! >>> I extracted the generateRandomData() function from the >>> generateCodeVerifier() function, which could be >>> reused for state and UUID generation. I also added a fallback in case >>> Uint8Array isn't available. >>> >>> I created a PR with the current implementation for KEYCLOAK-1033 (the >>> issue subject should be adapted to this) >>> https://github.com/keycloak/keycloak/pull/5255 >>> >>> What's the best way to implement an automated for this? >>> >>> Cheers, >>> Thomas >>> >>> On Wed, Jun 6, 2018 at 9:12 AM Marek Posolda >>> wrote: >>> >>>> Hi Thomas, >>>> >>>> I think it is great and will be good to support this in our javascript >>>> adapter OOTB. >>>> >>>> Few comments: >>>> - In keycloak.js, we use "createUUID()" function to generate "nonce" >>>> and >>>> "state" . IMO it will be good if all the things (nonce, state, >>>> codeVerifier...) are generated through same mechanism. I guess that we >>>> can use "window.crypto" or "window.msCrypto", but if none of them is >>>> available, then just fallback to what is currently used in >>>> "createUUID()" ? Also change the current generating of "nonce" and >>>> "state" to this as I suppose that "window.crypto" or "window.msCrypto" >>>> are safer alternatives than our current "createUUID()" ? >>>> >>>> - I have same concern as you about localStorage, but don't have any >>>> better alternative... No idea if sessionStorage is better. >>>> >>>> - We should document what browsers supports it. I guess that due to >>>> fallback for crypto/msCrypto, the "plain" method shouldn't be an issue >>>> for any browser as codeVerifier will be always generated just fine? But >>>> I guess that S256, which requires this "Uint8Array" stuff may have >>>> compatibility issues? Or am I wrong here? The issue is, that people can >>>> still use very old browsers (For example Windows XP with IE6) and not >>>> sure how bad it is if those people with old browsers can't >>>> authenticate... >>>> >>>> Marek >>>> >>>> >>>> On 05/06/18 21:33, Thomas Darimont wrote: >>>> > Hello, >>>> > >>>> > I gave it another spin and tested it with a whole bunch of browsers >>>> > - Windows (IE11, Edge, Firefox, Chrome) >>>> > - Linux (Chrome, Firefox) >>>> > >>>> > Current changes: (Added IE11 Support) >>>> > >>>> https://github.com/keycloak/keycloak/compare/master...thomasdarimont:poc/keycloak-js-pkce-support?expand=0 >>>> > >>>> > If you want to give it a try, you could use the js-console example >>>> from >>>> > >>>> > >>>> https://github.com/keycloak/keycloak/blob/master/examples/js-console/src/main/webapp/index.html >>>> > and just copy the keycloak.js with the PKCE support into the webapp >>>> folder >>>> > an include the script from there. >>>> > >>>> > In the initOptions for Keycloak, just add "pkceMethod: 'S256'", e.g.: >>>> > >>>> > var initOptions = { >>>> > responseMode: 'fragment', >>>> > flow: 'standard', >>>> > pkceMethod: 'S256' >>>> > }; >>>> > >>>> > If you look at your browser dev-tools, you should now see, >>>> code_challenge >>>> > and code_challenge_method parameters added to your >>>> > /auth url. Additionally a code_verifier parameter should be sent with >>>> the >>>> > /token POST request. >>>> > >>>> > Some additional remarks: >>>> > >>>> > In order to support IE11 I had to use the window.msCrypto APIs and I >>>> added >>>> > a fallback if even that is not available. >>>> > Currently the generated code_verifier is stored in localStorage >>>> similar to >>>> > the 'kc-callback-...' values. >>>> > I think that localStorage is not the best place to store a temporary >>>> secret >>>> > ... I'm open to alternatives. >>>> > >>>> > The PKCE code_verifier is generated and stored in localStorage when >>>> > building the auth URL, where either >>>> > the plain value or an url-safe base64 encoded sha256 has of the >>>> > code_verifier is used as the code_challenge, depending on the chosen >>>> method. >>>> > Instead of localStorage one could probably also just use >>>> sessionStorage, >>>> > which would have the advantage of automatic deletion when the tab / >>>> browser >>>> > is closed. >>>> > >>>> > The two included libraries could be embedded / scoped into the >>>> keycloak JS >>>> > scope to not interfere with other included versions of the libraries. >>>> > >>>> > Cheers, >>>> > Thomas >>>> > >>>> > On Thu, May 31, 2018 at 1:09 PM Thomas Darimont < >>>> > thomas.darimont at googlemail.com> wrote: >>>> > >>>> >> Hi folks, >>>> >> >>>> >> I've got a working PoC for PKCE support in the Keycloak JS adapter >>>> that >>>> >> supports `plain` and `S256` code_challenge_methods. >>>> >> Works very well with Keycloak 4.0.0.beta3 and Keycloak 3.4.3.Final. >>>> >> Perhaps this could serve as a base for a real PR. >>>> >> >>>> >> I needed to use two small js libraries to have proper support for >>>> sha256 >>>> >> and base64 encoding for Unit8Arrays in order to >>>> >> produce a codeChallenge in the same way the Keycloak server does it, >>>> for >>>> >> details see commit. >>>> >> >>>> >> Branch: >>>> >> >>>> https://github.com/thomasdarimont/keycloak/tree/poc/keycloak-js-pkce-support >>>> >> Commit: >>>> >> >>>> https://github.com/thomasdarimont/keycloak/commit/f05066d430f6504246f7e518a124aef2ef5195b8 >>>> >> >>>> >> Looks like this would solve the issue >>>> >> https://issues.jboss.org/browse/KEYCLOAK-1033 (which would probably >>>> need >>>> >> to be renamed). >>>> >> >>>> >> Cheers, >>>> >> Thomas >>>> >> >>>> >> On Wed, May 30, 2018 at 11:57 PM Thomas Darimont < >>>> >> thomas.darimont at googlemail.com> wrote: >>>> >> >>>> >>> Good point. Yes the main use case for PKCE are public clients / >>>> native >>>> >>> apps. >>>> >>> >>>> >>> However the recently published OAuth 2.0 Security Best Current >>>> Practice >>>> >>> (Draft 06 2018) [1] states: >>>> >>> " >>>> >>> 2.1. Protecting redirect-based flows >>>> >>> ... >>>> >>> Clients shall use PKCE [RFC7636] in order to (with the help of the >>>> >>> authorization server) detect and prevent attempts to inject >>>> (replay) >>>> >>> authorization codes into the authorization response. The PKCE >>>> >>> challenges must be transaction-specific and securely bound to >>>> the >>>> >>> user agent, in which the transaction was started. OpenID >>>> Connect >>>> >>> clients may use the "nonce" parameter of the OpenID Connect >>>> >>> authentication request as specified in [OpenID] in conjunction >>>> with >>>> >>> the corresponding ID Token claim for the same purpose. >>>> >>> >>>> >>> Note: although PKCE so far was recommended as mechanism to protect >>>> >>> native apps, this advice applies to all kinds of OAuth clients, >>>> >>> including web applications. >>>> >>> " >>>> >>> The last "Note" section was what inspired me to look into PKCE >>>> support >>>> >>> for server-side adapters as well. >>>> >>> But I generally agree that this is probably better suited for the >>>> JS / >>>> >>> CLI/ keycloak-installed adapters. >>>> >>> >>>> >>> [1] https://tools.ietf.org/html/draft-ietf-oauth-security-topics-06 >>>> >>> >>>> >>> On Wed, May 30, 2018 at 8:38 AM Stian Thorgersen < >>>> sthorger at redhat.com> >>>> >>> wrote: >>>> >>> >>>> >>>> As PKCE is aimed at public clients why is there a need to add >>>> support >>>> >>>> for this to the Java adapters? Makes more sense to add this to the >>>> >>>> JavaScript adapter and CLI/desktop adapter. >>>> >>>> >>>> >>>> On 30 May 2018 at 07:47, ???? / NORIMATSU?TAKASHI < >>>> >>>> takashi.norimatsu.ws at hitachi.com> wrote: >>>> >>>> >>>> >>>>> Hello, >>>> >>>>> >>>> >>>>> I've encountered the same problem and gave up. >>>> >>>>> >>>> >>>>> At that time, the naive idea had hit on me. >>>> >>>>> * prepare some concurrently accessible singleton (line >>>> >>>>> KeycloakDeployment) from OAuthRequestAuthenticator >>>> >>>>> * store generated codeVerifier on it with state parameter value >>>> as its >>>> >>>>> key. >>>> >>>>> >>>> >>>>> But, considering the nature of codeVerifier, the followings are >>>> >>>>> required for such the store >>>> >>>>> * codeVerifier should be treated the same secure levels as client >>>> >>>>> credentials >>>> >>>>> * codeVerifier should be short-lived and deleted after its life >>>> the >>>> >>>>> same as Authorization Code >>>> >>>>> >>>> >>>>> Therefore, It might be better to create an tentative instance >>>> whose >>>> >>>>> lifetime is between issuing Authorization Code Request and >>>> issuing Token >>>> >>>>> Request. And, it should be identified and only accessible from >>>> the session >>>> >>>>> instance who issued Authorization Code Request. >>>> >>>>> >>>> >>>>> However, I'm afraid it might be difficult to accomplish it in >>>> generic >>>> >>>>> fashion. We need to implement the above each type of client >>>> adapter. >>>> >>>>> >>>> >>>>> Best regards, >>>> >>>>> Takashi Norimatsu >>>> >>>>> Hitachi Ltd., >>>> >>>>> >>>> >>>>> -----Original Message----- >>>> >>>>> From: keycloak-dev-bounces at lists.jboss.org < >>>> >>>>> keycloak-dev-bounces at lists.jboss.org> On Behalf Of Thomas >>>> Darimont >>>> >>>>> Sent: Wednesday, May 30, 2018 9:02 AM >>>> >>>>> To: keycloak-dev >>>> >>>>> Subject: [!][keycloak-dev] PKCE support for Keycloak Adapters >>>> >>>>> (OAuthRequestAuthenticator) >>>> >>>>> >>>> >>>>> Hi there, >>>> >>>>> >>>> >>>>> I was recently playing with the PKCE support in Keycloak (server) >>>> which >>>> >>>>> worked quite well. >>>> >>>>> However the support for client / adapters seems to be quite >>>> limited at >>>> >>>>> the moment... >>>> >>>>> >>>> >>>>> I think support for PKCE to all? java adapters could be added >>>> quite >>>> >>>>> easily >>>> >>>>> - I could provide a >>>> >>>>> PR but I'm currently stuck with finding a generic way to store the >>>> >>>>> codeVerifier generated for the login redirect for later retrival >>>> for the >>>> >>>>> code2token exchange. >>>> >>>>> >>>> >>>>> Do you have any recommendations for this? >>>> >>>>> >>>> >>>>> I created the following JIRA issue (with some comments) to track >>>> this: >>>> >>>>> >>>> >>>>> >>>> https://clicktime.symantec.com/a/1/bkUjActRvyW1Ds3zoQSu7mjr4Nabixm_1YJAW4-UxEM=?d=d5OUWVTwLT2kMkuISm5qn8WHJTBcSVkENKzaB0Z2mA-PX8kp40LeKyOrcMpyKd841kYgP2EXaDDWYa0qu-AFLCtVLO4LvMfUJgUhu3xFwONMPy78dypmmmeEalkcYLU4XY3LcstbfVAoE0jRdEXXMyYStWwO95V_98pfhIYFlYFIHgapXJsFfGrldL8-siYGhinjnCn_AWyuyqrwhvBY582Dr3Pn9k4YZfsudBwcSJkErQKzyYEKfMhwz4ix7EAa-hvQ6rGHFdSza3jf1cMjsR4Xio667eNtirL9ruV4Z-FFQhamJMSJGb2o8rR52iEuGTp_28Vivk5HiwYx5XhZ4Bm9_dhN2eNeWT396bZQJwC7tDetr6UPVrPiMn6aTLdGMu6Wr-byBNvnEFmqxCB0Cx1tPxQkO4DVWKF4_iWgxZ6sW49k87BqaRTp3ktECRXNJ-CA04UZQbL7w-uPYlxvyvNNl408bCn5LpYf8w%3D%3D&u=https%3A%2F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-7467 >>>> >>>>> >>>> >>>>> Cheers, >>>> >>>>> Thomas >>>> >>>>> _______________________________________________ >>>> >>>>> keycloak-dev mailing list >>>> >>>>> keycloak-dev at lists.jboss.org >>>> >>>>> >>>> >>>>> >>>> https://clicktime.symantec.com/a/1/Xn2ffdZIVPL_UA8_cnNApcirkcZZdsnyb6SpUdKiO-s=?d=d5OUWVTwLT2kMkuISm5qn8WHJTBcSVkENKzaB0Z2mA-PX8kp40LeKyOrcMpyKd841kYgP2EXaDDWYa0qu-AFLCtVLO4LvMfUJgUhu3xFwONMPy78dypmmmeEalkcYLU4XY3LcstbfVAoE0jRdEXXMyYStWwO95V_98pfhIYFlYFIHgapXJsFfGrldL8-siYGhinjnCn_AWyuyqrwhvBY582Dr3Pn9k4YZfsudBwcSJkErQKzyYEKfMhwz4ix7EAa-hvQ6rGHFdSza3jf1cMjsR4Xio667eNtirL9ruV4Z-FFQhamJMSJGb2o8rR52iEuGTp_28Vivk5HiwYx5XhZ4Bm9_dhN2eNeWT396bZQJwC7tDetr6UPVrPiMn6aTLdGMu6Wr-byBNvnEFmqxCB0Cx1tPxQkO4DVWKF4_iWgxZ6sW49k87BqaRTp3ktECRXNJ-CA04UZQbL7w-uPYlxvyvNNl408bCn5LpYf8w%3D%3D&u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev >>>> >>>>> >>>> >>>>> _______________________________________________ >>>> >>>>> keycloak-dev mailing list >>>> >>>>> keycloak-dev at lists.jboss.org >>>> >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>>>> >>>> >>>> >>>> > _______________________________________________ >>>> > keycloak-dev mailing list >>>> > keycloak-dev at lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>>> >>>> From dt at acutus.pro Tue Jun 12 15:59:47 2018 From: dt at acutus.pro (Dmitry Telegin) Date: Tue, 12 Jun 2018 22:59:47 +0300 Subject: [keycloak-dev] Current state of OSGi in Keycloak; Keycloak at adaptTo()'2018 conference & more Message-ID: <1528833587.29773.1.camel@acutus.pro> Hi, Together with Ioan Eugen Stan (in CC) we'll be doing a talk at adaptTo()'2018 conference [1] that will take place 12-13 September in Potsdam, Germany. It's an event dedicated to Apache Sling and everything around it. The talk will be titled "Modern authentication in Sling with OpenID Connect and Keycloak". As you might guess, we're going to present Sling + Keycloak integration which I hope we'll manage to implement by the time of the conference :) that said, we welcome any thoughts that might help us with that. Now for technical details, Sling is an OSGi-based content-oriented web framework that runs on top of Apache Felix and uses Felix HTTP Service. I've examined Keycloak OSGi adapter and found its name a bit confusing; seems like it's only suitable for JBoss Fuse, depending on Pax Web (correct me if I'm wrong). Right now I see two scenarios, the first is to take current OSGi adapter and adapt it (sorry for tautology) to Felix HTTP Service; the second is to use the existing servlet filter adapter. I'd say I would prefer the second variant, as it's more straightforward. Felix and Sling have a proven and well-documented support for servlet filters, however, we'll have to solve the problems of packaging for OSGi, filter registration, configuration and more deep integration with Sling's security framework. Also please let us know if you consider our (future) code worth being contributed to Keycloak codebase. Most likely, the deliverables will include 1) servlet filter adapter packaged as OSGi bundle, 2) the Sling adapter proper. Cheers and hope to hear from you, Dmitry [1] https://adapt.to/2018/en/schedule/modern-authentication-in-sling-wi th-openid-connect-and-keycloak.html From gr.grzybek at gmail.com Wed Jun 13 10:35:13 2018 From: gr.grzybek at gmail.com (Grzegorz Grzybek) Date: Wed, 13 Jun 2018 16:35:13 +0200 Subject: [keycloak-dev] Current state of OSGi in Keycloak; Keycloak at adaptTo()'2018 conference & more In-Reply-To: <1528833587.29773.1.camel@acutus.pro> References: <1528833587.29773.1.camel@acutus.pro> Message-ID: Hello First, let me introduce myself (I've subscribed to keycloak-dev list just recently). I'm Grzegorz Grzybek and I'm contributing to both Apache Karaf (and JBoss Fuse) and ops4j PAX-WEB project. "Keycloak OSGi adapter" (GA = org.keycloak:keycloak-osgi-adapter) indeed has some Fuse specific features. Or rather pax-web specific features. It uses org.ops4j.pax.web.service.WebContainer OSGi service to register "something more" than what's possible to register using plain org.osgi.service.http.HttpService. In fact, org.ops4j.pax.web.service.WebContainer simply extends org.osgi.service.http.HttpService adding methods to register filters, listeners, login configurations security constraints, etc. So org.ops4j.pax.web.service.WebContainer allows you to directly register what's possible with WEB-INF/web.xml elements. I never used Felix' http service (because Karaf uses pax-web), so I'm not sure how keycloak works with plain OSGi http service. I think, for sling integration you should not use org.keycloak:keycloak-osgi-adapter, but org.keycloak:keycloak-servlet-filter-adapter. best regards Grzegorz Grzybek 2018-06-12 21:59 GMT+02:00 Dmitry Telegin
: > > Hi, > > Together with Ioan Eugen Stan (in CC) we'll be doing a talk at > adaptTo()'2018 conference [1] that will take place 12-13 September in > Potsdam, Germany. It's an event dedicated to Apache Sling and > everything around it. The talk will be titled "Modern authentication in > Sling with OpenID Connect and Keycloak". > > As you might guess, we're going to present Sling + Keycloak integration > which I hope we'll manage to implement by the time of the conference :) > that said, we welcome any thoughts that might help us with that. > > Now for technical details, Sling is an OSGi-based content-oriented web > framework that runs on top of Apache Felix and uses Felix HTTP Service. > I've examined Keycloak OSGi adapter and found its name a bit confusing; > seems like it's only suitable for JBoss Fuse, depending on Pax Web > (correct me if I'm wrong). > > Right now I see two scenarios, the first is to take current OSGi > adapter and adapt it (sorry for tautology) to Felix HTTP Service; the > second is to use the existing servlet filter adapter. I'd say I would > prefer the second variant, as it's more straightforward. Felix and > Sling have a proven and well-documented support for servlet filters, > however, we'll have to solve the problems of packaging for OSGi, filter > registration, configuration and more deep integration with Sling's > security framework. > > Also please let us know if you consider our (future) code worth being > contributed to Keycloak codebase. Most likely, the deliverables will > include 1) servlet filter adapter packaged as OSGi bundle, 2) the Sling > adapter proper. > > Cheers and hope to hear from you, > Dmitry > > [1] https://adapt.to/2018/en/schedule/modern-authentication-in-sling-wi > th-openid-connect-and-keycloak.html > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From takashi.norimatsu.ws at hitachi.com Thu Jun 14 02:36:21 2018 From: takashi.norimatsu.ws at hitachi.com (=?utf-8?B?5LmX5p2+6ZqG5b+XIC8gTk9SSU1BVFNV77yMVEFLQVNISQ==?=) Date: Thu, 14 Jun 2018 06:36:21 +0000 Subject: [keycloak-dev] Offline Session Max for Offline Token Message-ID: Hello, I've found that keycloak does not support Offline Session Max related to Offline Token while supports SSO Session Max related to Refresh Token. For authorization of REST API services, long life(not infinite, such as 60days) refresh token is required, offline access and persistency in keycloak side are also expected. Therefore, Offline Session Max is required for offline token. For example, consulting MS Azure, it has already supported this concept. https://docs.microsoft.com/en-US/azure/active-directory/develop/active-directory-token-and-claims#token-revocation I would like to try to implement this feature. Best regards, Takashi Norimatsu Hitachi Ltd., From sthorger at redhat.com Thu Jun 14 03:24:33 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 14 Jun 2018 09:24:33 +0200 Subject: [keycloak-dev] Community maintained extensions Message-ID: We've added a simple page to list community maintained extensions to Keycloak. If you've developed and maintain an extension to Keycloak we would love you to list your work on our website. To do that simply send a PR to https://github.com/keycloak/keycloak-web/tree/master/src/main/resources/extensions . A template for the required json file here https://github.com/keycloak/keycloak-web/blob/master/src/main/resources/extension-template.json . From hmlnarik at redhat.com Thu Jun 14 03:37:19 2018 From: hmlnarik at redhat.com (Hynek Mlnarik) Date: Thu, 14 Jun 2018 09:37:19 +0200 Subject: [keycloak-dev] Current state of OSGi in Keycloak; Keycloak at adaptTo()'2018 conference & more In-Reply-To: References: <1528833587.29773.1.camel@acutus.pro> Message-ID: OSGi http service is a generic one. Hence servlet filter is the only choice offered by Keycloak for generic http adapters. We would welcome contribution of OSGi bundle packaging. Keycloak contains adapters specific to a particular http servers, like Undertow, Jetty and others. For these to work, specific adapters have been implemented but they obviously need access to the underlying implementation. That's where pax-web comes in - it contains server-specific parts for undertow, jetty, tomcat, and keycloak can bind to it with its server-specific adapter implementations. This is not possible with generic OSGi http service though. Re contributing Sling adapter to keycloak codebase - that depends on the complexity of the adapter. If that would be some simple adjustments leveraging the servlet filetr that would apply to any OSGi adapter (which may or may not be part of the OSGi bundle packaging above), feel free to open a PR when you have it ready. For a more complex scenario, this would need a separate discussion. Let's see when the contribution would be ready. Thank you for your willingness to contribute! On Wed, Jun 13, 2018 at 4:35 PM, Grzegorz Grzybek wrote: > Hello > > First, let me introduce myself (I've subscribed to keycloak-dev list > just recently). I'm Grzegorz Grzybek and I'm contributing to both > Apache Karaf (and JBoss Fuse) and ops4j PAX-WEB project. > > "Keycloak OSGi adapter" (GA = org.keycloak:keycloak-osgi-adapter) > indeed has some Fuse specific features. Or rather pax-web specific > features. > It uses org.ops4j.pax.web.service.WebContainer OSGi service to > register "something more" than what's possible to register using plain > org.osgi.service.http.HttpService. > > In fact, org.ops4j.pax.web.service.WebContainer simply extends > org.osgi.service.http.HttpService adding methods to register filters, > listeners, login configurations security constraints, etc. > So org.ops4j.pax.web.service.WebContainer allows you to directly > register what's possible with WEB-INF/web.xml elements. > > I never used Felix' http service (because Karaf uses pax-web), so I'm > not sure how keycloak works with plain OSGi http service. > > I think, for sling integration you should not use > org.keycloak:keycloak-osgi-adapter, but > org.keycloak:keycloak-servlet-filter-adapter. > > best regards > Grzegorz Grzybek > > 2018-06-12 21:59 GMT+02:00 Dmitry Telegin
: > > > > Hi, > > > > Together with Ioan Eugen Stan (in CC) we'll be doing a talk at > > adaptTo()'2018 conference [1] that will take place 12-13 September in > > Potsdam, Germany. It's an event dedicated to Apache Sling and > > everything around it. The talk will be titled "Modern authentication in > > Sling with OpenID Connect and Keycloak". > > > > As you might guess, we're going to present Sling + Keycloak integration > > which I hope we'll manage to implement by the time of the conference :) > > that said, we welcome any thoughts that might help us with that. > > > > Now for technical details, Sling is an OSGi-based content-oriented web > > framework that runs on top of Apache Felix and uses Felix HTTP Service. > > I've examined Keycloak OSGi adapter and found its name a bit confusing; > > seems like it's only suitable for JBoss Fuse, depending on Pax Web > > (correct me if I'm wrong). > > > > Right now I see two scenarios, the first is to take current OSGi > > adapter and adapt it (sorry for tautology) to Felix HTTP Service; the > > second is to use the existing servlet filter adapter. I'd say I would > > prefer the second variant, as it's more straightforward. Felix and > > Sling have a proven and well-documented support for servlet filters, > > however, we'll have to solve the problems of packaging for OSGi, filter > > registration, configuration and more deep integration with Sling's > > security framework. > > > > Also please let us know if you consider our (future) code worth being > > contributed to Keycloak codebase. Most likely, the deliverables will > > include 1) servlet filter adapter packaged as OSGi bundle, 2) the Sling > > adapter proper. > > > > Cheers and hope to hear from you, > > Dmitry > > > > [1] https://adapt.to/2018/en/schedule/modern-authentication-in-sling-wi > > th-openid-connect-and-keycloak.html > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- --Hynek From sthorger at redhat.com Thu Jun 14 03:39:06 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 14 Jun 2018 09:39:06 +0200 Subject: [keycloak-dev] Keycloak 4.0.0.Final is out Message-ID: https://www.keycloak.org/downloads.html From thomas.darimont at googlemail.com Thu Jun 14 03:52:37 2018 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Thu, 14 Jun 2018 09:52:37 +0200 Subject: [keycloak-dev] Keycloak 4.0.0.Final is out In-Reply-To: References: Message-ID: Awesome work! Congrats :) Stian Thorgersen schrieb am Do., 14. Juni 2018, 09:40: > https://www.keycloak.org/downloads.html > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Thu Jun 14 07:38:23 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 14 Jun 2018 13:38:23 +0200 Subject: [keycloak-dev] OpenShift Commons Briefing #129: KeyCloak for Cloud Natives Message-ID: https://www.youtube.com/watch?v=j6PgJIV1UNI From mposolda at redhat.com Mon Jun 18 07:28:31 2018 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 18 Jun 2018 13:28:31 +0200 Subject: [keycloak-dev] Offline Session Max for Offline Token In-Reply-To: References: Message-ID: <6479ea5f-a6f3-64f8-99e0-01d82d8a3276@redhat.com> Hi, it makes sense to me to have support for this. However IMO default value should be still "infinity" like it is now. I am not sure what is the best way to handle this in admin console considering usability? Considering that timeouts in admin console (Tab "Tokens" of "Realm Settings") doesn't yet support infinity. And other timeouts besides "Offline Session Max" still should be kept to not support infinity IMO. Maybe one way is to have On/Off switch like "Offline Session Max Limited" . It is off by default and when it is switched to ON, it will show another field "Offline Session Max" with the timeout? Which can be 60 days by default maybe? At the model level, there would be still single int value IMO (EG. When the value is -1, it means infinity, which means that "Offline Session Max Limited" switch will be OFF in admin console and "Offline Session Max" hidden. When it is positive value, the "Offline Session Max Limited" switch will be ON and the actual value of timeout "Offline Session Max" will be shown). Could this work? Marek On 14/06/18 08:36, ???? / NORIMATSU?TAKASHI wrote: > Hello, > > I've found that keycloak does not support Offline Session Max related to Offline Token while supports SSO Session Max related to Refresh Token. > > For authorization of REST API services, long life(not infinite, such as 60days) refresh token is required, offline access and persistency in keycloak side are also expected. > Therefore, Offline Session Max is required for offline token. > > For example, consulting MS Azure, it has already supported this concept. > https://docs.microsoft.com/en-US/azure/active-directory/develop/active-directory-token-and-claims#token-revocation > > I would like to try to implement this feature. > Best regards, > Takashi Norimatsu > Hitachi Ltd., > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From takashi.norimatsu.ws at hitachi.com Mon Jun 18 20:24:32 2018 From: takashi.norimatsu.ws at hitachi.com (=?utf-8?B?5LmX5p2+6ZqG5b+XIC8gTk9SSU1BVFNV77yMVEFLQVNISQ==?=) Date: Tue, 19 Jun 2018 00:24:32 +0000 Subject: [keycloak-dev] Offline Session Max for Offline Token Message-ID: Hello, I agree with you. The specification seems to be as follows. * As default, operate as current Offline Access does, namely "Offline Session Max" concept is not adopted. * On Admin Console, have "Offline Session Max Limited" ON/OFF switch. If ON, show "Offline Session Max" dropdown whose default value is "60 days". If Off, it disappears. Default is OFF. * In Model, not use something to keep "Offline Session Max Limited" ON/OFF switch setting. Only use int to keep "Offline Session Max" value whose unit is "second". -1 indicates "infinity", namely not expire by "Offline Session Max". One point I would like to discuss is how to accommodate "Offline Session Max" setting (also "Offline Session Max Limited" ON/OFF switch implicitly). My proposal is the following. * On UI(html, js) and RealmModel, use setter/getter. * On RealmAdapter and RealmEntity, use attributes. * On RealmAttributes, define its attribute key such as String OFFLINE_SESSION_MAX_LIFESPAN = "offlineSessionMaxLifespan"; The reason why is to avoid DB migration works. What do you think about that? Best regards, Takashi Norimatsu Hitachi Ltd., -----Original Message----- From: Marek Posolda Sent: Monday, June 18, 2018 8:29 PM To: ???? / NORIMATSU?TAKASHI ; 'keycloak-dev at lists.jboss.org' Subject: [!]Re: [keycloak-dev] Offline Session Max for Offline Token Hi, it makes sense to me to have support for this. However IMO default value should be still "infinity" like it is now. I am not sure what is the best way to handle this in admin console considering usability? Considering that timeouts in admin console (Tab "Tokens" of "Realm Settings") doesn't yet support infinity. And other timeouts besides "Offline Session Max" still should be kept to not support infinity IMO. Maybe one way is to have On/Off switch like "Offline Session Max Limited" . It is off by default and when it is switched to ON, it will show another field "Offline Session Max" with the timeout? Which can be 60 days by default maybe? At the model level, there would be still single int value IMO (EG. When the value is -1, it means infinity, which means that "Offline Session Max Limited" switch will be OFF in admin console and "Offline Session Max" hidden. When it is positive value, the "Offline Session Max Limited" switch will be ON and the actual value of timeout "Offline Session Max" will be shown). Could this work? Marek On 14/06/18 08:36, ???? / NORIMATSU?TAKASHI wrote: > Hello, > > I've found that keycloak does not support Offline Session Max related to Offline Token while supports SSO Session Max related to Refresh Token. > > For authorization of REST API services, long life(not infinite, such as 60days) refresh token is required, offline access and persistency in keycloak side are also expected. > Therefore, Offline Session Max is required for offline token. > > For example, consulting MS Azure, it has already supported this concept. > https://clicktime.symantec.com/a/1/--rcGHJujTdPJSfFwNlM2MIYGqLILoWPKdL > 9CWfmjNc=?d=YWVjrivvynl5nVuhig7Zwbvg38OkJyUVDhaDQ312OlDzgNM4xTTDVE89zf > _mLEMJrbOBesYy_-Yw2RhKJfJm5AANJ_OD6WaMyDNij1Xb4Cuf-VYC4Ch2z5y5DLJ3vdQd > Cr_N3VusQfJENUGg44FTkalpZ_1vwmTbXJV1hjQGmNYtp8Hp6BWFQZmIv60C2fQGJYo4R0 > Pzdorm-4IhlIYi5LyAp_T45WsKMOn7PkZVYkBanJxHl3ESfMgcvkxElRlAfh2luIzQQkiz > e7gu-mj7EDmYyUiA6n4ngr8_PD0i3-0-GJbATfxQjS3Cg-MTJbjf6DdPlNhxriDK869vtT > 2bc6zkl0tBQxOQ5Sr6xspyxpbjN5mwFSvN4w2AmX0pfoubD3uf8mSNb5dBZjJ4xkOj9w%3 > D%3D&u=https%3A%2F%2Fdocs.microsoft.com%2Fen-US%2Fazure%2Factive-direc > tory%2Fdevelop%2Factive-directory-token-and-claims%23token-revocation > > I would like to try to implement this feature. > Best regards, > Takashi Norimatsu > Hitachi Ltd., > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://clicktime.symantec.com/a/1/PRLXsV_IH6jByHBptfs7DU9QRvpmlAlFI31 > S45woinY=?d=YWVjrivvynl5nVuhig7Zwbvg38OkJyUVDhaDQ312OlDzgNM4xTTDVE89zf_mLEMJrbOBesYy_-Yw2RhKJfJm5AANJ_OD6WaMyDNij1Xb4Cuf-VYC4Ch2z5y5DLJ3vdQdCr_N3VusQfJENUGg44FTkalpZ_1vwmTbXJV1hjQGmNYtp8Hp6BWFQZmIv60C2fQGJYo4R0Pzdorm-4IhlIYi5LyAp_T45WsKMOn7PkZVYkBanJxHl3ESfMgcvkxElRlAfh2luIzQQkize7gu-mj7EDmYyUiA6n4ngr8_PD0i3-0-GJbATfxQjS3Cg-MTJbjf6DdPlNhxriDK869vtT2bc6zkl0tBQxOQ5Sr6xspyxpbjN5mwFSvN4w2AmX0pfoubD3uf8mSNb5dBZjJ4xkOj9w%3D%3D&u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev From mposolda at redhat.com Tue Jun 19 14:54:46 2018 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 19 Jun 2018 20:54:46 +0200 Subject: [keycloak-dev] Offline Session Max for Offline Token In-Reply-To: References: Message-ID: <32accbeb-c159-0019-96ad-c6afacab1447@redhat.com> On 19/06/18 02:24, ???? / NORIMATSU?TAKASHI wrote: > Hello, > > I agree with you. The specification seems to be as follows. > > * As default, operate as current Offline Access does, namely "Offline Session Max" concept is not adopted. > * On Admin Console, have "Offline Session Max Limited" ON/OFF switch. If ON, show "Offline Session Max" dropdown whose default value is "60 days". If Off, it disappears. Default is OFF. > * In Model, not use something to keep "Offline Session Max Limited" ON/OFF switch setting. Only use int to keep "Offline Session Max" value whose unit is "second". -1 indicates "infinity", namely not expire by "Offline Session Max". > > One point I would like to discuss is how to accommodate "Offline Session Max" setting (also "Offline Session Max Limited" ON/OFF switch implicitly). > > My proposal is the following. > > * On UI(html, js) and RealmModel, use setter/getter. > * On RealmAdapter and RealmEntity, use attributes. > * On RealmAttributes, define its attribute key such as > String OFFLINE_SESSION_MAX_LIFESPAN = "offlineSessionMaxLifespan"; > > The reason why is to avoid DB migration works. > > What do you think about that? +1 Marek > > Best regards, > Takashi Norimatsu > Hitachi Ltd., > > -----Original Message----- > From: Marek Posolda > Sent: Monday, June 18, 2018 8:29 PM > To: ???? / NORIMATSU?TAKASHI ; 'keycloak-dev at lists.jboss.org' > Subject: [!]Re: [keycloak-dev] Offline Session Max for Offline Token > > Hi, > > it makes sense to me to have support for this. However IMO default value should be still "infinity" like it is now. > > I am not sure what is the best way to handle this in admin console considering usability? Considering that timeouts in admin console (Tab "Tokens" of "Realm Settings") doesn't yet support infinity. And other timeouts besides "Offline Session Max" still should be kept to not support infinity IMO. > > Maybe one way is to have On/Off switch like "Offline Session Max Limited" . It is off by default and when it is switched to ON, it will show another field "Offline Session Max" with the timeout? Which can be > 60 days by default maybe? At the model level, there would be still single int value IMO (EG. When the value is -1, it means infinity, which means that "Offline Session Max Limited" switch will be OFF in admin console and "Offline Session Max" hidden. When it is positive value, the "Offline Session Max Limited" switch will be ON and the actual value of timeout "Offline Session Max" will be shown). Could this work? > > Marek > > > > On 14/06/18 08:36, ???? / NORIMATSU?TAKASHI wrote: >> Hello, >> >> I've found that keycloak does not support Offline Session Max related to Offline Token while supports SSO Session Max related to Refresh Token. >> >> For authorization of REST API services, long life(not infinite, such as 60days) refresh token is required, offline access and persistency in keycloak side are also expected. >> Therefore, Offline Session Max is required for offline token. >> >> For example, consulting MS Azure, it has already supported this concept. >> https://clicktime.symantec.com/a/1/--rcGHJujTdPJSfFwNlM2MIYGqLILoWPKdL >> 9CWfmjNc=?d=YWVjrivvynl5nVuhig7Zwbvg38OkJyUVDhaDQ312OlDzgNM4xTTDVE89zf >> _mLEMJrbOBesYy_-Yw2RhKJfJm5AANJ_OD6WaMyDNij1Xb4Cuf-VYC4Ch2z5y5DLJ3vdQd >> Cr_N3VusQfJENUGg44FTkalpZ_1vwmTbXJV1hjQGmNYtp8Hp6BWFQZmIv60C2fQGJYo4R0 >> Pzdorm-4IhlIYi5LyAp_T45WsKMOn7PkZVYkBanJxHl3ESfMgcvkxElRlAfh2luIzQQkiz >> e7gu-mj7EDmYyUiA6n4ngr8_PD0i3-0-GJbATfxQjS3Cg-MTJbjf6DdPlNhxriDK869vtT >> 2bc6zkl0tBQxOQ5Sr6xspyxpbjN5mwFSvN4w2AmX0pfoubD3uf8mSNb5dBZjJ4xkOj9w%3 >> D%3D&u=https%3A%2F%2Fdocs.microsoft.com%2Fen-US%2Fazure%2Factive-direc >> tory%2Fdevelop%2Factive-directory-token-and-claims%23token-revocation >> >> I would like to try to implement this feature. >> Best regards, >> Takashi Norimatsu >> Hitachi Ltd., >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://clicktime.symantec.com/a/1/PRLXsV_IH6jByHBptfs7DU9QRvpmlAlFI31 >> S45woinY=?d=YWVjrivvynl5nVuhig7Zwbvg38OkJyUVDhaDQ312OlDzgNM4xTTDVE89zf_mLEMJrbOBesYy_-Yw2RhKJfJm5AANJ_OD6WaMyDNij1Xb4Cuf-VYC4Ch2z5y5DLJ3vdQdCr_N3VusQfJENUGg44FTkalpZ_1vwmTbXJV1hjQGmNYtp8Hp6BWFQZmIv60C2fQGJYo4R0Pzdorm-4IhlIYi5LyAp_T45WsKMOn7PkZVYkBanJxHl3ESfMgcvkxElRlAfh2luIzQQkize7gu-mj7EDmYyUiA6n4ngr8_PD0i3-0-GJbATfxQjS3Cg-MTJbjf6DdPlNhxriDK869vtT2bc6zkl0tBQxOQ5Sr6xspyxpbjN5mwFSvN4w2AmX0pfoubD3uf8mSNb5dBZjJ4xkOj9w%3D%3D&u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev > From johannes at kodet.no Tue Jun 19 18:27:55 2018 From: johannes at kodet.no (Johannes Knutsen) Date: Wed, 20 Jun 2018 00:27:55 +0200 Subject: [keycloak-dev] Improved CSP support Message-ID: Hi, I am currently looking at improvements in the Content Security Policy (CSP) support. In our deployment, we have security requirements stating that a CSP header should be used and inline scripts, styles and resources should be blocked. For example by setting a CSP value like default-src 'self';. Such a policy breaks Keycloak's manipulation of the browser history implemented in the BrowserHistoryHelper, since the JavascriptHistoryReplace injects an inline JavaScript. The simplest workaround is to also inject a nonce value or SHA hash of the script to the existing CSP header. However, while implementing this, I found that a CSP nonce in general would be nice to have available in any template context. This will also make it easier to migrate the default Keycloak theme to support stricter security policies. An example implementation can be found here: https://github.com/knutz3n/keycloak/commit/c6cfb3efa2942d7569066c0e4bd90a2ed75a0005 Would you be interested in merging a change like the one above? If not, what is your view on how to allow stricter content security policies? Tests and documentation is currently missing, but I will add both if this is something you would consider merging. As a note, I have also done some work on supporting a strict CSP value for the default theme. But there are some issues with included 3rd party scripts which must/should be resolved. Let me know if you want more details regarding this. Best regards, Johannes Knutsen From Mark.McGuigan at 360globalnet.com Wed Jun 20 04:52:29 2018 From: Mark.McGuigan at 360globalnet.com (Mark McGuigan) Date: Wed, 20 Jun 2018 08:52:29 +0000 Subject: [keycloak-dev] Accessing Token Endpoint with a User access token to get Permissions In-Reply-To: References: Message-ID: Hi, Apologies if this email is incorrectly posted. I'm using the newly released Keycloak 4 and I've been able to successfully get an access token for a user from an access code posted back to my application. This doesn't contain any permissions on the token (Rightly so, only roles) I'm now trying to get an RPT with permissions from the of client application that reflect what the User is allowed to do. My request looks something like: POST /auth/realms/MyRealm/protocol/openid-connect/token HTTP/1.1 Host: localhost:8080 Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5c ... Content-Type: application/x-www-form-urlencoded Cache-Control: no-cache Postman-Token: 4054feaf-a9d7-48e2-99b6-eabc86bf8da5 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Auma-ticket&audience=MyClient&permission=Default+Resource Where the Bearer is the generated access_token. However I'me getting a response of : 500 Internal Server Error { "error": "server_error", "error_description": "Unexpected error while evaluating permissions" } And a stack trace of: Unexpected error while evaluating permissions: java.lang.RuntimeException: Error while reading attributes from security token. at org.keycloak.authorization.common.KeycloakIdentity.(KeycloakIdentity.java:139) at org.keycloak.authorization.common.KeycloakIdentity.(KeycloakIdentity.java:68) at org.keycloak.authorization.authorization.AuthorizationTokenService.lambda$static$1(AuthorizationTokenService.java:124) at org.keycloak.authorization.authorization.AuthorizationTokenService.createEvaluationContext(AuthorizationTokenService.java:311) at org.keycloak.authorization.authorization.AuthorizationTokenService.authorize(AuthorizationTokenService.java:161) at org.keycloak.protocol.oidc.endpoints.TokenEndpoint.permissionGrant(TokenEndpoint.java:1124) at org.keycloak.protocol.oidc.endpoints.TokenEndpoint.processGrantRequest(TokenEndpoint.java:190) ..... Caused by: java.lang.NullPointerException at org.keycloak.services.util.DefaultClientSessionContext.fromClientSessionScopeParameter(DefaultClientSessionContext.java:64) at org.keycloak.authorization.common.KeycloakIdentity.(KeycloakIdentity.java:123) Any Ideas what I may be doing wrong? Any help appreciated. Regards, Mark From gambol99 at gmail.com Wed Jun 20 07:04:04 2018 From: gambol99 at gmail.com (gambol) Date: Wed, 20 Jun 2018 12:04:04 +0100 Subject: [keycloak-dev] LDAP Federation & Subject ID's Message-ID: Hiya One of our projects is looking to tie Knox and Keycloak together; with some documentation here https://community.hortonworks.com/articles/196751/knox-accept-third-party-jwt.html. At the moment the users are being federated to an ldap user store. The issue at the moment is the subject ID, they would like this mapped 'uid' attribute to the user representation in ldap, is this simply a matter of changing the 'UUID LDAP attribute' .. They did try and they started getting errors logging in, I'm guessing this was perhaps due to changing the mapping once users had already been imported? ... Alas, I don't have access to components myself, so acting as a middle man at the moment Rohith From james.holland at outlook.com Wed Jun 20 12:37:35 2018 From: james.holland at outlook.com (James Holland) Date: Wed, 20 Jun 2018 16:37:35 +0000 Subject: [keycloak-dev] Decoupled channel authentication (Google Push Authn) Message-ID: Hi, I'm trying to work out how to add an authentication flow where the actual authentication is done in another channel. Something like Google Push Authenticator, the IDP sends a push message that encodes a transaction, the app receives the push msg, decodes, and prompts the user to confirm (which signs the transaction). This signature is then sent to the IDP and thus allows access to the user in the original triggering channel. The only thing the user has to supply original triggering channel is a user identifier, no credentials. I have all this work in a standalone solution but wish to add this to keycloak, There are two OAuth2 related standards that support this model (but I could not find them on roadmap or feature requests): - - https://tools.ietf.org/html/draft-ietf-oauth-device-flow - http://openid.net/specs/openid-connect-modrna-client-initiated-backchannel-authentication-1_0.html I'm struggling to understand the various KeyCloak SPI's and when they are invoked, what is the flow? Does there exist a sequence or collaboration diagram on how the SPIs interact? So can anyone point me in the correct approach to this within KeyCloak, my current guess is: 1) Write an implementation of the Authentication SPI to send the push message and store the details of the transaction against the user record. 2) Create an endpoint to validate the authentication from the push app and update the stored transaction as complete (or could this be the existing OIDC endpoint but with a different Authentication SPI implementation to validate the TX) 3) Write some template pages/scripts that will poll against a new API to see if the transaction is complete, if it is it returns a Access &/or a Id token For the initial version I'd expect to have the page/JS poll the API but eventually replace with websocket, the http session object subscribing to a message queue to be informed on the transaction is complete. Sorry for the long message, but any guidance is very welcome. Obviously I intend to make it OSS. Regards James From gambol99 at gmail.com Thu Jun 21 08:08:06 2018 From: gambol99 at gmail.com (gambol) Date: Thu, 21 Jun 2018 13:08:06 +0100 Subject: [keycloak-dev] LDAP Federation & Subject ID's In-Reply-To: References: Message-ID: It appears I can map the sub claim to a user property i.e email ... But not a user attribute ... I was hoping to just add a uid to the user and manage like that assuming we can't get ldap mapping correctly On Wed, Jun 20, 2018, 12:04 PM gambol wrote: > Hiya > > One of our projects is looking to tie Knox and Keycloak together; with > some documentation here > https://community.hortonworks.com/articles/196751/knox-accept-third-party-jwt.html. > At the moment the users are being federated to an ldap user store. > > The issue at the moment is the subject ID, they would like this mapped > 'uid' attribute to the user representation in ldap, is this simply a matter > of changing the 'UUID LDAP attribute' .. They did try and they started > getting errors logging in, I'm guessing this was perhaps due to changing > the mapping once users had already been imported? ... > > Alas, I don't have access to components myself, so acting as a middle man > at the moment > > Rohith > From mposolda at redhat.com Thu Jun 21 08:30:52 2018 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 21 Jun 2018 14:30:52 +0200 Subject: [keycloak-dev] LDAP Federation & Subject ID's In-Reply-To: References: Message-ID: <6259578f-a649-801f-3946-811f0dfc23fa@redhat.com> On 20/06/18 13:04, gambol wrote: > Hiya > > One of our projects is looking to tie Knox and Keycloak together; with some > documentation here > https://community.hortonworks.com/articles/196751/knox-accept-third-party-jwt.html. > At the moment the users are being federated to an ldap user store. > > The issue at the moment is the subject ID, they would like this mapped > 'uid' attribute to the user representation in ldap, is this simply a matter > of changing the 'UUID LDAP attribute' .. They did try and they started > getting errors logging in, I'm guessing this was perhaps due to changing > the mapping once users had already been imported? ... Yes, exactly. I think it should be fine to configure "UUID LDAP Attribute" to the value "uid" , but if you already have some users imported from LDAP and then you change configuration later, strange things can happen. It seems we should document this limitation a bit more... One thing why "UUID LDAP Attribute" is not "uid" by default is, that "uid" can't be guaranteed to be 100% unique and it can happen that it's different user in some cases. For example scenario like: - User john is in LDAP "uid=john,dc=example,dc=com" - User john was unregistered from app and hence deleted from the LDAP - After some time, there is another user "john", who wants to register. He will be registered in LDAP with same uid like previous user. So "uid=john,dc=example,dc=com" . At this point, Keycloak won't be able to differentiate that 1st john and 2nd john is different user in case that "UUID LDAP Attribute" is mapped to "uid" . If you're fine with this limitation, it should be ok Marek > > Alas, I don't have access to components myself, so acting as a middle man > at the moment > > Rohith > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From gambol99 at gmail.com Thu Jun 21 09:35:54 2018 From: gambol99 at gmail.com (gambol) Date: Thu, 21 Jun 2018 14:35:54 +0100 Subject: [keycloak-dev] Outage Issue Message-ID: Hiya I was wondering if anyone has come across this before. We have Keycloak running in a kubernetes cluster, a mysql RDS, and standalone-ha setup using two gossip servers, each running behind a kube service and passed in via environment variables ${env.GOSSIP_ROUTER_HOST} Cluster appears to work fine, a new node added makes a change to topology and so forth. We do however out of the blue get the following error on occasion, every couple of weeks... Shortly after the rest of the replicas become affected, the health check on the /auth fails and or login attempts begin to timeout .. At present the only solution is to completely cycle the cluster. 13:07:52,451 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012108: CheckedAction::check - atomic action 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:47876e aborting with 1 threads active! 13:07:52,451 WARN [org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorTrackingImpl] (Transaction Reaper Worker 0) HHH000451: Transaction afterCompletion called by a background thread; delaying afterCompletion processing until the original thread can handle it. [status=4] 13:07:52,451 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:47876e 13:07:55,475 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:4787b9 in state RUN 13:07:55,476 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012095: Abort of action id 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:4787b9 invoked while multiple threads active within it. 13:07:55,480 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012381: Action id 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:4787b9 completed with multiple threads - thread default task-64 was in progress with sun.misc.Unsafe.park(Native Method) java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) org.apache.http.pool.PoolEntryFuture.await(PoolEntryFuture.java:138) org.apache.http.pool.AbstractConnPool.getPoolEntryBlocking(AbstractConnPool.java:306) org.apache.http.pool.AbstractConnPool.access$000(AbstractConnPool.java:64) org.apache.http.pool.AbstractConnPool$2.getPoolEntry(AbstractConnPool.java:192) org.apache.http.pool.AbstractConnPool$2.getPoolEntry(AbstractConnPool.java:185) org.apache.http.pool.PoolEntryFuture.get(PoolEntryFuture.java:107) org.apache.http.impl.conn.PoolingHttpClientConnectionManager.leaseConnection(PoolingHttpClientConnectionManager.java:276) org.apache.http.impl.conn.PoolingHttpClientConnectionManager$1.get(PoolingHttpClientConnectionManager.java:263) org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:190) org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184) org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88) org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184) org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107) org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55) org.keycloak.broker.provider.util.SimpleHttp.makeRequest(SimpleHttp.java:185) org.keycloak.broker.provider.util.SimpleHttp.asResponse(SimpleHttp.java:154) org.keycloak.broker.provider.util.SimpleHttp.asString(SimpleHttp.java:146) org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider$Endpoint.authResponse(AbstractOAuth2IdentityProvider.java:397) sun.reflect.GeneratedMethodAccessor994.invoke(Unknown Source) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) java.lang.reflect.Method.invoke(Method.java:498) org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140) org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107) org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133) org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:406) org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:213) org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:228) 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.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:90) io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) 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) org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68) io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$1243/578097420.call(Unknown Source) org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown Source) org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown Source) org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown Source) org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown Source) io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) io.undertow.server.Connectors.executeRootHandler(Connectors.java:326) io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812) java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) java.lang.Thread.run(Thread.java:748) Repeating over and over ... Just before is 11:26:08,882 WARN [org.keycloak.events] (default task-166) type=CODE_TO_TOKEN_ERROR, realmId=XXX, clientId=XXXX, userId=null, ipAddress=XXXXXXXXXX , error=invalid_code, grant_type=authorization_code, code_id=XXXXXXXX , client_auth_method=client-secret 11:30:04,172 WARN [org.keycloak.services.managers.AuthenticationManager] (default task-100) Some clients have been not been logged out for user XXXXXXXXXXXXXXXXXXX in hod-ci realm: XXXXX 11:30:04,203 WARN [org.keycloak.events] (default task-92) type=IDENTITY_PROVIDER_LOGIN_ERROR, realmId=HOD-CI, clientId=null, userId=null, ipAddress=213.251.23.186, error=expired_code, identity_provider=O365, restart_after_timeout=true 11:38:13,851 WARN [org.keycloak.forms.login.freemarker.model.ProfileBean] (default task-88) There are more values for attribute 'group' of user 'XXXX\XXXXXX' . Will display just first value 11:43:37,370 WARN [org.keycloak.events] (default task-36) type=LOGIN_ERROR, realmId=lev, clientId=lev-web, userId=null, ipAddress=XXXXXXXX, error=user_not_found, auth_method=openid-connect, auth_type=code, redirect_uri=https://lev.homeoffice.gov.uk/oauth/callback, code_id=5a08f532-1051-4805-8dd6-d71362303521, username=XXXXXXXXX 11:47:01,018 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:46efe0 in state RUN 11:47:01,019 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012095: Abort of action id 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:46efe0 invoked while multiple threads active within it. 11:47:01,022 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012381: Action id 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:46efe0 completed with multiple threads - thread default task-165 was in progress with sun.misc.Unsafe.park(Native Method) java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) org.apache.http.pool.PoolEntryFuture.await(PoolEntryFuture.java:138) org.apache.http.pool.AbstractConnPool.getPoolEntryBlocking(AbstractConnPool.java:306) org.apache.http.pool.AbstractConnPool.access$000(AbstractConnPool.java:64) org.apache.http.pool.AbstractConnPool$2.getPoolEntry(AbstractConnPool.java:192) org.apache.http.pool.AbstractConnPool$2.getPoolEntry(AbstractConnPool.java:185) org.apache.http.pool.PoolEntryFuture.get(PoolEntryFuture.java:107) org.apache.http.impl.conn.PoolingHttpClientConnectionManager.leaseConnection(PoolingHttpClientConnectionManager.java:276) org.apache.http.impl.conn.PoolingHttpClientConnectionManager$1.get(PoolingHttpClientConnectionManager.java:263) org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:190) org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184) org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88) org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184) org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107) org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55) org.keycloak.broker.provider.util.SimpleHttp.makeRequest(SimpleHttp.java:185) org.keycloak.broker.provider.util.SimpleHttp.asResponse(SimpleHttp.java:154) org.keycloak.broker.provider.util.SimpleHttp.asString(SimpleHttp.java:146) org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider$Endpoint.authResponse(AbstractOAuth2IdentityProvider.java:397) sun.reflect.GeneratedMethodAccessor994.invoke(Unknown Source) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) java.lang.reflect.Method.invoke(Method.java:498) org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140) org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107) org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133) org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:406) org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:213) org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:228) 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.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:90) io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) 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) org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68) io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$1243/578097420.call(Unknown Source) org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown Source) org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown Source) org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown Source) org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown Source) io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) io.undertow.server.Connectors.executeRootHandler(Connectors.java:326) io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812) java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) java.lang.Thread.run(Thread.java:748) Rohith From psilva at redhat.com Fri Jun 22 10:42:21 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Fri, 22 Jun 2018 11:42:21 -0300 Subject: [keycloak-dev] Accessing Token Endpoint with a User access token to get Permissions In-Reply-To: References: Message-ID: Hi, Are you sending the access token or ID token as a bearer ? Could you give more details on how you are obtaining the token ? On Wed, Jun 20, 2018 at 5:52 AM, Mark McGuigan < Mark.McGuigan at 360globalnet.com> wrote: > Hi, > > Apologies if this email is incorrectly posted. > > I'm using the newly released Keycloak 4 and I've been able to successfully > get an access token for a user from an access code posted back to my > application. This doesn't contain any permissions on the token (Rightly so, > only roles) > I'm now trying to get an RPT with permissions from the of client > application that reflect what the User is allowed to do. > > My request looks something like: > POST /auth/realms/MyRealm/protocol/openid-connect/token HTTP/1.1 > Host: localhost:8080 > Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5c ... > Content-Type: application/x-www-form-urlencoded > Cache-Control: no-cache > Postman-Token: 4054feaf-a9d7-48e2-99b6-eabc86bf8da5 > > grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Auma-ticket&audience= > MyClient&permission=Default+Resource > > Where the Bearer is the generated access_token. However I'me getting a > response of : > > 500 Internal Server Error > { > "error": "server_error", > "error_description": "Unexpected error while evaluating permissions" > } > > And a stack trace of: > > Unexpected error while evaluating permissions: java.lang.RuntimeException: > Error while reading attributes from security token. > at org.keycloak.authorization.common.KeycloakIdentity. > (KeycloakIdentity.java:139) > at org.keycloak.authorization.common.KeycloakIdentity. > (KeycloakIdentity.java:68) > at org.keycloak.authorization.authorization. > AuthorizationTokenService.lambda$static$1(AuthorizationTokenService. > java:124) > at org.keycloak.authorization.authorization. > AuthorizationTokenService.createEvaluationContext( > AuthorizationTokenService.java:311) > at org.keycloak.authorization.authorization. > AuthorizationTokenService.authorize(AuthorizationTokenService.java:161) > at org.keycloak.protocol.oidc.endpoints.TokenEndpoint. > permissionGrant(TokenEndpoint.java:1124) > at org.keycloak.protocol.oidc.endpoints.TokenEndpoint. > processGrantRequest(TokenEndpoint.java:190) > ..... > Caused by: java.lang.NullPointerException > at org.keycloak.services.util.DefaultClientSessionContext. > fromClientSessionScopeParameter(DefaultClientSessionContext.java:64) > at org.keycloak.authorization.common.KeycloakIdentity. > (KeycloakIdentity.java:123) > > Any Ideas what I may be doing wrong? Any help appreciated. > > Regards, > > Mark > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From Mark.McGuigan at 360globalnet.com Fri Jun 22 10:52:21 2018 From: Mark.McGuigan at 360globalnet.com (Mark McGuigan) Date: Fri, 22 Jun 2018 14:52:21 +0000 Subject: [keycloak-dev] Accessing Token Endpoint with a User access token to get Permissions In-Reply-To: References: Message-ID: HI Pedro, Sure, my process is as follows: * Application forwards to Authorisation service to get a response type of ?code? * Authorisation service returns code and I forward it to the Token endpoint (no bearer) to get an access token * The Access Token contains the user authentication JWT at this point (contains Roles but not permissions) * Then I try to pass this access token as a ?bearer? to the token endpoint to get user permission but this is where I get the 500 Error described below Any pointers as to what I could be doing wrong would really be appreciated.. Kind regards, Mark From: Pedro Igor Silva [mailto:psilva at redhat.com] Sent: 22 June 2018 15:42 To: Mark McGuigan Cc: keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] Accessing Token Endpoint with a User access token to get Permissions Hi, Are you sending the access token or ID token as a bearer ? Could you give more details on how you are obtaining the token ? On Wed, Jun 20, 2018 at 5:52 AM, Mark McGuigan > wrote: Hi, Apologies if this email is incorrectly posted. I'm using the newly released Keycloak 4 and I've been able to successfully get an access token for a user from an access code posted back to my application. This doesn't contain any permissions on the token (Rightly so, only roles) I'm now trying to get an RPT with permissions from the of client application that reflect what the User is allowed to do. My request looks something like: POST /auth/realms/MyRealm/protocol/openid-connect/token HTTP/1.1 Host: localhost:8080 Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5c ... Content-Type: application/x-www-form-urlencoded Cache-Control: no-cache Postman-Token: 4054feaf-a9d7-48e2-99b6-eabc86bf8da5 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Auma-ticket&audience=MyClient&permission=Default+Resource Where the Bearer is the generated access_token. However I'me getting a response of : 500 Internal Server Error { "error": "server_error", "error_description": "Unexpected error while evaluating permissions" } And a stack trace of: Unexpected error while evaluating permissions: java.lang.RuntimeException: Error while reading attributes from security token. at org.keycloak.authorization.common.KeycloakIdentity.(KeycloakIdentity.java:139) at org.keycloak.authorization.common.KeycloakIdentity.(KeycloakIdentity.java:68) at org.keycloak.authorization.authorization.AuthorizationTokenService.lambda$static$1(AuthorizationTokenService.java:124) at org.keycloak.authorization.authorization.AuthorizationTokenService.createEvaluationContext(AuthorizationTokenService.java:311) at org.keycloak.authorization.authorization.AuthorizationTokenService.authorize(AuthorizationTokenService.java:161) at org.keycloak.protocol.oidc.endpoints.TokenEndpoint.permissionGrant(TokenEndpoint.java:1124) at org.keycloak.protocol.oidc.endpoints.TokenEndpoint.processGrantRequest(TokenEndpoint.java:190) ..... Caused by: java.lang.NullPointerException at org.keycloak.services.util.DefaultClientSessionContext.fromClientSessionScopeParameter(DefaultClientSessionContext.java:64) at org.keycloak.authorization.common.KeycloakIdentity.(KeycloakIdentity.java:123) Any Ideas what I may be doing wrong? Any help appreciated. Regards, Mark _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From psilva at redhat.com Fri Jun 22 13:23:56 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Fri, 22 Jun 2018 14:23:56 -0300 Subject: [keycloak-dev] Accessing Token Endpoint with a User access token to get Permissions In-Reply-To: References: Message-ID: I'm not sure what is happening, this flow is similar to what we do in quickstarts and tests. Could you please export your realm and send me the file? On Fri, Jun 22, 2018 at 11:52 AM, Mark McGuigan < Mark.McGuigan at 360globalnet.com> wrote: > HI Pedro, > > > > Sure, my process is as follows: > > - Application forwards to Authorisation service to get a response type > of ?code? > - Authorisation service returns code and I forward it to the Token > endpoint (no bearer) to get an access token > - The Access Token contains the user authentication JWT at this point > (contains Roles but not permissions) > - Then I try to pass this access token as a ?bearer? to the token > endpoint to get user permission but this is where I get the 500 Error > described below > > > > Any pointers as to what I could be doing wrong would really be > appreciated.. > > Kind regards, > > > > Mark > > > > > > *From:* Pedro Igor Silva [mailto:psilva at redhat.com] > *Sent:* 22 June 2018 15:42 > *To:* Mark McGuigan > *Cc:* keycloak-dev at lists.jboss.org > *Subject:* Re: [keycloak-dev] Accessing Token Endpoint with a User access > token to get Permissions > > > > Hi, > > > > Are you sending the access token or ID token as a bearer ? Could you give > more details on how you are obtaining the token ? > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jun 20, 2018 at 5:52 AM, Mark McGuigan < > Mark.McGuigan at 360globalnet.com> wrote: > > Hi, > > Apologies if this email is incorrectly posted. > > I'm using the newly released Keycloak 4 and I've been able to successfully > get an access token for a user from an access code posted back to my > application. This doesn't contain any permissions on the token (Rightly so, > only roles) > I'm now trying to get an RPT with permissions from the of client > application that reflect what the User is allowed to do. > > My request looks something like: > POST /auth/realms/MyRealm/protocol/openid-connect/token HTTP/1.1 > Host: localhost:8080 > Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5c ... > Content-Type: application/x-www-form-urlencoded > Cache-Control: no-cache > Postman-Token: 4054feaf-a9d7-48e2-99b6-eabc86bf8da5 > > grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Auma-ticket&audience= > MyClient&permission=Default+Resource > > Where the Bearer is the generated access_token. However I'me getting a > response of : > > 500 Internal Server Error > { > "error": "server_error", > "error_description": "Unexpected error while evaluating permissions" > } > > And a stack trace of: > > Unexpected error while evaluating permissions: java.lang.RuntimeException: > Error while reading attributes from security token. > at org.keycloak.authorization.common.KeycloakIdentity. > (KeycloakIdentity.java:139) > at org.keycloak.authorization.common.KeycloakIdentity. > (KeycloakIdentity.java:68) > at org.keycloak.authorization.authorization. > AuthorizationTokenService.lambda$static$1(AuthorizationTokenService. > java:124) > at org.keycloak.authorization.authorization. > AuthorizationTokenService.createEvaluationContext( > AuthorizationTokenService.java:311) > at org.keycloak.authorization.authorization. > AuthorizationTokenService.authorize(AuthorizationTokenService.java:161) > at org.keycloak.protocol.oidc.endpoints.TokenEndpoint. > permissionGrant(TokenEndpoint.java:1124) > at org.keycloak.protocol.oidc.endpoints.TokenEndpoint. > processGrantRequest(TokenEndpoint.java:190) > ..... > Caused by: java.lang.NullPointerException > at org.keycloak.services.util.DefaultClientSessionContext. > fromClientSessionScopeParameter(DefaultClientSessionContext.java:64) > at org.keycloak.authorization.common.KeycloakIdentity. > (KeycloakIdentity.java:123) > > Any Ideas what I may be doing wrong? Any help appreciated. > > Regards, > > Mark > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > From eivind at jotta.no Mon Jun 25 03:50:45 2018 From: eivind at jotta.no (Eivind Larsen) Date: Mon, 25 Jun 2018 00:50:45 -0700 Subject: [keycloak-dev] Admin API: Delete session id Message-ID: Hi Keycloak Devs! In the admin API there is a call to delete a session by ID: DELETE /{realm}/sessions/{session_id} This works for user (online) sessions, but when given the session ID of an offline session, it gives 404 error and nothing is deleted. Seeing as this is the only way to delete a given as session by id, I would expect the call to work for offline sessions as well, ideally deleting both the user session and the offline session by this id. What do you think? Is there an alternative way to delete an offline session by id? I think it would be more useful if this call was scoped per user. Currently you have to load all user sessions, verify that this session ID is indeed owned by the user, then call delete. Scoping per user would make it impossible to delete a wrong user's session, and it would reduce requests to the keycloak instance. Best Regards, Eivind Larsen From james.holland at outlook.com Mon Jun 25 05:21:15 2018 From: james.holland at outlook.com (James Holland) Date: Mon, 25 Jun 2018 09:21:15 +0000 Subject: [keycloak-dev] Decoupled channel authentication (Google Push Authn) In-Reply-To: References: Message-ID: I've added the feature request https://issues.jboss.org/browse/KEYCLOAK-7675 for this. From sthorger at redhat.com Mon Jun 25 06:05:20 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 25 Jun 2018 12:05:20 +0200 Subject: [keycloak-dev] Admin API: Delete session id In-Reply-To: References: Message-ID: Hi, Please use the user mailing list for questions and help. On Mon, 25 Jun 2018 at 09:57, Eivind Larsen wrote: > Hi Keycloak Devs! > > In the admin API there is a call to delete a session by ID: > > DELETE /{realm}/sessions/{session_id} > > This works for user (online) sessions, but when given the session ID of an > offline session, it gives 404 error and nothing is deleted. > > Seeing as this is the only way to delete a given as session by id, > I would expect the call to work for offline sessions as well, > ideally deleting both the user session and the offline session by this id. > > What do you think? > > Is there an alternative way to delete an offline session by id? > > I think it would be more useful if this call was scoped per user. > Currently you have to load all user sessions, verify that this session ID > is indeed owned by the user, then call delete. Scoping per user would make > it impossible to delete a wrong user's session, and it would reduce > requests to the keycloak instance. > > Best Regards, > Eivind Larsen > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bruno at abstractj.org Mon Jun 25 11:42:29 2018 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 25 Jun 2018 12:42:29 -0300 Subject: [keycloak-dev] Keycloak Proxy Rename Message-ID: <20180625154229.GA17717@abstractj.org> Good afternoon, We are considering to transfer or fork the keycloak-proxy[1] to Keycloak organization. In order to accomplish that, I've been working with Rohith updating some of its dependencies[2]. While discussing with our team, we reached the conclusion that call it a proxy could potentially increase the scope of the project and also give people the wrong idea. Because would be expected things like load balancing, rate limiting, and other features. That's not what we want right now. I would like to gather some feedback from the community before we move forward. So please vote on the following Doodle: https://doodle.com/poll/gux626ktscgpr96t Also, feel free to suggest other names and it will be included. [1] - https://github.com/gambol99/keycloak-proxy [2] - https://issues.jboss.org/browse/KEYCLOAK-7265 -- abstractj From mposolda at redhat.com Tue Jun 26 04:59:58 2018 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 26 Jun 2018 10:59:58 +0200 Subject: [keycloak-dev] JWS signatures using PS256 or ES256 algorithms for signing In-Reply-To: References: Message-ID: On 30/05/18 09:35, Stian Thorgersen wrote: >> I think it might be better to determine which kind of Token Signature >> Provider be used by not parsing JWS, for example, looking up Client or >> Realm settings. >> This PR might have impacts on keycloak's performance because it has parsed >> JWS to determine it every time keycloak receives JWS Token. >> > On the server-side that is easy. On the adapter side that would probably > require adding a property to keycloak.json to set the algorithm. In either > case it should probably default to RSA for existing realms at least, but we > could consider setting it to ES256 for new realms. > +1 Parsing token signature to determine algorithm should be avoided IMO. AFAIR Some OAuth/OIDC vendors had security issues in the past, that they parsed the header with "none" algorithm and then client applications automatically trust unsigned tokens. We should make sure this is not possible. Marek From sthorger at redhat.com Tue Jun 26 12:25:15 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 26 Jun 2018 18:25:15 +0200 Subject: [keycloak-dev] JWS signatures using PS256 or ES256 algorithms for signing In-Reply-To: References: Message-ID: I don't really like the idea of having to reconfigure to make the adapter accept new signature. I know oidc well known endpoint doesn't have signature algorithm for access token, but we could add one and have adapters pull from the server what algorithms to accept. On Tue, 26 Jun 2018, 11:00 Marek Posolda, wrote: > On 30/05/18 09:35, Stian Thorgersen wrote: > > I think it might be better to determine which kind of Token Signature > Provider be used by not parsing JWS, for example, looking up Client or > Realm settings. > This PR might have impacts on keycloak's performance because it has parsed > JWS to determine it every time keycloak receives JWS Token. > > > On the server-side that is easy. On the adapter side that would probably > require adding a property to keycloak.json to set the algorithm. In either > case it should probably default to RSA for existing realms at least, but we > could consider setting it to ES256 for new realms. > > > +1 > > Parsing token signature to determine algorithm should be avoided IMO. > AFAIR Some OAuth/OIDC vendors had security issues in the past, that they > parsed the header with "none" algorithm and then client applications > automatically trust unsigned tokens. We should make sure this is not > possible. > > Marek > From sthorger at redhat.com Wed Jun 27 02:25:02 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 27 Jun 2018 08:25:02 +0200 Subject: [keycloak-dev] Decoupled channel authentication (Google Push Authn) In-Reply-To: References: Message-ID: Hi, Take a look at https://github.com/stianst/authenticator-example. It's just a POC, but it does pretty much what you're after with regards to an out of bands authenticator. Now to make it nice there's two aspects that needs to be worked on: 1. Support for additional multi factor mechanisms - users should be able to choose between available means, pluggable support including configuration, etc.. I hope this is something we'll be working on soon. 2. Push based out of bands - we need some concept of authentication events that the authenticator web page can wait for. I would assume this would use websockets. For Google prompt it would be nice to have that available OOTB, but it does depend on #1 to allow us to properly support more than one multi factor in a realm. On Mon, 25 Jun 2018 at 11:23, James Holland wrote: > I've added the feature request > https://issues.jboss.org/browse/KEYCLOAK-7675 for this. > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From mposolda at redhat.com Wed Jun 27 03:30:05 2018 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 27 Jun 2018 09:30:05 +0200 Subject: [keycloak-dev] JWS signatures using PS256 or ES256 algorithms for signing In-Reply-To: References: Message-ID: +1 Having the configuration in adapter (keycloak.json) won't scale also because REST services (bearer-only clients) will need to verify signatures by "frontend" clients, but each frontend client can use different algorithm to sign it's token. So keycloak.json of bearer-only clients would need to have some configuration map to track all of this... Also "rotation" of algorithms will be impossible (if administrator changes the algorithm for client in admin console, the adapter configuration in keycloak.json will need to be updated and hence application restarted...) But I think we don't need to add any new endpoint, but just re-use existing client registration endpoints for that? OIDC Client registration has various metadata for clients like id_token_signed_response_alg, id_token_encrypted_response_alg, userinfo_signed_response_alg etc. See [1]. Also we have support for Dynamic client registration management [2], so client applications are able to "download" the client's metadata from the endpoint. The specification enforces that requests are authenticated by Client Registration Access Token. But ATM we also support authentication by bearer tokens, which is great. When application sees the bearer token signed/encrypted by unknown algorithm, it can send the request to KC registration/management endpoint of particular client to download the client's metadata. This will work fine also for bearer-only clients. The bearer-only client can parse the token and send the request to the registration/management endpoint of particular "frontend" client the token was issued for to determine the right algorithms etc. [1] https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata [2] https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-05 Marek On 26/06/18 18:25, Stian Thorgersen wrote: > I don't really like the idea of having to reconfigure to make the > adapter accept new signature. I know oidc well known? endpoint doesn't > have signature algorithm for access token, but we could add one and > have adapters pull from the server what algorithms to accept. > > On Tue, 26 Jun 2018, 11:00 Marek Posolda, > wrote: > > On 30/05/18 09:35, Stian Thorgersen wrote: >>> I think it might be better to determine which kind of Token Signature >>> Provider be used by not parsing JWS, for example, looking up Client or >>> Realm settings. >>> This PR might have impacts on keycloak's performance because it has parsed >>> JWS to determine it every time keycloak receives JWS Token. >>> >> On the server-side that is easy. On the adapter side that would probably >> require adding a property to keycloak.json to set the algorithm. In either >> case it should probably default to RSA for existing realms at least, but we >> could consider setting it to ES256 for new realms. >> > +1 > > Parsing token signature to determine algorithm should be avoided > IMO. AFAIR Some OAuth/OIDC vendors had security issues in the > past, that they parsed the header with "none" algorithm and then > client applications automatically trust unsigned tokens. We should > make sure this is not possible. > > Marek > From james.holland at outlook.com Wed Jun 27 04:45:19 2018 From: james.holland at outlook.com (James Holland) Date: Wed, 27 Jun 2018 08:45:19 +0000 Subject: [keycloak-dev] Decoupled channel authentication (Google Push Authn) In-Reply-To: References: Message-ID: Hi Stian, thanks for this :-) AuthenticationFlowContext & UserSessionProvider no longer have methods to get the ClientSessionModel to lookup the user session, any suggestion on how to get this in 4.0.0.Final? I was looking at AuthenticationSessionProvider? I agree with you wrt to your points 1 & 2, websocket callback is something I'm working on separately, but only as a method of telling the waiting page to refresh instead of polling; just need a distributed Pub/sub & filter (so only the specific sessions get called.) Regards James Stian Thorgersen wrote on 27/06/2018 07:25: Hi, Take a look at https://github.com/stianst/authenticator-example. It's just a POC, but it does pretty much what you're after with regards to an out of bands authenticator. Now to make it nice there's two aspects that needs to be worked on: 1. Support for additional multi factor mechanisms - users should be able to choose between available means, pluggable support including configuration, etc.. I hope this is something we'll be working on soon. 2. Push based out of bands - we need some concept of authentication events that the authenticator web page can wait for. I would assume this would use websockets. For Google prompt it would be nice to have that available OOTB, but it does depend on #1 to allow us to properly support more than one multi factor in a realm. On Mon, 25 Jun 2018 at 11:23, James Holland > wrote: I've added the feature request https://issues.jboss.org/browse/KEYCLOAK-7675 for this. _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From slaskawi at redhat.com Wed Jun 27 05:57:03 2018 From: slaskawi at redhat.com (Sebastian Laskawiec) Date: Wed, 27 Jun 2018 11:57:03 +0200 Subject: [keycloak-dev] Outage Issue In-Reply-To: References: Message-ID: >From your description and the logs I guess it might be a problem with some transaction. Would you be able to tell us more about the Keycloak version you're running? Also, a Thread dump would be helpful and you might investigate if there are any long running transactions in the DB [1]. Thanks, Sebastian [1] https://www.psce.com/en/blog/2015/01/22/tracking-mysql-query-history-in-long-running-transactions/ On Thu, Jun 21, 2018 at 3:45 PM gambol wrote: > Hiya > > I was wondering if anyone has come across this before. We have Keycloak > running in a kubernetes cluster, a mysql RDS, and standalone-ha setup using > two gossip servers, each running behind a kube service and passed in via > environment variables > > > ${env.GOSSIP_ROUTER_HOST} > > > Cluster appears to work fine, a new node added makes a change to topology > and so forth. We do however out of the blue get the following error on > occasion, every couple of weeks... Shortly after the rest of the replicas > become affected, the health check on the /auth fails and or login attempts > begin to timeout .. At present the only solution is to completely cycle the > cluster. > > 13:07:52,451 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) > ARJUNA012108: CheckedAction::check - atomic action > 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:47876e aborting with 1 threads active! > 13:07:52,451 WARN > > [org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorTrackingImpl] > (Transaction Reaper Worker 0) HHH000451: Transaction afterCompletion called > by a background thread; delaying afterCompletion processing until the > original thread can handle it. [status=4] > 13:07:52,451 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) > ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction > Reaper Worker 0,5,main] successfully canceled TX > 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:47876e > 13:07:55,475 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) > ARJUNA012117: TransactionReaper::check timeout for TX > 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:4787b9 in state RUN > 13:07:55,476 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) > ARJUNA012095: Abort of action id 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:4787b9 > invoked while multiple threads active within it. > 13:07:55,480 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) > ARJUNA012381: Action id 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:4787b9 completed > with multiple threads - thread default task-64 was in progress with > sun.misc.Unsafe.park(Native Method) > java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) > org.apache.http.pool.PoolEntryFuture.await(PoolEntryFuture.java:138) > > org.apache.http.pool.AbstractConnPool.getPoolEntryBlocking(AbstractConnPool.java:306) > org.apache.http.pool.AbstractConnPool.access$000(AbstractConnPool.java:64) > > org.apache.http.pool.AbstractConnPool$2.getPoolEntry(AbstractConnPool.java:192) > > org.apache.http.pool.AbstractConnPool$2.getPoolEntry(AbstractConnPool.java:185) > org.apache.http.pool.PoolEntryFuture.get(PoolEntryFuture.java:107) > > org.apache.http.impl.conn.PoolingHttpClientConnectionManager.leaseConnection(PoolingHttpClientConnectionManager.java:276) > > org.apache.http.impl.conn.PoolingHttpClientConnectionManager$1.get(PoolingHttpClientConnectionManager.java:263) > > org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:190) > org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184) > org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88) > org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) > > org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184) > > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) > > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107) > > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55) > > org.keycloak.broker.provider.util.SimpleHttp.makeRequest(SimpleHttp.java:185) > > org.keycloak.broker.provider.util.SimpleHttp.asResponse(SimpleHttp.java:154) > org.keycloak.broker.provider.util.SimpleHttp.asString(SimpleHttp.java:146) > > org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider$Endpoint.authResponse(AbstractOAuth2IdentityProvider.java:397) > sun.reflect.GeneratedMethodAccessor994.invoke(Unknown Source) > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > java.lang.reflect.Method.invoke(Method.java:498) > > org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140) > > org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) > > org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) > > org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) > > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107) > > org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133) > > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) > > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:406) > > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:213) > > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:228) > > 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.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) > > org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:90) > io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) > > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) > > io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) > > 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) > > org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68) > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > > io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > > io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > > io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > > io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > > io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > > org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > > org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$1243/578097420.call(Unknown > Source) > > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) > > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown > Source) > > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) > > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown > Source) > > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) > > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown > Source) > > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) > > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown > Source) > > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > io.undertow.server.Connectors.executeRootHandler(Connectors.java:326) > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812) > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > java.lang.Thread.run(Thread.java:748) > > Repeating over and over ... Just before is > > 11:26:08,882 WARN [org.keycloak.events] (default task-166) > type=CODE_TO_TOKEN_ERROR, realmId=XXX, clientId=XXXX, userId=null, > ipAddress=XXXXXXXXXX , error=invalid_code, grant_type=authorization_code, > code_id=XXXXXXXX , client_auth_method=client-secret > 11:30:04,172 WARN [org.keycloak.services.managers.AuthenticationManager] > (default task-100) Some clients have been not been logged out for user > XXXXXXXXXXXXXXXXXXX in hod-ci realm: XXXXX > 11:30:04,203 WARN [org.keycloak.events] (default task-92) > type=IDENTITY_PROVIDER_LOGIN_ERROR, realmId=HOD-CI, clientId=null, > userId=null, ipAddress=213.251.23.186, error=expired_code, > identity_provider=O365, restart_after_timeout=true > 11:38:13,851 WARN [org.keycloak.forms.login.freemarker.model.ProfileBean] > (default task-88) There are more values for attribute 'group' of user > 'XXXX\XXXXXX' . Will display just first value > 11:43:37,370 WARN [org.keycloak.events] (default task-36) > type=LOGIN_ERROR, realmId=lev, clientId=lev-web, userId=null, > ipAddress=XXXXXXXX, error=user_not_found, auth_method=openid-connect, > auth_type=code, redirect_uri=https://lev.homeoffice.gov.uk/oauth/callback, > code_id=5a08f532-1051-4805-8dd6-d71362303521, username=XXXXXXXXX > 11:47:01,018 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) > ARJUNA012117: TransactionReaper::check timeout for TX > 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:46efe0 in state RUN > 11:47:01,019 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) > ARJUNA012095: Abort of action id 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:46efe0 > invoked while multiple threads active within it. > 11:47:01,022 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) > ARJUNA012381: Action id 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:46efe0 completed > with multiple threads - thread default task-165 was in progress with > sun.misc.Unsafe.park(Native Method) > java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) > > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) > org.apache.http.pool.PoolEntryFuture.await(PoolEntryFuture.java:138) > > org.apache.http.pool.AbstractConnPool.getPoolEntryBlocking(AbstractConnPool.java:306) > org.apache.http.pool.AbstractConnPool.access$000(AbstractConnPool.java:64) > > org.apache.http.pool.AbstractConnPool$2.getPoolEntry(AbstractConnPool.java:192) > > org.apache.http.pool.AbstractConnPool$2.getPoolEntry(AbstractConnPool.java:185) > org.apache.http.pool.PoolEntryFuture.get(PoolEntryFuture.java:107) > > org.apache.http.impl.conn.PoolingHttpClientConnectionManager.leaseConnection(PoolingHttpClientConnectionManager.java:276) > > org.apache.http.impl.conn.PoolingHttpClientConnectionManager$1.get(PoolingHttpClientConnectionManager.java:263) > > org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:190) > org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184) > org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88) > org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) > > org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184) > > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) > > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107) > > org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55) > > org.keycloak.broker.provider.util.SimpleHttp.makeRequest(SimpleHttp.java:185) > > org.keycloak.broker.provider.util.SimpleHttp.asResponse(SimpleHttp.java:154) > org.keycloak.broker.provider.util.SimpleHttp.asString(SimpleHttp.java:146) > > org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider$Endpoint.authResponse(AbstractOAuth2IdentityProvider.java:397) > sun.reflect.GeneratedMethodAccessor994.invoke(Unknown Source) > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > java.lang.reflect.Method.invoke(Method.java:498) > > org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140) > > org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) > > org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) > > org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) > > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107) > > org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133) > > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) > > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:406) > > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:213) > > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:228) > > 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.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) > > org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:90) > io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) > > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) > > io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) > > 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) > > org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68) > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > > io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > > io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > > io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > > io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > > io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > > org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > > org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$1243/578097420.call(Unknown > Source) > > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) > > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown > Source) > > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) > > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown > Source) > > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) > > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown > Source) > > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) > > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown > Source) > > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > io.undertow.server.Connectors.executeRootHandler(Connectors.java:326) > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812) > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > java.lang.Thread.run(Thread.java:748) > > Rohith > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Wed Jun 27 15:31:33 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 27 Jun 2018 21:31:33 +0200 Subject: [keycloak-dev] Decoupled channel authentication (Google Push Authn) In-Reply-To: References: Message-ID: I haven't tried, but you should be able to use authentication notes instead: ctx.getAuthenticationSession().get/setAuthNote On Wed, 27 Jun 2018 at 10:45, James Holland wrote: > Hi Stian, thanks for this :-) > > AuthenticationFlowContext & UserSessionProvider no longer have methods to > get the ClientSessionModel to lookup the user session, any suggestion on > how to get this in 4.0.0.Final? I was looking at > AuthenticationSessionProvider? > > I agree with you wrt to your points 1 & 2, websocket callback is something > I'm working on separately, but only as a method of telling the waiting page > to refresh instead of polling; just need a distributed Pub/sub & filter (so > only the specific sessions get called.) > > Regards James > > > Stian Thorgersen wrote on 27/06/2018 07:25: > > Hi, > > Take a look at https://github.com/stianst/authenticator-example. It's > just a POC, but it does pretty much what you're after with regards to an > out of bands authenticator. > > Now to make it nice there's two aspects that needs to be worked on: > > 1. Support for additional multi factor mechanisms - users should be able > to choose between available means, pluggable support including > configuration, etc.. I hope this is something we'll be working on soon. > 2. Push based out of bands - we need some concept of authentication events > that the authenticator web page can wait for. I would assume this would use > websockets. > > For Google prompt it would be nice to have that available OOTB, but it > does depend on #1 to allow us to properly support more than one multi > factor in a realm. > > On Mon, 25 Jun 2018 at 11:23, James Holland > wrote: > >> I've added the feature request >> https://issues.jboss.org/browse/KEYCLOAK-7675 for this. >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > From sthorger at redhat.com Wed Jun 27 15:36:43 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 27 Jun 2018 21:36:43 +0200 Subject: [keycloak-dev] Decoupled channel authentication (Google Push Authn) In-Reply-To: References: Message-ID: What I had in mind with websocket was something along the lines of web page listens for an event filtered on the authentication session id and the callback would trigger an event with the authentication session id. Would be nice if the authenticator SPI would also allow adding callback endpoints without having to create a realm resource for it. On Wed, 27 Jun 2018 at 21:31, Stian Thorgersen wrote: > I haven't tried, but you should be able to use authentication notes > instead: > > ctx.getAuthenticationSession().get/setAuthNote > > On Wed, 27 Jun 2018 at 10:45, James Holland > wrote: > >> Hi Stian, thanks for this :-) >> >> AuthenticationFlowContext & UserSessionProvider no longer have methods to >> get the ClientSessionModel to lookup the user session, any suggestion on >> how to get this in 4.0.0.Final? I was looking at >> AuthenticationSessionProvider? >> >> I agree with you wrt to your points 1 & 2, websocket callback is >> something I'm working on separately, but only as a method of telling the >> waiting page to refresh instead of polling; just need a distributed Pub/sub >> & filter (so only the specific sessions get called.) >> >> Regards James >> >> >> Stian Thorgersen wrote on 27/06/2018 07:25: >> >> Hi, >> >> Take a look at https://github.com/stianst/authenticator-example. It's >> just a POC, but it does pretty much what you're after with regards to an >> out of bands authenticator. >> >> Now to make it nice there's two aspects that needs to be worked on: >> >> 1. Support for additional multi factor mechanisms - users should be able >> to choose between available means, pluggable support including >> configuration, etc.. I hope this is something we'll be working on soon. >> 2. Push based out of bands - we need some concept of authentication >> events that the authenticator web page can wait for. I would assume this >> would use websockets. >> >> For Google prompt it would be nice to have that available OOTB, but it >> does depend on #1 to allow us to properly support more than one multi >> factor in a realm. >> >> On Mon, 25 Jun 2018 at 11:23, James Holland >> wrote: >> >>> I've added the feature request >>> https://issues.jboss.org/browse/KEYCLOAK-7675 for this. >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> From sthorger at redhat.com Thu Jun 28 04:12:08 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 28 Jun 2018 10:12:08 +0200 Subject: [keycloak-dev] JWS signatures using PS256 or ES256 algorithms for signing In-Reply-To: References: Message-ID: On Wed, 27 Jun 2018 at 09:31, Marek Posolda wrote: > +1 > > Having the configuration in adapter (keycloak.json) won't scale also > because REST services (bearer-only clients) will need to verify signatures > by "frontend" clients, but each frontend client can use different algorithm > to sign it's token. So keycloak.json of bearer-only clients would need to > have some configuration map to track all of this... Also "rotation" of > algorithms will be impossible (if administrator changes the algorithm for > client in admin console, the adapter configuration in keycloak.json will > need to be updated and hence application restarted...) > > But I think we don't need to add any new endpoint, but just re-use > existing client registration endpoints for that? OIDC Client registration > has various metadata for clients like id_token_signed_response_alg, > id_token_encrypted_response_alg, userinfo_signed_response_alg etc. See [1]. > Also we have support for Dynamic client registration management [2], so > client applications are able to "download" the client's metadata from the > endpoint. > I wasn't thinking adding a new endpoint. We should use OIDC well-known endpoint. However, that doesn't include any attributes for the access token, only ID token. Which is of course due to the fact that the access token is opaque in OIDC. We could for instance add "access_token_signed_response_alg". Clients would by default check the OIDC well-known endpoint for what algorithm to use, but it should also be possible to override in keycloak.json as that OIDC well-known would say the realm default, but we want to be able to override the algorithm for individual clients. > > The specification enforces that requests are authenticated by Client > Registration Access Token. But ATM we also support authentication by bearer > tokens, which is great. When application sees the bearer token > signed/encrypted by unknown algorithm, it can send the request to KC > registration/management endpoint of particular client to download the > client's metadata. This will work fine also for bearer-only clients. The > bearer-only client can parse the token and send the request to the > registration/management endpoint of particular "frontend" client the token > was issued for to determine the right algorithms etc. > Same as well-known. Dynamic client registration metadata from OIDC doesn't specify anything for access token sign algorithm. So we would have to add our own. > > [1] > https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata > [2] https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-05 > > Marek > > On 26/06/18 18:25, Stian Thorgersen wrote: > > I don't really like the idea of having to reconfigure to make the adapter > accept new signature. I know oidc well known endpoint doesn't have > signature algorithm for access token, but we could add one and have > adapters pull from the server what algorithms to accept. > > On Tue, 26 Jun 2018, 11:00 Marek Posolda, wrote: > >> On 30/05/18 09:35, Stian Thorgersen wrote: >> >> I think it might be better to determine which kind of Token Signature >> Provider be used by not parsing JWS, for example, looking up Client or >> Realm settings. >> This PR might have impacts on keycloak's performance because it has parsed >> JWS to determine it every time keycloak receives JWS Token. >> >> >> On the server-side that is easy. On the adapter side that would probably >> require adding a property to keycloak.json to set the algorithm. In either >> case it should probably default to RSA for existing realms at least, but we >> could consider setting it to ES256 for new realms. >> >> >> +1 >> >> Parsing token signature to determine algorithm should be avoided IMO. >> AFAIR Some OAuth/OIDC vendors had security issues in the past, that they >> parsed the header with "none" algorithm and then client applications >> automatically trust unsigned tokens. We should make sure this is not >> possible. >> >> Marek >> > > > From mposolda at redhat.com Thu Jun 28 10:13:06 2018 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 28 Jun 2018 16:13:06 +0200 Subject: [keycloak-dev] JWS signatures using PS256 or ES256 algorithms for signing In-Reply-To: References: Message-ID: <9212683c-1824-626c-f6ef-0ffdb6b5a73c@redhat.com> On 28/06/18 10:12, Stian Thorgersen wrote: > > > On Wed, 27 Jun 2018 at 09:31, Marek Posolda > wrote: > > +1 > > Having the configuration in adapter (keycloak.json) won't scale > also because REST services (bearer-only clients) will need to > verify signatures by "frontend" clients, but each frontend client > can use different algorithm to sign it's token. So keycloak.json > of bearer-only clients would need to have some configuration map > to track all of this... Also "rotation" of algorithms will be > impossible (if administrator changes the algorithm for client in > admin console, the adapter configuration in keycloak.json will > need to be updated and hence application restarted...) > > But I think we don't need to add any new endpoint, but just re-use > existing client registration endpoints for that? OIDC Client > registration has various metadata for clients like > id_token_signed_response_alg, id_token_encrypted_response_alg, > userinfo_signed_response_alg etc. See [1]. Also we have support > for Dynamic client registration management [2], so client > applications are able to "download" the client's metadata from the > endpoint. > > > I wasn't thinking adding a new endpoint. We should use OIDC well-known > endpoint. However, that doesn't include any attributes for the access > token, only ID token. Which is of course due to the fact that the > access token is opaque in OIDC. We could for instance add > "access_token_signed_response_alg". > > Clients would by default check the OIDC well-known endpoint for what > algorithm to use, but it should also be possible to override in > keycloak.json as that OIDC well-known would say the realm default, but > we want to be able to override the algorithm for individual clients. IMO OIDC well-known endpoint is not good for that. It's not the endpoint to be useful for retrieve metadata of specific client, rather it's global for a realm. Even for ID token, there is not single signature algorithm. There is just list of supported algorithms in id_token_signing_alg_values_supported . I wonder that for our adapters, we can just use the Client Registration (Management) endpoint of our own representation - the endpoint of DefaultClientRegistrationProvider.getDefault() . That's our own rep, so we are fine to return the accessToken signature algorithm. We can ensure that algorithm is always returned (We will return client specific algorithm or fallback to realm default algorithm if client doesn't have one set). We can invoke that endpoint with the bearer-token, which adapter will always have - it can just use the token it wants to verify signature for. Any reason why it won't work? I wouldn't add anything to keycloak.json. IMO it would suck because: - If algorithm is changed by admin in KC admin console, adapter will need to be re-configured in keycloak.json and restarted (no automatic algorithm "rotation" support) - Configuration of algorithm will be duplicated on both adapter and server - Bearer-only clients can be invoked with tokens of various "frontend" clients signed by various different algorithms. So the configuration in keycloak.json would be quite complicated here. Marek > > The specification enforces that requests are authenticated by > Client Registration Access Token. But ATM we also support > authentication by bearer tokens, which is great. When application > sees the bearer token signed/encrypted by unknown algorithm, it > can send the request to KC registration/management endpoint of > particular client to download the client's metadata. This will > work fine also for bearer-only clients. The bearer-only client can > parse the token and send the request to the > registration/management endpoint of particular "frontend" client > the token was issued for to determine the right algorithms etc. > > > Same as well-known. Dynamic client registration metadata from OIDC > doesn't specify anything for access token sign algorithm. So we would > have to add our own. > > > [1] > https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata > [2] https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-05 > > Marek > > On 26/06/18 18:25, Stian Thorgersen wrote: >> I don't really like the idea of having to reconfigure to make the >> adapter accept new signature. I know oidc well known? endpoint >> doesn't have signature algorithm for access token, but we could >> add one and have adapters pull from the server what algorithms to >> accept. >> >> On Tue, 26 Jun 2018, 11:00 Marek Posolda, > > wrote: >> >> On 30/05/18 09:35, Stian Thorgersen wrote: >>>> I think it might be better to determine which kind of Token Signature >>>> Provider be used by not parsing JWS, for example, looking up Client or >>>> Realm settings. >>>> This PR might have impacts on keycloak's performance because it has parsed >>>> JWS to determine it every time keycloak receives JWS Token. >>>> >>> On the server-side that is easy. On the adapter side that would probably >>> require adding a property to keycloak.json to set the algorithm. In either >>> case it should probably default to RSA for existing realms at least, but we >>> could consider setting it to ES256 for new realms. >>> >> +1 >> >> Parsing token signature to determine algorithm should be >> avoided IMO. AFAIR Some OAuth/OIDC vendors had security >> issues in the past, that they parsed the header with "none" >> algorithm and then client applications automatically trust >> unsigned tokens. We should make sure this is not possible. >> >> Marek >> > > From sthorger at redhat.com Thu Jun 28 18:31:54 2018 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 29 Jun 2018 00:31:54 +0200 Subject: [keycloak-dev] JWS signatures using PS256 or ES256 algorithms for signing In-Reply-To: <9212683c-1824-626c-f6ef-0ffdb6b5a73c@redhat.com> References: <9212683c-1824-626c-f6ef-0ffdb6b5a73c@redhat.com> Message-ID: On Thu, 28 Jun 2018, 16:13 Marek Posolda, wrote: > On 28/06/18 10:12, Stian Thorgersen wrote: > > > > On Wed, 27 Jun 2018 at 09:31, Marek Posolda wrote: > >> +1 >> >> Having the configuration in adapter (keycloak.json) won't scale also >> because REST services (bearer-only clients) will need to verify signatures >> by "frontend" clients, but each frontend client can use different algorithm >> to sign it's token. So keycloak.json of bearer-only clients would need to >> have some configuration map to track all of this... Also "rotation" of >> algorithms will be impossible (if administrator changes the algorithm for >> client in admin console, the adapter configuration in keycloak.json will >> need to be updated and hence application restarted...) >> >> But I think we don't need to add any new endpoint, but just re-use >> existing client registration endpoints for that? OIDC Client registration >> has various metadata for clients like id_token_signed_response_alg, >> id_token_encrypted_response_alg, userinfo_signed_response_alg etc. See [1]. >> Also we have support for Dynamic client registration management [2], so >> client applications are able to "download" the client's metadata from the >> endpoint. >> > > I wasn't thinking adding a new endpoint. We should use OIDC well-known > endpoint. However, that doesn't include any attributes for the access > token, only ID token. Which is of course due to the fact that the access > token is opaque in OIDC. We could for instance add > "access_token_signed_response_alg". > > Clients would by default check the OIDC well-known endpoint for what > algorithm to use, but it should also be possible to override in > keycloak.json as that OIDC well-known would say the realm default, but we > want to be able to override the algorithm for individual clients. > > IMO OIDC well-known endpoint is not good for that. It's not the endpoint > to be useful for retrieve metadata of specific client, rather it's global > for a realm. Even for ID token, there is not single signature algorithm. > There is just list of supported algorithms in > id_token_signing_alg_values_supported . > > I wonder that for our adapters, we can just use the Client Registration > (Management) endpoint of our own representation - the endpoint of > DefaultClientRegistrationProvider.getDefault() . That's our own rep, so we > are fine to return the accessToken signature algorithm. We can ensure that > algorithm is always returned (We will return client specific algorithm or > fallback to realm default algorithm if client doesn't have one set). We can > invoke that endpoint with the bearer-token, which adapter will always have > - it can just use the token it wants to verify signature for. Any reason > why it won't work? > > I wouldn't add anything to keycloak.json. IMO it would suck because: > - If algorithm is changed by admin in KC admin console, adapter will need > to be re-configured in keycloak.json and restarted (no automatic algorithm > "rotation" support) > - Configuration of algorithm will be duplicated on both adapter and server > - Bearer-only clients can be invoked with tokens of various "frontend" > clients signed by various different algorithms. So the configuration in > keycloak.json would be quite complicated here. > The way I see it is the realm should have its supported algorithms advertised in the well-known endpoint. It should also have a default set, but that doesn't need to be advertised. Clients should check that tokens are signed with an algorithm from that list. Now if a client wants tokens issued to it with a different algorithm than the realm default it should have the option to set a different algorithm for itself. I do not think there's any need to update this automatically and I think setting it in keycloak.json is fine. If we want it updated automatically we should do it by adding support for clients to do dynamic client registration as well as be able to get updates either pushed or pulled. For bearer clients they should have an option to limit the set of algorithms they support and again Keycloak.json is fine here. I believe all clients secured with Keycloak adapters would just use the the realm default anyways. Having the option to override for clients is more aimed at non-Keycloak adapters which may for instance not support es256, but only rs256, while the user would like to use es256 whenever possible. > Marek > > >> The specification enforces that requests are authenticated by Client >> Registration Access Token. But ATM we also support authentication by bearer >> tokens, which is great. When application sees the bearer token >> signed/encrypted by unknown algorithm, it can send the request to KC >> registration/management endpoint of particular client to download the >> client's metadata. This will work fine also for bearer-only clients. The >> bearer-only client can parse the token and send the request to the >> registration/management endpoint of particular "frontend" client the token >> was issued for to determine the right algorithms etc. >> > > Same as well-known. Dynamic client registration metadata from OIDC doesn't > specify anything for access token sign algorithm. So we would have to add > our own. > > >> >> [1] >> https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata >> [2] https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-05 >> >> Marek >> >> On 26/06/18 18:25, Stian Thorgersen wrote: >> >> I don't really like the idea of having to reconfigure to make the adapter >> accept new signature. I know oidc well known endpoint doesn't have >> signature algorithm for access token, but we could add one and have >> adapters pull from the server what algorithms to accept. >> >> On Tue, 26 Jun 2018, 11:00 Marek Posolda, wrote: >> >>> On 30/05/18 09:35, Stian Thorgersen wrote: >>> >>> I think it might be better to determine which kind of Token Signature >>> Provider be used by not parsing JWS, for example, looking up Client or >>> Realm settings. >>> This PR might have impacts on keycloak's performance because it has parsed >>> JWS to determine it every time keycloak receives JWS Token. >>> >>> >>> On the server-side that is easy. On the adapter side that would probably >>> require adding a property to keycloak.json to set the algorithm. In either >>> case it should probably default to RSA for existing realms at least, but we >>> could consider setting it to ES256 for new realms. >>> >>> >>> +1 >>> >>> Parsing token signature to determine algorithm should be avoided IMO. >>> AFAIR Some OAuth/OIDC vendors had security issues in the past, that they >>> parsed the header with "none" algorithm and then client applications >>> automatically trust unsigned tokens. We should make sure this is not >>> possible. >>> >>> Marek >>> >> >> >> > From mposolda at redhat.com Fri Jun 29 03:44:34 2018 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 29 Jun 2018 09:44:34 +0200 Subject: [keycloak-dev] Wildfly 13 upgrade Message-ID: The PR for Wildfly 13 upgrade is finally ready to review - https://github.com/keycloak/keycloak/pull/5293 . Few things to highlight for this PR: - Dependencies of undertow, infinispan, resteasy and aesh and some others were updated to use the versions used by Wildfly. - Some configuration changes are needed in infinispan Wildfly subsystem (Removed jndi-name from cache-container element, Replaced "eviction" element by "objects" element in the configuration of caches, ...). This is all documented and described in migration guide. Also migration scripts were updated to reflect all of this and automatically update configurations of standalone and domain configuration files. Server-config-migration-tests is passing - For Cross-DC, infinispan-server used is now infinispan-server 9.2.4.Final (same infinispan version like Wildfly 13 is using) and JDG 7.2. It was a bit of pain, but finally cross-dc tests are passing fine with both infinispan-server-9.2.4 and JDG 7.2. The PR contains some changes especially in the keycloak-model-infinispan part as updating infinispan wasn't so straightforward. Few things to note: -- Some API changes and deprecated methods in infinispan, which we need to adapt too -- For cross-dc, we don't use JDG '___script_cache' anymore for preloading sessions. It caused some issues in the past related to security. Also there seem to be a bug in JDG 7.2, which prevent it to work correctly. We know use "remoteCache.retrieveEntries", which was improved in infinispan 9 and allows great performance and preloading sessions in parallel. Was trying to test preloading with million sessions in JDG and it took just around a minute on my laptop - There is still the issue that keycloak-admin-cli and keycloak-client-registration-cli use the old aesh. I've created https://issues.jboss.org/browse/KEYCLOAK-7737 . Fortunately old aesh is not needed as Wildfly module, because the "fat" jars "keycloak-admin-cli" and "keycloak-client-registration-cli" just contains it's classes (as well as the other dependencies) contained in itself. IMO this is not a blocker to upgrade master to Wildfly 13 now and it can be addressed later. But will be good to address this (EG. if there are security and other issues in old aesh, we won't be able to rely on Wildfly support etc). WDYT? - I've sent the PR for documentation last week https://github.com/keycloak/keycloak-documentation/pull/410 . But this one is not yet ready for review. I need to update it based on feedback from Matthew. Also need to update a bit the content as well. Hopefully will be ready for review later today. Marek From Mark.McGuigan at 360globalnet.com Fri Jun 29 04:36:07 2018 From: Mark.McGuigan at 360globalnet.com (Mark McGuigan) Date: Fri, 29 Jun 2018 08:36:07 +0000 Subject: [keycloak-dev] Accessing Token Endpoint with a User access token to get Permissions In-Reply-To: References: Message-ID: Hi Pedro, Please find the Realm export attached. Any help on this would be greatly appreciated. Regards, Mark From: Pedro Igor Silva [mailto:psilva at redhat.com] Sent: 22 June 2018 18:24 To: Mark McGuigan Cc: keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] Accessing Token Endpoint with a User access token to get Permissions I'm not sure what is happening, this flow is similar to what we do in quickstarts and tests. Could you please export your realm and send me the file? On Fri, Jun 22, 2018 at 11:52 AM, Mark McGuigan > wrote: HI Pedro, Sure, my process is as follows: * Application forwards to Authorisation service to get a response type of ?code? * Authorisation service returns code and I forward it to the Token endpoint (no bearer) to get an access token * The Access Token contains the user authentication JWT at this point (contains Roles but not permissions) * Then I try to pass this access token as a ?bearer? to the token endpoint to get user permission but this is where I get the 500 Error described below Any pointers as to what I could be doing wrong would really be appreciated.. Kind regards, Mark From: Pedro Igor Silva [mailto:psilva at redhat.com] Sent: 22 June 2018 15:42 To: Mark McGuigan > Cc: keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] Accessing Token Endpoint with a User access token to get Permissions Hi, Are you sending the access token or ID token as a bearer ? Could you give more details on how you are obtaining the token ? On Wed, Jun 20, 2018 at 5:52 AM, Mark McGuigan > wrote: Hi, Apologies if this email is incorrectly posted. I'm using the newly released Keycloak 4 and I've been able to successfully get an access token for a user from an access code posted back to my application. This doesn't contain any permissions on the token (Rightly so, only roles) I'm now trying to get an RPT with permissions from the of client application that reflect what the User is allowed to do. My request looks something like: POST /auth/realms/MyRealm/protocol/openid-connect/token HTTP/1.1 Host: localhost:8080 Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5c ... Content-Type: application/x-www-form-urlencoded Cache-Control: no-cache Postman-Token: 4054feaf-a9d7-48e2-99b6-eabc86bf8da5 grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Auma-ticket&audience=MyClient&permission=Default+Resource Where the Bearer is the generated access_token. However I'me getting a response of : 500 Internal Server Error { "error": "server_error", "error_description": "Unexpected error while evaluating permissions" } And a stack trace of: Unexpected error while evaluating permissions: java.lang.RuntimeException: Error while reading attributes from security token. at org.keycloak.authorization.common.KeycloakIdentity.(KeycloakIdentity.java:139) at org.keycloak.authorization.common.KeycloakIdentity.(KeycloakIdentity.java:68) at org.keycloak.authorization.authorization.AuthorizationTokenService.lambda$static$1(AuthorizationTokenService.java:124) at org.keycloak.authorization.authorization.AuthorizationTokenService.createEvaluationContext(AuthorizationTokenService.java:311) at org.keycloak.authorization.authorization.AuthorizationTokenService.authorize(AuthorizationTokenService.java:161) at org.keycloak.protocol.oidc.endpoints.TokenEndpoint.permissionGrant(TokenEndpoint.java:1124) at org.keycloak.protocol.oidc.endpoints.TokenEndpoint.processGrantRequest(TokenEndpoint.java:190) ..... Caused by: java.lang.NullPointerException at org.keycloak.services.util.DefaultClientSessionContext.fromClientSessionScopeParameter(DefaultClientSessionContext.java:64) at org.keycloak.authorization.common.KeycloakIdentity.(KeycloakIdentity.java:123) Any Ideas what I may be doing wrong? Any help appreciated. Regards, Mark _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: realm-export.json Type: application/octet-stream Size: 69072 bytes Desc: realm-export.json Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20180629/921ae514/attachment-0001.obj From gambol99 at gmail.com Fri Jun 29 05:50:58 2018 From: gambol99 at gmail.com (gambol) Date: Fri, 29 Jun 2018 10:50:58 +0100 Subject: [keycloak-dev] Outage Issue In-Reply-To: References: Message-ID: Hi Sebastian The keycloak version is 3.4.3.Final though we've also experienced the issue on 3.1 as well. Next time, though I hope there won't be a next time :-) .. I'll grab a thread dump and running transactions Rohith On Wed, Jun 27, 2018 at 10:57 AM Sebastian Laskawiec wrote: > From your description and the logs I guess it might be a problem with some > transaction. > > Would you be able to tell us more about the Keycloak version you're > running? Also, a Thread dump would be helpful and you might investigate if > there are any long running transactions in the DB [1]. > > Thanks, > Sebastian > > [1] > https://www.psce.com/en/blog/2015/01/22/tracking-mysql-query-history-in-long-running-transactions/ > > On Thu, Jun 21, 2018 at 3:45 PM gambol wrote: > >> Hiya >> >> I was wondering if anyone has come across this before. We have Keycloak >> running in a kubernetes cluster, a mysql RDS, and standalone-ha setup >> using >> two gossip servers, each running behind a kube service and passed in via >> environment variables >> >> >> ${env.GOSSIP_ROUTER_HOST} >> >> >> Cluster appears to work fine, a new node added makes a change to topology >> and so forth. We do however out of the blue get the following error on >> occasion, every couple of weeks... Shortly after the rest of the replicas >> become affected, the health check on the /auth fails and or login attempts >> begin to timeout .. At present the only solution is to completely cycle >> the >> cluster. >> >> 13:07:52,451 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) >> ARJUNA012108: CheckedAction::check - atomic action >> 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:47876e aborting with 1 threads active! >> 13:07:52,451 WARN >> >> [org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorTrackingImpl] >> (Transaction Reaper Worker 0) HHH000451: Transaction afterCompletion >> called >> by a background thread; delaying afterCompletion processing until the >> original thread can handle it. [status=4] >> 13:07:52,451 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) >> ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction >> Reaper Worker 0,5,main] successfully canceled TX >> 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:47876e >> 13:07:55,475 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) >> ARJUNA012117: TransactionReaper::check timeout for TX >> 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:4787b9 in state RUN >> 13:07:55,476 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) >> ARJUNA012095: Abort of action id 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:4787b9 >> invoked while multiple threads active within it. >> 13:07:55,480 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) >> ARJUNA012381: Action id 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:4787b9 completed >> with multiple threads - thread default task-64 was in progress with >> sun.misc.Unsafe.park(Native Method) >> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) >> org.apache.http.pool.PoolEntryFuture.await(PoolEntryFuture.java:138) >> >> org.apache.http.pool.AbstractConnPool.getPoolEntryBlocking(AbstractConnPool.java:306) >> org.apache.http.pool.AbstractConnPool.access$000(AbstractConnPool.java:64) >> >> org.apache.http.pool.AbstractConnPool$2.getPoolEntry(AbstractConnPool.java:192) >> >> org.apache.http.pool.AbstractConnPool$2.getPoolEntry(AbstractConnPool.java:185) >> org.apache.http.pool.PoolEntryFuture.get(PoolEntryFuture.java:107) >> >> org.apache.http.impl.conn.PoolingHttpClientConnectionManager.leaseConnection(PoolingHttpClientConnectionManager.java:276) >> >> org.apache.http.impl.conn.PoolingHttpClientConnectionManager$1.get(PoolingHttpClientConnectionManager.java:263) >> >> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:190) >> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184) >> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88) >> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) >> >> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184) >> >> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) >> >> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107) >> >> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55) >> >> org.keycloak.broker.provider.util.SimpleHttp.makeRequest(SimpleHttp.java:185) >> >> org.keycloak.broker.provider.util.SimpleHttp.asResponse(SimpleHttp.java:154) >> org.keycloak.broker.provider.util.SimpleHttp.asString(SimpleHttp.java:146) >> >> org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider$Endpoint.authResponse(AbstractOAuth2IdentityProvider.java:397) >> sun.reflect.GeneratedMethodAccessor994.invoke(Unknown Source) >> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> java.lang.reflect.Method.invoke(Method.java:498) >> >> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140) >> >> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) >> >> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) >> >> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) >> >> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107) >> >> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133) >> >> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) >> >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:406) >> >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:213) >> >> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:228) >> >> 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.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) >> >> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:90) >> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) >> >> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) >> >> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) >> >> 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) >> >> org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68) >> >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> >> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) >> >> io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) >> >> io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) >> >> io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) >> >> io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) >> >> io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) >> >> org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) >> >> org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$1243/578097420.call(Unknown >> Source) >> >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) >> >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown >> Source) >> >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) >> >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown >> Source) >> >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) >> >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown >> Source) >> >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) >> >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown >> Source) >> >> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) >> >> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) >> >> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) >> io.undertow.server.Connectors.executeRootHandler(Connectors.java:326) >> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812) >> >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) >> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) >> java.lang.Thread.run(Thread.java:748) >> >> Repeating over and over ... Just before is >> >> 11:26:08,882 WARN [org.keycloak.events] (default task-166) >> type=CODE_TO_TOKEN_ERROR, realmId=XXX, clientId=XXXX, userId=null, >> ipAddress=XXXXXXXXXX , error=invalid_code, grant_type=authorization_code, >> code_id=XXXXXXXX , client_auth_method=client-secret >> 11:30:04,172 WARN [org.keycloak.services.managers.AuthenticationManager] >> (default task-100) Some clients have been not been logged out for user >> XXXXXXXXXXXXXXXXXXX in hod-ci realm: XXXXX >> 11:30:04,203 WARN [org.keycloak.events] (default task-92) >> type=IDENTITY_PROVIDER_LOGIN_ERROR, realmId=HOD-CI, clientId=null, >> userId=null, ipAddress=213.251.23.186, error=expired_code, >> identity_provider=O365, restart_after_timeout=true >> 11:38:13,851 WARN [org.keycloak.forms.login.freemarker.model.ProfileBean] >> (default task-88) There are more values for attribute 'group' of user >> 'XXXX\XXXXXX' . Will display just first value >> 11:43:37,370 WARN [org.keycloak.events] (default task-36) >> type=LOGIN_ERROR, realmId=lev, clientId=lev-web, userId=null, >> ipAddress=XXXXXXXX, error=user_not_found, auth_method=openid-connect, >> auth_type=code, redirect_uri=https://lev.homeoffice.gov.uk/oauth/callback >> , >> code_id=5a08f532-1051-4805-8dd6-d71362303521, username=XXXXXXXXX >> 11:47:01,018 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) >> ARJUNA012117: TransactionReaper::check timeout for TX >> 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:46efe0 in state RUN >> 11:47:01,019 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) >> ARJUNA012095: Abort of action id 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:46efe0 >> invoked while multiple threads active within it. >> 11:47:01,022 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) >> ARJUNA012381: Action id 0:ffff0a0a8b0a:-6d4f7aec:5b0ef057:46efe0 completed >> with multiple threads - thread default task-165 was in progress with >> sun.misc.Unsafe.park(Native Method) >> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) >> >> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) >> org.apache.http.pool.PoolEntryFuture.await(PoolEntryFuture.java:138) >> >> org.apache.http.pool.AbstractConnPool.getPoolEntryBlocking(AbstractConnPool.java:306) >> org.apache.http.pool.AbstractConnPool.access$000(AbstractConnPool.java:64) >> >> org.apache.http.pool.AbstractConnPool$2.getPoolEntry(AbstractConnPool.java:192) >> >> org.apache.http.pool.AbstractConnPool$2.getPoolEntry(AbstractConnPool.java:185) >> org.apache.http.pool.PoolEntryFuture.get(PoolEntryFuture.java:107) >> >> org.apache.http.impl.conn.PoolingHttpClientConnectionManager.leaseConnection(PoolingHttpClientConnectionManager.java:276) >> >> org.apache.http.impl.conn.PoolingHttpClientConnectionManager$1.get(PoolingHttpClientConnectionManager.java:263) >> >> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:190) >> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184) >> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88) >> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) >> >> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184) >> >> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) >> >> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107) >> >> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55) >> >> org.keycloak.broker.provider.util.SimpleHttp.makeRequest(SimpleHttp.java:185) >> >> org.keycloak.broker.provider.util.SimpleHttp.asResponse(SimpleHttp.java:154) >> org.keycloak.broker.provider.util.SimpleHttp.asString(SimpleHttp.java:146) >> >> org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider$Endpoint.authResponse(AbstractOAuth2IdentityProvider.java:397) >> sun.reflect.GeneratedMethodAccessor994.invoke(Unknown Source) >> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> java.lang.reflect.Method.invoke(Method.java:498) >> >> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140) >> >> org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) >> >> org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) >> >> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:138) >> >> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:107) >> >> org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:133) >> >> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:101) >> >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:406) >> >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:213) >> >> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:228) >> >> 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.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129) >> >> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:90) >> io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) >> >> io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131) >> >> io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84) >> >> 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) >> >> org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68) >> >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) >> >> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) >> >> io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) >> >> io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) >> >> io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) >> >> io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) >> >> io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) >> >> org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) >> >> org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$1243/578097420.call(Unknown >> Source) >> >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) >> >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown >> Source) >> >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) >> >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown >> Source) >> >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) >> >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown >> Source) >> >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) >> >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1244/197032188.call(Unknown >> Source) >> >> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) >> >> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) >> >> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) >> io.undertow.server.Connectors.executeRootHandler(Connectors.java:326) >> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812) >> >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) >> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) >> java.lang.Thread.run(Thread.java:748) >> >> Rohith >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > From aznidin at yahoo.com Fri Jun 29 05:57:38 2018 From: aznidin at yahoo.com (Aznidin Zainuddin) Date: Fri, 29 Jun 2018 17:57:38 +0800 Subject: [keycloak-dev] Keycloak with Oracle IDCS as Parent IDP Message-ID: <08C29A4C-D376-4E17-BC93-6E20C7F36546@yahoo.com> Hi, I?ve been using keycloak to secure the company?s webpage for a while. There?s a new requirement that I use Oracle IDCS IDP. Because the IDP doesn?t support user access level/authorization, I?m forced to use the IDP as Keycloak?s parent IDP. The IDCS supports OpenID Connect 1.0 and so I tried to add it as an external IDP using two of the possible methods i.e. OpenID Connect 1.0 and Keycloak OpenId Connect. Both methods failed at the point where an eccess token was requested with the following stack trace: 09:56:33,923 ERROR [org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider] (default task-15) Failed to make identity provider oauth callback: org.keycloak.broker.provider.IdentityBrokerException: No access_token from server. ??????? at org.keycloak.broker.oidc.OIDCIdentityProvider.verifyAccessToken(OIDCIdentityProvider.java:443) ??????? at org.keycloak.broker.oidc.OIDCIdentityProvider.getFederatedIdentity(OIDCIdentityProvider.java:345) ??????? at org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider$Endpoint.authResponse(AbstractOAuth2IdentityProvider.java:407) ??????? 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.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140) ??????? 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:406) ??????? at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:213) ??????? at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:228) ??????? 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:90) ??????? at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) ??????? 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 org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68) ??????? at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) ??????? at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) ??????? at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) ??????? at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) ??????? at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) ??????? at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) ??????? at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) ??????? at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) ??????? at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) ??????? at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) ??????? at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) ??????? at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) ??????? at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) ??????? at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) ??????? at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) ??????? at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326) ??????? at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812) ??????? at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ??????? at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ??????? at java.lang.Thread.run(Thread.java:748) 09:56:33,948 WARN [org.keycloak.events] (default task-15) type=LOGIN_ERROR, realmId=onesys, clientId=null, userId=null, ipAddress=10.255.0.2, error=identity_provider_login_failure ------------------------------------- I?m not really a Keycloak expert but it seems to me that the protocol breaks because Keycloak and IDCS ?talks? different dialects. Could it be that there?s some way to configure it in Keycloak to make it work? Oracle came back with the following, I quote: ????????? IDCS OIDC discovery endpoint says this: "token_endpoint_auth_methods_supported": [ ??????? "client_secret_basic", ??????? "client_secret_jwt" ??? ], ????????? It seems that when Keycloak is an OIDC RP, it might be ignoring this directive and sending the client_secret in POST body anyways. Please check with Keycloak team if there is a way to configure Keycloak to use one of the IDCS supported ways. This is something that is not our skillset and people with Keycloak knowledge will be more effective in helping you with this. ????????? If Keycloak doesn?t support one of these two ways, you will need to raise a ticket with them to provide support for at least one of these ways of client_authentication. ????????? On the other hand, IDCS doesn?t yet support ?client_secret_post?. There is already an internal bug filed against IDCS for this - BUG 27981356 - TOKEN EXCHANGE SHOULD ACCEPT CLIENT_ID AND CLIENT_SECRET IN POST PAYLOAD. However, it doesn?t seem that the scheduled delivery of this feature will meet your timelines. From psilva at redhat.com Fri Jun 29 07:08:40 2018 From: psilva at redhat.com (Pedro Igor Silva) Date: Fri, 29 Jun 2018 08:08:40 -0300 Subject: [keycloak-dev] Accessing Token Endpoint with a User access token to get Permissions In-Reply-To: References: Message-ID: Thanks, Mark. I've imported your realm and was not able to reproduce the issue. What I did was: * Import your realm settings * Add a new user * Obtain access token for MyApp on behalf of user alice * Obtain RPT using the previous access token I've also tested using an access token issued to a public client (different client than MyApp). >From the stackstrace, it seems that the there is no client session associated with the client making the request to obtain the permissions. But in theory, you should not get that error but a 401 response from the server. If you could share how you reproduce the issue using your realm settings, I appreciate. Regards. Pedro Igor On Fri, Jun 29, 2018 at 5:36 AM, Mark McGuigan < Mark.McGuigan at 360globalnet.com> wrote: > Hi Pedro, > > > > Please find the Realm export attached. Any help on this would be greatly > appreciated. > > > > Regards, > > > > Mark > > > > *From:* Pedro Igor Silva [mailto:psilva at redhat.com] > *Sent:* 22 June 2018 18:24 > *To:* Mark McGuigan > *Cc:* keycloak-dev at lists.jboss.org > *Subject:* Re: [keycloak-dev] Accessing Token Endpoint with a User access > token to get Permissions > > > > I'm not sure what is happening, this flow is similar to what we do in > quickstarts and tests. Could you please export your realm and send me the > file? > > > > > > > > On Fri, Jun 22, 2018 at 11:52 AM, Mark McGuigan < > Mark.McGuigan at 360globalnet.com> wrote: > > HI Pedro, > > > > Sure, my process is as follows: > > - Application forwards to Authorisation service to get a response type > of ?code? > - Authorisation service returns code and I forward it to the Token > endpoint (no bearer) to get an access token > - The Access Token contains the user authentication JWT at this point > (contains Roles but not permissions) > - Then I try to pass this access token as a ?bearer? to the token > endpoint to get user permission but this is where I get the 500 Error > described below > > > > Any pointers as to what I could be doing wrong would really be > appreciated.. > > Kind regards, > > > > Mark > > > > > > *From:* Pedro Igor Silva [mailto:psilva at redhat.com] > *Sent:* 22 June 2018 15:42 > *To:* Mark McGuigan > *Cc:* keycloak-dev at lists.jboss.org > *Subject:* Re: [keycloak-dev] Accessing Token Endpoint with a User access > token to get Permissions > > > > Hi, > > > > Are you sending the access token or ID token as a bearer ? Could you give > more details on how you are obtaining the token ? > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jun 20, 2018 at 5:52 AM, Mark McGuigan < > Mark.McGuigan at 360globalnet.com> wrote: > > Hi, > > Apologies if this email is incorrectly posted. > > I'm using the newly released Keycloak 4 and I've been able to successfully > get an access token for a user from an access code posted back to my > application. This doesn't contain any permissions on the token (Rightly so, > only roles) > I'm now trying to get an RPT with permissions from the of client > application that reflect what the User is allowed to do. > > My request looks something like: > POST /auth/realms/MyRealm/protocol/openid-connect/token HTTP/1.1 > Host: localhost:8080 > Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5c ... > Content-Type: application/x-www-form-urlencoded > Cache-Control: no-cache > Postman-Token: 4054feaf-a9d7-48e2-99b6-eabc86bf8da5 > > grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Auma-ticket&audience= > MyClient&permission=Default+Resource > > Where the Bearer is the generated access_token. However I'me getting a > response of : > > 500 Internal Server Error > { > "error": "server_error", > "error_description": "Unexpected error while evaluating permissions" > } > > And a stack trace of: > > Unexpected error while evaluating permissions: java.lang.RuntimeException: > Error while reading attributes from security token. > at org.keycloak.authorization.common.KeycloakIdentity. > (KeycloakIdentity.java:139) > at org.keycloak.authorization.common.KeycloakIdentity. > (KeycloakIdentity.java:68) > at org.keycloak.authorization.authorization. > AuthorizationTokenService.lambda$static$1(AuthorizationTokenService. > java:124) > at org.keycloak.authorization.authorization. > AuthorizationTokenService.createEvaluationContext( > AuthorizationTokenService.java:311) > at org.keycloak.authorization.authorization. > AuthorizationTokenService.authorize(AuthorizationTokenService.java:161) > at org.keycloak.protocol.oidc.endpoints.TokenEndpoint. > permissionGrant(TokenEndpoint.java:1124) > at org.keycloak.protocol.oidc.endpoints.TokenEndpoint. > processGrantRequest(TokenEndpoint.java:190) > ..... > Caused by: java.lang.NullPointerException > at org.keycloak.services.util.DefaultClientSessionContext. > fromClientSessionScopeParameter(DefaultClientSessionContext.java:64) > at org.keycloak.authorization.common.KeycloakIdentity. > (KeycloakIdentity.java:123) > > Any Ideas what I may be doing wrong? Any help appreciated. > > Regards, > > Mark > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > From Matt.Domsch at quest.com Sat Jun 30 14:18:50 2018 From: Matt.Domsch at quest.com (Matt Domsch (mdomsch)) Date: Sat, 30 Jun 2018 18:18:50 +0000 Subject: [keycloak-dev] Keycloak with Oracle IDCS as Parent IDP In-Reply-To: <08C29A4C-D376-4E17-BC93-6E20C7F36546@yahoo.com> References: <08C29A4C-D376-4E17-BC93-6E20C7F36546@yahoo.com> Message-ID: I have seen similar from Azure AD when the scope did not include something that AAD expected. In your case be sure scope matches the audience. See https://docs.oracle.com/en/cloud/get-started/subscriptions-cloud/csimg/obtaining-access-token-using-user-credentials-client-assertion.html Thanks, Matt ________________________________________ From: keycloak-dev-bounces at lists.jboss.org [keycloak-dev-bounces at lists.jboss.org] on behalf of Aznidin Zainuddin [aznidin at yahoo.com] Sent: Friday, June 29, 2018 4:57 AM To: keycloak-dev at lists.jboss.org Subject: [keycloak-dev] Keycloak with Oracle IDCS as Parent IDP Hi, I?ve been using keycloak to secure the company?s webpage for a while. There?s a new requirement that I use Oracle IDCS IDP. Because the IDP doesn?t support user access level/authorization, I?m forced to use the IDP as Keycloak?s parent IDP. The IDCS supports OpenID Connect 1.0 and so I tried to add it as an external IDP using two of the possible methods i.e. OpenID Connect 1.0 and Keycloak OpenId Connect. Both methods failed at the point where an eccess token was requested with the following stack trace: 09:56:33,923 ERROR [org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider] (default task-15) Failed to make identity provider oauth callback: org.keycloak.broker.provider.IdentityBrokerException: No access_token from server. at org.keycloak.broker.oidc.OIDCIdentityProvider.verifyAccessToken(OIDCIdentityProvider.java:443) at org.keycloak.broker.oidc.OIDCIdentityProvider.getFederatedIdentity(OIDCIdentityProvider.java:345) at org.keycloak.broker.oidc.AbstractOAuth2IdentityProvider$Endpoint.authResponse(AbstractOAuth2IdentityProvider.java:407) 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.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140) 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:406) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:213) at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:228) 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:90) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61) 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 org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326) at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) 09:56:33,948 WARN [org.keycloak.events] (default task-15) type=LOGIN_ERROR, realmId=onesys, clientId=null, userId=null, ipAddress=10.255.0.2, error=identity_provider_login_failure ------------------------------------- I?m not really a Keycloak expert but it seems to me that the protocol breaks because Keycloak and IDCS ?talks? different dialects. Could it be that there?s some way to configure it in Keycloak to make it work? Oracle came back with the following, I quote: ? IDCS OIDC discovery endpoint says this: "token_endpoint_auth_methods_supported": [ "client_secret_basic", "client_secret_jwt" ], ? It seems that when Keycloak is an OIDC RP, it might be ignoring this directive and sending the client_secret in POST body anyways. Please check with Keycloak team if there is a way to configure Keycloak to use one of the IDCS supported ways. This is something that is not our skillset and people with Keycloak knowledge will be more effective in helping you with this. ? If Keycloak doesn?t support one of these two ways, you will need to raise a ticket with them to provide support for at least one of these ways of client_authentication. ? On the other hand, IDCS doesn?t yet support ?client_secret_post?. There is already an internal bug filed against IDCS for this - BUG 27981356 - TOKEN EXCHANGE SHOULD ACCEPT CLIENT_ID AND CLIENT_SECRET IN POST PAYLOAD. However, it doesn?t seem that the scheduled delivery of this feature will meet your timelines. _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev