From takashi.norimatsu.ws at hitachi.com Wed Jun 5 03:18:46 2019 From: takashi.norimatsu.ws at hitachi.com (=?iso-2022-jp?B?GyRCPmg+Pk40O1YbKEIgLyBOT1JJTUFUU1UbJEIhJBsoQlRBS0FTSEk=?=) Date: Wed, 5 Jun 2019 07:18:46 +0000 Subject: [keycloak-dev] Encrypted OIDC ID Tokens support and admin console In-Reply-To: <16330b65-4097-65f6-8ebe-f663db5175c0@redhat.com> References: <16330b65-4097-65f6-8ebe-f663db5175c0@redhat.com> Message-ID: Hello, I think it is a good idea to have "OIDC keys" feature. When I wrote the PR for Support signature algorithm PS256/384/512 for tokens and request object (https://github.com/keycloak/keycloak/pull/5974), I encountered this matter. "OIDC keys" feature might be beneficial for the clients using JWS Client Assertion (Signed JWT) as their authentication with signature algorithm other than RS256 (e.g. ES256). I think this "OIDC keys" feature be realized as the separate PR because the PR for ID Token Encryption is independent of how to load the client public key. Takashi Norimatsu Hitachi, Ltd. -----Original Message----- From: keycloak-dev-bounces at lists.jboss.org On Behalf Of Marek Posolda Sent: Friday, May 31, 2019 4:31 PM To: keycloak-dev at lists.jboss.org Subject: [!][keycloak-dev] Encrypted OIDC ID Tokens support and admin console We have PR for introducing encryption support for OIDC ID Tokens. See [1] and [2]. IMO The PR is great contribution and is quite complete. There is support for manage encryption keys through the REST API or through the OIDC client registration, which is probably sufficient for have the OIDC FAPI support happy. However one thing, which seems to be missing, is better admin console support for seeing and managing the encryption keys of the client. Regarding the admin console, the PR just introduces 2 new options for the client for choosing the algorithms for encryption of ID Tokens. For more details, admin console doesn't have support for "hardcode" the client encryption key/certificate. It has support for downloading the key from the client's JWKS URL, but the JWKS URL is configured on the bit strange place. Right now, it is configured under tab "Credentials", then you need to choose "Signed-JWT" and then you can configure the JWKS URL. This was OK, when only point of JWKS URL was used just for signed-jwt client authentication. But now with adding the encrypted ID tokens support, this is not very appropriate place IMO. For example if you want to use encrypted ID Tokens together with traditional client authentication based on clientId/clientSecret, you shouldn't be required to go to "Credentials -> Signed JWT Authenticator" at all. So not sure, if we shoud do some small re-design of admin console now? For example, for SAML clients, there is tab "SAML Keys" where you can see/generate/import/export keys used for SAML. I can imagine something like that for OIDC clients too. We can introduce tab "OIDC Keys" or just "Keys" . That will allow to have switch "Use JWKS URL" and then configure JWKS URL (optional) or alternatively the client keys used for SIG and ENC, which will be required just if "Use JWKS URL" is OFF similarly like it is currently in the "Credentials -> Signed JWT". Then in the tab "Credentials -> Signed JWT", there will be just info that you need to configure JWKS URL or Signing key in the tab "Keys" - so no configuration options on this page. Similarly the tooltips for the new options for ID Token support will contain the tooltip, that you should configure JWKS URL or "hardcode" encryption key in the tab "Keys" . The bonus point will be the possibility to view the keys downloaded from JWKS URL and the ability to invalidate the keys of the individual client from the cache (currently it's possible to invalidate just globally for the whole realm AFAIK). TBH I am not sure whether to add admin console support in this PR or have the follow-up PR. WDYT? [1] https://clicktime.symantec.com/3VyqBz5ZQQnkb2zESQe6atT7Vc?u=https%3A%2F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-6768 [2] https://clicktime.symantec.com/3CaqkVXcTCi2NSLnz1xnr5c7Vc?u=https%3A%2F%2Fgithub.com%2Fkeycloak%2Fkeycloak%2Fpull%2F5779 Marek _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://clicktime.symantec.com/35pN5a3WP5d8Jzezose3c5m7Vc?u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev From h2-wada at nri.co.jp Wed Jun 5 06:26:17 2019 From: h2-wada at nri.co.jp (h2-wada) Date: Wed, 5 Jun 2019 10:26:17 +0000 Subject: [keycloak-dev] Override "native" Keycloak providers In-Reply-To: <67B38388-64A5-4800-A89E-55D3C9547724@virginpulse.com> References: <1DDE98A1-431C-49BF-B20B-AB00C61CF763@contoso.com> , <67B38388-64A5-4800-A89E-55D3C9547724@virginpulse.com> Message-ID: Hi, I also wanted to override the default SAMLProtocolFactory with my class with the same provider id as Thomas mentioned. In my case, it has been successful in replacing the native provider with the same provider id by using the Keycloak Deployer [1]. I confirmed it works with keycloak version 4.3.0.Final, 4.8.3.Final and 6.0.1. The deployment approach is as follows. I think it's a straightforward way than deployment as a module. +Bonus: Hot deployment works !! - Create "jboss-deployment-structure.xml" and place under the "META-INF" directory in your JAR or EAR which contains your classes. - Deploy JAR or EAR by placing it in the "$KEYCLOAK_HOME/standalone/deployments/" directory. [1] https://www.keycloak.org/docs/latest/server_development/index.html#using-the-keycloak-deployer -- Hiroyuki Wada Nomura Research Institute, Ltd. h2-wada at nri.co.jp -------------------------------------------------------------------- ?????????????????????????????????? ???????????????????????????????? ???????????????????????????? PLEASE READ:This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail. -------------------------------------------------------------------- ________________________________________ ???: keycloak-dev-bounces at lists.jboss.org ? Jerry Saravia ?????? ????: 2019?4?15? 22:12 ??: Thomas Darimont CC: keycloak-dev at lists.jboss.org ??: Re: [keycloak-dev] Override "native" Keycloak providers Thanks Thomas, This worked!!! Jerry Saravia Software Engineer T(516) 603-6914 M516-603-6914 virginpulse.com |virginpulse.com/global-challenge 492 Old Connecticut Path, Framingham, MA 01701, USA Australia | Bosnia and Herzegovina | Brazil | Canada | Singapore | Switzerland | United Kingdom | USA Confidentiality Notice: The information contained in this e-mail, including any attachment(s), is intended solely for use by the designated recipient(s). Unauthorized use, dissemination, distribution, or reproduction of this message by anyone other than the intended recipient(s), or a person designated as responsible for delivering such messages to the intended recipient, is strictly prohibited and may be unlawful. This e-mail may contain proprietary, confidential or privileged information. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Virgin Pulse, Inc. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message. v2.52 From: Thomas Darimont Date: Wednesday, March 27, 2019 at 18:23 To: Jerry Saravia Cc: "keycloak-dev at lists.jboss.org" Subject: Re: [keycloak-dev] Override "native" Keycloak providers This email originates outside Virgin Pulse. Hello Jerry, I encountered a similar problem with Keycloak 4.x when I needed to implement my own SamlProtocolFactory to customize the SAML Message handling. See: http://lists.jboss.org/pipermail/keycloak-dev/2019-February/011745.html The only way I could get this to work was to add my custom extension jar to the module.xml of the keycloak-services module, see the link for details. It's by far not the best solution, but at least it works. Cheers, Thomas On Wed, 27 Mar 2019 at 22:28, Jerry Saravia > wrote: Hello, We?ve been using version 3.4.3 for a while now and are attempting to upgrade to 4.8 and we?ve run into some issues. Summary: We have created our own providers with the same PROVIDER_ID as some of the built in providers. For example, PasswordCredentialProvider has a provider id of ?keycloak-password? and we created our own with the same id that gets loaded after the native one. This worked because in 3.4.3 providers that were using the same id would still have their factories added to the factory map. See this link here for 3.4.3 changes: https://github.com/keycloak/keycloak/blob/3.4.3.Final/services/src/main/java/org/keycloak/provider/ProviderManager.java#L96-L100 These are the 4.8 changes https://github.com/keycloak/keycloak/blob/4.8.3.Final/services/src/main/java/org/keycloak/provider/ProviderManager.java#L96-L99 In 4.8, the fully qualified class name (FQCN) is not longer used. Instead it uses the provider id and the spi name. I can no longer use the same PROVIDER_ID as the native providers to ?override? them, but sometimes there is code that gets the provider specifically by id. For example, in the UpdatePassword required action we have this: PasswordCredentialProvider passwordProvider = (PasswordCredentialProvider)context.getSession().getProvider(CredentialProvider.class, PasswordCredentialProviderFactory.PROVIDER_ID); In 3.4.3 because our provider was loaded we were able to inject into code that normally isn?t overridable. We did the same for the OIDCLoginProtocolFactory to alter some token endpoint behavior even the UpdatePassword required action itself rather than making a brand new required action that is a ?second rate? because it isn?t native to Keycloak. Is there a solution for this in 4.8.3? I see this change was made in 4.0.0.Beta1 according to some of the history. J Jerry Saravia Software Engineer T(516) 603-6914 M516-603-6914 virginpulse.com |virginpulse.com/global-challenge 492 Old Connecticut Path, Framingham, MA 01701, USA Australia | Bosnia and Herzegovina | Brazil | Canada | Singapore | Switzerland | United Kingdom | USA Confidentiality Notice: The information contained in this e-mail, including any attachment(s), is intended solely for use by the designated recipient(s). Unauthorized use, dissemination, distribution, or reproduction of this message by anyone other than the intended recipient(s), or a person designated as responsible for delivering such messages to the intended recipient, is strictly prohibited and may be unlawful. This e-mail may contain proprietary, confidential or privileged information. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Virgin Pulse, Inc. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message. v2.48 _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From thomas.darimont at googlemail.com Wed Jun 5 07:23:19 2019 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Wed, 5 Jun 2019 12:23:19 +0100 Subject: [keycloak-dev] Override "native" Keycloak providers In-Reply-To: References: <1DDE98A1-431C-49BF-B20B-AB00C61CF763@contoso.com> <67B38388-64A5-4800-A89E-55D3C9547724@virginpulse.com> Message-ID: Hi Hiroyuki, I had some classloading issues with embedded libraries when I tried this approach. That's why I used the module variant. Do you use additional libraries in your custom SAMLProtocolFactory extension? Would you mind sharing your deployment-structure.xml for reference? Cheers and many thanks for your numerous valuable discussions and contributions! Thomas h2-wada schrieb am Mi., 5. Juni 2019, 11:08: > Hi, > > I also wanted to override the default SAMLProtocolFactory with my class > with the same provider id as Thomas mentioned. > In my case, it has been successful in replacing the native provider with > the same provider id by using the Keycloak Deployer [1]. I confirmed it > works with keycloak version 4.3.0.Final, 4.8.3.Final and 6.0.1. > > The deployment approach is as follows. I think it's a straightforward way > than deployment as a module. +Bonus: Hot deployment works !! > > - Create "jboss-deployment-structure.xml" and place under the "META-INF" > directory in your JAR or EAR which contains your classes. > - Deploy JAR or EAR by placing it in the > "$KEYCLOAK_HOME/standalone/deployments/" directory. > > > [1] > https://www.keycloak.org/docs/latest/server_development/index.html#using-the-keycloak-deployer > > > -- > Hiroyuki Wada > Nomura Research Institute, Ltd. > h2-wada at nri.co.jp > > -------------------------------------------------------------------- > ?????????????????????????????????? > ???????????????????????????????? > ???????????????????????????? > PLEASE READ:This e-mail is confidential and intended for > the named recipient only. If you are not an intended recipient, > please notify the sender and delete this e-mail. > -------------------------------------------------------------------- > > > ________________________________________ > ???: keycloak-dev-bounces at lists.jboss.org < > keycloak-dev-bounces at lists.jboss.org> ? Jerry Saravia < > jerry.saravia at virginpulse.com> ?????? > ????: 2019?4?15? 22:12 > ??: Thomas Darimont > CC: keycloak-dev at lists.jboss.org > ??: Re: [keycloak-dev] Override "native" Keycloak providers > > Thanks Thomas, > > This worked!!! > > > Jerry Saravia > Software Engineer > T(516) 603-6914 > M516-603-6914 > virginpulse.com > |virginpulse.com/global-challenge > 492 Old Connecticut Path, Framingham, MA 01701, USA > Australia | Bosnia and Herzegovina | Brazil | Canada | Singapore | > Switzerland | United Kingdom | USA > Confidentiality Notice: The information contained in this e-mail, > including any attachment(s), is intended solely for use by the designated > recipient(s). Unauthorized use, dissemination, distribution, or > reproduction of this message by anyone other than the intended > recipient(s), or a person designated as responsible for delivering such > messages to the intended recipient, is strictly prohibited and may be > unlawful. This e-mail may contain proprietary, confidential or privileged > information. Any views or opinions expressed are solely those of the author > and do not necessarily represent those of Virgin Pulse, Inc. If you have > received this message in error, or are not the named recipient(s), please > immediately notify the sender and delete this e-mail message. > v2.52 > From: Thomas Darimont > Date: Wednesday, March 27, 2019 at 18:23 > To: Jerry Saravia > Cc: "keycloak-dev at lists.jboss.org" > Subject: Re: [keycloak-dev] Override "native" Keycloak providers > > This email originates outside Virgin Pulse. > > Hello Jerry, > > I encountered a similar problem with Keycloak 4.x when I needed to > implement my own SamlProtocolFactory to customize the SAML Message handling. > See: > http://lists.jboss.org/pipermail/keycloak-dev/2019-February/011745.html< > https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.jboss.org%2Fpipermail%2Fkeycloak-dev%2F2019-February%2F011745.html&data=02%7C01%7Cjerry.saravia%40virginpulse.com%7C40d6fd71af6b4998c21a08d6b302ceed%7Cb123a16e892b4cf6a55a6f8c7606a035%7C0%7C0%7C636893221988678776&sdata=JRszK70Y260c5Lvbra19Qp4E%2B9FswzPwPMJRQb8t5G4%3D&reserved=0 > > > The only way I could get this to work was to add my custom extension jar > to the module.xml of the keycloak-services module, > see the link for details. > > It's by far not the best solution, but at least it works. > > Cheers, > Thomas > > On Wed, 27 Mar 2019 at 22:28, Jerry Saravia > wrote: > Hello, > > > > We?ve been using version 3.4.3 for a while now and are attempting to > upgrade to 4.8 and we?ve run into some issues. > > > > Summary: We have created our own providers with the same PROVIDER_ID as > some of the built in providers. For example, PasswordCredentialProvider has > a provider id of ?keycloak-password? and we created our own with the same > id that gets loaded after the native one. This worked because in 3.4.3 > providers that were using the same id would still have their factories > added to the factory map. > > > > See this link here for 3.4.3 changes: > > > https://github.com/keycloak/keycloak/blob/3.4.3.Final/services/src/main/java/org/keycloak/provider/ProviderManager.java#L96-L100 > < > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkeycloak%2Fkeycloak%2Fblob%2F3.4.3.Final%2Fservices%2Fsrc%2Fmain%2Fjava%2Forg%2Fkeycloak%2Fprovider%2FProviderManager.java%23L96-L100&data=02%7C01%7Cjerry.saravia%40virginpulse.com%7C40d6fd71af6b4998c21a08d6b302ceed%7Cb123a16e892b4cf6a55a6f8c7606a035%7C0%7C0%7C636893221988678776&sdata=0pjRiO7IuJLBc7XxS%2F2UOwZKDDL4RGbu3yHPJO%2FFG5U%3D&reserved=0 > > > > > > These are the 4.8 changes > > > https://github.com/keycloak/keycloak/blob/4.8.3.Final/services/src/main/java/org/keycloak/provider/ProviderManager.java#L96-L99 > < > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkeycloak%2Fkeycloak%2Fblob%2F4.8.3.Final%2Fservices%2Fsrc%2Fmain%2Fjava%2Forg%2Fkeycloak%2Fprovider%2FProviderManager.java%23L96-L99&data=02%7C01%7Cjerry.saravia%40virginpulse.com%7C40d6fd71af6b4998c21a08d6b302ceed%7Cb123a16e892b4cf6a55a6f8c7606a035%7C0%7C0%7C636893221988688789&sdata=I5hMBZLoQsSFqEakuWb6uSTtuAGOAUSfeQ%2B4CIOwPZY%3D&reserved=0 > > > > > > In 4.8, the fully qualified class name (FQCN) is not longer used. Instead > it uses the provider id and the spi name. I can no longer use the same > PROVIDER_ID as the native providers to ?override? them, but sometimes there > is code that gets the provider specifically by id. For example, in the > UpdatePassword required action we have this: > > > > PasswordCredentialProvider passwordProvider = > (PasswordCredentialProvider)context.getSession().getProvider(CredentialProvider.class, > PasswordCredentialProviderFactory.PROVIDER_ID); > > > > In 3.4.3 because our provider was loaded we were able to inject into code > that normally isn?t overridable. We did the same for the > OIDCLoginProtocolFactory to alter some token endpoint behavior even the > UpdatePassword required action itself rather than making a brand new > required action that is a ?second rate? because it isn?t native to Keycloak. > > > > Is there a solution for this in 4.8.3? I see this change was made in > 4.0.0.Beta1 according to some of the history. > > > > J > > > Jerry Saravia > Software Engineer > T(516) 603-6914 > M516-603-6914 > virginpulse.com< > https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvirginpulse.com&data=02%7C01%7Cjerry.saravia%40virginpulse.com%7C40d6fd71af6b4998c21a08d6b302ceed%7Cb123a16e892b4cf6a55a6f8c7606a035%7C0%7C0%7C636893221988688789&sdata=wFxdGkMhleh%2F9flNW3Kf%2FLs38Sead7L07IvapwyQPY4%3D&reserved=0 > > > |virginpulse.com/global-challenge< > https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvirginpulse.com%2Fglobal-challenge&data=02%7C01%7Cjerry.saravia%40virginpulse.com%7C40d6fd71af6b4998c21a08d6b302ceed%7Cb123a16e892b4cf6a55a6f8c7606a035%7C0%7C0%7C636893221988698793&sdata=2LvPxrCOKkzZnCzkNOLGCHj4Jpq74Z70Iy4CNDJCbRw%3D&reserved=0 > > > 492 Old Connecticut Path, Framingham, MA 01701, USA > Australia | Bosnia and Herzegovina | Brazil | Canada | Singapore | > Switzerland | United Kingdom | USA > Confidentiality Notice: The information contained in this e-mail, > including any attachment(s), is intended solely for use by the designated > recipient(s). Unauthorized use, dissemination, distribution, or > reproduction of this message by anyone other than the intended > recipient(s), or a person designated as responsible for delivering such > messages to the intended recipient, is strictly prohibited and may be > unlawful. This e-mail may contain proprietary, confidential or privileged > information. Any views or opinions expressed are solely those of the author > and do not necessarily represent those of Virgin Pulse, Inc. If you have > received this message in error, or are not the named recipient(s), please > immediately notify the sender and delete this e-mail message. > v2.48 > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev< > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev&data=02%7C01%7Cjerry.saravia%40virginpulse.com%7C40d6fd71af6b4998c21a08d6b302ceed%7Cb123a16e892b4cf6a55a6f8c7606a035%7C0%7C0%7C636893221988708801&sdata=6IayjP%2Bvxtn2C7pH9%2FQQK8rE4zrXRX4%2BWEmXu9ReeMI%3D&reserved=0 > > > From sthorger at redhat.com Wed Jun 5 08:29:59 2019 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 5 Jun 2019 14:29:59 +0200 Subject: [keycloak-dev] Override "native" Keycloak providers In-Reply-To: References: <1DDE98A1-431C-49BF-B20B-AB00C61CF763@contoso.com> <67B38388-64A5-4800-A89E-55D3C9547724@virginpulse.com> Message-ID: This kinda works by accident and it's not fully reliable as something could change. I'd like to make sure only one provider is registered with a specific id, but allow disabling built-in providers. If that sounds like a plan please create an issue. On Wed, 5 Jun 2019, 13:29 Thomas Darimont, wrote: > Hi Hiroyuki, > > I had some classloading issues with embedded libraries when I tried this > approach. That's why I used the module variant. Do you use additional > libraries in your custom SAMLProtocolFactory extension? Would you mind > sharing your deployment-structure.xml for reference? > > Cheers and many thanks for your numerous valuable discussions and > contributions! > Thomas > > h2-wada schrieb am Mi., 5. Juni 2019, 11:08: > > > Hi, > > > > I also wanted to override the default SAMLProtocolFactory with my class > > with the same provider id as Thomas mentioned. > > In my case, it has been successful in replacing the native provider with > > the same provider id by using the Keycloak Deployer [1]. I confirmed it > > works with keycloak version 4.3.0.Final, 4.8.3.Final and 6.0.1. > > > > The deployment approach is as follows. I think it's a straightforward way > > than deployment as a module. +Bonus: Hot deployment works !! > > > > - Create "jboss-deployment-structure.xml" and place under the "META-INF" > > directory in your JAR or EAR which contains your classes. > > - Deploy JAR or EAR by placing it in the > > "$KEYCLOAK_HOME/standalone/deployments/" directory. > > > > > > [1] > > > https://www.keycloak.org/docs/latest/server_development/index.html#using-the-keycloak-deployer > > > > > > -- > > Hiroyuki Wada > > Nomura Research Institute, Ltd. > > h2-wada at nri.co.jp > > > > -------------------------------------------------------------------- > > ?????????????????????????????????? > > ???????????????????????????????? > > ???????????????????????????? > > PLEASE READ:This e-mail is confidential and intended for > > the named recipient only. If you are not an intended recipient, > > please notify the sender and delete this e-mail. > > -------------------------------------------------------------------- > > > > > > ________________________________________ > > ???: keycloak-dev-bounces at lists.jboss.org < > > keycloak-dev-bounces at lists.jboss.org> ? Jerry Saravia < > > jerry.saravia at virginpulse.com> ?????? > > ????: 2019?4?15? 22:12 > > ??: Thomas Darimont > > CC: keycloak-dev at lists.jboss.org > > ??: Re: [keycloak-dev] Override "native" Keycloak providers > > > > Thanks Thomas, > > > > This worked!!! > > > > > > Jerry Saravia > > Software Engineer > > T(516) 603-6914 > > M516-603-6914 > > virginpulse.com > > |virginpulse.com/global-challenge > > 492 Old Connecticut Path, Framingham, MA 01701, USA > > Australia | Bosnia and Herzegovina | Brazil | Canada | Singapore | > > Switzerland | United Kingdom | USA > > Confidentiality Notice: The information contained in this e-mail, > > including any attachment(s), is intended solely for use by the designated > > recipient(s). Unauthorized use, dissemination, distribution, or > > reproduction of this message by anyone other than the intended > > recipient(s), or a person designated as responsible for delivering such > > messages to the intended recipient, is strictly prohibited and may be > > unlawful. This e-mail may contain proprietary, confidential or privileged > > information. Any views or opinions expressed are solely those of the > author > > and do not necessarily represent those of Virgin Pulse, Inc. If you have > > received this message in error, or are not the named recipient(s), please > > immediately notify the sender and delete this e-mail message. > > v2.52 > > From: Thomas Darimont > > Date: Wednesday, March 27, 2019 at 18:23 > > To: Jerry Saravia > > Cc: "keycloak-dev at lists.jboss.org" > > Subject: Re: [keycloak-dev] Override "native" Keycloak providers > > > > This email originates outside Virgin Pulse. > > > > Hello Jerry, > > > > I encountered a similar problem with Keycloak 4.x when I needed to > > implement my own SamlProtocolFactory to customize the SAML Message > handling. > > See: > > http://lists.jboss.org/pipermail/keycloak-dev/2019-February/011745.html< > > > https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.jboss.org%2Fpipermail%2Fkeycloak-dev%2F2019-February%2F011745.html&data=02%7C01%7Cjerry.saravia%40virginpulse.com%7C40d6fd71af6b4998c21a08d6b302ceed%7Cb123a16e892b4cf6a55a6f8c7606a035%7C0%7C0%7C636893221988678776&sdata=JRszK70Y260c5Lvbra19Qp4E%2B9FswzPwPMJRQb8t5G4%3D&reserved=0 > > > > > The only way I could get this to work was to add my custom extension jar > > to the module.xml of the keycloak-services module, > > see the link for details. > > > > It's by far not the best solution, but at least it works. > > > > Cheers, > > Thomas > > > > On Wed, 27 Mar 2019 at 22:28, Jerry Saravia < > jerry.saravia at virginpulse.com > > > wrote: > > Hello, > > > > > > > > We?ve been using version 3.4.3 for a while now and are attempting to > > upgrade to 4.8 and we?ve run into some issues. > > > > > > > > Summary: We have created our own providers with the same PROVIDER_ID as > > some of the built in providers. For example, PasswordCredentialProvider > has > > a provider id of ?keycloak-password? and we created our own with the same > > id that gets loaded after the native one. This worked because in 3.4.3 > > providers that were using the same id would still have their factories > > added to the factory map. > > > > > > > > See this link here for 3.4.3 changes: > > > > > > > https://github.com/keycloak/keycloak/blob/3.4.3.Final/services/src/main/java/org/keycloak/provider/ProviderManager.java#L96-L100 > > < > > > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkeycloak%2Fkeycloak%2Fblob%2F3.4.3.Final%2Fservices%2Fsrc%2Fmain%2Fjava%2Forg%2Fkeycloak%2Fprovider%2FProviderManager.java%23L96-L100&data=02%7C01%7Cjerry.saravia%40virginpulse.com%7C40d6fd71af6b4998c21a08d6b302ceed%7Cb123a16e892b4cf6a55a6f8c7606a035%7C0%7C0%7C636893221988678776&sdata=0pjRiO7IuJLBc7XxS%2F2UOwZKDDL4RGbu3yHPJO%2FFG5U%3D&reserved=0 > > > > > > > > > > > These are the 4.8 changes > > > > > > > https://github.com/keycloak/keycloak/blob/4.8.3.Final/services/src/main/java/org/keycloak/provider/ProviderManager.java#L96-L99 > > < > > > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkeycloak%2Fkeycloak%2Fblob%2F4.8.3.Final%2Fservices%2Fsrc%2Fmain%2Fjava%2Forg%2Fkeycloak%2Fprovider%2FProviderManager.java%23L96-L99&data=02%7C01%7Cjerry.saravia%40virginpulse.com%7C40d6fd71af6b4998c21a08d6b302ceed%7Cb123a16e892b4cf6a55a6f8c7606a035%7C0%7C0%7C636893221988688789&sdata=I5hMBZLoQsSFqEakuWb6uSTtuAGOAUSfeQ%2B4CIOwPZY%3D&reserved=0 > > > > > > > > > > > In 4.8, the fully qualified class name (FQCN) is not longer used. Instead > > it uses the provider id and the spi name. I can no longer use the same > > PROVIDER_ID as the native providers to ?override? them, but sometimes > there > > is code that gets the provider specifically by id. For example, in the > > UpdatePassword required action we have this: > > > > > > > > PasswordCredentialProvider passwordProvider = > > > (PasswordCredentialProvider)context.getSession().getProvider(CredentialProvider.class, > > PasswordCredentialProviderFactory.PROVIDER_ID); > > > > > > > > In 3.4.3 because our provider was loaded we were able to inject into code > > that normally isn?t overridable. We did the same for the > > OIDCLoginProtocolFactory to alter some token endpoint behavior even the > > UpdatePassword required action itself rather than making a brand new > > required action that is a ?second rate? because it isn?t native to > Keycloak. > > > > > > > > Is there a solution for this in 4.8.3? I see this change was made in > > 4.0.0.Beta1 according to some of the history. > > > > > > > > J > > > > > > Jerry Saravia > > Software Engineer > > T(516) 603-6914 > > M516-603-6914 > > virginpulse.com< > > > https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvirginpulse.com&data=02%7C01%7Cjerry.saravia%40virginpulse.com%7C40d6fd71af6b4998c21a08d6b302ceed%7Cb123a16e892b4cf6a55a6f8c7606a035%7C0%7C0%7C636893221988688789&sdata=wFxdGkMhleh%2F9flNW3Kf%2FLs38Sead7L07IvapwyQPY4%3D&reserved=0 > > > > > |virginpulse.com/global-challenge< > > > https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvirginpulse.com%2Fglobal-challenge&data=02%7C01%7Cjerry.saravia%40virginpulse.com%7C40d6fd71af6b4998c21a08d6b302ceed%7Cb123a16e892b4cf6a55a6f8c7606a035%7C0%7C0%7C636893221988698793&sdata=2LvPxrCOKkzZnCzkNOLGCHj4Jpq74Z70Iy4CNDJCbRw%3D&reserved=0 > > > > > 492 Old Connecticut Path, Framingham, MA 01701, USA > > Australia | Bosnia and Herzegovina | Brazil | Canada | Singapore | > > Switzerland | United Kingdom | USA > > Confidentiality Notice: The information contained in this e-mail, > > including any attachment(s), is intended solely for use by the designated > > recipient(s). Unauthorized use, dissemination, distribution, or > > reproduction of this message by anyone other than the intended > > recipient(s), or a person designated as responsible for delivering such > > messages to the intended recipient, is strictly prohibited and may be > > unlawful. This e-mail may contain proprietary, confidential or privileged > > information. Any views or opinions expressed are solely those of the > author > > and do not necessarily represent those of Virgin Pulse, Inc. If you have > > received this message in error, or are not the named recipient(s), please > > immediately notify the sender and delete this e-mail message. > > v2.48 > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev< > > > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev&data=02%7C01%7Cjerry.saravia%40virginpulse.com%7C40d6fd71af6b4998c21a08d6b302ceed%7Cb123a16e892b4cf6a55a6f8c7606a035%7C0%7C0%7C636893221988708801&sdata=6IayjP%2Bvxtn2C7pH9%2FQQK8rE4zrXRX4%2BWEmXu9ReeMI%3D&reserved=0 > > > > > > _______________________________________________ > 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 5 08:31:14 2019 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 5 Jun 2019 14:31:14 +0200 Subject: [keycloak-dev] Encrypted OIDC ID Tokens support and admin console In-Reply-To: References: <16330b65-4097-65f6-8ebe-f663db5175c0@redhat.com> Message-ID: +1 I also like the idea of OIDC keys, or perhaps it should just be called keys? +1 to separate pr as well On Wed, 5 Jun 2019, 09:21 ???? / NORIMATSU?TAKASHI, < takashi.norimatsu.ws at hitachi.com> wrote: > Hello, > > I think it is a good idea to have "OIDC keys" feature. > > When I wrote the PR for Support signature algorithm PS256/384/512 for > tokens and request object (https://github.com/keycloak/keycloak/pull/5974), > I encountered this matter. > > "OIDC keys" feature might be beneficial for the clients using JWS Client > Assertion (Signed JWT) as their authentication with signature algorithm > other than RS256 (e.g. ES256). > > I think this "OIDC keys" feature be realized as the separate PR because > the PR for ID Token Encryption is independent of how to load the client > public key. > > Takashi Norimatsu > Hitachi, Ltd. > > -----Original Message----- > From: keycloak-dev-bounces at lists.jboss.org < > keycloak-dev-bounces at lists.jboss.org> On Behalf Of Marek Posolda > Sent: Friday, May 31, 2019 4:31 PM > To: keycloak-dev at lists.jboss.org > Subject: [!][keycloak-dev] Encrypted OIDC ID Tokens support and admin > console > > We have PR for introducing encryption support for OIDC ID Tokens. See [1] > and [2]. > > IMO The PR is great contribution and is quite complete. There is support > for manage encryption keys through the REST API or through the OIDC client > registration, which is probably sufficient for have the OIDC FAPI support > happy. However one thing, which seems to be missing, is better admin > console support for seeing and managing the encryption keys of the client. > > Regarding the admin console, the PR just introduces 2 new options for the > client for choosing the algorithms for encryption of ID Tokens. > > For more details, admin console doesn't have support for "hardcode" the > client encryption key/certificate. It has support for downloading the key > from the client's JWKS URL, but the JWKS URL is configured on the bit > strange place. Right now, it is configured under tab "Credentials", then > you need to choose "Signed-JWT" and then you can configure the JWKS URL. > This was OK, when only point of JWKS URL was used just for signed-jwt > client authentication. But now with adding the encrypted ID tokens support, > this is not very appropriate place IMO. For example if you want to use > encrypted ID Tokens together with traditional client authentication based > on clientId/clientSecret, you shouldn't be required to go to "Credentials > -> Signed JWT Authenticator" at all. > > So not sure, if we shoud do some small re-design of admin console now? > For example, for SAML clients, there is tab "SAML Keys" where you can > see/generate/import/export keys used for SAML. I can imagine something like > that for OIDC clients too. We can introduce tab "OIDC Keys" or just "Keys" > . That will allow to have switch "Use JWKS URL" and then configure JWKS URL > (optional) or alternatively the client keys used for SIG and ENC, which > will be required just if "Use JWKS URL" is OFF similarly like it is > currently in the "Credentials -> Signed JWT". Then in the tab "Credentials > -> Signed JWT", there will be just info that you need to configure JWKS URL > or Signing key in the tab "Keys" - so no configuration options on this > page. Similarly the tooltips for the new options for ID Token support will > contain the tooltip, that you should configure JWKS URL or "hardcode" > encryption key in the tab "Keys" . > > The bonus point will be the possibility to view the keys downloaded from > JWKS URL and the ability to invalidate the keys of the individual client > from the cache (currently it's possible to invalidate just globally for the > whole realm AFAIK). > > TBH I am not sure whether to add admin console support in this PR or have > the follow-up PR. > > WDYT? > > [1] > https://clicktime.symantec.com/3VyqBz5ZQQnkb2zESQe6atT7Vc?u=https%3A%2F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-6768 > [2] > https://clicktime.symantec.com/3CaqkVXcTCi2NSLnz1xnr5c7Vc?u=https%3A%2F%2Fgithub.com%2Fkeycloak%2Fkeycloak%2Fpull%2F5779 > > Marek > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > > https://clicktime.symantec.com/35pN5a3WP5d8Jzezose3c5m7Vc?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 Wed Jun 5 09:27:09 2019 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 5 Jun 2019 15:27:09 +0200 Subject: [keycloak-dev] Encrypted OIDC ID Tokens support and admin console In-Reply-To: References: <16330b65-4097-65f6-8ebe-f663db5175c0@redhat.com> Message-ID: <3861eb2b-db58-e237-a074-de2622ff3189@redhat.com> Thanks everyone for the feedback. Created https://issues.jboss.org/browse/KEYCLOAK-10462 as a follow-up JIRA on the initial OIDC encryption support JIRA KEYCLOAK-6768 Not sure if it is better to have "OIDC Keys" or "Keys" . For the SAML clients, we have tab "SAML Keys" . On the other hand, at the realm level we have tab called "Keys"... IMO any of those two is acceptable. Marek On 05/06/2019 14:31, Stian Thorgersen wrote: > +1 I also like the idea of OIDC keys, or perhaps it should just be > called keys? > > +1 to separate pr as well > > On Wed, 5 Jun 2019, 09:21 ???? / NORIMATSU?TAKASHI, > > wrote: > > Hello, > > I think it is a good idea to have "OIDC keys" feature. > > When I wrote the PR for Support signature algorithm PS256/384/512 > for tokens and request object > (https://github.com/keycloak/keycloak/pull/5974), I encountered > this matter. > > "OIDC keys" feature might be beneficial for the clients using JWS > Client Assertion (Signed JWT) as their authentication with > signature algorithm other than RS256 (e.g. ES256). > > I think this "OIDC keys" feature be realized as the separate PR > because the PR for ID Token Encryption is independent of how to > load the client public key. > > Takashi Norimatsu > Hitachi, Ltd. > > -----Original Message----- > From: keycloak-dev-bounces at lists.jboss.org > > > On Behalf Of Marek > Posolda > Sent: Friday, May 31, 2019 4:31 PM > To: keycloak-dev at lists.jboss.org > Subject: [!][keycloak-dev] Encrypted OIDC ID Tokens support and > admin console > > We have PR for introducing encryption support for OIDC ID Tokens. > See [1] and [2]. > > IMO The PR is great contribution and is quite complete. There is > support for manage encryption keys through the REST API or through > the OIDC client registration, which is probably sufficient for > have the OIDC FAPI support happy. However one thing, which seems > to be missing, is better admin console support for seeing and > managing the encryption keys of the client. > > Regarding the admin console, the PR just introduces 2 new options > for the client for choosing the algorithms for encryption of ID > Tokens. > > For more details, admin console doesn't have support for > "hardcode" the client encryption key/certificate. It has support > for downloading the key from the client's JWKS URL, but the JWKS > URL is configured on the bit strange place. Right now, it is > configured under tab "Credentials", then you need to choose > "Signed-JWT" and then you can configure the JWKS URL. This was OK, > when only point of JWKS URL was used just for signed-jwt client > authentication. But now with adding the encrypted ID tokens > support, this is not very appropriate place IMO. For example if > you want to use encrypted ID Tokens together with traditional > client authentication based on clientId/clientSecret, you > shouldn't be required to go to "Credentials -> Signed JWT > Authenticator" at all. > > So not sure, if we shoud do some small re-design of admin console > now? > For example, for SAML clients, there is tab "SAML Keys" where you > can see/generate/import/export keys used for SAML. I can imagine > something like that for OIDC clients too. We can introduce tab > "OIDC Keys" or just "Keys" . That will allow to have switch "Use > JWKS URL" and then configure JWKS URL (optional) or alternatively > the client keys used for SIG and ENC, which will be required just > if "Use JWKS URL" is OFF similarly like it is currently in the > "Credentials -> Signed JWT". Then in the tab "Credentials -> > Signed JWT", there will be just info that you need to configure > JWKS URL or Signing key in the tab "Keys" - so no configuration > options on this page. Similarly the tooltips for the new options > for ID Token support will contain the tooltip, that you should > configure JWKS URL or "hardcode" encryption key in the tab "Keys" . > > The bonus point will be the possibility to view the keys > downloaded from JWKS URL and the ability to invalidate the keys of > the individual client from the cache (currently it's possible to > invalidate just globally for the whole realm AFAIK). > > TBH I am not sure whether to add admin console support in this PR > or have the follow-up PR. > > WDYT? > > [1] > https://clicktime.symantec.com/3VyqBz5ZQQnkb2zESQe6atT7Vc?u=https%3A%2F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-6768 > [2] > https://clicktime.symantec.com/3CaqkVXcTCi2NSLnz1xnr5c7Vc?u=https%3A%2F%2Fgithub.com%2Fkeycloak%2Fkeycloak%2Fpull%2F5779 > > Marek > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://clicktime.symantec.com/35pN5a3WP5d8Jzezose3c5m7Vc?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 h2-wada at nri.co.jp Wed Jun 5 09:36:09 2019 From: h2-wada at nri.co.jp (h2-wada) Date: Wed, 5 Jun 2019 13:36:09 +0000 Subject: [keycloak-dev] Override "native" Keycloak providers In-Reply-To: References: <1DDE98A1-431C-49BF-B20B-AB00C61CF763@contoso.com> <67B38388-64A5-4800-A89E-55D3C9547724@virginpulse.com> , Message-ID: Hi Thomas, > Do you use additional libraries in your custom SAMLProtocolFactory extension? Would you mind sharing your deployment-structure.xml for reference? In my real project, I don't use any additional libraries. So I created a very simple extension which replaces default LoginFormsProvider and use a third-party library (i.e. webauthn4j). But there is no classloading issues. I pushed the sample extension to our github repository. Could you check it? The extension works when accessing login page. https://github.com/openstandia/keycloak-extension-test Best regards, -- Hiroyuki Wada Nomura Research Institute, Ltd. h2-wada at nri.co.jp -------------------------------------------------------------------- ?????????????????????????????????? ???????????????????????????????? ???????????????????????????? PLEASE READ:This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail. -------------------------------------------------------------------- ________________________________________ ???: Thomas Darimont ????: 2019?6?5? 20:23 ??: h2-wada CC: Jerry Saravia; keycloak-dev ??: Re: [keycloak-dev] Override "native" Keycloak providers Hi Hiroyuki, I had some classloading issues with embedded libraries when I tried this approach. That's why I used the module variant. Do you use additional libraries in your custom SAMLProtocolFactory extension? Would you mind sharing your deployment-structure.xml for reference? Cheers and many thanks for your numerous valuable discussions and contributions! Thomas h2-wada > schrieb am Mi., 5. Juni 2019, 11:08: Hi, I also wanted to override the default SAMLProtocolFactory with my class with the same provider id as Thomas mentioned. In my case, it has been successful in replacing the native provider with the same provider id by using the Keycloak Deployer [1]. I confirmed it works with keycloak version 4.3.0.Final, 4.8.3.Final and 6.0.1. The deployment approach is as follows. I think it's a straightforward way than deployment as a module. +Bonus: Hot deployment works !! - Create "jboss-deployment-structure.xml" and place under the "META-INF" directory in your JAR or EAR which contains your classes. - Deploy JAR or EAR by placing it in the "$KEYCLOAK_HOME/standalone/deployments/" directory. [1] https://www.keycloak.org/docs/latest/server_development/index.html#using-the-keycloak-deployer -- Hiroyuki Wada Nomura Research Institute, Ltd. h2-wada at nri.co.jp -------------------------------------------------------------------- ?????????????????????????????????? ???????????????????????????????? ???????????????????????????? PLEASE READ:This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail. -------------------------------------------------------------------- ________________________________________ ???: keycloak-dev-bounces at lists.jboss.org > ? Jerry Saravia > ?????? ????: 2019?4?15? 22:12 ??: Thomas Darimont CC: keycloak-dev at lists.jboss.org ??: Re: [keycloak-dev] Override "native" Keycloak providers Thanks Thomas, This worked!!! Jerry Saravia Software Engineer T(516) 603-6914 M516-603-6914 virginpulse.com |virginpulse.com/global-challenge 492 Old Connecticut Path, Framingham, MA 01701, USA Australia | Bosnia and Herzegovina | Brazil | Canada | Singapore | Switzerland | United Kingdom | USA Confidentiality Notice: The information contained in this e-mail, including any attachment(s), is intended solely for use by the designated recipient(s). Unauthorized use, dissemination, distribution, or reproduction of this message by anyone other than the intended recipient(s), or a person designated as responsible for delivering such messages to the intended recipient, is strictly prohibited and may be unlawful. This e-mail may contain proprietary, confidential or privileged information. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Virgin Pulse, Inc. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message. v2.52 From: Thomas Darimont > Date: Wednesday, March 27, 2019 at 18:23 To: Jerry Saravia > Cc: "keycloak-dev at lists.jboss.org" > Subject: Re: [keycloak-dev] Override "native" Keycloak providers This email originates outside Virgin Pulse. Hello Jerry, I encountered a similar problem with Keycloak 4.x when I needed to implement my own SamlProtocolFactory to customize the SAML Message handling. See: http://lists.jboss.org/pipermail/keycloak-dev/2019-February/011745.html The only way I could get this to work was to add my custom extension jar to the module.xml of the keycloak-services module, see the link for details. It's by far not the best solution, but at least it works. Cheers, Thomas On Wed, 27 Mar 2019 at 22:28, Jerry Saravia >> wrote: Hello, We?ve been using version 3.4.3 for a while now and are attempting to upgrade to 4.8 and we?ve run into some issues. Summary: We have created our own providers with the same PROVIDER_ID as some of the built in providers. For example, PasswordCredentialProvider has a provider id of ?keycloak-password? and we created our own with the same id that gets loaded after the native one. This worked because in 3.4.3 providers that were using the same id would still have their factories added to the factory map. See this link here for 3.4.3 changes: https://github.com/keycloak/keycloak/blob/3.4.3.Final/services/src/main/java/org/keycloak/provider/ProviderManager.java#L96-L100 These are the 4.8 changes https://github.com/keycloak/keycloak/blob/4.8.3.Final/services/src/main/java/org/keycloak/provider/ProviderManager.java#L96-L99 In 4.8, the fully qualified class name (FQCN) is not longer used. Instead it uses the provider id and the spi name. I can no longer use the same PROVIDER_ID as the native providers to ?override? them, but sometimes there is code that gets the provider specifically by id. For example, in the UpdatePassword required action we have this: PasswordCredentialProvider passwordProvider = (PasswordCredentialProvider)context.getSession().getProvider(CredentialProvider.class, PasswordCredentialProviderFactory.PROVIDER_ID); In 3.4.3 because our provider was loaded we were able to inject into code that normally isn?t overridable. We did the same for the OIDCLoginProtocolFactory to alter some token endpoint behavior even the UpdatePassword required action itself rather than making a brand new required action that is a ?second rate? because it isn?t native to Keycloak. Is there a solution for this in 4.8.3? I see this change was made in 4.0.0.Beta1 according to some of the history. J Jerry Saravia Software Engineer T(516) 603-6914 M516-603-6914 virginpulse.com |virginpulse.com/global-challenge 492 Old Connecticut Path, Framingham, MA 01701, USA Australia | Bosnia and Herzegovina | Brazil | Canada | Singapore | Switzerland | United Kingdom | USA Confidentiality Notice: The information contained in this e-mail, including any attachment(s), is intended solely for use by the designated recipient(s). Unauthorized use, dissemination, distribution, or reproduction of this message by anyone other than the intended recipient(s), or a person designated as responsible for delivering such messages to the intended recipient, is strictly prohibited and may be unlawful. This e-mail may contain proprietary, confidential or privileged information. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Virgin Pulse, Inc. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message. v2.48 _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-dev From h2-wada at nri.co.jp Wed Jun 5 09:44:21 2019 From: h2-wada at nri.co.jp (h2-wada) Date: Wed, 5 Jun 2019 13:44:21 +0000 Subject: [keycloak-dev] Override "native" Keycloak providers In-Reply-To: References: <1DDE98A1-431C-49BF-B20B-AB00C61CF763@contoso.com> <67B38388-64A5-4800-A89E-55D3C9547724@virginpulse.com> , Message-ID: Hi Stian, It would be nice if a way to disable the build-in provider with a specific id is implemented officially! I'll create a ticket later, thanks. Best regards, -- Hiroyuki Wada Nomura Research Institute, Ltd. h2-wada at nri.co.jp -------------------------------------------------------------------- ?????????????????????????????????? ???????????????????????????????? ???????????????????????????? PLEASE READ:This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail. -------------------------------------------------------------------- ________________________________________ ???: Stian Thorgersen ????: 2019?6?5? 21:29 ??: Thomas Darimont CC: Hiroyuki Wada; Jerry Saravia; keycloak-dev ??: Re: [keycloak-dev] Override "native" Keycloak providers This kinda works by accident and it's not fully reliable as something could change. I'd like to make sure only one provider is registered with a specific id, but allow disabling built-in providers. If that sounds like a plan please create an issue. On Wed, 5 Jun 2019, 13:29 Thomas Darimont, > wrote: Hi Hiroyuki, I had some classloading issues with embedded libraries when I tried this approach. That's why I used the module variant. Do you use additional libraries in your custom SAMLProtocolFactory extension? Would you mind sharing your deployment-structure.xml for reference? Cheers and many thanks for your numerous valuable discussions and contributions! Thomas h2-wada > schrieb am Mi., 5. Juni 2019, 11:08: > Hi, > > I also wanted to override the default SAMLProtocolFactory with my class > with the same provider id as Thomas mentioned. > In my case, it has been successful in replacing the native provider with > the same provider id by using the Keycloak Deployer [1]. I confirmed it > works with keycloak version 4.3.0.Final, 4.8.3.Final and 6.0.1. > > The deployment approach is as follows. I think it's a straightforward way > than deployment as a module. +Bonus: Hot deployment works !! > > - Create "jboss-deployment-structure.xml" and place under the "META-INF" > directory in your JAR or EAR which contains your classes. > - Deploy JAR or EAR by placing it in the > "$KEYCLOAK_HOME/standalone/deployments/" directory. > > > [1] > https://www.keycloak.org/docs/latest/server_development/index.html#using-the-keycloak-deployer > > > -- > Hiroyuki Wada > Nomura Research Institute, Ltd. > h2-wada at nri.co.jp > > -------------------------------------------------------------------- > ?????????????????????????????????? > ???????????????????????????????? > ???????????????????????????? > PLEASE READ:This e-mail is confidential and intended for > the named recipient only. If you are not an intended recipient, > please notify the sender and delete this e-mail. > -------------------------------------------------------------------- > > > ________________________________________ > ???: keycloak-dev-bounces at lists.jboss.org < > keycloak-dev-bounces at lists.jboss.org> ? Jerry Saravia < > jerry.saravia at virginpulse.com> ?????? > ????: 2019?4?15? 22:12 > ??: Thomas Darimont > CC: keycloak-dev at lists.jboss.org > ??: Re: [keycloak-dev] Override "native" Keycloak providers > > Thanks Thomas, > > This worked!!! > > > Jerry Saravia > Software Engineer > T(516) 603-6914 > M516-603-6914 > virginpulse.com > |virginpulse.com/global-challenge > 492 Old Connecticut Path, Framingham, MA 01701, USA > Australia | Bosnia and Herzegovina | Brazil | Canada | Singapore | > Switzerland | United Kingdom | USA > Confidentiality Notice: The information contained in this e-mail, > including any attachment(s), is intended solely for use by the designated > recipient(s). Unauthorized use, dissemination, distribution, or > reproduction of this message by anyone other than the intended > recipient(s), or a person designated as responsible for delivering such > messages to the intended recipient, is strictly prohibited and may be > unlawful. This e-mail may contain proprietary, confidential or privileged > information. Any views or opinions expressed are solely those of the author > and do not necessarily represent those of Virgin Pulse, Inc. If you have > received this message in error, or are not the named recipient(s), please > immediately notify the sender and delete this e-mail message. > v2.52 > From: Thomas Darimont > > Date: Wednesday, March 27, 2019 at 18:23 > To: Jerry Saravia > > Cc: "keycloak-dev at lists.jboss.org" > > Subject: Re: [keycloak-dev] Override "native" Keycloak providers > > This email originates outside Virgin Pulse. > > Hello Jerry, > > I encountered a similar problem with Keycloak 4.x when I needed to > implement my own SamlProtocolFactory to customize the SAML Message handling. > See: > http://lists.jboss.org/pipermail/keycloak-dev/2019-February/011745.html< > https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.jboss.org%2Fpipermail%2Fkeycloak-dev%2F2019-February%2F011745.html&data=02%7C01%7Cjerry.saravia%40virginpulse.com%7C40d6fd71af6b4998c21a08d6b302ceed%7Cb123a16e892b4cf6a55a6f8c7606a035%7C0%7C0%7C636893221988678776&sdata=JRszK70Y260c5Lvbra19Qp4E%2B9FswzPwPMJRQb8t5G4%3D&reserved=0 > > > The only way I could get this to work was to add my custom extension jar > to the module.xml of the keycloak-services module, > see the link for details. > > It's by far not the best solution, but at least it works. > > Cheers, > Thomas > > On Wed, 27 Mar 2019 at 22:28, Jerry Saravia > >> wrote: > Hello, > > > > We?ve been using version 3.4.3 for a while now and are attempting to > upgrade to 4.8 and we?ve run into some issues. > > > > Summary: We have created our own providers with the same PROVIDER_ID as > some of the built in providers. For example, PasswordCredentialProvider has > a provider id of ?keycloak-password? and we created our own with the same > id that gets loaded after the native one. This worked because in 3.4.3 > providers that were using the same id would still have their factories > added to the factory map. > > > > See this link here for 3.4.3 changes: > > > https://github.com/keycloak/keycloak/blob/3.4.3.Final/services/src/main/java/org/keycloak/provider/ProviderManager.java#L96-L100 > < > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkeycloak%2Fkeycloak%2Fblob%2F3.4.3.Final%2Fservices%2Fsrc%2Fmain%2Fjava%2Forg%2Fkeycloak%2Fprovider%2FProviderManager.java%23L96-L100&data=02%7C01%7Cjerry.saravia%40virginpulse.com%7C40d6fd71af6b4998c21a08d6b302ceed%7Cb123a16e892b4cf6a55a6f8c7606a035%7C0%7C0%7C636893221988678776&sdata=0pjRiO7IuJLBc7XxS%2F2UOwZKDDL4RGbu3yHPJO%2FFG5U%3D&reserved=0 > > > > > > These are the 4.8 changes > > > https://github.com/keycloak/keycloak/blob/4.8.3.Final/services/src/main/java/org/keycloak/provider/ProviderManager.java#L96-L99 > < > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkeycloak%2Fkeycloak%2Fblob%2F4.8.3.Final%2Fservices%2Fsrc%2Fmain%2Fjava%2Forg%2Fkeycloak%2Fprovider%2FProviderManager.java%23L96-L99&data=02%7C01%7Cjerry.saravia%40virginpulse.com%7C40d6fd71af6b4998c21a08d6b302ceed%7Cb123a16e892b4cf6a55a6f8c7606a035%7C0%7C0%7C636893221988688789&sdata=I5hMBZLoQsSFqEakuWb6uSTtuAGOAUSfeQ%2B4CIOwPZY%3D&reserved=0 > > > > > > In 4.8, the fully qualified class name (FQCN) is not longer used. Instead > it uses the provider id and the spi name. I can no longer use the same > PROVIDER_ID as the native providers to ?override? them, but sometimes there > is code that gets the provider specifically by id. For example, in the > UpdatePassword required action we have this: > > > > PasswordCredentialProvider passwordProvider = > (PasswordCredentialProvider)context.getSession().getProvider(CredentialProvider.class, > PasswordCredentialProviderFactory.PROVIDER_ID); > > > > In 3.4.3 because our provider was loaded we were able to inject into code > that normally isn?t overridable. We did the same for the > OIDCLoginProtocolFactory to alter some token endpoint behavior even the > UpdatePassword required action itself rather than making a brand new > required action that is a ?second rate? because it isn?t native to Keycloak. > > > > Is there a solution for this in 4.8.3? I see this change was made in > 4.0.0.Beta1 according to some of the history. > > > > J > > > Jerry Saravia > Software Engineer > T(516) 603-6914 > M516-603-6914 > virginpulse.com< > https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvirginpulse.com&data=02%7C01%7Cjerry.saravia%40virginpulse.com%7C40d6fd71af6b4998c21a08d6b302ceed%7Cb123a16e892b4cf6a55a6f8c7606a035%7C0%7C0%7C636893221988688789&sdata=wFxdGkMhleh%2F9flNW3Kf%2FLs38Sead7L07IvapwyQPY4%3D&reserved=0 > > > |virginpulse.com/global-challenge< > https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvirginpulse.com%2Fglobal-challenge&data=02%7C01%7Cjerry.saravia%40virginpulse.com%7C40d6fd71af6b4998c21a08d6b302ceed%7Cb123a16e892b4cf6a55a6f8c7606a035%7C0%7C0%7C636893221988698793&sdata=2LvPxrCOKkzZnCzkNOLGCHj4Jpq74Z70Iy4CNDJCbRw%3D&reserved=0 > > > 492 Old Connecticut Path, Framingham, MA 01701, USA > Australia | Bosnia and Herzegovina | Brazil | Canada | Singapore | > Switzerland | United Kingdom | USA > Confidentiality Notice: The information contained in this e-mail, > including any attachment(s), is intended solely for use by the designated > recipient(s). Unauthorized use, dissemination, distribution, or > reproduction of this message by anyone other than the intended > recipient(s), or a person designated as responsible for delivering such > messages to the intended recipient, is strictly prohibited and may be > unlawful. This e-mail may contain proprietary, confidential or privileged > information. Any views or opinions expressed are solely those of the author > and do not necessarily represent those of Virgin Pulse, Inc. If you have > received this message in error, or are not the named recipient(s), please > immediately notify the sender and delete this e-mail message. > v2.48 > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-dev< > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev&data=02%7C01%7Cjerry.saravia%40virginpulse.com%7C40d6fd71af6b4998c21a08d6b302ceed%7Cb123a16e892b4cf6a55a6f8c7606a035%7C0%7C0%7C636893221988708801&sdata=6IayjP%2Bvxtn2C7pH9%2FQQK8rE4zrXRX4%2BWEmXu9ReeMI%3D&reserved=0 > > > _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From lucagraf at gmx.de Wed Jun 5 10:54:26 2019 From: lucagraf at gmx.de (Luca Graf) Date: Wed, 5 Jun 2019 16:54:26 +0200 Subject: [keycloak-dev] Integration test: Verify url that was used in an adapter backchannel request Message-ID: I currently work on KEYCLOAK-6073 (Support different URLs for front and back channel requests in adapters) and try to implement some kind of integration test, to verify that an adapter actual use its configured url for backchannel requests. When I understand the existing integration tests correct, it should be relative easy to trigger most of the actions that execute backchannel requests (code-to-token, logout, etc.) with an adapter test (AbstractExampleAdapterTest, AbstractServletsAdapterTest). But I don't see a straight forward way how to verify the url that was actual used by the adapter (in the deployed example or servlet). Not sure if I am on the right track, so any thoughts on how to approach this are appreciated. :) Thanks Luca From sthorger at redhat.com Wed Jun 5 11:37:35 2019 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 5 Jun 2019 17:37:35 +0200 Subject: [keycloak-dev] Encrypted OIDC ID Tokens support and admin console In-Reply-To: <3861eb2b-db58-e237-a074-de2622ff3189@redhat.com> References: <16330b65-4097-65f6-8ebe-f663db5175c0@redhat.com> <3861eb2b-db58-e237-a074-de2622ff3189@redhat.com> Message-ID: I would do Keys and rename saml keys to keys. On Wed, 5 Jun 2019, 15:27 Marek Posolda, wrote: > Thanks everyone for the feedback. Created > https://issues.jboss.org/browse/KEYCLOAK-10462 as a follow-up JIRA on the > initial OIDC encryption support JIRA KEYCLOAK-6768 > > Not sure if it is better to have "OIDC Keys" or "Keys" . For the SAML > clients, we have tab "SAML Keys" . On the other hand, at the realm level we > have tab called "Keys"... IMO any of those two is acceptable. > > Marek > > On 05/06/2019 14:31, Stian Thorgersen wrote: > > +1 I also like the idea of OIDC keys, or perhaps it should just be called > keys? > > +1 to separate pr as well > > On Wed, 5 Jun 2019, 09:21 ???? / NORIMATSU?TAKASHI, < > takashi.norimatsu.ws at hitachi.com> wrote: > >> Hello, >> >> I think it is a good idea to have "OIDC keys" feature. >> >> When I wrote the PR for Support signature algorithm PS256/384/512 for >> tokens and request object (https://github.com/keycloak/keycloak/pull/5974), >> I encountered this matter. >> >> "OIDC keys" feature might be beneficial for the clients using JWS Client >> Assertion (Signed JWT) as their authentication with signature algorithm >> other than RS256 (e.g. ES256). >> >> I think this "OIDC keys" feature be realized as the separate PR because >> the PR for ID Token Encryption is independent of how to load the client >> public key. >> >> Takashi Norimatsu >> Hitachi, Ltd. >> >> -----Original Message----- >> From: keycloak-dev-bounces at lists.jboss.org < >> keycloak-dev-bounces at lists.jboss.org> On Behalf Of Marek Posolda >> Sent: Friday, May 31, 2019 4:31 PM >> To: keycloak-dev at lists.jboss.org >> Subject: [!][keycloak-dev] Encrypted OIDC ID Tokens support and admin >> console >> >> We have PR for introducing encryption support for OIDC ID Tokens. See [1] >> and [2]. >> >> IMO The PR is great contribution and is quite complete. There is support >> for manage encryption keys through the REST API or through the OIDC client >> registration, which is probably sufficient for have the OIDC FAPI support >> happy. However one thing, which seems to be missing, is better admin >> console support for seeing and managing the encryption keys of the client. >> >> Regarding the admin console, the PR just introduces 2 new options for the >> client for choosing the algorithms for encryption of ID Tokens. >> >> For more details, admin console doesn't have support for "hardcode" the >> client encryption key/certificate. It has support for downloading the key >> from the client's JWKS URL, but the JWKS URL is configured on the bit >> strange place. Right now, it is configured under tab "Credentials", then >> you need to choose "Signed-JWT" and then you can configure the JWKS URL. >> This was OK, when only point of JWKS URL was used just for signed-jwt >> client authentication. But now with adding the encrypted ID tokens support, >> this is not very appropriate place IMO. For example if you want to use >> encrypted ID Tokens together with traditional client authentication based >> on clientId/clientSecret, you shouldn't be required to go to "Credentials >> -> Signed JWT Authenticator" at all. >> >> So not sure, if we shoud do some small re-design of admin console now? >> For example, for SAML clients, there is tab "SAML Keys" where you can >> see/generate/import/export keys used for SAML. I can imagine something like >> that for OIDC clients too. We can introduce tab "OIDC Keys" or just "Keys" >> . That will allow to have switch "Use JWKS URL" and then configure JWKS URL >> (optional) or alternatively the client keys used for SIG and ENC, which >> will be required just if "Use JWKS URL" is OFF similarly like it is >> currently in the "Credentials -> Signed JWT". Then in the tab "Credentials >> -> Signed JWT", there will be just info that you need to configure JWKS URL >> or Signing key in the tab "Keys" - so no configuration options on this >> page. Similarly the tooltips for the new options for ID Token support will >> contain the tooltip, that you should configure JWKS URL or "hardcode" >> encryption key in the tab "Keys" . >> >> The bonus point will be the possibility to view the keys downloaded from >> JWKS URL and the ability to invalidate the keys of the individual client >> from the cache (currently it's possible to invalidate just globally for the >> whole realm AFAIK). >> >> TBH I am not sure whether to add admin console support in this PR or have >> the follow-up PR. >> >> WDYT? >> >> [1] >> https://clicktime.symantec.com/3VyqBz5ZQQnkb2zESQe6atT7Vc?u=https%3A%2F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-6768 >> [2] >> https://clicktime.symantec.com/3CaqkVXcTCi2NSLnz1xnr5c7Vc?u=https%3A%2F%2Fgithub.com%2Fkeycloak%2Fkeycloak%2Fpull%2F5779 >> >> Marek >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> >> https://clicktime.symantec.com/35pN5a3WP5d8Jzezose3c5m7Vc?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 sthorger at redhat.com Wed Jun 5 11:38:54 2019 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 5 Jun 2019 17:38:54 +0200 Subject: [keycloak-dev] Integration test: Verify url that was used in an adapter backchannel request In-Reply-To: References: Message-ID: One option could be to use an invalid URL for the front-end URL. On Wed, 5 Jun 2019, 17:23 Luca Graf, wrote: > I currently work on KEYCLOAK-6073 (Support different URLs for front and > back channel requests in adapters) and try to implement some kind of > integration test, to verify that an adapter actual use its configured > url for backchannel requests. > > When I understand the existing integration tests correct, it should be > relative easy to trigger most of the actions that execute backchannel > requests > (code-to-token, logout, etc.) with an adapter test > (AbstractExampleAdapterTest, AbstractServletsAdapterTest). But I don't > see a straight forward way how to verify the url that was actual used by > the adapter (in the deployed example or servlet). > > Not sure if I am on the right track, so any thoughts on how to approach > this are appreciated. :) > > Thanks > Luca > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From lucagraf at gmx.de Wed Jun 5 12:38:15 2019 From: lucagraf at gmx.de (Luca Graf) Date: Wed, 5 Jun 2019 18:38:15 +0200 Subject: [keycloak-dev] Integration test: Verify url that was used in an adapter backchannel request In-Reply-To: References: Message-ID: <52df81f4-28bc-059e-a25f-a2b72cbd53f8@gmx.de> I like the idea and it should be possible to cover all cases without needing any frontchannel communication at all. In the end it should make no difference if the token endpoint was called during a direct flow or a standard flow. Thanks for the input, i will give it try in the next days. Luca On 05.06.19 17:38, Stian Thorgersen wrote: > One option could be to use an invalid URL for the front-end URL. > > On Wed, 5 Jun 2019, 17:23 Luca Graf, > wrote: > > I currently work on KEYCLOAK-6073 (Support different URLs for > front and > back channel requests in adapters) and try to implement some kind of > integration test, to verify that an adapter actual use its configured > url for backchannel requests. > > When I understand the existing integration tests correct, it should be > relative easy to trigger most of the actions that execute backchannel > requests > (code-to-token, logout, etc.) with an adapter test > (AbstractExampleAdapterTest, AbstractServletsAdapterTest). But I don't > see a straight forward way how to verify the url that was actual > used by > the adapter (in the deployed example or servlet). > > Not sure if I am on the right track, so any thoughts on how to > approach > this are appreciated. :) > > Thanks > Luca > > _______________________________________________ > 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 Fri Jun 7 02:22:33 2019 From: takashi.norimatsu.ws at hitachi.com (=?utf-8?B?5LmX5p2+6ZqG5b+XIC8gTk9SSU1BVFNV77yMVEFLQVNISQ==?=) Date: Fri, 7 Jun 2019 06:22:33 +0000 Subject: [keycloak-dev] Request for someone to contribute an WebAuthn4j extension In-Reply-To: References: Message-ID: Hello, I've sent the pull-request of the design document about WebAuthn support. https://github.com/keycloak/keycloak-community/pull/11 I've already done the preliminary analysis by developing the prototype. Before moving onto developing product level codes, I'd like to clarify whether my design is appropriate or not at first. Regards, Takashi Norimatsu Hitachi, Ltd. -----Original Message----- From: keycloak-dev-bounces at lists.jboss.org On Behalf Of ???? / NORIMATSU?TAKASHI Sent: Friday, May 10, 2019 4:50 PM To: 'stian at redhat.com' ; ???? / NAKAMURA?YUUICHI Cc: keycloak-dev Subject: [!]Re: [keycloak-dev] Request for someone to contribute an WebAuthn4j extension Thank you for comments. >* Don't require clicking "Authenticate" button, it's confusing and >should happen automatically >* Use a required action for registration, not an authenticator and custom registration flow. This fits better with the future plans of application initiated actions, and also allows users not self-registered. Yes, I agree with you. I'll revise our prototype. >* Don't use custom table for credentials. I see it's marked as an open issue, but just wanted to mention it again. Custom entities are not supported, this has issues with hot-deployment and I don't want to have to add additional tables for each credential type. Could you please the following master branch? I hope this would resolve your concern. https://clicktime.symantec.com/3MAs6Rwqhcr46HvYrs4eB3m7Vc?u=https%3A%2F%2Fgithub.com%2Fwebauthn4j%2Fkeycloak-webauthn-authenticator%2F At first, I've referred to FIDO U2F Authenticator for Keycloak. https://clicktime.symantec.com/3RZaGXroD3f7kN6dP3qZcUZ7Vc?u=https%3A%2F%2Fgithub.com%2Fstianst%2Fkeycloak-experimental%2Ftree%2Fmaster%2Ffido-u2f And, I've used the existing credential store as follows instead of creating a new table. https://clicktime.symantec.com/385Nkm51Mqizdw6m5JnezBW7Vc?u=https%3A%2F%2Fgithub.com%2Fwebauthn4j%2Fkeycloak-webauthn-authenticator%2Fissues%2F7 >* Problems on re-build/deploy as mentioned in open issues is related to two things I think. Firstly, the above with regards to custom entities. Secondly, we have an issue that theme resources are not re-loaded on re-load (see https://clicktime.symantec.com/3Lsa2WMfYXDxYYeDYNzSjZu7Vc?u=https%3A%2F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-8044). I see. I'll watch this issue. >With regards to testing have you done any research into possibility of functional testing? I know we've discussed this in the past, but not sure if any progress has been made here. I'm currently investigating it. Firstly, I'll clarify whether I can use "Web Authentication Testing API" suggested by Yoshikazu Nojima in https://clicktime.symantec.com/3GSzo2tW2LN6YTVVjVbDyLU7Vc?u=https%3A%2F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-9359 for Arquillian integration tests. Regards, Takashi Norimatsu -----Original Message----- From: keycloak-dev-bounces at lists.jboss.org On Behalf Of Stian Thorgersen Sent: Monday, April 29, 2019 8:08 PM To: ???? / NAKAMURA?YUUICHI Cc: keycloak-dev Subject: [!]Re: [keycloak-dev] Request for someone to contribute an WebAuthn4j extension Sorry for late reply. Finally found some time to try this out. It works pretty well for me, but here's a few discussion points: * Don't require clicking "Authenticate" button, it's confusing and should happen automatically * Use a required action for registration, not an authenticator and custom registration flow. This fits better with the future plans of application initiated actions, and also allows users not self-registered. * Don't use custom table for credentials. I see it's marked as an open issue, but just wanted to mention it again. Custom entities are not supported, this has issues with hot-deployment and I don't want to have to add additional tables for each credential type. * Problems on re-build/deploy as mentioned in open issues is related to two things I think. Firstly, the above with regards to custom entities. Secondly, we have an issue that theme resources are not re-loaded on re-load (see https://clicktime.symantec.com/3JzfAFCPayipxzHfDuqGJYs7Vc?u=https%3A%2F%2Fissues.jboss.org%2Fbrowse%2FKEYCLOAK-8044). With regards to testing have you done any research into possibility of functional testing? I know we've discussed this in the past, but not sure if any progress has been made here. On Thu, 11 Apr 2019 at 05:56, ???? / NAKAMURA?YUUICHI < yuichi.nakamura.fe at hitachi.com> wrote: > Hi, > > We've updated the webauthn authenticator prototype based on webauthn4j : > > https://clicktime.symantec.com/3WCzrfPNkLpaxtUGpjWEzmE7Vc?u=https%3A%2 > F%2Fgithub.com%2Fwebauthn4j%2Fkeycloak-webauthn-authenticator%2Ftree%2 > Fdemo-completed > > We've confirmed that this demo worked well under the following > environments: > * U2F with Resident Key Not supported Authenticator Scenario OS : > Windows 10 Browser : Google Chrome (ver 73), Mozilla FireFox (ver 66) > Authenticator : Yubico Security Key > Server(RP) : keycloak-5.0.0 > > * U2F with Resident Key supported Authenticator Scenario OS : Windows > 10 Browser : Microsoft Edge (ver 44) Authenticator : Internal > Fingerprint Authentication Device > Server(RP) : keycloak-5.0.0 > > * UAF with Resident Key supported Authenticator Scenario OS : Windows > 10 Browser : Microsoft Edge (ver 44) Authenticator : Internal > Fingerprint Authentication Device > Server(RP) : keycloak-5.0.0 > > We will continue to improve the prototype, so feedback is welcomed. > > Regards, > Yuichi Nakamura > > -----Original Message----- > From: keycloak-dev-bounces at lists.jboss.org < > keycloak-dev-bounces at lists.jboss.org> On Behalf Of ???? / > NAKAMURA?YUUICHI > Sent: Tuesday, March 19, 2019 4:32 PM > To: stian at redhat.com > Cc: keycloak-dev > Subject: [!]Re: [keycloak-dev] Request for someone to contribute an > WebAuthn4j extension > > Hi, > > Sorry, we have implemented only for Edge now. > Please wait for other browsers. > > > One comment is that it shouldn't create a new table, but rather just > serialize the value to the existing credential table in the same way > as the FIDO U2F example does [1]. > Thank you, we will fix. > > Regards, > Yuichi Nakamura > > > From: Stian Thorgersen > Sent: Monday, March 18, 2019 5:49 PM > To: ???? / NAKAMURA?YUUICHI > Cc: keycloak-dev ; ???? / > NORIMATSU?TAKASHI > ; ???? / MOGI?TAKASHI < > takashi.mogi.ep at hitachi.com>; Yoshikazu Nojima > Subject: [!]Re: [keycloak-dev] Request for someone to contribute an > WebAuthn4j extension > > Tried this out today and it didn't work for me. I was getting some JS > error both on Chrome and Firefox when trying to register authenticator. > > One comment is that it shouldn't create a new table, but rather just > serialize the value to the existing credential table in the same way > as the FIDO U2F example does [1]. > > [1] > https://clicktime.symantec.com/3XYorxFfnwRutc8N4z3Ubc77Vc?u=https%3A%2 > F%2Fgithub.com%2Fstianst%2Fkeycloak-experimental%2Ftree%2Fmaster%2Ffid > o-u2f > > On Fri, 15 Mar 2019 at 08:13, ???? / NAKAMURA?YUUICHI yuichi.nakamura.fe at hitachi.com> wrote: > Hi, > > We?ve uploaded the initial prototype of webauthn authenticator below: > https://clicktime.symantec.com/37NWG7BAMWtR42Swt5VUTw77Vc?u=https%3A%2 > F%2Fgithub.com%2Fwebauthn4j%2Fkeycloak-webauthn-authenticator > > Feedback is welcomed. > > From: Stian Thorgersen > Sent: Thursday, February 28, 2019 6:53 PM > To: ???? / NAKAMURA?YUUICHI > Cc: keycloak-dev > Subject: [!]Re: [keycloak-dev] Request for someone to contribute an > WebAuthn4j extension > > That's great, thanks. > > Do you have an idea on roughly when you can have a prototype ready? > > On Thu, 28 Feb 2019 at 00:32, ???? / NAKAMURA?YUUICHI yuichi.nakamura.fe at hitachi.com> wrote: > Hi, > > My team has begun to help webauthn4j project, and is going to develop > prototype of authenticator for keycloak. > We'd like to take this. > > Regards, > Yuichi Nakamura > Hitachi, Ltd. > > -----Original Message----- > From: mailto:mailto:keycloak-dev-bounces at lists.jboss.org keycloak-dev-bounces at lists.jboss.org> On Behalf Of Stian Thorgersen > Sent: Thursday, February 28, 2019 12:26 AM > To: keycloak-dev > Subject: [!][keycloak-dev] Request for someone to contribute an > WebAuthn4j extension > > A while back I created an experimental extension to Keycloak for FIDO U2F. > It would be great if someone could adapt this to WebAuthn by > leveraging webauthn4j library [1]. > > Any takers? It shouldn't be hard ;) > > [1] > https://clicktime.symantec.com/3DJdi8ZVRTPPRjKw5d1qT287Vc?u=https%3A%2 > F%2Fgithub.com%2Fwebauthn4j%2Fwebauthn4j > _______________________________________________ > keycloak-dev mailing list > mailto:mailto:keycloak-dev at lists.jboss.org > > https://clicktime.symantec.com/35NVx3Bd41ZVjjssocqwjpK7Vc?u=https%3A%2 > F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > > https://clicktime.symantec.com/3K7AmDtC5f54UYS4NNrH1wo7Vc?u=https%3A%2 > F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev > _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://clicktime.symantec.com/3NyVEGQ7RdnBC2VTZQtDSHz7Vc?u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://clicktime.symantec.com/3C1h6LsbwTQyQXDMT9GBKQf7Vc?u=https%3A%2F%2Flists.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev From sthorger at redhat.com Fri Jun 7 03:28:39 2019 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 7 Jun 2019 09:28:39 +0200 Subject: [keycloak-dev] Multi factor and step up 2nd draft Message-ID: The multi factor and step up design proposal has been updated with a 2nd draft. Please review if you are interested. https://github.com/keycloak/keycloak-community/pull/5 From Oliver.Heger at bosch-si.com Fri Jun 7 07:35:25 2019 From: Oliver.Heger at bosch-si.com (Heger Oliver (INST-IOT/ESB)) Date: Fri, 7 Jun 2019 11:35:25 +0000 Subject: [keycloak-dev] Dynamic SAML roles to user mapper Message-ID: <6b6e9c770271455d88d0f7b5ecaa157f@bosch-si.com> Hi all, For an external customer we need to bring together the SAML IDP of the customer as leading system for user data with our services that are only supporting OIDC. We think Keycloak could fit very well as some kind of mediator between the customer's IDP and our OIDC-based services. The services expect JWTs containing basic user data and also a list with all the roles the user has. With the mappers available in Keycloak a JWT can be constructed that contains the desired information. But now it can happen that the roles model is extended in agreement between the IDP and the client services. As we understand it, in order to support the newly added roles, they would have to be added manually into Keycloak before they can be referenced by the existing SAML Attribute to Role mapper. This manual step we would like to avoid. In our ideal scenario, Keycloak would just be an infrastructure component handling the SAML to OIDC conversion. With respect to the roles assigned to users, it should be agnostic and simply copy the information it receives from the SAML IDP verbatim. To achieve this we think about implementing a custom mapper that allows dealing with roles in this way. It would read the roles from a configurable attribute of the SAML response and assign them to the user affected in the Keycloak data model. If a role was encountered that did not exist yet, it would be newly created. That way the roles model used by Keycloak would adapt itself dynamically to the model used by the parties involved, and no manual updates would be required. Do you think there is an easier solution for this problem than writing a custom mapper? If the answer is no, would you be interested in such a mapper implementation? We would be happy to contribute it. In our opinion this feature would strengthen the brokering facilities of Keycloak. Thank you and kind regards Oliver Heger (INST-IOT/ESB) Bosch Software Innovations GmbH | Stuttgarter Stra?e 130 | 71332 Waiblingen | GERMANY | www.bosch-si.com Tel. +49 711 811-58473 | Fax +49 711 811-58200 | oliver.heger at bosch-si.com Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn, Dr. Aleksandar Mitrovic From jgross.biz at gmail.com Sat Jun 8 02:44:43 2019 From: jgross.biz at gmail.com (Justin Gross) Date: Sat, 8 Jun 2019 02:44:43 -0400 Subject: [keycloak-dev] Client Storage SPI and KEYCLOAK-6408 Message-ID: <5cfb5959.1c69fb81.fbd17.8ad9@mx.google.com> Good afternoon, good evening and good morning everyone! I am Justin and I?d like to start contributing to Keycloak. Is there anyone on the list that is interested in the continuing development of Client Storage SPI? (KEYCLOAK-6408 in JIRA) If you answered yes to the above, what storage systems/software are you interested in using for client storage? Preparing to take on some of the things listed in KEYCLOAK-6408. I am in the middle of a lite refactoring of some useful things which are currently specific to user storage federation such as SynchronizationResult, ImportSynchronization, etc? so they can be used by the yet to be finished Client Storage API. I also plan to refactor some of the LDAP federation stuff so that the user specific stuff is separate from the core LDAP functionality itself. Eventually I want to use LDAP to store client configuration and there?s a lot of useful LDAP functionality stashed away in the user federation stuff. Thank you, Justin Gross From tomasz.pretki at dgt.eu Sat Jun 8 10:07:22 2019 From: tomasz.pretki at dgt.eu (=?iso-8859-2?Q?Tomasz_Pr=EAtki?=) Date: Sat, 8 Jun 2019 14:07:22 +0000 Subject: [keycloak-dev] KEYCLOAK-10251 New Claim JSON Type - JSON Message-ID: Hi, As of now Keycloak allows to specify claims as single values of String, boolean, int and long. By naming a claim with "fully qualified name like 'address.street'" Keycloak creates a nested json object. But what if someone wants to specify a list of addresses? How to achieve that? Especially when this list has to be updated through Admin REST API? That's the use-case I and my colleagues at work have faced. We want to store a list of servers (name, url, some ids) as a hardcoded claim, be able to fetch them from userinfo and show in Web UI to choose one and connect to. Currently we store the list as a json in a String claim, but it would be more appropriate to specify a raw json in a single claim that would be included in claims as a node. Regards Tomasz Pr?tki From jgross.biz at gmail.com Sat Jun 8 23:07:50 2019 From: jgross.biz at gmail.com (Justin Gross) Date: Sat, 8 Jun 2019 23:07:50 -0400 Subject: [keycloak-dev] Storage SPI: Users, Clients, and ? Message-ID: <5cfc7806.1c69fb81.e065d.af73@mx.google.com> Born out of necessity it looks like originally (for storage SPI) there was only user storage SPI and eventually came a partial client storage SPI motivated by a need for Openshift integration. The more I think about how it could be finished, and the more I look at the user storage SPI, the more I am finding code within user storage SPI that can be generalized as simply storage SPI. Seeking feedback on refactoring existing user storage SPI related interfaces to be agnostic to users and generalized as ?storage SPI?. This should reduce the need for duplicating similar code when implementing other storage SPI (ie: client storage SPI). In the future I could see more storage SPI?s being created and I feel this would be extremely useful. Thank you, Justin Gross From slaskawi at redhat.com Mon Jun 10 06:07:01 2019 From: slaskawi at redhat.com (Sebastian Laskawiec) Date: Mon, 10 Jun 2019 12:07:01 +0200 Subject: [keycloak-dev] Keycloak Operator proposal Message-ID: Dear Community, In the near-to-mid future we plan to start working on Keyclaok Operator. Before we dive into the code, we'd like to share our plans with wider audience. A while ago, I created a small design document and issued a Pull Request against the Keycloak Community repo: https://github.com/keycloak/keycloak- community/pull/8 If you are interested in this topic, please grab a cup of coffee and give us some feedback on the PR. Thanks, Sebastian From psilva at redhat.com Mon Jun 10 08:03:10 2019 From: psilva at redhat.com (Pedro Igor Silva) Date: Mon, 10 Jun 2019 09:03:10 -0300 Subject: [keycloak-dev] Storage SPI: Users, Clients, and ? In-Reply-To: <5cfc7806.1c69fb81.e065d.af73@mx.google.com> References: <5cfc7806.1c69fb81.e065d.af73@mx.google.com> Message-ID: Hi Justin, Personally, I think that having a single and multi-purpose SPI can lead to a much more complex and full of hacks to address the different requirements when integrating with different sources and data. In any case, I would suggest you to start a design document and send a PR to https://github.com/keycloak/keycloak-community. So we can understand better your proposal and discuss it. Regards. Pedro Igor On Sun, Jun 9, 2019 at 12:10 AM Justin Gross wrote: > Born out of necessity it looks like originally (for storage SPI) there was > only user storage SPI and eventually came a partial client storage SPI > motivated by a need for Openshift integration. The more I think about how > it could be finished, and the more I look at the user storage SPI, the more > I am finding code within user storage SPI that can be generalized as simply > storage SPI. > > Seeking feedback on refactoring existing user storage SPI related > interfaces to be agnostic to users and generalized as ?storage SPI?. This > should reduce the need for duplicating similar code when implementing other > storage SPI (ie: client storage SPI). > > In the future I could see more storage SPI?s being created and I feel this > would be extremely useful. > > > Thank you, > > Justin Gross > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From psilva at redhat.com Mon Jun 10 08:04:35 2019 From: psilva at redhat.com (Pedro Igor Silva) Date: Mon, 10 Jun 2019 09:04:35 -0300 Subject: [keycloak-dev] KEYCLOAK-10251 New Claim JSON Type - JSON In-Reply-To: References: Message-ID: Hi, Do you mean something like https://github.com/keycloak/keycloak/pull/6041 ? On Sat, Jun 8, 2019 at 11:14 AM Tomasz Pr?tki wrote: > Hi, > > As of now Keycloak allows to specify claims as single values of String, > boolean, int and long. By naming a claim with "fully qualified name like > 'address.street'" Keycloak creates a nested json object. But what if > someone wants to specify a list of addresses? How to achieve that? > Especially when this list has to be updated through Admin REST API? > That's the use-case I and my colleagues at work have faced. We want to > store a list of servers (name, url, some ids) as a hardcoded claim, be able > to fetch them from userinfo and show in Web UI to choose one and connect > to. Currently we store the list as a json in a String claim, but it would > be more appropriate to specify a raw json in a single claim that would be > included in claims as a node. > > Regards > Tomasz Pr?tki > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From tomasz.pretki at dgt.eu Mon Jun 10 08:26:46 2019 From: tomasz.pretki at dgt.eu (=?utf-8?B?VG9tYXN6IFByxJl0a2k=?=) Date: Mon, 10 Jun 2019 12:26:46 +0000 Subject: [keycloak-dev] KEYCLOAK-10251 New Claim JSON Type - JSON In-Reply-To: References: Message-ID: Yes, exactly that. From: Pedro Igor Silva Sent: Monday, June 10, 2019 2:05 PM To: Tomasz Pr?tki Cc: keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] KEYCLOAK-10251 New Claim JSON Type - JSON Hi, Do you mean something like https://github.com/keycloak/keycloak/pull/6041 ? On Sat, Jun 8, 2019 at 11:14 AM Tomasz Pr?tki > wrote: Hi, As of now Keycloak allows to specify claims as single values of String, boolean, int and long. By naming a claim with "fully qualified name like 'address.street'" Keycloak creates a nested json object. But what if someone wants to specify a list of addresses? How to achieve that? Especially when this list has to be updated through Admin REST API? That's the use-case I and my colleagues at work have faced. We want to store a list of servers (name, url, some ids) as a hardcoded claim, be able to fetch them from userinfo and show in Web UI to choose one and connect to. Currently we store the list as a json in a String claim, but it would be more appropriate to specify a raw json in a single claim that would be included in claims as a node. Regards Tomasz Pr?tki _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From psilva at redhat.com Mon Jun 10 10:39:37 2019 From: psilva at redhat.com (Pedro Igor Silva) Date: Mon, 10 Jun 2019 11:39:37 -0300 Subject: [keycloak-dev] Keycloak REST API SPI Message-ID: Hi, When reviewing the Account REST API based on our guidelines [1], I realized that we should implement APIs on top of a specific SPI. As you might know, today we have the RealmResourceSPI [2] which kinds of provides a hook to plug additional APIs into Keycloak. However, the RealmResourceSPI was created for a different purpose and is too generic. The idea behind the new SPI is that it will serve as an entry point for any API we implement for now on, being specific for the addition and management of APIs based on our guidelines. We would still keep the RealmResourceSPI as it is in order to not break backward compatibility. As we result, we should be able to: * Enhanced pluggability of new APIs * Versioning * Control over APIs marked as a technology preview or extensions * Better separation and loose-coupled APIs * Manage APIs individually as well as their respective versions Please, let me know what you think. Regards. Pedro Igor [1] https://github.com/keycloak/keycloak-community/pull/4 [2] https://github.com/keycloak/keycloak/blob/7e33f4a7d1cbf2b37aa2a6d5b87dfe70d57d0252/server-spi-private/src/main/java/org/keycloak/services/resource/RealmResourceSPI.java From jgross.biz at gmail.com Mon Jun 10 14:07:01 2019 From: jgross.biz at gmail.com (Justin Gross) Date: Mon, 10 Jun 2019 14:07:01 -0400 Subject: [keycloak-dev] Storage SPI: Users, Clients, and ? In-Reply-To: References: <5cfc7806.1c69fb81.e065d.af73@mx.google.com> Message-ID: <5cfe9c45.1c69fb81.da535.e964@mx.google.com> Thanks for your feedback Pedro. I apologize I think I may have misspoke or misrepresented my thoughts. A design document might prove helpful in explaining. TLDR; I didn?t intend to advocate for a single multi-purpose SPI but rather a ?parent? SPI which both User Storage and Client Storage could inherit from (implementation wise) and potential future storage SPIs. Looking over User Storage SPI and Client Storage SPI I see a lot of the code in Client Storage Provider (and related files) as copied from User Storage and code that is not specific to either and related only to storage itself. There are more Client Storage Provider related stuff that, when finished, will probably also just be a copy/duplicate of existing generic code in User Storage Provider (and related). Given that most storage SPI?s will probably have similar ?storage general? interfaces and functions it would make sense to me to create a common ancestor rather than continue to duplicate code in every specific storage SPI thereby actually simplifying (instead of making more complex) the User and Client (and other future) storage SPI?s. My proposition (I?ll PR to community) is that we move code that is not specific to User Storage (or Client) but that is actually general code (code currently being duplicated or soon to be if finishing Client Storage SPI) into ?storage? classes and interfaces. This would group together the storage interfaces and functionality that are general and thereby simplifies the production of new storage SPI?s as new storage SPI?s can narrow their focus to the specific requirements you spoke of Pedro. Thank you, Justin Gross From: Pedro Igor Silva Sent: Monday, June 10, 2019 8:03 AM To: Justin Gross Cc: keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] Storage SPI: Users, Clients, and ? Hi Justin, Personally, I think that having a single and multi-purpose SPI can lead to a much more complex and full of hacks to address the different requirements when integrating with different sources and data. In any case, I would suggest you to start a design document and send a PR to?https://github.com/keycloak/keycloak-community. So we can understand better your proposal and discuss it. Regards. Pedro Igor On Sun, Jun 9, 2019 at 12:10 AM Justin Gross wrote: Born out of necessity it looks like originally (for storage SPI) there was only user storage SPI and eventually came a partial client storage SPI motivated by a need for Openshift integration. The more I think about how it could be finished, and the more I look at the user storage SPI, the more I am finding code within user storage SPI that can be generalized as simply storage SPI. Seeking feedback on refactoring existing user storage SPI related interfaces to be agnostic to users and generalized as ?storage SPI?. This should reduce the need for duplicating similar code when implementing other storage SPI (ie: client storage SPI). In the future I could see more storage SPI?s being created and I feel this would be extremely useful. Thank you, Justin Gross _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From psilva at redhat.com Mon Jun 10 14:25:35 2019 From: psilva at redhat.com (Pedro Igor Silva) Date: Mon, 10 Jun 2019 15:25:35 -0300 Subject: [keycloak-dev] Storage SPI: Users, Clients, and ? In-Reply-To: <5cfe9c45.1c69fb81.da535.e964@mx.google.com> References: <5cfc7806.1c69fb81.e065d.af73@mx.google.com> <5cfe9c45.1c69fb81.da535.e964@mx.google.com> Message-ID: I see your point now. Please, go one with your PR or design document I'm sure you'll get tons of reviews as you are touching a quite sensitive area :) Stian can talk more about this, but maybe this is something for Keycloak.Next. Regards. On Mon, Jun 10, 2019 at 3:07 PM Justin Gross wrote: > Thanks for your feedback Pedro. > > > > I apologize I think I may have misspoke or misrepresented my thoughts. A > design document might prove helpful in explaining. > > > > TLDR; > > > > I didn?t intend to advocate for a single multi-purpose SPI but rather a > ?parent? SPI which both User Storage and Client Storage could inherit from > (implementation wise) and potential future storage SPIs. > > > > Looking over User Storage SPI and Client Storage SPI I see a lot of the > code in Client Storage Provider (and related files) as copied from User > Storage and code that is not specific to either and related only to storage > itself. There are more Client Storage Provider related stuff that, when > finished, will probably also just be a copy/duplicate of existing generic > code in User Storage Provider (and related). > > > > Given that most storage SPI?s will probably have similar ?storage general? > interfaces and functions it would make sense to me to create a common > ancestor rather than continue to duplicate code in every specific storage > SPI thereby actually simplifying (instead of making more complex) the User > and Client (and other future) storage SPI?s. > > > > My proposition (I?ll PR to community) is that we move code that is not > specific to User Storage (or Client) but that is actually general code > (code currently being duplicated or soon to be if finishing Client Storage > SPI) into ?storage? classes and interfaces. This would group together the > storage interfaces and functionality that are general and thereby > simplifies the production of new storage SPI?s as new storage SPI?s can > narrow their focus to the specific requirements you spoke of Pedro. > > > > Thank you, > > Justin Gross > > > > *From: *Pedro Igor Silva > *Sent: *Monday, June 10, 2019 8:03 AM > *To: *Justin Gross > *Cc: *keycloak-dev at lists.jboss.org > *Subject: *Re: [keycloak-dev] Storage SPI: Users, Clients, and ? > > > > Hi Justin, > > > > Personally, I think that having a single and multi-purpose SPI can lead to > a much more complex and full of hacks to address the different requirements > when integrating with different sources and data. In any case, I would > suggest you to start a design document and send a PR to > https://github.com/keycloak/keycloak-community. So we can understand > better your proposal and discuss it. > > > > Regards. > > Pedro Igor > > > > On Sun, Jun 9, 2019 at 12:10 AM Justin Gross wrote: > > Born out of necessity it looks like originally (for storage SPI) there was > only user storage SPI and eventually came a partial client storage SPI > motivated by a need for Openshift integration. The more I think about how > it could be finished, and the more I look at the user storage SPI, the more > I am finding code within user storage SPI that can be generalized as simply > storage SPI. > > Seeking feedback on refactoring existing user storage SPI related > interfaces to be agnostic to users and generalized as ?storage SPI?. This > should reduce the need for duplicating similar code when implementing other > storage SPI (ie: client storage SPI). > > In the future I could see more storage SPI?s being created and I feel this > would be extremely useful. > > > Thank you, > > Justin Gross > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > From mposolda at redhat.com Mon Jun 10 15:02:33 2019 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 10 Jun 2019 21:02:33 +0200 Subject: [keycloak-dev] Storage SPI: Users, Clients, and ? In-Reply-To: References: <5cfc7806.1c69fb81.e065d.af73@mx.google.com> <5cfe9c45.1c69fb81.da535.e964@mx.google.com> Message-ID: <54de8d33-acf0-76e3-e5f5-b1ee1bc55669@redhat.com> Hi, I remember we already discuss this some time ago. I agree that have some "generic" storage SPI could be beneficial for various use-cases. For example Role Storage SPI or Group Storage SPI could be beneficial for LDAP integration - Keycloak currently supports syncing LDAP roles and groups to KC database and use role (group) mappings based on the role (group) mappings from LDAP, but there are some corner cases, which causes that data are not always 100% accurate. For example when some LDAP group is changed, Keycloak is not notified about this change etc. But agree with Pedro, that complexity of this probably won't justify the added value. We can maybe think about it for Keycloak.next if something like this can work, but ATM I have quite doubts... But maybe I am wrong and you come with some cool design proposal :) BTV. Just a warning, that if you think about refactoring of current User + Client Storage SPI (and not adding any new SPI), then the potential challenge is, that UserStorage SPI is officially supported and is guaranteed to be backwards compatible. In other words, existing interfaces can't be easily changed in backwards incompatible way. Marek On 10/06/2019 20:25, Pedro Igor Silva wrote: > I see your point now. Please, go one with your PR or design document I'm > sure you'll get tons of reviews as you are touching a quite sensitive area > :) > > Stian can talk more about this, but maybe this is something for > Keycloak.Next. > > Regards. > > On Mon, Jun 10, 2019 at 3:07 PM Justin Gross wrote: > >> Thanks for your feedback Pedro. >> >> >> >> I apologize I think I may have misspoke or misrepresented my thoughts. A >> design document might prove helpful in explaining. >> >> >> >> TLDR; >> >> >> >> I didn?t intend to advocate for a single multi-purpose SPI but rather a >> ?parent? SPI which both User Storage and Client Storage could inherit from >> (implementation wise) and potential future storage SPIs. >> >> >> >> Looking over User Storage SPI and Client Storage SPI I see a lot of the >> code in Client Storage Provider (and related files) as copied from User >> Storage and code that is not specific to either and related only to storage >> itself. There are more Client Storage Provider related stuff that, when >> finished, will probably also just be a copy/duplicate of existing generic >> code in User Storage Provider (and related). >> >> >> >> Given that most storage SPI?s will probably have similar ?storage general? >> interfaces and functions it would make sense to me to create a common >> ancestor rather than continue to duplicate code in every specific storage >> SPI thereby actually simplifying (instead of making more complex) the User >> and Client (and other future) storage SPI?s. >> >> >> >> My proposition (I?ll PR to community) is that we move code that is not >> specific to User Storage (or Client) but that is actually general code >> (code currently being duplicated or soon to be if finishing Client Storage >> SPI) into ?storage? classes and interfaces. This would group together the >> storage interfaces and functionality that are general and thereby >> simplifies the production of new storage SPI?s as new storage SPI?s can >> narrow their focus to the specific requirements you spoke of Pedro. >> >> >> >> Thank you, >> >> Justin Gross >> >> >> >> *From: *Pedro Igor Silva >> *Sent: *Monday, June 10, 2019 8:03 AM >> *To: *Justin Gross >> *Cc: *keycloak-dev at lists.jboss.org >> *Subject: *Re: [keycloak-dev] Storage SPI: Users, Clients, and ? >> >> >> >> Hi Justin, >> >> >> >> Personally, I think that having a single and multi-purpose SPI can lead to >> a much more complex and full of hacks to address the different requirements >> when integrating with different sources and data. In any case, I would >> suggest you to start a design document and send a PR to >> https://github.com/keycloak/keycloak-community. So we can understand >> better your proposal and discuss it. >> >> >> >> Regards. >> >> Pedro Igor >> >> >> >> On Sun, Jun 9, 2019 at 12:10 AM Justin Gross wrote: >> >> Born out of necessity it looks like originally (for storage SPI) there was >> only user storage SPI and eventually came a partial client storage SPI >> motivated by a need for Openshift integration. The more I think about how >> it could be finished, and the more I look at the user storage SPI, the more >> I am finding code within user storage SPI that can be generalized as simply >> storage SPI. >> >> Seeking feedback on refactoring existing user storage SPI related >> interfaces to be agnostic to users and generalized as ?storage SPI?. This >> should reduce the need for duplicating similar code when implementing other >> storage SPI (ie: client storage SPI). >> >> In the future I could see more storage SPI?s being created and I feel this >> would be extremely useful. >> >> >> Thank you, >> >> Justin Gross >> _______________________________________________ >> 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 jgross.biz at gmail.com Mon Jun 10 23:28:01 2019 From: jgross.biz at gmail.com (Justin Gross) Date: Mon, 10 Jun 2019 23:28:01 -0400 Subject: [keycloak-dev] Storage SPI: Users, Clients, and ? In-Reply-To: <54de8d33-acf0-76e3-e5f5-b1ee1bc55669@redhat.com> References: <5cfc7806.1c69fb81.e065d.af73@mx.google.com> <5cfe9c45.1c69fb81.da535.e964@mx.google.com> <54de8d33-acf0-76e3-e5f5-b1ee1bc55669@redhat.com> Message-ID: <5cff1fc0.1c69fb81.edd25.ebb3@mx.google.com> Your feedback is much appreciated! Especially the note on UserStorage SPI being officially supported and therefore guaranteed to be backward compatible. I hadn?t planned on changing that interface but I could see how by ?transplanting? large pieces of it to an ancestor that someone could change the ancestor and then negatively impact compatibility in UserStorage SPI accidentally or by happenstance. Definitely good to keep in mind and I?ll make sure my proposal doesn?t effect User Storage SPI directly or make it any easier to disturb it. Thanks again! Justin Gross From: Marek Posolda Sent: Monday, June 10, 2019 3:02 PM To: Pedro Igor Silva; Justin Gross Cc: keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] Storage SPI: Users, Clients, and ? Hi, I remember we already discuss this some time ago. I agree that have some "generic" storage SPI could be beneficial for various use-cases. For example Role Storage SPI or Group Storage SPI could be beneficial for LDAP integration - Keycloak currently supports syncing LDAP roles and groups to KC database and use role (group) mappings based on the role (group) mappings from LDAP, but there are some corner cases, which causes that data are not always 100% accurate. For example when some LDAP group is changed, Keycloak is not notified about this change etc. But agree with Pedro, that complexity of this probably won't justify the added value. We can maybe think about it for Keycloak.next if something like this can work, but ATM I have quite doubts... But maybe I am wrong and you come with some cool design proposal :) BTV. Just a warning, that if you think about refactoring of current User + Client Storage SPI (and not adding any new SPI), then the potential challenge is, that UserStorage SPI is officially supported and is guaranteed to be backwards compatible. In other words, existing interfaces can't be easily changed in backwards incompatible way. Marek On 10/06/2019 20:25, Pedro Igor Silva wrote: > I see your point now. Please, go one with your PR or design document I'm > sure you'll get tons of reviews as you are touching a quite sensitive area > :) > > Stian can talk more about this, but maybe this is something for > Keycloak.Next. > > Regards. > > On Mon, Jun 10, 2019 at 3:07 PM Justin Gross wrote: > >> Thanks for your feedback Pedro. >> >> >> >> I apologize I think I may have misspoke or misrepresented my thoughts. A >> design document might prove helpful in explaining. >> >> >> >> TLDR; >> >> >> >> I didn?t intend to advocate for a single multi-purpose SPI but rather a >> ?parent? SPI which both User Storage and Client Storage could inherit from >> (implementation wise) and potential future storage SPIs. >> >> >> >> Looking over User Storage SPI and Client Storage SPI I see a lot of the >> code in Client Storage Provider (and related files) as copied from User >> Storage and code that is not specific to either and related only to storage >> itself. There are more Client Storage Provider related stuff that, when >> finished, will probably also just be a copy/duplicate of existing generic >> code in User Storage Provider (and related). >> >> >> >> Given that most storage SPI?s will probably have similar ?storage general? >> interfaces and functions it would make sense to me to create a common >> ancestor rather than continue to duplicate code in every specific storage >> SPI thereby actually simplifying (instead of making more complex) the User >> and Client (and other future) storage SPI?s. >> >> >> >> My proposition (I?ll PR to community) is that we move code that is not >> specific to User Storage (or Client) but that is actually general code >> (code currently being duplicated or soon to be if finishing Client Storage >> SPI) into ?storage? classes and interfaces. This would group together the >> storage interfaces and functionality that are general and thereby >> simplifies the production of new storage SPI?s as new storage SPI?s can >> narrow their focus to the specific requirements you spoke of Pedro. >> >> >> >> Thank you, >> >> Justin Gross >> >> >> >> *From: *Pedro Igor Silva >> *Sent: *Monday, June 10, 2019 8:03 AM >> *To: *Justin Gross >> *Cc: *keycloak-dev at lists.jboss.org >> *Subject: *Re: [keycloak-dev] Storage SPI: Users, Clients, and ? >> >> >> >> Hi Justin, >> >> >> >> Personally, I think that having a single and multi-purpose SPI can lead to >> a much more complex and full of hacks to address the different requirements >> when integrating with different sources and data. In any case, I would >> suggest you to start a design document and send a PR to >> https://github.com/keycloak/keycloak-community. So we can understand >> better your proposal and discuss it. >> >> >> >> Regards. >> >> Pedro Igor >> >> >> >> On Sun, Jun 9, 2019 at 12:10 AM Justin Gross wrote: >> >> Born out of necessity it looks like originally (for storage SPI) there was >> only user storage SPI and eventually came a partial client storage SPI >> motivated by a need for Openshift integration. The more I think about how >> it could be finished, and the more I look at the user storage SPI, the more >> I am finding code within user storage SPI that can be generalized as simply >> storage SPI. >> >> Seeking feedback on refactoring existing user storage SPI related >> interfaces to be agnostic to users and generalized as ?storage SPI?. This >> should reduce the need for duplicating similar code when implementing other >> storage SPI (ie: client storage SPI). >> >> In the future I could see more storage SPI?s being created and I feel this >> would be extremely useful. >> >> >> Thank you, >> >> Justin Gross >> _______________________________________________ >> 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 jgross.biz at gmail.com Mon Jun 10 23:59:33 2019 From: jgross.biz at gmail.com (Justin Gross) Date: Mon, 10 Jun 2019 23:59:33 -0400 Subject: [keycloak-dev] Guaranteed Backwards Compatibility Message-ID: <5cff2725.1c69fb81.6acc2.03b1@mx.google.com> Marek Posolda brought up a good point in another thread about certain pieces of Keycloak being guaranteed to have backward compatibility. Is there a guideline for this, a strict outline of what is guaranteed to continue being backwards compatible or any documentation outlining what should be kept strictly compatible during a version change? TLDR; I recognize and understand the semantic versioning (or at least presume to) however I ask this so that I can make sure I consider the list of sacred things (if there is one) and especially take this into account while I design/propose/work on anything within the Keycloak project. I tried Google searching but only found the upgrade docs at keycloak.org/docs/latest/upgrading. Thank you, Justin Gross From sthorger at redhat.com Tue Jun 11 06:42:48 2019 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 11 Jun 2019 12:42:48 +0200 Subject: [keycloak-dev] Guaranteed Backwards Compatibility In-Reply-To: <5cff2725.1c69fb81.6acc2.03b1@mx.google.com> References: <5cff2725.1c69fb81.6acc2.03b1@mx.google.com> Message-ID: The aim is to always be backwards compatible, and deprecate rather than remove. Non-public APIs are not covered. For example only user storage SPI is a public API, while other SPIs like event listener is private and as such we reserve the right to break it. On Tue, 11 Jun 2019 at 06:01, Justin Gross wrote: > Marek Posolda brought up a good point in another thread about certain > pieces of Keycloak being guaranteed to have backward compatibility. Is > there a guideline for this, a strict outline of what is guaranteed to > continue being backwards compatible or any documentation outlining what > should be kept strictly compatible during a version change? > > TLDR; > > I recognize and understand the semantic versioning (or at least presume > to) however I ask this so that I can make sure I consider the list of > sacred things (if there is one) and especially take this into account while > I design/propose/work on anything within the Keycloak project. I tried > Google searching but only found the upgrade docs at > keycloak.org/docs/latest/upgrading. > > > Thank you, > > Justin Gross > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Tue Jun 11 06:45:21 2019 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 11 Jun 2019 12:45:21 +0200 Subject: [keycloak-dev] Storage SPI: Users, Clients, and ? In-Reply-To: <5cff1fc0.1c69fb81.edd25.ebb3@mx.google.com> References: <5cfc7806.1c69fb81.e065d.af73@mx.google.com> <5cfe9c45.1c69fb81.da535.e964@mx.google.com> <54de8d33-acf0-76e3-e5f5-b1ee1bc55669@redhat.com> <5cff1fc0.1c69fb81.edd25.ebb3@mx.google.com> Message-ID: We shouldn't undertake any big refactoring of these right now. We are planning a much bigger overhaul around the storage layer in Keycloak.Next. With regards to clients I'm still considering whether or not a realm needs to have more than one client store. At the moment I'm leaning towards that it should have just one and the API should be fairly simple and easy to replace with something custom. On Tue, 11 Jun 2019 at 05:29, Justin Gross wrote: > Your feedback is much appreciated! Especially the note on UserStorage SPI > being officially supported and therefore guaranteed to be backward > compatible. I hadn?t planned on changing that interface but I could see how > by ?transplanting? large pieces of it to an ancestor that someone could > change the ancestor and then negatively impact compatibility in UserStorage > SPI accidentally or by happenstance. Definitely good to keep in mind and > I?ll make sure my proposal doesn?t effect User Storage SPI directly or make > it any easier to disturb it. > > > Thanks again! > > Justin Gross > > > From: Marek Posolda > Sent: Monday, June 10, 2019 3:02 PM > To: Pedro Igor Silva; Justin Gross > Cc: keycloak-dev at lists.jboss.org > Subject: Re: [keycloak-dev] Storage SPI: Users, Clients, and ? > > Hi, > > I remember we already discuss this some time ago. I agree that have some > "generic" storage SPI could be beneficial for various use-cases. For > example Role Storage SPI or Group Storage SPI could be beneficial for > LDAP integration - Keycloak currently supports syncing LDAP roles and > groups to KC database and use role (group) mappings based on the role > (group) mappings from LDAP, but there are some corner cases, which > causes that data are not always 100% accurate. For example when some > LDAP group is changed, Keycloak is not notified about this change etc. > > But agree with Pedro, that complexity of this probably won't justify the > added value. We can maybe think about it for Keycloak.next if something > like this can work, but ATM I have quite doubts... But maybe I am wrong > and you come with some cool design proposal :) > > BTV. Just a warning, that if you think about refactoring of current User > + Client Storage SPI (and not adding any new SPI), then the potential > challenge is, that UserStorage SPI is officially supported and is > guaranteed to be backwards compatible. In other words, existing > interfaces can't be easily changed in backwards incompatible way. > > Marek > > On 10/06/2019 20:25, Pedro Igor Silva wrote: > > I see your point now. Please, go one with your PR or design document I'm > > sure you'll get tons of reviews as you are touching a quite sensitive > area > > :) > > > > Stian can talk more about this, but maybe this is something for > > Keycloak.Next. > > > > Regards. > > > > On Mon, Jun 10, 2019 at 3:07 PM Justin Gross > wrote: > > > >> Thanks for your feedback Pedro. > >> > >> > >> > >> I apologize I think I may have misspoke or misrepresented my thoughts. A > >> design document might prove helpful in explaining. > >> > >> > >> > >> TLDR; > >> > >> > >> > >> I didn?t intend to advocate for a single multi-purpose SPI but rather a > >> ?parent? SPI which both User Storage and Client Storage could inherit > from > >> (implementation wise) and potential future storage SPIs. > >> > >> > >> > >> Looking over User Storage SPI and Client Storage SPI I see a lot of the > >> code in Client Storage Provider (and related files) as copied from User > >> Storage and code that is not specific to either and related only to > storage > >> itself. There are more Client Storage Provider related stuff that, when > >> finished, will probably also just be a copy/duplicate of existing > generic > >> code in User Storage Provider (and related). > >> > >> > >> > >> Given that most storage SPI?s will probably have similar ?storage > general? > >> interfaces and functions it would make sense to me to create a common > >> ancestor rather than continue to duplicate code in every specific > storage > >> SPI thereby actually simplifying (instead of making more complex) the > User > >> and Client (and other future) storage SPI?s. > >> > >> > >> > >> My proposition (I?ll PR to community) is that we move code that is not > >> specific to User Storage (or Client) but that is actually general code > >> (code currently being duplicated or soon to be if finishing Client > Storage > >> SPI) into ?storage? classes and interfaces. This would group together > the > >> storage interfaces and functionality that are general and thereby > >> simplifies the production of new storage SPI?s as new storage SPI?s can > >> narrow their focus to the specific requirements you spoke of Pedro. > >> > >> > >> > >> Thank you, > >> > >> Justin Gross > >> > >> > >> > >> *From: *Pedro Igor Silva > >> *Sent: *Monday, June 10, 2019 8:03 AM > >> *To: *Justin Gross > >> *Cc: *keycloak-dev at lists.jboss.org > >> *Subject: *Re: [keycloak-dev] Storage SPI: Users, Clients, and ? > >> > >> > >> > >> Hi Justin, > >> > >> > >> > >> Personally, I think that having a single and multi-purpose SPI can lead > to > >> a much more complex and full of hacks to address the different > requirements > >> when integrating with different sources and data. In any case, I would > >> suggest you to start a design document and send a PR to > >> https://github.com/keycloak/keycloak-community. So we can understand > >> better your proposal and discuss it. > >> > >> > >> > >> Regards. > >> > >> Pedro Igor > >> > >> > >> > >> On Sun, Jun 9, 2019 at 12:10 AM Justin Gross > wrote: > >> > >> Born out of necessity it looks like originally (for storage SPI) there > was > >> only user storage SPI and eventually came a partial client storage SPI > >> motivated by a need for Openshift integration. The more I think about > how > >> it could be finished, and the more I look at the user storage SPI, the > more > >> I am finding code within user storage SPI that can be generalized as > simply > >> storage SPI. > >> > >> Seeking feedback on refactoring existing user storage SPI related > >> interfaces to be agnostic to users and generalized as ?storage SPI?. > This > >> should reduce the need for duplicating similar code when implementing > other > >> storage SPI (ie: client storage SPI). > >> > >> In the future I could see more storage SPI?s being created and I feel > this > >> would be extremely useful. > >> > >> > >> Thank you, > >> > >> Justin Gross > >> _______________________________________________ > >> 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 Tue Jun 11 06:45:49 2019 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 11 Jun 2019 12:45:49 +0200 Subject: [keycloak-dev] Keycloak REST API SPI In-Reply-To: References: Message-ID: +1 On Mon, 10 Jun 2019 at 16:50, Pedro Igor Silva wrote: > Hi, > > When reviewing the Account REST API based on our guidelines [1], I realized > that we should implement APIs on top of a specific SPI. > > As you might know, today we have the RealmResourceSPI [2] which kinds of > provides a hook to plug additional APIs into Keycloak. However, the > RealmResourceSPI was created for a different purpose and is too generic. > > The idea behind the new SPI is that it will serve as an entry point for any > API we implement for now on, being specific for the addition and management > of APIs based on our guidelines. We would still keep the RealmResourceSPI > as it is in order to not break backward compatibility. As we result, we > should be able to: > > * Enhanced pluggability of new APIs > * Versioning > * Control over APIs marked as a technology preview or extensions > * Better separation and loose-coupled APIs > * Manage APIs individually as well as their respective versions > > Please, let me know what you think. > > Regards. > Pedro Igor > > [1] https://github.com/keycloak/keycloak-community/pull/4 > [2] > > https://github.com/keycloak/keycloak/blob/7e33f4a7d1cbf2b37aa2a6d5b87dfe70d57d0252/server-spi-private/src/main/java/org/keycloak/services/resource/RealmResourceSPI.java > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Tue Jun 11 06:49:15 2019 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 11 Jun 2019 12:49:15 +0200 Subject: [keycloak-dev] Client Storage SPI and KEYCLOAK-6408 In-Reply-To: <5cfb5959.1c69fb81.fbd17.8ad9@mx.google.com> References: <5cfb5959.1c69fb81.fbd17.8ad9@mx.google.com> Message-ID: We are planning a bigger rework of the storage layer in the future as part of Keycloak .Next. With that in mind you should rather follow the discussion around that as it unfolds over the next few months. For the current implementation we can be open to smaller stuff, but not big overhauls. Finishing the client storage API may be useful, but to be honest not many people have been interested here. I'd rather see a simpler client store where it's easier to replace with a custom store. I don't think there's need to federate multiple client stores for a single realm. For LDAP I'm not sure what you mean about separate core and user stuff. It is only a user store, at least now. Are you perhaps thinking about storing clients in LDAP? On Sat, 8 Jun 2019 at 08:46, Justin Gross wrote: > Good afternoon, good evening and good morning everyone! I am Justin and > I?d like to start contributing to Keycloak. > > Is there anyone on the list that is interested in the continuing > development of Client Storage SPI? (KEYCLOAK-6408 in JIRA) > > If you answered yes to the above, what storage systems/software are you > interested in using for client storage? > > Preparing to take on some of the things listed in KEYCLOAK-6408. > > I am in the middle of a lite refactoring of some useful things which are > currently specific to user storage federation such as > SynchronizationResult, ImportSynchronization, etc? so they can be used by > the yet to be finished Client Storage API. > > I also plan to refactor some of the LDAP federation stuff so that the user > specific stuff is separate from the core LDAP functionality itself. > Eventually I want to use LDAP to store client configuration and there?s a > lot of useful LDAP functionality stashed away in the user federation stuff. > > > Thank you, > > Justin Gross > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From luke at code-house.org Tue Jun 11 13:18:16 2019 From: luke at code-house.org (=?UTF-8?Q?=c5=81ukasz_Dywicki?=) Date: Tue, 11 Jun 2019 19:18:16 +0200 Subject: [keycloak-dev] Client Storage SPI and KEYCLOAK-6408 In-Reply-To: References: <5cfb5959.1c69fb81.fbd17.8ad9@mx.google.com> Message-ID: <0d765eec-900f-2ce7-c4b0-51f036a2a4df@code-house.org> Hey Stian, I track mailing lists from time to time but I see the term "Keycloak.Next" first time. Do you have a scope of changes you would like to introduce within next major release? Perhaps there is an JIRA epic or something where I could sign in to track progress and horizon of changes? All best, ?ukasz Dywicki -- Code-House http://code-house.org On 11.06.2019 12:49, Stian Thorgersen wrote: > We are planning a bigger rework of the storage layer in the future as part > of Keycloak .Next. > > With that in mind you should rather follow the discussion around that as it > unfolds over the next few months. > > For the current implementation we can be open to smaller stuff, but not big > overhauls. > > Finishing the client storage API may be useful, but to be honest not many > people have been interested here. I'd rather see a simpler client store > where it's easier to replace with a custom store. I don't think there's > need to federate multiple client stores for a single realm. > > For LDAP I'm not sure what you mean about separate core and user stuff. It > is only a user store, at least now. Are you perhaps thinking about storing > clients in LDAP? > > On Sat, 8 Jun 2019 at 08:46, Justin Gross wrote: > >> Good afternoon, good evening and good morning everyone! I am Justin and >> I?d like to start contributing to Keycloak. >> >> Is there anyone on the list that is interested in the continuing >> development of Client Storage SPI? (KEYCLOAK-6408 in JIRA) >> >> If you answered yes to the above, what storage systems/software are you >> interested in using for client storage? >> >> Preparing to take on some of the things listed in KEYCLOAK-6408. >> >> I am in the middle of a lite refactoring of some useful things which are >> currently specific to user storage federation such as >> SynchronizationResult, ImportSynchronization, etc? so they can be used by >> the yet to be finished Client Storage API. >> >> I also plan to refactor some of the LDAP federation stuff so that the user >> specific stuff is separate from the core LDAP functionality itself. >> Eventually I want to use LDAP to store client configuration and there?s a >> lot of useful LDAP functionality stashed away in the user federation stuff. >> >> >> Thank you, >> >> Justin Gross >> >> _______________________________________________ >> 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 Kevin.Fox at pnnl.gov Tue Jun 11 15:20:01 2019 From: Kevin.Fox at pnnl.gov (Fox, Kevin M) Date: Tue, 11 Jun 2019 19:20:01 +0000 Subject: [keycloak-dev] Krb5 direct support Message-ID: <1A3C52DFCD06494D8528644858247BF01C3621F4@EX10MBOX03.pnnl.gov> I've got a public client that I would like to use a direct flow with something similar to the grant_type=password, but instead would like to use kerberos spnego. I did try to edit the password flow to use the krb plugin rather then the password one but it complains about it not being configured, but regular web based krb spnego works fine so the plugin is configured properly. How hard would it be to add a grant_type=krb5 option to the code? Thanks, Kevin From cedric at couralet.eu Wed Jun 12 02:26:22 2019 From: cedric at couralet.eu (=?utf-8?q?cedric=40couralet=2Eeu?=) Date: Wed, 12 Jun 2019 08:26:22 +0200 Subject: [keycloak-dev] =?utf-8?q?Client_Storage_SPI_and_KEYCLOAK-6408?= In-Reply-To: Message-ID: <1bfa-5d009b00-13-83c20e@237995633> In case it could help , for our limited case, we would like the possibility to fetch client configuration from ldap (and secret). Historically, we manage application account (and roles) in ldap. Having keycloak able to retrieve those from ldap would be a huge help. Personnally, I'd like to use keycloak as an orchestrator (very good at that) between different "store", without state. Le Mardi, Juin 11, 2019 12:49 CEST, Stian Thorgersen a ?crit: > We are planning a bigger rework of the storage layer in the future as part > of Keycloak .Next. > > With that in mind you should rather follow the discussion around that as it > unfolds over the next few months. > > For the current implementation we can be open to smaller stuff, but not big > overhauls. > > Finishing the client storage API may be useful, but to be honest not many > people have been interested here. I'd rather see a simpler client store > where it's easier to replace with a custom store. I don't think there's > need to federate multiple client stores for a single realm. > > For LDAP I'm not sure what you mean about separate core and user stuff. It > is only a user store, at least now. Are you perhaps thinking about storing > clients in LDAP? > > On Sat, 8 Jun 2019 at 08:46, Justin Gross wrote: > > > Good afternoon, good evening and good morning everyone! I am Justin and > > I?d like to start contributing to Keycloak. > > > > Is there anyone on the list that is interested in the continuing > > development of Client Storage SPI? (KEYCLOAK-6408 in JIRA) > > > > If you answered yes to the above, what storage systems/software are you > > interested in using for client storage? > > > > Preparing to take on some of the things listed in KEYCLOAK-6408. > > > > I am in the middle of a lite refactoring of some useful things which are > > currently specific to user storage federation such as > > SynchronizationResult, ImportSynchronization, etc? so they can be used by > > the yet to be finished Client Storage API. > > > > I also plan to refactor some of the LDAP federation stuff so that the user > > specific stuff is separate from the core LDAP functionality itself. > > Eventually I want to use LDAP to store client configuration and there?s a > > lot of useful LDAP functionality stashed away in the user federation stuff. > > > > > > Thank you, > > > > Justin Gross > > > > _______________________________________________ > > 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 Wed Jun 12 03:16:26 2019 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 12 Jun 2019 08:16:26 +0100 Subject: [keycloak-dev] Client Storage SPI and KEYCLOAK-6408 In-Reply-To: <0d765eec-900f-2ce7-c4b0-51f036a2a4df@code-house.org> References: <5cfb5959.1c69fb81.fbd17.8ad9@mx.google.com> <0d765eec-900f-2ce7-c4b0-51f036a2a4df@code-house.org> Message-ID: I will share more details around Keycloak Next in a few weeks. Just need to get time to write it up. On Tue, 11 Jun 2019, 18:55 ?ukasz Dywicki, wrote: > Hey Stian, > I track mailing lists from time to time but I see the term > "Keycloak.Next" first time. > Do you have a scope of changes you would like to introduce within next > major release? Perhaps there is an JIRA epic or something where I could > sign in to track progress and horizon of changes? > > All best, > ?ukasz Dywicki > -- > Code-House > http://code-house.org > > > > On 11.06.2019 12:49, Stian Thorgersen wrote: > > We are planning a bigger rework of the storage layer in the future as > part > > of Keycloak .Next. > > > > With that in mind you should rather follow the discussion around that as > it > > unfolds over the next few months. > > > > For the current implementation we can be open to smaller stuff, but not > big > > overhauls. > > > > Finishing the client storage API may be useful, but to be honest not many > > people have been interested here. I'd rather see a simpler client store > > where it's easier to replace with a custom store. I don't think there's > > need to federate multiple client stores for a single realm. > > > > For LDAP I'm not sure what you mean about separate core and user stuff. > It > > is only a user store, at least now. Are you perhaps thinking about > storing > > clients in LDAP? > > > > On Sat, 8 Jun 2019 at 08:46, Justin Gross wrote: > > > >> Good afternoon, good evening and good morning everyone! I am Justin and > >> I?d like to start contributing to Keycloak. > >> > >> Is there anyone on the list that is interested in the continuing > >> development of Client Storage SPI? (KEYCLOAK-6408 in JIRA) > >> > >> If you answered yes to the above, what storage systems/software are you > >> interested in using for client storage? > >> > >> Preparing to take on some of the things listed in KEYCLOAK-6408. > >> > >> I am in the middle of a lite refactoring of some useful things which are > >> currently specific to user storage federation such as > >> SynchronizationResult, ImportSynchronization, etc? so they can be used > by > >> the yet to be finished Client Storage API. > >> > >> I also plan to refactor some of the LDAP federation stuff so that the > user > >> specific stuff is separate from the core LDAP functionality itself. > >> Eventually I want to use LDAP to store client configuration and there?s > a > >> lot of useful LDAP functionality stashed away in the user federation > stuff. > >> > >> > >> Thank you, > >> > >> Justin Gross > >> > >> _______________________________________________ > >> 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 Wed Jun 12 03:17:52 2019 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 12 Jun 2019 08:17:52 +0100 Subject: [keycloak-dev] Client Storage SPI and KEYCLOAK-6408 In-Reply-To: <1bfa-5d009b00-13-83c20e@237995633> References: <1bfa-5d009b00-13-83c20e@237995633> Message-ID: Big question is do you want to store clients in LDAP only or multiple places for a single realm? On Wed, 12 Jun 2019, 07:26 cedric at couralet.eu, wrote: > In case it could help , for our limited case, we would like the > possibility to fetch client configuration from ldap (and secret). > Historically, we manage application account (and roles) in ldap. Having > keycloak able to retrieve those from ldap would be a huge help. > Personnally, I'd like to use keycloak as an orchestrator (very good at > that) between different "store", without state. > > > Le Mardi, Juin 11, 2019 12:49 CEST, Stian Thorgersen > a ?crit: > > > We are planning a bigger rework of the storage layer in the future as > part > > of Keycloak .Next. > > > > With that in mind you should rather follow the discussion around that as > it > > unfolds over the next few months. > > > > For the current implementation we can be open to smaller stuff, but not > big > > overhauls. > > > > Finishing the client storage API may be useful, but to be honest not many > > people have been interested here. I'd rather see a simpler client store > > where it's easier to replace with a custom store. I don't think there's > > need to federate multiple client stores for a single realm. > > > > For LDAP I'm not sure what you mean about separate core and user stuff. > It > > is only a user store, at least now. Are you perhaps thinking about > storing > > clients in LDAP? > > > > On Sat, 8 Jun 2019 at 08:46, Justin Gross wrote: > > > > > Good afternoon, good evening and good morning everyone! I am Justin and > > > I?d like to start contributing to Keycloak. > > > > > > Is there anyone on the list that is interested in the continuing > > > development of Client Storage SPI? (KEYCLOAK-6408 in JIRA) > > > > > > If you answered yes to the above, what storage systems/software are you > > > interested in using for client storage? > > > > > > Preparing to take on some of the things listed in KEYCLOAK-6408. > > > > > > I am in the middle of a lite refactoring of some useful things which > are > > > currently specific to user storage federation such as > > > SynchronizationResult, ImportSynchronization, etc? so they can be used > by > > > the yet to be finished Client Storage API. > > > > > > I also plan to refactor some of the LDAP federation stuff so that the > user > > > specific stuff is separate from the core LDAP functionality itself. > > > Eventually I want to use LDAP to store client configuration and > there?s a > > > lot of useful LDAP functionality stashed away in the user federation > stuff. > > > > > > > > > Thank you, > > > > > > Justin Gross > > > > > > _______________________________________________ > > > 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 andrea.bruehlmann at dvbern.ch Wed Jun 12 07:48:00 2019 From: andrea.bruehlmann at dvbern.ch (=?iso-8859-1?Q?Br=FChlmann_Andrea?=) Date: Wed, 12 Jun 2019 11:48:00 +0000 Subject: [keycloak-dev] 10602 small German translation errors - please review Message-ID: Hi there, I fixed a few German translation errors. See Jira 10602: https://issues.jboss.org/browse/KEYCLOAK-10602 Anyone up for reviewing it? Thanks. Andrea Andrea Br?hlmann Anwendungsentwicklerin DV Bern AG | Nussbaumstrasse 21 | Postfach 106 | CH-3000 Bern 22 T +41 31 378 24 24 | D +41 31 378 24 87 www.dvbern.ch Wir suchen Spezialisten, helfen Sie uns! https://www.dvbern.ch/karriere From cedric at couralet.eu Wed Jun 12 08:09:29 2019 From: cedric at couralet.eu (=?utf-8?q?cedric=40couralet=2Eeu?=) Date: Wed, 12 Jun 2019 14:09:29 +0200 Subject: [keycloak-dev] =?utf-8?q?Client_Storage_SPI_and_KEYCLOAK-6408?= In-Reply-To: Message-ID: <23fc-5d00eb80-15-5258e780@63448353> Not sure I understand your question, I imagine a functionality like for the users ("user federation"), sort of client federation which could use ldap (or other thing). So, it could be multiple places with a "sync registration" feature or not. I realize it is a great deal of change of course. Le Mercredi, Juin 12, 2019 09:17 CEST, Stian Thorgersen a ?crit: > Big question is do you want to store clients in LDAP only or multiple > places for a single realm? > > On Wed, 12 Jun 2019, 07:26 cedric at couralet.eu, wrote: > > > In case it could help , for our limited case, we would like the > > possibility to fetch client configuration from ldap (and secret). > > Historically, we manage application account (and roles) in ldap. Having > > keycloak able to retrieve those from ldap would be a huge help. > > Personnally, I'd like to use keycloak as an orchestrator (very good at > > that) between different "store", without state. > > > > > > Le Mardi, Juin 11, 2019 12:49 CEST, Stian Thorgersen > > a ?crit: > > > > > We are planning a bigger rework of the storage layer in the future as > > part > > > of Keycloak .Next. > > > > > > With that in mind you should rather follow the discussion around that as > > it > > > unfolds over the next few months. > > > > > > For the current implementation we can be open to smaller stuff, but not > > big > > > overhauls. > > > > > > Finishing the client storage API may be useful, but to be honest not many > > > people have been interested here. I'd rather see a simpler client store > > > where it's easier to replace with a custom store. I don't think there's > > > need to federate multiple client stores for a single realm. > > > > > > For LDAP I'm not sure what you mean about separate core and user stuff. > > It > > > is only a user store, at least now. Are you perhaps thinking about > > storing > > > clients in LDAP? > > > > > > On Sat, 8 Jun 2019 at 08:46, Justin Gross wrote: > > > > > > > Good afternoon, good evening and good morning everyone! I am Justin and > > > > I?d like to start contributing to Keycloak. > > > > > > > > Is there anyone on the list that is interested in the continuing > > > > development of Client Storage SPI? (KEYCLOAK-6408 in JIRA) > > > > > > > > If you answered yes to the above, what storage systems/software are you > > > > interested in using for client storage? > > > > > > > > Preparing to take on some of the things listed in KEYCLOAK-6408. > > > > > > > > I am in the middle of a lite refactoring of some useful things which > > are > > > > currently specific to user storage federation such as > > > > SynchronizationResult, ImportSynchronization, etc? so they can be used > > by > > > > the yet to be finished Client Storage API. > > > > > > > > I also plan to refactor some of the LDAP federation stuff so that the > > user > > > > specific stuff is separate from the core LDAP functionality itself. > > > > Eventually I want to use LDAP to store client configuration and > > there?s a > > > > lot of useful LDAP functionality stashed away in the user federation > > stuff. > > > > > > > > > > > > Thank you, > > > > > > > > Justin Gross > > > > > > > > _______________________________________________ > > > > 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 Wed Jun 12 09:06:30 2019 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 12 Jun 2019 15:06:30 +0200 Subject: [keycloak-dev] Client Storage SPI and KEYCLOAK-6408 In-Reply-To: <23fc-5d00eb80-15-5258e780@63448353> References: <23fc-5d00eb80-15-5258e780@63448353> Message-ID: So multiple sources for same realm. Not sure that is a common enough use-case to add as it will of course be much simpler to have a single client store for a realm. On Wed, 12 Jun 2019 at 14:09, cedric at couralet.eu wrote: > Not sure I understand your question, I imagine a functionality like for > the users ("user federation"), sort of client federation which could use > ldap (or other thing). So, it could be multiple places with a "sync > registration" feature or not. I realize it is a great deal of change of > course. > > Le Mercredi, Juin 12, 2019 09:17 CEST, Stian Thorgersen < > sthorger at redhat.com> a ?crit: > > > Big question is do you want to store clients in LDAP only or multiple > > places for a single realm? > > > > On Wed, 12 Jun 2019, 07:26 cedric at couralet.eu, > wrote: > > > > > In case it could help , for our limited case, we would like the > > > possibility to fetch client configuration from ldap (and secret). > > > Historically, we manage application account (and roles) in ldap. > Having > > > keycloak able to retrieve those from ldap would be a huge help. > > > Personnally, I'd like to use keycloak as an orchestrator (very good at > > > that) between different "store", without state. > > > > > > > > > Le Mardi, Juin 11, 2019 12:49 CEST, Stian Thorgersen < > sthorger at redhat.com> > > > a ?crit: > > > > > > > We are planning a bigger rework of the storage layer in the future as > > > part > > > > of Keycloak .Next. > > > > > > > > With that in mind you should rather follow the discussion around > that as > > > it > > > > unfolds over the next few months. > > > > > > > > For the current implementation we can be open to smaller stuff, but > not > > > big > > > > overhauls. > > > > > > > > Finishing the client storage API may be useful, but to be honest not > many > > > > people have been interested here. I'd rather see a simpler client > store > > > > where it's easier to replace with a custom store. I don't think > there's > > > > need to federate multiple client stores for a single realm. > > > > > > > > For LDAP I'm not sure what you mean about separate core and user > stuff. > > > It > > > > is only a user store, at least now. Are you perhaps thinking about > > > storing > > > > clients in LDAP? > > > > > > > > On Sat, 8 Jun 2019 at 08:46, Justin Gross > wrote: > > > > > > > > > Good afternoon, good evening and good morning everyone! I am > Justin and > > > > > I?d like to start contributing to Keycloak. > > > > > > > > > > Is there anyone on the list that is interested in the continuing > > > > > development of Client Storage SPI? (KEYCLOAK-6408 in JIRA) > > > > > > > > > > If you answered yes to the above, what storage systems/software > are you > > > > > interested in using for client storage? > > > > > > > > > > Preparing to take on some of the things listed in KEYCLOAK-6408. > > > > > > > > > > I am in the middle of a lite refactoring of some useful things > which > > > are > > > > > currently specific to user storage federation such as > > > > > SynchronizationResult, ImportSynchronization, etc? so they can be > used > > > by > > > > > the yet to be finished Client Storage API. > > > > > > > > > > I also plan to refactor some of the LDAP federation stuff so that > the > > > user > > > > > specific stuff is separate from the core LDAP functionality itself. > > > > > Eventually I want to use LDAP to store client configuration and > > > there?s a > > > > > lot of useful LDAP functionality stashed away in the user > federation > > > stuff. > > > > > > > > > > > > > > > Thank you, > > > > > > > > > > Justin Gross > > > > > > > > > > _______________________________________________ > > > > > 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 Paolo.Tedesco at cern.ch Thu Jun 13 07:15:43 2019 From: Paolo.Tedesco at cern.ch (Paolo Tedesco) Date: Thu, 13 Jun 2019 11:15:43 +0000 Subject: [keycloak-dev] Customizing usernames Message-ID: <6D320D40264A8545A9C25EC79DE1E32502031D43FB@CERNXCHG41.cern.ch> Hi all, I'm looking for a way to customize the unique identifiers used by Keycloak in its internal user database, to avoid possible email or username clashes. For example, I would like to be able to change the username of someone logging in through github to "login at github.com", so that if someone has the same login in the CERN LDAP the user is not offered the possibility to merge the accounts. Our problems come from the fact that we allow people to change their mail addresses, and also to use external non-CERN addresses as their email, so we cannot rely on email much. We would also like to avoid people to merge accounts at all as we think this might be confusing for users on some occasions, and generate support tickets for us. Is there a supported way to do this, or would we need to code something ourselves? If we need to code something, should we write a plugin of some kind (e.g. custom mappers) or would we need to modify directly the code that manages the login from the identity provider? In case someone else requested something similar, we might make our development available. Thanks, Paolo Tedesco From Leon.Graser at bosch-si.com Thu Jun 13 08:40:26 2019 From: Leon.Graser at bosch-si.com (Graser Leon (INST-CSS/BSV-OS2)) Date: Thu, 13 Jun 2019 12:40:26 +0000 Subject: [keycloak-dev] User Consents via Account REST API In-Reply-To: References: <7cc300612a8f4ec7b71cf0fb7449f081@bosch-si.com> Message-ID: <98d43360bc2a4fca9302b564a06a3945@bosch-si.com> Hi, We created a ticket in the Keycloak Jira https://issues.jboss.org/browse/KEYCLOAK-10653 with some ideas on this issue. Feel free to comment on this. Mit freundlichen Gr??en / Best regards Leon Graser INST-CSS/BSV-OS Tel. +49 30 726112284 | Mobil +49 152 09198324 -----Original Message----- From: keycloak-dev-bounces at lists.jboss.org On Behalf Of Schuster Sebastian (INST-CSS/BSV-OS2) Sent: Freitag, 24. Mai 2019 15:39 To: stian at redhat.com Cc: keycloak-dev Subject: Re: [keycloak-dev] User Consents via Account REST API Will do! Mit freundlichen Gr??en / Best regards Dr.-Ing. Sebastian Schuster Open Source Services (INST-CSS/BSV-OS2) Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn, Dr. Aleksandar Mitrovic Von: Stian Thorgersen Gesendet: Donnerstag, 23. Mai 2019 09:57 An: Schuster Sebastian (INST-CSS/BSV-OS2) Cc: keycloak-dev ; Lanzendoerfer Jonas (AE-EB/ICO2) Betreff: Re: [keycloak-dev] User Consents via Account REST API I assume it's not the third party application that is installing the plugins, but rather some internal user management application? Having a third-party app being able to manage consents would obviously defeat the whole purpose of consent. I don't have any issue with adding endpoints to be able to manage applications and the introduction of fine-grained roles. Fine-grained roles should be added for everything though, not just consents. Also, the applications endpoint does more than just manage consents it also manages offline access to applications, so that needs to be considered. Would be good with a design proposal around this, to continue the discussion there rather than fragmented on the ML. On Wed, 22 May 2019 at 17:02, Schuster Sebastian (INST-CSS/BSV-OS2) > wrote: Hi everybody (and probably especially Stan and Stian), In some of our projects we want to make heavy use of Keycloaks ability to obtain user consent to third parties to access user data in our APIs. In one project, the third parties provide modules that plug into our app and the user should give his consent for this plugin at plugin installation time. We plan to have one client for every plugin so the user can for every plugin decide which scope of backend API access it wants to grant to the plugin. I would be cool if asking for consent would be possible from the app in its UI at the point when the user installs the plugin. To do that, we would like to extend the account REST Api that?s currently in preview state so it a) covers the ?applications? functionality (this is currently a TODO) b) allows to create consents using the REST Api. I am well aware there might be security implications here for clients that are essentially public, e.g. a rogue app could manage consents of a user if he does not pay attention. c) use a finer-grained role model for the accounts service, e.g. at least splitting up view-account into view-profile+view-consents and manage-account into manage-profile+manage-consents so we can control which clients may invoke the consents functionality or we can prevent changing profile attributes that come from an external IDP in our case. What do you think about these changes/additions? Do they make sense? If yes, we would like to contribute them. Thanks and best regards, Sebastian Mit freundlichen Gr??en / Best regards Dr.-Ing. Sebastian Schuster Open Source Services (INST-CSS/BSV-OS2) Bosch Software Innovations GmbH | Ullsteinstr. 128 | 12109 Berlin | GERMANY | www.bosch-si.com Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Fax +49 30 726112-100 | Sebastian.Schuster at bosch-si.com> Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn, Dr. Aleksandar Mitrovic _______________________________________________ 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 Thu Jun 13 08:51:40 2019 From: vramik at redhat.com (Vlasta Ramik) Date: Thu, 13 Jun 2019 14:51:40 +0200 Subject: [keycloak-dev] "You are already logged-in" issue Message-ID: Hi, I'm working on https://issues.jboss.org/browse/KEYCLOAK-5179 See if message "You are already logged-in" can be avoided during authentication. In current state we discard the RootAuthenticationSession when user successfully finishes the authentication. In that moment we loose all the information stored in AuthenticationSession(s) for other tab(s) and in some cases we do not know where to redirect the user. To solve this issue there seems to be 2 possibilities. 1. Do not remove RootAuthenticationSession once the user finishes the authentication. Instead we can remove just AuthenticationSession associated with the specific tab from the RootAuthenticationSession and the RootAuthenticationSession would be deleted together with last AuthenticationSession from it. 2. Add and pass redirect_uri parameter to login flow. With the parameter we'd always have an information where it should be redirected in case the authentication was successfully finished in other tab. With solution #1 it'd increase the memory as it keeps RootAuthenticationSession alive till all tabs are alive. Solution #2 keeps current behavior regarding the authentication sessions but it slightly increases the length of uris. wdyt? From sthorger at redhat.com Thu Jun 13 12:17:21 2019 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 13 Jun 2019 18:17:21 +0200 Subject: [keycloak-dev] "You are already logged-in" issue In-Reply-To: References: Message-ID: Discussed this with Marek a bit and may have a potential solution here. My suggestion is the following: 1. Add a timestamp to a cookie - this timestamp is updated whenever the user makes any action in the authentication session. Basically submitting any form. 2. Add a piece of JS that reads the value of this cookie. If the value changes it will refresh the page. This will hand over the logic of what to do now to the Keycloak server. If username/password was submitted on one tab, the second tab should automatically update and show the next step (or if complete redirect to the client with successful login) 3. Change the client_id param to a more generic state param. This should be a base64 encoded value with the info that we need in case root authentication session is lost (base64(c=&r=(redirect-uri). With having a single param base64 encoded we can more easily add additional info if we need without having to add more query parameters. 4. Root authentication session should not be deleted straight away if there are more child authentication sessions, but rather it should be garbage collected after X mins of inactivity. 5. If root authentication session is garbage collected we should redirect to the client with login error, rather than display error page, with some error message stating failed due to inactivity. The client can then handle it accordingly. On Thu, 13 Jun 2019 at 14:53, Vlasta Ramik wrote: > Hi, > > I'm working on https://issues.jboss.org/browse/KEYCLOAK-5179 See if > message "You are already logged-in" can be avoided during authentication. > > In current state we discard the RootAuthenticationSession when user > successfully finishes the authentication. In that moment we loose all > the information stored in AuthenticationSession(s) for other tab(s) and > in some cases we do not know where to redirect the user. To solve this > issue there seems to be 2 possibilities. > > 1. Do not remove RootAuthenticationSession once the user finishes the > authentication. Instead we can remove just AuthenticationSession > associated with the specific tab from the RootAuthenticationSession and > the RootAuthenticationSession would be deleted together with last > AuthenticationSession from it. > > 2. Add and pass redirect_uri parameter to login flow. With the parameter > we'd always have an information where it should be redirected in case > the authentication was successfully finished in other tab. > > With solution #1 it'd increase the memory as it keeps > RootAuthenticationSession alive till all tabs are alive. > > Solution #2 keeps current behavior regarding the authentication sessions > but it slightly increases the length of uris. > > wdyt? > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From chris.smith at cmfirstgroup.com Thu Jun 13 12:31:52 2019 From: chris.smith at cmfirstgroup.com (Chris Smith) Date: Thu, 13 Jun 2019 16:31:52 +0000 Subject: [keycloak-dev] Custom protocol mapper does not show up in console Message-ID: I'm trying to get my initial protocol mapper to show up in the KC console This is my protocol mapper https://github.com/smitopher/fms-keycloak This is the Jar https://github.com/smitopher/fms-keycloak/blob/master/fms-kerberos.jar It is deployed to /standalone/deployments It does not show up in the console https://github.com/smitopher/fms-keycloak/blob/master/kc-console.jpg Am I missing anything obvious? From sthorger at redhat.com Thu Jun 13 12:35:39 2019 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 13 Jun 2019 18:35:39 +0200 Subject: [keycloak-dev] Customizing usernames In-Reply-To: <6D320D40264A8545A9C25EC79DE1E32502031D43FB@CERNXCHG41.cern.ch> References: <6D320D40264A8545A9C25EC79DE1E32502031D43FB@CERNXCHG41.cern.ch> Message-ID: Could you explain your use-case a bit better? It seems to me that having a unique id as we do for the users today is exactly what you want. We decided to use a unique id rather than the username for exactly the reasons you mention. On Thu, 13 Jun 2019 at 13:19, Paolo Tedesco wrote: > Hi all, > > > > I'm looking for a way to customize the unique identifiers used by Keycloak > in its internal user database, to avoid possible email or username clashes. > > For example, I would like to be able to change the username of someone > logging in through github to "login at github.com", so that if someone has > the same login in the CERN LDAP the user is not offered the possibility to > merge the accounts. > > Our problems come from the fact that we allow people to change their mail > addresses, and also to use external non-CERN addresses as their email, so > we cannot rely on email much. > We would also like to avoid people to merge accounts at all as we think > this might be confusing for users on some occasions, and generate support > tickets for us. > > Is there a supported way to do this, or would we need to code something > ourselves? > If we need to code something, should we write a plugin of some kind (e.g. > custom mappers) or would we need to modify directly the code that manages > the login from the identity provider? > In case someone else requested something similar, we might make our > development available. > > Thanks, > Paolo Tedesco > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From chris.smith at cmfirstgroup.com Thu Jun 13 12:54:23 2019 From: chris.smith at cmfirstgroup.com (Chris Smith) Date: Thu, 13 Jun 2019 16:54:23 +0000 Subject: [keycloak-dev] Custom protocol mapper does not show up in console In-Reply-To: References: Message-ID: After a long and mighty struggle... By inspecting the jar file, it became apparent that an Eclipse jar export is not the thing to do Maven package is the ticket. I then discovered I needed the META-INF/jboss-deployment-structure.xml Now my protocol mapper shows up Right after my desperate plea ;-P From: Chris Smith Sent: Thursday, June 13, 2019 11:32 AM To: keycloak-dev at lists.jboss.org Subject: Custom protocol mapper does not show up in console I'm trying to get my initial protocol mapper to show up in the KC console This is my protocol mapper https://github.com/smitopher/fms-keycloak This is the Jar https://github.com/smitopher/fms-keycloak/blob/master/fms-kerberos.jar It is deployed to /standalone/deployments It does not show up in the console https://github.com/smitopher/fms-keycloak/blob/master/kc-console.jpg Am I missing anything obvious? From Paolo.Tedesco at cern.ch Fri Jun 14 02:33:17 2019 From: Paolo.Tedesco at cern.ch (Paolo Tedesco) Date: Fri, 14 Jun 2019 06:33:17 +0000 Subject: [keycloak-dev] Customizing usernames In-Reply-To: References: <6D320D40264A8545A9C25EC79DE1E32502031D43FB@CERNXCHG41.cern.ch> Message-ID: <6D320D40264A8545A9C25EC79DE1E32502031D477C@CERNXCHG41.cern.ch> Hi Stian, We want to avoid that users are presented with the "account already exists" dialogue and the option to merge accounts, because we think that it wouldn't always be clear for users what is going on. We managed to turn off the unique email validation, but then, for what we understood, we need to have unique usernames. Maybe we are just missing something, then how do we configure unique IDs (which are not mail addresses) instead of usernames? Thanks, Paolo From: Stian Thorgersen Sent: Thursday, June 13, 2019 18:36 To: Paolo Tedesco Cc: keycloak-dev at lists.jboss.org; Cristian Schuszter ; Asier Aguado Corman ; Hannah Short Subject: Re: [keycloak-dev] Customizing usernames Could you explain your use-case a bit better? It seems to me that having a unique id as we do for the users today is exactly what you want. We decided to use a unique id rather than the username for exactly the reasons you mention. On Thu, 13 Jun 2019 at 13:19, Paolo Tedesco > wrote: Hi all, I'm looking for a way to customize the unique identifiers used by Keycloak in its internal user database, to avoid possible email or username clashes. For example, I would like to be able to change the username of someone logging in through github to "login at github.com", so that if someone has the same login in the CERN LDAP the user is not offered the possibility to merge the accounts. Our problems come from the fact that we allow people to change their mail addresses, and also to use external non-CERN addresses as their email, so we cannot rely on email much. We would also like to avoid people to merge accounts at all as we think this might be confusing for users on some occasions, and generate support tickets for us. Is there a supported way to do this, or would we need to code something ourselves? If we need to code something, should we write a plugin of some kind (e.g. custom mappers) or would we need to modify directly the code that manages the login from the identity provider? In case someone else requested something similar, we might make our development available. Thanks, Paolo Tedesco _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From Daniel.Martin at digital.homeoffice.gov.uk Fri Jun 14 08:04:37 2019 From: Daniel.Martin at digital.homeoffice.gov.uk (Daniel Martin) Date: Fri, 14 Jun 2019 12:04:37 +0000 Subject: [keycloak-dev] keycloak-gatekeeper - Cookies being applied to subdomains Message-ID: Hi, I believe there is a bug in the keycloak-gatekeeper in that when it sets cookies they apply to the subdomains of the host. This causes any other services on those subdomains that are running keycloak-gatekeeper to fail when the cookie is present. For example, let's say we are running keycloak-gatekeeper on the following URLs: 1. mydomain.com 2. sub.mydomain.com If a user logs in to mydomain.com and then tries to visit sub.mydomain.com the service will fail (infinite redirect loop) as the cookie from the first service will be applied to the second service. In terms of the cookie, the problem is caused by this piece of code: https://github.com/keycloak/keycloak-gatekeeper/blob/master/cookies.go#L30-L34 If you read section 4.1.2.3 of https://tools.ietf.org/html/rfc6265#section-4.1.2 it implies that if you set the 'Domain' attribute in that fashion it will propagate down to subdomains. It seems that to prevent this the 'Domain' attribute should simply be omitted. I've created a PR for this here: https://github.com/keycloak/keycloak-gatekeeper/pull/480 Do you agree? If so, can we get this fix merged? Best regards, Daniel Martin. Please ensure that any communication with the Home Office is via an official account ending with digital.homeoffice.gov.uk or homeoffice.gsi.gov.uk. This email and any files transmitted with it are private and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please return it to the address it came from telling them it is not for you and then delete it from your system. Communications via the digital.homeoffice.gov.uk domain may be automatically logged, monitored and/or recorded for legal purposes. This email message has been swept for computer viruses. From mposolda at redhat.com Fri Jun 14 11:53:41 2019 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 14 Jun 2019 17:53:41 +0200 Subject: [keycloak-dev] "You are already logged-in" issue In-Reply-To: References: Message-ID: <02f9c10b-b2e8-2cb9-0eb7-412580514ca0@redhat.com> Thinking more about this and have some more points inline. Dne 13. 06. 19 v 18:17 Stian Thorgersen napsal(a): > Discussed this with Marek a bit and may have a potential solution here. > > My suggestion is the following: > > 1. Add a timestamp to a cookie - this timestamp is updated whenever the > user makes any action in the authentication session. Basically submitting > any form. > 2. Add a piece of JS that reads the value of this cookie. If the value > changes it will refresh the page. This will hand over the logic of what to > do now to the Keycloak server. If username/password was submitted on one > tab, the second tab should automatically update and show the next step (or > if complete redirect to the client with successful login) So just to clarify, this would also mean that we will track the "authentication state" informations (executions, authNotes, requiredActions etc) per RootAuthenticationSession, not per AuthenticationSession. Correct? Because authentication state will be shared per whole browser, not per individual tabs as it is now. So just the "client state" will need to be shared per individual tabs. ATM I am not seeing any reason why it won't work. But it will require some more refactoring... > 3. Change the client_id param to a more generic state param. This should be > a base64 encoded value with the info that we need in case root > authentication session is lost (base64(c=&r=(redirect-uri). With > having a single param base64 encoded we can more easily add additional info > if we need without having to add more query parameters. I wonder that if instead of just clientId + redirectUri, we can add the parameter, which will contain all the client informations encoded in the JWS token? Something similar/same like current KC_RESTART cookie, which is JWS encapsulating all the client state sent from the OIDC or SAML client. The advantages of this approach: - Less informations on the server side. Especially with the "authentication state" shared globally per rootAuthSession and with the "client state" in the parameter, we "usually" (see below for why word "usually") won't need to track any state on the server side. So we will be "usually" able to remove RootAuthSession directly after authentication finished as it's now. - We will be able to remove KC_RESTART cookie. This cookie is not very great anyway as it encapsulates info just from the single browser tab - Less probability of redirecting to the client with the error as all the client info are available in the token param. Disadvantage: - There are some cases that client info in the JWT will be bigger than 2000 characters limit [1]. In that case, we will need to fallback and will still need to track the client info somewhere else that in the request parameter. Either on server side (hence still a need to have the list of AuthenticationSessions attached to RootAuthSession) or per the cookie, which is not limited in the size. The support for the fallback will require some more refactoring... [1] https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers Marek > 4. Root authentication session should not be deleted straight away if there > are more child authentication sessions, but rather it should be garbage > collected after X mins of inactivity. > 5. If root authentication session is garbage collected we should redirect > to the client with login error, rather than display error page, with some > error message stating failed due to inactivity. The client can then handle > it accordingly. > > On Thu, 13 Jun 2019 at 14:53, Vlasta Ramik wrote: > >> Hi, >> >> I'm working on https://issues.jboss.org/browse/KEYCLOAK-5179 See if >> message "You are already logged-in" can be avoided during authentication. >> >> In current state we discard the RootAuthenticationSession when user >> successfully finishes the authentication. In that moment we loose all >> the information stored in AuthenticationSession(s) for other tab(s) and >> in some cases we do not know where to redirect the user. To solve this >> issue there seems to be 2 possibilities. >> >> 1. Do not remove RootAuthenticationSession once the user finishes the >> authentication. Instead we can remove just AuthenticationSession >> associated with the specific tab from the RootAuthenticationSession and >> the RootAuthenticationSession would be deleted together with last >> AuthenticationSession from it. >> >> 2. Add and pass redirect_uri parameter to login flow. With the parameter >> we'd always have an information where it should be redirected in case >> the authentication was successfully finished in other tab. >> >> With solution #1 it'd increase the memory as it keeps >> RootAuthenticationSession alive till all tabs are alive. >> >> Solution #2 keeps current behavior regarding the authentication sessions >> but it slightly increases the length of uris. >> >> wdyt? >> >> >> >> _______________________________________________ >> 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 14 12:01:18 2019 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 14 Jun 2019 18:01:18 +0200 Subject: [keycloak-dev] Customizing usernames In-Reply-To: <6D320D40264A8545A9C25EC79DE1E32502031D477C@CERNXCHG41.cern.ch> References: <6D320D40264A8545A9C25EC79DE1E32502031D43FB@CERNXCHG41.cern.ch> <6D320D40264A8545A9C25EC79DE1E32502031D477C@CERNXCHG41.cern.ch> Message-ID: <0618c636-d59b-82ca-dd18-2ddbea51d9e4@redhat.com> I think that for this, you can use "Username Template" importer. It is the IdentityProvider mapper. After creating Identity Provider, you can click to tab "Mappers" and configure it here. Just a note that with this approach, you will end with duplicated keycloak accounts for someone, who may be same person. Another possibility is to tweak the "First Broker Login" flow and tweak authenticators. For example automatically merge accounts without prompting (But this option has some security implications, see docs for the details). If you have some recommendations for the usability of the default dialog, feel free to suggest here. But IMO having both the "automerging accounts" or "duplicated accounts" is problematic and hence we have the option of asking users for merge accounts OOTB. Marek Dne 14. 06. 19 v 8:33 Paolo Tedesco napsal(a): > Hi Stian, > > We want to avoid that users are presented with the "account already exists" dialogue and the option to merge accounts, because we think that it wouldn't always be clear for users what is going on. > We managed to turn off the unique email validation, but then, for what we understood, we need to have unique usernames. > Maybe we are just missing something, then how do we configure unique IDs (which are not mail addresses) instead of usernames? > > Thanks, > Paolo > > From: Stian Thorgersen > Sent: Thursday, June 13, 2019 18:36 > To: Paolo Tedesco > Cc: keycloak-dev at lists.jboss.org; Cristian Schuszter ; Asier Aguado Corman ; Hannah Short > Subject: Re: [keycloak-dev] Customizing usernames > > Could you explain your use-case a bit better? It seems to me that having a unique id as we do for the users today is exactly what you want. We decided to use a unique id rather than the username for exactly the reasons you mention. > > On Thu, 13 Jun 2019 at 13:19, Paolo Tedesco > wrote: > Hi all, > > > > I'm looking for a way to customize the unique identifiers used by Keycloak in its internal user database, to avoid possible email or username clashes. > > For example, I would like to be able to change the username of someone logging in through github to "login at github.com", so that if someone has the same login in the CERN LDAP the user is not offered the possibility to merge the accounts. > > Our problems come from the fact that we allow people to change their mail addresses, and also to use external non-CERN addresses as their email, so we cannot rely on email much. > We would also like to avoid people to merge accounts at all as we think this might be confusing for users on some occasions, and generate support tickets for us. > > Is there a supported way to do this, or would we need to code something ourselves? > If we need to code something, should we write a plugin of some kind (e.g. custom mappers) or would we need to modify directly the code that manages the login from the identity provider? > In case someone else requested something similar, we might make our development available. > > Thanks, > Paolo Tedesco > > _______________________________________________ > 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 bruno at abstractj.org Fri Jun 14 14:45:25 2019 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 14 Jun 2019 15:45:25 -0300 Subject: [keycloak-dev] keycloak-gatekeeper - Cookies being applied to subdomains In-Reply-To: References: Message-ID: <20190614184524.GB29177@abstractj.org> Hi Daniel, thanks for reporting this. As we discussed on that PR, please file a Jira adding the steps to reproduce, affected version and everything that's recommended in the contribution guidelines. So we can start to look at the issue. At first glance, it looks like a bug. On 2019-06-14, Daniel Martin wrote: > Hi, > > I believe there is a bug in the keycloak-gatekeeper in that when it sets cookies they apply to the subdomains of the host. This causes any other services on those subdomains that are running keycloak-gatekeeper to fail when the cookie is present. > > For example, let's say we are running keycloak-gatekeeper on the following URLs: > > 1. mydomain.com > 2. sub.mydomain.com > > If a user logs in to mydomain.com and then tries to visit sub.mydomain.com the service will fail (infinite redirect loop) as the cookie from the first service will be applied to the second service. > > In terms of the cookie, the problem is caused by this piece of code: https://github.com/keycloak/keycloak-gatekeeper/blob/master/cookies.go#L30-L34 > > If you read section 4.1.2.3 of https://tools.ietf.org/html/rfc6265#section-4.1.2 it implies that if you set the 'Domain' attribute in that fashion it will propagate down to subdomains. > > It seems that to prevent this the 'Domain' attribute should simply be omitted. > > I've created a PR for this here: https://github.com/keycloak/keycloak-gatekeeper/pull/480 > > Do you agree? If so, can we get this fix merged? > > Best regards, > > > Daniel Martin. > > Please ensure that any communication with the Home Office is via an official account ending with digital.homeoffice.gov.uk or homeoffice.gsi.gov.uk. This email and any files transmitted with it are private and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please return it to the address it came from telling them it is not for you and then delete it from your system. Communications via the digital.homeoffice.gov.uk domain may be automatically logged, monitored and/or recorded for legal purposes. This email message has been swept for computer viruses. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- abstractj From chris.smith at cmfirstgroup.com Fri Jun 14 17:24:09 2019 From: chris.smith at cmfirstgroup.com (Chris Smith) Date: Fri, 14 Jun 2019 21:24:09 +0000 Subject: [keycloak-dev] Putting a value into a custom Protocol mapper Message-ID: I'm trying to have a custom protocol mapper provide a serialized Kerberos ticket as a claim I have updated the KerberosUsernamePasswordAuthenticator so that it gets the ticket public Subject authenticateSubject(String username, String password) throws LoginException { String principal = getKerberosPrincipal(username); logger.debug("Validating password of principal: " + principal); loginContext = new LoginContext("does-not-matter", null, createJaasCallbackHandler(principal, password), createJaasConfiguration()); loginContext.login(); serializedKerberosTicket = serializeTicket(); logger.debug("Principal " + principal + " authenticated succesfully"); return loginContext.getSubject(); } private String serializeTicket() { KerberosTicket kerberosTicket = loginContext.getSubject() .getPrivateCredentials(KerberosTicket.class) .stream().findFirst().get(); try (ByteArrayOutputStream bos = new ByteArrayOutputStream(); ObjectOutputStream oos = new ObjectOutputStream(bos)){ oos.writeObject(kerberosTicket); return Base64.getEncoder().encodeToString(bos.toByteArray()); } catch (IOException e) { logger.error("Kerberos ticket serialization failed", e); return null; } } I reviewed the SPNEGOAuthenticator and traced it's execution to see how it adds the Kerberos ticket and I do not see that as a workable approach as it is so different from the Kerberos User/Password authenticator. Where can my custom KerberosUsernamePasswordAuthenticator put the serialized ticket so that my custom protocol mapper will get it and add it as a claim on my Access token? I have looked and googled with no luck. From sthorger at redhat.com Sun Jun 16 04:18:09 2019 From: sthorger at redhat.com (Stian Thorgersen) Date: Sun, 16 Jun 2019 10:18:09 +0200 Subject: [keycloak-dev] "You are already logged-in" issue In-Reply-To: <02f9c10b-b2e8-2cb9-0eb7-412580514ca0@redhat.com> References: <02f9c10b-b2e8-2cb9-0eb7-412580514ca0@redhat.com> Message-ID: On Fri, 14 Jun 2019 at 17:53, Marek Posolda wrote: > Thinking more about this and have some more points inline. > > Dne 13. 06. 19 v 18:17 Stian Thorgersen napsal(a): > > Discussed this with Marek a bit and may have a potential solution here. > > > > My suggestion is the following: > > > > 1. Add a timestamp to a cookie - this timestamp is updated whenever the > > user makes any action in the authentication session. Basically submitting > > any form. > > 2. Add a piece of JS that reads the value of this cookie. If the value > > changes it will refresh the page. This will hand over the logic of what > to > > do now to the Keycloak server. If username/password was submitted on one > > tab, the second tab should automatically update and show the next step > (or > > if complete redirect to the client with successful login) > So just to clarify, this would also mean that we will track the > "authentication state" informations (executions, authNotes, > requiredActions etc) per RootAuthenticationSession, not per > AuthenticationSession. Correct? Because authentication state will be > shared per whole browser, not per individual tabs as it is now. So just > the "client state" will need to be shared per individual tabs. > > ATM I am not seeing any reason why it won't work. But it will require > some more refactoring... Yes, we'd need to share the authentication state across multiple tabs > > 3. Change the client_id param to a more generic state param. This should > be > > a base64 encoded value with the info that we need in case root > > authentication session is lost (base64(c=&r=(redirect-uri). > With > > having a single param base64 encoded we can more easily add additional > info > > if we need without having to add more query parameters. > I wonder that if instead of just clientId + redirectUri, we can add the > parameter, which will contain all the client informations encoded in the > JWS token? Something similar/same like current KC_RESTART cookie, which > is JWS encapsulating all the client state sent from the OIDC or SAML > client. The advantages of this approach: > > - Less informations on the server side. Especially with the > "authentication state" shared globally per rootAuthSession and with the > "client state" in the parameter, we "usually" (see below for why word > "usually") won't need to track any state on the server side. So we will > be "usually" able to remove RootAuthSession directly after > authentication finished as it's now. > > - We will be able to remove KC_RESTART cookie. This cookie is not very > great anyway as it encapsulates info just from the single browser tab > > - Less probability of redirecting to the client with the error as all > the client info are available in the token param. > > > Disadvantage: > - There are some cases that client info in the JWT will be bigger than > 2000 characters limit [1]. In that case, we will need to fallback and > will still need to track the client info somewhere else that in the > request parameter. Either on server side (hence still a need to have the > list of AuthenticationSessions attached to RootAuthSession) or per the > cookie, which is not limited in the size. The support for the fallback > will require some more refactoring... > It's slightly more complicated to keep all state in a JWT, but probably ideal at least when the session isn't too big. Perhaps we could do the fallover thing we discussed in the past. As long as JWT is smaller than 2KB we just add it to a cookie, but if it gets to big we add a reference in the cookie and store the values server side in a session. Would be worth trying to think this one through properly and see if we can solve this once and for all. > > [1] > > https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers > > Marek > > 4. Root authentication session should not be deleted straight away if > there > > are more child authentication sessions, but rather it should be garbage > > collected after X mins of inactivity. > > 5. If root authentication session is garbage collected we should redirect > > to the client with login error, rather than display error page, with some > > error message stating failed due to inactivity. The client can then > handle > > it accordingly. > > > > On Thu, 13 Jun 2019 at 14:53, Vlasta Ramik wrote: > > > >> Hi, > >> > >> I'm working on https://issues.jboss.org/browse/KEYCLOAK-5179 See if > >> message "You are already logged-in" can be avoided during > authentication. > >> > >> In current state we discard the RootAuthenticationSession when user > >> successfully finishes the authentication. In that moment we loose all > >> the information stored in AuthenticationSession(s) for other tab(s) and > >> in some cases we do not know where to redirect the user. To solve this > >> issue there seems to be 2 possibilities. > >> > >> 1. Do not remove RootAuthenticationSession once the user finishes the > >> authentication. Instead we can remove just AuthenticationSession > >> associated with the specific tab from the RootAuthenticationSession and > >> the RootAuthenticationSession would be deleted together with last > >> AuthenticationSession from it. > >> > >> 2. Add and pass redirect_uri parameter to login flow. With the parameter > >> we'd always have an information where it should be redirected in case > >> the authentication was successfully finished in other tab. > >> > >> With solution #1 it'd increase the memory as it keeps > >> RootAuthenticationSession alive till all tabs are alive. > >> > >> Solution #2 keeps current behavior regarding the authentication sessions > >> but it slightly increases the length of uris. > >> > >> wdyt? > >> > >> > >> > >> _______________________________________________ > >> 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 Daniel.Martin at digital.homeoffice.gov.uk Mon Jun 17 12:41:19 2019 From: Daniel.Martin at digital.homeoffice.gov.uk (Daniel Martin) Date: Mon, 17 Jun 2019 16:41:19 +0000 Subject: [keycloak-dev] keycloak-gatekeeper - Cookies being applied to subdomains In-Reply-To: <20190614184524.GB29177@abstractj.org> References: , <20190614184524.GB29177@abstractj.org> Message-ID: Hi Bruno, I've created at JIRA at https://issues.jboss.org/browse/KEYCLOAK-10668 and updated the PR to reference it. Best regards, Daniel. ________________________________ From: Bruno Oliveira Sent: 14 June 2019 19:45 To: Daniel Martin Cc: keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] keycloak-gatekeeper - Cookies being applied to subdomains Hi Daniel, thanks for reporting this. As we discussed on that PR, please file a Jira adding the steps to reproduce, affected version and everything that's recommended in the contribution guidelines. So we can start to look at the issue. At first glance, it looks like a bug. On 2019-06-14, Daniel Martin wrote: > Hi, > > I believe there is a bug in the keycloak-gatekeeper in that when it sets cookies they apply to the subdomains of the host. This causes any other services on those subdomains that are running keycloak-gatekeeper to fail when the cookie is present. > > For example, let's say we are running keycloak-gatekeeper on the following URLs: > > 1. mydomain.com > 2. sub.mydomain.com > > If a user logs in to mydomain.com and then tries to visit sub.mydomain.com the service will fail (infinite redirect loop) as the cookie from the first service will be applied to the second service. > > In terms of the cookie, the problem is caused by this piece of code: https://github.com/keycloak/keycloak-gatekeeper/blob/master/cookies.go#L30-L34 > > If you read section 4.1.2.3 of https://tools.ietf.org/html/rfc6265#section-4.1.2 it implies that if you set the 'Domain' attribute in that fashion it will propagate down to subdomains. > > It seems that to prevent this the 'Domain' attribute should simply be omitted. > > I've created a PR for this here: https://github.com/keycloak/keycloak-gatekeeper/pull/480 > > Do you agree? If so, can we get this fix merged? > > Best regards, > > > Daniel Martin. > > Please ensure that any communication with the Home Office is via an official account ending with digital.homeoffice.gov.uk or homeoffice.gsi.gov.uk. This email and any files transmitted with it are private and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please return it to the address it came from telling them it is not for you and then delete it from your system. Communications via the digital.homeoffice.gov.uk domain may be automatically logged, monitored and/or recorded for legal purposes. This email message has been swept for computer viruses. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- abstractj Please ensure that any communication with the Home Office is via an official account ending with digital.homeoffice.gov.uk or homeoffice.gsi.gov.uk. This email and any files transmitted with it are private and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please return it to the address it came from telling them it is not for you and then delete it from your system. Communications via the digital.homeoffice.gov.uk domain may be automatically logged, monitored and/or recorded for legal purposes. This email message has been swept for computer viruses. From chris.smith at cmfirstgroup.com Mon Jun 17 18:14:30 2019 From: chris.smith at cmfirstgroup.com (Chris Smith) Date: Mon, 17 Jun 2019 22:14:30 +0000 Subject: [keycloak-dev] Putting a value into a custom Protocol mapper In-Reply-To: References: Message-ID: I really need some help here I can not find out how to add a Claim after a successful Kerberos User/Password login This is as far as I know what is going on. This is in the LDAPStorageProvider class. The KerberosUsernamePasswordAuthenticator has been updated to hold the serialized Kerberos ticket. I now need to put this somewhere/somehow so that my custom Protocol mapper will put it into the Access Token public boolean validPassword(RealmModel realm, UserModel user, String password) { if (kerberosConfig.isAllowKerberosAuthentication() && kerberosConfig.isUseKerberosForPasswordAuthentication()) { // Use Kerberos JAAS (Krb5LoginModule) Map state = new HashMap<>(); KerberosUsernamePasswordAuthenticator authenticator = factory.createKerberosUsernamePasswordAuthenticator(kerberosConfig); boolean isValidUser = authenticator.validUser(user.getUsername(), password); if (isValidUser) { String delegationCredential = authenticator.getSerializedKerberosTicket(); if (delegationCredential != null) { state.put(KerberosConstants.GSS_DELEGATION_CREDENTIAL, delegationCredential); } << WHAT GOES HERE?? >> return isValidUser; This is from my servlet KeycloakPrincipal kcp = (KeycloakPrincipal)request.getUserPrincipal(); AccessToken at = kcp.getKeycloakSecurityContext().getToken(); Map otherClaims = at.getOtherClaims(); String otherClaim = (String)otherClaims.get("odic-fms-sso-kerberos-ticket-mapper"); GSSCredential gssCredential = KerberosSerializationUtils.deserializeCredential(otherClaim); From: Chris Smith Sent: Friday, June 14, 2019 4:24 PM To: keycloak-dev at lists.jboss.org Subject: Putting a value into a custom Protocol mapper I'm trying to have a custom protocol mapper provide a serialized Kerberos ticket as a claim I have updated the KerberosUsernamePasswordAuthenticator so that it gets the ticket public Subject authenticateSubject(String username, String password) throws LoginException { String principal = getKerberosPrincipal(username); logger.debug("Validating password of principal: " + principal); loginContext = new LoginContext("does-not-matter", null, createJaasCallbackHandler(principal, password), createJaasConfiguration()); loginContext.login(); serializedKerberosTicket = serializeTicket(); logger.debug("Principal " + principal + " authenticated succesfully"); return loginContext.getSubject(); } private String serializeTicket() { KerberosTicket kerberosTicket = loginContext.getSubject() .getPrivateCredentials(KerberosTicket.class) .stream().findFirst().get(); try (ByteArrayOutputStream bos = new ByteArrayOutputStream(); ObjectOutputStream oos = new ObjectOutputStream(bos)){ oos.writeObject(kerberosTicket); return Base64.getEncoder().encodeToString(bos.toByteArray()); } catch (IOException e) { logger.error("Kerberos ticket serialization failed", e); return null; } } I reviewed the SPNEGOAuthenticator and traced it's execution to see how it adds the Kerberos ticket and I do not see that as a workable approach as it is so different from the Kerberos User/Password authenticator. Where can my custom KerberosUsernamePasswordAuthenticator put the serialized ticket so that my custom protocol mapper will get it and add it as a claim on my Access token? I have looked and googled with no luck. From chris.smith at cmfirstgroup.com Mon Jun 17 18:37:37 2019 From: chris.smith at cmfirstgroup.com (Chris Smith) Date: Mon, 17 Jun 2019 22:37:37 +0000 Subject: [keycloak-dev] Putting a value into a custom Protocol mapper In-Reply-To: References: Message-ID: correction From: Chris Smith Sent: Monday, June 17, 2019 5:15 PM To: keycloak-dev at lists.jboss.org; Marek Posolda Subject: RE: Putting a value into a custom Protocol mapper I really need some help here I can not find out how to add a Claim after a successful Kerberos User/Password login This is as far as I know what is going on. This is in the LDAPStorageProvider class. The KerberosUsernamePasswordAuthenticator has been updated to hold the serialized Kerberos ticket. I now need to put this somewhere/somehow so that my custom Protocol mapper will put it into the Access Token public boolean validPassword(RealmModel realm, UserModel user, String password) { if (kerberosConfig.isAllowKerberosAuthentication() && kerberosConfig.isUseKerberosForPasswordAuthentication()) { // Use Kerberos JAAS (Krb5LoginModule) Map state = new HashMap<>(); KerberosUsernamePasswordAuthenticator authenticator = factory.createKerberosUsernamePasswordAuthenticator(kerberosConfig); boolean isValidUser = authenticator.validUser(user.getUsername(), password); if (isValidUser) { String delegationCredential = authenticator.getSerializedKerberosTicket(); if (delegationCredential != null) { state.put("odic-fms-sso-kerberos-ticket-mapper", delegationCredential); } << WHAT GOES HERE?? >> return isValidUser; This is from my servlet KeycloakPrincipal kcp = (KeycloakPrincipal)request.getUserPrincipal(); AccessToken at = kcp.getKeycloakSecurityContext().getToken(); Map otherClaims = at.getOtherClaims(); String otherClaim = (String)otherClaims.get("odic-fms-sso-kerberos-ticket-mapper"); GSSCredential gssCredential = KerberosSerializationUtils.deserializeCredential(otherClaim); From: Chris Smith Sent: Friday, June 14, 2019 4:24 PM To: keycloak-dev at lists.jboss.org Subject: Putting a value into a custom Protocol mapper I'm trying to have a custom protocol mapper provide a serialized Kerberos ticket as a claim I have updated the KerberosUsernamePasswordAuthenticator so that it gets the ticket public Subject authenticateSubject(String username, String password) throws LoginException { String principal = getKerberosPrincipal(username); logger.debug("Validating password of principal: " + principal); loginContext = new LoginContext("does-not-matter", null, createJaasCallbackHandler(principal, password), createJaasConfiguration()); loginContext.login(); serializedKerberosTicket = serializeTicket(); logger.debug("Principal " + principal + " authenticated succesfully"); return loginContext.getSubject(); } private String serializeTicket() { KerberosTicket kerberosTicket = loginContext.getSubject() .getPrivateCredentials(KerberosTicket.class) .stream().findFirst().get(); try (ByteArrayOutputStream bos = new ByteArrayOutputStream(); ObjectOutputStream oos = new ObjectOutputStream(bos)){ oos.writeObject(kerberosTicket); return Base64.getEncoder().encodeToString(bos.toByteArray()); } catch (IOException e) { logger.error("Kerberos ticket serialization failed", e); return null; } } I reviewed the SPNEGOAuthenticator and traced it's execution to see how it adds the Kerberos ticket and I do not see that as a workable approach as it is so different from the Kerberos User/Password authenticator. Where can my custom KerberosUsernamePasswordAuthenticator put the serialized ticket so that my custom protocol mapper will get it and add it as a claim on my Access token? I have looked and googled with no luck. From sthorger at redhat.com Tue Jun 18 03:44:41 2019 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 18 Jun 2019 09:44:41 +0200 Subject: [keycloak-dev] Latest documentation not showing on Google Message-ID: For some reason our latest documentation is not showing on Google. This issue started happening when we changed the toolset for our docs. Does anyone have any clue why this is happening and what we can do to resolve this? From Paolo.Tedesco at cern.ch Tue Jun 18 07:49:35 2019 From: Paolo.Tedesco at cern.ch (Paolo Tedesco) Date: Tue, 18 Jun 2019 11:49:35 +0000 Subject: [keycloak-dev] Customizing usernames In-Reply-To: <0618c636-d59b-82ca-dd18-2ddbea51d9e4@redhat.com> References: <6D320D40264A8545A9C25EC79DE1E32502031D43FB@CERNXCHG41.cern.ch> <6D320D40264A8545A9C25EC79DE1E32502031D477C@CERNXCHG41.cern.ch> <0618c636-d59b-82ca-dd18-2ddbea51d9e4@redhat.com> Message-ID: <6D320D40264A8545A9C25EC79DE1E32502031D521C@CERNXCHG41.cern.ch> Hi Marek, Thanks a lot for your reply, we were trying to configure this with the Github provider, which allows less customization in the mappers. The username template mapper looks exactly like what we need, but we don't manage to configure a generic OpenID connect Identity Provider to work with Github. We get an error saying "could not decode access token response". It seems that Github by default return something like this in the token URL access_token=e72e16c7e42f292c6912e7710c838347ae178b4a&token_type=bearer and the identity provider tries to parse it as a JWT. Is it possible to configure github as a generic OpenID connect IDP? Thanks, Paolo -----Original Message----- From: Marek Posolda Sent: Friday, June 14, 2019 18:01 To: Paolo Tedesco ; stian at redhat.com Cc: keycloak-dev at lists.jboss.org; Asier Aguado Corman ; Hannah Short ; Cristian Schuszter Subject: Re: [keycloak-dev] Customizing usernames I think that for this, you can use "Username Template" importer. It is the IdentityProvider mapper. After creating Identity Provider, you can click to tab "Mappers" and configure it here. Just a note that with this approach, you will end with duplicated keycloak accounts for someone, who may be same person. Another possibility is to tweak the "First Broker Login" flow and tweak authenticators. For example automatically merge accounts without prompting (But this option has some security implications, see docs for the details). If you have some recommendations for the usability of the default dialog, feel free to suggest here. But IMO having both the "automerging accounts" or "duplicated accounts" is problematic and hence we have the option of asking users for merge accounts OOTB. Marek Dne 14. 06. 19 v 8:33 Paolo Tedesco napsal(a): > Hi Stian, > > We want to avoid that users are presented with the "account already exists" dialogue and the option to merge accounts, because we think that it wouldn't always be clear for users what is going on. > We managed to turn off the unique email validation, but then, for what we understood, we need to have unique usernames. > Maybe we are just missing something, then how do we configure unique IDs (which are not mail addresses) instead of usernames? > > Thanks, > Paolo > > From: Stian Thorgersen > Sent: Thursday, June 13, 2019 18:36 > To: Paolo Tedesco > Cc: keycloak-dev at lists.jboss.org; Cristian Schuszter > ; Asier Aguado Corman > ; Hannah Short > Subject: Re: [keycloak-dev] Customizing usernames > > Could you explain your use-case a bit better? It seems to me that having a unique id as we do for the users today is exactly what you want. We decided to use a unique id rather than the username for exactly the reasons you mention. > > On Thu, 13 Jun 2019 at 13:19, Paolo Tedesco > wrote: > Hi all, > > > > I'm looking for a way to customize the unique identifiers used by Keycloak in its internal user database, to avoid possible email or username clashes. > > For example, I would like to be able to change the username of someone logging in through github to "login at github.com", so that if someone has the same login in the CERN LDAP the user is not offered the possibility to merge the accounts. > > Our problems come from the fact that we allow people to change their mail addresses, and also to use external non-CERN addresses as their email, so we cannot rely on email much. > We would also like to avoid people to merge accounts at all as we think this might be confusing for users on some occasions, and generate support tickets for us. > > Is there a supported way to do this, or would we need to code something ourselves? > If we need to code something, should we write a plugin of some kind (e.g. custom mappers) or would we need to modify directly the code that manages the login from the identity provider? > In case someone else requested something similar, we might make our development available. > > Thanks, > Paolo Tedesco > > _______________________________________________ > 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 contributing.to.keycloak at gmail.com Wed Jun 19 08:04:48 2019 From: contributing.to.keycloak at gmail.com (Roland) Date: Wed, 19 Jun 2019 14:04:48 +0200 Subject: [keycloak-dev] Add SAML Extensions (and AuthContext) as another client note to the AuthenticationSessionModel in SamlService Message-ID: Hello, when a SAML Request is received in Keycloak, the method loginRequest in abstract class BindingProtocol in class org.keycloak.protocol.samlSamlService puts the information from the request into the AuthenticationSessionModel in this section of code: authSession.setProtocol(SamlProtocol.LOGIN_PROTOCOL); authSession.setRedirectUri(redirect); authSession.setAction( AuthenticationSessionModel.Action.AUTHENTICATE.name()); authSession.setClientNote(SamlProtocol.SAML_BINDING, bindingType); authSession.setClientNote(GeneralConstants.RELAY_STATE, relayState); authSession.setClientNote(SamlProtocol.SAML_REQUEST_ID, requestAbstractType.getID()); What we are missing here is the SAML Extensions, which happen to be in the SAML Request which we receive, and which we want to pass on to a brokered external Identity Provider. For example something like this: ExtensionsType et = requestAbstractType.getExtensions(); List list = et.getAny(); authSession.setAuthNote("SAML_EXTENSION", ); In the same way we would also like access to the AuthContext through the authSession. I would offer to contribute this if the community approves the idea. Thanks and Regards, Roland From chris.smith at cmfirstgroup.com Wed Jun 19 12:12:22 2019 From: chris.smith at cmfirstgroup.com (Chris Smith) Date: Wed, 19 Jun 2019 16:12:22 +0000 Subject: [keycloak-dev] Putting a value into a custom Protocol mapper In-Reply-To: References: Message-ID: OK, I have an ugly hack. I hope someone might have a suggestion more aligned with Keycloak architecture My hack is to use a ThreadLocal to hold the serialized Kerberos ticket in the LDAPStorageProvider public static final String KERBEROS_NOT_SET = "*NOT_SET"; public static final ThreadLocal SERILIZED_KERBEROS_TICKET = new ThreadLocal() { @Override protected String initialValue() { return KERBEROS_NOT_SET; } }; public boolean validPassword(RealmModel realm, UserModel user, String password) { if (kerberosConfig.isAllowKerberosAuthentication() && kerberosConfig.isUseKerberosForPasswordAuthentication()) { // Use Kerberos JAAS (Krb5LoginModule) KerberosUsernamePasswordAuthenticator authenticator = factory.createKerberosUsernamePasswordAuthenticator(kerberosConfig); boolean isValid = authenticator.validUser(user.getUsername(), password); if (isValid) { SERILIZED_KERBEROS_TICKET.set(authenticator.getSerializedKerberosTicket()); } return isValid; } else { // Use Naming LDAP API ... And in the UsernamePasswordForm 1: override the validate password method 2: write the serialized ticket as a user session note to the AuthenticationFlowContext. @Override public boolean validatePassword(AuthenticationFlowContext context, UserModel user, MultivaluedMap inputData) { boolean isValid = super.validatePassword(context, user, inputData); if (isValid) { saveKerbTicketClaim(context); } return isValid; } private void saveKerbTicketClaim(AuthenticationFlowContext context) { String kerbTicket = LDAPStorageProvider.SERILIZED_KERBEROS_TICKET.get(); if (!kerbTicket.equals(LDAPStorageProvider.KERBEROS_NOT_SET)) { context.getAuthenticationSession() .setUserSessionNote(KerberosConstants.GSS_DELEGATION_CREDENTIAL, kerbTicket); } LDAPStorageProvider.SERILIZED_KERBEROS_TICKET.remove(); return; } This is bad, but it works for now until someone can point out to me what I missed. -----Original Message----- From: keycloak-dev-bounces at lists.jboss.org On Behalf Of Chris Smith Sent: Monday, June 17, 2019 5:38 PM To: keycloak-dev at lists.jboss.org; Marek Posolda Subject: Re: [keycloak-dev] Putting a value into a custom Protocol mapper correction From: Chris Smith Sent: Monday, June 17, 2019 5:15 PM To: keycloak-dev at lists.jboss.org; Marek Posolda Subject: RE: Putting a value into a custom Protocol mapper I really need some help here I can not find out how to add a Claim after a successful Kerberos User/Password login This is as far as I know what is going on. This is in the LDAPStorageProvider class. The KerberosUsernamePasswordAuthenticator has been updated to hold the serialized Kerberos ticket. I now need to put this somewhere/somehow so that my custom Protocol mapper will put it into the Access Token public boolean validPassword(RealmModel realm, UserModel user, String password) { if (kerberosConfig.isAllowKerberosAuthentication() && kerberosConfig.isUseKerberosForPasswordAuthentication()) { // Use Kerberos JAAS (Krb5LoginModule) Map state = new HashMap<>(); KerberosUsernamePasswordAuthenticator authenticator = factory.createKerberosUsernamePasswordAuthenticator(kerberosConfig); boolean isValidUser = authenticator.validUser(user.getUsername(), password); if (isValidUser) { String delegationCredential = authenticator.getSerializedKerberosTicket(); if (delegationCredential != null) { state.put("odic-fms-sso-kerberos-ticket-mapper", delegationCredential); } << WHAT GOES HERE?? >> return isValidUser; This is from my servlet KeycloakPrincipal kcp = (KeycloakPrincipal)request.getUserPrincipal(); AccessToken at = kcp.getKeycloakSecurityContext().getToken(); Map otherClaims = at.getOtherClaims(); String otherClaim = (String)otherClaims.get("odic-fms-sso-kerberos-ticket-mapper"); GSSCredential gssCredential = KerberosSerializationUtils.deserializeCredential(otherClaim); From: Chris Smith Sent: Friday, June 14, 2019 4:24 PM To: keycloak-dev at lists.jboss.org Subject: Putting a value into a custom Protocol mapper I'm trying to have a custom protocol mapper provide a serialized Kerberos ticket as a claim I have updated the KerberosUsernamePasswordAuthenticator so that it gets the ticket public Subject authenticateSubject(String username, String password) throws LoginException { String principal = getKerberosPrincipal(username); logger.debug("Validating password of principal: " + principal); loginContext = new LoginContext("does-not-matter", null, createJaasCallbackHandler(principal, password), createJaasConfiguration()); loginContext.login(); serializedKerberosTicket = serializeTicket(); logger.debug("Principal " + principal + " authenticated succesfully"); return loginContext.getSubject(); } private String serializeTicket() { KerberosTicket kerberosTicket = loginContext.getSubject() .getPrivateCredentials(KerberosTicket.class) .stream().findFirst().get(); try (ByteArrayOutputStream bos = new ByteArrayOutputStream(); ObjectOutputStream oos = new ObjectOutputStream(bos)){ oos.writeObject(kerberosTicket); return Base64.getEncoder().encodeToString(bos.toByteArray()); } catch (IOException e) { logger.error("Kerberos ticket serialization failed", e); return null; } } I reviewed the SPNEGOAuthenticator and traced it's execution to see how it adds the Kerberos ticket and I do not see that as a workable approach as it is so different from the Kerberos User/Password authenticator. Where can my custom KerberosUsernamePasswordAuthenticator put the serialized ticket so that my custom protocol mapper will get it and add it as a claim on my Access token? I have looked and googled with no luck. _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From andrea.bruehlmann at dvbern.ch Thu Jun 20 04:05:42 2019 From: andrea.bruehlmann at dvbern.ch (=?utf-8?B?QnLDvGhsbWFubiBBbmRyZWE=?=) Date: Thu, 20 Jun 2019 08:05:42 +0000 Subject: [keycloak-dev] 10602 small German translation errors - please review In-Reply-To: References: Message-ID: Anyone? Andrea Br?hlmann Anwendungsentwicklerin DV Bern AG | Nussbaumstrasse 21 | Postfach 106 | CH-3000 Bern 22 T +41 31 378 24 24 | D +41 31 378 24 87 www.dvbern.ch Wir suchen Spezialisten, helfen Sie uns! https://www.dvbern.ch/karriere -----Urspr?ngliche Nachricht----- Von: keycloak-dev-bounces at lists.jboss.org Im Auftrag von Br?hlmann Andrea Gesendet: Mittwoch, 12. Juni 2019 13:48 An: keycloak-dev at lists.jboss.org Betreff: [keycloak-dev] 10602 small German translation errors - please review [secure] Hi there, I fixed a few German translation errors. See Jira 10602: https://issues.jboss.org/browse/KEYCLOAK-10602 Anyone up for reviewing it? Thanks. Andrea Andrea Br?hlmann Anwendungsentwicklerin DV Bern AG | Nussbaumstrasse 21 | Postfach 106 | CH-3000 Bern 22 T +41 31 378 24 24 | D +41 31 378 24 87 www.dvbern.ch Wir suchen Spezialisten, helfen Sie uns! https://www.dvbern.ch/karriere From sblanc at redhat.com Thu Jun 20 04:37:42 2019 From: sblanc at redhat.com (Sebastien Blanc) Date: Thu, 20 Jun 2019 10:37:42 +0200 Subject: [keycloak-dev] 10602 small German translation errors - please review In-Reply-To: References: Message-ID: You can create a pull request and it will be reviewed/merged there. Le jeu. 20 juin 2019 ? 10:09, Br?hlmann Andrea a ?crit : > Anyone? > > > Andrea > Br?hlmann > Anwendungsentwicklerin > DV Bern AG | Nussbaumstrasse 21 > > | Postfach 106 | CH-3000 > Bern 22 > T +41 31 378 24 24 | D +41 31 378 24 87 > www.dvbern.ch > Wir suchen Spezialisten, helfen Sie uns! https://www.dvbern.ch/karriere > > -----Urspr?ngliche Nachricht----- > Von: keycloak-dev-bounces at lists.jboss.org < > keycloak-dev-bounces at lists.jboss.org> Im Auftrag von Br?hlmann Andrea > Gesendet: Mittwoch, 12. Juni 2019 13:48 > An: keycloak-dev at lists.jboss.org > Betreff: [keycloak-dev] 10602 small German translation errors - please > review [secure] > > Hi there, > > I fixed a few German translation errors. See Jira 10602: > https://issues.jboss.org/browse/KEYCLOAK-10602 > > Anyone up for reviewing it? > Thanks. > > Andrea > > Andrea > Br?hlmann > Anwendungsentwicklerin > DV Bern AG | Nussbaumstrasse 21 > > | Postfach 106 | CH-3000 Bern 22 T +41 31 378 24 24 | D +41 31 378 24 87 > www.dvbern.ch Wir suchen Spezialisten, helfen Sie uns! > https://www.dvbern.ch/karriere > > _______________________________________________ > 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 21 04:49:39 2019 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 21 Jun 2019 10:49:39 +0200 Subject: [keycloak-dev] 10602 small German translation errors - please review In-Reply-To: References: Message-ID: He already did. The PR is here: https://github.com/keycloak/keycloak/pull/6096 We just need someone to do a quick review of this. On Thu, 20 Jun 2019 at 12:06, Sebastien Blanc wrote: > You can create a pull request and it will be reviewed/merged there. > > Le jeu. 20 juin 2019 ? 10:09, Br?hlmann Andrea < > andrea.bruehlmann at dvbern.ch> > a ?crit : > > > Anyone? > > > > > > Andrea > > Br?hlmann > > Anwendungsentwicklerin > > DV Bern AG | Nussbaumstrasse 21 > > < > https://www.google.com/maps/search/Nussbaumstrasse+21?entry=gmail&source=g > > > > | Postfach 106 | CH-3000 > > Bern 22 > > T +41 31 378 24 24 | D +41 31 378 24 87 > > www.dvbern.ch > > Wir suchen Spezialisten, helfen Sie uns! https://www.dvbern.ch/karriere > > > > -----Urspr?ngliche Nachricht----- > > Von: keycloak-dev-bounces at lists.jboss.org < > > keycloak-dev-bounces at lists.jboss.org> Im Auftrag von Br?hlmann Andrea > > Gesendet: Mittwoch, 12. Juni 2019 13:48 > > An: keycloak-dev at lists.jboss.org > > Betreff: [keycloak-dev] 10602 small German translation errors - please > > review [secure] > > > > Hi there, > > > > I fixed a few German translation errors. See Jira 10602: > > https://issues.jboss.org/browse/KEYCLOAK-10602 > > > > Anyone up for reviewing it? > > Thanks. > > > > Andrea > > > > Andrea > > Br?hlmann > > Anwendungsentwicklerin > > DV Bern AG | Nussbaumstrasse 21 > > < > https://www.google.com/maps/search/Nussbaumstrasse+21?entry=gmail&source=g > > > > | Postfach 106 | CH-3000 Bern 22 T +41 31 378 24 24 | D +41 31 378 24 87 > > www.dvbern.ch Wir suchen Spezialisten, helfen Sie uns! > > https://www.dvbern.ch/karriere > > > > _______________________________________________ > > 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 Fri Jun 21 05:05:51 2019 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Fri, 21 Jun 2019 11:05:51 +0200 Subject: [keycloak-dev] 10602 small German translation errors - please review In-Reply-To: References: Message-ID: Hi folks, looks good to me. Cheers, Thomas On Fri, 21 Jun 2019 at 10:50, Stian Thorgersen wrote: > He already did. The PR is here: > https://github.com/keycloak/keycloak/pull/6096 > > We just need someone to do a quick review of this. > > On Thu, 20 Jun 2019 at 12:06, Sebastien Blanc wrote: > > > You can create a pull request and it will be reviewed/merged there. > > > > Le jeu. 20 juin 2019 ? 10:09, Br?hlmann Andrea < > > andrea.bruehlmann at dvbern.ch> > > a ?crit : > > > > > Anyone? > > > > > > > > > Andrea > > > Br?hlmann > > > Anwendungsentwicklerin > > > DV Bern AG | Nussbaumstrasse 21 > > > < > > > https://www.google.com/maps/search/Nussbaumstrasse+21?entry=gmail&source=g > > > > > > | Postfach 106 | CH-3000 > > > Bern 22 > > > T +41 31 378 24 24 | D +41 31 378 24 87 > > > www.dvbern.ch > > > Wir suchen Spezialisten, helfen Sie uns! > https://www.dvbern.ch/karriere > > > > > > -----Urspr?ngliche Nachricht----- > > > Von: keycloak-dev-bounces at lists.jboss.org < > > > keycloak-dev-bounces at lists.jboss.org> Im Auftrag von Br?hlmann Andrea > > > Gesendet: Mittwoch, 12. Juni 2019 13:48 > > > An: keycloak-dev at lists.jboss.org > > > Betreff: [keycloak-dev] 10602 small German translation errors - please > > > review [secure] > > > > > > Hi there, > > > > > > I fixed a few German translation errors. See Jira 10602: > > > https://issues.jboss.org/browse/KEYCLOAK-10602 > > > > > > Anyone up for reviewing it? > > > Thanks. > > > > > > Andrea > > > > > > Andrea > > > Br?hlmann > > > Anwendungsentwicklerin > > > DV Bern AG | Nussbaumstrasse 21 > > > < > > > https://www.google.com/maps/search/Nussbaumstrasse+21?entry=gmail&source=g > > > > > > | Postfach 106 | CH-3000 Bern 22 T +41 31 378 24 24 | D +41 31 378 24 > 87 > > > www.dvbern.ch Wir suchen Spezialisten, helfen Sie uns! > > > https://www.dvbern.ch/karriere > > > > > > _______________________________________________ > > > 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 21 05:22:48 2019 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 21 Jun 2019 11:22:48 +0200 Subject: [keycloak-dev] 10602 small German translation errors - please review In-Reply-To: References: Message-ID: Merged, thanks :) On Fri, 21 Jun 2019 at 11:06, Thomas Darimont < thomas.darimont at googlemail.com> wrote: > Hi folks, > > looks good to me. > > Cheers, > Thomas > > On Fri, 21 Jun 2019 at 10:50, Stian Thorgersen > wrote: > >> He already did. The PR is here: >> https://github.com/keycloak/keycloak/pull/6096 >> >> We just need someone to do a quick review of this. >> >> On Thu, 20 Jun 2019 at 12:06, Sebastien Blanc wrote: >> >> > You can create a pull request and it will be reviewed/merged there. >> > >> > Le jeu. 20 juin 2019 ? 10:09, Br?hlmann Andrea < >> > andrea.bruehlmann at dvbern.ch> >> > a ?crit : >> > >> > > Anyone? >> > > >> > > >> > > Andrea >> > > Br?hlmann >> > > Anwendungsentwicklerin >> > > DV Bern AG | Nussbaumstrasse 21 >> > > < >> > >> https://www.google.com/maps/search/Nussbaumstrasse+21?entry=gmail&source=g >> > > >> > > | Postfach 106 | CH-3000 >> > > Bern 22 >> > > T +41 31 378 24 24 | D +41 31 378 24 87 >> > > www.dvbern.ch >> > > Wir suchen Spezialisten, helfen Sie uns! >> https://www.dvbern.ch/karriere >> > > >> > > -----Urspr?ngliche Nachricht----- >> > > Von: keycloak-dev-bounces at lists.jboss.org < >> > > keycloak-dev-bounces at lists.jboss.org> Im Auftrag von Br?hlmann Andrea >> > > Gesendet: Mittwoch, 12. Juni 2019 13:48 >> > > An: keycloak-dev at lists.jboss.org >> > > Betreff: [keycloak-dev] 10602 small German translation errors - please >> > > review [secure] >> > > >> > > Hi there, >> > > >> > > I fixed a few German translation errors. See Jira 10602: >> > > https://issues.jboss.org/browse/KEYCLOAK-10602 >> > > >> > > Anyone up for reviewing it? >> > > Thanks. >> > > >> > > Andrea >> > > >> > > Andrea >> > > Br?hlmann >> > > Anwendungsentwicklerin >> > > DV Bern AG | Nussbaumstrasse 21 >> > > < >> > >> https://www.google.com/maps/search/Nussbaumstrasse+21?entry=gmail&source=g >> > > >> > > | Postfach 106 | CH-3000 Bern 22 T +41 31 378 24 24 | D +41 31 378 24 >> 87 >> > > www.dvbern.ch Wir suchen Spezialisten, helfen Sie uns! >> > > https://www.dvbern.ch/karriere >> > > >> > > _______________________________________________ >> > > 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 asier.aguado at cern.ch Fri Jun 21 07:59:08 2019 From: asier.aguado at cern.ch (Asier Aguado) Date: Fri, 21 Jun 2019 13:59:08 +0200 Subject: [keycloak-dev] Customizing usernames In-Reply-To: <6D320D40264A8545A9C25EC79DE1E32502031D521C@CERNXCHG41.cern.ch> References: <6D320D40264A8545A9C25EC79DE1E32502031D43FB@CERNXCHG41.cern.ch> <6D320D40264A8545A9C25EC79DE1E32502031D477C@CERNXCHG41.cern.ch> <0618c636-d59b-82ca-dd18-2ddbea51d9e4@redhat.com> <6D320D40264A8545A9C25EC79DE1E32502031D521C@CERNXCHG41.cern.ch> Message-ID: <8ea26b51-d5c4-c522-6edd-617a8556af56@cern.ch> Hi Marek, We're still trying to configure GitHub using the generic OIDC provider, so we can use the username template mapper we need. According to the GitHub docs [1], the token URL returns its content in a different format depending on the HTTP header received. Keycloak seems to parse it as JSON, so it could make sense to include the header "Accept: application/json" in the request. Would this change fix the parsing error? Thanks, Asier [1] https://developer.github.com/apps/building-oauth-apps/authorizing-oauth-apps/ On 18/06/2019 13:49, Paolo Tedesco wrote:- > Hi Marek, > > Thanks a lot for your reply, we were trying to configure this with the Github provider, which allows less customization in the mappers. > The username template mapper looks exactly like what we need, but we don't manage to configure a generic OpenID connect Identity Provider to work with Github. > We get an error saying "could not decode access token response". > It seems that Github by default return something like this in the token URL > > access_token=e72e16c7e42f292c6912e7710c838347ae178b4a&token_type=bearer > > and the identity provider tries to parse it as a JWT. > Is it possible to configure github as a generic OpenID connect IDP? > > Thanks, > Paolo > > -----Original Message----- > From: Marek Posolda > Sent: Friday, June 14, 2019 18:01 > To: Paolo Tedesco ; stian at redhat.com > Cc: keycloak-dev at lists.jboss.org; Asier Aguado Corman ; Hannah Short ; Cristian Schuszter > Subject: Re: [keycloak-dev] Customizing usernames > > I think that for this, you can use "Username Template" importer. It is the IdentityProvider mapper. After creating Identity Provider, you can click to tab "Mappers" and configure it here. Just a note that with this approach, you will end with duplicated keycloak accounts for someone, who may be same person. > > Another possibility is to tweak the "First Broker Login" flow and tweak authenticators. For example automatically merge accounts without prompting (But this option has some security implications, see docs for the details). > > If you have some recommendations for the usability of the default dialog, feel free to suggest here. But IMO having both the "automerging accounts" or "duplicated accounts" is problematic and hence we have the option of asking users for merge accounts OOTB. > > Marek > > Dne 14. 06. 19 v 8:33 Paolo Tedesco napsal(a): >> Hi Stian, >> >> We want to avoid that users are presented with the "account already exists" dialogue and the option to merge accounts, because we think that it wouldn't always be clear for users what is going on. >> We managed to turn off the unique email validation, but then, for what we understood, we need to have unique usernames. >> Maybe we are just missing something, then how do we configure unique IDs (which are not mail addresses) instead of usernames? >> >> Thanks, >> Paolo >> >> From: Stian Thorgersen >> Sent: Thursday, June 13, 2019 18:36 >> To: Paolo Tedesco >> Cc: keycloak-dev at lists.jboss.org; Cristian Schuszter >> ; Asier Aguado Corman >> ; Hannah Short >> Subject: Re: [keycloak-dev] Customizing usernames >> >> Could you explain your use-case a bit better? It seems to me that having a unique id as we do for the users today is exactly what you want. We decided to use a unique id rather than the username for exactly the reasons you mention. >> >> On Thu, 13 Jun 2019 at 13:19, Paolo Tedesco > wrote: >> Hi all, >> >> >> >> I'm looking for a way to customize the unique identifiers used by Keycloak in its internal user database, to avoid possible email or username clashes. >> >> For example, I would like to be able to change the username of someone logging in through github to "login at github.com", so that if someone has the same login in the CERN LDAP the user is not offered the possibility to merge the accounts. >> >> Our problems come from the fact that we allow people to change their mail addresses, and also to use external non-CERN addresses as their email, so we cannot rely on email much. >> We would also like to avoid people to merge accounts at all as we think this might be confusing for users on some occasions, and generate support tickets for us. >> >> Is there a supported way to do this, or would we need to code something ourselves? >> If we need to code something, should we write a plugin of some kind (e.g. custom mappers) or would we need to modify directly the code that manages the login from the identity provider? >> In case someone else requested something similar, we might make our development available. >> >> Thanks, >> Paolo Tedesco >> >> _______________________________________________ >> 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 Oliver.Heger at bosch-si.com Fri Jun 21 08:42:42 2019 From: Oliver.Heger at bosch-si.com (Heger Oliver (INST-IOT/ESB)) Date: Fri, 21 Jun 2019 12:42:42 +0000 Subject: [keycloak-dev] Dynamic SAML roles to user mapper Message-ID: <3e7aaddffc934ab981663a8305491a25@bosch-si.com> Hi all, In the mean time we made some progress by creating an initial implementation of a custom mapper for SAML roles that supports our use case. The mapper extracts a list of role names from a configurable attribute of the SAML response from the IDP. Roles that do not exist in the current realm are created automatically. Then the current user is assigned exactly this list of roles. There are some further configuration options to support a transformation of role names to a certain degree. So it is possible for instance to specify a regular expression to select only a subset of the roles from the SAML response, and a template can be provided for generating role names dynamically. Is there some interest in this mapper implementation? Do you think it could be useful in general? Kind regards Oliver -----Urspr?ngliche Nachricht----- Von: keycloak-dev-bounces at lists.jboss.org Im Auftrag von Heger Oliver (INST-IOT/ESB) Gesendet: Freitag, 7. Juni 2019 13:35 An: keycloak-dev at lists.jboss.org Betreff: [keycloak-dev] Dynamic SAML roles to user mapper Hi all, For an external customer we need to bring together the SAML IDP of the customer as leading system for user data with our services that are only supporting OIDC. We think Keycloak could fit very well as some kind of mediator between the customer's IDP and our OIDC-based services. The services expect JWTs containing basic user data and also a list with all the roles the user has. With the mappers available in Keycloak a JWT can be constructed that contains the desired information. But now it can happen that the roles model is extended in agreement between the IDP and the client services. As we understand it, in order to support the newly added roles, they would have to be added manually into Keycloak before they can be referenced by the existing SAML Attribute to Role mapper. This manual step we would like to avoid. In our ideal scenario, Keycloak would just be an infrastructure component handling the SAML to OIDC conversion. With respect to the roles assigned to users, it should be agnostic and simply copy the information it receives from the SAML IDP verbatim. To achieve this we think about implementing a custom mapper that allows dealing with roles in this way. It would read the roles from a configurable attribute of the SAML response and assign them to the user affected in the Keycloak data model. If a role was encountered that did not exist yet, it would be newly created. That way the roles model used by Keycloak would adapt itself dynamically to the model used by the parties involved, and no manual updates would be required. Do you think there is an easier solution for this problem than writing a custom mapper? If the answer is no, would you be interested in such a mapper implementation? We would be happy to contribute it. In our opinion this feature would strengthen the brokering facilities of Keycloak. Thank you and kind regards Oliver Heger (INST-IOT/ESB) Bosch Software Innovations GmbH | Stuttgarter Stra?e 130 | 71332 Waiblingen | GERMANY | www.bosch-si.com Tel. +49 711 811-58473 | Fax +49 711 811-58200 | oliver.heger at bosch-si.com Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten L?cke; Gesch?ftsf?hrung: Dr. Stefan Ferber, Michael Hahn, Dr. Aleksandar Mitrovic _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From jgross.biz at gmail.com Fri Jun 21 17:01:21 2019 From: jgross.biz at gmail.com (Justin Gross) Date: Fri, 21 Jun 2019 14:01:21 -0700 Subject: [keycloak-dev] Client Storage SPI and KEYCLOAK-6408 In-Reply-To: References: <5cfb5959.1c69fb81.fbd17.8ad9@mx.google.com> Message-ID: <5d0d45a0.1c69fb81.234a6.0087@mx.google.com> Yes Stian, we are planning to store clients in an LDAP storage. Initially storing only those that are not bundled in with Keycloak (though I don?t see why we couldn?t also store those in LDAP). The main reasons for using LDAP for us are LDAP has advanced replication features and functionality that are reliable and allow selective replication. We need an IAM and Client store solution which is primarily online (and managed from the cloud) but can operate normally while offline (on-premise, internet loss, synced). Some users will migrate from location to location so we need ?cross-realm? log-in. We don?t want to sync every user (or client) to every location though so the filtered LDAP replication works wonderful. We can sync all ?migratory? users and then only those we expect at that physical location. We can sync clients and users selectively based on any arbitrary attribute. Since LDAP is not specifically a user credential store but rather a lightweight directory service we wish to use it as such and store more than just users in it. I have created LDAP schemas for the client related data and plan on finishing the minor storage refactoring and LDAP Client Store implementation once I am back from vacation. I plan on implementing the LDAP Client Store as an EAR that can be deployed rather than baked in to Keycloak itself but it would be nice if it was eventually merged in if deemed warranted. Thanks, Justin Gross From: Stian Thorgersen Sent: Tuesday, June 11, 2019 3:49 AM To: Justin Gross Cc: keycloak-dev at lists.jboss.org Subject: Re: [keycloak-dev] Client Storage SPI and KEYCLOAK-6408 We are planning a bigger rework of the storage layer in the future as part of Keycloak .Next. With that in mind you should rather follow the discussion around that as it unfolds over the next few months. For the current implementation we can be open to smaller stuff, but not big overhauls. Finishing the client storage API may be useful, but to be honest not many people have been interested here. I'd rather see a simpler client store where it's easier to replace with a custom store. I don't think there's need to federate multiple client stores for a single realm. For LDAP I'm not sure what you mean about separate core and user stuff. It is only a user store, at least now. Are you perhaps thinking about storing clients in LDAP? On Sat, 8 Jun 2019 at 08:46, Justin Gross wrote: Good afternoon, good evening and good morning everyone! I am Justin and I?d like to start contributing to Keycloak. Is there anyone on the list that is interested in the continuing development of Client Storage SPI? (KEYCLOAK-6408 in JIRA) If you answered yes to the above, what storage systems/software are you interested in using for client storage? Preparing to take on some of the things listed in KEYCLOAK-6408. I am in the middle of a lite refactoring of some useful things which are currently specific to user storage federation such as SynchronizationResult, ImportSynchronization, etc? so they can be used by the yet to be finished Client Storage API. I also plan to refactor some of the LDAP federation stuff so that the user specific stuff is separate from the core LDAP functionality itself. Eventually I want to use LDAP to store client configuration and there?s a lot of useful LDAP functionality stashed away in the user federation stuff. Thank you, Justin Gross _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev From marc at autonomic.ai Fri Jun 21 19:02:44 2019 From: marc at autonomic.ai (Marc Spehlmann) Date: Fri, 21 Jun 2019 16:02:44 -0700 Subject: [keycloak-dev] Federated Identity Collisions Message-ID: Hello dev community, I was building a feature on top of keycloak which allows my company?s customers to provision users. While working on this, I realized that I can break a user's federated login by the following procedure: 1. create a User A, add to this user a federation {"identityProvider": "google", "userId":"123", ?marc at google.com"} 2. create a User B, add to this user a federation {"identityProvider": "google", "userId":"123", ?marc at google.com"} Now when either user A or B tries to do federated login using the google provider, they receive a 500 error with a phrase like `More results found for identityProvider` being logged on the backend. The code in `getUserByFederatedIdentity` of the JpaUserProvider does not check for uniqueness of the userId/federated_username. Couple questions: - Is there a check I can do prior to adding a user in the admin-api for a duplicate federated_identity? - Is this a known deficiency? Best, Marc From dpolivaev at gmx.de Sun Jun 23 07:11:28 2019 From: dpolivaev at gmx.de (Dimitry Polivaev) Date: Sun, 23 Jun 2019 13:11:28 +0200 Subject: [keycloak-dev] Non blocking KeycloakInstalled loginDesktop() and logout() Message-ID: Hello folks, currently there are only blocking variants of loginDesktop() and logout() at KeycloakInstalled. It means that if the methods are called they open an URL in browser and wait until they get callback from the Keycloak server. It makes not advisable to call them from the UI thread because they block it. But even if the methods are called from a worker thread so that the application is not blocked, they always open a server socket and start threads and there is no way to close the socket and to kill the associated callback threads from the application code. I would like to contribute non blocking versions which return CompletableFuture. If the user cancels the returned CompletableFuture, also the opened server socket should be closed. See https://issues.jboss.org/browse/KEYCLOAK-10700 Any objections or opinions? Cheers, Dimitry From contributing.to.keycloak at gmail.com Mon Jun 24 01:54:58 2019 From: contributing.to.keycloak at gmail.com (Roland) Date: Mon, 24 Jun 2019 07:54:58 +0200 Subject: [keycloak-dev] Fwd: Add SAML Extensions (and AuthContext) as another client note to the AuthenticationSessionModel in SamlService In-Reply-To: References: Message-ID: Any remarks on this? Did anyone get the chance to take a look? Stian? Thanks! Roland ---------- Forwarded message --------- Von: Roland Date: Mi., 19. Juni 2019 um 14:04 Uhr Subject: Add SAML Extensions (and AuthContext) as another client note to the AuthenticationSessionModel in SamlService To: Hello, when a SAML Request is received in Keycloak, the method loginRequest in abstract class BindingProtocol in class org.keycloak.protocol.samlSamlService puts the information from the request into the AuthenticationSessionModel in this section of code: authSession.setProtocol(SamlProtocol.LOGIN_PROTOCOL); authSession.setRedirectUri(redirect); authSession.setAction( AuthenticationSessionModel.Action.AUTHENTICATE.name()); authSession.setClientNote(SamlProtocol.SAML_BINDING, bindingType); authSession.setClientNote(GeneralConstants.RELAY_STATE, relayState); authSession.setClientNote(SamlProtocol.SAML_REQUEST_ID, requestAbstractType.getID()); What we are missing here is the SAML Extensions, which happen to be in the SAML Request which we receive, and which we want to pass on to a brokered external Identity Provider. For example something like this: ExtensionsType et = requestAbstractType.getExtensions(); List list = et.getAny(); authSession.setAuthNote("SAML_EXTENSION", ); In the same way we would also like access to the AuthContext through the authSession. I would offer to contribute this if the community approves the idea. Thanks and Regards, Roland From mposolda at redhat.com Mon Jun 24 06:52:54 2019 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 24 Jun 2019 12:52:54 +0200 Subject: [keycloak-dev] Customizing usernames In-Reply-To: <8ea26b51-d5c4-c522-6edd-617a8556af56@cern.ch> References: <6D320D40264A8545A9C25EC79DE1E32502031D43FB@CERNXCHG41.cern.ch> <6D320D40264A8545A9C25EC79DE1E32502031D477C@CERNXCHG41.cern.ch> <0618c636-d59b-82ca-dd18-2ddbea51d9e4@redhat.com> <6D320D40264A8545A9C25EC79DE1E32502031D521C@CERNXCHG41.cern.ch> <8ea26b51-d5c4-c522-6edd-617a8556af56@cern.ch> Message-ID: <1ae306d8-a506-f163-6795-db0c932e7c36@redhat.com> Hi, I am not sure about the side-effect of this. IMO it will be better if "Username Template Importer" mapper is allowed as the mapper in the github provider (as well as other social providers). Then it will work with the Github provider without need to configure Github as generic OIDC. If you are able to create JIRA and send PR for this change, it will be nice :) Thanks, Marek On 21/06/2019 13:59, Asier Aguado wrote: > Hi Marek, > > We're still trying to configure GitHub using the generic OIDC > provider, so we can use the username template mapper we need. > > According to the GitHub docs [1], the token URL returns its content in > a different format depending on the HTTP header received. Keycloak > seems to parse it as JSON, so it could make sense to include the > header "Accept: application/json" in the request. Would this change > fix the parsing error? > > Thanks, > Asier > > [1] > https://developer.github.com/apps/building-oauth-apps/authorizing-oauth-apps/ > > > On 18/06/2019 13:49, Paolo Tedesco wrote:- >> Hi Marek, >> >> Thanks a lot for your reply, we were trying to configure this with >> the Github provider, which allows less customization in the mappers. >> The username template mapper looks exactly like what we need, but we >> don't manage to configure a generic OpenID connect Identity Provider >> to work with Github. >> We get an error saying "could not decode access token response". >> It seems that Github by default return something like this in the >> token URL >> >> access_token=e72e16c7e42f292c6912e7710c838347ae178b4a&token_type=bearer >> >> and the identity provider tries to parse it as a JWT. >> Is it possible to configure github as a generic OpenID connect IDP? >> >> Thanks, >> Paolo >> >> -----Original Message----- >> From: Marek Posolda >> Sent: Friday, June 14, 2019 18:01 >> To: Paolo Tedesco ; stian at redhat.com >> Cc: keycloak-dev at lists.jboss.org; Asier Aguado Corman >> ; Hannah Short ; Cristian >> Schuszter >> Subject: Re: [keycloak-dev] Customizing usernames >> >> I think that for this, you can use "Username Template" importer. It >> is the IdentityProvider mapper. After creating Identity Provider, you >> can click to tab "Mappers" and configure it here. Just a note that >> with this approach, you will end with duplicated keycloak accounts >> for someone, who may be same person. >> >> Another possibility is to tweak the "First Broker Login" flow and >> tweak authenticators. For example automatically merge accounts >> without prompting (But this option has some security implications, >> see docs for the details). >> >> If you have some recommendations for the usability of the default >> dialog, feel free to suggest here. But IMO having both the >> "automerging accounts" or "duplicated accounts" is problematic and >> hence we have the option of asking users for merge accounts OOTB. >> >> Marek >> >> Dne 14. 06. 19 v 8:33 Paolo Tedesco napsal(a): >>> Hi Stian, >>> >>> We want to avoid that users are presented with the "account already >>> exists" dialogue and the option to merge accounts, because we think >>> that it wouldn't always be clear for users what is going on. >>> We managed to turn off the unique email validation, but then, for >>> what we understood, we need to have unique usernames. >>> Maybe we are just missing something, then how do we configure unique >>> IDs (which are not mail addresses) instead of usernames? >>> >>> Thanks, >>> Paolo >>> >>> From: Stian Thorgersen >>> Sent: Thursday, June 13, 2019 18:36 >>> To: Paolo Tedesco >>> Cc: keycloak-dev at lists.jboss.org; Cristian Schuszter >>> ; Asier Aguado Corman >>> ; Hannah Short >>> Subject: Re: [keycloak-dev] Customizing usernames >>> >>> Could you explain your use-case a bit better? It seems to me that >>> having a unique id as we do for the users today is exactly what you >>> want. We decided to use a unique id rather than the username for >>> exactly the reasons you mention. >>> >>> On Thu, 13 Jun 2019 at 13:19, Paolo Tedesco >>> > wrote: >>> Hi all, >>> >>> >>> >>> I'm looking for a way to customize the unique identifiers used by >>> Keycloak in its internal user database, to avoid possible email or >>> username clashes. >>> >>> For example, I would like to be able to change the username of >>> someone logging in through github to >>> "login at github.com", so that if someone has >>> the same login in the CERN LDAP the user is not offered the >>> possibility to merge the accounts. >>> >>> Our problems come from the fact that we allow people to change their >>> mail addresses, and also to use external non-CERN addresses as their >>> email, so we cannot rely on email much. >>> We would also like to avoid people to merge accounts at all as we >>> think this might be confusing for users on some occasions, and >>> generate support tickets for us. >>> >>> Is there a supported way to do this, or would we need to code >>> something ourselves? >>> If we need to code something, should we write a plugin of some kind >>> (e.g. custom mappers) or would we need to modify directly the code >>> that manages the login from the identity provider? >>> In case someone else requested something similar, we might make our >>> development available. >>> >>> Thanks, >>> Paolo Tedesco >>> >>> _______________________________________________ >>> 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 Mon Jun 24 09:00:04 2019 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 24 Jun 2019 15:00:04 +0200 Subject: [keycloak-dev] Putting a value into a custom Protocol mapper In-Reply-To: References: Message-ID: <46574d98-ab5b-14e4-ba63-46e7a403b1e2@redhat.com> ATM There is no nice way of doing this as method "validPassword" on UserStorageProvider is limited to return just boolean. No any additional state can be returned from the credential validation ATM. One slightly better way than thread-local could be to use the KeycloakSession attributes. KeycloakSession is simply per-request object, so you can use methods like getAttribute/setAttribute. For some other use-case, we recently discuss to add AuthenticationSessionModel as an additional thing to the KeycloakContext. That would allow to retrieve current AuthenticationSession inside the LDAPStorageProvider. However that is not available yet and there may be some issues with the future portability of this solution as LDAPStorageProvider (or any other UserStorageProvider) shouldn't ideally have direct access to stuff like AuthenticationSessionModel... So not convinced about this solution, just mentioning for the completeness ;) Marek On 19/06/2019 18:12, Chris Smith wrote: > OK, I have an ugly hack. I hope someone might have a suggestion more aligned with Keycloak architecture > My hack is to use a ThreadLocal to hold the serialized Kerberos ticket in the LDAPStorageProvider > > public static final String KERBEROS_NOT_SET = "*NOT_SET"; > public static final ThreadLocal SERILIZED_KERBEROS_TICKET = new ThreadLocal() { > @Override > protected String initialValue() { > return KERBEROS_NOT_SET; > } > }; > > public boolean validPassword(RealmModel realm, UserModel user, String password) { > if (kerberosConfig.isAllowKerberosAuthentication() && kerberosConfig.isUseKerberosForPasswordAuthentication()) { > // Use Kerberos JAAS (Krb5LoginModule) > KerberosUsernamePasswordAuthenticator authenticator = factory.createKerberosUsernamePasswordAuthenticator(kerberosConfig); > boolean isValid = authenticator.validUser(user.getUsername(), password); > if (isValid) { > SERILIZED_KERBEROS_TICKET.set(authenticator.getSerializedKerberosTicket()); > } > return isValid; > } else { > // Use Naming LDAP API > ... > > And in the UsernamePasswordForm > 1: override the validate password method > 2: write the serialized ticket as a user session note to the AuthenticationFlowContext. > > @Override > public boolean validatePassword(AuthenticationFlowContext context, UserModel user, > MultivaluedMap inputData) { > boolean isValid = super.validatePassword(context, user, inputData); > if (isValid) { > saveKerbTicketClaim(context); > } > return isValid; > } > > private void saveKerbTicketClaim(AuthenticationFlowContext context) { > String kerbTicket = LDAPStorageProvider.SERILIZED_KERBEROS_TICKET.get(); > if (!kerbTicket.equals(LDAPStorageProvider.KERBEROS_NOT_SET)) { > context.getAuthenticationSession() > .setUserSessionNote(KerberosConstants.GSS_DELEGATION_CREDENTIAL, kerbTicket); > } > LDAPStorageProvider.SERILIZED_KERBEROS_TICKET.remove(); > return; > } > > This is bad, but it works for now until someone can point out to me what I missed. > > > -----Original Message----- > From: keycloak-dev-bounces at lists.jboss.org On Behalf Of Chris Smith > Sent: Monday, June 17, 2019 5:38 PM > To: keycloak-dev at lists.jboss.org; Marek Posolda > Subject: Re: [keycloak-dev] Putting a value into a custom Protocol mapper > > correction > > From: Chris Smith > Sent: Monday, June 17, 2019 5:15 PM > To: keycloak-dev at lists.jboss.org; Marek Posolda > Subject: RE: Putting a value into a custom Protocol mapper > > I really need some help here > I can not find out how to add a Claim after a successful Kerberos User/Password login > > This is as far as I know what is going on. > This is in the LDAPStorageProvider class. The KerberosUsernamePasswordAuthenticator has been updated to hold the serialized Kerberos ticket. I now need to put this somewhere/somehow so that my custom Protocol mapper will put it into the Access Token > > public boolean validPassword(RealmModel realm, UserModel user, String password) { > if (kerberosConfig.isAllowKerberosAuthentication() && kerberosConfig.isUseKerberosForPasswordAuthentication()) { > // Use Kerberos JAAS (Krb5LoginModule) > Map state = new HashMap<>(); > KerberosUsernamePasswordAuthenticator authenticator = factory.createKerberosUsernamePasswordAuthenticator(kerberosConfig); > boolean isValidUser = authenticator.validUser(user.getUsername(), password); > if (isValidUser) { > String delegationCredential = authenticator.getSerializedKerberosTicket(); > if (delegationCredential != null) { > state.put("odic-fms-sso-kerberos-ticket-mapper", delegationCredential); > } > > > << WHAT GOES HERE?? >> > > return isValidUser; > > This is from my servlet > > KeycloakPrincipal kcp = (KeycloakPrincipal)request.getUserPrincipal(); > AccessToken at = kcp.getKeycloakSecurityContext().getToken(); > Map otherClaims = at.getOtherClaims(); > String otherClaim = (String)otherClaims.get("odic-fms-sso-kerberos-ticket-mapper"); > GSSCredential gssCredential = KerberosSerializationUtils.deserializeCredential(otherClaim); > > From: Chris Smith > Sent: Friday, June 14, 2019 4:24 PM > To: keycloak-dev at lists.jboss.org > Subject: Putting a value into a custom Protocol mapper > > I'm trying to have a custom protocol mapper provide a serialized Kerberos ticket as a claim > > I have updated the KerberosUsernamePasswordAuthenticator so that it gets the ticket > > public Subject authenticateSubject(String username, String password) throws LoginException { > String principal = getKerberosPrincipal(username); > > logger.debug("Validating password of principal: " + principal); > loginContext = new LoginContext("does-not-matter", null, > createJaasCallbackHandler(principal, password), > createJaasConfiguration()); > > loginContext.login(); > serializedKerberosTicket = serializeTicket(); > logger.debug("Principal " + principal + " authenticated succesfully"); > return loginContext.getSubject(); > } > > private String serializeTicket() { > KerberosTicket kerberosTicket = loginContext.getSubject() > .getPrivateCredentials(KerberosTicket.class) > .stream().findFirst().get(); > try (ByteArrayOutputStream bos = new ByteArrayOutputStream(); > ObjectOutputStream oos = new ObjectOutputStream(bos)){ > oos.writeObject(kerberosTicket); > return Base64.getEncoder().encodeToString(bos.toByteArray()); > } catch (IOException e) { > logger.error("Kerberos ticket serialization failed", e); > return null; > } > } > > I reviewed the SPNEGOAuthenticator and traced it's execution to see how it adds the Kerberos ticket and I do not see that as a workable approach as it is so different from the Kerberos User/Password authenticator. > > Where can my custom KerberosUsernamePasswordAuthenticator put the serialized ticket so that my custom protocol mapper will get it and add it as a claim on my Access token? > > I have looked and googled with no luck. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From chris.smith at cmfirstgroup.com Tue Jun 25 12:31:29 2019 From: chris.smith at cmfirstgroup.com (Chris Smith) Date: Tue, 25 Jun 2019 16:31:29 +0000 Subject: [keycloak-dev] Putting a value into a custom Protocol mapper In-Reply-To: <46574d98-ab5b-14e4-ba63-46e7a403b1e2@redhat.com> References: <46574d98-ab5b-14e4-ba63-46e7a403b1e2@redhat.com> Message-ID: Thanks for the response and suggestion. That removed the ThreadLocal. Keycloak has a rather large codebase doing lots of complex work. It was a challenge finding what I needed to do. -----Original Message----- From: Marek Posolda Sent: Monday, June 24, 2019 8:00 AM To: Chris Smith ; keycloak-dev at lists.jboss.org Subject: Re: Putting a value into a custom Protocol mapper ATM There is no nice way of doing this as method "validPassword" on UserStorageProvider is limited to return just boolean. No any additional state can be returned from the credential validation ATM. One slightly better way than thread-local could be to use the KeycloakSession attributes. KeycloakSession is simply per-request object, so you can use methods like getAttribute/setAttribute. For some other use-case, we recently discuss to add AuthenticationSessionModel as an additional thing to the KeycloakContext. That would allow to retrieve current AuthenticationSession inside the LDAPStorageProvider. However that is not available yet and there may be some issues with the future portability of this solution as LDAPStorageProvider (or any other UserStorageProvider) shouldn't ideally have direct access to stuff like AuthenticationSessionModel... So not convinced about this solution, just mentioning for the completeness ;) Marek On 19/06/2019 18:12, Chris Smith wrote: > OK, I have an ugly hack. I hope someone might have a suggestion more > aligned with Keycloak architecture My hack is to use a ThreadLocal to > hold the serialized Kerberos ticket in the LDAPStorageProvider > > public static final String KERBEROS_NOT_SET = "*NOT_SET"; > public static final ThreadLocal SERILIZED_KERBEROS_TICKET = new ThreadLocal() { > @Override > protected String initialValue() { > return KERBEROS_NOT_SET; > } > }; > > public boolean validPassword(RealmModel realm, UserModel user, String password) { > if (kerberosConfig.isAllowKerberosAuthentication() && kerberosConfig.isUseKerberosForPasswordAuthentication()) { > // Use Kerberos JAAS (Krb5LoginModule) > KerberosUsernamePasswordAuthenticator authenticator = factory.createKerberosUsernamePasswordAuthenticator(kerberosConfig); > boolean isValid = authenticator.validUser(user.getUsername(), password); > if (isValid) { > SERILIZED_KERBEROS_TICKET.set(authenticator.getSerializedKerberosTicket()); > } > return isValid; > } else { > // Use Naming LDAP API > ... > > And in the UsernamePasswordForm > 1: override the validate password method > 2: write the serialized ticket as a user session note to the AuthenticationFlowContext. > > @Override > public boolean validatePassword(AuthenticationFlowContext context, UserModel user, > MultivaluedMap inputData) { > boolean isValid = super.validatePassword(context, user, inputData); > if (isValid) { > saveKerbTicketClaim(context); > } > return isValid; > } > > private void saveKerbTicketClaim(AuthenticationFlowContext context) { > String kerbTicket = LDAPStorageProvider.SERILIZED_KERBEROS_TICKET.get(); > if (!kerbTicket.equals(LDAPStorageProvider.KERBEROS_NOT_SET)) { > context.getAuthenticationSession() > .setUserSessionNote(KerberosConstants.GSS_DELEGATION_CREDENTIAL, kerbTicket); > } > LDAPStorageProvider.SERILIZED_KERBEROS_TICKET.remove(); > return; > } > > This is bad, but it works for now until someone can point out to me what I missed. > > > -----Original Message----- > From: keycloak-dev-bounces at lists.jboss.org > On Behalf Of Chris Smith > Sent: Monday, June 17, 2019 5:38 PM > To: keycloak-dev at lists.jboss.org; Marek Posolda > Subject: Re: [keycloak-dev] Putting a value into a custom Protocol > mapper > > correction > > From: Chris Smith > Sent: Monday, June 17, 2019 5:15 PM > To: keycloak-dev at lists.jboss.org; Marek Posolda > Subject: RE: Putting a value into a custom Protocol mapper > > I really need some help here > I can not find out how to add a Claim after a successful Kerberos > User/Password login > > This is as far as I know what is going on. > This is in the LDAPStorageProvider class. The > KerberosUsernamePasswordAuthenticator has been updated to hold the > serialized Kerberos ticket. I now need to put this somewhere/somehow > so that my custom Protocol mapper will put it into the Access Token > > public boolean validPassword(RealmModel realm, UserModel user, String password) { > if (kerberosConfig.isAllowKerberosAuthentication() && kerberosConfig.isUseKerberosForPasswordAuthentication()) { > // Use Kerberos JAAS (Krb5LoginModule) > Map state = new HashMap<>(); > KerberosUsernamePasswordAuthenticator authenticator = factory.createKerberosUsernamePasswordAuthenticator(kerberosConfig); > boolean isValidUser = authenticator.validUser(user.getUsername(), password); > if (isValidUser) { > String delegationCredential = authenticator.getSerializedKerberosTicket(); > if (delegationCredential != null) { > state.put("odic-fms-sso-kerberos-ticket-mapper", delegationCredential); > } > > > << WHAT GOES HERE?? >> > > return isValidUser; > > This is from my servlet > > KeycloakPrincipal kcp = (KeycloakPrincipal)request.getUserPrincipal(); > AccessToken at = kcp.getKeycloakSecurityContext().getToken(); > Map otherClaims = at.getOtherClaims(); > String otherClaim = (String)otherClaims.get("odic-fms-sso-kerberos-ticket-mapper"); > GSSCredential gssCredential = > KerberosSerializationUtils.deserializeCredential(otherClaim); > > From: Chris Smith > Sent: Friday, June 14, 2019 4:24 PM > To: keycloak-dev at lists.jboss.org > Subject: Putting a value into a custom Protocol mapper > > I'm trying to have a custom protocol mapper provide a serialized > Kerberos ticket as a claim > > I have updated the KerberosUsernamePasswordAuthenticator so that it > gets the ticket > > public Subject authenticateSubject(String username, String password) throws LoginException { > String principal = getKerberosPrincipal(username); > > logger.debug("Validating password of principal: " + principal); > loginContext = new LoginContext("does-not-matter", null, > createJaasCallbackHandler(principal, password), > createJaasConfiguration()); > > loginContext.login(); > serializedKerberosTicket = serializeTicket(); > logger.debug("Principal " + principal + " authenticated succesfully"); > return loginContext.getSubject(); > } > > private String serializeTicket() { > KerberosTicket kerberosTicket = loginContext.getSubject() > .getPrivateCredentials(KerberosTicket.class) > .stream().findFirst().get(); > try (ByteArrayOutputStream bos = new ByteArrayOutputStream(); > ObjectOutputStream oos = new ObjectOutputStream(bos)){ > oos.writeObject(kerberosTicket); > return Base64.getEncoder().encodeToString(bos.toByteArray()); > } catch (IOException e) { > logger.error("Kerberos ticket serialization failed", e); > return null; > } > } > > I reviewed the SPNEGOAuthenticator and traced it's execution to see how it adds the Kerberos ticket and I do not see that as a workable approach as it is so different from the Kerberos User/Password authenticator. > > Where can my custom KerberosUsernamePasswordAuthenticator put the serialized ticket so that my custom protocol mapper will get it and add it as a claim on my Access token? > > I have looked and googled with no luck. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From psilva at redhat.com Tue Jun 25 14:14:25 2019 From: psilva at redhat.com (Pedro Igor Silva) Date: Tue, 25 Jun 2019 15:14:25 -0300 Subject: [keycloak-dev] Spring Security and KeycloakRole (GrantedAuthority) Implementation Message-ID: Hello All, I would like to know from those using the Spring Security Adapter if we can do a very simple change to the KeycloakRole type which is used to represent roles granted by Keycloak. The change [1] is all about changing the equals method to support any instance of GrantedAuthority (parent) instead of KeycloakRole instances only. The reason I'm asking is that in GrantedAuthority docs there is a comment [2] that made me wonder if we could potentially break any existing deployment relying on the current implementation of equals, where an exact match of KeycloakRole instance is expected. Please, let me know your feedback. I'm OK with the proposed changes but I would like to hear more feedback before we accept the changes. [1] https://github.com/keycloak/keycloak/pull/6113 [2] https://github.com/spring-projects/spring-security/blob/master/core/src/main/java/org/springframework/security/core/GrantedAuthority.java#L42 Regards. Pedro Igor From maxime.suret at early-birds.io Wed Jun 26 13:02:26 2019 From: maxime.suret at early-birds.io (maxime.suret at early-birds.io) Date: Wed, 26 Jun 2019 19:02:26 +0200 Subject: [keycloak-dev] UMA authorization process in Gatekeeper Message-ID: Hi All, When Keycloak Gatekeeper gets a 401 response with a permission ticket from upstream, it would be very useful if it could fetch the corresponding RPT and retry accessing the upstream resource with it. The RPT would then be placed in the access cookie to avoid this process in subsequent requests. That would also be a nice feature to have when using gatekeeper as a forwad signing proxy. What do you think ? I am willing to implement this myself. Thanks ! Maxime -- From arlen.thurber at datastax.com Wed Jun 26 13:48:08 2019 From: arlen.thurber at datastax.com (Arlen Thurber) Date: Wed, 26 Jun 2019 10:48:08 -0700 Subject: [keycloak-dev] Identity first login flow Message-ID: Hello Keycloak community, I am looking for more information on an custom authentication method named Identity first login flow. I found this concept in a keycloak Jira ticket https://issues.jboss.org/browse/KEYCLOAK-1514 The issue was opened 03/Jul/15. There was a discussion back in February of 2018 that mentioned that this functionality would be offered "out of the box", but i cant find any more mention of it, and the issue was just recently put into plan on 06/Mar/19 . In the description of Identity first login flow : "This makes it possible to not require a password for a user when other authentication mechanisms are used (for example fingerprint, two-way ssl, etc.). Also, it allows automatically redirecting to an external IdP when the user is linked to an external IdP (either the user used the IdP to login before or a email domain has been configured to the IdP)." Does anyone have any more information about this concept, an example of it working, or advice on how this login flow could be achieved? I have started looking into a custom authenticator and authentication flow, but it would be ideal if this functionality was built in. Thank you, Arlen From sthorger at redhat.com Wed Jun 26 14:32:03 2019 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 26 Jun 2019 20:32:03 +0200 Subject: [keycloak-dev] Identity first login flow In-Reply-To: References: Message-ID: We are planning to add this later in the year as it is related to webauthn passwordless logins. Not much more information around it at this point though. On Wed, 26 Jun 2019, 20:04 Arlen Thurber, wrote: > Hello Keycloak community, > > I am looking for more information on an custom authentication method named > Identity first login flow. I found this concept in a keycloak Jira ticket > https://issues.jboss.org/browse/KEYCLOAK-1514 > The issue was opened 03/Jul/15. There was a discussion back in February of > 2018 that mentioned that this functionality would be offered "out of the > box", but i cant find any more mention of it, and the issue was just > recently > put into plan on 06/Mar/19 . > > In the description of Identity first login flow : > "This makes it possible to not require a password for a user when other > authentication mechanisms are used (for example fingerprint, two-way ssl, > etc.). Also, it allows automatically redirecting to an external IdP when > the user is linked to an external IdP (either the user used the IdP to > login before or a email domain has been configured to the IdP)." > > Does anyone have any more information about this concept, an example of it > working, or advice on how this login flow could be achieved? I have started > looking into a custom authenticator and authentication flow, but it would > be ideal if this functionality was built in. > > Thank you, > Arlen > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From khaianisnizar2007 at gmail.com Wed Jun 26 17:41:58 2019 From: khaianisnizar2007 at gmail.com (anis khai) Date: Wed, 26 Jun 2019 22:41:58 +0100 Subject: [keycloak-dev] Using keycloak token as secret key for Des to encrypt banking transaction Message-ID: In order to share secret key for Des as symetric algorithm To encrypt transaction data shared between mobile device and backend microservices I m thinking to use keycloak token (code grant flow selected) Because it have timetolive infinispan and regrouped information container in scope mappers Is it right choice or there is a vuln?rabilit?s WE will consider refresh token in m'y flow Any advice or proposition is weclome. @Stian Best regards thanks in avance. From sthorger at redhat.com Thu Jun 27 02:17:26 2019 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 27 Jun 2019 08:17:26 +0200 Subject: [keycloak-dev] Review update to Turkish translation Message-ID: Can someone from the community please review a short update to the Turkish translation? The PR is: https://github.com/keycloak/keycloak/pull/6124 From niko at n-k.de Thu Jun 27 08:39:15 2019 From: niko at n-k.de (=?utf-8?Q?Niko_K=C3=B6bler?=) Date: Thu, 27 Jun 2019 14:39:15 +0200 Subject: [keycloak-dev] Let the check-sso feature of the javascript adapter do the check in hidden iframe Message-ID: Hi all / Stian, based on the discussion in https://github.com/keycloak/keycloak/pull/5932, I created a new Jira issue and a PR (wip) with a first approach. I'd like to discuss, if this yields into the right direction. Regards, - Niko From psilva at redhat.com Thu Jun 27 09:14:45 2019 From: psilva at redhat.com (Pedro Igor Silva) Date: Thu, 27 Jun 2019 10:14:45 -0300 Subject: [keycloak-dev] UMA authorization process in Gatekeeper In-Reply-To: References: Message-ID: Hi Maxime, Interesting idea. Basically, the GK will do the dirty work for clients, right? We could probably consider having this task as a subtask of https://issues.jboss.org/browse/KEYCLOAK-10367 ? Regards. Pedro Igor On Wed, Jun 26, 2019 at 2:05 PM wrote: > Hi All, > > When Keycloak Gatekeeper gets a 401 response with a permission ticket > from upstream, it would be very useful if it could fetch the > corresponding RPT and retry accessing the upstream resource with it. > The RPT would then be placed in the access cookie to avoid this process > in subsequent requests. > That would also be a nice feature to have when using gatekeeper as a > forwad signing proxy. > What do you think ? I am willing to implement this myself. > > Thanks ! > > Maxime > > > -- > > < > https://www.eventbrite.com/e/atelier-by-early-birds-x-saint-gobain-distribution-batiment-france-la-personnalisation-au-service-tickets-60817610109 > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bruno at abstractj.org Thu Jun 27 12:31:38 2019 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 27 Jun 2019 13:31:38 -0300 Subject: [keycloak-dev] [KEYCLOAK-9870] - Gatekeeper renewal does not renew refresh tokens Message-ID: <20190627163138.GA3980@abstractj.org> Some time ago we got a bug report for Gatekeeper related with refresh token revocation[1]. Here are the steps to reproduce: "In keycloak, menu Tokens, set "revoke refresh token" to ON with value set to 0. This means refresh token can be used only once. Gain access with a session through keycloak-gatekeeper, wait token expiry, try calling a resource: this works. Now wait again for a second token expiry. try calling a resource: failure - the refresh token has expired" >From my perspective, it looks like the expected behavior and not a bug. If the access token has expired in the first time, the refresh token was used to obtain a new one and request access to the resource. So in the second request, failure should be expected. So it's better to ask. What is the expected behavior when "revoke refresh token" is set to 0 from the adapters? I tried to look at our docs, but couldn't find anything. [1] - https://issues.jboss.org/browse/KEYCLOAK-9870 -- abstractj From psilva at redhat.com Thu Jun 27 13:51:27 2019 From: psilva at redhat.com (Pedro Igor Silva) Date: Thu, 27 Jun 2019 14:51:27 -0300 Subject: [keycloak-dev] [KEYCLOAK-9870] - Gatekeeper renewal does not renew refresh tokens In-Reply-To: <20190627163138.GA3980@abstractj.org> References: <20190627163138.GA3980@abstractj.org> Message-ID: It seems to be a bug. The first time you refresh, refresh count is 0, the second time is 1, which is expected to fail. You should be able to continue refreshing tokens if you are using the last RT obtained from the server. If you look docs, this is basically a security layer to deal with compromised RTs. On Thu, Jun 27, 2019 at 1:58 PM Bruno Oliveira wrote: > Some time ago we got a bug report for Gatekeeper related with refresh > token revocation[1]. Here are the steps to reproduce: > > "In keycloak, menu Tokens, set "revoke refresh token" to ON with value > set to 0. This means refresh token can be used only once. > > Gain access with a session through keycloak-gatekeeper, wait token > expiry, try calling a resource: this works. Now wait again for a second > token expiry. try calling a resource: failure - the refresh token has > expired" > > >From my perspective, it looks like the expected behavior and not a bug. > If the access token has expired in the first time, the refresh token was > used to obtain a new one and request access to the resource. So in the > second request, failure should be expected. > > So it's better to ask. What is the expected behavior when "revoke > refresh token" is set to 0 from the adapters? I tried to look at our docs, > but couldn't find anything. > > [1] - https://issues.jboss.org/browse/KEYCLOAK-9870 > > -- > > abstractj > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bruno at abstractj.org Thu Jun 27 14:10:09 2019 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 27 Jun 2019 15:10:09 -0300 Subject: [keycloak-dev] [KEYCLOAK-9870] - Gatekeeper renewal does not renew refresh tokens In-Reply-To: References: <20190627163138.GA3980@abstractj.org> Message-ID: <20190627181009.GA22367@abstractj.org> Thank you Pedro, that helps. Now it's clear what is expected from "Refresh Token Max Reuse" when 0 is set. On 2019-06-27, Pedro Igor Silva wrote: > It seems to be a bug. The first time you refresh, refresh count is 0, the > second time is 1, which is expected to fail. You should be able to continue > refreshing tokens if you are using the last RT obtained from the server. > > If you look docs, this is basically a security layer to deal with > compromised RTs. > > On Thu, Jun 27, 2019 at 1:58 PM Bruno Oliveira wrote: > > > Some time ago we got a bug report for Gatekeeper related with refresh > > token revocation[1]. Here are the steps to reproduce: > > > > "In keycloak, menu Tokens, set "revoke refresh token" to ON with value > > set to 0. This means refresh token can be used only once. > > > > Gain access with a session through keycloak-gatekeeper, wait token > > expiry, try calling a resource: this works. Now wait again for a second > > token expiry. try calling a resource: failure - the refresh token has > > expired" > > > > >From my perspective, it looks like the expected behavior and not a bug. > > If the access token has expired in the first time, the refresh token was > > used to obtain a new one and request access to the resource. So in the > > second request, failure should be expected. > > > > So it's better to ask. What is the expected behavior when "revoke > > refresh token" is set to 0 from the adapters? I tried to look at our docs, > > but couldn't find anything. > > > > [1] - https://issues.jboss.org/browse/KEYCLOAK-9870 > > > > -- > > > > abstractj > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -- abstractj From ssilvert at redhat.com Thu Jun 27 16:27:17 2019 From: ssilvert at redhat.com (Stan Silvert) Date: Thu, 27 Jun 2019 16:27:17 -0400 Subject: [keycloak-dev] Application Initiated Action In-Reply-To: References: Message-ID: An AIA is initiated with an auth request.? So before the AIA runs, any required actions set by the admin will run. Is that OK or should we skip any other required action? I think it definitely makes sense if you are logging in to do the AIA.? For instance, admin wants user to update his profile.? User does an AIA for change password, but he is not logged in. 0) User is presented with login screen and logs in. 1) User is presented with "update profile" screen. 2) User is presented with "change password screen. 3) User is redirected back to his app. User does an AIA for change password, but he is already logged in.: 1) User is presented with "update profile" screen. 2) User is presented with "change password screen. 3) User is redirected back to his app. Is that OK, or should step 1 be skipped in the second scenario? On 5/6/2019 2:50 AM, Stian Thorgersen wrote: > Last chance to comment on Application Initiated Action design: > > https://github.com/keycloak/keycloak-community/pull/7 > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From thomas.darimont at googlemail.com Thu Jun 27 17:38:26 2019 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Thu, 27 Jun 2019 23:38:26 +0200 Subject: [keycloak-dev] Identity first login flow In-Reply-To: References: Message-ID: Hello, I just gave this a quick spin: https://github.com/thomasdarimont/keycloak-extension-playground/tree/master/auth-identity-first-extension For a demo see also https://twitter.com/thomasdarimont/status/1144357602094194688 Would be great to have something like that directly in Keycloak :) Cheers, Thomas On Wed, 26 Jun 2019 at 20:35, Stian Thorgersen wrote: > We are planning to add this later in the year as it is related to webauthn > passwordless logins. Not much more information around it at this point > though. > > On Wed, 26 Jun 2019, 20:04 Arlen Thurber, > wrote: > > > Hello Keycloak community, > > > > I am looking for more information on an custom authentication method > named > > Identity first login flow. I found this concept in a keycloak Jira ticket > > https://issues.jboss.org/browse/KEYCLOAK-1514 > > The issue was opened 03/Jul/15. There was a discussion back in February > of > > 2018 that mentioned that this functionality would be offered "out of the > > box", but i cant find any more mention of it, and the issue was just > > recently > > put into plan on 06/Mar/19 . > > > > In the description of Identity first login flow : > > "This makes it possible to not require a password for a user when other > > authentication mechanisms are used (for example fingerprint, two-way ssl, > > etc.). Also, it allows automatically redirecting to an external IdP when > > the user is linked to an external IdP (either the user used the IdP to > > login before or a email domain has been configured to the IdP)." > > > > Does anyone have any more information about this concept, an example of > it > > working, or advice on how this login flow could be achieved? I have > started > > looking into a custom authenticator and authentication flow, but it would > > be ideal if this functionality was built in. > > > > Thank you, > > Arlen > > > > > > _______________________________________________ > > 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 28 01:31:50 2019 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 28 Jun 2019 07:31:50 +0200 Subject: [keycloak-dev] [KEYCLOAK-9870] - Gatekeeper renewal does not renew refresh tokens In-Reply-To: <20190627181009.GA22367@abstractj.org> References: <20190627163138.GA3980@abstractj.org> <20190627181009.GA22367@abstractj.org> Message-ID: Gatekeeper should indeed always update the refresh token with the latest obtained from Keycloak after refreshing tokens. There's at least 3 reasons for this: * Key rotation - as a realm rotates its keys it will issue new refersh tokens with the new keys on token refresh * Max re-use - refresh tokens can be single-use as you mentioned * Other updates - refresh tokens are opaque and the authorization server can use it for whatever purpose it wants. We don't currently do any updates to the claims within, but we could in the future and other authorization servers may already do so So, yes this is a bug in Gatekeeper On Thu, 27 Jun 2019 at 20:18, Bruno Oliveira wrote: > Thank you Pedro, that helps. Now it's clear what is expected from "Refresh > Token Max Reuse" when 0 is set. > > On 2019-06-27, Pedro Igor Silva wrote: > > It seems to be a bug. The first time you refresh, refresh count is 0, the > > second time is 1, which is expected to fail. You should be able to > continue > > refreshing tokens if you are using the last RT obtained from the server. > > > > If you look docs, this is basically a security layer to deal with > > compromised RTs. > > > > On Thu, Jun 27, 2019 at 1:58 PM Bruno Oliveira > wrote: > > > > > Some time ago we got a bug report for Gatekeeper related with refresh > > > token revocation[1]. Here are the steps to reproduce: > > > > > > "In keycloak, menu Tokens, set "revoke refresh token" to ON with value > > > set to 0. This means refresh token can be used only once. > > > > > > Gain access with a session through keycloak-gatekeeper, wait token > > > expiry, try calling a resource: this works. Now wait again for a > second > > > token expiry. try calling a resource: failure - the refresh token has > > > expired" > > > > > > >From my perspective, it looks like the expected behavior and not a > bug. > > > If the access token has expired in the first time, the refresh token > was > > > used to obtain a new one and request access to the resource. So in the > > > second request, failure should be expected. > > > > > > So it's better to ask. What is the expected behavior when "revoke > > > refresh token" is set to 0 from the adapters? I tried to look at our > docs, > > > but couldn't find anything. > > > > > > [1] - https://issues.jboss.org/browse/KEYCLOAK-9870 > > > > > > -- > > > > > > abstractj > > > _______________________________________________ > > > keycloak-dev mailing list > > > keycloak-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > -- > > abstractj > _______________________________________________ > 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 28 02:12:45 2019 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 28 Jun 2019 08:12:45 +0200 Subject: [keycloak-dev] Application Initiated Action In-Reply-To: References: Message-ID: Required actions should run as soon as possible. As such required actions should execute prior to an AIA. We should probably consider checking what required actions have executed though to make sure that a single action is not triggered multiple times. So if an AIA is the same action as a required action that has already been done, then perhaps it should be skipped as it has already been done? On Thu, 27 Jun 2019 at 22:30, Stan Silvert wrote: > An AIA is initiated with an auth request. So before the AIA runs, any > required actions set by the admin will run. > > Is that OK or should we skip any other required action? > > I think it definitely makes sense if you are logging in to do the AIA. > For instance, admin wants user to update his profile. User does an AIA > for change password, but he is not logged in. > 0) User is presented with login screen and logs in. > 1) User is presented with "update profile" screen. > 2) User is presented with "change password screen. > 3) User is redirected back to his app. > > User does an AIA for change password, but he is already logged in.: > 1) User is presented with "update profile" screen. > 2) User is presented with "change password screen. > 3) User is redirected back to his app. > > Is that OK, or should step 1 be skipped in the second scenario? > > > On 5/6/2019 2:50 AM, Stian Thorgersen wrote: > > Last chance to comment on Application Initiated Action design: > > > > https://github.com/keycloak/keycloak-community/pull/7 > > _______________________________________________ > > 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 28 02:13:06 2019 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 28 Jun 2019 08:13:06 +0200 Subject: [keycloak-dev] Let the check-sso feature of the javascript adapter do the check in hidden iframe In-Reply-To: References: Message-ID: Replied on the PR On Thu, 27 Jun 2019 at 15:00, Niko K?bler wrote: > Hi all / Stian, > > based on the discussion in https://github.com/keycloak/keycloak/pull/5932, > I created a new Jira issue and a PR (wip) with a first approach. > I'd like to discuss, if this yields into the right direction. > > Regards, > - Niko > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From ssilvert at redhat.com Fri Jun 28 07:14:48 2019 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 28 Jun 2019 07:14:48 -0400 Subject: [keycloak-dev] Application Initiated Action In-Reply-To: References: Message-ID: <8b29c80b-7dbe-6962-c171-e0d5fed19697@redhat.com> On 6/28/2019 2:12 AM, Stian Thorgersen wrote: > Required actions should run as soon as possible. As such required > actions should execute prior to an AIA. We should probably consider > checking what required actions have executed though to make sure that > a single action is not triggered multiple times. So if an AIA is the > same action as a required action that has already been done, then > perhaps it should be skipped as it has already been done? It looks like the logic must already be there to avoid duplicates. I haven't found where in the code this happens, but it seems to be working properly by default. > > On Thu, 27 Jun 2019 at 22:30, Stan Silvert > wrote: > > An AIA is initiated with an auth request.? So before the AIA runs, > any > required actions set by the admin will run. > > Is that OK or should we skip any other required action? > > I think it definitely makes sense if you are logging in to do the > AIA. > For instance, admin wants user to update his profile.? User does > an AIA > for change password, but he is not logged in. > 0) User is presented with login screen and logs in. > 1) User is presented with "update profile" screen. > 2) User is presented with "change password screen. > 3) User is redirected back to his app. > > User does an AIA for change password, but he is already logged in.: > 1) User is presented with "update profile" screen. > 2) User is presented with "change password screen. > 3) User is redirected back to his app. > > Is that OK, or should step 1 be skipped in the second scenario? > > > On 5/6/2019 2:50 AM, Stian Thorgersen wrote: > > Last chance to comment on Application Initiated Action design: > > > > https://github.com/keycloak/keycloak-community/pull/7 > > _______________________________________________ > > 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 yormen1 at gmail.com Sat Jun 29 03:49:44 2019 From: yormen1 at gmail.com (Yor Men) Date: Sat, 29 Jun 2019 07:49:44 +0000 Subject: [keycloak-dev] Social login rest api Message-ID: Hi, Does keycloak provide an api that can generate a link for you to click on and redirect you to let say github and login. Let me sight an example, we have an application that is secured with keycloak, we want to allow users to be able to login to the app using github, facebook and google without having to go to the keycloak page in any way. What we want to do is, when the login page is called, the controller generates the URI and is bound to the model. This model value is placed in a particular social login button. Any other suggestion is welcome. Thank you. From jgross.biz at gmail.com Sat Jun 29 04:43:59 2019 From: jgross.biz at gmail.com (Justin Gross) Date: Sat, 29 Jun 2019 04:43:59 -0400 Subject: [keycloak-dev] Social login rest api In-Reply-To: References: Message-ID: Many identity providers are supported out of the box with keycloak including Facebook, GitHub, GitLab, BitBucket, OpenShift, Microsoft, and LinkedIn to name a few. There are instructions for each respective provider and if you have another identity provider who implements the OIDC protocol they should work too provided they strictly adhere to the OIDC protocol. Please see the following link from the official documentation. https://www.keycloak.org/docs/latest/server_admin/index.html#social-identity-providers Best regards, Justin Gross On Sat, Jun 29, 2019, 3:50 AM Yor Men wrote: > Hi, > > Does keycloak provide an api that can generate a link for you to click on > and redirect you to let say github and login. > > Let me sight an example, we have an application that is secured with > keycloak, we want to allow users to be able to login to the app using > github, facebook and google without having to go to the keycloak page in > any way. > > What we want to do is, when the login page is called, the controller > generates the URI and is bound to the model. This model value is placed in > a particular social login button. > > Any other suggestion is welcome. > > Thank you. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From jgross.biz at gmail.com Sat Jun 29 04:52:58 2019 From: jgross.biz at gmail.com (Justin Gross) Date: Sat, 29 Jun 2019 04:52:58 -0400 Subject: [keycloak-dev] Social login rest api In-Reply-To: References: Message-ID: Apologies, I just re-read your email. I don't believe there is a built-in API to retrieve some special link that completely bypasses Keycloak during authentication but even if there was you would have to redirect to Keycloak at some point to complete the login. That being said you might be able to implement a new authorization flow which provides this functionality and then add a custom resource with an API (as a Keycloak module) which can generate your link which initiates the custom auth flow. Maybe you don't need a login flow and can instead just make the Keycloak resource/module. I'd look at how the login page generates the login buttons it provides (and payload it uses) and then create the API you want which does the same thing but without a UI as Keycloak module. Just food for thought. Sorry for replying in haste previously. Thank you, Justin Grosz On Sat, Jun 29, 2019, 3:50 AM Yor Men wrote: > Hi, > > Does keycloak provide an api that can generate a link for you to click on > and redirect you to let say github and login. > > Let me sight an example, we have an application that is secured with > keycloak, we want to allow users to be able to login to the app using > github, facebook and google without having to go to the keycloak page in > any way. > > What we want to do is, when the login page is called, the controller > generates the URI and is bound to the model. This model value is placed in > a particular social login button. > > Any other suggestion is welcome. > > Thank you. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From gentoo at penguindreams.us Sat Jun 29 11:18:36 2019 From: gentoo at penguindreams.us (Martin Maher) Date: Sat, 29 Jun 2019 08:18:36 -0700 Subject: [keycloak-dev] Additional authentication protocol support In-Reply-To: References: Message-ID: <3DE74CE3-1C6A-4BA6-BAC3-69165EFAA495@penguindreams.us> Hello, I have just become aware of keycloak as a platform we utilize has replaced their regular Unix/Linux PAM with keycloak. My question is whether or not it would be possible for the project to add RADIUS, Diameter, and most desirably TACACS+ protocol support as methods to the keycloak PAM agent. Regards, Martin