May 2019 - keycloak-dev - Jboss List Archives

Re: [keycloak-dev] passing SAML extensions and context to custom authenticators

by Caranzo Gideon

Hi Hynek, Thank you for your response. Yes, I agree with you. It would be good to have this mechanism in those areas as well. I already have a PR ready for just the SAML login portion. Is it fine with you if I submit this first so that we can use it as early as possible? We can create a separate ticket to implement similar mechanism for other SAML messages and broker endpoint which can be done in near future. Thanks, Gideon -----Original Message----- From: keycloak-dev-bounces(a)lists.jboss.org [mailto:keycloak-dev-bounces@lists.jboss.org] On Behalf Of Hynek Mlnarik Sent: Thursday, January 24, 2019 1:58 AM To: Gideon Caranzo <gideonray(a)gmail.com> Cc: keycloak-dev <keycloak-dev(a)lists.jboss.org> Subject: Re: [keycloak-dev] passing SAML extensions and context to custom authenticators Hi Gideon, thanks for the idea. Something like that would be a useful enhancement. The implementation would need to cover also the broker endpoint, other SAML message types (extensions are part of message types other than AuthnRequest as well), and count on several implementations of the hypothetical SamlAuthenticationPreprocessor. Could you please file an "Enhancement" JIRA? --Hynek On Wed, Jan 16, 2019 at 5:49 PM Gideon Caranzo <gideonray(a)gmail.com> wrote: > Hi All, > > I'd like to propose a feature that allows custom authenticators to > handle SAML extensions, authentication context and other request attributes. > > Right now in OIDC, all request claims are passed to custom > authenticators which allows for customized behavior depending on the claims. > However, this is not the case for SAML. Only attributes that are > explicitly set (e.g. NameID) in the auth session are passed to custom authenticators. > > Information like SAML extension and authentication context are not > available which limits the ability to define custom behaviors. In the > past, we ran into similar limitation and we had to update keycloak > core to add support for NameID attribute. > > To solve this, we can have an optional hook that pre-process SAML > login request right before authentication. The hook can then extract > the needed attributes and set it accordingly for custom authenticators to process. > > The pre-processing will be done in > *SamlService.BindingProtocol.loginRequest()*: > > *public* *class* SamlService *extends* AuthorizationEndpointBase { > > *. . .* > > *public* *abstract* *class* BindingProtocol { > > . . . > > *protected* Response loginRequest(String relayState, > AuthnRequestType requestAbstractType, ClientModel client) { > > . . . > > SamlAuthenticationPreprocessor preProcessor = session > .getProvider(SamlAuthenticationPreprocessor.*class*); > > *if* (preProcessor != *null*) { > > preProcessor.process(requestAbstractType, authSession); > > } > > > > *return* newBrowserAuthentication(authSession, > requestAbstractType.isIsPassive(), redirectToAuthentication); > > } > > > Let me know what you think. Thanks. > > Best regards, > Gideon > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis > ts.jboss.org%2Fmailman%2Flistinfo%2Fkeycloak-dev&data=02%7C01%7Cgi > deon.caranzo%40gemalto.com%7C6f947d88676b4f788b2108d681d1d529%7C37d0a9 > db7c464096bfe31add5b495d6d%7C0%7C0%7C636839135555784466&sdata=Yhpx > 28KFJWJGa1kv1ROWWqJd3nt60YvAb0YmeKUU5Mg%3D&reserved=0 > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.... ________________________________ This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus.

5 years, 8 months

2
1
0 / 0

Application Initiated Action

by Stian Thorgersen

Last chance to comment on Application Initiated Action design: https://github.com/keycloak/keycloak-community/pull/7

5 years, 10 months

2
3
0 / 0

User Consents via Account REST API

by Schuster Sebastian (INST-CSS/BSV-OS2)

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<http://www.bosch-si.com> Tel. +49 30 726112-485 | Mobil +49 152 02177668 | Fax +49 30 726112-100 | Sebastian.Schuster(a)bosch-si.com<mailto:Sebastian.Schuster@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

5 years, 11 months

3
3
0 / 0

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...

5 years, 11 months

3
3
0 / 0

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

5 years, 11 months

3
4
0 / 0

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

5 years, 11 months

4
5
0 / 0

Support for briefRepresentation on the group members endpoint

by Jeroen ter Voorde

Hi, I added a PR to support the briefRepresentation parameter on the groups/{id}/members endpoint. I hope this can be included in the 7.0 release. The reason is is that i need to request the full member list for multiple groups and returning the full representation is quite slow. I could not find where to update the documentation. Is this autogenerated from the annotations? Issue: https://issues.jboss.org/browse/KEYCLOAK-10419 Thanks, Jeroen

5 years, 11 months

1
0
0 / 0

Nodejs-Adapter-Update

by Konstantinos Schoinas

Hi everyone, I would like to discuss about an bug ( and a possible update ) in keycloak-connect Node-js Module. At the moment when a user session is expired keycloak-connect will try to redirect the user in the login page ( A flow that is compltetly fine ) .But when you perform an AJAX request with an expired session keycloak-connect doesn't handle this AJAX request properly. When a session is invalidated keycloak-connect takes a set of actions in order to make the user to re-login. The last function that is called in this flow is the forceLogin() function in the protect.js file. The problem here is that AJAX request can't handle the redirection by its nature ( 302 HTTP Code). I have already created a JIRA Ticket for this issue --> https://issues.jboss.org/browse/KEYCLOAK-10264 I have uploaded there some instructions & an example with code in order to reproduce this issue. In addition i have made a workaround for this issue that i also have implemented in the code in JIRA. I would like to contribute my changes in the keycloak-connect module to a feature version (if they get approved ) but i don't know the specific process i have to follow in order to submit my updates. I would really appreciate if someone could take a look at this issue or either describe me a way for contributing to keycloak-connect repository with my updates. Thanks for your time, Konstantinos

5 years, 11 months

1
0
0 / 0

Running Node.js tests with Chrome instead of Phantomjs

by Michal Hajas

Hi all, currently, we are using phantomjs browser for running Node.js tests [1]. However, we are experiencing some issues which seem to be caused by phantomjs, so we are considering to change the default browser from phantomjs to headless chrome. Do you have some objections why not to do so? [1] https://github.com/keycloak/keycloak-nodejs-connect/blob/master/test/util...

5 years, 11 months

6
10
0 / 0

Re: [keycloak-dev] [keycloak-team] tomcat adapter

by Vlasta Ramik

On 5/27/19 1:04 PM, Stian Thorgersen wrote: > Vlasta - can you send this to Keycloak dev as well please? > > On Mon, 27 May 2019 at 12:38, Vlasta Ramik <vramik(a)redhat.com > <mailto:vramik@redhat.com>> wrote: > > Hey guys, > > I'm currently working on KEYCLOAK-9598 Apache Tomcat 9.0.x > adapter. Adapter for tomcat8 works fine on tomcat9, it's currently > tested in pipeline. But in my opinion it's a bit strange install > something called tomca8-adapter to tomcat9 application server. > > I can see several ways how to solve this. > > * remove the specific version from the package and have common > tomcat-adapter and specific tomcat7-adapter, where > tomcat-adapter would be used for both tomcat8 and tomcat9, > this approach is the same what we have with Wildfly > > +1 > > * > > > * create a note in documentation that tomcat8 adapter is meant > to be used with tomcat9, but I don't like this option > * repackage the tomcat8 adapter: > https://github.com/keycloak/keycloak/pull/6068/files > > WDYT? > > V. >

5 years, 11 months

2
1
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

keycloak-dev May 2019