Re: [keycloak-dev] Request for someone to contribute an WebAuthn4j extension
by 中村雄一 / NAKAMURA，YUUICHI
Hi,
We've updated the webauthn authenticator prototype based on webauthn4j :
https://github.com/webauthn4j/keycloak-webauthn-authenticator/tree/demo-c...
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(a)lists.jboss.org <keycloak-dev-bounces(a)lists.jboss.org> On Behalf Of 中村雄一 / NAKAMURA，YUUICHI
Sent: Tuesday, March 19, 2019 4:32 PM
To: stian(a)redhat.com
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>
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 <sthorger(a)redhat.com>
Sent: Monday, March 18, 2019 5:49 PM
To: 中村雄一 / NAKAMURA，YUUICHI <yuichi.nakamura.fe(a)hitachi.com>
Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org>; 乗松隆志 / NORIMATSU，TAKASHI <takashi.norimatsu.ws(a)hitachi.com>; 茂木昂士 / MOGI，TAKASHI <takashi.mogi.ep(a)hitachi.com>; Yoshikazu Nojima <mail(a)ynojima.net>
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...
On Fri, 15 Mar 2019 at 08:13, 中村雄一 / NAKAMURA，YUUICHI <mailto:yuichi.nakamura.fe@hitachi.com> wrote:
Hi,
We’ve uploaded the initial prototype of webauthn authenticator below: https://clicktime.symantec.com/37NWG7BAMWtR42Swt5VUTw77Vc?u=https%3A%2F%2...
Feedback is welcomed.
From: Stian Thorgersen <mailto:sthorger@redhat.com>
Sent: Thursday, February 28, 2019 6:53 PM
To: 中村雄一 / NAKAMURA，YUUICHI <mailto:yuichi.nakamura.fe@hitachi.com>
Cc: keycloak-dev <mailto:keycloak-dev@lists.jboss.org>
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 <mailto:mailto:yuichi.nakamura.fe@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@lists.jboss.org <mailto:mailto:keycloak-dev-bounces@lists.jboss.org> On Behalf Of Stian Thorgersen
Sent: Thursday, February 28, 2019 12:26 AM
To: keycloak-dev <mailto:mailto:keycloak-dev@lists.jboss.org>
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%2F%2...
_______________________________________________
keycloak-dev mailing list
mailto:mailto:keycloak-dev@lists.jboss.org
https://clicktime.symantec.com/35NVx3Bd41ZVjjssocqwjpK7Vc?u=https%3A%2F%2...
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://clicktime.symantec.com/3K7AmDtC5f54UYS4NNrH1wo7Vc?u=https%3A%2F%2...
4 years, 10 months
Integration test: Verify url that was used in an adapter backchannel request
by Luca Graf
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
4 years, 10 months
Encrypted OIDC ID Tokens support and admin console
by Marek Posolda
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://issues.jboss.org/browse/KEYCLOAK-6768
[2] https://github.com/keycloak/keycloak/pull/5779
Marek
4 years, 10 months
Re: [keycloak-dev] Override "native" Keycloak providers
by Thomas Darimont
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 <h2-wada(a)nri.co.jp> 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-...
>
>
> --
> Hiroyuki Wada
> Nomura Research Institute, Ltd.
> h2-wada(a)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(a)lists.jboss.org <
> keycloak-dev-bounces(a)lists.jboss.org> が Jerry Saravia <
> jerry.saravia(a)virginpulse.com> の代理で送信
> 送信日時: 2019年4月15日 22:12
> 宛先: Thomas Darimont
> CC: keycloak-dev(a)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 <thomas.darimont(a)googlemail.com>
> Date: Wednesday, March 27, 2019 at 18:23
> To: Jerry Saravia <jerry.saravia(a)virginpulse.com>
> Cc: "keycloak-dev(a)lists.jboss.org" <keycloak-dev(a)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.jb...
> >
> 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(a)virginpulse.com
> <mailto:jerry.saravia@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/j...
> <
> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub....
> >
>
>
>
> These are the 4.8 changes
>
>
> https://github.com/keycloak/keycloak/blob/4.8.3.Final/services/src/main/j...
> <
> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub....
> >
>
>
>
> 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%2Fvirginpu...
> >
> |virginpulse.com/global-challenge<
> https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvirginpu...
> >
> 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(a)lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev<
> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.j...
> >
>
4 years, 10 months
Override "native" Keycloak providers
by Jerry Saravia
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/j...
These are the 4.8 changes
https://github.com/keycloak/keycloak/blob/4.8.3.Final/services/src/main/j...
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
4 years, 10 months
