From jannik.huels at googlemail.com Tue Aug 1 11:53:48 2017 From: jannik.huels at googlemail.com (=?utf-8?Q?Jannik_H=C3=BCls?=) Date: Tue, 1 Aug 2017 17:53:48 +0200 Subject: [keycloak-dev] KEYCLOAK-3314 acr/amr support Message-ID: <18bfd4af-7430-456c-ab59-a8d38b720531@Spark> Hi, I would like to contribute to the Keycloak project and implement acr and amr support like described in?KEYCLOAK-3314. (However, I don?t know whether this is a good place to start - but at least this is a recent topic very many customers are currently requesting ;-)) My idea would be to implement it in a way Youssef suggested in the comments. Thus every Authenticator of a specific Flow may get a "Authentication Method Reference Value?. E.g. having two Authenticators ?pwd? and ?top?: The claim acr_values describes the desired level of an authentication request, thus using acr_values=pwd for the initial response should only trigger the pwd Authenticator and return acr=pwd and amr=[pwd]. A second authentication request using acr_values=otp should only ?trigger the otp authenticator, but return acr=otp and amr=[pwd,otp]. Please let me know if you want to implement support of acr and amr - even if my initial thoughts do not correspond to the ideas you have to implement this. :-) Kind regards Jannik From psilva at redhat.com Tue Aug 1 13:10:46 2017 From: psilva at redhat.com (Pedro Igor Silva) Date: Tue, 1 Aug 2017 14:10:46 -0300 Subject: [keycloak-dev] token exchange In-Reply-To: <64994417-43b0-95d3-5de9-c0d78a226d79@redhat.com> References: <71449542-5454-44e4-936b-2099e366d8b5@redhat.com> <49f60419-0d5b-9f0b-ec58-7c06eb513570@redhat.com> <64994417-43b0-95d3-5de9-c0d78a226d79@redhat.com> Message-ID: On Mon, Jul 31, 2017 at 1:54 PM, Bill Burke wrote: > > > On 7/31/17 12:18 PM, Bill Burke wrote: > > > > On 7/31/17 11:35 AM, Pedro Igor Silva wrote: > > On Fri, Jul 28, 2017 at 5:24 PM, Bill Burke wrote: > >> I've implemented a simple token exchange API [1] that allows you to >> exchange an access token created for one client to another client. The >> REST API follows the oauth token exchange api [2] very loosely. >> >> subject_token: a keycloak access token >> >> audience: takes a client id >> >> It then converts the access token created for one client and converts it >> to another. It lives under the token endpoint. >> >> The security model is as follows: >> >> * Authenticate calling client the same way as password grant. >> >> * The calling client must have service account enabled >> >> * Service account must have a realm role "token-exchanger" grant edto it >> or, it must have a client role "token-exchanger" granted to it. This >> exchanger client role is a role defined by the target client you are >> exchanging the token to. >> >> >> Is this a good security model? I'm thinking of not creating these roles >> right now and to enable support for exchange would require defining the >> roles specified above. >> > > I think roles are too coarse-grained to represent this kind of policy. A > better option would be to explicitly define the clients that are allowed to > exchange tokens for a particular resource server. Eg.: > > RS A allows Client B, C and D to exchange their tokens where the target > audience is RS A (or if using "resource", a specific resource in RS A). > > > I changed it a little. actors are: > > * Authenticated client asking for change > * Clients that are the audience of the token being exchanged > * Client you want the token to be exchanged to > > So, the authenticated client must be in the audience of the token being > exchanged, or, have permission to exchange from that particular audience. > The authenticated client also must have permission to exchange to the > audience it wants to exchange to. > > Good idea to change it to use the fine grain admin permissions. There's a > couple of issues/problems with doing this that I think are easily done: > > * public clients can't have service accounts. > * Client Policy looks at kc_client_id attribute which is pulled from the > issuedFor claim in the token. This isn't correct as we permission checks > based on the authenticated client, not the token. > > So I'll have to create a new Identity type that either wraps the service > account or ClientModel and sets the "kc_client_id" property. > Our policy evaluation engine is based on the claims within the token. The "issueFor" is basically the "azp" claim from OIDC. In fact, we don't even need that "kc_client_id". We could make this configurable though, and let users decide whether they want to check the "authenticated client" or "azp" ? Btw, I'm about to finish UMA Grant Type, one of the changes I'm doing for UMA 2.0. My changes will conflict with yours. Are you going to merge your changes soon ? Another thing I noticed is that maybe we could have a SPI for custom grant types. What you did and what I'm doing may justify a specific SPI for plugging custom grant types. Maybe too much, but maybe a nice to have. > > > Bill > From thomas at recloux.fr Wed Aug 2 01:43:52 2017 From: thomas at recloux.fr (Thomas Recloux) Date: Wed, 02 Aug 2017 07:43:52 +0200 Subject: [keycloak-dev] Spring security adapter : configure KeycloakAuthenticatedActionsFilter Message-ID: <1501652632.3702867.1060414504.4369C23E@webmail.messagingengine.com> Hi All, I created this pull request to configure KeycloakAuthenticatedActionsFilter by default in spring security adapter. https://github.com/keycloak/keycloak/pull/4346 Is there anything blocking the merge ? Cheers, Thomas From mposolda at redhat.com Thu Aug 3 06:11:15 2017 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 3 Aug 2017 12:11:15 +0200 Subject: [keycloak-dev] Blacklist Password Policy In-Reply-To: References: <337617da-bd59-0f4f-3040-f84ed50339f5@redhat.com> Message-ID: +1 for filesystem. Marek On 29/07/17 10:06, Thomas Darimont wrote: > Okay cool. > > Instead of storing the password blacklist in the database I could instead > just refer to a password > blacklist that lives on the file system. > > So Keycloak could ship with some of the lists from [0] and refer to those > with a name like "default-blacklist1000", "default-blacklist-100000" > in the BlacklistPasswordPolicy > config > within the admin-console. > > The "default-blacklist-100000" blacklist would then be mapped and resolve > to > something like > "META-INF/password-blacklist/10_million_password_list_top_100000.txt". > > Users could provide their own blacklists with the provider config stored in > standalone.xml > than could then be adjusted via jboss-cli. > > I think this filesystem based approach is better than having to load and > store big text-blobs in the database. > > Cheers, > Thomas > > [0] https://github.com/danielmiessler/SecLists/tree/master/Passwords > Using those password lists seems to be allowed according to their license: > https://www.owasp.org/index.php/Projects/OWASP_SecLists_Project > which is Creative Commons Attribution ShareAlike 3.0 License > -> IANAL but it seems to be useable in commercial products as well > https://creativecommons.org/licenses/by-sa/3.0/ > as long as the authors are mentioned. > > > 2017-07-28 22:03 GMT+02:00 Bill Burke : > >> Yah, that sounds cool. >> >> >> On 7/28/17 11:48 AM, Thomas Darimont wrote: >>> Hello, >>> >>> I build a configurable Password Policy that allows to match a given >>> password against >>> a blacklist with easy to guess passwords that should be not allowed as >> user >>> passwords. >>> >>> The 'BlacklistPasswordPolicyProvider' can be configured via the admin UI >>> with a ";" delimited list of easy to guess passwords. >>> >>> If the user / or admin want's to change the password it is checked >> against >>> the blacklist. >>> A password list can be found here: >>> https://github.com/danielmiessler/SecLists/tree/master/Passwords >>> >>> A blacklist is of course not a perfect solution but could still be useful >>> for some users. >>> >>> Password blacklist would be compiled to a trie at startup (and on changes >>> of the blacklist) >>> for efficient lookups. >>> >>> WDYT? >>> >>> Cheers, >>> Thomas >>> _______________________________________________ >>> 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 thomas.darimont at googlemail.com Thu Aug 3 06:28:19 2017 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Thu, 3 Aug 2017 12:28:19 +0200 Subject: [keycloak-dev] Blacklist Password Policy In-Reply-To: References: <337617da-bd59-0f4f-3040-f84ed50339f5@redhat.com> Message-ID: Hello, great that's just what I built :) here is the PR: https://github.com/keycloak/keycloak/pull/4370 I'm not sure about the error handling if a configured password list cannot be found on the filesystem. https://github.com/keycloak/keycloak/pull/4370/files#diff-91236e069747f156edbd2c282fec8d92R78 Looking forward to your feedback :) Cheers, Thomas 2017-08-03 12:11 GMT+02:00 Marek Posolda : > +1 for filesystem. > > Marek > > > On 29/07/17 10:06, Thomas Darimont wrote: > >> Okay cool. >> >> Instead of storing the password blacklist in the database I could instead >> just refer to a password >> blacklist that lives on the file system. >> >> So Keycloak could ship with some of the lists from [0] and refer to those >> with a name like "default-blacklist1000", "default-blacklist-100000" >> in the BlacklistPasswordPolicy >> config >> within the admin-console. >> >> The "default-blacklist-100000" blacklist would then be mapped and resolve >> to >> something like >> "META-INF/password-blacklist/10_million_password_list_top_100000.txt". >> >> Users could provide their own blacklists with the provider config stored >> in >> standalone.xml >> than could then be adjusted via jboss-cli. >> >> I think this filesystem based approach is better than having to load and >> store big text-blobs in the database. >> >> Cheers, >> Thomas >> >> [0] https://github.com/danielmiessler/SecLists/tree/master/Passwords >> Using those password lists seems to be allowed according to their license: >> https://www.owasp.org/index.php/Projects/OWASP_SecLists_Project >> which is Creative Commons Attribution ShareAlike 3.0 License >> -> IANAL but it seems to be useable in commercial products as well >> https://creativecommons.org/licenses/by-sa/3.0/ >> as long as the authors are mentioned. >> >> >> 2017-07-28 22:03 GMT+02:00 Bill Burke : >> >> Yah, that sounds cool. >>> >>> >>> On 7/28/17 11:48 AM, Thomas Darimont wrote: >>> >>>> Hello, >>>> >>>> I build a configurable Password Policy that allows to match a given >>>> password against >>>> a blacklist with easy to guess passwords that should be not allowed as >>>> >>> user >>> >>>> passwords. >>>> >>>> The 'BlacklistPasswordPolicyProvider' can be configured via the admin >>>> UI >>>> with a ";" delimited list of easy to guess passwords. >>>> >>>> If the user / or admin want's to change the password it is checked >>>> >>> against >>> >>>> the blacklist. >>>> A password list can be found here: >>>> https://github.com/danielmiessler/SecLists/tree/master/Passwords >>>> >>>> A blacklist is of course not a perfect solution but could still be >>>> useful >>>> for some users. >>>> >>>> Password blacklist would be compiled to a trie at startup (and on >>>> changes >>>> of the blacklist) >>>> for efficient lookups. >>>> >>>> WDYT? >>>> >>>> Cheers, >>>> Thomas >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > From mposolda at redhat.com Thu Aug 3 09:46:35 2017 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 3 Aug 2017 15:46:35 +0200 Subject: [keycloak-dev] (no subject) In-Reply-To: References: Message-ID: <34591f06-087e-6eef-2474-8aea05ea8a2b@redhat.com> Hmm.. Is it possible to have blacklist password policy implementation without this dependency? We are trying to not introduce much 3rd party dependencies, so not sure if it's possible to accept PR with this additional dependency... Anyway, I think you need to update distribution/feature-packs/server-feature-pack . Add dependency to pom.xml file and to modules directory. Also add it as dependency to server-spi-private module. Marek On 31/07/17 17:24, Thomas Darimont wrote: > Hello, > > how can I add a new dependency to the keycloak modules/system/layers/base > when building > a server-distribution? > > I need to add org.apache.commons:commons-collections4 for the PatriciaTrie > which I need for > my BlacklistPasswordPolicyProvider: [0] > > I tried adding a dependency to keycloak/dependencies/server-all/pom.xml but > I still get > CNFEs if I try to run the server from the dist-build. > > Caused by: java.lang.ClassNotFoundException: > org.apache.commons.collections4.trie.PatriciaTrie from [Module > "org.keycloak.keycloak-server-spi-private" from local module loader > @282ba1e (finder: local module finder @13b6d03 (roots: > /home/tom/dev/playground/keycloak/keycloak-3.3.0.CR1-SNAPSHOT/modules,/home/tom/dev/playground/keycloak/keycloak-3.3.0.CR1-SNAPSHOT/modules/system/layers/keycloak,/home/tom/dev/playground/keycloak/keycloak-3.3.0.CR1-SNAPSHOT/modules/system/layers/base))] > > Cheers, > Thomas > > [0] > https://github.com/thomasdarimont/keycloak/commit/59a84df2f70623f11bd4d78771a4b91422fa0286 > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Thu Aug 3 10:04:24 2017 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 3 Aug 2017 16:04:24 +0200 Subject: [keycloak-dev] Blacklist Password Policy In-Reply-To: References: <337617da-bd59-0f4f-3040-f84ed50339f5@redhat.com> Message-ID: <1fa2a292-ad0d-af5c-87c0-80288169ac96@redhat.com> My vote is to throw an error if password list cannot be found on the filesystem. IMO it would be bad if admin has an impression that he just successfully configured blacklist password policy even if it doesn't work in reality. There should be rather error thrown, so admin is aware that it doesn't work. However the biggest issue with the PR is another dependency as Hynek pointed in PR and me in other thread. Marek On 03/08/17 12:28, Thomas Darimont wrote: > Hello, > > great that's just what I built :) here is the PR: > https://github.com/keycloak/keycloak/pull/4370 > > I'm not sure about the error handling if a configured password list > cannot be found on the filesystem. > https://github.com/keycloak/keycloak/pull/4370/files#diff-91236e069747f156edbd2c282fec8d92R78 > > Looking forward to your feedback :) > > Cheers, > Thomas > > 2017-08-03 12:11 GMT+02:00 Marek Posolda >: > > +1 for filesystem. > > Marek > > > On 29/07/17 10:06, Thomas Darimont wrote: > > Okay cool. > > Instead of storing the password blacklist in the database I > could instead > just refer to a password > blacklist that lives on the file system. > > So Keycloak could ship with some of the lists from [0] and > refer to those > with a name like "default-blacklist1000", > "default-blacklist-100000" > in the BlacklistPasswordPolicy > config > within the admin-console. > > The "default-blacklist-100000" blacklist would then be mapped > and resolve > to > something like > "META-INF/password-blacklist/10_million_password_list_top_100000.txt". > > Users could provide their own blacklists with the provider > config stored in > standalone.xml > than could then be adjusted via jboss-cli. > > I think this filesystem based approach is better than having > to load and > store big text-blobs in the database. > > Cheers, > Thomas > > [0] > https://github.com/danielmiessler/SecLists/tree/master/Passwords > > Using those password lists seems to be allowed according to > their license: > https://www.owasp.org/index.php/Projects/OWASP_SecLists_Project > > which is Creative Commons Attribution ShareAlike 3.0 License > -> IANAL but it seems to be useable in commercial products as well > https://creativecommons.org/licenses/by-sa/3.0/ > > as long as the authors are mentioned. > > > 2017-07-28 22:03 GMT+02:00 Bill Burke >: > > Yah, that sounds cool. > > > On 7/28/17 11:48 AM, Thomas Darimont wrote: > > Hello, > > I build a configurable Password Policy that allows to > match a given > password against > a blacklist with easy to guess passwords that should > be not allowed as > > user > > passwords. > > The 'BlacklistPasswordPolicyProvider' can be > configured via the admin UI > with a ";" delimited list of easy to guess passwords. > > If the user / or admin want's to change the password > it is checked > > against > > the blacklist. > A password list can be found here: > https://github.com/danielmiessler/SecLists/tree/master/Passwords > > > A blacklist is of course not a perfect solution but > could still be useful > for some users. > > Password blacklist would be compiled to a trie at > startup (and on changes > of the blacklist) > for efficient lookups. > > WDYT? > > Cheers, > Thomas > _______________________________________________ > 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 Shankar_Bhaskaran at infosys.com Fri Aug 4 01:09:56 2017 From: Shankar_Bhaskaran at infosys.com (Shankar_Bhaskaran) Date: Fri, 4 Aug 2017 05:09:56 +0000 Subject: [keycloak-dev] Keycloak and HAProxy Message-ID: <6f52043452674dd28d4fdea8950b89e4@CHNSHLMBX32.ad.infosys.com> Hi , We have configured HAProxy as our load balancer and keycloak (3.0) as our SSO. We have configured the keycloak domain and secured our wars with keycloak for our web application. In Haproxy we have provided the "forwardfor" option which introduces the header parameter -"X-Forwarded-For" and configured keycloak as given below to accept the header parameter as given below. "" But still the redirect from keycloak is going to HAProxy machine and not to backend servers with our webapp. Is there any help you can provide here Regards, Shankar From mposolda at redhat.com Fri Aug 4 04:09:31 2017 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 4 Aug 2017 10:09:31 +0200 Subject: [keycloak-dev] generic cli sso utility In-Reply-To: References: Message-ID: <0cfaaecd-51ab-eacb-cba3-a536acd6c943@redhat.com> I wonder if it's possible to have CLI utility, which is able to read HTML with the form and challenge user based on that? For example once it receives the HTML like this:
Username: Password:
Then in command line, user will be challenged for username and password. I am not sure if it's doable in practice and how much work it is. Sounds like re-implementing browser in command line. But maybe something like this exists already? BTV. Some things will never work in CLI in my opinion. For example: - Registration with captcha - TOTP setup - Broker login (but hopefully some brokers offer alternatives) Marek On 28/07/17 22:36, Bill Burke wrote: > I've developed a small command line utility around Keycloak Installed. > The idea is that this utility performs a login with keycloak to obtain > an access token. This utility saves the access and refresh token in a > file (similar to how ssh does in .ssh). Then bash scripts can be used to > export the access token as an environment variable so it can be used by > other command line utilities. > > > https://github.com/patriot1burke/keycloak/blob/master/adapters/oidc/installed/src/main/java/org/keycloak/adapters/installed/KeycloakCliSso.java > > https://github.com/patriot1burke/keycloak/tree/master/adapters/oidc/cli-sso > > > Eventually I'm thinking of creating a text/plain protocol with Keycloak > server so that launching a browser or cutting/pasting between the > command line window and browser isn't a requirement. It woudl be a plain > text challenge response protocol. This would require a bit more work as > it would require reworking all of our built in authenticators and > required action plugins. > > _______________________________________________ > 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 Aug 4 05:14:13 2017 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Fri, 4 Aug 2017 11:14:13 +0200 Subject: [keycloak-dev] Keycloak and HAProxy In-Reply-To: <6f52043452674dd28d4fdea8950b89e4@CHNSHLMBX32.ad.infosys.com> References: <6f52043452674dd28d4fdea8950b89e4@CHNSHLMBX32.ad.infosys.com> Message-ID: Hello Shankar, a while ago I built a demo-system with Keycloak running behind a ha-proxy with docker. Maybe this helps you a bit. https://github.com/jugsaar/visit-yajug-20161023-keycloak/tree/master/idm-system Cheers, Thomas 2017-08-04 7:09 GMT+02:00 Shankar_Bhaskaran : > Hi , > > We have configured HAProxy as our load balancer and keycloak (3.0) as our > SSO. We have configured the keycloak domain and secured our wars with > keycloak for our web application. > > In Haproxy we have provided the "forwardfor" option which introduces the > header parameter -"X-Forwarded-For" and configured keycloak as given below > to accept the header parameter as given below. > > " redirect-socket="https" proxy-address-forwarding="true"/>" > > But still the redirect from keycloak is going to HAProxy machine and not > to backend servers with our webapp. > > Is there any help you can provide here > > Regards, > Shankar > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From psilva at redhat.com Fri Aug 4 10:15:33 2017 From: psilva at redhat.com (Pedro Igor Silva) Date: Fri, 4 Aug 2017 11:15:33 -0300 Subject: [keycloak-dev] User Managed Access and UMA 2.0 Changes Message-ID: Hey All, Sorry for the long message, but I tried to highlight some important bits of what I'm doing :) I'm not done yet, so here are the ideas I'm considering .... I'm almost done with the initial changes to get the user managed access bits of UMA. Basically, this is about providing the backbone in order to support use cases such as resource sharing, authorization flows and users capable of managing their own resources. A really interesting feature set for IoT use cases as well those looking for giving more privacy control to their users (not only the security). In a nutshell, we have now a new entity in our model: * PermissionTicketEntity This entity holds all information we need in order to know which resource/scope was requested and when. Plus any additional claims the RS wants to associated with a permission request. This entity will allow us to perform: * Queries to obtain the person/entity that need to approve a permission request * Queries to obtain the person/entity looking for access * Queries to obtain the resources/scopes being requested * For how long a permission is valid * Which claims (contextual data pushed by the RS when issuing a permission ticket) are associated with a permission request and need to be approved by the owner and enforced by the RS. As you know, the UMA flow starts with a client trying to access a resource protected by a RS. At this moment the RS issues a *permission ticket* which then is returned to the client to give him a chance to obtain the RPT (token with the actual permissions) from the AS. Two things here: * Only resources that support "user/owner managed access" are supposed to have permission tickets persisted * The RS can set additional claims to the permission ticket in order to provide contextual data for policies and let them take any decision considering this data. E.g: I need to withdraw some money from my wife's bank account, but she just want to let me do it if the amount is <= $100 dollars. Basic sharing will be based on a simple approval/reject of a permission request (permission ticket). Please, let me know what you think. Thanks. From bubi at charmides.in-berlin.de Sun Aug 6 02:30:50 2017 From: bubi at charmides.in-berlin.de (Burghard Britzke) Date: Sun, 6 Aug 2017 08:30:50 +0200 Subject: [keycloak-dev] Searching for a class named org.keycloak.services.filters.ClientConnectionFilter References: <468FF9D7-636A-4A2E-8D96-CC9992DCA802@charmides.in-berlin.de> Message-ID: <35AE1E1D-4186-4335-81B4-D0338279AE90@charmides.in-berlin.de> I posted it already on the [keycloak-user] mailing list without a reply. I want to run the keycloak server on a tomcat 8/9 instance. For that, I found an article https://reachmnadeem.wordpress.com/2015/01/14/deploying-keycloak-in-tomcat/ which describes, how to deploy keycloak on tomcat. Unfortunately it describes the version 1.1.0-Beta2, which is very old. It his web.xml a filter is with the name org.keycloak.services.filters.ClientConnectionFilter referenced. When starting the context on tomcat8/9, a ClassNotFoundException is thrown. I have been unable to resolve the dependency in 1.1.0-Beta2 and 3.2.0-Final, too. The name of the class intends that it is from the keycloak project. Can anybody post me a hint, where to find this class? I also asked the author of the above article, but until now he did not answer. -- Gru? burghard.britzke https://britzke.berlin/ > Anfang der weitergeleiteten Nachricht: > > An: keycloak-user at lists.jboss.org > > in order to run a keycloak-server on tomcat, I am searching for a class named org.keycloak.services.filters.ClientConnectionFilter. Could anybody send me a hint where to find it? Could anybody share a link to a documentation of this filter? > -- > Gru? > burghard.britzke > https://britzke.berlin/ > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From bart.toersche at simacan.com Wed Aug 9 05:33:08 2017 From: bart.toersche at simacan.com (Bart Toersche) Date: Wed, 9 Aug 2017 11:33:08 +0200 Subject: [keycloak-dev] Unexpected behavior: Obtaining new access tokens with an access token Message-ID: Hi, I would like to report some unexpected behavior while requesting access- and refresh token pairs. It is possible to obtain a new access- and refresh token pair using only an access token. To describe this more thoroughly; If someone obtained a valid access token s/he can obtain a new access- and refresh token pair without ever knowing the refresh token. The problem is that refresh tokens never leave the client except when requesting a new one at the authorization server. However, the access token is sent to resource servers for obtaining resources (obviously). But now a resource server is actually able to obtain a new access- and refresh token pair on behalf of the user as well, which was never the user's intention (since it can keep a valid token indefinitely by refreshing it). Of course, since the resource server doesn't have client credentials for private clients it cannot obtain a new access- and refresh token pair for those. However, it can do so for public clients as only their name is known. (In fact, it is available in the "azp" claim of the access token.) Steps to reproduce (I tested this with a clean setup of Keycloak 3.2.0-Final): 1. We will use the admin-cli client and the admin account. You can do this with any client and account, but since this is already set up for this particular example, it makes things a bit more easy. 2. Using the admin account, fetch a new access- and refresh token pair using any grant type. We will be using the password grant: curl --data "client_id=admin-cli&grant_type=password&username=&password=" http://localhost:8080/auth/ realms/master/protocol/openid-connect/token 3. Grab the access_token value from the response and perform a refresh grant using this access token: curl --data "client_id=admin-cli&grant_type=refresh_token&refresh_ token=" http://localhost:8080/auth/ realms/master/protocol/openid-connect/token 4. You will now have a response including a new access- and refresh token pair. This unexpected behavior can be solved by either checking the "typ" claim to be set to "Refresh", or, when time allows, using a different signing secret for the access- and refresh tokens. I would prefer the latter solution. Thanks in advance, Bart Toersche From mposolda at redhat.com Wed Aug 9 06:12:54 2017 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 9 Aug 2017 12:12:54 +0200 Subject: [keycloak-dev] Adding notBefore to user? Message-ID: <5e3fd697-c004-1b4d-eca6-aae9e7833b3e@redhat.com> I am thinking about adding notBefore to user. It will be updated when user logouts in Account management or when admin logouts user in admin console. I am thinking about this because in cross-dc environment, it can happen under some circumstances that particular userSession "123" is not available in infinispan cache on any Keycloak server, however it's available on the remoteCache on JDG server. So it can happen that: - Admin press "Logout all sessions", but session 123 won't be affected as it's available just on remoteCache - Someone (attacker) sends refresh token for session 123. It will be loaded from remoteCache store to Keycloak cache and will be treated as valid session. Do you think it's bad idea to add notBefore to user? There may be some other ways to mitigate the issue if you think it's bad. I am thinking about adding it to separate table, so it's persistent among server restarts even for users from federated user storages. Something similar to like consents are saved. WDYT? Marek From bburke at redhat.com Wed Aug 9 10:08:29 2017 From: bburke at redhat.com (Bill Burke) Date: Wed, 9 Aug 2017 10:08:29 -0400 Subject: [keycloak-dev] Adding notBefore to user? In-Reply-To: <5e3fd697-c004-1b4d-eca6-aae9e7833b3e@redhat.com> References: <5e3fd697-c004-1b4d-eca6-aae9e7833b3e@redhat.com> Message-ID: <45e6831f-3ca7-5b46-4b41-69be08259c00@redhat.com> What if the user has multiple sessions and only wants to log out of one? On 8/9/17 6:12 AM, Marek Posolda wrote: > I am thinking about adding notBefore to user. It will be updated when > user logouts in Account management or when admin logouts user in admin > console. > > I am thinking about this because in cross-dc environment, it can happen > under some circumstances that particular userSession "123" is not > available in infinispan cache on any Keycloak server, however it's > available on the remoteCache on JDG server. So it can happen that: > - Admin press "Logout all sessions", but session 123 won't be affected > as it's available just on remoteCache > - Someone (attacker) sends refresh token for session 123. It will be > loaded from remoteCache store to Keycloak cache and will be treated as > valid session. > > Do you think it's bad idea to add notBefore to user? There may be some > other ways to mitigate the issue if you think it's bad. > > I am thinking about adding it to separate table, so it's persistent > among server restarts even for users from federated user storages. > Something similar to like consents are saved. WDYT? > > Marek > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Wed Aug 9 10:22:24 2017 From: bburke at redhat.com (Bill Burke) Date: Wed, 9 Aug 2017 10:22:24 -0400 Subject: [keycloak-dev] account service REST API? Message-ID: <7d49651b-8fd8-b225-f0d1-0c1d4a5a2cc8@redhat.com> The AccountService class was originally intended to be both a browser service as well as a REST API. Some endpoints on AccountService don't work. Should I be fixing the Account Service for REST invocations? Are we still indending the AccountService to be accessible via REST calls? From mposolda at redhat.com Wed Aug 9 11:08:57 2017 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 9 Aug 2017 17:08:57 +0200 Subject: [keycloak-dev] Adding notBefore to user? In-Reply-To: <45e6831f-3ca7-5b46-4b41-69be08259c00@redhat.com> References: <5e3fd697-c004-1b4d-eca6-aae9e7833b3e@redhat.com> <45e6831f-3ca7-5b46-4b41-69be08259c00@redhat.com> Message-ID: I am thinking that logout of single concrete session won't update notBefore. Just "Logout all sessions" for concrete user will update it for this user. I assume that admin or user usually use "Logout all" if he thinks that something was broken (password compromised, mobile phone steal etc)? BTV. Admin console has support for logout of single session as well as logout all. However account management has support just for "logout all" ATM. Maybe something useful to add? Marek On 09/08/17 16:08, Bill Burke wrote: > What if the user has multiple sessions and only wants to log out of one? > > > On 8/9/17 6:12 AM, Marek Posolda wrote: >> I am thinking about adding notBefore to user. It will be updated when >> user logouts in Account management or when admin logouts user in admin >> console. >> >> I am thinking about this because in cross-dc environment, it can happen >> under some circumstances that particular userSession "123" is not >> available in infinispan cache on any Keycloak server, however it's >> available on the remoteCache on JDG server. So it can happen that: >> - Admin press "Logout all sessions", but session 123 won't be affected >> as it's available just on remoteCache >> - Someone (attacker) sends refresh token for session 123. It will be >> loaded from remoteCache store to Keycloak cache and will be treated as >> valid session. >> >> Do you think it's bad idea to add notBefore to user? There may be some >> other ways to mitigate the issue if you think it's bad. >> >> I am thinking about adding it to separate table, so it's persistent >> among server restarts even for users from federated user storages. >> Something similar to like consents are saved. WDYT? >> >> Marek >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Wed Aug 9 11:12:51 2017 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 9 Aug 2017 17:12:51 +0200 Subject: [keycloak-dev] account service REST API? In-Reply-To: <7d49651b-8fd8-b225-f0d1-0c1d4a5a2cc8@redhat.com> References: <7d49651b-8fd8-b225-f0d1-0c1d4a5a2cc8@redhat.com> Message-ID: I think that Stian already started on REST support in AccountService. I saw some commits around this some time ago. But it's probably not yet pushed, just somewhere in his private repo. Not 100% sure.. Marek On 09/08/17 16:22, Bill Burke wrote: > The AccountService class was originally intended to be both a browser > service as well as a REST API. Some endpoints on AccountService don't > work. Should I be fixing the Account Service for REST invocations? Are > we still indending the AccountService to be accessible via REST calls? > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From ssilvert at redhat.com Wed Aug 9 11:17:37 2017 From: ssilvert at redhat.com (Stan Silvert) Date: Wed, 9 Aug 2017 11:17:37 -0400 Subject: [keycloak-dev] account service REST API? In-Reply-To: References: <7d49651b-8fd8-b225-f0d1-0c1d4a5a2cc8@redhat.com> Message-ID: <7ec6f5d7-41a8-2728-c7a6-c588f820e90c@redhat.com> Yes, this is being worked on by Stian and myself. It's in a private repo now but we will probably merge to master soon after he returns from holiday. Stan On 8/9/2017 11:12 AM, Marek Posolda wrote: > I think that Stian already started on REST support in AccountService. I > saw some commits around this some time ago. But it's probably not yet > pushed, just somewhere in his private repo. Not 100% sure.. > > Marek > > On 09/08/17 16:22, Bill Burke wrote: >> The AccountService class was originally intended to be both a browser >> service as well as a REST API. Some endpoints on AccountService don't >> work. Should I be fixing the Account Service for REST invocations? Are >> we still indending the AccountService to be accessible via REST calls? >> >> _______________________________________________ >> 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 bburke at redhat.com Wed Aug 9 14:19:47 2017 From: bburke at redhat.com (Bill Burke) Date: Wed, 9 Aug 2017 14:19:47 -0400 Subject: [keycloak-dev] account service REST API? In-Reply-To: <7ec6f5d7-41a8-2728-c7a6-c588f820e90c@redhat.com> References: <7d49651b-8fd8-b225-f0d1-0c1d4a5a2cc8@redhat.com> <7ec6f5d7-41a8-2728-c7a6-c588f820e90c@redhat.com> Message-ID: <81fe7205-1b5f-042c-24fd-e54f44dee563@redhat.com> Right now there's no way to unlink accounts, which is why i ask. On 8/9/17 11:17 AM, Stan Silvert wrote: > Yes, this is being worked on by Stian and myself. It's in a private > repo now but we will probably merge to master soon after he returns from > holiday. > > Stan > > On 8/9/2017 11:12 AM, Marek Posolda wrote: >> I think that Stian already started on REST support in AccountService. I >> saw some commits around this some time ago. But it's probably not yet >> pushed, just somewhere in his private repo. Not 100% sure.. >> >> Marek >> >> On 09/08/17 16:22, Bill Burke wrote: >>> The AccountService class was originally intended to be both a browser >>> service as well as a REST API. Some endpoints on AccountService don't >>> work. Should I be fixing the Account Service for REST invocations? Are >>> we still indending the AccountService to be accessible via REST calls? >>> >>> _______________________________________________ >>> 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 bburke at redhat.com Wed Aug 9 14:20:21 2017 From: bburke at redhat.com (Bill Burke) Date: Wed, 9 Aug 2017 14:20:21 -0400 Subject: [keycloak-dev] Adding notBefore to user? In-Reply-To: References: <5e3fd697-c004-1b4d-eca6-aae9e7833b3e@redhat.com> <45e6831f-3ca7-5b46-4b41-69be08259c00@redhat.com> Message-ID: <33c2d1b5-8028-82de-0145-1850f78c849b@redhat.com> I think that works then what you are proposing. On 8/9/17 11:08 AM, Marek Posolda wrote: > I am thinking that logout of single concrete session won't update > notBefore. Just "Logout all sessions" for concrete user will update it > for this user. I assume that admin or user usually use "Logout all" if > he thinks that something was broken (password compromised, mobile > phone steal etc)? > > BTV. Admin console has support for logout of single session as well as > logout all. However account management has support just for "logout > all" ATM. Maybe something useful to add? > > Marek > > On 09/08/17 16:08, Bill Burke wrote: >> What if the user has multiple sessions and only wants to log out of one? >> >> >> On 8/9/17 6:12 AM, Marek Posolda wrote: >>> I am thinking about adding notBefore to user. It will be updated when >>> user logouts in Account management or when admin logouts user in admin >>> console. >>> >>> I am thinking about this because in cross-dc environment, it can happen >>> under some circumstances that particular userSession "123" is not >>> available in infinispan cache on any Keycloak server, however it's >>> available on the remoteCache on JDG server. So it can happen that: >>> - Admin press "Logout all sessions", but session 123 won't be affected >>> as it's available just on remoteCache >>> - Someone (attacker) sends refresh token for session 123. It will be >>> loaded from remoteCache store to Keycloak cache and will be treated as >>> valid session. >>> >>> Do you think it's bad idea to add notBefore to user? There may be some >>> other ways to mitigate the issue if you think it's bad. >>> >>> I am thinking about adding it to separate table, so it's persistent >>> among server restarts even for users from federated user storages. >>> Something similar to like consents are saved. WDYT? >>> >>> Marek >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > From bruno at abstractj.org Wed Aug 9 16:06:22 2017 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 09 Aug 2017 20:06:22 +0000 Subject: [keycloak-dev] Blacklist Password Policy In-Reply-To: <1fa2a292-ad0d-af5c-87c0-80288169ac96@redhat.com> References: <337617da-bd59-0f4f-3040-f84ed50339f5@redhat.com> <1fa2a292-ad0d-af5c-87c0-80288169ac96@redhat.com> Message-ID: A little bit late for the discussion, but today I was looking into this http://www.kitploit.com/2017/08/jwt-cracker-simple-hs256-jwt-token.html and wondering if we would be interesting to provide the same for client secrets. Just to prevent weak secrets. Of course this is out of the scope for this implementation. But maybe a nice to have. On Thu, Aug 3, 2017 at 11:31 AM Marek Posolda wrote: > My vote is to throw an error if password list cannot be found on the > filesystem. IMO it would be bad if admin has an impression that he just > successfully configured blacklist password policy even if it doesn't > work in reality. There should be rather error thrown, so admin is aware > that it doesn't work. > > However the biggest issue with the PR is another dependency as Hynek > pointed in PR and me in other thread. > > Marek > > > On 03/08/17 12:28, Thomas Darimont wrote: > > Hello, > > > > great that's just what I built :) here is the PR: > > https://github.com/keycloak/keycloak/pull/4370 > > > > I'm not sure about the error handling if a configured password list > > cannot be found on the filesystem. > > > https://github.com/keycloak/keycloak/pull/4370/files#diff-91236e069747f156edbd2c282fec8d92R78 > > > > Looking forward to your feedback :) > > > > Cheers, > > Thomas > > > > 2017-08-03 12:11 GMT+02:00 Marek Posolda > >: > > > > +1 for filesystem. > > > > Marek > > > > > > On 29/07/17 10:06, Thomas Darimont wrote: > > > > Okay cool. > > > > Instead of storing the password blacklist in the database I > > could instead > > just refer to a password > > blacklist that lives on the file system. > > > > So Keycloak could ship with some of the lists from [0] and > > refer to those > > with a name like "default-blacklist1000", > > "default-blacklist-100000" > > in the BlacklistPasswordPolicy > > config > > within the admin-console. > > > > The "default-blacklist-100000" blacklist would then be mapped > > and resolve > > to > > something like > > > "META-INF/password-blacklist/10_million_password_list_top_100000.txt". > > > > Users could provide their own blacklists with the provider > > config stored in > > standalone.xml > > than could then be adjusted via jboss-cli. > > > > I think this filesystem based approach is better than having > > to load and > > store big text-blobs in the database. > > > > Cheers, > > Thomas > > > > [0] > > https://github.com/danielmiessler/SecLists/tree/master/Passwords > > < > https://github.com/danielmiessler/SecLists/tree/master/Passwords> > > Using those password lists seems to be allowed according to > > their license: > > https://www.owasp.org/index.php/Projects/OWASP_SecLists_Project > > > > > which is Creative Commons Attribution ShareAlike 3.0 License > > -> IANAL but it seems to be useable in commercial products as > well > > https://creativecommons.org/licenses/by-sa/3.0/ > > > > as long as the authors are mentioned. > > > > > > 2017-07-28 22:03 GMT+02:00 Bill Burke > >: > > > > Yah, that sounds cool. > > > > > > On 7/28/17 11:48 AM, Thomas Darimont wrote: > > > > Hello, > > > > I build a configurable Password Policy that allows to > > match a given > > password against > > a blacklist with easy to guess passwords that should > > be not allowed as > > > > user > > > > passwords. > > > > The 'BlacklistPasswordPolicyProvider' can be > > configured via the admin UI > > with a ";" delimited list of easy to guess passwords. > > > > If the user / or admin want's to change the password > > it is checked > > > > against > > > > the blacklist. > > A password list can be found here: > > > https://github.com/danielmiessler/SecLists/tree/master/Passwords > > < > https://github.com/danielmiessler/SecLists/tree/master/Passwords> > > > > A blacklist is of course not a perfect solution but > > could still be useful > > for some users. > > > > Password blacklist would be compiled to a trie at > > startup (and on changes > > of the blacklist) > > for efficient lookups. > > > > WDYT? > > > > Cheers, > > Thomas > > _______________________________________________ > > 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 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 ssilvert at redhat.com Wed Aug 9 16:33:43 2017 From: ssilvert at redhat.com (Stan Silvert) Date: Wed, 9 Aug 2017 16:33:43 -0400 Subject: [keycloak-dev] account service REST API? In-Reply-To: <81fe7205-1b5f-042c-24fd-e54f44dee563@redhat.com> References: <7d49651b-8fd8-b225-f0d1-0c1d4a5a2cc8@redhat.com> <7ec6f5d7-41a8-2728-c7a6-c588f820e90c@redhat.com> <81fe7205-1b5f-042c-24fd-e54f44dee563@redhat.com> Message-ID: <179c19da-be19-e288-67d3-3700f85d079c@redhat.com> If you want to go ahead and write REST support for that then I don't think you will be interfering with anything we are doing. Right now, what we have is not very comprehensive. It's just enough to add a little live data to the new account console. On 8/9/2017 2:19 PM, Bill Burke wrote: > Right now there's no way to unlink accounts, which is why i ask. > > > On 8/9/17 11:17 AM, Stan Silvert wrote: >> Yes, this is being worked on by Stian and myself. It's in a private >> repo now but we will probably merge to master soon after he returns from >> holiday. >> >> Stan >> >> On 8/9/2017 11:12 AM, Marek Posolda wrote: >>> I think that Stian already started on REST support in AccountService. I >>> saw some commits around this some time ago. But it's probably not yet >>> pushed, just somewhere in his private repo. Not 100% sure.. >>> >>> Marek >>> >>> On 09/08/17 16:22, Bill Burke wrote: >>>> The AccountService class was originally intended to be both a browser >>>> service as well as a REST API. Some endpoints on AccountService don't >>>> work. Should I be fixing the Account Service for REST invocations? Are >>>> we still indending the AccountService to be accessible via REST calls? >>>> >>>> _______________________________________________ >>>> 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 > _______________________________________________ > 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 Aug 9 18:32:14 2017 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Thu, 10 Aug 2017 00:32:14 +0200 Subject: [keycloak-dev] Blacklist Password Policy In-Reply-To: References: <337617da-bd59-0f4f-3040-f84ed50339f5@redhat.com> <1fa2a292-ad0d-af5c-87c0-80288169ac96@redhat.com> Message-ID: Good point! Thanks for the hint Bruno :) 2017-08-09 22:06 GMT+02:00 Bruno Oliveira : > A little bit late for the discussion, but today I was looking into this > http://www.kitploit.com/2017/08/jwt-cracker-simple-hs256-jwt-token.html and > wondering if we would be interesting to provide the same for client > secrets. Just to prevent weak secrets. > > Of course this is out of the scope for this implementation. But maybe a > nice to have. > > On Thu, Aug 3, 2017 at 11:31 AM Marek Posolda wrote: > >> My vote is to throw an error if password list cannot be found on the >> filesystem. IMO it would be bad if admin has an impression that he just >> successfully configured blacklist password policy even if it doesn't >> work in reality. There should be rather error thrown, so admin is aware >> that it doesn't work. >> >> However the biggest issue with the PR is another dependency as Hynek >> pointed in PR and me in other thread. >> >> Marek >> >> >> On 03/08/17 12:28, Thomas Darimont wrote: >> > Hello, >> > >> > great that's just what I built :) here is the PR: >> > https://github.com/keycloak/keycloak/pull/4370 >> > >> > I'm not sure about the error handling if a configured password list >> > cannot be found on the filesystem. >> > https://github.com/keycloak/keycloak/pull/4370/files#diff- >> 91236e069747f156edbd2c282fec8d92R78 >> > >> > Looking forward to your feedback :) >> > >> > Cheers, >> > Thomas >> > >> > 2017-08-03 12:11 GMT+02:00 Marek Posolda > > >: >> >> > >> > +1 for filesystem. >> > >> > Marek >> > >> > >> > On 29/07/17 10:06, Thomas Darimont wrote: >> > >> > Okay cool. >> > >> > Instead of storing the password blacklist in the database I >> > could instead >> > just refer to a password >> > blacklist that lives on the file system. >> > >> > So Keycloak could ship with some of the lists from [0] and >> > refer to those >> > with a name like "default-blacklist1000", >> > "default-blacklist-100000" >> > in the BlacklistPasswordPolicy >> > config >> > within the admin-console. >> > >> > The "default-blacklist-100000" blacklist would then be mapped >> > and resolve >> > to >> > something like >> > "META-INF/password-blacklist/10_million_password_list_top_ >> 100000.txt". >> > >> > Users could provide their own blacklists with the provider >> > config stored in >> > standalone.xml >> > than could then be adjusted via jboss-cli. >> > >> > I think this filesystem based approach is better than having >> > to load and >> > store big text-blobs in the database. >> > >> > Cheers, >> > Thomas >> > >> > [0] >> > https://github.com/danielmiessler/SecLists/tree/ >> master/Passwords >> > > master/Passwords> >> > Using those password lists seems to be allowed according to >> > their license: >> > https://www.owasp.org/index.php/Projects/OWASP_SecLists_Project >> > > Project> >> > which is Creative Commons Attribution ShareAlike 3.0 License >> > -> IANAL but it seems to be useable in commercial products as >> well >> > https://creativecommons.org/licenses/by-sa/3.0/ >> > >> > as long as the authors are mentioned. >> > >> > >> > 2017-07-28 22:03 GMT+02:00 Bill Burke > > >: >> >> > >> > Yah, that sounds cool. >> > >> > >> > On 7/28/17 11:48 AM, Thomas Darimont wrote: >> > >> > Hello, >> > >> > I build a configurable Password Policy that allows to >> > match a given >> > password against >> > a blacklist with easy to guess passwords that should >> > be not allowed as >> > >> > user >> > >> > passwords. >> > >> > The 'BlacklistPasswordPolicyProvider' can be >> > configured via the admin UI >> > with a ";" delimited list of easy to guess passwords. >> > >> > If the user / or admin want's to change the password >> > it is checked >> > >> > against >> > >> > the blacklist. >> > A password list can be found here: >> > https://github.com/danielmiessler/SecLists/tree/ >> master/Passwords >> > > master/Passwords> >> > >> > A blacklist is of course not a perfect solution but >> > could still be useful >> > for some users. >> > >> > Password blacklist would be compiled to a trie at >> > startup (and on changes >> > of the blacklist) >> > for efficient lookups. >> > >> > WDYT? >> > >> > Cheers, >> > Thomas >> > _______________________________________________ >> > 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 > 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 Thu Aug 10 07:03:57 2017 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 10 Aug 2017 11:03:57 +0000 Subject: [keycloak-dev] Blacklist Password Policy In-Reply-To: References: <337617da-bd59-0f4f-3040-f84ed50339f5@redhat.com> <1fa2a292-ad0d-af5c-87c0-80288169ac96@redhat.com> Message-ID: In order to not miss this, I just created the following jiras: https://issues.jboss.org/browse/KEYCLOAK-5275 https://issues.jboss.org/browse/KEYCLOAK-5276 On Wed, Aug 9, 2017 at 5:06 PM Bruno Oliveira wrote: > A little bit late for the discussion, but today I was looking into this > http://www.kitploit.com/2017/08/jwt-cracker-simple-hs256-jwt-token.html and > wondering if we would be interesting to provide the same for client > secrets. Just to prevent weak secrets. > > Of course this is out of the scope for this implementation. But maybe a > nice to have. > > On Thu, Aug 3, 2017 at 11:31 AM Marek Posolda wrote: > >> My vote is to throw an error if password list cannot be found on the >> filesystem. IMO it would be bad if admin has an impression that he just >> successfully configured blacklist password policy even if it doesn't >> work in reality. There should be rather error thrown, so admin is aware >> that it doesn't work. >> >> However the biggest issue with the PR is another dependency as Hynek >> pointed in PR and me in other thread. >> >> Marek >> >> >> On 03/08/17 12:28, Thomas Darimont wrote: >> > Hello, >> > >> > great that's just what I built :) here is the PR: >> > https://github.com/keycloak/keycloak/pull/4370 >> > >> > I'm not sure about the error handling if a configured password list >> > cannot be found on the filesystem. >> > >> https://github.com/keycloak/keycloak/pull/4370/files#diff-91236e069747f156edbd2c282fec8d92R78 >> > >> > Looking forward to your feedback :) >> > >> > Cheers, >> > Thomas >> > >> > 2017-08-03 12:11 GMT+02:00 Marek Posolda > > >: >> > >> > +1 for filesystem. >> > >> > Marek >> > >> > >> > On 29/07/17 10:06, Thomas Darimont wrote: >> > >> > Okay cool. >> > >> > Instead of storing the password blacklist in the database I >> > could instead >> > just refer to a password >> > blacklist that lives on the file system. >> > >> > So Keycloak could ship with some of the lists from [0] and >> > refer to those >> > with a name like "default-blacklist1000", >> > "default-blacklist-100000" >> > in the BlacklistPasswordPolicy >> > config >> > within the admin-console. >> > >> > The "default-blacklist-100000" blacklist would then be mapped >> > and resolve >> > to >> > something like >> > >> "META-INF/password-blacklist/10_million_password_list_top_100000.txt". >> > >> > Users could provide their own blacklists with the provider >> > config stored in >> > standalone.xml >> > than could then be adjusted via jboss-cli. >> > >> > I think this filesystem based approach is better than having >> > to load and >> > store big text-blobs in the database. >> > >> > Cheers, >> > Thomas >> > >> > [0] >> > >> https://github.com/danielmiessler/SecLists/tree/master/Passwords >> > < >> https://github.com/danielmiessler/SecLists/tree/master/Passwords> >> > Using those password lists seems to be allowed according to >> > their license: >> > https://www.owasp.org/index.php/Projects/OWASP_SecLists_Project >> > < >> https://www.owasp.org/index.php/Projects/OWASP_SecLists_Project> >> > which is Creative Commons Attribution ShareAlike 3.0 License >> > -> IANAL but it seems to be useable in commercial products as >> well >> > https://creativecommons.org/licenses/by-sa/3.0/ >> > >> > as long as the authors are mentioned. >> > >> > >> > 2017-07-28 22:03 GMT+02:00 Bill Burke > > >: >> > >> > Yah, that sounds cool. >> > >> > >> > On 7/28/17 11:48 AM, Thomas Darimont wrote: >> > >> > Hello, >> > >> > I build a configurable Password Policy that allows to >> > match a given >> > password against >> > a blacklist with easy to guess passwords that should >> > be not allowed as >> > >> > user >> > >> > passwords. >> > >> > The 'BlacklistPasswordPolicyProvider' can be >> > configured via the admin UI >> > with a ";" delimited list of easy to guess passwords. >> > >> > If the user / or admin want's to change the password >> > it is checked >> > >> > against >> > >> > the blacklist. >> > A password list can be found here: >> > >> https://github.com/danielmiessler/SecLists/tree/master/Passwords >> > < >> https://github.com/danielmiessler/SecLists/tree/master/Passwords> >> > >> > A blacklist is of course not a perfect solution but >> > could still be useful >> > for some users. >> > >> > Password blacklist would be compiled to a trie at >> > startup (and on changes >> > of the blacklist) >> > for efficient lookups. >> > >> > WDYT? >> > >> > Cheers, >> > Thomas >> > _______________________________________________ >> > 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 > 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 Thu Aug 10 13:44:01 2017 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Thu, 10 Aug 2017 19:44:01 +0200 Subject: [keycloak-dev] Blacklist Password Policy In-Reply-To: References: <337617da-bd59-0f4f-3040-f84ed50339f5@redhat.com> <1fa2a292-ad0d-af5c-87c0-80288169ac96@redhat.com> Message-ID: Some more food for thought... I came up with another idea for efficiently deal with large password blacklists. Instead of having the plain passwords as a TreeSet (as in the current PR) or encoding it into something like a Radix Tree / PatriciaTrie one can also use a BloomFilter [0]. A password blacklist would be loaded into a Bloomfilter. If the filter does not contain a given password then it is definitely not blacklisted, which means the user can use it. If the filter says it contains the value - which could be a false positive (with a configurable probability) one could tell the user to use a different password (or check the password list on disk just to be sure)... A Bloomfilter with 1e7 elements and a false positive rate of 1 in a million takes 36mb memory [1] There is Java-BloomFilter [2] - a single Java class that one can copy into the project if one keeps the LGPL comment in place (as stated on their github page). Perhaps this would be another option. I think password blacklists are another layer of security of which some say are superior to some rule based password policies - as discussed in [3] [0] https://en.wikipedia.org/wiki/Bloom_filter [1] https://hur.st/bloomfilter?n=10000000&p=1.0E-6 [2] https://github.com/MagnusS/Java-BloomFilter [3] https://nakedsecurity.sophos.com/2016/08/18/nists-new-password-rules-what-you-need-to-know/ Cheers, Thomas 2017-08-10 13:03 GMT+02:00 Bruno Oliveira : > In order to not miss this, I just created the following jiras: > > https://issues.jboss.org/browse/KEYCLOAK-5275 > https://issues.jboss.org/browse/KEYCLOAK-5276 > > > On Wed, Aug 9, 2017 at 5:06 PM Bruno Oliveira wrote: > >> A little bit late for the discussion, but today I was looking into this >> http://www.kitploit.com/2017/08/jwt-cracker-simple-hs256-jwt-token.html and >> wondering if we would be interesting to provide the same for client >> secrets. Just to prevent weak secrets. >> >> Of course this is out of the scope for this implementation. But maybe a >> nice to have. >> >> On Thu, Aug 3, 2017 at 11:31 AM Marek Posolda >> wrote: >> >>> My vote is to throw an error if password list cannot be found on the >>> filesystem. IMO it would be bad if admin has an impression that he just >>> successfully configured blacklist password policy even if it doesn't >>> work in reality. There should be rather error thrown, so admin is aware >>> that it doesn't work. >>> >>> However the biggest issue with the PR is another dependency as Hynek >>> pointed in PR and me in other thread. >>> >>> Marek >>> >>> >>> On 03/08/17 12:28, Thomas Darimont wrote: >>> > Hello, >>> > >>> > great that's just what I built :) here is the PR: >>> > https://github.com/keycloak/keycloak/pull/4370 >>> > >>> > I'm not sure about the error handling if a configured password list >>> > cannot be found on the filesystem. >>> > https://github.com/keycloak/keycloak/pull/4370/files#diff- >>> 91236e069747f156edbd2c282fec8d92R78 >>> > >>> > Looking forward to your feedback :) >>> > >>> > Cheers, >>> > Thomas >>> > >>> > 2017-08-03 12:11 GMT+02:00 Marek Posolda >> > >: >>> > >>> > +1 for filesystem. >>> > >>> > Marek >>> > >>> > >>> > On 29/07/17 10:06, Thomas Darimont wrote: >>> > >>> > Okay cool. >>> > >>> > Instead of storing the password blacklist in the database I >>> > could instead >>> > just refer to a password >>> > blacklist that lives on the file system. >>> > >>> > So Keycloak could ship with some of the lists from [0] and >>> > refer to those >>> > with a name like "default-blacklist1000", >>> > "default-blacklist-100000" >>> > in the BlacklistPasswordPolicy >>> > config >>> > within the admin-console. >>> > >>> > The "default-blacklist-100000" blacklist would then be mapped >>> > and resolve >>> > to >>> > something like >>> > "META-INF/password-blacklist/10_million_password_list_top_ >>> 100000.txt". >>> > >>> > Users could provide their own blacklists with the provider >>> > config stored in >>> > standalone.xml >>> > than could then be adjusted via jboss-cli. >>> > >>> > I think this filesystem based approach is better than having >>> > to load and >>> > store big text-blobs in the database. >>> > >>> > Cheers, >>> > Thomas >>> > >>> > [0] >>> > https://github.com/danielmiessler/SecLists/tree/ >>> master/Passwords >>> > >> master/Passwords> >>> > Using those password lists seems to be allowed according to >>> > their license: >>> > https://www.owasp.org/index.php/Projects/OWASP_SecLists_ >>> Project >>> > >> Project> >>> > which is Creative Commons Attribution ShareAlike 3.0 License >>> > -> IANAL but it seems to be useable in commercial products as >>> well >>> > https://creativecommons.org/licenses/by-sa/3.0/ >>> > >>> > as long as the authors are mentioned. >>> > >>> > >>> > 2017-07-28 22:03 GMT+02:00 Bill Burke >> > >: >>> > >>> > Yah, that sounds cool. >>> > >>> > >>> > On 7/28/17 11:48 AM, Thomas Darimont wrote: >>> > >>> > Hello, >>> > >>> > I build a configurable Password Policy that allows to >>> > match a given >>> > password against >>> > a blacklist with easy to guess passwords that should >>> > be not allowed as >>> > >>> > user >>> > >>> > passwords. >>> > >>> > The 'BlacklistPasswordPolicyProvider' can be >>> > configured via the admin UI >>> > with a ";" delimited list of easy to guess passwords. >>> > >>> > If the user / or admin want's to change the password >>> > it is checked >>> > >>> > against >>> > >>> > the blacklist. >>> > A password list can be found here: >>> > https://github.com/danielmiessler/SecLists/tree/ >>> master/Passwords >>> > >> master/Passwords> >>> > >>> > A blacklist is of course not a perfect solution but >>> > could still be useful >>> > for some users. >>> > >>> > Password blacklist would be compiled to a trie at >>> > startup (and on changes >>> > of the blacklist) >>> > for efficient lookups. >>> > >>> > WDYT? >>> > >>> > Cheers, >>> > Thomas >>> > _______________________________________________ >>> > 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 >> 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 bburke at redhat.com Fri Aug 11 11:48:12 2017 From: bburke at redhat.com (Bill Burke) Date: Fri, 11 Aug 2017 11:48:12 -0400 Subject: [keycloak-dev] Blacklist Password Policy In-Reply-To: References: <337617da-bd59-0f4f-3040-f84ed50339f5@redhat.com> <1fa2a292-ad0d-af5c-87c0-80288169ac96@redhat.com> Message-ID: <35772d2d-8b0e-5f37-c38b-c6369e2e8f48@redhat.com> Great research Thomas. Would definitely be interested in incorporating this. On 8/10/17 1:44 PM, Thomas Darimont wrote: > Some more food for thought... > > I came up with another idea for efficiently deal with large password > blacklists. > > Instead of having the plain passwords as a TreeSet (as in the current PR) > or encoding it into something like a Radix Tree / PatriciaTrie one can also > use a BloomFilter [0]. > > A password blacklist would be loaded into a Bloomfilter. > If the filter does not contain a given password then it is definitely not > blacklisted, > which means the user can use it. > If the filter says it contains the value - which could be a false positive > (with a configurable probability) > one could tell the user to use a different password (or check the password > list on disk just to be sure)... > > A Bloomfilter with 1e7 elements and a false positive rate of 1 in a million > takes 36mb memory [1] > > There is Java-BloomFilter [2] - a single Java class that one can copy into > the project if one keeps the LGPL comment in place (as stated on their > github page). > > Perhaps this would be another option. > > I think password blacklists are another layer of security of which some say > are superior to some > rule based password policies - as discussed in [3] > > [0] https://en.wikipedia.org/wiki/Bloom_filter > [1] https://hur.st/bloomfilter?n=10000000&p=1.0E-6 > [2] https://github.com/MagnusS/Java-BloomFilter > [3] > https://nakedsecurity.sophos.com/2016/08/18/nists-new-password-rules-what-you-need-to-know/ > > Cheers, > Thomas > > > 2017-08-10 13:03 GMT+02:00 Bruno Oliveira : > >> In order to not miss this, I just created the following jiras: >> >> https://issues.jboss.org/browse/KEYCLOAK-5275 >> https://issues.jboss.org/browse/KEYCLOAK-5276 >> >> >> On Wed, Aug 9, 2017 at 5:06 PM Bruno Oliveira wrote: >> >>> A little bit late for the discussion, but today I was looking into this >>> http://www.kitploit.com/2017/08/jwt-cracker-simple-hs256-jwt-token.html and >>> wondering if we would be interesting to provide the same for client >>> secrets. Just to prevent weak secrets. >>> >>> Of course this is out of the scope for this implementation. But maybe a >>> nice to have. >>> >>> On Thu, Aug 3, 2017 at 11:31 AM Marek Posolda >>> wrote: >>> >>>> My vote is to throw an error if password list cannot be found on the >>>> filesystem. IMO it would be bad if admin has an impression that he just >>>> successfully configured blacklist password policy even if it doesn't >>>> work in reality. There should be rather error thrown, so admin is aware >>>> that it doesn't work. >>>> >>>> However the biggest issue with the PR is another dependency as Hynek >>>> pointed in PR and me in other thread. >>>> >>>> Marek >>>> >>>> >>>> On 03/08/17 12:28, Thomas Darimont wrote: >>>>> Hello, >>>>> >>>>> great that's just what I built :) here is the PR: >>>>> https://github.com/keycloak/keycloak/pull/4370 >>>>> >>>>> I'm not sure about the error handling if a configured password list >>>>> cannot be found on the filesystem. >>>>> https://github.com/keycloak/keycloak/pull/4370/files#diff- >>>> 91236e069747f156edbd2c282fec8d92R78 >>>>> Looking forward to your feedback :) >>>>> >>>>> Cheers, >>>>> Thomas >>>>> >>>>> 2017-08-03 12:11 GMT+02:00 Marek Posolda >>>> >: >>>>> >>>>> +1 for filesystem. >>>>> >>>>> Marek >>>>> >>>>> >>>>> On 29/07/17 10:06, Thomas Darimont wrote: >>>>> >>>>> Okay cool. >>>>> >>>>> Instead of storing the password blacklist in the database I >>>>> could instead >>>>> just refer to a password >>>>> blacklist that lives on the file system. >>>>> >>>>> So Keycloak could ship with some of the lists from [0] and >>>>> refer to those >>>>> with a name like "default-blacklist1000", >>>>> "default-blacklist-100000" >>>>> in the BlacklistPasswordPolicy >>>>> config >>>>> within the admin-console. >>>>> >>>>> The "default-blacklist-100000" blacklist would then be mapped >>>>> and resolve >>>>> to >>>>> something like >>>>> "META-INF/password-blacklist/10_million_password_list_top_ >>>> 100000.txt". >>>>> Users could provide their own blacklists with the provider >>>>> config stored in >>>>> standalone.xml >>>>> than could then be adjusted via jboss-cli. >>>>> >>>>> I think this filesystem based approach is better than having >>>>> to load and >>>>> store big text-blobs in the database. >>>>> >>>>> Cheers, >>>>> Thomas >>>>> >>>>> [0] >>>>> https://github.com/danielmiessler/SecLists/tree/ >>>> master/Passwords >>>>> >>> master/Passwords> >>>>> Using those password lists seems to be allowed according to >>>>> their license: >>>>> https://www.owasp.org/index.php/Projects/OWASP_SecLists_ >>>> Project >>>>> >>> Project> >>>>> which is Creative Commons Attribution ShareAlike 3.0 License >>>>> -> IANAL but it seems to be useable in commercial products as >>>> well >>>>> https://creativecommons.org/licenses/by-sa/3.0/ >>>>> >>>>> as long as the authors are mentioned. >>>>> >>>>> >>>>> 2017-07-28 22:03 GMT+02:00 Bill Burke >>>> >: >>>>> >>>>> Yah, that sounds cool. >>>>> >>>>> >>>>> On 7/28/17 11:48 AM, Thomas Darimont wrote: >>>>> >>>>> Hello, >>>>> >>>>> I build a configurable Password Policy that allows to >>>>> match a given >>>>> password against >>>>> a blacklist with easy to guess passwords that should >>>>> be not allowed as >>>>> >>>>> user >>>>> >>>>> passwords. >>>>> >>>>> The 'BlacklistPasswordPolicyProvider' can be >>>>> configured via the admin UI >>>>> with a ";" delimited list of easy to guess passwords. >>>>> >>>>> If the user / or admin want's to change the password >>>>> it is checked >>>>> >>>>> against >>>>> >>>>> the blacklist. >>>>> A password list can be found here: >>>>> https://github.com/danielmiessler/SecLists/tree/ >>>> master/Passwords >>>>> >>> master/Passwords> >>>>> A blacklist is of course not a perfect solution but >>>>> could still be useful >>>>> for some users. >>>>> >>>>> Password blacklist would be compiled to a trie at >>>>> startup (and on changes >>>>> of the blacklist) >>>>> for efficient lookups. >>>>> >>>>> WDYT? >>>>> >>>>> Cheers, >>>>> Thomas >>>>> _______________________________________________ >>>>> 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 >>> 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 Mon Aug 14 06:07:09 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 14 Aug 2017 12:07:09 +0200 Subject: [keycloak-dev] Do we care about reproducible builds? In-Reply-To: References: <9c9c15cf-3135-c7a7-b471-e7baddfb926e@redhat.com> Message-ID: In community let's just use public NPM as we do for Maven repos. We do not maintain old Keycloak releases and hence don't need to guarantee that we can reproduce old builds. On 20 July 2017 at 19:41, Stan Silvert wrote: > I have a PR pending now that will pull js libraries from the public npm > repo. The versions are locked. I'll also include a readme file to let > you know what to do if you need to add or update a js library. > > If I don't hear any objection, we won't worry about strict > reproducibility for community releases. We can enhance this later if we > choose. > > On 7/20/2017 8:57 AM, Stan Silvert wrote: > > So to be more clear, a reproducible build means that once we release a > > version of Keycloak we can rebuild and reproduce the exact bits at any > time. > > > > To do this perfectly, we must pull in the exact versions of every js > > library we ship. > > > > So the question is, for community builds, should we maintain our own > > archived version of these libraries or can we pull from the public npm > repo? > > > > In the public npm repo, library publishers are allowed to modify their > > bits for 24 hours after publishing. They may also republish at a later > > time via special request, though this is highly discouraged. > > > > So if we don't archive js libraries with each release it is possible, > > though unlikely, that we could end up with a non-reproducible build. > > > > That's why I ask how much we really care about reproducibility in > community. > > > > On 7/19/2017 6:10 PM, Pedro Igor Silva wrote: > >> Not sure if we need to worry about our own npm repo but just grab the > >> versions we need from npm during the first install/build. Or are you > >> more worried about introducing vulnerabilities in case (somehow, by > >> passing checksum, i don't know) the version we use is modified ? > >> > >> Regards. > >> Pedro Igor > >> > >> On Wed, Jul 19, 2017 at 3:26 PM, Stan Silvert >> > wrote: > >> > >> I'm asking this question about the community version of Keycloak. > >> RH-SSO > >> absolutely must be reproducible. > >> > >> The reason I ask is because we will soon stop checking > >> node_modules into > >> github. javascript libraries will be pulled in at build time. > >> > >> We will lock down the library versions with yarn, which means > >> everything > >> is theoretically reproducible as long as the public npm repo is > >> stable. > >> > >> But if we want to be extra-sure, we can set up our own npm repo and > >> archive it with each community release. > >> > >> WDYT? How much do we care about reproducible builds in community? > >> > >> Stan > >> _______________________________________________ > >> 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 Mon Aug 14 06:12:17 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 14 Aug 2017 12:12:17 +0200 Subject: [keycloak-dev] WebSocket token validation In-Reply-To: References: Message-ID: Would be nice to have, but AFAIK we haven't had much demand for this (not sure why). We're pretty swamped at the moment so contribution would have to include testing, documentation as well as a quickstart (in our new quickstart repo). I'd also like feedback from the rest of the team to see what others think. On 18 July 2017 at 12:16, David Klingenberg wrote: > Hi guys, > > we are using keycloak in our project and we need to use websockets. There > is currently no official solution for keycloak - websocket integration, but > there is a great library in hawkular for this purpose: > > https://github.com/hawkular/hawkular-accounts/tree/master/websocket-api > > > I think it would be great if this could become part of keycloak. What do > you think? I'm willing to contribute on it. > > > > Best Regards, > David > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Mon Aug 14 06:57:28 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 14 Aug 2017 12:57:28 +0200 Subject: [keycloak-dev] Proposal of using existing authentication and authorization server on behalf of keycloak browser-based authentication In-Reply-To: <831D472326678942A9B4BB933AAA103D68CA8DDB@GSjpTK1DCembx01.service.hitachi.net> References: <831D472326678942A9B4BB933AAA103D68CA8DDB@GSjpTK1DCembx01.service.hitachi.net> Message-ID: I'm not really following what you are proposing to contribute to Keycloak. We already have the SPI that allows adding a custom provider if your IdP doesn't support SAML or OpenID Connect. On 31 July 2017 at 06:09, ???? / NORIMATSU?TAKASHI < takashi.norimatsu.ws at hitachi.com> wrote: > Hello. > > Previously, I had proposed the feature and its implementation of > delegating authentication and authorization to an external existing server > on behalf of keycloak's browser-based authentication mechanism, and had > gotten advices that it is appropriate to use Identity Brokering for such > the feature. > > I've re-implemented this feature again by Identity Brokering. The > description and implementation of this feature is mentioned below. > https://github.com/Hitachi/PoV-keycloak-delegate-authn-consent > https://github.com/Hitachi/PoV-keycloak-delegate-authn- > consent/tree/master/src/keycloak/examples/providers/delegate-authn-consent > It can delegate not only authentication but authorization(consent). > > Kindly review it and provide us some comment and advices. > We would like to contribute this feature onto keycloak. > > Best Regards > Takashi Norimatsu > Hitachi, Ltd. > > --- > From: Stian Thorgersen [mailto:sthorger at redhat.com] > Sent: Thursday, June 29, 2017 6:23 PM > To: ???? / NORIMATSU?TAKASHI > Cc: keycloak-dev at lists.jboss.org > Subject: [!]Re: [keycloak-dev] Proposal of using existing authentication > server on behalf of keycloak browser-based authentication > > There's an SPI to implement your own custom identity brokering provider > [1]. > > [1] https://github.com/keycloak/keycloak/blob/master/ > server-spi-private/src/main/java/org/keycloak/broker/ > provider/IdentityProvider.java > > On 29 June 2017 at 10:51, ???? / NORIMATSU?TAKASHI < > takashi.norimatsu.ws at hitachi.com> wrote: > I need to use the authentication server without OIDC/OAuth2/SAMLv2 > implementation as an external IdP, > in order to integrate existing authentication system. > (some commercial products supports such the case) > > I consulted identity broker's section in keycloak's manual below and found > that if I use this feature the external IdP must support OIDC or SAMLv2. > https://keycloak.gitbooks.io/documentation/server_admin/ > topics/identity-broker.html > > Therefore, I realized it by using redirect based authentication flows. > > Can identity Brokering can support such the case? > > Aside from this, I'd like to contribute it to Community extensions and > examples. > > Best Regards > Takashi Norimatsu > Hitachi, Ltd. > > --- > From: Stian Thorgersen [mailto:sthorger at redhat.com] > Sent: Tuesday, June 27, 2017 5:52 PM > To: ???? / NORIMATSU?TAKASHI > Cc: keycloak-dev at lists.jboss.org > Subject: [!]Re: [keycloak-dev] Proposal of using existing authentication > server on behalf of keycloak browser-based authentication > > I'm not in favour of adding this. If it's using redirect based > authentication flows it should be done through identity brokering, not > authentication flows. It's also a very complex example that we don't want > to maintain. We've also in the process of moving all examples away from the > main Keycloak repository into a separate quickstart repository. > > On 27 June 2017 at 08:54, ???? / NORIMATSU?TAKASHI < > takashi.norimatsu.ws at hitachi.com> wrote: > Hello. > > Previously, I had proposed the feature of delegating authentication to an > external authentication server on behalf of keycloak's browser-based > authentication mechanism. > > I've integrated this feature to keycloak's "examples" packages and send PR > (https://github.com/keycloak/keycloak/pull/4260). > Hope this PR is reviewed and merged as an example for combining some > providers to customize keycloak. > > Detailed description of this feature is mentioned below. > https://github.com/Hitachi/PoV-keycloak-authentication-delegation > > I am now engaging in integrating this feature to keycloak as product-base > default providers, but encounter technical problems about writing > arquillian. Would someone tell me how to resolve this problem? > > [Problem] > - I could not find how to run an external authentication > server(application running on wildfly 10) during each arquillian test cases. > > After resolving this problem and writing and running arquillian test > cases, I'll send PR for this feature as product-base default providers. > > Best Regards > Takashi Norimatsu > Hitachi, Ltd. > > _______________________________________________ > 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 Mon Aug 14 06:58:38 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 14 Aug 2017 12:58:38 +0200 Subject: [keycloak-dev] account service REST API? In-Reply-To: <81fe7205-1b5f-042c-24fd-e54f44dee563@redhat.com> References: <7d49651b-8fd8-b225-f0d1-0c1d4a5a2cc8@redhat.com> <7ec6f5d7-41a8-2728-c7a6-c588f820e90c@redhat.com> <81fe7205-1b5f-042c-24fd-e54f44dee563@redhat.com> Message-ID: It'll be added soon. On 9 August 2017 at 20:19, Bill Burke wrote: > Right now there's no way to unlink accounts, which is why i ask. > > > On 8/9/17 11:17 AM, Stan Silvert wrote: > > Yes, this is being worked on by Stian and myself. It's in a private > > repo now but we will probably merge to master soon after he returns from > > holiday. > > > > Stan > > > > On 8/9/2017 11:12 AM, Marek Posolda wrote: > >> I think that Stian already started on REST support in AccountService. I > >> saw some commits around this some time ago. But it's probably not yet > >> pushed, just somewhere in his private repo. Not 100% sure.. > >> > >> Marek > >> > >> On 09/08/17 16:22, Bill Burke wrote: > >>> The AccountService class was originally intended to be both a browser > >>> service as well as a REST API. Some endpoints on AccountService don't > >>> work. Should I be fixing the Account Service for REST invocations? > Are > >>> we still indending the AccountService to be accessible via REST calls? > >>> > >>> _______________________________________________ > >>> 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 > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Mon Aug 14 07:06:12 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 14 Aug 2017 13:06:12 +0200 Subject: [keycloak-dev] token exchange In-Reply-To: References: <71449542-5454-44e4-936b-2099e366d8b5@redhat.com> <49f60419-0d5b-9f0b-ec58-7c06eb513570@redhat.com> <64994417-43b0-95d3-5de9-c0d78a226d79@redhat.com> Message-ID: I'm assuming the basic token exchange service comes from the way the CLI tool works? I.e. you login to the tool then it allows exchanging the token for a particular CLI client? Would it not be better to obtain an ID token and use direct grant to obtain a token for the client using the ID token as the authentication mechanism? On 1 August 2017 at 19:10, Pedro Igor Silva wrote: > On Mon, Jul 31, 2017 at 1:54 PM, Bill Burke wrote: > > > > > > > On 7/31/17 12:18 PM, Bill Burke wrote: > > > > > > > > On 7/31/17 11:35 AM, Pedro Igor Silva wrote: > > > > On Fri, Jul 28, 2017 at 5:24 PM, Bill Burke wrote: > > > >> I've implemented a simple token exchange API [1] that allows you to > >> exchange an access token created for one client to another client. The > >> REST API follows the oauth token exchange api [2] very loosely. > >> > >> subject_token: a keycloak access token > >> > >> audience: takes a client id > >> > >> It then converts the access token created for one client and converts it > >> to another. It lives under the token endpoint. > >> > >> The security model is as follows: > >> > >> * Authenticate calling client the same way as password grant. > >> > >> * The calling client must have service account enabled > >> > >> * Service account must have a realm role "token-exchanger" grant edto it > >> or, it must have a client role "token-exchanger" granted to it. This > >> exchanger client role is a role defined by the target client you are > >> exchanging the token to. > >> > >> > >> Is this a good security model? I'm thinking of not creating these roles > >> right now and to enable support for exchange would require defining the > >> roles specified above. > >> > > > > I think roles are too coarse-grained to represent this kind of policy. A > > better option would be to explicitly define the clients that are allowed > to > > exchange tokens for a particular resource server. Eg.: > > > > RS A allows Client B, C and D to exchange their tokens where the target > > audience is RS A (or if using "resource", a specific resource in RS A). > > > > > > I changed it a little. actors are: > > > > * Authenticated client asking for change > > * Clients that are the audience of the token being exchanged > > * Client you want the token to be exchanged to > > > > So, the authenticated client must be in the audience of the token being > > exchanged, or, have permission to exchange from that particular audience. > > The authenticated client also must have permission to exchange to the > > audience it wants to exchange to. > > > > Good idea to change it to use the fine grain admin permissions. There's > a > > couple of issues/problems with doing this that I think are easily done: > > > > * public clients can't have service accounts. > > * Client Policy looks at kc_client_id attribute which is pulled from the > > issuedFor claim in the token. This isn't correct as we permission checks > > based on the authenticated client, not the token. > > > > So I'll have to create a new Identity type that either wraps the service > > account or ClientModel and sets the "kc_client_id" property. > > > > Our policy evaluation engine is based on the claims within the token. The > "issueFor" is basically the "azp" claim from OIDC. In fact, we don't even > need that "kc_client_id". We could make this configurable though, and let > users decide whether they want to check the "authenticated client" or "azp" > ? > > Btw, I'm about to finish UMA Grant Type, one of the changes I'm doing for > UMA 2.0. My changes will conflict with yours. Are you going to merge your > changes soon ? > > Another thing I noticed is that maybe we could have a SPI for custom grant > types. What you did and what I'm doing may justify a specific SPI for > plugging custom grant types. Maybe too much, but maybe a nice to have. > > > > > > > > Bill > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Mon Aug 14 07:08:16 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 14 Aug 2017 13:08:16 +0200 Subject: [keycloak-dev] generic cli sso utility In-Reply-To: <0cfaaecd-51ab-eacb-cba3-a536acd6c943@redhat.com> References: <0cfaaecd-51ab-eacb-cba3-a536acd6c943@redhat.com> Message-ID: For this exact reason it can't use the browser based flow rather it should the direct grant (or some other flow?!?). On 4 August 2017 at 10:09, Marek Posolda wrote: > I wonder if it's possible to have CLI utility, which is able to read > HTML with the form and challenge user based on that? For example once it > receives the HTML like this: > >
> Username: > Password: >
> > Then in command line, user will be challenged for username and password. > > I am not sure if it's doable in practice and how much work it is. Sounds > like re-implementing browser in command line. But maybe something like > this exists already? > > BTV. Some things will never work in CLI in my opinion. For example: > - Registration with captcha > - TOTP setup > - Broker login (but hopefully some brokers offer alternatives) > > Marek > > > On 28/07/17 22:36, Bill Burke wrote: > > I've developed a small command line utility around Keycloak Installed. > > The idea is that this utility performs a login with keycloak to obtain > > an access token. This utility saves the access and refresh token in a > > file (similar to how ssh does in .ssh). Then bash scripts can be used to > > export the access token as an environment variable so it can be used by > > other command line utilities. > > > > > > https://github.com/patriot1burke/keycloak/blob/master/adapters/oidc/ > installed/src/main/java/org/keycloak/adapters/installed/ > KeycloakCliSso.java > > > > https://github.com/patriot1burke/keycloak/tree/ > master/adapters/oidc/cli-sso > > > > > > Eventually I'm thinking of creating a text/plain protocol with Keycloak > > server so that launching a browser or cutting/pasting between the > > command line window and browser isn't a requirement. It woudl be a plain > > text challenge response protocol. This would require a bit more work as > > it would require reworking all of our built in authenticators and > > required action plugins. > > > > _______________________________________________ > > 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 darran.lofthouse at jboss.com Mon Aug 14 07:28:30 2017 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Mon, 14 Aug 2017 11:28:30 +0000 Subject: [keycloak-dev] generic cli sso utility In-Reply-To: References: <0cfaaecd-51ab-eacb-cba3-a536acd6c943@redhat.com> Message-ID: Could the integration Pedro added to the JBoss CLI make use of this. I believe there at the moment any tokens are obtained at the time they are needed so would be good to combine that with a cached token as well. Regards, Darran Lofthouse. On Mon, 14 Aug 2017 at 12:21 Stian Thorgersen wrote: > For this exact reason it can't use the browser based flow rather it should > the direct grant (or some other flow?!?). > > On 4 August 2017 at 10:09, Marek Posolda wrote: > > > I wonder if it's possible to have CLI utility, which is able to read > > HTML with the form and challenge user based on that? For example once it > > receives the HTML like this: > > > >
> > Username: > > Password: > >
> > > > Then in command line, user will be challenged for username and password. > > > > I am not sure if it's doable in practice and how much work it is. Sounds > > like re-implementing browser in command line. But maybe something like > > this exists already? > > > > BTV. Some things will never work in CLI in my opinion. For example: > > - Registration with captcha > > - TOTP setup > > - Broker login (but hopefully some brokers offer alternatives) > > > > Marek > > > > > > On 28/07/17 22:36, Bill Burke wrote: > > > I've developed a small command line utility around Keycloak Installed. > > > The idea is that this utility performs a login with keycloak to obtain > > > an access token. This utility saves the access and refresh token in a > > > file (similar to how ssh does in .ssh). Then bash scripts can be used > to > > > export the access token as an environment variable so it can be used by > > > other command line utilities. > > > > > > > > > https://github.com/patriot1burke/keycloak/blob/master/adapters/oidc/ > > installed/src/main/java/org/keycloak/adapters/installed/ > > KeycloakCliSso.java > > > > > > https://github.com/patriot1burke/keycloak/tree/ > > master/adapters/oidc/cli-sso > > > > > > > > > Eventually I'm thinking of creating a text/plain protocol with Keycloak > > > server so that launching a browser or cutting/pasting between the > > > command line window and browser isn't a requirement. It woudl be a > plain > > > text challenge response protocol. This would require a bit more work > as > > > it would require reworking all of our built in authenticators and > > > required action plugins. > > > > > > _______________________________________________ > > > 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 bburke at redhat.com Mon Aug 14 09:42:07 2017 From: bburke at redhat.com (Bill Burke) Date: Mon, 14 Aug 2017 09:42:07 -0400 Subject: [keycloak-dev] token exchange In-Reply-To: References: <71449542-5454-44e4-936b-2099e366d8b5@redhat.com> <49f60419-0d5b-9f0b-ec58-7c06eb513570@redhat.com> <64994417-43b0-95d3-5de9-c0d78a226d79@redhat.com> Message-ID: <9b6efb46-944c-213b-848e-4e82d922da6f@redhat.com> CLI tool I wrote doesn't allow token exchange, yet, but you're correct, I'm thinking of using it to perform token exchange. Our ID tokens are not signed right now. Also you still need client to client exchange so that you can "downgrade" a token to talk to an untrusted service. I've also added new fine-grain permissions "exchange-from" and "exchange-to". For example, lets say Client A gets token and invokes on service B which needs to invoke on untrusted service C. 1. Service B asks to exchange the token created for A to talk to C 2. Token exchange endpoint looks at issuer, its A, so it sees if service B has permission to "exchange-from" tokens created for A 3. Token exchange then sees if B has permission to "exchange-to" B. FYI, I'm also expanding this so that you can exchange an access token for a social provider token. Automatic refreshes and everything if the provider supports it. Gonna change how client initiated linking works too so that instead of doing the silly hash algorithm required by the call, clients would call the exchange first, get an error response like "not linked" that contained a browser URL that the client can use to create the link. Also no reason I couldn't do the same for exchange an external token to a internal one. Would work the same as our IDP, import the user, etc. On 8/14/17 7:06 AM, Stian Thorgersen wrote: > I'm assuming the basic token exchange service comes from the way the > CLI tool works? I.e. you login to the tool then it allows exchanging > the token for a particular CLI client? > > Would it not be better to obtain an ID token and use direct grant to > obtain a token for the client using the ID token as the authentication > mechanism? > > On 1 August 2017 at 19:10, Pedro Igor Silva > wrote: > > On Mon, Jul 31, 2017 at 1:54 PM, Bill Burke > wrote: > > > > > > > On 7/31/17 12:18 PM, Bill Burke wrote: > > > > > > > > On 7/31/17 11:35 AM, Pedro Igor Silva wrote: > > > > On Fri, Jul 28, 2017 at 5:24 PM, Bill Burke > wrote: > > > >> I've implemented a simple token exchange API [1] that allows you to > >> exchange an access token created for one client to another > client. The > >> REST API follows the oauth token exchange api [2] very loosely. > >> > >> subject_token: a keycloak access token > >> > >> audience: takes a client id > >> > >> It then converts the access token created for one client and > converts it > >> to another. It lives under the token endpoint. > >> > >> The security model is as follows: > >> > >> * Authenticate calling client the same way as password grant. > >> > >> * The calling client must have service account enabled > >> > >> * Service account must have a realm role "token-exchanger" > grant edto it > >> or, it must have a client role "token-exchanger" granted to > it. This > >> exchanger client role is a role defined by the target client > you are > >> exchanging the token to. > >> > >> > >> Is this a good security model? I'm thinking of not creating > these roles > >> right now and to enable support for exchange would require > defining the > >> roles specified above. > >> > > > > I think roles are too coarse-grained to represent this kind of > policy. A > > better option would be to explicitly define the clients that are > allowed to > > exchange tokens for a particular resource server. Eg.: > > > > RS A allows Client B, C and D to exchange their tokens where the > target > > audience is RS A (or if using "resource", a specific resource in > RS A). > > > > > > I changed it a little. actors are: > > > > * Authenticated client asking for change > > * Clients that are the audience of the token being exchanged > > * Client you want the token to be exchanged to > > > > So, the authenticated client must be in the audience of the > token being > > exchanged, or, have permission to exchange from that particular > audience. > > The authenticated client also must have permission to exchange > to the > > audience it wants to exchange to. > > > > Good idea to change it to use the fine grain admin permissions. > There's a > > couple of issues/problems with doing this that I think are > easily done: > > > > * public clients can't have service accounts. > > * Client Policy looks at kc_client_id attribute which is pulled > from the > > issuedFor claim in the token. This isn't correct as we > permission checks > > based on the authenticated client, not the token. > > > > So I'll have to create a new Identity type that either wraps the > service > > account or ClientModel and sets the "kc_client_id" property. > > > > Our policy evaluation engine is based on the claims within the > token. The > "issueFor" is basically the "azp" claim from OIDC. In fact, we > don't even > need that "kc_client_id". We could make this configurable though, > and let > users decide whether they want to check the "authenticated client" > or "azp" > ? > > Btw, I'm about to finish UMA Grant Type, one of the changes I'm > doing for > UMA 2.0. My changes will conflict with yours. Are you going to > merge your > changes soon ? > > Another thing I noticed is that maybe we could have a SPI for > custom grant > types. What you did and what I'm doing may justify a specific SPI for > plugging custom grant types. Maybe too much, but maybe a nice to have. > > > > > > > > Bill > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > From bburke at redhat.com Mon Aug 14 09:56:32 2017 From: bburke at redhat.com (Bill Burke) Date: Mon, 14 Aug 2017 09:56:32 -0400 Subject: [keycloak-dev] generic cli sso utility In-Reply-To: References: <0cfaaecd-51ab-eacb-cba3-a536acd6c943@redhat.com> Message-ID: <3958ff9c-a987-51ad-1d8c-d115d4d99b7a@redhat.com> You can't use direct grant as the CLI won't know what credential input is required. i.e. pw only, pw + otp, pw + sms, etc.... Right now the CLI tool I wrote uses the KeycloakInstalled stuff you did Stian and stores tokens in a hidden directory. I would eventually like to make it RSH friendly and define a flow that was text based and displayable to the console. All with kerberos and client cert support too. Maybe this is something we can do with a text-based browser (Lynx)? Not sure how KeycloakInstalled would detect this and be able to run it though. Also configuratoin for kerveros and client cert would be problematic. On 8/14/17 7:08 AM, Stian Thorgersen wrote: > For this exact reason it can't use the browser based flow rather it > should the direct grant (or some other flow?!?). > > On 4 August 2017 at 10:09, Marek Posolda > wrote: > > I wonder if it's possible to have CLI utility, which is able to read > HTML with the form and challenge user based on that? For example > once it > receives the HTML like this: > >
> Username: > Password: >
> > Then in command line, user will be challenged for username and > password. > > I am not sure if it's doable in practice and how much work it is. > Sounds > like re-implementing browser in command line. But maybe something like > this exists already? > > BTV. Some things will never work in CLI in my opinion. For example: > - Registration with captcha > - TOTP setup > - Broker login (but hopefully some brokers offer alternatives) > > Marek > > > On 28/07/17 22:36, Bill Burke wrote: > > I've developed a small command line utility around Keycloak > Installed. > > The idea is that this utility performs a login with keycloak to > obtain > > an access token. This utility saves the access and refresh > token in a > > file (similar to how ssh does in .ssh). Then bash scripts can be > used to > > export the access token as an environment variable so it can be > used by > > other command line utilities. > > > > > > > https://github.com/patriot1burke/keycloak/blob/master/adapters/oidc/installed/src/main/java/org/keycloak/adapters/installed/KeycloakCliSso.java > > > > > > https://github.com/patriot1burke/keycloak/tree/master/adapters/oidc/cli-sso > > > > > > > Eventually I'm thinking of creating a text/plain protocol with > Keycloak > > server so that launching a browser or cutting/pasting between the > > command line window and browser isn't a requirement. It woudl be > a plain > > text challenge response protocol. This would require a bit more > work as > > it would require reworking all of our built in authenticators and > > required action plugins. > > > > _______________________________________________ > > 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 Aug 15 02:46:15 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 15 Aug 2017 08:46:15 +0200 Subject: [keycloak-dev] generic cli sso utility In-Reply-To: <3958ff9c-a987-51ad-1d8c-d115d4d99b7a@redhat.com> References: <0cfaaecd-51ab-eacb-cba3-a536acd6c943@redhat.com> <3958ff9c-a987-51ad-1d8c-d115d4d99b7a@redhat.com> Message-ID: I don't think leveraging a text-based browser is a good idea: * No-one has one installed and they suck big time. You probably need Cygwin on Windows to get one as well * Would require special themes to make anything that would be remotely usable * Not always usable on a remote shell. You need to do ssh (and other things) with special commands to have an emulated terminal rather than just a stream of characters As separate flow and/or extending direct grant to have some sort of challenge/response would probably be better. Thinking about 3 different use-cases for the CLI: * Desktop - in this case the system browser is probably the best option as there's then SSO between web and CLIs and there's the best UI available * Server/RSH - in this case wouldn't private/public keys be the best option? SSH does this very well with RSA keys. We could even just use the same keys as SSH by allowing users to upload their public SSH key * Embedded/IoT (probably a completely different thing altogether) - in this case the device has very limited capabilities so you probably want to complete the authentication on a separate device On 14 August 2017 at 15:56, Bill Burke wrote: > You can't use direct grant as the CLI won't know what credential input is > required. i.e. pw only, pw + otp, pw + sms, etc.... Right now the CLI tool > I wrote uses the KeycloakInstalled stuff you did Stian and stores tokens in > a hidden directory. > > I would eventually like to make it RSH friendly and define a flow that was > text based and displayable to the console. All with kerberos and client > cert support too. Maybe this is something we can do with a text-based > browser (Lynx)? Not sure how KeycloakInstalled would detect this and be > able to run it though. Also configuratoin for kerveros and client cert > would be problematic. > > On 8/14/17 7:08 AM, Stian Thorgersen wrote: > > For this exact reason it can't use the browser based flow rather it should > the direct grant (or some other flow?!?). > > On 4 August 2017 at 10:09, Marek Posolda wrote: > >> I wonder if it's possible to have CLI utility, which is able to read >> HTML with the form and challenge user based on that? For example once it >> receives the HTML like this: >> >>
>> Username: >> Password: >>
>> >> Then in command line, user will be challenged for username and password. >> >> I am not sure if it's doable in practice and how much work it is. Sounds >> like re-implementing browser in command line. But maybe something like >> this exists already? >> >> BTV. Some things will never work in CLI in my opinion. For example: >> - Registration with captcha >> - TOTP setup >> - Broker login (but hopefully some brokers offer alternatives) >> >> Marek >> >> >> On 28/07/17 22:36, Bill Burke wrote: >> > I've developed a small command line utility around Keycloak Installed. >> > The idea is that this utility performs a login with keycloak to obtain >> > an access token. This utility saves the access and refresh token in a >> > file (similar to how ssh does in .ssh). Then bash scripts can be used to >> > export the access token as an environment variable so it can be used by >> > other command line utilities. >> > >> > >> > https://github.com/patriot1burke/keycloak/blob/master/ >> adapters/oidc/installed/src/main/java/org/keycloak/ >> adapters/installed/KeycloakCliSso.java >> > >> > https://github.com/patriot1burke/keycloak/tree/master/ >> adapters/oidc/cli-sso >> > >> > >> > Eventually I'm thinking of creating a text/plain protocol with Keycloak >> > server so that launching a browser or cutting/pasting between the >> > command line window and browser isn't a requirement. It woudl be a plain >> > text challenge response protocol. This would require a bit more work as >> > it would require reworking all of our built in authenticators and >> > required action plugins. >> > >> > _______________________________________________ >> > 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 Aug 15 02:50:27 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 15 Aug 2017 08:50:27 +0200 Subject: [keycloak-dev] token exchange In-Reply-To: <9b6efb46-944c-213b-848e-4e82d922da6f@redhat.com> References: <71449542-5454-44e4-936b-2099e366d8b5@redhat.com> <49f60419-0d5b-9f0b-ec58-7c06eb513570@redhat.com> <64994417-43b0-95d3-5de9-c0d78a226d79@redhat.com> <9b6efb46-944c-213b-848e-4e82d922da6f@redhat.com> Message-ID: First of all I'm not arguing against token exchange service. It's a very useful thing IMO and I can see loads of use-cases for it. I'm just wondering about how usable it will be for the CLI tool and I'm worried about how complicated it would be to setup. If the ID token was signed that could serve as a the "identity cookie" for a CLI SSO session (if ID token is not suitable we could introduce some sort of identity token that can be used by direct grant to allow SSO sessions). Using direct grant you can then easily obtain a token for a specific client by just passing a valid "identity cookie" same way as the web browser does. Is that not simpler to setup and use? On 14 August 2017 at 15:42, Bill Burke wrote: > CLI tool I wrote doesn't allow token exchange, yet, but you're correct, > I'm thinking of using it to perform token exchange. > > Our ID tokens are not signed right now. Also you still need client to > client exchange so that you can "downgrade" a token to talk to an untrusted > service. I've also added new fine-grain permissions "exchange-from" and > "exchange-to". > > For example, lets say Client A gets token and invokes on service B which > needs to invoke on untrusted service C. > > 1. Service B asks to exchange the token created for A to talk to C > 2. Token exchange endpoint looks at issuer, its A, so it sees if service B > has permission to "exchange-from" tokens created for A > 3. Token exchange then sees if B has permission to "exchange-to" B. > > FYI, I'm also expanding this so that you can exchange an access token for > a social provider token. Automatic refreshes and everything if the > provider supports it. Gonna change how client initiated linking works too > so that instead of doing the silly hash algorithm required by the call, > clients would call the exchange first, get an error response like "not > linked" that contained a browser URL that the client can use to create the > link. > > Also no reason I couldn't do the same for exchange an external token to a > internal one. Would work the same as our IDP, import the user, etc. > > > On 8/14/17 7:06 AM, Stian Thorgersen wrote: > > I'm assuming the basic token exchange service comes from the way the CLI > tool works? I.e. you login to the tool then it allows exchanging the token > for a particular CLI client? > > Would it not be better to obtain an ID token and use direct grant to > obtain a token for the client using the ID token as the authentication > mechanism? > > On 1 August 2017 at 19:10, Pedro Igor Silva wrote: > >> On Mon, Jul 31, 2017 at 1:54 PM, Bill Burke wrote: >> >> > >> > >> > On 7/31/17 12:18 PM, Bill Burke wrote: >> > >> > >> > >> > On 7/31/17 11:35 AM, Pedro Igor Silva wrote: >> > >> > On Fri, Jul 28, 2017 at 5:24 PM, Bill Burke wrote: >> > >> >> I've implemented a simple token exchange API [1] that allows you to >> >> exchange an access token created for one client to another client. The >> >> REST API follows the oauth token exchange api [2] very loosely. >> >> >> >> subject_token: a keycloak access token >> >> >> >> audience: takes a client id >> >> >> >> It then converts the access token created for one client and converts >> it >> >> to another. It lives under the token endpoint. >> >> >> >> The security model is as follows: >> >> >> >> * Authenticate calling client the same way as password grant. >> >> >> >> * The calling client must have service account enabled >> >> >> >> * Service account must have a realm role "token-exchanger" grant edto >> it >> >> or, it must have a client role "token-exchanger" granted to it. This >> >> exchanger client role is a role defined by the target client you are >> >> exchanging the token to. >> >> >> >> >> >> Is this a good security model? I'm thinking of not creating these >> roles >> >> right now and to enable support for exchange would require defining the >> >> roles specified above. >> >> >> > >> > I think roles are too coarse-grained to represent this kind of policy. A >> > better option would be to explicitly define the clients that are >> allowed to >> > exchange tokens for a particular resource server. Eg.: >> > >> > RS A allows Client B, C and D to exchange their tokens where the target >> > audience is RS A (or if using "resource", a specific resource in RS A). >> > >> > >> > I changed it a little. actors are: >> > >> > * Authenticated client asking for change >> > * Clients that are the audience of the token being exchanged >> > * Client you want the token to be exchanged to >> > >> > So, the authenticated client must be in the audience of the token being >> > exchanged, or, have permission to exchange from that particular >> audience. >> > The authenticated client also must have permission to exchange to the >> > audience it wants to exchange to. >> > >> > Good idea to change it to use the fine grain admin permissions. >> There's a >> > couple of issues/problems with doing this that I think are easily done: >> > >> > * public clients can't have service accounts. >> > * Client Policy looks at kc_client_id attribute which is pulled from the >> > issuedFor claim in the token. This isn't correct as we permission >> checks >> > based on the authenticated client, not the token. >> > >> > So I'll have to create a new Identity type that either wraps the service >> > account or ClientModel and sets the "kc_client_id" property. >> > >> >> Our policy evaluation engine is based on the claims within the token. The >> "issueFor" is basically the "azp" claim from OIDC. In fact, we don't even >> need that "kc_client_id". We could make this configurable though, and let >> users decide whether they want to check the "authenticated client" or >> "azp" >> ? >> >> Btw, I'm about to finish UMA Grant Type, one of the changes I'm doing for >> UMA 2.0. My changes will conflict with yours. Are you going to merge your >> changes soon ? >> >> Another thing I noticed is that maybe we could have a SPI for custom grant >> types. What you did and what I'm doing may justify a specific SPI for >> plugging custom grant types. Maybe too much, but maybe a nice to have. >> >> >> > >> > >> > Bill >> > >> _______________________________________________ >> 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 Tue Aug 15 02:58:23 2017 From: takashi.norimatsu.ws at hitachi.com (=?utf-8?B?5LmX5p2+6ZqG5b+XIC8gTk9SSU1BVFNV77yMVEFLQVNISQ==?=) Date: Tue, 15 Aug 2017 06:58:23 +0000 Subject: [keycloak-dev] Proposal of using existing authentication and authorization server on behalf of keycloak browser-based authentication In-Reply-To: References: <831D472326678942A9B4BB933AAA103D68CA8DDB@GSjpTK1DCembx01.service.hitachi.net> Message-ID: <831D472326678942A9B4BB933AAA103D68CB9260@GSjpTK1DCembx02.service.hitachi.net> > I'm not really following what you are proposing to contribute to Keycloak. Thank you for comment. This contribution to keycloak is that to enhance competitiveness with proprietary products. In some market, customers have highly customized Web UI for authentication. (e.g. soft keyboard, responsive web design, very sophisticated look and feel). They want to use Authorization server product (such as keycloak) implementing OpenID Connect for securing the customer's API. They want to use existing highly customized authentication server, but do not want to implement OpenID Connect on this authentication server (too much complex and difficult to implement). To meet such needs, proprietary products have the following solution. Proprietary authorization server products have their own procedure (much simpler than OpenID Connect and SAMLv2) to communicate with existing authentication server as below: https://communities.ca.com/blogs/oauth/2016/10/04/howto-integrating-otk-with-external-login-server?et=notification.send https://www.ibm.com/support/knowledgecenter/en/SSMNED_5.0.0/com.ibm.apic.toolkit.doc/tapim_sec_api_config_scheme_oauth_endpoint.html In customer's existing authentication server, customers only have to implement communication with the authorization server according to the procedure prepared by the authorization server product (It is much easier than implementing OpenID Connect or SAMLv2). Customers do not have to implement anything in authorization server side. On the other hand, if keycloak is used, customers have to do following: a) In authorization server (RH SSO), simple procedure to communicate with external authentication server have to be designed and implemented using SPI. b) In customer's existing authentication server, implement procedure prepared by a). -> In proprietary products, a) is prepared, but keycloak is not. Our proposed patch is intended to complement a). --- From: Stian Thorgersen [mailto:sthorger at redhat.com] Sent: Monday, August 14, 2017 7:57 PM To: ???? / NORIMATSU?TAKASHI Cc: keycloak-dev at lists.jboss.org Subject: [!]Re: [keycloak-dev] Proposal of using existing authentication and authorization server on behalf of keycloak browser-based authentication I'm not really following what you are proposing to contribute to Keycloak. We already have the SPI that allows adding a custom provider if your IdP doesn't support SAML or OpenID Connect. On 31 July 2017 at 06:09, ???? / NORIMATSU?TAKASHI wrote: Hello. Previously, I had proposed the feature and its implementation of delegating authentication and authorization to an external existing server on behalf of keycloak's browser-based authentication mechanism, and had gotten advices that it is appropriate to use Identity Brokering for such the feature. I've re-implemented this feature again by Identity Brokering. The description and implementation of this feature is mentioned below. https://github.com/Hitachi/PoV-keycloak-delegate-authn-consent https://github.com/Hitachi/PoV-keycloak-delegate-authn-consent/tree/master/src/keycloak/examples/providers/delegate-authn-consent It can delegate not only authentication but authorization(consent). Kindly review it and provide us some comment and advices. We would like to contribute this feature onto keycloak. Best Regards Takashi Norimatsu Hitachi, Ltd. --- From: Stian Thorgersen [mailto:sthorger at redhat.com] Sent: Thursday, June 29, 2017 6:23 PM To: ???? / NORIMATSU?TAKASHI Cc: keycloak-dev at lists.jboss.org Subject: [!]Re: [keycloak-dev] Proposal of using existing authentication server on behalf of keycloak browser-based authentication There's an SPI to implement your own custom identity brokering provider [1]. [1]?https://github.com/keycloak/keycloak/blob/master/server-spi-private/src/main/java/org/keycloak/broker/provider/IdentityProvider.java On 29 June 2017 at 10:51, ???? / NORIMATSU?TAKASHI wrote: I need to use the authentication server without OIDC/OAuth2/SAMLv2 implementation as an external IdP, in order to integrate existing authentication system. (some commercial products supports such the case) I consulted identity broker's section in keycloak's manual below and found that if I use this feature the external IdP must support OIDC or SAMLv2. https://keycloak.gitbooks.io/documentation/server_admin/topics/identity-broker.html Therefore, I realized it by using redirect based authentication flows. Can identity Brokering can support such the case? Aside from this, I'd like to contribute it to Community extensions and examples. Best Regards Takashi Norimatsu Hitachi, Ltd. --- From: Stian Thorgersen [mailto:sthorger at redhat.com] Sent: Tuesday, June 27, 2017 5:52 PM To: ???? / NORIMATSU?TAKASHI Cc: keycloak-dev at lists.jboss.org Subject: [!]Re: [keycloak-dev] Proposal of using existing authentication server on behalf of keycloak browser-based authentication I'm not in favour of adding this. If it's using redirect based authentication flows it should be done through identity brokering, not authentication flows. It's also a very complex example that we don't want to maintain. We've also in the process of moving all examples away from the main Keycloak repository into a separate quickstart repository. On 27 June 2017 at 08:54, ???? / NORIMATSU?TAKASHI wrote: Hello. Previously, I had proposed the feature of delegating authentication to an external authentication server on behalf of keycloak's browser-based authentication mechanism. I've integrated this feature to keycloak's "examples" packages and send PR (https://github.com/keycloak/keycloak/pull/4260). Hope this PR is reviewed and merged as an example for combining some providers to customize keycloak. Detailed description of this feature is mentioned below. https://github.com/Hitachi/PoV-keycloak-authentication-delegation I am now engaging in integrating this feature to keycloak as product-base default providers, but encounter technical problems about writing arquillian. Would someone tell me how to resolve this problem? [Problem] - I could not find how to run an external authentication server(application running on wildfly 10) during each arquillian test cases. After resolving this problem and writing and running arquillian test cases, I'll send PR for this feature as product-base default providers. Best Regards Takashi Norimatsu Hitachi, Ltd. _______________________________________________ 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 Aug 15 03:49:28 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 15 Aug 2017 09:49:28 +0200 Subject: [keycloak-dev] Proposal of using existing authentication and authorization server on behalf of keycloak browser-based authentication In-Reply-To: <831D472326678942A9B4BB933AAA103D68CB9260@GSjpTK1DCembx02.service.hitachi.net> References: <831D472326678942A9B4BB933AAA103D68CA8DDB@GSjpTK1DCembx01.service.hitachi.net> <831D472326678942A9B4BB933AAA103D68CB9260@GSjpTK1DCembx02.service.hitachi.net> Message-ID: Afraid I still don't understand what you are trying to contribute to Keycloak. As I said we already allow creating custom identity providers using whatever protocol you want. We can't accept contribution of a custom identity provider which is seems is what you are trying to contribute. On 15 August 2017 at 08:58, ???? / NORIMATSU?TAKASHI < takashi.norimatsu.ws at hitachi.com> wrote: > > I'm not really following what you are proposing to contribute to > Keycloak. > Thank you for comment. > This contribution to keycloak is that to enhance competitiveness with > proprietary products. > > In some market, customers have highly customized Web UI for authentication. > (e.g. soft keyboard, responsive web design, very sophisticated look and > feel). > > They want to use Authorization server product (such as keycloak) > implementing OpenID Connect for securing the customer's API. > They want to use existing highly customized authentication server, but do > not want to implement OpenID Connect on this authentication server (too > much complex and difficult to implement). > > To meet such needs, proprietary products have the following solution. > > Proprietary authorization server products have their own procedure (much > simpler than OpenID Connect and SAMLv2) to communicate with existing > authentication server as below: > https://communities.ca.com/blogs/oauth/2016/10/04/howto- > integrating-otk-with-external-login-server?et=notification.send > https://www.ibm.com/support/knowledgecenter/en/SSMNED_5.0. > 0/com.ibm.apic.toolkit.doc/tapim_sec_api_config_scheme_oauth_endpoint.html > > In customer's existing authentication server, customers only have to > implement communication with the authorization server according to the > procedure prepared by the authorization server product (It is much easier > than implementing OpenID Connect or SAMLv2). Customers do not have to > implement anything in authorization server side. > On the other hand, if keycloak is used, customers have to do following: > a) In authorization server (RH SSO), simple procedure to communicate with > external authentication server have to be designed and implemented using > SPI. > b) In customer's existing authentication server, implement procedure > prepared by a). > -> In proprietary products, a) is prepared, but keycloak is not. > > Our proposed patch is intended to complement a). > > --- > > From: Stian Thorgersen [mailto:sthorger at redhat.com] > Sent: Monday, August 14, 2017 7:57 PM > To: ???? / NORIMATSU?TAKASHI > Cc: keycloak-dev at lists.jboss.org > Subject: [!]Re: [keycloak-dev] Proposal of using existing authentication > and authorization server on behalf of keycloak browser-based authentication > > I'm not really following what you are proposing to contribute to Keycloak. > We already have the SPI that allows adding a custom provider if your IdP > doesn't support SAML or OpenID Connect. > > On 31 July 2017 at 06:09, ???? / NORIMATSU?TAKASHI < > takashi.norimatsu.ws at hitachi.com> wrote: > Hello. > > Previously, I had proposed the feature and its implementation of > delegating authentication and authorization to an external existing server > on behalf of keycloak's browser-based authentication mechanism, and had > gotten advices that it is appropriate to use Identity Brokering for such > the feature. > > I've re-implemented this feature again by Identity Brokering. The > description and implementation of this feature is mentioned below. > https://github.com/Hitachi/PoV-keycloak-delegate-authn-consent > https://github.com/Hitachi/PoV-keycloak-delegate-authn- > consent/tree/master/src/keycloak/examples/providers/delegate-authn-consent > It can delegate not only authentication but authorization(consent). > > Kindly review it and provide us some comment and advices. > We would like to contribute this feature onto keycloak. > > Best Regards > Takashi Norimatsu > Hitachi, Ltd. > > --- > From: Stian Thorgersen [mailto:sthorger at redhat.com] > Sent: Thursday, June 29, 2017 6:23 PM > To: ???? / NORIMATSU?TAKASHI > Cc: keycloak-dev at lists.jboss.org > Subject: [!]Re: [keycloak-dev] Proposal of using existing authentication > server on behalf of keycloak browser-based authentication > > There's an SPI to implement your own custom identity brokering provider > [1]. > > [1] https://github.com/keycloak/keycloak/blob/master/ > server-spi-private/src/main/java/org/keycloak/broker/ > provider/IdentityProvider.java > > On 29 June 2017 at 10:51, ???? / NORIMATSU?TAKASHI < > takashi.norimatsu.ws at hitachi.com> wrote: > I need to use the authentication server without OIDC/OAuth2/SAMLv2 > implementation as an external IdP, > in order to integrate existing authentication system. > (some commercial products supports such the case) > > I consulted identity broker's section in keycloak's manual below and found > that if I use this feature the external IdP must support OIDC or SAMLv2. > https://keycloak.gitbooks.io/documentation/server_admin/ > topics/identity-broker.html > > Therefore, I realized it by using redirect based authentication flows. > > Can identity Brokering can support such the case? > > Aside from this, I'd like to contribute it to Community extensions and > examples. > > Best Regards > Takashi Norimatsu > Hitachi, Ltd. > > --- > From: Stian Thorgersen [mailto:sthorger at redhat.com] > Sent: Tuesday, June 27, 2017 5:52 PM > To: ???? / NORIMATSU?TAKASHI > Cc: keycloak-dev at lists.jboss.org > Subject: [!]Re: [keycloak-dev] Proposal of using existing authentication > server on behalf of keycloak browser-based authentication > > I'm not in favour of adding this. If it's using redirect based > authentication flows it should be done through identity brokering, not > authentication flows. It's also a very complex example that we don't want > to maintain. We've also in the process of moving all examples away from the > main Keycloak repository into a separate quickstart repository. > > On 27 June 2017 at 08:54, ???? / NORIMATSU?TAKASHI < > takashi.norimatsu.ws at hitachi.com> wrote: > Hello. > > Previously, I had proposed the feature of delegating authentication to an > external authentication server on behalf of keycloak's browser-based > authentication mechanism. > > I've integrated this feature to keycloak's "examples" packages and send PR > (https://github.com/keycloak/keycloak/pull/4260). > Hope this PR is reviewed and merged as an example for combining some > providers to customize keycloak. > > Detailed description of this feature is mentioned below. > https://github.com/Hitachi/PoV-keycloak-authentication-delegation > > I am now engaging in integrating this feature to keycloak as product-base > default providers, but encounter technical problems about writing > arquillian. Would someone tell me how to resolve this problem? > > [Problem] > - I could not find how to run an external authentication > server(application running on wildfly 10) during each arquillian test cases. > > After resolving this problem and writing and running arquillian test > cases, I'll send PR for this feature as product-base default providers. > > Best Regards > Takashi Norimatsu > Hitachi, Ltd. > > _______________________________________________ > 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 Aug 15 05:56:05 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 15 Aug 2017 11:56:05 +0200 Subject: [keycloak-dev] Upgraded to WildFly 11 Beta Message-ID: Master is now on WildFly 11 Beta. All tests passed on Travis so seems like it's all good. https://issues.jboss.org/browse/KEYCLOAK-5297 https://github.com/keycloak/keycloak/pull/4387 From sthorger at redhat.com Tue Aug 15 08:00:11 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 15 Aug 2017 14:00:11 +0200 Subject: [keycloak-dev] Remove realm json at "/auth/realms/" Message-ID: I propose we remove the realm json returned at "/auth/realms/" and just return an empty page * It can end-up being visible to end-users - we should rather have a realm welcome page / SSO landing page here * It's not used by anything AFAIK * From time to time people complain about it ( https://issues.jboss.org/browse/KEYCLOAK-5279 for instance, there's more similar issues reported) From psilva at redhat.com Tue Aug 15 08:22:34 2017 From: psilva at redhat.com (Pedro Igor Silva) Date: Tue, 15 Aug 2017 09:22:34 -0300 Subject: [keycloak-dev] Upgraded to WildFly 11 Beta In-Reply-To: References: Message-ID: Can we start enabling Elytron Adapter tests ? On Tue, Aug 15, 2017 at 6:56 AM, Stian Thorgersen wrote: > Master is now on WildFly 11 Beta. All tests passed on Travis so seems like > it's all good. > > https://issues.jboss.org/browse/KEYCLOAK-5297 > https://github.com/keycloak/keycloak/pull/4387 > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Tue Aug 15 08:32:11 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 15 Aug 2017 14:32:11 +0200 Subject: [keycloak-dev] Upgraded to WildFly 11 Beta In-Reply-To: References: Message-ID: Are they not already on in Central CI? We don't currently have any of the new adapter tests enabled by default in local builds or in Travis due to the time it takes to run. On 15 August 2017 at 14:22, Pedro Igor Silva wrote: > Can we start enabling Elytron Adapter tests ? > > On Tue, Aug 15, 2017 at 6:56 AM, Stian Thorgersen > wrote: > >> Master is now on WildFly 11 Beta. All tests passed on Travis so seems like >> it's all good. >> >> https://issues.jboss.org/browse/KEYCLOAK-5297 >> https://github.com/keycloak/keycloak/pull/4387 >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > From psilva at redhat.com Tue Aug 15 08:41:53 2017 From: psilva at redhat.com (Pedro Igor Silva) Date: Tue, 15 Aug 2017 09:41:53 -0300 Subject: [keycloak-dev] token exchange In-Reply-To: <9b6efb46-944c-213b-848e-4e82d922da6f@redhat.com> References: <71449542-5454-44e4-936b-2099e366d8b5@redhat.com> <49f60419-0d5b-9f0b-ec58-7c06eb513570@redhat.com> <64994417-43b0-95d3-5de9-c0d78a226d79@redhat.com> <9b6efb46-944c-213b-848e-4e82d922da6f@redhat.com> Message-ID: On Mon, Aug 14, 2017 at 10:42 AM, Bill Burke wrote: > CLI tool I wrote doesn't allow token exchange, yet, but you're correct, > I'm thinking of using it to perform token exchange. > > Our ID tokens are not signed right now. Also you still need client to > client exchange so that you can "downgrade" a token to talk to an untrusted > service. I've also added new fine-grain permissions "exchange-from" and > "exchange-to". > > For example, lets say Client A gets token and invokes on service B which > needs to invoke on untrusted service C. > When Client A gets token to invoke Service B, how the "aud" claim in the token looks like for you ? Is it referencing Service B ? Asking because I noticed that our access tokens are being issued using the authenticated client in "aud" claim where it should contain (or in addition to other audiences) the target service. A typical scenario for bearer token authentication. Also, our BearerTokenRequestAuthenticator does not seem to validate audience. Considering the flow you described, Client A would need a token with Service B as a valid audience in order to be able to start the flow. From sthorger at redhat.com Tue Aug 15 09:44:09 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 15 Aug 2017 15:44:09 +0200 Subject: [keycloak-dev] token exchange In-Reply-To: References: <71449542-5454-44e4-936b-2099e366d8b5@redhat.com> <49f60419-0d5b-9f0b-ec58-7c06eb513570@redhat.com> <64994417-43b0-95d3-5de9-c0d78a226d79@redhat.com> <9b6efb46-944c-213b-848e-4e82d922da6f@redhat.com> Message-ID: 'aud' is broken: https://issues.jboss.org/browse/KEYCLOAK-1201 Big question is how do you control what the list of "clients" in the aud should be? Manually? Based on scope (what about full scope and loads of clients, what about when there are no client roles)? On 15 August 2017 at 14:41, Pedro Igor Silva wrote: > > On Mon, Aug 14, 2017 at 10:42 AM, Bill Burke wrote: > >> CLI tool I wrote doesn't allow token exchange, yet, but you're correct, >> I'm thinking of using it to perform token exchange. >> >> Our ID tokens are not signed right now. Also you still need client to >> client exchange so that you can "downgrade" a token to talk to an untrusted >> service. I've also added new fine-grain permissions "exchange-from" and >> "exchange-to". >> >> For example, lets say Client A gets token and invokes on service B which >> needs to invoke on untrusted service C. >> > > When Client A gets token to invoke Service B, how the "aud" claim in the > token looks like for you ? Is it referencing Service B ? > > Asking because I noticed that our access tokens are being issued using the > authenticated client in "aud" claim where it should contain (or in addition > to other audiences) the target service. A typical scenario for bearer token > authentication. Also, our BearerTokenRequestAuthenticator does not seem > to validate audience. > > Considering the flow you described, Client A would need a token with > Service B as a valid audience in order to be able to start the flow. > From psilva at redhat.com Tue Aug 15 09:48:53 2017 From: psilva at redhat.com (Pedro Igor Silva) Date: Tue, 15 Aug 2017 10:48:53 -0300 Subject: [keycloak-dev] token exchange In-Reply-To: References: <71449542-5454-44e4-936b-2099e366d8b5@redhat.com> <49f60419-0d5b-9f0b-ec58-7c06eb513570@redhat.com> <64994417-43b0-95d3-5de9-c0d78a226d79@redhat.com> <9b6efb46-944c-213b-848e-4e82d922da6f@redhat.com> Message-ID: IMO, we should do it based on scopes. That is how OAuth2 is supposed to work, specially when AS is 1:N to resource servers. Clients would need to ask for a scope which can be mapped to a specific resource server / client application. There are other options that we can consider, but using scopes seems more aligned with the specs. On Tue, Aug 15, 2017 at 10:44 AM, Stian Thorgersen wrote: > 'aud' is broken: > https://issues.jboss.org/browse/KEYCLOAK-1201 > > Big question is how do you control what the list of "clients" in the aud > should be? Manually? Based on scope (what about full scope and loads of > clients, what about when there are no client roles)? > > On 15 August 2017 at 14:41, Pedro Igor Silva wrote: > >> >> On Mon, Aug 14, 2017 at 10:42 AM, Bill Burke wrote: >> >>> CLI tool I wrote doesn't allow token exchange, yet, but you're correct, >>> I'm thinking of using it to perform token exchange. >>> >>> Our ID tokens are not signed right now. Also you still need client to >>> client exchange so that you can "downgrade" a token to talk to an untrusted >>> service. I've also added new fine-grain permissions "exchange-from" and >>> "exchange-to". >>> >>> For example, lets say Client A gets token and invokes on service B which >>> needs to invoke on untrusted service C. >>> >> >> When Client A gets token to invoke Service B, how the "aud" claim in the >> token looks like for you ? Is it referencing Service B ? >> >> Asking because I noticed that our access tokens are being issued using >> the authenticated client in "aud" claim where it should contain (or in >> addition to other audiences) the target service. A typical scenario for >> bearer token authentication. Also, our BearerTokenRequestAuthenticator >> does not seem to validate audience. >> >> Considering the flow you described, Client A would need a token with >> Service B as a valid audience in order to be able to start the flow. >> > > From bburke at redhat.com Tue Aug 15 11:32:59 2017 From: bburke at redhat.com (Bill Burke) Date: Tue, 15 Aug 2017 11:32:59 -0400 Subject: [keycloak-dev] token exchange In-Reply-To: References: <71449542-5454-44e4-936b-2099e366d8b5@redhat.com> <49f60419-0d5b-9f0b-ec58-7c06eb513570@redhat.com> <64994417-43b0-95d3-5de9-c0d78a226d79@redhat.com> <9b6efb46-944c-213b-848e-4e82d922da6f@redhat.com> Message-ID: I would be worried about the security implications of allowing an ID token as a way to obtain access. If you have even one client in the domain that is not fully trusted then you are toast. So how is it set up to make things easy? One "master" client is defined in realm. That client is given permission to obtain exchange for anything. That client is marked as confidential. Generic CLI tool is configured with client id and secret of "master" client. On 8/15/17 2:50 AM, Stian Thorgersen wrote: > First of all I'm not arguing against token exchange service. It's a > very useful thing IMO and I can see loads of use-cases for it. I'm > just wondering about how usable it will be for the CLI tool and I'm > worried about how complicated it would be to setup. If the ID token > was signed that could serve as a the "identity cookie" for a CLI SSO > session (if ID token is not suitable we could introduce some sort of > identity token that can be used by direct grant to allow SSO > sessions). Using direct grant you can then easily obtain a token for a > specific client by just passing a valid "identity cookie" same way as > the web browser does. Is that not simpler to setup and use? > > On 14 August 2017 at 15:42, Bill Burke > wrote: > > CLI tool I wrote doesn't allow token exchange, yet, but you're > correct, I'm thinking of using it to perform token exchange. > > Our ID tokens are not signed right now. Also you still need > client to client exchange so that you can "downgrade" a token to > talk to an untrusted service. I've also added new fine-grain > permissions "exchange-from" and "exchange-to". > > For example, lets say Client A gets token and invokes on service B > which needs to invoke on untrusted service C. > > 1. Service B asks to exchange the token created for A to talk to C > 2. Token exchange endpoint looks at issuer, its A, so it sees if > service B has permission to "exchange-from" tokens created for A > 3. Token exchange then sees if B has permission to "exchange-to" B. > > FYI, I'm also expanding this so that you can exchange an access > token for a social provider token. Automatic refreshes and > everything if the provider supports it. Gonna change how client > initiated linking works too so that instead of doing the silly > hash algorithm required by the call, clients would call the > exchange first, get an error response like "not linked" that > contained a browser URL that the client can use to create the link. > > Also no reason I couldn't do the same for exchange an external > token to a internal one. Would work the same as our IDP, import > the user, etc. > > > On 8/14/17 7:06 AM, Stian Thorgersen wrote: >> I'm assuming the basic token exchange service comes from the way >> the CLI tool works? I.e. you login to the tool then it allows >> exchanging the token for a particular CLI client? >> >> Would it not be better to obtain an ID token and use direct grant >> to obtain a token for the client using the ID token as the >> authentication mechanism? >> >> On 1 August 2017 at 19:10, Pedro Igor Silva > > wrote: >> >> On Mon, Jul 31, 2017 at 1:54 PM, Bill Burke >> > wrote: >> >> > >> > >> > On 7/31/17 12:18 PM, Bill Burke wrote: >> > >> > >> > >> > On 7/31/17 11:35 AM, Pedro Igor Silva wrote: >> > >> > On Fri, Jul 28, 2017 at 5:24 PM, Bill Burke >> > wrote: >> > >> >> I've implemented a simple token exchange API [1] that >> allows you to >> >> exchange an access token created for one client to another >> client. The >> >> REST API follows the oauth token exchange api [2] very >> loosely. >> >> >> >> subject_token: a keycloak access token >> >> >> >> audience: takes a client id >> >> >> >> It then converts the access token created for one client >> and converts it >> >> to another. It lives under the token endpoint. >> >> >> >> The security model is as follows: >> >> >> >> * Authenticate calling client the same way as password grant. >> >> >> >> * The calling client must have service account enabled >> >> >> >> * Service account must have a realm role "token-exchanger" >> grant edto it >> >> or, it must have a client role "token-exchanger" granted >> to it. This >> >> exchanger client role is a role defined by the target >> client you are >> >> exchanging the token to. >> >> >> >> >> >> Is this a good security model? I'm thinking of not >> creating these roles >> >> right now and to enable support for exchange would require >> defining the >> >> roles specified above. >> >> >> > >> > I think roles are too coarse-grained to represent this kind >> of policy. A >> > better option would be to explicitly define the clients >> that are allowed to >> > exchange tokens for a particular resource server. Eg.: >> > >> > RS A allows Client B, C and D to exchange their tokens >> where the target >> > audience is RS A (or if using "resource", a specific >> resource in RS A). >> > >> > >> > I changed it a little. actors are: >> > >> > * Authenticated client asking for change >> > * Clients that are the audience of the token being exchanged >> > * Client you want the token to be exchanged to >> > >> > So, the authenticated client must be in the audience of the >> token being >> > exchanged, or, have permission to exchange from that >> particular audience. >> > The authenticated client also must have permission to >> exchange to the >> > audience it wants to exchange to. >> > >> > Good idea to change it to use the fine grain admin >> permissions. There's a >> > couple of issues/problems with doing this that I think are >> easily done: >> > >> > * public clients can't have service accounts. >> > * Client Policy looks at kc_client_id attribute which is >> pulled from the >> > issuedFor claim in the token. This isn't correct as we >> permission checks >> > based on the authenticated client, not the token. >> > >> > So I'll have to create a new Identity type that either >> wraps the service >> > account or ClientModel and sets the "kc_client_id" property. >> > >> >> Our policy evaluation engine is based on the claims within >> the token. The >> "issueFor" is basically the "azp" claim from OIDC. In fact, >> we don't even >> need that "kc_client_id". We could make this configurable >> though, and let >> users decide whether they want to check the "authenticated >> client" or "azp" >> ? >> >> Btw, I'm about to finish UMA Grant Type, one of the changes >> I'm doing for >> UMA 2.0. My changes will conflict with yours. Are you going >> to merge your >> changes soon ? >> >> Another thing I noticed is that maybe we could have a SPI for >> custom grant >> types. What you did and what I'm doing may justify a specific >> SPI for >> plugging custom grant types. Maybe too much, but maybe a nice >> to have. >> >> >> > >> > >> > Bill >> > >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> > > From bburke at redhat.com Tue Aug 15 11:47:24 2017 From: bburke at redhat.com (Bill Burke) Date: Tue, 15 Aug 2017 11:47:24 -0400 Subject: [keycloak-dev] generic cli sso utility In-Reply-To: References: <0cfaaecd-51ab-eacb-cba3-a536acd6c943@redhat.com> <3958ff9c-a987-51ad-1d8c-d115d4d99b7a@redhat.com> Message-ID: The end goal I want is that for CLI SSO, Keycloak is the SSO mechanism that can do kerberos, client-cert, or whatever mechanism the admin desires, and specific app CLI's only worry about propagating bearer tokens. More comments inline: On 8/15/17 2:46 AM, Stian Thorgersen wrote: > I don't think leveraging a text-based browser is a good idea: > > * No-one has one installed and they suck big time. You probably need > Cygwin on Windows to get one as well > * Would require special themes to make anything that would be remotely > usable > * Not always usable on a remote shell. You need to do ssh (and other > things) with special commands to have an emulated terminal rather than > just a stream of characters > > As separate flow and/or extending direct grant to have some sort of > challenge/response would probably be better. > > Thinking about 3 different use-cases for the CLI: > > * Desktop - in this case the system browser is probably the best > option as there's then SSO between web and CLIs and there's the best > UI available I like KeycloakInstalled, but its still a bit quirky. Person has to manually close the browser. KeycloakInstalled also probably needs a themeable splash screen after authentication completes. > * Server/RSH - in this case wouldn't private/public keys be the best > option? SSH does this very well with RSA keys. We could even just use > the same keys as SSH by allowing users to upload their public SSH key Maybe its just a matter of doing an SSO login once and creating and storing an offline token? Could even protect the token by encrypting it with a local pin/pw. Bill From bburke at redhat.com Tue Aug 15 11:50:01 2017 From: bburke at redhat.com (Bill Burke) Date: Tue, 15 Aug 2017 11:50:01 -0400 Subject: [keycloak-dev] token exchange In-Reply-To: References: <71449542-5454-44e4-936b-2099e366d8b5@redhat.com> <49f60419-0d5b-9f0b-ec58-7c06eb513570@redhat.com> <64994417-43b0-95d3-5de9-c0d78a226d79@redhat.com> <9b6efb46-944c-213b-848e-4e82d922da6f@redhat.com> Message-ID: <6ff23f98-f940-7e93-d970-860602838199@redhat.com> On 8/15/17 8:41 AM, Pedro Igor Silva wrote: > > On Mon, Aug 14, 2017 at 10:42 AM, Bill Burke > wrote: > > CLI tool I wrote doesn't allow token exchange, yet, but you're > correct, I'm thinking of using it to perform token exchange. > > Our ID tokens are not signed right now. Also you still need > client to client exchange so that you can "downgrade" a token to > talk to an untrusted service. I've also added new fine-grain > permissions "exchange-from" and "exchange-to". > > For example, lets say Client A gets token and invokes on service B > which needs to invoke on untrusted service C. > > > When Client A gets token to invoke Service B, how the "aud" claim in > the token looks like for you ? Is it referencing Service B ? > > Asking because I noticed that our access tokens are being issued using > the authenticated client in "aud" claim where it should contain (or in > addition to other audiences) the target service. A typical scenario > for bearer token authentication. Also, our > BearerTokenRequestAuthenticator does not seem to validate audience. > > Considering the flow you described, Client A would need a token with > Service B as a valid audience in order to be able to start the flow. "aud" is who the token is created for. i.e. the audience defines how the token is formatted: role mappings, claims, etc. "azp" is who the token is issued for. In an exchange situation like above "aud" would be Service C, but the "azp" claim would be "B". At least, that's how I have it implemented right now. Bill From bburke at redhat.com Tue Aug 15 11:51:53 2017 From: bburke at redhat.com (Bill Burke) Date: Tue, 15 Aug 2017 11:51:53 -0400 Subject: [keycloak-dev] token exchange In-Reply-To: References: <71449542-5454-44e4-936b-2099e366d8b5@redhat.com> <49f60419-0d5b-9f0b-ec58-7c06eb513570@redhat.com> <64994417-43b0-95d3-5de9-c0d78a226d79@redhat.com> <9b6efb46-944c-213b-848e-4e82d922da6f@redhat.com> Message-ID: <661fb731-034b-8675-1eeb-699626d16462@redhat.com> I don't agree with the JIRA. See my previous email: aud" is who the token is created for. i.e. the audience defines how the token is formatted: role mappings, claims, etc. "azp" is who the token is issued for. In an exchange situation like above "aud" would be Service C, but the "azp" claim would be "B". At least, that's how I have it implemented right now. On 8/15/17 9:44 AM, Stian Thorgersen wrote: > 'aud' is broken: > https://issues.jboss.org/browse/KEYCLOAK-1201 > > Big question is how do you control what the list of "clients" in the > aud should be? Manually? Based on scope (what about full scope and > loads of clients, what about when there are no client roles)? > > On 15 August 2017 at 14:41, Pedro Igor Silva > wrote: > > > On Mon, Aug 14, 2017 at 10:42 AM, Bill Burke > wrote: > > CLI tool I wrote doesn't allow token exchange, yet, but you're > correct, I'm thinking of using it to perform token exchange. > > Our ID tokens are not signed right now. Also you still need > client to client exchange so that you can "downgrade" a token > to talk to an untrusted service. I've also added new > fine-grain permissions "exchange-from" and "exchange-to". > > For example, lets say Client A gets token and invokes on > service B which needs to invoke on untrusted service C. > > > When Client A gets token to invoke Service B, how the "aud" claim > in the token looks like for you ? Is it referencing Service B ? > > Asking because I noticed that our access tokens are being issued > using the authenticated client in "aud" claim where it should > contain (or in addition to other audiences) the target service. A > typical scenario for bearer token authentication. Also, our > BearerTokenRequestAuthenticator does not seem to validate audience. > > Considering the flow you described, Client A would need a token > with Service B as a valid audience in order to be able to start > the flow. > > From bburke at redhat.com Tue Aug 15 11:58:57 2017 From: bburke at redhat.com (Bill Burke) Date: Tue, 15 Aug 2017 11:58:57 -0400 Subject: [keycloak-dev] token exchange In-Reply-To: References: <71449542-5454-44e4-936b-2099e366d8b5@redhat.com> <49f60419-0d5b-9f0b-ec58-7c06eb513570@redhat.com> <64994417-43b0-95d3-5de9-c0d78a226d79@redhat.com> <9b6efb46-944c-213b-848e-4e82d922da6f@redhat.com> Message-ID: <17e73e76-54c3-fed6-8fb1-34ae3864a2de@redhat.com> I disagree Pedro. Needs to be based scopes and/or audience. In our original example, Service B only knows he wants to talk to Service C. Shouldn't have to know the set of scopes he needs to "downgrade" to talk to C. The original OAuth spec assumed that the browser would be involved. Scopes are useful in that sense as the IDP can ask for consent. There's no way to ask for consent from the user in a service to service invocation. Hence, we have the token-exchange Draft in OAuth WG and this is why that spec offers both scope and audience as parameters. On 8/15/17 9:48 AM, Pedro Igor Silva wrote: > IMO, we should do it based on scopes. That is how OAuth2 is supposed > to work, specially when AS is 1:N to resource servers. Clients would > need to ask for a scope which can be mapped to a specific resource > server / client application. > > There are other options that we can consider, but using scopes seems > more aligned with the specs. > > On Tue, Aug 15, 2017 at 10:44 AM, Stian Thorgersen > > wrote: > > 'aud' is broken: > https://issues.jboss.org/browse/KEYCLOAK-1201 > > > Big question is how do you control what the list of "clients" in > the aud should be? Manually? Based on scope (what about full scope > and loads of clients, what about when there are no client roles)? > > On 15 August 2017 at 14:41, Pedro Igor Silva > wrote: > > > On Mon, Aug 14, 2017 at 10:42 AM, Bill Burke > > wrote: > > CLI tool I wrote doesn't allow token exchange, yet, but > you're correct, I'm thinking of using it to perform token > exchange. > > Our ID tokens are not signed right now. Also you still > need client to client exchange so that you can "downgrade" > a token to talk to an untrusted service. I've also added > new fine-grain permissions "exchange-from" and "exchange-to". > > For example, lets say Client A gets token and invokes on > service B which needs to invoke on untrusted service C. > > > When Client A gets token to invoke Service B, how the "aud" > claim in the token looks like for you ? Is it referencing > Service B ? > > Asking because I noticed that our access tokens are being > issued using the authenticated client in "aud" claim where it > should contain (or in addition to other audiences) the target > service. A typical scenario for bearer token authentication. > Also, our BearerTokenRequestAuthenticator does not seem to > validate audience. > > Considering the flow you described, Client A would need a > token with Service B as a valid audience in order to be able > to start the flow. > > > From bburke at redhat.com Tue Aug 15 13:18:57 2017 From: bburke at redhat.com (Bill Burke) Date: Tue, 15 Aug 2017 13:18:57 -0400 Subject: [keycloak-dev] Remove realm json at "/auth/realms/" In-Reply-To: References: Message-ID: The idea of that URL is to expose public information about the realm, i.e. public cert/key and public endpoint urls. If this information is not being used and we have other mechanisms in place, then yeah, remove it. IMO, the jira you reference is unrelated. Its about shutting down the admin console/API. As far as that goes, it would be cool to split up keycloak into separate subsystems: * backend (required) * admin api/console * account service * authentication/brokering/token endpoints Even have the admin api/console be exposed from a different bind address/port. On 8/15/17 8:00 AM, Stian Thorgersen wrote: > I propose we remove the realm json returned at "/auth/realms/" > and just return an empty page > > * It can end-up being visible to end-users - we should rather have a realm > welcome page / SSO landing page here > * It's not used by anything AFAIK > * From time to time people complain about it ( > https://issues.jboss.org/browse/KEYCLOAK-5279 for instance, there's more > similar issues reported) > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Tue Aug 15 13:22:32 2017 From: bburke at redhat.com (Bill Burke) Date: Tue, 15 Aug 2017 13:22:32 -0400 Subject: [keycloak-dev] Upgraded to WildFly 11 Beta In-Reply-To: References: Message-ID: Can't you just create a smaller job in Travis for this? Is there a total limit we are getting close to reaching? LDAP and DB compatiblity is one thing, but, we need Travis to pick up as much as possible. Otherwise its very hard for us to release on demand. Our release process is already really slow and other parts of the company are complaining that its too long. On 8/15/17 8:32 AM, Stian Thorgersen wrote: > Are they not already on in Central CI? We don't currently have any of the > new adapter tests enabled by default in local builds or in Travis due to > the time it takes to run. > > On 15 August 2017 at 14:22, Pedro Igor Silva wrote: > >> Can we start enabling Elytron Adapter tests ? >> >> On Tue, Aug 15, 2017 at 6:56 AM, Stian Thorgersen >> wrote: >> >>> Master is now on WildFly 11 Beta. All tests passed on Travis so seems like >>> it's all good. >>> >>> https://issues.jboss.org/browse/KEYCLOAK-5297 >>> https://github.com/keycloak/keycloak/pull/4387 >>> _______________________________________________ >>> 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 psilva at redhat.com Tue Aug 15 13:39:49 2017 From: psilva at redhat.com (Pedro Igor Silva) Date: Tue, 15 Aug 2017 14:39:49 -0300 Subject: [keycloak-dev] token exchange In-Reply-To: <17e73e76-54c3-fed6-8fb1-34ae3864a2de@redhat.com> References: <71449542-5454-44e4-936b-2099e366d8b5@redhat.com> <49f60419-0d5b-9f0b-ec58-7c06eb513570@redhat.com> <64994417-43b0-95d3-5de9-c0d78a226d79@redhat.com> <9b6efb46-944c-213b-848e-4e82d922da6f@redhat.com> <17e73e76-54c3-fed6-8fb1-34ae3864a2de@redhat.com> Message-ID: Sure, my question and arguments were related with Client A asking for a token to access Service B. Service B -> Service C is what you are doing with token exchange. Otherwise, you will need to use token exchange in Client A to ask a token for Service B. Where Client A is not even a resource server, thus a "aud" claim referencing Client A is useless. On Tue, Aug 15, 2017 at 12:58 PM, Bill Burke wrote: > I disagree Pedro. Needs to be based scopes and/or audience. In our > original example, Service B only knows he wants to talk to Service C. > Shouldn't have to know the set of scopes he needs to "downgrade" to talk to > C. > > The original OAuth spec assumed that the browser would be involved. > Scopes are useful in that sense as the IDP can ask for consent. There's no > way to ask for consent from the user in a service to service invocation. > Hence, we have the token-exchange Draft in OAuth WG and this is why that > spec offers both scope and audience as parameters. > > On 8/15/17 9:48 AM, Pedro Igor Silva wrote: > > IMO, we should do it based on scopes. That is how OAuth2 is supposed to > work, specially when AS is 1:N to resource servers. Clients would need to > ask for a scope which can be mapped to a specific resource server / client > application. > > There are other options that we can consider, but using scopes seems more > aligned with the specs. > > On Tue, Aug 15, 2017 at 10:44 AM, Stian Thorgersen > wrote: > >> 'aud' is broken: >> https://issues.jboss.org/browse/KEYCLOAK-1201 >> >> Big question is how do you control what the list of "clients" in the aud >> should be? Manually? Based on scope (what about full scope and loads of >> clients, what about when there are no client roles)? >> >> On 15 August 2017 at 14:41, Pedro Igor Silva wrote: >> >>> >>> On Mon, Aug 14, 2017 at 10:42 AM, Bill Burke wrote: >>> >>>> CLI tool I wrote doesn't allow token exchange, yet, but you're correct, >>>> I'm thinking of using it to perform token exchange. >>>> >>>> Our ID tokens are not signed right now. Also you still need client to >>>> client exchange so that you can "downgrade" a token to talk to an untrusted >>>> service. I've also added new fine-grain permissions "exchange-from" and >>>> "exchange-to". >>>> >>>> For example, lets say Client A gets token and invokes on service B >>>> which needs to invoke on untrusted service C. >>>> >>> >>> When Client A gets token to invoke Service B, how the "aud" claim in the >>> token looks like for you ? Is it referencing Service B ? >>> >>> Asking because I noticed that our access tokens are being issued using >>> the authenticated client in "aud" claim where it should contain (or in >>> addition to other audiences) the target service. A typical scenario for >>> bearer token authentication. Also, our BearerTokenRequestAuthenticator >>> does not seem to validate audience. >>> >>> Considering the flow you described, Client A would need a token with >>> Service B as a valid audience in order to be able to start the flow. >>> >> >> > > From psilva at redhat.com Tue Aug 15 13:51:53 2017 From: psilva at redhat.com (Pedro Igor Silva) Date: Tue, 15 Aug 2017 14:51:53 -0300 Subject: [keycloak-dev] token exchange In-Reply-To: References: <71449542-5454-44e4-936b-2099e366d8b5@redhat.com> <49f60419-0d5b-9f0b-ec58-7c06eb513570@redhat.com> <64994417-43b0-95d3-5de9-c0d78a226d79@redhat.com> <9b6efb46-944c-213b-848e-4e82d922da6f@redhat.com> Message-ID: We have discussed this before (I think because of Kubernetes), I don't see issues about using the IDToken as a bearer for "authentication". Of course, as long as you enforce validations that check if token can be trusted. In fact, I was about to start a discussion around IDToken and signature. In UMA 2.0 you can use different claim token formats to obtain a token (RPT) from the token endpoint. There is a specific grant type for that. One of the main changes we had in the specs. A common format is " http://openid.net/specs/openid-connect-core-1_0.html#HybridIDToken", which is about using an IDToken. On Tue, Aug 15, 2017 at 12:32 PM, Bill Burke wrote: > I would be worried about the security implications of allowing an ID token > as a way to obtain access. If you have even one client in the domain that > is not fully trusted then you are toast. So how is it set up to make > things easy? One "master" client is defined in realm. That client is > given permission to obtain exchange for anything. That client is marked as > confidential. Generic CLI tool is configured with client id and secret of > "master" client. > On 8/15/17 2:50 AM, Stian Thorgersen wrote: > > First of all I'm not arguing against token exchange service. It's a very > useful thing IMO and I can see loads of use-cases for it. I'm just > wondering about how usable it will be for the CLI tool and I'm worried > about how complicated it would be to setup. If the ID token was signed that > could serve as a the "identity cookie" for a CLI SSO session (if ID token > is not suitable we could introduce some sort of identity token that can be > used by direct grant to allow SSO sessions). Using direct grant you can > then easily obtain a token for a specific client by just passing a valid > "identity cookie" same way as the web browser does. Is that not simpler to > setup and use? > > On 14 August 2017 at 15:42, Bill Burke wrote: > >> CLI tool I wrote doesn't allow token exchange, yet, but you're correct, >> I'm thinking of using it to perform token exchange. >> >> Our ID tokens are not signed right now. Also you still need client to >> client exchange so that you can "downgrade" a token to talk to an untrusted >> service. I've also added new fine-grain permissions "exchange-from" and >> "exchange-to". >> >> For example, lets say Client A gets token and invokes on service B which >> needs to invoke on untrusted service C. >> >> 1. Service B asks to exchange the token created for A to talk to C >> 2. Token exchange endpoint looks at issuer, its A, so it sees if service >> B has permission to "exchange-from" tokens created for A >> 3. Token exchange then sees if B has permission to "exchange-to" B. >> >> FYI, I'm also expanding this so that you can exchange an access token for >> a social provider token. Automatic refreshes and everything if the >> provider supports it. Gonna change how client initiated linking works too >> so that instead of doing the silly hash algorithm required by the call, >> clients would call the exchange first, get an error response like "not >> linked" that contained a browser URL that the client can use to create the >> link. >> >> Also no reason I couldn't do the same for exchange an external token to a >> internal one. Would work the same as our IDP, import the user, etc. >> >> >> On 8/14/17 7:06 AM, Stian Thorgersen wrote: >> >> I'm assuming the basic token exchange service comes from the way the CLI >> tool works? I.e. you login to the tool then it allows exchanging the token >> for a particular CLI client? >> >> Would it not be better to obtain an ID token and use direct grant to >> obtain a token for the client using the ID token as the authentication >> mechanism? >> >> On 1 August 2017 at 19:10, Pedro Igor Silva wrote: >> >>> On Mon, Jul 31, 2017 at 1:54 PM, Bill Burke wrote: >>> >>> > >>> > >>> > On 7/31/17 12:18 PM, Bill Burke wrote: >>> > >>> > >>> > >>> > On 7/31/17 11:35 AM, Pedro Igor Silva wrote: >>> > >>> > On Fri, Jul 28, 2017 at 5:24 PM, Bill Burke wrote: >>> > >>> >> I've implemented a simple token exchange API [1] that allows you to >>> >> exchange an access token created for one client to another client. >>> The >>> >> REST API follows the oauth token exchange api [2] very loosely. >>> >> >>> >> subject_token: a keycloak access token >>> >> >>> >> audience: takes a client id >>> >> >>> >> It then converts the access token created for one client and converts >>> it >>> >> to another. It lives under the token endpoint. >>> >> >>> >> The security model is as follows: >>> >> >>> >> * Authenticate calling client the same way as password grant. >>> >> >>> >> * The calling client must have service account enabled >>> >> >>> >> * Service account must have a realm role "token-exchanger" grant edto >>> it >>> >> or, it must have a client role "token-exchanger" granted to it. This >>> >> exchanger client role is a role defined by the target client you are >>> >> exchanging the token to. >>> >> >>> >> >>> >> Is this a good security model? I'm thinking of not creating these >>> roles >>> >> right now and to enable support for exchange would require defining >>> the >>> >> roles specified above. >>> >> >>> > >>> > I think roles are too coarse-grained to represent this kind of policy. >>> A >>> > better option would be to explicitly define the clients that are >>> allowed to >>> > exchange tokens for a particular resource server. Eg.: >>> > >>> > RS A allows Client B, C and D to exchange their tokens where the target >>> > audience is RS A (or if using "resource", a specific resource in RS A). >>> > >>> > >>> > I changed it a little. actors are: >>> > >>> > * Authenticated client asking for change >>> > * Clients that are the audience of the token being exchanged >>> > * Client you want the token to be exchanged to >>> > >>> > So, the authenticated client must be in the audience of the token being >>> > exchanged, or, have permission to exchange from that particular >>> audience. >>> > The authenticated client also must have permission to exchange to the >>> > audience it wants to exchange to. >>> > >>> > Good idea to change it to use the fine grain admin permissions. >>> There's a >>> > couple of issues/problems with doing this that I think are easily done: >>> > >>> > * public clients can't have service accounts. >>> > * Client Policy looks at kc_client_id attribute which is pulled from >>> the >>> > issuedFor claim in the token. This isn't correct as we permission >>> checks >>> > based on the authenticated client, not the token. >>> > >>> > So I'll have to create a new Identity type that either wraps the >>> service >>> > account or ClientModel and sets the "kc_client_id" property. >>> > >>> >>> Our policy evaluation engine is based on the claims within the token. The >>> "issueFor" is basically the "azp" claim from OIDC. In fact, we don't even >>> need that "kc_client_id". We could make this configurable though, and let >>> users decide whether they want to check the "authenticated client" or >>> "azp" >>> ? >>> >>> Btw, I'm about to finish UMA Grant Type, one of the changes I'm doing for >>> UMA 2.0. My changes will conflict with yours. Are you going to merge your >>> changes soon ? >>> >>> Another thing I noticed is that maybe we could have a SPI for custom >>> grant >>> types. What you did and what I'm doing may justify a specific SPI for >>> plugging custom grant types. Maybe too much, but maybe a nice to have. >>> >>> >>> > >>> > >>> > Bill >>> > >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> >> > > From jdennis at redhat.com Tue Aug 15 15:47:25 2017 From: jdennis at redhat.com (John Dennis) Date: Tue, 15 Aug 2017 15:47:25 -0400 Subject: [keycloak-dev] generic cli sso utility In-Reply-To: References: <0cfaaecd-51ab-eacb-cba3-a536acd6c943@redhat.com> <3958ff9c-a987-51ad-1d8c-d115d4d99b7a@redhat.com> Message-ID: <6dd799d5-7a8a-0140-3e07-cc9baad1cfd1@redhat.com> On 08/15/2017 11:47 AM, Bill Burke wrote: > Maybe its just a matter of doing an SSO login once and creating and > storing an offline token? Could even protect the token by encrypting it > with a local pin/pw. Why not use the platform keyring? -- John From sthorger at redhat.com Wed Aug 16 02:55:26 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 16 Aug 2017 08:55:26 +0200 Subject: [keycloak-dev] Remove realm json at "/auth/realms/" In-Reply-To: References: Message-ID: Why split it into multiple subsystems? Are you only talking about the ability to enable/disable? If so that can easily be added through the profile feature like we do for authorization services. That's probably 2 min work. The ability to expose admin endpoints on a different address/port would be great. On 15 August 2017 at 19:18, Bill Burke wrote: > The idea of that URL is to expose public information about the realm, > i.e. public cert/key and public endpoint urls. If this information is > not being used and we have other mechanisms in place, then yeah, remove it. > > IMO, the jira you reference is unrelated. Its about shutting down the > admin console/API. As far as that goes, it would be cool to split up > keycloak into separate subsystems: > > * backend (required) > * admin api/console > * account service > * authentication/brokering/token endpoints > > Even have the admin api/console be exposed from a different bind > address/port. > > On 8/15/17 8:00 AM, Stian Thorgersen wrote: > > I propose we remove the realm json returned at "/auth/realms/ name>" > > and just return an empty page > > > > * It can end-up being visible to end-users - we should rather have a > realm > > welcome page / SSO landing page here > > * It's not used by anything AFAIK > > * From time to time people complain about it ( > > https://issues.jboss.org/browse/KEYCLOAK-5279 for instance, there's more > > similar issues reported) > > _______________________________________________ > > 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 Aug 16 02:59:54 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 16 Aug 2017 08:59:54 +0200 Subject: [keycloak-dev] Upgraded to WildFly 11 Beta In-Reply-To: References: Message-ID: Travis limits how many jobs can run in parallel (up to 5, but depends on overall load from all users) as well as a time limit per job. We can add more jobs, but that would impact time it takes to test a PR. How long would you be happy to wait for PR tests to complete? On 15 August 2017 at 19:22, Bill Burke wrote: > Can't you just create a smaller job in Travis for this? Is there a > total limit we are getting close to reaching? LDAP and DB compatiblity > is one thing, but, we need Travis to pick up as much as possible. > Otherwise its very hard for us to release on demand. Our release > process is already really slow and other parts of the company are > complaining that its too long. > > > On 8/15/17 8:32 AM, Stian Thorgersen wrote: > > Are they not already on in Central CI? We don't currently have any of the > > new adapter tests enabled by default in local builds or in Travis due to > > the time it takes to run. > > > > On 15 August 2017 at 14:22, Pedro Igor Silva wrote: > > > >> Can we start enabling Elytron Adapter tests ? > >> > >> On Tue, Aug 15, 2017 at 6:56 AM, Stian Thorgersen > >> wrote: > >> > >>> Master is now on WildFly 11 Beta. All tests passed on Travis so seems > like > >>> it's all good. > >>> > >>> https://issues.jboss.org/browse/KEYCLOAK-5297 > >>> https://github.com/keycloak/keycloak/pull/4387 > >>> _______________________________________________ > >>> 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 rudreshsj at gmail.com Wed Aug 16 05:30:06 2017 From: rudreshsj at gmail.com (Rudresh Shashikant) Date: Wed, 16 Aug 2017 16:30:06 +0700 Subject: [keycloak-dev] Extending Keycloak with custom integrations Message-ID: Hi All, first time posting in the mailing list. I have a client that needs the following: + social integration for login + after successful login, need to be able to extend keycloak to talk to a backend API and get additional information about this user + also need to use that additional information for an extra step involving OTP (via SMS) + end result of this additional workflow is to associate the social login of the user with their internal Enterprise userId +----------------------------------+ | Assumption: Social login complete| +----------------------------------+ User Keycloak Backend API SMS OTP <--------------------- ---------------------> user code ----------------------> <--------------------- user mobile# --------------------------------------------------> <---------------------------------------------------------------------- <-------------------------------------------------- -------------------> +---------------------+ | if successful, link | | user code to | | social login | +---------------------+ I will proceed to go through the codebase and documentation now but have started by reaching out to the community first in case anyone can point me in the correct direction. Thanks in advance. Regards, Rudy. From john.d.ament at gmail.com Wed Aug 16 06:12:04 2017 From: john.d.ament at gmail.com (John D. Ament) Date: Wed, 16 Aug 2017 10:12:04 +0000 Subject: [keycloak-dev] Remove realm json at "/auth/realms/" In-Reply-To: References: Message-ID: KEYCLOAK-5279 isn't asking to split it out. We're dealing with the access at a network level, making it so that certain URIs aren't accessible. But the ability to hide the fact that it may need to exist is important. I think the more relevant ticket is KEYCLOAK-5277, where at least in a multitenant fashion the fact that a realm may exist is considered sensitive information. The fact that there's a public API that returns 200/404 if a realm exists is considered a problem, so having it removed would alleviate any concerns in that area. On Tue, Aug 15, 2017 at 1:19 PM Bill Burke wrote: > The idea of that URL is to expose public information about the realm, > i.e. public cert/key and public endpoint urls. If this information is > not being used and we have other mechanisms in place, then yeah, remove it. > > IMO, the jira you reference is unrelated. Its about shutting down the > admin console/API. As far as that goes, it would be cool to split up > keycloak into separate subsystems: > > * backend (required) > * admin api/console > * account service > * authentication/brokering/token endpoints > > Even have the admin api/console be exposed from a different bind > address/port. > > On 8/15/17 8:00 AM, Stian Thorgersen wrote: > > I propose we remove the realm json returned at "/auth/realms/ name>" > > and just return an empty page > > > > * It can end-up being visible to end-users - we should rather have a > realm > > welcome page / SSO landing page here > > * It's not used by anything AFAIK > > * From time to time people complain about it ( > > https://issues.jboss.org/browse/KEYCLOAK-5279 for instance, there's more > > similar issues reported) > > _______________________________________________ > > 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 Aug 16 07:55:31 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 16 Aug 2017 13:55:31 +0200 Subject: [keycloak-dev] generic cli sso utility In-Reply-To: <6dd799d5-7a8a-0140-3e07-cc9baad1cfd1@redhat.com> References: <0cfaaecd-51ab-eacb-cba3-a536acd6c943@redhat.com> <3958ff9c-a987-51ad-1d8c-d115d4d99b7a@redhat.com> <6dd799d5-7a8a-0140-3e07-cc9baad1cfd1@redhat.com> Message-ID: On 15 August 2017 at 21:47, John Dennis wrote: > On 08/15/2017 11:47 AM, Bill Burke wrote: > >> Maybe its just a matter of doing an SSO login once and creating and >> storing an offline token? Could even protect the token by encrypting it >> with a local pin/pw. >> > > Why not use the platform keyring? I doubt there's a cross-OS way to do that > > > -- > John > From sthorger at redhat.com Wed Aug 16 07:58:49 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 16 Aug 2017 13:58:49 +0200 Subject: [keycloak-dev] generic cli sso utility In-Reply-To: References: <0cfaaecd-51ab-eacb-cba3-a536acd6c943@redhat.com> <3958ff9c-a987-51ad-1d8c-d115d4d99b7a@redhat.com> Message-ID: On 15 August 2017 at 17:47, Bill Burke wrote: > The end goal I want is that for CLI SSO, Keycloak is the SSO mechanism > that can do kerberos, client-cert, or whatever mechanism the admin desires, > and specific app CLI's only worry about propagating bearer tokens. More > comments inline: > > > On 8/15/17 2:46 AM, Stian Thorgersen wrote: > >> I don't think leveraging a text-based browser is a good idea: >> >> * No-one has one installed and they suck big time. You probably need >> Cygwin on Windows to get one as well >> * Would require special themes to make anything that would be remotely >> usable >> * Not always usable on a remote shell. You need to do ssh (and other >> things) with special commands to have an emulated terminal rather than just >> a stream of characters >> >> As separate flow and/or extending direct grant to have some sort of >> challenge/response would probably be better. >> >> Thinking about 3 different use-cases for the CLI: >> >> * Desktop - in this case the system browser is probably the best option >> as there's then SSO between web and CLIs and there's the best UI available >> > I like KeycloakInstalled, but its still a bit quirky. Person has to > manually close the browser. KeycloakInstalled also probably needs a > themeable splash screen after authentication completes. KeycloakInstalled is very rough/quirky. I did it many years ago and it was kinda just a quick prototype more than anything. > > > > * Server/RSH - in this case wouldn't private/public keys be the best >> option? SSH does this very well with RSA keys. We could even just use the >> same keys as SSH by allowing users to upload their public SSH key >> > Maybe its just a matter of doing an SSO login once and creating and > storing an offline token? Could even protect the token by encrypting it > with a local pin/pw. True an offline token is a nice way to do it, but how do you do the login once if there's no UI available? You can do direct grant with username/password, but what if there's OTP or some other even more crazy auth mechanism in place for the web flow? Kinda where I think there's going to be a need for a CLI flow and a web flow. > > > Bill > From alkazako at redhat.com Wed Aug 16 09:40:24 2017 From: alkazako at redhat.com (Alexey Kazakov) Date: Wed, 16 Aug 2017 06:40:24 -0700 Subject: [keycloak-dev] Remove realm json at "/auth/realms/" In-Reply-To: References: Message-ID: <9c42e9ba-93cc-660d-103a-cb9cd28c46ca@redhat.com> On 08/15/2017 05:00 AM, Stian Thorgersen wrote: > I propose we remove the realm json returned at "/auth/realms/" > and just return an empty page > > * It can end-up being visible to end-users - we should rather have a realm > welcome page / SSO landing page here What is wrong with exposing this json to users? > * It's not used by anything AFAIK I'm not sure if this endpoint is documented but it can be used by users/clients. For example we use this endpoint to fetch the public key of the realm in openshift.io plus for simple health check. Should something else be used instead? > * From time to time people complain about it ( > https://issues.jboss.org/browse/KEYCLOAK-5279 for instance, there's more > similar issues reported) It seems that I don't have access to this issue. What kind of problems this endpoint can cause? > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Wed Aug 16 10:29:37 2017 From: bburke at redhat.com (Bill Burke) Date: Wed, 16 Aug 2017 10:29:37 -0400 Subject: [keycloak-dev] generic cli sso utility In-Reply-To: <6dd799d5-7a8a-0140-3e07-cc9baad1cfd1@redhat.com> References: <0cfaaecd-51ab-eacb-cba3-a536acd6c943@redhat.com> <3958ff9c-a987-51ad-1d8c-d115d4d99b7a@redhat.com> <6dd799d5-7a8a-0140-3e07-cc9baad1cfd1@redhat.com> Message-ID: <0eb1d237-79ce-ed97-4296-029cf430fe41@redhat.com> On 8/15/17 3:47 PM, John Dennis wrote: > On 08/15/2017 11:47 AM, Bill Burke wrote: >> Maybe its just a matter of doing an SSO login once and creating and >> storing an offline token? Could even protect the token by encrypting it >> with a local pin/pw. > > Why not use the platform keyring? > I think that is an option rather than a solution? We don't know if these CLIs will be running on Windows, OSX, Fedora, or RHEL. From bburke at redhat.com Wed Aug 16 14:53:50 2017 From: bburke at redhat.com (Bill Burke) Date: Wed, 16 Aug 2017 14:53:50 -0400 Subject: [keycloak-dev] Extending Keycloak with custom integrations In-Reply-To: References: Message-ID: <5ce3a0b8-2166-ea93-a40e-d447109421a3@redhat.com> FYI, this is a user list quest, so post to the keycloak-user list instead. But...you should be able to do those things through broker login flows, writing extensions for them, and using our theme architecture. On 8/16/17 5:30 AM, Rudresh Shashikant wrote: > Hi All, > > first time posting in the mailing list. I have a client that needs the > following: > + social integration for login > + after successful login, need to be able to extend keycloak to talk to a > backend API and get additional information about this user > + also need to use that additional information for an extra step involving > OTP (via SMS) > + end result of this additional workflow is to associate the social login > of the user with their internal Enterprise userId > > > +----------------------------------+ > | Assumption: Social login complete| > +----------------------------------+ > > User Keycloak Backend API SMS OTP > > <--------------------- > > ---------------------> > user code > > ----------------------> > <--------------------- > user mobile# > > --------------------------------------------------> > <---------------------------------------------------------------------- > > <-------------------------------------------------- > -------------------> > +---------------------+ > | if successful, link | > | user code to | > | social login | > +---------------------+ > > > > I will proceed to go through the codebase and documentation now but have > started by reaching out to the community first in case anyone can point me > in the correct direction. > > Thanks in advance. > > Regards, > Rudy. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Wed Aug 16 15:06:49 2017 From: bburke at redhat.com (Bill Burke) Date: Wed, 16 Aug 2017 15:06:49 -0400 Subject: [keycloak-dev] generic cli sso utility In-Reply-To: References: <0cfaaecd-51ab-eacb-cba3-a536acd6c943@redhat.com> <3958ff9c-a987-51ad-1d8c-d115d4d99b7a@redhat.com> Message-ID: <930d842a-8130-f513-c266-9c19c4ab5ced@redhat.com> On 8/16/17 7:58 AM, Stian Thorgersen wrote: > > > On 15 August 2017 at 17:47, Bill Burke > wrote: > > The end goal I want is that for CLI SSO, Keycloak is the SSO > mechanism that can do kerberos, client-cert, or whatever mechanism > the admin desires, and specific app CLI's only worry about > propagating bearer tokens. More comments inline: > > > On 8/15/17 2:46 AM, Stian Thorgersen wrote: > > I don't think leveraging a text-based browser is a good idea: > > * No-one has one installed and they suck big time. You > probably need Cygwin on Windows to get one as well > * Would require special themes to make anything that would be > remotely usable > * Not always usable on a remote shell. You need to do ssh (and > other things) with special commands to have an emulated > terminal rather than just a stream of characters > > As separate flow and/or extending direct grant to have some > sort of challenge/response would probably be better. > > Thinking about 3 different use-cases for the CLI: > > * Desktop - in this case the system browser is probably the > best option as there's then SSO between web and CLIs and > there's the best UI available > > I like KeycloakInstalled, but its still a bit quirky. Person has > to manually close the browser. KeycloakInstalled also probably > needs a themeable splash screen after authentication completes. > > > KeycloakInstalled is very rough/quirky. I did it many years ago and it > was kinda just a quick prototype more than anything. Its actually quite cool. Thomas Darimount turned me onto it while you were gone. The generic CLI utility I wrote is based on it. > > > > * Server/RSH - in this case wouldn't private/public keys be > the best option? SSH does this very well with RSA keys. We > could even just use the same keys as SSH by allowing users to > upload their public SSH key > > Maybe its just a matter of doing an SSO login once and creating > and storing an offline token? Could even protect the token by > encrypting it with a local pin/pw. > > > True an offline token is a nice way to do it, but how do you do the > login once if there's no UI available? You can do direct grant with > username/password, but what if there's OTP or some other even more > crazy auth mechanism in place for the web flow? Kinda where I think > there's going to be a need for a CLI flow and a web flow. I feel the same about the eventual need of a CLI flow. Bill From takashi.norimatsu.ws at hitachi.com Wed Aug 16 22:24:00 2017 From: takashi.norimatsu.ws at hitachi.com (=?utf-8?B?5LmX5p2+6ZqG5b+XIC8gTk9SSU1BVFNV77yMVEFLQVNISQ==?=) Date: Thu, 17 Aug 2017 02:24:00 +0000 Subject: [keycloak-dev] Proposal of using existing authentication and authorization server on behalf of keycloak browser-based authentication In-Reply-To: References: <831D472326678942A9B4BB933AAA103D68CA8DDB@GSjpTK1DCembx01.service.hitachi.net> <831D472326678942A9B4BB933AAA103D68CB9260@GSjpTK1DCembx02.service.hitachi.net> Message-ID: <831D472326678942A9B4BB933AAA103D68CB9AC5@GSjpTK1DCembx02.service.hitachi.net> We do NOT intend to propose a "custom"(customer specific) brokering protocol, are proposing a simplified brokering procedure for an external authentication server without implementing OIDC/SAML. This is useful for users who have their existing authentication server. They had to implement OIDC/SAML(very hard) or had to design and implement another procedure(is also not easy). By the proposal, they can integrate their authentication server easily. For example, UMA standard for authorization service is proposed, but seems to be complicated, so keycloak has simplified procedure(entitlement API). Feature is different but situation is the same (simplified OIDC/SAML). ---------- From: Stian Thorgersen [mailto:sthorger at redhat.com] Sent: Tuesday, August 15, 2017 4:49 PM To: ???? / NORIMATSU?TAKASHI Cc: keycloak-dev at lists.jboss.org Subject: [!]Re: Re: [keycloak-dev] Proposal of using existing authentication and authorization server on behalf of keycloak browser-based authentication Afraid I still don't understand what you are trying to contribute to Keycloak. As I said we already allow creating custom identity providers using whatever protocol you want. We can't accept contribution of a custom identity provider which is seems is what you are trying to contribute. On 15 August 2017 at 08:58, ???? / NORIMATSU?TAKASHI wrote: > I'm not really following what you are proposing to contribute to Keycloak. Thank you for comment. This contribution to keycloak is that to enhance competitiveness with proprietary products. In some market, customers have highly customized Web UI for authentication. (e.g. soft keyboard, responsive web design, very sophisticated look and feel). They want to use Authorization server product (such as keycloak) implementing OpenID Connect for securing the customer's API. They want to use existing highly customized authentication server, but do not want to implement OpenID Connect on this authentication server (too much complex and difficult to implement). To meet such needs, proprietary products have the following solution. Proprietary authorization server products have their own procedure (much simpler than OpenID Connect and SAMLv2) to communicate with existing authentication server as below: https://communities.ca.com/blogs/oauth/2016/10/04/howto-integrating-otk-with-external-login-server?et=notification.send https://www.ibm.com/support/knowledgecenter/en/SSMNED_5.0.0/com.ibm.apic.toolkit.doc/tapim_sec_api_config_scheme_oauth_endpoint.html In customer's existing authentication server, customers only have to implement communication with the authorization server according to the procedure prepared by the authorization server product (It is much easier than implementing OpenID Connect or SAMLv2). Customers do not have to implement anything in authorization server side. On the other hand, if keycloak is used, customers have to do following: a) In authorization server (RH SSO), simple procedure to communicate with external authentication server have to be designed and implemented using SPI. b) In customer's existing authentication server, implement procedure prepared by a). -> In proprietary products, a) is prepared, but keycloak is not. Our proposed patch is intended to complement a). --- From: Stian Thorgersen [mailto:sthorger at redhat.com] Sent: Monday, August 14, 2017 7:57 PM To: ???? / NORIMATSU?TAKASHI Cc: keycloak-dev at lists.jboss.org Subject: [!]Re: [keycloak-dev] Proposal of using existing authentication and authorization server on behalf of keycloak browser-based authentication I'm not really following what you are proposing to contribute to Keycloak. We already have the SPI that allows adding a custom provider if your IdP doesn't support SAML or OpenID Connect. On 31 July 2017 at 06:09, ???? / NORIMATSU?TAKASHI wrote: Hello. Previously, I had proposed the feature and its implementation of delegating authentication and authorization to an external existing server on behalf of keycloak's browser-based authentication mechanism, and had gotten advices that it is appropriate to use Identity Brokering for such the feature. I've re-implemented this feature again by Identity Brokering. The description and implementation of this feature is mentioned below. https://github.com/Hitachi/PoV-keycloak-delegate-authn-consent https://github.com/Hitachi/PoV-keycloak-delegate-authn-consent/tree/master/src/keycloak/examples/providers/delegate-authn-consent It can delegate not only authentication but authorization(consent). Kindly review it and provide us some comment and advices. We would like to contribute this feature onto keycloak. Best Regards Takashi Norimatsu Hitachi, Ltd. --- From: Stian Thorgersen [mailto:sthorger at redhat.com] Sent: Thursday, June 29, 2017 6:23 PM To: ???? / NORIMATSU?TAKASHI Cc: keycloak-dev at lists.jboss.org Subject: [!]Re: [keycloak-dev] Proposal of using existing authentication server on behalf of keycloak browser-based authentication There's an SPI to implement your own custom identity brokering provider [1]. [1]?https://github.com/keycloak/keycloak/blob/master/server-spi-private/src/main/java/org/keycloak/broker/provider/IdentityProvider.java On 29 June 2017 at 10:51, ???? / NORIMATSU?TAKASHI wrote: I need to use the authentication server without OIDC/OAuth2/SAMLv2 implementation as an external IdP, in order to integrate existing authentication system. (some commercial products supports such the case) I consulted identity broker's section in keycloak's manual below and found that if I use this feature the external IdP must support OIDC or SAMLv2. https://keycloak.gitbooks.io/documentation/server_admin/topics/identity-broker.html Therefore, I realized it by using redirect based authentication flows. Can identity Brokering can support such the case? Aside from this, I'd like to contribute it to Community extensions and examples. Best Regards Takashi Norimatsu Hitachi, Ltd. --- From: Stian Thorgersen [mailto:sthorger at redhat.com] Sent: Tuesday, June 27, 2017 5:52 PM To: ???? / NORIMATSU?TAKASHI Cc: keycloak-dev at lists.jboss.org Subject: [!]Re: [keycloak-dev] Proposal of using existing authentication server on behalf of keycloak browser-based authentication I'm not in favour of adding this. If it's using redirect based authentication flows it should be done through identity brokering, not authentication flows. It's also a very complex example that we don't want to maintain. We've also in the process of moving all examples away from the main Keycloak repository into a separate quickstart repository. On 27 June 2017 at 08:54, ???? / NORIMATSU?TAKASHI wrote: Hello. Previously, I had proposed the feature of delegating authentication to an external authentication server on behalf of keycloak's browser-based authentication mechanism. I've integrated this feature to keycloak's "examples" packages and send PR (https://github.com/keycloak/keycloak/pull/4260). Hope this PR is reviewed and merged as an example for combining some providers to customize keycloak. Detailed description of this feature is mentioned below. https://github.com/Hitachi/PoV-keycloak-authentication-delegation I am now engaging in integrating this feature to keycloak as product-base default providers, but encounter technical problems about writing arquillian. Would someone tell me how to resolve this problem? [Problem] - I could not find how to run an external authentication server(application running on wildfly 10) during each arquillian test cases. After resolving this problem and writing and running arquillian test cases, I'll send PR for this feature as product-base default providers. Best Regards Takashi Norimatsu Hitachi, Ltd. _______________________________________________ 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 Thu Aug 17 00:46:17 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 17 Aug 2017 06:46:17 +0200 Subject: [keycloak-dev] Remove realm json at "/auth/realms/" In-Reply-To: <9c42e9ba-93cc-660d-103a-cb9cd28c46ca@redhat.com> References: <9c42e9ba-93cc-660d-103a-cb9cd28c46ca@redhat.com> Message-ID: On 16 August 2017 at 15:40, Alexey Kazakov wrote: > > On 08/15/2017 05:00 AM, Stian Thorgersen wrote: > > I propose we remove the realm json returned at "/auth/realms/ name>" > > and just return an empty page > > > > * It can end-up being visible to end-users - we should rather have a > realm > > welcome page / SSO landing page here > What is wrong with exposing this json to users? > Nothing much really. There's no details there that are sensitive nor can't easily be found out regardless. It doesn't look good if a end-user happens to go to this URL though and is shown some JSON file rather than a HTML page. > > > * It's not used by anything AFAIK > > I'm not sure if this endpoint is documented but it can be used by > users/clients. For example we use this endpoint to fetch the public key > of the realm in openshift.io plus for simple health check. Should > something else be used instead? > For public keys use: /auth/realms//.well-known/openid-configuration That's what our adapters use and it's a OIDC standard endpoint > > > * From time to time people complain about it ( > > https://issues.jboss.org/browse/KEYCLOAK-5279 for instance, there's more > > similar issues reported) > It seems that I don't have access to this issue. What kind of problems > this endpoint can cause? > Folks claim it's a security issue. I disagree with that, but it comes up from time to time. > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Thu Aug 17 00:48:08 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 17 Aug 2017 06:48:08 +0200 Subject: [keycloak-dev] Remove realm json at "/auth/realms/" In-Reply-To: References: Message-ID: On 16 August 2017 at 12:12, John D. Ament wrote: > KEYCLOAK-5279 isn't asking to split it out. We're dealing with the access > at a network level, making it so that certain URIs aren't accessible. But > the ability to hide the fact that it may need to exist is important. > > I think the more relevant ticket is KEYCLOAK-5277, where at least in a > multitenant fashion the fact that a realm may exist is considered sensitive > information. The fact that there's a public API that returns 200/404 if a > realm exists is considered a problem, so having it removed would alleviate > any concerns in that area. > Firstly, I disagree that exposing if a realm name is a valid realm or not is not a particular big risk. Folks can find valid realm names just by logging in to your apps. Secondly, there's no way to stop someone from being able to detect if a realm name is valid or not. Pretty much every endpoint the server has can tell you that. I assume you're not seriously expecting us to provide some sort of fake realm where there is none? > > On Tue, Aug 15, 2017 at 1:19 PM Bill Burke wrote: > > > The idea of that URL is to expose public information about the realm, > > i.e. public cert/key and public endpoint urls. If this information is > > not being used and we have other mechanisms in place, then yeah, remove > it. > > > > IMO, the jira you reference is unrelated. Its about shutting down the > > admin console/API. As far as that goes, it would be cool to split up > > keycloak into separate subsystems: > > > > * backend (required) > > * admin api/console > > * account service > > * authentication/brokering/token endpoints > > > > Even have the admin api/console be exposed from a different bind > > address/port. > > > > On 8/15/17 8:00 AM, Stian Thorgersen wrote: > > > I propose we remove the realm json returned at "/auth/realms/ > name>" > > > and just return an empty page > > > > > > * It can end-up being visible to end-users - we should rather have a > > realm > > > welcome page / SSO landing page here > > > * It's not used by anything AFAIK > > > * From time to time people complain about it ( > > > https://issues.jboss.org/browse/KEYCLOAK-5279 for instance, there's > more > > > similar issues reported) > > > _______________________________________________ > > > 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 Thu Aug 17 00:53:56 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 17 Aug 2017 06:53:56 +0200 Subject: [keycloak-dev] Proposal of using existing authentication and authorization server on behalf of keycloak browser-based authentication In-Reply-To: <831D472326678942A9B4BB933AAA103D68CA8DDB@GSjpTK1DCembx01.service.hitachi.net> References: <831D472326678942A9B4BB933AAA103D68CA8DDB@GSjpTK1DCembx01.service.hitachi.net> Message-ID: So rather than using standard protocols (OIDC or SAML) you've come up with your own custom protocol that folks would have to implement instead? On 31 July 2017 at 06:09, ???? / NORIMATSU?TAKASHI < takashi.norimatsu.ws at hitachi.com> wrote: > Hello. > > Previously, I had proposed the feature and its implementation of > delegating authentication and authorization to an external existing server > on behalf of keycloak's browser-based authentication mechanism, and had > gotten advices that it is appropriate to use Identity Brokering for such > the feature. > > I've re-implemented this feature again by Identity Brokering. The > description and implementation of this feature is mentioned below. > https://github.com/Hitachi/PoV-keycloak-delegate-authn-consent > https://github.com/Hitachi/PoV-keycloak-delegate-authn- > consent/tree/master/src/keycloak/examples/providers/delegate-authn-consent > It can delegate not only authentication but authorization(consent). > > Kindly review it and provide us some comment and advices. > We would like to contribute this feature onto keycloak. > > Best Regards > Takashi Norimatsu > Hitachi, Ltd. > > --- > From: Stian Thorgersen [mailto:sthorger at redhat.com] > Sent: Thursday, June 29, 2017 6:23 PM > To: ???? / NORIMATSU?TAKASHI > Cc: keycloak-dev at lists.jboss.org > Subject: [!]Re: [keycloak-dev] Proposal of using existing authentication > server on behalf of keycloak browser-based authentication > > There's an SPI to implement your own custom identity brokering provider > [1]. > > [1] https://github.com/keycloak/keycloak/blob/master/ > server-spi-private/src/main/java/org/keycloak/broker/ > provider/IdentityProvider.java > > On 29 June 2017 at 10:51, ???? / NORIMATSU?TAKASHI < > takashi.norimatsu.ws at hitachi.com> wrote: > I need to use the authentication server without OIDC/OAuth2/SAMLv2 > implementation as an external IdP, > in order to integrate existing authentication system. > (some commercial products supports such the case) > > I consulted identity broker's section in keycloak's manual below and found > that if I use this feature the external IdP must support OIDC or SAMLv2. > https://keycloak.gitbooks.io/documentation/server_admin/ > topics/identity-broker.html > > Therefore, I realized it by using redirect based authentication flows. > > Can identity Brokering can support such the case? > > Aside from this, I'd like to contribute it to Community extensions and > examples. > > Best Regards > Takashi Norimatsu > Hitachi, Ltd. > > --- > From: Stian Thorgersen [mailto:sthorger at redhat.com] > Sent: Tuesday, June 27, 2017 5:52 PM > To: ???? / NORIMATSU?TAKASHI > Cc: keycloak-dev at lists.jboss.org > Subject: [!]Re: [keycloak-dev] Proposal of using existing authentication > server on behalf of keycloak browser-based authentication > > I'm not in favour of adding this. If it's using redirect based > authentication flows it should be done through identity brokering, not > authentication flows. It's also a very complex example that we don't want > to maintain. We've also in the process of moving all examples away from the > main Keycloak repository into a separate quickstart repository. > > On 27 June 2017 at 08:54, ???? / NORIMATSU?TAKASHI < > takashi.norimatsu.ws at hitachi.com> wrote: > Hello. > > Previously, I had proposed the feature of delegating authentication to an > external authentication server on behalf of keycloak's browser-based > authentication mechanism. > > I've integrated this feature to keycloak's "examples" packages and send PR > (https://github.com/keycloak/keycloak/pull/4260). > Hope this PR is reviewed and merged as an example for combining some > providers to customize keycloak. > > Detailed description of this feature is mentioned below. > https://github.com/Hitachi/PoV-keycloak-authentication-delegation > > I am now engaging in integrating this feature to keycloak as product-base > default providers, but encounter technical problems about writing > arquillian. Would someone tell me how to resolve this problem? > > [Problem] > - I could not find how to run an external authentication > server(application running on wildfly 10) during each arquillian test cases. > > After resolving this problem and writing and running arquillian test > cases, I'll send PR for this feature as product-base default providers. > > Best Regards > Takashi Norimatsu > Hitachi, Ltd. > > _______________________________________________ > 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 Thu Aug 17 00:57:49 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 17 Aug 2017 06:57:49 +0200 Subject: [keycloak-dev] token exchange In-Reply-To: References: <71449542-5454-44e4-936b-2099e366d8b5@redhat.com> <49f60419-0d5b-9f0b-ec58-7c06eb513570@redhat.com> <64994417-43b0-95d3-5de9-c0d78a226d79@redhat.com> <9b6efb46-944c-213b-848e-4e82d922da6f@redhat.com> Message-ID: True ID token is not the right thing to use. What about a special session token that can be used together with direct grant to allow SSO in direct grant: * First time you call direct grant it returns a session token - could add a special query param to request this * Once you have a session token (this is the equivalent of the identity cookie for the web flows) you can obtain a tokens through direct grant and it'll always be linked to the same user session On 15 August 2017 at 17:32, Bill Burke wrote: > I would be worried about the security implications of allowing an ID token > as a way to obtain access. If you have even one client in the domain that > is not fully trusted then you are toast. So how is it set up to make > things easy? One "master" client is defined in realm. That client is > given permission to obtain exchange for anything. That client is marked as > confidential. Generic CLI tool is configured with client id and secret of > "master" client. > On 8/15/17 2:50 AM, Stian Thorgersen wrote: > > First of all I'm not arguing against token exchange service. It's a very > useful thing IMO and I can see loads of use-cases for it. I'm just > wondering about how usable it will be for the CLI tool and I'm worried > about how complicated it would be to setup. If the ID token was signed that > could serve as a the "identity cookie" for a CLI SSO session (if ID token > is not suitable we could introduce some sort of identity token that can be > used by direct grant to allow SSO sessions). Using direct grant you can > then easily obtain a token for a specific client by just passing a valid > "identity cookie" same way as the web browser does. Is that not simpler to > setup and use? > > On 14 August 2017 at 15:42, Bill Burke wrote: > >> CLI tool I wrote doesn't allow token exchange, yet, but you're correct, >> I'm thinking of using it to perform token exchange. >> >> Our ID tokens are not signed right now. Also you still need client to >> client exchange so that you can "downgrade" a token to talk to an untrusted >> service. I've also added new fine-grain permissions "exchange-from" and >> "exchange-to". >> >> For example, lets say Client A gets token and invokes on service B which >> needs to invoke on untrusted service C. >> >> 1. Service B asks to exchange the token created for A to talk to C >> 2. Token exchange endpoint looks at issuer, its A, so it sees if service >> B has permission to "exchange-from" tokens created for A >> 3. Token exchange then sees if B has permission to "exchange-to" B. >> >> FYI, I'm also expanding this so that you can exchange an access token for >> a social provider token. Automatic refreshes and everything if the >> provider supports it. Gonna change how client initiated linking works too >> so that instead of doing the silly hash algorithm required by the call, >> clients would call the exchange first, get an error response like "not >> linked" that contained a browser URL that the client can use to create the >> link. >> >> Also no reason I couldn't do the same for exchange an external token to a >> internal one. Would work the same as our IDP, import the user, etc. >> >> >> On 8/14/17 7:06 AM, Stian Thorgersen wrote: >> >> I'm assuming the basic token exchange service comes from the way the CLI >> tool works? I.e. you login to the tool then it allows exchanging the token >> for a particular CLI client? >> >> Would it not be better to obtain an ID token and use direct grant to >> obtain a token for the client using the ID token as the authentication >> mechanism? >> >> On 1 August 2017 at 19:10, Pedro Igor Silva wrote: >> >>> On Mon, Jul 31, 2017 at 1:54 PM, Bill Burke wrote: >>> >>> > >>> > >>> > On 7/31/17 12:18 PM, Bill Burke wrote: >>> > >>> > >>> > >>> > On 7/31/17 11:35 AM, Pedro Igor Silva wrote: >>> > >>> > On Fri, Jul 28, 2017 at 5:24 PM, Bill Burke wrote: >>> > >>> >> I've implemented a simple token exchange API [1] that allows you to >>> >> exchange an access token created for one client to another client. >>> The >>> >> REST API follows the oauth token exchange api [2] very loosely. >>> >> >>> >> subject_token: a keycloak access token >>> >> >>> >> audience: takes a client id >>> >> >>> >> It then converts the access token created for one client and converts >>> it >>> >> to another. It lives under the token endpoint. >>> >> >>> >> The security model is as follows: >>> >> >>> >> * Authenticate calling client the same way as password grant. >>> >> >>> >> * The calling client must have service account enabled >>> >> >>> >> * Service account must have a realm role "token-exchanger" grant edto >>> it >>> >> or, it must have a client role "token-exchanger" granted to it. This >>> >> exchanger client role is a role defined by the target client you are >>> >> exchanging the token to. >>> >> >>> >> >>> >> Is this a good security model? I'm thinking of not creating these >>> roles >>> >> right now and to enable support for exchange would require defining >>> the >>> >> roles specified above. >>> >> >>> > >>> > I think roles are too coarse-grained to represent this kind of policy. >>> A >>> > better option would be to explicitly define the clients that are >>> allowed to >>> > exchange tokens for a particular resource server. Eg.: >>> > >>> > RS A allows Client B, C and D to exchange their tokens where the target >>> > audience is RS A (or if using "resource", a specific resource in RS A). >>> > >>> > >>> > I changed it a little. actors are: >>> > >>> > * Authenticated client asking for change >>> > * Clients that are the audience of the token being exchanged >>> > * Client you want the token to be exchanged to >>> > >>> > So, the authenticated client must be in the audience of the token being >>> > exchanged, or, have permission to exchange from that particular >>> audience. >>> > The authenticated client also must have permission to exchange to the >>> > audience it wants to exchange to. >>> > >>> > Good idea to change it to use the fine grain admin permissions. >>> There's a >>> > couple of issues/problems with doing this that I think are easily done: >>> > >>> > * public clients can't have service accounts. >>> > * Client Policy looks at kc_client_id attribute which is pulled from >>> the >>> > issuedFor claim in the token. This isn't correct as we permission >>> checks >>> > based on the authenticated client, not the token. >>> > >>> > So I'll have to create a new Identity type that either wraps the >>> service >>> > account or ClientModel and sets the "kc_client_id" property. >>> > >>> >>> Our policy evaluation engine is based on the claims within the token. The >>> "issueFor" is basically the "azp" claim from OIDC. In fact, we don't even >>> need that "kc_client_id". We could make this configurable though, and let >>> users decide whether they want to check the "authenticated client" or >>> "azp" >>> ? >>> >>> Btw, I'm about to finish UMA Grant Type, one of the changes I'm doing for >>> UMA 2.0. My changes will conflict with yours. Are you going to merge your >>> changes soon ? >>> >>> Another thing I noticed is that maybe we could have a SPI for custom >>> grant >>> types. What you did and what I'm doing may justify a specific SPI for >>> plugging custom grant types. Maybe too much, but maybe a nice to have. >>> >>> >>> > >>> > >>> > Bill >>> > >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> >> > > From sthorger at redhat.com Thu Aug 17 01:00:34 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 17 Aug 2017 07:00:34 +0200 Subject: [keycloak-dev] token exchange In-Reply-To: <661fb731-034b-8675-1eeb-699626d16462@redhat.com> References: <71449542-5454-44e4-936b-2099e366d8b5@redhat.com> <49f60419-0d5b-9f0b-ec58-7c06eb513570@redhat.com> <64994417-43b0-95d3-5de9-c0d78a226d79@redhat.com> <9b6efb46-944c-213b-848e-4e82d922da6f@redhat.com> <661fb731-034b-8675-1eeb-699626d16462@redhat.com> Message-ID: That's not how I interpret the spec. https://tools.ietf.org/html/rfc7519#section-4.1.3 states: *"The "aud" (audience) claim identifies the recipients that the JWT is* * intended for. Each principal intended to process the JWT MUST* * identify itself with a value in the audience claim. If the principal* * processing the claim does not identify itself with a value in the* * "aud" claim when this claim is present, then the JWT MUST be* * rejected. In the general case, the "aud" value is an array of case-* * sensitive strings, each containing a StringOrURI value. In the* * special case when the JWT has one audience, the "aud" value MAY be a* * single case-sensitive string containing a StringOrURI value. The* * interpretation of audience values is generally application specific.* * Use of this claim is OPTIONAL."* >From that I read that all services that is invoked with a token should be listed in the aud claim. On 15 August 2017 at 17:51, Bill Burke wrote: > I don't agree with the JIRA. See my previous email: > > aud" is who the token is created for. i.e. the audience defines how the > token is formatted: role mappings, claims, etc. > "azp" is who the token is issued for. In an exchange situation like above > "aud" would be Service C, but the "azp" claim would be "B". At least, > that's how I have it implemented right now. > > On 8/15/17 9:44 AM, Stian Thorgersen wrote: > > 'aud' is broken: > https://issues.jboss.org/browse/KEYCLOAK-1201 > > Big question is how do you control what the list of "clients" in the aud > should be? Manually? Based on scope (what about full scope and loads of > clients, what about when there are no client roles)? > > On 15 August 2017 at 14:41, Pedro Igor Silva wrote: > >> >> On Mon, Aug 14, 2017 at 10:42 AM, Bill Burke wrote: >> >>> CLI tool I wrote doesn't allow token exchange, yet, but you're correct, >>> I'm thinking of using it to perform token exchange. >>> >>> Our ID tokens are not signed right now. Also you still need client to >>> client exchange so that you can "downgrade" a token to talk to an untrusted >>> service. I've also added new fine-grain permissions "exchange-from" and >>> "exchange-to". >>> >>> For example, lets say Client A gets token and invokes on service B which >>> needs to invoke on untrusted service C. >>> >> >> When Client A gets token to invoke Service B, how the "aud" claim in the >> token looks like for you ? Is it referencing Service B ? >> >> Asking because I noticed that our access tokens are being issued using >> the authenticated client in "aud" claim where it should contain (or in >> addition to other audiences) the target service. A typical scenario for >> bearer token authentication. Also, our BearerTokenRequestAuthenticator >> does not seem to validate audience. >> >> Considering the flow you described, Client A would need a token with >> Service B as a valid audience in order to be able to start the flow. >> > > > From sthorger at redhat.com Thu Aug 17 01:05:38 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 17 Aug 2017 07:05:38 +0200 Subject: [keycloak-dev] token exchange In-Reply-To: References: <71449542-5454-44e4-936b-2099e366d8b5@redhat.com> <49f60419-0d5b-9f0b-ec58-7c06eb513570@redhat.com> <64994417-43b0-95d3-5de9-c0d78a226d79@redhat.com> <9b6efb46-944c-213b-848e-4e82d922da6f@redhat.com> Message-ID: Actually, Bill has convinced me that ID token shouldn't be used for authentication. If anything a special token only available in direct grant should be used. The problem with ID token is that it's sent to the clients themselves which would effectively give all clients full access to a users account: * User logs in to app 1 through web flows * App 1 gets an access token with limited roles, but also an ID token that could be used for authentication * App 1 uses the ID token to "authenticate" itself as the user to App 2 and can now obtain an access token with more privileges then it should So using ID token to authenticate a user is a completely broken concept. On 15 August 2017 at 19:51, Pedro Igor Silva wrote: > We have discussed this before (I think because of Kubernetes), I don't see > issues about using the IDToken as a bearer for "authentication". Of course, > as long as you enforce validations that check if token can be trusted. > > In fact, I was about to start a discussion around IDToken and signature. > In UMA 2.0 you can use different claim token formats to obtain a token > (RPT) from the token endpoint. There is a specific grant type for that. One > of the main changes we had in the specs. > > A common format is "http://openid.net/specs/openid-connect-core-1_0.html# > HybridIDToken", which is about using an IDToken. > > On Tue, Aug 15, 2017 at 12:32 PM, Bill Burke wrote: > >> I would be worried about the security implications of allowing an ID >> token as a way to obtain access. If you have even one client in the domain >> that is not fully trusted then you are toast. So how is it set up to make >> things easy? One "master" client is defined in realm. That client is >> given permission to obtain exchange for anything. That client is marked as >> confidential. Generic CLI tool is configured with client id and secret of >> "master" client. >> On 8/15/17 2:50 AM, Stian Thorgersen wrote: >> >> First of all I'm not arguing against token exchange service. It's a very >> useful thing IMO and I can see loads of use-cases for it. I'm just >> wondering about how usable it will be for the CLI tool and I'm worried >> about how complicated it would be to setup. If the ID token was signed that >> could serve as a the "identity cookie" for a CLI SSO session (if ID token >> is not suitable we could introduce some sort of identity token that can be >> used by direct grant to allow SSO sessions). Using direct grant you can >> then easily obtain a token for a specific client by just passing a valid >> "identity cookie" same way as the web browser does. Is that not simpler to >> setup and use? >> >> On 14 August 2017 at 15:42, Bill Burke wrote: >> >>> CLI tool I wrote doesn't allow token exchange, yet, but you're correct, >>> I'm thinking of using it to perform token exchange. >>> >>> Our ID tokens are not signed right now. Also you still need client to >>> client exchange so that you can "downgrade" a token to talk to an untrusted >>> service. I've also added new fine-grain permissions "exchange-from" and >>> "exchange-to". >>> >>> For example, lets say Client A gets token and invokes on service B which >>> needs to invoke on untrusted service C. >>> >>> 1. Service B asks to exchange the token created for A to talk to C >>> 2. Token exchange endpoint looks at issuer, its A, so it sees if service >>> B has permission to "exchange-from" tokens created for A >>> 3. Token exchange then sees if B has permission to "exchange-to" B. >>> >>> FYI, I'm also expanding this so that you can exchange an access token >>> for a social provider token. Automatic refreshes and everything if the >>> provider supports it. Gonna change how client initiated linking works too >>> so that instead of doing the silly hash algorithm required by the call, >>> clients would call the exchange first, get an error response like "not >>> linked" that contained a browser URL that the client can use to create the >>> link. >>> >>> Also no reason I couldn't do the same for exchange an external token to >>> a internal one. Would work the same as our IDP, import the user, etc. >>> >>> >>> On 8/14/17 7:06 AM, Stian Thorgersen wrote: >>> >>> I'm assuming the basic token exchange service comes from the way the CLI >>> tool works? I.e. you login to the tool then it allows exchanging the token >>> for a particular CLI client? >>> >>> Would it not be better to obtain an ID token and use direct grant to >>> obtain a token for the client using the ID token as the authentication >>> mechanism? >>> >>> On 1 August 2017 at 19:10, Pedro Igor Silva wrote: >>> >>>> On Mon, Jul 31, 2017 at 1:54 PM, Bill Burke wrote: >>>> >>>> > >>>> > >>>> > On 7/31/17 12:18 PM, Bill Burke wrote: >>>> > >>>> > >>>> > >>>> > On 7/31/17 11:35 AM, Pedro Igor Silva wrote: >>>> > >>>> > On Fri, Jul 28, 2017 at 5:24 PM, Bill Burke >>>> wrote: >>>> > >>>> >> I've implemented a simple token exchange API [1] that allows you to >>>> >> exchange an access token created for one client to another client. >>>> The >>>> >> REST API follows the oauth token exchange api [2] very loosely. >>>> >> >>>> >> subject_token: a keycloak access token >>>> >> >>>> >> audience: takes a client id >>>> >> >>>> >> It then converts the access token created for one client and >>>> converts it >>>> >> to another. It lives under the token endpoint. >>>> >> >>>> >> The security model is as follows: >>>> >> >>>> >> * Authenticate calling client the same way as password grant. >>>> >> >>>> >> * The calling client must have service account enabled >>>> >> >>>> >> * Service account must have a realm role "token-exchanger" grant >>>> edto it >>>> >> or, it must have a client role "token-exchanger" granted to it. This >>>> >> exchanger client role is a role defined by the target client you are >>>> >> exchanging the token to. >>>> >> >>>> >> >>>> >> Is this a good security model? I'm thinking of not creating these >>>> roles >>>> >> right now and to enable support for exchange would require defining >>>> the >>>> >> roles specified above. >>>> >> >>>> > >>>> > I think roles are too coarse-grained to represent this kind of >>>> policy. A >>>> > better option would be to explicitly define the clients that are >>>> allowed to >>>> > exchange tokens for a particular resource server. Eg.: >>>> > >>>> > RS A allows Client B, C and D to exchange their tokens where the >>>> target >>>> > audience is RS A (or if using "resource", a specific resource in RS >>>> A). >>>> > >>>> > >>>> > I changed it a little. actors are: >>>> > >>>> > * Authenticated client asking for change >>>> > * Clients that are the audience of the token being exchanged >>>> > * Client you want the token to be exchanged to >>>> > >>>> > So, the authenticated client must be in the audience of the token >>>> being >>>> > exchanged, or, have permission to exchange from that particular >>>> audience. >>>> > The authenticated client also must have permission to exchange to the >>>> > audience it wants to exchange to. >>>> > >>>> > Good idea to change it to use the fine grain admin permissions. >>>> There's a >>>> > couple of issues/problems with doing this that I think are easily >>>> done: >>>> > >>>> > * public clients can't have service accounts. >>>> > * Client Policy looks at kc_client_id attribute which is pulled from >>>> the >>>> > issuedFor claim in the token. This isn't correct as we permission >>>> checks >>>> > based on the authenticated client, not the token. >>>> > >>>> > So I'll have to create a new Identity type that either wraps the >>>> service >>>> > account or ClientModel and sets the "kc_client_id" property. >>>> > >>>> >>>> Our policy evaluation engine is based on the claims within the token. >>>> The >>>> "issueFor" is basically the "azp" claim from OIDC. In fact, we don't >>>> even >>>> need that "kc_client_id". We could make this configurable though, and >>>> let >>>> users decide whether they want to check the "authenticated client" or >>>> "azp" >>>> ? >>>> >>>> Btw, I'm about to finish UMA Grant Type, one of the changes I'm doing >>>> for >>>> UMA 2.0. My changes will conflict with yours. Are you going to merge >>>> your >>>> changes soon ? >>>> >>>> Another thing I noticed is that maybe we could have a SPI for custom >>>> grant >>>> types. What you did and what I'm doing may justify a specific SPI for >>>> plugging custom grant types. Maybe too much, but maybe a nice to have. >>>> >>>> >>>> > >>>> > >>>> > Bill >>>> > >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >>> >>> >> >> > From takashi.norimatsu.ws at hitachi.com Thu Aug 17 02:47:55 2017 From: takashi.norimatsu.ws at hitachi.com (=?utf-8?B?5LmX5p2+6ZqG5b+XIC8gTk9SSU1BVFNV77yMVEFLQVNISQ==?=) Date: Thu, 17 Aug 2017 06:47:55 +0000 Subject: [keycloak-dev] Proposal of using existing authentication and authorization server on behalf of keycloak browser-based authentication In-Reply-To: <831D472326678942A9B4BB933AAA103D68CB9AC0@GSjpTK1DCembx02.service.hitachi.net> References: <831D472326678942A9B4BB933AAA103D68CA8DDB@GSjpTK1DCembx01.service.hitachi.net> <831D472326678942A9B4BB933AAA103D68CB9260@GSjpTK1DCembx02.service.hitachi.net> <831D472326678942A9B4BB933AAA103D68CB9AC0@GSjpTK1DCembx02.service.hitachi.net> Message-ID: <831D472326678942A9B4BB933AAA103D68CB9B5D@GSjpTK1DCembx02.service.hitachi.net> Hello. >So rather than using standard protocols (OIDC or SAML) you've come up with your own custom protocol that folks would have to implement instead? Yes, but much easier for people than using OIDC/SAML. If OIDC is used for the existing authentication server, following OIDC OP functions would have to be implemented. - Authz Code Flow (at least) - Authz Code management - ID Token/Access Token management - JWT - JWS - key management for JWT Instead, if supporting the simplified protocol such the one I have proposed, only following would have to be implemented - Issue temporal opaque ticket - Send authenticated user info in return to this ticket Regards Takashi Norimatsu -----Original Message----- From: ???? / NORIMATSU?TAKASHI Sent: Thursday, August 17, 2017 11:24 AM To: 'stian at redhat.com' Cc: 'keycloak-dev at lists.jboss.org' Subject: RE: [!]Re: Re: [keycloak-dev] Proposal of using existing authentication and authorization server on behalf of keycloak browser-based authentication We do NOT intend to propose a "custom"(customer specific) brokering protocol, are proposing a simplified brokering procedure for an external authentication server without implementing OIDC/SAML. This is useful for users who have their existing authentication server. They had to implement OIDC/SAML(very hard) or had to design and implement another procedure(is also not easy). By the proposal, they can integrate their authentication server easily. For example, UMA standard for authorization service is proposed, but seems to be complicated, so keycloak has simplified procedure(entitlement API). Feature is different but situation is the same (simplified OIDC/SAML). ---------- From: Stian Thorgersen [mailto:sthorger at redhat.com] Sent: Tuesday, August 15, 2017 4:49 PM To: ???? / NORIMATSU?TAKASHI Cc: keycloak-dev at lists.jboss.org Subject: [!]Re: Re: [keycloak-dev] Proposal of using existing authentication and authorization server on behalf of keycloak browser-based authentication Afraid I still don't understand what you are trying to contribute to Keycloak. As I said we already allow creating custom identity providers using whatever protocol you want. We can't accept contribution of a custom identity provider which is seems is what you are trying to contribute. On 15 August 2017 at 08:58, ???? / NORIMATSU?TAKASHI wrote: > I'm not really following what you are proposing to contribute to Keycloak. Thank you for comment. This contribution to keycloak is that to enhance competitiveness with proprietary products. In some market, customers have highly customized Web UI for authentication. (e.g. soft keyboard, responsive web design, very sophisticated look and feel). They want to use Authorization server product (such as keycloak) implementing OpenID Connect for securing the customer's API. They want to use existing highly customized authentication server, but do not want to implement OpenID Connect on this authentication server (too much complex and difficult to implement). To meet such needs, proprietary products have the following solution. Proprietary authorization server products have their own procedure (much simpler than OpenID Connect and SAMLv2) to communicate with existing authentication server as below: https://communities.ca.com/blogs/oauth/2016/10/04/howto-integrating-otk-with-external-login-server?et=notification.send https://www.ibm.com/support/knowledgecenter/en/SSMNED_5.0.0/com.ibm.apic.toolkit.doc/tapim_sec_api_config_scheme_oauth_endpoint.html In customer's existing authentication server, customers only have to implement communication with the authorization server according to the procedure prepared by the authorization server product (It is much easier than implementing OpenID Connect or SAMLv2). Customers do not have to implement anything in authorization server side. On the other hand, if keycloak is used, customers have to do following: a) In authorization server (RH SSO), simple procedure to communicate with external authentication server have to be designed and implemented using SPI. b) In customer's existing authentication server, implement procedure prepared by a). -> In proprietary products, a) is prepared, but keycloak is not. Our proposed patch is intended to complement a). --- From: Stian Thorgersen [mailto:sthorger at redhat.com] Sent: Monday, August 14, 2017 7:57 PM To: ???? / NORIMATSU?TAKASHI Cc: keycloak-dev at lists.jboss.org Subject: [!]Re: [keycloak-dev] Proposal of using existing authentication and authorization server on behalf of keycloak browser-based authentication I'm not really following what you are proposing to contribute to Keycloak. We already have the SPI that allows adding a custom provider if your IdP doesn't support SAML or OpenID Connect. On 31 July 2017 at 06:09, ???? / NORIMATSU?TAKASHI wrote: Hello. Previously, I had proposed the feature and its implementation of delegating authentication and authorization to an external existing server on behalf of keycloak's browser-based authentication mechanism, and had gotten advices that it is appropriate to use Identity Brokering for such the feature. I've re-implemented this feature again by Identity Brokering. The description and implementation of this feature is mentioned below. https://github.com/Hitachi/PoV-keycloak-delegate-authn-consent https://github.com/Hitachi/PoV-keycloak-delegate-authn-consent/tree/master/src/keycloak/examples/providers/delegate-authn-consent It can delegate not only authentication but authorization(consent). Kindly review it and provide us some comment and advices. We would like to contribute this feature onto keycloak. Best Regards Takashi Norimatsu Hitachi, Ltd. --- From: Stian Thorgersen [mailto:sthorger at redhat.com] Sent: Thursday, June 29, 2017 6:23 PM To: ???? / NORIMATSU?TAKASHI Cc: keycloak-dev at lists.jboss.org Subject: [!]Re: [keycloak-dev] Proposal of using existing authentication server on behalf of keycloak browser-based authentication There's an SPI to implement your own custom identity brokering provider [1]. [1]?https://github.com/keycloak/keycloak/blob/master/server-spi-private/src/main/java/org/keycloak/broker/provider/IdentityProvider.java On 29 June 2017 at 10:51, ???? / NORIMATSU?TAKASHI wrote: I need to use the authentication server without OIDC/OAuth2/SAMLv2 implementation as an external IdP, in order to integrate existing authentication system. (some commercial products supports such the case) I consulted identity broker's section in keycloak's manual below and found that if I use this feature the external IdP must support OIDC or SAMLv2. https://keycloak.gitbooks.io/documentation/server_admin/topics/identity-broker.html Therefore, I realized it by using redirect based authentication flows. Can identity Brokering can support such the case? Aside from this, I'd like to contribute it to Community extensions and examples. Best Regards Takashi Norimatsu Hitachi, Ltd. --- From: Stian Thorgersen [mailto:sthorger at redhat.com] Sent: Tuesday, June 27, 2017 5:52 PM To: ???? / NORIMATSU?TAKASHI Cc: keycloak-dev at lists.jboss.org Subject: [!]Re: [keycloak-dev] Proposal of using existing authentication server on behalf of keycloak browser-based authentication I'm not in favour of adding this. If it's using redirect based authentication flows it should be done through identity brokering, not authentication flows. It's also a very complex example that we don't want to maintain. We've also in the process of moving all examples away from the main Keycloak repository into a separate quickstart repository. On 27 June 2017 at 08:54, ???? / NORIMATSU?TAKASHI wrote: Hello. Previously, I had proposed the feature of delegating authentication to an external authentication server on behalf of keycloak's browser-based authentication mechanism. I've integrated this feature to keycloak's "examples" packages and send PR (https://github.com/keycloak/keycloak/pull/4260). Hope this PR is reviewed and merged as an example for combining some providers to customize keycloak. Detailed description of this feature is mentioned below. https://github.com/Hitachi/PoV-keycloak-authentication-delegation I am now engaging in integrating this feature to keycloak as product-base default providers, but encounter technical problems about writing arquillian. Would someone tell me how to resolve this problem? [Problem] - I could not find how to run an external authentication server(application running on wildfly 10) during each arquillian test cases. After resolving this problem and writing and running arquillian test cases, I'll send PR for this feature as product-base default providers. Best Regards Takashi Norimatsu Hitachi, Ltd. _______________________________________________ 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 Thu Aug 17 02:53:53 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 17 Aug 2017 08:53:53 +0200 Subject: [keycloak-dev] Proposal of using existing authentication and authorization server on behalf of keycloak browser-based authentication In-Reply-To: <831D472326678942A9B4BB933AAA103D68CB9B5D@GSjpTK1DCembx02.service.hitachi.net> References: <831D472326678942A9B4BB933AAA103D68CA8DDB@GSjpTK1DCembx01.service.hitachi.net> <831D472326678942A9B4BB933AAA103D68CB9260@GSjpTK1DCembx02.service.hitachi.net> <831D472326678942A9B4BB933AAA103D68CB9AC0@GSjpTK1DCembx02.service.hitachi.net> <831D472326678942A9B4BB933AAA103D68CB9B5D@GSjpTK1DCembx02.service.hitachi.net> Message-ID: OK, I finally understand exactly what you want to contribute, but afraid we'll have to reject it. We can not accept and maintain a custom protocol for many reasons, including: * It's a lot of work to maintain * It needs documenting and understanding by users * It's just a slightly different way to doing things than OIDC. In fact for Identity Brokering there's not that much you need to implement the OIDC part in the IdP * It could contain security vulnerabilities On 17 August 2017 at 08:47, ???? / NORIMATSU?TAKASHI < takashi.norimatsu.ws at hitachi.com> wrote: > Hello. > > >So rather than using standard protocols (OIDC or SAML) you've come up > with your own custom protocol that folks would have to implement instead? > Yes, but much easier for people than using OIDC/SAML. > > If OIDC is used for the existing authentication server, following OIDC OP > functions would have to be implemented. > - Authz Code Flow (at least) > - Authz Code management > - ID Token/Access Token management > - JWT > - JWS > - key management for JWT > > Instead, if supporting the simplified protocol such the one I have > proposed, only following would have to be implemented > - Issue temporal opaque ticket > - Send authenticated user info in return to this ticket > > Regards > Takashi Norimatsu > > -----Original Message----- > From: ???? / NORIMATSU?TAKASHI > Sent: Thursday, August 17, 2017 11:24 AM > To: 'stian at redhat.com' > Cc: 'keycloak-dev at lists.jboss.org' > Subject: RE: [!]Re: Re: [keycloak-dev] Proposal of using existing > authentication and authorization server on behalf of keycloak browser-based > authentication > > We do NOT intend to propose a "custom"(customer specific) brokering > protocol, are proposing a simplified brokering procedure for an external > authentication server without implementing OIDC/SAML. > > This is useful for users who have their existing authentication server. > They had to implement OIDC/SAML(very hard) or had to design and implement > another procedure(is also not easy). By the proposal, they can integrate > their authentication server easily. > > For example, UMA standard for authorization service is proposed, but seems > to be complicated, so keycloak has simplified procedure(entitlement API). > Feature is different but situation is the same (simplified OIDC/SAML). > > ---------- > From: Stian Thorgersen [mailto:sthorger at redhat.com] > Sent: Tuesday, August 15, 2017 4:49 PM > To: ???? / NORIMATSU?TAKASHI > Cc: keycloak-dev at lists.jboss.org > Subject: [!]Re: Re: [keycloak-dev] Proposal of using existing > authentication and authorization server on behalf of keycloak browser-based > authentication > > Afraid I still don't understand what you are trying to contribute to > Keycloak. As I said we already allow creating custom identity providers > using whatever protocol you want. We can't accept contribution of a custom > identity provider which is seems is what you are trying to contribute. > > On 15 August 2017 at 08:58, ???? / NORIMATSU?TAKASHI < > takashi.norimatsu.ws at hitachi.com> wrote: > > I'm not really following what you are proposing to contribute to > Keycloak. > Thank you for comment. > This contribution to keycloak is that to enhance competitiveness with > proprietary products. > > In some market, customers have highly customized Web UI for authentication. > (e.g. soft keyboard, responsive web design, very sophisticated look and > feel). > > They want to use Authorization server product (such as keycloak) > implementing OpenID Connect for securing the customer's API. > They want to use existing highly customized authentication server, but do > not want to implement OpenID Connect on this authentication server (too > much complex and difficult to implement). > > To meet such needs, proprietary products have the following solution. > > Proprietary authorization server products have their own procedure (much > simpler than OpenID Connect and SAMLv2) to communicate with existing > authentication server as below: > https://communities.ca.com/blogs/oauth/2016/10/04/howto- > integrating-otk-with-external-login-server?et=notification.send > https://www.ibm.com/support/knowledgecenter/en/SSMNED_5.0. > 0/com.ibm.apic.toolkit.doc/tapim_sec_api_config_scheme_oauth_endpoint.html > > In customer's existing authentication server, customers only have to > implement communication with the authorization server according to the > procedure prepared by the authorization server product (It is much easier > than implementing OpenID Connect or SAMLv2). Customers do not have to > implement anything in authorization server side. > On the other hand, if keycloak is used, customers have to do following: > a) In authorization server (RH SSO), simple procedure to communicate with > external authentication server have to be designed and implemented using > SPI. > b) In customer's existing authentication server, implement procedure > prepared by a). > -> In proprietary products, a) is prepared, but keycloak is not. > > Our proposed patch is intended to complement a). > > --- > > From: Stian Thorgersen [mailto:sthorger at redhat.com] > Sent: Monday, August 14, 2017 7:57 PM > To: ???? / NORIMATSU?TAKASHI > Cc: keycloak-dev at lists.jboss.org > Subject: [!]Re: [keycloak-dev] Proposal of using existing authentication > and authorization server on behalf of keycloak browser-based authentication > > I'm not really following what you are proposing to contribute to Keycloak. > We already have the SPI that allows adding a custom provider if your IdP > doesn't support SAML or OpenID Connect. > > On 31 July 2017 at 06:09, ???? / NORIMATSU?TAKASHI < > takashi.norimatsu.ws at hitachi.com> wrote: > Hello. > > Previously, I had proposed the feature and its implementation of > delegating authentication and authorization to an external existing server > on behalf of keycloak's browser-based authentication mechanism, and had > gotten advices that it is appropriate to use Identity Brokering for such > the feature. > > I've re-implemented this feature again by Identity Brokering. The > description and implementation of this feature is mentioned below. > https://github.com/Hitachi/PoV-keycloak-delegate-authn-consent > https://github.com/Hitachi/PoV-keycloak-delegate-authn- > consent/tree/master/src/keycloak/examples/providers/delegate-authn-consent > It can delegate not only authentication but authorization(consent). > > Kindly review it and provide us some comment and advices. > We would like to contribute this feature onto keycloak. > > Best Regards > Takashi Norimatsu > Hitachi, Ltd. > > --- > From: Stian Thorgersen [mailto:sthorger at redhat.com] > Sent: Thursday, June 29, 2017 6:23 PM > To: ???? / NORIMATSU?TAKASHI > Cc: keycloak-dev at lists.jboss.org > Subject: [!]Re: [keycloak-dev] Proposal of using existing authentication > server on behalf of keycloak browser-based authentication > > There's an SPI to implement your own custom identity brokering provider > [1]. > > [1] https://github.com/keycloak/keycloak/blob/master/ > server-spi-private/src/main/java/org/keycloak/broker/ > provider/IdentityProvider.java > > On 29 June 2017 at 10:51, ???? / NORIMATSU?TAKASHI < > takashi.norimatsu.ws at hitachi.com> wrote: > I need to use the authentication server without OIDC/OAuth2/SAMLv2 > implementation as an external IdP, in order to integrate existing > authentication system. > (some commercial products supports such the case) > > I consulted identity broker's section in keycloak's manual below and found > that if I use this feature the external IdP must support OIDC or SAMLv2. > https://keycloak.gitbooks.io/documentation/server_admin/ > topics/identity-broker.html > > Therefore, I realized it by using redirect based authentication flows. > > Can identity Brokering can support such the case? > > Aside from this, I'd like to contribute it to Community extensions and > examples. > > Best Regards > Takashi Norimatsu > Hitachi, Ltd. > > --- > From: Stian Thorgersen [mailto:sthorger at redhat.com] > Sent: Tuesday, June 27, 2017 5:52 PM > To: ???? / NORIMATSU?TAKASHI > Cc: keycloak-dev at lists.jboss.org > Subject: [!]Re: [keycloak-dev] Proposal of using existing authentication > server on behalf of keycloak browser-based authentication > > I'm not in favour of adding this. If it's using redirect based > authentication flows it should be done through identity brokering, not > authentication flows. It's also a very complex example that we don't want > to maintain. We've also in the process of moving all examples away from the > main Keycloak repository into a separate quickstart repository. > > On 27 June 2017 at 08:54, ???? / NORIMATSU?TAKASHI < > takashi.norimatsu.ws at hitachi.com> wrote: > Hello. > > Previously, I had proposed the feature of delegating authentication to an > external authentication server on behalf of keycloak's browser-based > authentication mechanism. > > I've integrated this feature to keycloak's "examples" packages and send PR > (https://github.com/keycloak/keycloak/pull/4260). > Hope this PR is reviewed and merged as an example for combining some > providers to customize keycloak. > > Detailed description of this feature is mentioned below. > https://github.com/Hitachi/PoV-keycloak-authentication-delegation > > I am now engaging in integrating this feature to keycloak as product-base > default providers, but encounter technical problems about writing > arquillian. Would someone tell me how to resolve this problem? > > [Problem] > - I could not find how to run an external authentication > server(application running on wildfly 10) during each arquillian test cases. > > After resolving this problem and writing and running arquillian test > cases, I'll send PR for this feature as product-base default providers. > > Best Regards > Takashi Norimatsu > Hitachi, Ltd. > > _______________________________________________ > 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 Thu Aug 17 03:20:35 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 17 Aug 2017 09:20:35 +0200 Subject: [keycloak-dev] KEYCLOAK-3314 acr/amr support In-Reply-To: <18bfd4af-7430-456c-ab59-a8d38b720531@Spark> References: <18bfd4af-7430-456c-ab59-a8d38b720531@Spark> Message-ID: Authentication flows and authenticators should be protocol agnostic. We currently support both OIDC and SAML. In the future we may add more as well. With that regards there needs to be a protocol agnostic concept of step-up authentication. We have some design ideas around it, which involves having conditions within the authentication flows that handles it rather than having authenticators to it themselves. Take a look at https://issues.jboss.org/browse/KEYCLOAK-847 that links to a Google Doc with some notes On 1 August 2017 at 17:53, Jannik H?ls wrote: > Hi, > > I would like to contribute to the Keycloak project and implement acr and > amr support like described in KEYCLOAK-3314. (However, I don?t know whether > this is a good place to start - but at least this is a recent topic very > many customers are currently requesting ;-)) > > My idea would be to implement it in a way Youssef suggested in the > comments. Thus every Authenticator of a specific Flow may get a > "Authentication Method Reference Value?. > E.g. having two Authenticators ?pwd? and ?top?: > > The claim acr_values describes the desired level of an authentication > request, thus using acr_values=pwd for the initial response should only > trigger the pwd Authenticator and return acr=pwd and amr=[pwd]. > A second authentication request using acr_values=otp should only trigger > the otp authenticator, but return acr=otp and amr=[pwd,otp]. > > Please let me know if you want to implement support of acr and amr - even > if my initial thoughts do not correspond to the ideas you have to implement > this. :-) > > Kind regards > Jannik > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From sthorger at redhat.com Thu Aug 17 06:19:35 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 17 Aug 2017 12:19:35 +0200 Subject: [keycloak-dev] Setup 'keycloak-security' mailing list Message-ID: We need to have a dedicated place to report and discuss security vulnerabilities. This should be a list anyone can send to, but only specific people can subscribe to. I'd like to create a new mailing list 'keycloak-security' for this purpose and have everyone on the team subscribed. Thoughts? Suggestions to alternative approaches? From sthorger at redhat.com Thu Aug 17 06:27:40 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 17 Aug 2017 12:27:40 +0200 Subject: [keycloak-dev] Wait time for PR tests to complete Message-ID: How long are we all willing to wait for PR tests to complete? Main reason I'm asking is that I'd like to add more tests to Travis (adapter tests, maybe testing with some proper dbs, etc..). From hmlnarik at redhat.com Thu Aug 17 07:07:46 2017 From: hmlnarik at redhat.com (Hynek Mlnarik) Date: Thu, 17 Aug 2017 13:07:46 +0200 Subject: [keycloak-dev] Wait time for PR tests to complete In-Reply-To: References: Message-ID: In terms of passed time since submitting the PR, not sum of times of the jobs, anything up to 2 hours in average would do for me. In terms of individual build jobs, at most 1 hour per job. I'd prefer PR testing to include testing adapters (at least WF) and cluster / cross DC scenarios. On Thu, Aug 17, 2017 at 12:27 PM, Stian Thorgersen wrote: > How long are we all willing to wait for PR tests to complete? > > Main reason I'm asking is that I'd like to add more tests to Travis > (adapter tests, maybe testing with some proper dbs, etc..). > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- --Hynek From sthorger at redhat.com Thu Aug 17 07:17:42 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 17 Aug 2017 13:17:42 +0200 Subject: [keycloak-dev] Wait time for PR tests to complete In-Reply-To: References: Message-ID: Travis already kills jobs after 50 min, so I'm only asking about the total amount of time from submitting a PR to all tests have completed. If others submit PRs at the same time everything is queued though and we have max 5 concurrent jobs for our repo. On 17 August 2017 at 13:07, Hynek Mlnarik wrote: > In terms of passed time since submitting the PR, not sum of times of > the jobs, anything up to 2 hours in average would do for me. In terms > of individual build jobs, at most 1 hour per job. > > I'd prefer PR testing to include testing adapters (at least WF) and > cluster / cross DC scenarios. > > On Thu, Aug 17, 2017 at 12:27 PM, Stian Thorgersen > wrote: > > How long are we all willing to wait for PR tests to complete? > > > > Main reason I'm asking is that I'd like to add more tests to Travis > > (adapter tests, maybe testing with some proper dbs, etc..). > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > > --Hynek > From sthorger at redhat.com Thu Aug 17 07:20:32 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 17 Aug 2017 13:20:32 +0200 Subject: [keycloak-dev] Keycloak 3.3.0.CR1 release approaching Message-ID: Keycloak 3.3.0.CR1 is scheduled to be released next week, so get your PRs ready. There's a good chance it'll get delayed a bit though as we're waiting for WildFly 11 CR1. From sthorger at redhat.com Thu Aug 17 07:29:49 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 17 Aug 2017 13:29:49 +0200 Subject: [keycloak-dev] May need to drop OpenShift v2 cartridge Message-ID: Our OpenShift v2 cartridge [1] is based on the WildFly cartridge [2]. We have a problem now as Keycloak 3.3 will be based on WildFly 11, while the WildFly cartridge hasn't been updated (and probably won't be) to WildFly 11. So we may need to drop OpenShift v2 support unless someone is willing to work on it. [1] https://github.com/keycloak/openshift-keycloak-cartridge [2] https://github.com/openshift-cartridges/openshift-wildfly-cartridge From psilva at redhat.com Thu Aug 17 07:47:46 2017 From: psilva at redhat.com (Pedro Igor Silva) Date: Thu, 17 Aug 2017 08:47:46 -0300 Subject: [keycloak-dev] token exchange In-Reply-To: References: <71449542-5454-44e4-936b-2099e366d8b5@redhat.com> <49f60419-0d5b-9f0b-ec58-7c06eb513570@redhat.com> <64994417-43b0-95d3-5de9-c0d78a226d79@redhat.com> <9b6efb46-944c-213b-848e-4e82d922da6f@redhat.com> Message-ID: I don't know Stian. We are talking about authentication and that is what the IDToken is all about. In fact, even Google [1] has some references about using IDTokens as a way to *authenticate* users. There are also specs with extensions to OAuth2 that do allow usage of *assertions" with the token endpoint [2] [3]. For instance, SAML and JWT assertions. [1] https://developers.google.com/identity/sign-in/web/backend-auth [2] https://www.rfc-editor.org/rfc/rfc7523.txt [3] https://tools.ietf.org/html/rfc7521 On Thu, Aug 17, 2017 at 2:05 AM, Stian Thorgersen wrote: > Actually, Bill has convinced me that ID token shouldn't be used for > authentication. If anything a special token only available in direct grant > should be used. The problem with ID token is that it's sent to the clients > themselves which would effectively give all clients full access to a users > account: > > * User logs in to app 1 through web flows > * App 1 gets an access token with limited roles, but also an ID token that > could be used for authentication > * App 1 uses the ID token to "authenticate" itself as the user to App 2 > and can now obtain an access token with more privileges then it should > It depends on how you set your policies. > > So using ID token to authenticate a user is a completely broken concept. > > On 15 August 2017 at 19:51, Pedro Igor Silva wrote: > >> We have discussed this before (I think because of Kubernetes), I don't >> see issues about using the IDToken as a bearer for "authentication". Of >> course, as long as you enforce validations that check if token can be >> trusted. >> >> In fact, I was about to start a discussion around IDToken and signature. >> In UMA 2.0 you can use different claim token formats to obtain a token >> (RPT) from the token endpoint. There is a specific grant type for that. One >> of the main changes we had in the specs. >> >> A common format is "http://openid.net/specs/openi >> d-connect-core-1_0.html#HybridIDToken", which is about using an IDToken. >> >> On Tue, Aug 15, 2017 at 12:32 PM, Bill Burke wrote: >> >>> I would be worried about the security implications of allowing an ID >>> token as a way to obtain access. If you have even one client in the domain >>> that is not fully trusted then you are toast. So how is it set up to make >>> things easy? One "master" client is defined in realm. That client is >>> given permission to obtain exchange for anything. That client is marked as >>> confidential. Generic CLI tool is configured with client id and secret of >>> "master" client. >>> On 8/15/17 2:50 AM, Stian Thorgersen wrote: >>> >>> First of all I'm not arguing against token exchange service. It's a very >>> useful thing IMO and I can see loads of use-cases for it. I'm just >>> wondering about how usable it will be for the CLI tool and I'm worried >>> about how complicated it would be to setup. If the ID token was signed that >>> could serve as a the "identity cookie" for a CLI SSO session (if ID token >>> is not suitable we could introduce some sort of identity token that can be >>> used by direct grant to allow SSO sessions). Using direct grant you can >>> then easily obtain a token for a specific client by just passing a valid >>> "identity cookie" same way as the web browser does. Is that not simpler to >>> setup and use? >>> >>> On 14 August 2017 at 15:42, Bill Burke wrote: >>> >>>> CLI tool I wrote doesn't allow token exchange, yet, but you're correct, >>>> I'm thinking of using it to perform token exchange. >>>> >>>> Our ID tokens are not signed right now. Also you still need client to >>>> client exchange so that you can "downgrade" a token to talk to an untrusted >>>> service. I've also added new fine-grain permissions "exchange-from" and >>>> "exchange-to". >>>> >>>> For example, lets say Client A gets token and invokes on service B >>>> which needs to invoke on untrusted service C. >>>> >>>> 1. Service B asks to exchange the token created for A to talk to C >>>> 2. Token exchange endpoint looks at issuer, its A, so it sees if >>>> service B has permission to "exchange-from" tokens created for A >>>> 3. Token exchange then sees if B has permission to "exchange-to" B. >>>> >>>> FYI, I'm also expanding this so that you can exchange an access token >>>> for a social provider token. Automatic refreshes and everything if the >>>> provider supports it. Gonna change how client initiated linking works too >>>> so that instead of doing the silly hash algorithm required by the call, >>>> clients would call the exchange first, get an error response like "not >>>> linked" that contained a browser URL that the client can use to create the >>>> link. >>>> >>>> Also no reason I couldn't do the same for exchange an external token to >>>> a internal one. Would work the same as our IDP, import the user, etc. >>>> >>>> >>>> On 8/14/17 7:06 AM, Stian Thorgersen wrote: >>>> >>>> I'm assuming the basic token exchange service comes from the way the >>>> CLI tool works? I.e. you login to the tool then it allows exchanging the >>>> token for a particular CLI client? >>>> >>>> Would it not be better to obtain an ID token and use direct grant to >>>> obtain a token for the client using the ID token as the authentication >>>> mechanism? >>>> >>>> On 1 August 2017 at 19:10, Pedro Igor Silva wrote: >>>> >>>>> On Mon, Jul 31, 2017 at 1:54 PM, Bill Burke wrote: >>>>> >>>>> > >>>>> > >>>>> > On 7/31/17 12:18 PM, Bill Burke wrote: >>>>> > >>>>> > >>>>> > >>>>> > On 7/31/17 11:35 AM, Pedro Igor Silva wrote: >>>>> > >>>>> > On Fri, Jul 28, 2017 at 5:24 PM, Bill Burke >>>>> wrote: >>>>> > >>>>> >> I've implemented a simple token exchange API [1] that allows you to >>>>> >> exchange an access token created for one client to another client. >>>>> The >>>>> >> REST API follows the oauth token exchange api [2] very loosely. >>>>> >> >>>>> >> subject_token: a keycloak access token >>>>> >> >>>>> >> audience: takes a client id >>>>> >> >>>>> >> It then converts the access token created for one client and >>>>> converts it >>>>> >> to another. It lives under the token endpoint. >>>>> >> >>>>> >> The security model is as follows: >>>>> >> >>>>> >> * Authenticate calling client the same way as password grant. >>>>> >> >>>>> >> * The calling client must have service account enabled >>>>> >> >>>>> >> * Service account must have a realm role "token-exchanger" grant >>>>> edto it >>>>> >> or, it must have a client role "token-exchanger" granted to it. >>>>> This >>>>> >> exchanger client role is a role defined by the target client you are >>>>> >> exchanging the token to. >>>>> >> >>>>> >> >>>>> >> Is this a good security model? I'm thinking of not creating these >>>>> roles >>>>> >> right now and to enable support for exchange would require defining >>>>> the >>>>> >> roles specified above. >>>>> >> >>>>> > >>>>> > I think roles are too coarse-grained to represent this kind of >>>>> policy. A >>>>> > better option would be to explicitly define the clients that are >>>>> allowed to >>>>> > exchange tokens for a particular resource server. Eg.: >>>>> > >>>>> > RS A allows Client B, C and D to exchange their tokens where the >>>>> target >>>>> > audience is RS A (or if using "resource", a specific resource in RS >>>>> A). >>>>> > >>>>> > >>>>> > I changed it a little. actors are: >>>>> > >>>>> > * Authenticated client asking for change >>>>> > * Clients that are the audience of the token being exchanged >>>>> > * Client you want the token to be exchanged to >>>>> > >>>>> > So, the authenticated client must be in the audience of the token >>>>> being >>>>> > exchanged, or, have permission to exchange from that particular >>>>> audience. >>>>> > The authenticated client also must have permission to exchange to the >>>>> > audience it wants to exchange to. >>>>> > >>>>> > Good idea to change it to use the fine grain admin permissions. >>>>> There's a >>>>> > couple of issues/problems with doing this that I think are easily >>>>> done: >>>>> > >>>>> > * public clients can't have service accounts. >>>>> > * Client Policy looks at kc_client_id attribute which is pulled from >>>>> the >>>>> > issuedFor claim in the token. This isn't correct as we permission >>>>> checks >>>>> > based on the authenticated client, not the token. >>>>> > >>>>> > So I'll have to create a new Identity type that either wraps the >>>>> service >>>>> > account or ClientModel and sets the "kc_client_id" property. >>>>> > >>>>> >>>>> Our policy evaluation engine is based on the claims within the token. >>>>> The >>>>> "issueFor" is basically the "azp" claim from OIDC. In fact, we don't >>>>> even >>>>> need that "kc_client_id". We could make this configurable though, and >>>>> let >>>>> users decide whether they want to check the "authenticated client" or >>>>> "azp" >>>>> ? >>>>> >>>>> Btw, I'm about to finish UMA Grant Type, one of the changes I'm doing >>>>> for >>>>> UMA 2.0. My changes will conflict with yours. Are you going to merge >>>>> your >>>>> changes soon ? >>>>> >>>>> Another thing I noticed is that maybe we could have a SPI for custom >>>>> grant >>>>> types. What you did and what I'm doing may justify a specific SPI for >>>>> plugging custom grant types. Maybe too much, but maybe a nice to have. >>>>> >>>>> >>>>> > >>>>> > >>>>> > Bill >>>>> > >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>> >>>> >>>> >>> >>> >> > From ssilvert at redhat.com Thu Aug 17 07:48:44 2017 From: ssilvert at redhat.com (Stan Silvert) Date: Thu, 17 Aug 2017 07:48:44 -0400 Subject: [keycloak-dev] Wait time for PR tests to complete In-Reply-To: References: Message-ID: <0f378ff2-6876-9117-5f20-122e50279575@redhat.com> On 8/17/2017 6:27 AM, Stian Thorgersen wrote: > How long are we all willing to wait for PR tests to complete? Longer doesn't bother me. It's not like I'm waiting around for it to finish. > > Main reason I'm asking is that I'd like to add more tests to Travis > (adapter tests, maybe testing with some proper dbs, etc..). > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From sthorger at redhat.com Thu Aug 17 07:54:30 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 17 Aug 2017 13:54:30 +0200 Subject: [keycloak-dev] token exchange In-Reply-To: References: <71449542-5454-44e4-936b-2099e366d8b5@redhat.com> <49f60419-0d5b-9f0b-ec58-7c06eb513570@redhat.com> <64994417-43b0-95d3-5de9-c0d78a226d79@redhat.com> <9b6efb46-944c-213b-848e-4e82d922da6f@redhat.com> Message-ID: On 17 August 2017 at 13:47, Pedro Igor Silva wrote: > I don't know Stian. We are talking about authentication and that is what > the IDToken is all about. In fact, even Google [1] has some references > about using IDTokens as a way to *authenticate* users. > Sure, but that's to authenticate to one specific application, not to authenticate to the IdP itself. The concept of authenticating with the IdP with a ID token is broken. > > There are also specs with extensions to OAuth2 that do allow usage of > *assertions" with the token endpoint [2] [3]. For instance, SAML and JWT > assertions. > > [1] https://developers.google.com/identity/sign-in/web/backend-auth > [2] https://www.rfc-editor.org/rfc/rfc7523.txt > [3] https://tools.ietf.org/html/rfc7521 > > On Thu, Aug 17, 2017 at 2:05 AM, Stian Thorgersen > wrote: > >> Actually, Bill has convinced me that ID token shouldn't be used for >> authentication. If anything a special token only available in direct grant >> should be used. The problem with ID token is that it's sent to the clients >> themselves which would effectively give all clients full access to a users >> account: >> >> * User logs in to app 1 through web flows >> * App 1 gets an access token with limited roles, but also an ID token >> that could be used for authentication >> * App 1 uses the ID token to "authenticate" itself as the user to App 2 >> and can now obtain an access token with more privileges then it should >> > > It depends on how you set your policies. > > >> >> So using ID token to authenticate a user is a completely broken concept. >> >> On 15 August 2017 at 19:51, Pedro Igor Silva wrote: >> >>> We have discussed this before (I think because of Kubernetes), I don't >>> see issues about using the IDToken as a bearer for "authentication". Of >>> course, as long as you enforce validations that check if token can be >>> trusted. >>> >>> In fact, I was about to start a discussion around IDToken and signature. >>> In UMA 2.0 you can use different claim token formats to obtain a token >>> (RPT) from the token endpoint. There is a specific grant type for that. One >>> of the main changes we had in the specs. >>> >>> A common format is "http://openid.net/specs/openi >>> d-connect-core-1_0.html#HybridIDToken", which is about using an IDToken. >>> >>> On Tue, Aug 15, 2017 at 12:32 PM, Bill Burke wrote: >>> >>>> I would be worried about the security implications of allowing an ID >>>> token as a way to obtain access. If you have even one client in the domain >>>> that is not fully trusted then you are toast. So how is it set up to make >>>> things easy? One "master" client is defined in realm. That client is >>>> given permission to obtain exchange for anything. That client is marked as >>>> confidential. Generic CLI tool is configured with client id and secret of >>>> "master" client. >>>> On 8/15/17 2:50 AM, Stian Thorgersen wrote: >>>> >>>> First of all I'm not arguing against token exchange service. It's a >>>> very useful thing IMO and I can see loads of use-cases for it. I'm just >>>> wondering about how usable it will be for the CLI tool and I'm worried >>>> about how complicated it would be to setup. If the ID token was signed that >>>> could serve as a the "identity cookie" for a CLI SSO session (if ID token >>>> is not suitable we could introduce some sort of identity token that can be >>>> used by direct grant to allow SSO sessions). Using direct grant you can >>>> then easily obtain a token for a specific client by just passing a valid >>>> "identity cookie" same way as the web browser does. Is that not simpler to >>>> setup and use? >>>> >>>> On 14 August 2017 at 15:42, Bill Burke wrote: >>>> >>>>> CLI tool I wrote doesn't allow token exchange, yet, but you're >>>>> correct, I'm thinking of using it to perform token exchange. >>>>> >>>>> Our ID tokens are not signed right now. Also you still need client to >>>>> client exchange so that you can "downgrade" a token to talk to an untrusted >>>>> service. I've also added new fine-grain permissions "exchange-from" and >>>>> "exchange-to". >>>>> >>>>> For example, lets say Client A gets token and invokes on service B >>>>> which needs to invoke on untrusted service C. >>>>> >>>>> 1. Service B asks to exchange the token created for A to talk to C >>>>> 2. Token exchange endpoint looks at issuer, its A, so it sees if >>>>> service B has permission to "exchange-from" tokens created for A >>>>> 3. Token exchange then sees if B has permission to "exchange-to" B. >>>>> >>>>> FYI, I'm also expanding this so that you can exchange an access token >>>>> for a social provider token. Automatic refreshes and everything if the >>>>> provider supports it. Gonna change how client initiated linking works too >>>>> so that instead of doing the silly hash algorithm required by the call, >>>>> clients would call the exchange first, get an error response like "not >>>>> linked" that contained a browser URL that the client can use to create the >>>>> link. >>>>> >>>>> Also no reason I couldn't do the same for exchange an external token >>>>> to a internal one. Would work the same as our IDP, import the user, etc. >>>>> >>>>> >>>>> On 8/14/17 7:06 AM, Stian Thorgersen wrote: >>>>> >>>>> I'm assuming the basic token exchange service comes from the way the >>>>> CLI tool works? I.e. you login to the tool then it allows exchanging the >>>>> token for a particular CLI client? >>>>> >>>>> Would it not be better to obtain an ID token and use direct grant to >>>>> obtain a token for the client using the ID token as the authentication >>>>> mechanism? >>>>> >>>>> On 1 August 2017 at 19:10, Pedro Igor Silva wrote: >>>>> >>>>>> On Mon, Jul 31, 2017 at 1:54 PM, Bill Burke >>>>>> wrote: >>>>>> >>>>>> > >>>>>> > >>>>>> > On 7/31/17 12:18 PM, Bill Burke wrote: >>>>>> > >>>>>> > >>>>>> > >>>>>> > On 7/31/17 11:35 AM, Pedro Igor Silva wrote: >>>>>> > >>>>>> > On Fri, Jul 28, 2017 at 5:24 PM, Bill Burke >>>>>> wrote: >>>>>> > >>>>>> >> I've implemented a simple token exchange API [1] that allows you to >>>>>> >> exchange an access token created for one client to another >>>>>> client. The >>>>>> >> REST API follows the oauth token exchange api [2] very loosely. >>>>>> >> >>>>>> >> subject_token: a keycloak access token >>>>>> >> >>>>>> >> audience: takes a client id >>>>>> >> >>>>>> >> It then converts the access token created for one client and >>>>>> converts it >>>>>> >> to another. It lives under the token endpoint. >>>>>> >> >>>>>> >> The security model is as follows: >>>>>> >> >>>>>> >> * Authenticate calling client the same way as password grant. >>>>>> >> >>>>>> >> * The calling client must have service account enabled >>>>>> >> >>>>>> >> * Service account must have a realm role "token-exchanger" grant >>>>>> edto it >>>>>> >> or, it must have a client role "token-exchanger" granted to it. >>>>>> This >>>>>> >> exchanger client role is a role defined by the target client you >>>>>> are >>>>>> >> exchanging the token to. >>>>>> >> >>>>>> >> >>>>>> >> Is this a good security model? I'm thinking of not creating these >>>>>> roles >>>>>> >> right now and to enable support for exchange would require >>>>>> defining the >>>>>> >> roles specified above. >>>>>> >> >>>>>> > >>>>>> > I think roles are too coarse-grained to represent this kind of >>>>>> policy. A >>>>>> > better option would be to explicitly define the clients that are >>>>>> allowed to >>>>>> > exchange tokens for a particular resource server. Eg.: >>>>>> > >>>>>> > RS A allows Client B, C and D to exchange their tokens where the >>>>>> target >>>>>> > audience is RS A (or if using "resource", a specific resource in RS >>>>>> A). >>>>>> > >>>>>> > >>>>>> > I changed it a little. actors are: >>>>>> > >>>>>> > * Authenticated client asking for change >>>>>> > * Clients that are the audience of the token being exchanged >>>>>> > * Client you want the token to be exchanged to >>>>>> > >>>>>> > So, the authenticated client must be in the audience of the token >>>>>> being >>>>>> > exchanged, or, have permission to exchange from that particular >>>>>> audience. >>>>>> > The authenticated client also must have permission to exchange to >>>>>> the >>>>>> > audience it wants to exchange to. >>>>>> > >>>>>> > Good idea to change it to use the fine grain admin permissions. >>>>>> There's a >>>>>> > couple of issues/problems with doing this that I think are easily >>>>>> done: >>>>>> > >>>>>> > * public clients can't have service accounts. >>>>>> > * Client Policy looks at kc_client_id attribute which is pulled >>>>>> from the >>>>>> > issuedFor claim in the token. This isn't correct as we permission >>>>>> checks >>>>>> > based on the authenticated client, not the token. >>>>>> > >>>>>> > So I'll have to create a new Identity type that either wraps the >>>>>> service >>>>>> > account or ClientModel and sets the "kc_client_id" property. >>>>>> > >>>>>> >>>>>> Our policy evaluation engine is based on the claims within the token. >>>>>> The >>>>>> "issueFor" is basically the "azp" claim from OIDC. In fact, we don't >>>>>> even >>>>>> need that "kc_client_id". We could make this configurable though, and >>>>>> let >>>>>> users decide whether they want to check the "authenticated client" or >>>>>> "azp" >>>>>> ? >>>>>> >>>>>> Btw, I'm about to finish UMA Grant Type, one of the changes I'm doing >>>>>> for >>>>>> UMA 2.0. My changes will conflict with yours. Are you going to merge >>>>>> your >>>>>> changes soon ? >>>>>> >>>>>> Another thing I noticed is that maybe we could have a SPI for custom >>>>>> grant >>>>>> types. What you did and what I'm doing may justify a specific SPI for >>>>>> plugging custom grant types. Maybe too much, but maybe a nice to have. >>>>>> >>>>>> >>>>>> > >>>>>> > >>>>>> > Bill >>>>>> > >>>>>> _______________________________________________ >>>>>> keycloak-dev mailing list >>>>>> keycloak-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >> > From john.d.ament at gmail.com Thu Aug 17 07:58:10 2017 From: john.d.ament at gmail.com (John D. Ament) Date: Thu, 17 Aug 2017 11:58:10 +0000 Subject: [keycloak-dev] Ticket with patch RE NPE when loading Recaptcha flow Message-ID: https://issues.jboss.org/browse/KEYCLOAK-5274 I attached a patch to this ticket, let me know if you want me to raise a PR with this change. John From psilva at redhat.com Thu Aug 17 08:11:52 2017 From: psilva at redhat.com (Pedro Igor Silva) Date: Thu, 17 Aug 2017 09:11:52 -0300 Subject: [keycloak-dev] Keycloak 3.3.0.CR1 release approaching In-Reply-To: References: Message-ID: I have some changes in the queue for WF11 + Elytron adapters [1] and I'm working on some other changes to adapter subsystem. I hope to have a PR with subsystem changes until tomorrow. My challenge is to try to keep the same subsystem working for both WF10 and WF11. Otherwise, I'm afraid we would need a separated distribution for WF11. [1] https://github.com/keycloak/keycloak/pull/4388 On Thu, Aug 17, 2017 at 8:20 AM, Stian Thorgersen wrote: > Keycloak 3.3.0.CR1 is scheduled to be released next week, so get your PRs > ready. There's a good chance it'll get delayed a bit though as we're > waiting for WildFly 11 CR1. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bruno at abstractj.org Thu Aug 17 09:56:20 2017 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 17 Aug 2017 13:56:20 +0000 Subject: [keycloak-dev] Setup 'keycloak-security' mailing list In-Reply-To: References: Message-ID: Go for it! +1 I'd add a very visible section at the website and README files, about reporting vulnerabilities. Today we have this http://www.keycloak.org/community.html. But it's not that obvious. I'd suggest something like https://www.emberjs.com/security/ On Thu, Aug 17, 2017 at 7:22 AM Stian Thorgersen wrote: > We need to have a dedicated place to report and discuss security > vulnerabilities. This should be a list anyone can send to, but only > specific people can subscribe to. > > I'd like to create a new mailing list 'keycloak-security' for this purpose > and have everyone on the team subscribed. > > Thoughts? Suggestions to alternative approaches? > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From alkazako at redhat.com Thu Aug 17 14:45:30 2017 From: alkazako at redhat.com (Alexey Kazakov) Date: Thu, 17 Aug 2017 11:45:30 -0700 Subject: [keycloak-dev] Remove realm json at "/auth/realms/" In-Reply-To: References: <9c42e9ba-93cc-660d-103a-cb9cd28c46ca@redhat.com> Message-ID: <55f8654e-bf70-9f16-b615-e5bcde122569@redhat.com> On 08/16/2017 09:46 PM, Stian Thorgersen wrote: > > > On 16 August 2017 at 15:40, Alexey Kazakov > wrote: > > > On 08/15/2017 05:00 AM, Stian Thorgersen wrote: > > I propose we remove the realm json returned at > "/auth/realms/" > > and just return an empty page > > > > * It can end-up being visible to end-users - we should rather > have a realm > > welcome page / SSO landing page here > What is wrong with exposing this json to users? > > > Nothing much really. There's no details there that are sensitive nor > can't easily be found out regardless. It doesn't look good if a > end-user happens to go to this URL though and is shown some JSON file > rather than a HTML page. > > > > > * It's not used by anything AFAIK > > I'm not sure if this endpoint is documented but it can be used by > users/clients. For example we use this endpoint to fetch the > public key > of the realm in openshift.io plus for simple > health check. Should > something else be used instead? > > > For public keys use: > /auth/realms//.well-known/openid-configuration > > That's what our adapters use and it's a OIDC standard endpoint Hm.. I don't see any public key in /auth/realms//.well-known/openid-configuration Thanks. > > > > > * From time to time people complain about it ( > > https://issues.jboss.org/browse/KEYCLOAK-5279 > for instance, > there's more > > similar issues reported) > It seems that I don't have access to this issue. What kind of problems > this endpoint can cause? > > > Folks claim it's a security issue. I disagree with that, but it comes > up from time to time. > > > > > _______________________________________________ > > 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 Aug 18 01:25:25 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 18 Aug 2017 07:25:25 +0200 Subject: [keycloak-dev] Remove realm json at "/auth/realms/" In-Reply-To: <55f8654e-bf70-9f16-b615-e5bcde122569@redhat.com> References: <9c42e9ba-93cc-660d-103a-cb9cd28c46ca@redhat.com> <55f8654e-bf70-9f16-b615-e5bcde122569@redhat.com> Message-ID: My bad, been on holiday to long. It's not in there directly, but rather then URI for the keys are specified in jwks_uri. So it'll be something like: http://localhost:8080/auth/realms/master/protocol/openid-connect/certs One of the main reasons you want to use this is that there can be more than one public key permitted at any given time due to key rotation support. On 17 August 2017 at 20:45, Alexey Kazakov wrote: > > > On 08/16/2017 09:46 PM, Stian Thorgersen wrote: > > > > > > On 16 August 2017 at 15:40, Alexey Kazakov > > wrote: > > > > > > On 08/15/2017 05:00 AM, Stian Thorgersen wrote: > > > I propose we remove the realm json returned at > > "/auth/realms/" > > > and just return an empty page > > > > > > * It can end-up being visible to end-users - we should rather > > have a realm > > > welcome page / SSO landing page here > > What is wrong with exposing this json to users? > > > > > > Nothing much really. There's no details there that are sensitive nor > > can't easily be found out regardless. It doesn't look good if a > > end-user happens to go to this URL though and is shown some JSON file > > rather than a HTML page. > > > > > > > > > * It's not used by anything AFAIK > > > > I'm not sure if this endpoint is documented but it can be used by > > users/clients. For example we use this endpoint to fetch the > > public key > > of the realm in openshift.io plus for simple > > health check. Should > > something else be used instead? > > > > > > For public keys use: > > /auth/realms//.well-known/openid-configuration > > > > That's what our adapters use and it's a OIDC standard endpoint > > Hm.. I don't see any public key in /auth/realms/ name>/.well-known/openid-configuration > > Thanks. > > > > > > > > > > * From time to time people complain about it ( > > > https://issues.jboss.org/browse/KEYCLOAK-5279 > > for instance, > > there's more > > > similar issues reported) > > It seems that I don't have access to this issue. What kind of > problems > > this endpoint can cause? > > > > > > Folks claim it's a security issue. I disagree with that, but it comes > > up from time to time. > > > > > > > > > _______________________________________________ > > > 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 Aug 18 02:30:42 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Fri, 18 Aug 2017 08:30:42 +0200 Subject: [keycloak-dev] Ticket with patch RE NPE when loading Recaptcha flow In-Reply-To: References: Message-ID: Please send a PR. Ideally it should have a testcase as well, but I'm not sure that would be very trivial as we don't currently have tests with caching disabled. On 17 August 2017 at 13:58, John D. Ament wrote: > https://issues.jboss.org/browse/KEYCLOAK-5274 > > I attached a patch to this ticket, let me know if you want me to raise a PR > with this change. > > John > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bburke at redhat.com Fri Aug 18 10:26:01 2017 From: bburke at redhat.com (Bill Burke) Date: Fri, 18 Aug 2017 10:26:01 -0400 Subject: [keycloak-dev] token exchange permission model Message-ID: <71ebe041-7c4b-bd95-572d-e323db410f7f@redhat.com> Right now I have a "exchange-from" and "exchange-to" permission when exchanging client->client tokens. I'm wondering if an "exchange-from" permission needs to exist? Would we ever have the case where a client is allowed to "exchange-to", but not "exchange-from"? I'm thinking this is just overboard and would rarely be used. Bill From psilva at redhat.com Fri Aug 18 13:11:07 2017 From: psilva at redhat.com (Pedro Igor Silva) Date: Fri, 18 Aug 2017 14:11:07 -0300 Subject: [keycloak-dev] token exchange permission model In-Reply-To: <71ebe041-7c4b-bd95-572d-e323db410f7f@redhat.com> References: <71ebe041-7c4b-bd95-572d-e323db410f7f@redhat.com> Message-ID: +1. I think exchange-to is enough for now. On Fri, Aug 18, 2017 at 11:26 AM, Bill Burke wrote: > Right now I have a "exchange-from" and "exchange-to" permission when > exchanging client->client tokens. I'm wondering if an "exchange-from" > permission needs to exist? Would we ever have the case where a client > is allowed to "exchange-to", but not "exchange-from"? I'm thinking this > is just overboard and would rarely be used. > > Bill > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From alkazako at redhat.com Fri Aug 18 14:06:42 2017 From: alkazako at redhat.com (Alexey Kazakov) Date: Fri, 18 Aug 2017 11:06:42 -0700 Subject: [keycloak-dev] Remove realm json at "/auth/realms/" In-Reply-To: References: <9c42e9ba-93cc-660d-103a-cb9cd28c46ca@redhat.com> <55f8654e-bf70-9f16-b615-e5bcde122569@redhat.com> Message-ID: On 08/17/2017 10:25 PM, Stian Thorgersen wrote: > My bad, been on holiday to long. It's not in there directly, but > rather then URI for the keys are specified in jwks_uri. So it'll be > something like: > http://localhost:8080/auth/realms/master/protocol/openid-connect/certs Ah, OK. That looks good :) We will need to start using this endpoint instead of the /auth/realms/ Thanks! > One of the main reasons you want to use this is that there can be more > than one public key permitted at any given time due to key rotation > support. > > On 17 August 2017 at 20:45, Alexey Kazakov > wrote: > > > > On 08/16/2017 09:46 PM, Stian Thorgersen wrote: > > > > > > On 16 August 2017 at 15:40, Alexey Kazakov > > >> wrote: > > > > > > On 08/15/2017 05:00 AM, Stian Thorgersen wrote: > > > I propose we remove the realm json returned at > > "/auth/realms/" > > > and just return an empty page > > > > > > * It can end-up being visible to end-users - we should rather > > have a realm > > > welcome page / SSO landing page here > > What is wrong with exposing this json to users? > > > > > > Nothing much really. There's no details there that are sensitive nor > > can't easily be found out regardless. It doesn't look good if a > > end-user happens to go to this URL though and is shown some JSON > file > > rather than a HTML page. > > > > > > > > > * It's not used by anything AFAIK > > > > I'm not sure if this endpoint is documented but it can be > used by > > users/clients. For example we use this endpoint to fetch the > > public key > > of the realm in openshift.io > plus for simple > > health check. Should > > something else be used instead? > > > > > > For public keys use: > > /auth/realms//.well-known/openid-configuration > > > > That's what our adapters use and it's a OIDC standard endpoint > > Hm.. I don't see any public key in /auth/realms/ name>/.well-known/openid-configuration > > Thanks. > > > > > > > > > > * From time to time people complain about it ( > > > https://issues.jboss.org/browse/KEYCLOAK-5279 > > > > for instance, > > there's more > > > similar issues reported) > > It seems that I don't have access to this issue. What kind > of problems > > this endpoint can cause? > > > > > > Folks claim it's a security issue. I disagree with that, but it > comes > > up from time to time. > > > > > > > > > _______________________________________________ > > > 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 bburke at redhat.com Fri Aug 18 14:51:20 2017 From: bburke at redhat.com (Bill Burke) Date: Fri, 18 Aug 2017 14:51:20 -0400 Subject: [keycloak-dev] jarless Keycloak distro Message-ID: <788701fa-6769-8aac-07f4-70b1f258aadc@redhat.com> Did you know with a flip of a switch that a jarless Keycloak distro can be created? Just edit /distribution/server-provisioning.xml and remove extraction params: All the module.xml reference maven artifacts and when you boot the distro it tries by default to resolve them in ~/.m2, you can even point it to a remote distro and it will download the jars. From sthorger at redhat.com Mon Aug 21 00:56:57 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 21 Aug 2017 06:56:57 +0200 Subject: [keycloak-dev] jarless Keycloak distro In-Reply-To: <788701fa-6769-8aac-07f4-70b1f258aadc@redhat.com> References: <788701fa-6769-8aac-07f4-70b1f258aadc@redhat.com> Message-ID: I knew, but are there any benefits? On 18 August 2017 at 20:51, Bill Burke wrote: > Did you know with a flip of a switch that a jarless Keycloak distro can > be created? Just edit /distribution/server-provisioning.xml and > remove extraction params: > > extract-schemas="true"> > > artifactId="keycloak-server-feature-pack" version="${project.version}"/> > > > > All the module.xml reference maven artifacts and when you boot the > distro it tries by default to resolve them in ~/.m2, you can even point > it to a remote distro and it will download the jars. > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From mposolda at redhat.com Mon Aug 21 04:49:06 2017 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 21 Aug 2017 10:49:06 +0200 Subject: [keycloak-dev] jarless Keycloak distro In-Reply-To: References: <788701fa-6769-8aac-07f4-70b1f258aadc@redhat.com> Message-ID: <97fb8d41-1da3-63c5-ef21-88be67e1f745@redhat.com> Thanks for the tip! I see the benefit just during development. Or is it some other? Usually when I do changes in Keycloak sources in some module (eg. in keycloak-model-jpa module) I need to: 1) Build the module with "mvn clean install" 2) Copy the keycloak-model-jpa.jar to the modules in my Wildfly server. Or rebuild whole distro. 3) Restart the Wildfly With this, you don't need step 2. Still embedded undertow is best as you don't even need step 1 when running KeycloakServer from Idea ;) And for UI only changes, even server restart is not needed with embedded undertow and -Dresources option. Marek On 21/08/17 06:56, Stian Thorgersen wrote: > I knew, but are there any benefits? > > On 18 August 2017 at 20:51, Bill Burke wrote: > >> Did you know with a flip of a switch that a jarless Keycloak distro can >> be created? Just edit /distribution/server-provisioning.xml and >> remove extraction params: >> >> > extract-schemas="true"> >> >> > artifactId="keycloak-server-feature-pack" version="${project.version}"/> >> >> >> >> All the module.xml reference maven artifacts and when you boot the >> distro it tries by default to resolve them in ~/.m2, you can even point >> it to a remote distro and it will download the jars. >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From hmlnarik at redhat.com Mon Aug 21 05:30:40 2017 From: hmlnarik at redhat.com (Hynek Mlnarik) Date: Mon, 21 Aug 2017 11:30:40 +0200 Subject: [keycloak-dev] jarless Keycloak distro In-Reply-To: <788701fa-6769-8aac-07f4-70b1f258aadc@redhat.com> References: <788701fa-6769-8aac-07f4-70b1f258aadc@redhat.com> Message-ID: Thanks for the hint! I didn't know about that and started using it when working on adapters for WF. Less painful development now :-) --Hynek On Fri, Aug 18, 2017 at 8:51 PM, Bill Burke wrote: > Did you know with a flip of a switch that a jarless Keycloak distro can > be created? Just edit /distribution/server-provisioning.xml and > remove extraction params: > > extract-schemas="true"> > > artifactId="keycloak-server-feature-pack" version="${project.version}"/> > > > > All the module.xml reference maven artifacts and when you boot the > distro it tries by default to resolve them in ~/.m2, you can even point > it to a remote distro and it will download the jars. > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- --Hynek From john.d.ament at gmail.com Mon Aug 21 07:47:33 2017 From: john.d.ament at gmail.com (John D. Ament) Date: Mon, 21 Aug 2017 11:47:33 +0000 Subject: [keycloak-dev] Ticket with patch RE NPE when loading Recaptcha flow In-Reply-To: References: Message-ID: Done - https://github.com/keycloak/keycloak/pull/4404 On Fri, Aug 18, 2017 at 2:30 AM Stian Thorgersen wrote: > Please send a PR. Ideally it should have a testcase as well, but I'm not > sure that would be very trivial as we don't currently have tests with > caching disabled. > > On 17 August 2017 at 13:58, John D. Ament wrote: > >> https://issues.jboss.org/browse/KEYCLOAK-5274 >> >> I attached a patch to this ticket, let me know if you want me to raise a >> PR >> with this change. >> >> John >> > _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > From john.d.ament at gmail.com Mon Aug 21 07:56:11 2017 From: john.d.ament at gmail.com (John D. Ament) Date: Mon, 21 Aug 2017 11:56:11 +0000 Subject: [keycloak-dev] Allow FreemarkerEmailTemplateProvider to be extensible Message-ID: All, I've raised a PR, based on another ticket that was out there, that makes FreemarkerEmailTemplateProvider more extensible. https://issues.jboss.org/browse/KEYCLOAK-5285 Any chance this could be included in the coming 3.3 release? John From ssilvert at redhat.com Mon Aug 21 08:36:16 2017 From: ssilvert at redhat.com (Stan Silvert) Date: Mon, 21 Aug 2017 08:36:16 -0400 Subject: [keycloak-dev] jarless Keycloak distro In-Reply-To: <97fb8d41-1da3-63c5-ef21-88be67e1f745@redhat.com> References: <788701fa-6769-8aac-07f4-70b1f258aadc@redhat.com> <97fb8d41-1da3-63c5-ef21-88be67e1f745@redhat.com> Message-ID: I've been using a jarless distro since I first started working on Keycloak. I like working with a "real" WF server instead of embedded undertow. The tradeoff is that I do need to do step 1 (build the module). The only thing you really need to change in server-provisioning.xml is the copy-module-artifacts param. Just change it from true to false. I have a have a bat file that builds jarless server, adds admin user, and points the theme stuff to my dev directory: cd c:\GitHub\keycloak\distribution\server-dist call mvn clean sed -i 's/copy-module-artifacts="true"/copy-module-artifacts="false"/' /cygdrive/c/GitHub/keycloak/distribution/server-provisioning.xml call mvn compile -DskipTests sed -i 's/copy-module-artifacts="false"/copy-module-artifacts="true"/' /cygdrive/c/GitHub/keycloak/distribution/server-provisioning.xml cd c:\GitHub\keycloak\distribution\server-dist\target\keycloak*\modules copy c:\GitHub\keycloak\distribution\server-dist\src\main\modules\layers.conf set NOPAUSE=true cd c:\GitHub\keycloak\distribution\server-dist\target\keycloak*\bin call add-user-keycloak -u admin -p admin call jboss-cli --file=/bat/write-theme-dir.cli The write-theme-dir.cli script is handy on its own: embed-server --server-config=standalone.xml /subsystem=keycloak-server/theme=defaults/:write-attribute(name=dir,value=/GitHub/keycloak/themes/src/main/resources/theme) /subsystem=keycloak-server/theme=defaults/:write-attribute(name=cacheTemplates,value=false) /subsystem=keycloak-server/theme=defaults/:write-attribute(name=cacheThemes,value=false) On 8/21/2017 4:49 AM, Marek Posolda wrote: > Thanks for the tip! > > I see the benefit just during development. Or is it some other? > > Usually when I do changes in Keycloak sources in some module (eg. in > keycloak-model-jpa module) I need to: > > 1) Build the module with "mvn clean install" > 2) Copy the keycloak-model-jpa.jar to the modules in my Wildfly server. > Or rebuild whole distro. > 3) Restart the Wildfly > > With this, you don't need step 2. > > Still embedded undertow is best as you don't even need step 1 when > running KeycloakServer from Idea ;) And for UI only changes, even server > restart is not needed with embedded undertow and -Dresources option. > > Marek > > > On 21/08/17 06:56, Stian Thorgersen wrote: >> I knew, but are there any benefits? >> >> On 18 August 2017 at 20:51, Bill Burke wrote: >> >>> Did you know with a flip of a switch that a jarless Keycloak distro can >>> be created? Just edit /distribution/server-provisioning.xml and >>> remove extraction params: >>> >>> >> extract-schemas="true"> >>> >>> >> artifactId="keycloak-server-feature-pack" version="${project.version}"/> >>> >>> >>> >>> All the module.xml reference maven artifacts and when you boot the >>> distro it tries by default to resolve them in ~/.m2, you can even point >>> it to a remote distro and it will download the jars. >>> >>> >>> _______________________________________________ >>> 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 bburke at redhat.com Mon Aug 21 10:02:50 2017 From: bburke at redhat.com (Bill Burke) Date: Mon, 21 Aug 2017 10:02:50 -0400 Subject: [keycloak-dev] jarless Keycloak distro In-Reply-To: <97fb8d41-1da3-63c5-ef21-88be67e1f745@redhat.com> References: <788701fa-6769-8aac-07f4-70b1f258aadc@redhat.com> <97fb8d41-1da3-63c5-ef21-88be67e1f745@redhat.com> Message-ID: <135446a4-bcc5-6633-d407-032f8ba289c2@redhat.com> Helps in dev a lot like you said. I was told Wildfly team builds it for their arquillian test harness.? Not sure why it would be beneficial. Could define "profiles" that are small downloads and ready to run. At least for Wildfly, saves disk space or allows for a mounted NFS shared maven repo. Jason Greene was talking about using shared docker data volumes + mmapped jars.? This kind of structure might be able to facilitate that. On 8/21/17 4:49 AM, Marek Posolda wrote: > Thanks for the tip! > > I see the benefit just during development. Or is it some other? > > Usually when I do changes in Keycloak sources in some module (eg. in > keycloak-model-jpa module) I need to: > > 1) Build the module with "mvn clean install" > 2) Copy the keycloak-model-jpa.jar to the modules in my Wildfly > server. Or rebuild whole distro. > 3) Restart the Wildfly > > With this, you don't need step 2. > > Still embedded undertow is best as you don't even need step 1 when > running KeycloakServer from Idea ;) And for UI only changes, even > server restart is not needed with embedded undertow and -Dresources > option. > > Marek > > > On 21/08/17 06:56, Stian Thorgersen wrote: >> I knew, but are there any benefits? >> >> On 18 August 2017 at 20:51, Bill Burke wrote: >> >>> Did you know with a flip of a switch that a jarless Keycloak distro can >>> be created?? Just edit /distribution/server-provisioning.xml and >>> remove extraction params: >>> >>> >> extract-schemas="true"> >>> ????? >>> ????????? >> artifactId="keycloak-server-feature-pack" >>> version="${project.version}"/> >>> ????? >>> >>> >>> All the module.xml reference maven artifacts and when you boot the >>> distro it tries by default to resolve them in ~/.m2, you can even point >>> it to a remote distro and it will download the jars. >>> >>> >>> _______________________________________________ >>> 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 bburke at redhat.com Mon Aug 21 10:05:09 2017 From: bburke at redhat.com (Bill Burke) Date: Mon, 21 Aug 2017 10:05:09 -0400 Subject: [keycloak-dev] remove jboss-client.jar? Message-ID: FYI, Our distro is 17M bigger because we include jboss.client.jar. This jar is uber jar by Java clients that want to talk to server (stubs, jndi, etc.), but its 17M. Bill From ssilvert at redhat.com Mon Aug 21 11:31:07 2017 From: ssilvert at redhat.com (Stan Silvert) Date: Mon, 21 Aug 2017 11:31:07 -0400 Subject: [keycloak-dev] remove jboss-client.jar? In-Reply-To: References: Message-ID: <8918a5b7-6ee5-d364-b925-d85b1f7172be@redhat.com> We could also think about getting rid of jboss-cli-client.jar. It's not used by jboss-cli.sh when you are running from /bin. It is copied to a remote box when someone wants to use jboss-cli.sh remotely. Removing it would save another 7M. On 8/21/2017 10:05 AM, Bill Burke wrote: > FYI, > > Our distro is 17M bigger because we include jboss.client.jar. This jar > is uber jar by Java clients that want to talk to server (stubs, jndi, > etc.), but its 17M. > > Bill > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From thomas.darimont at googlemail.com Mon Aug 21 13:03:55 2017 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Mon, 21 Aug 2017 19:03:55 +0200 Subject: [keycloak-dev] remove jboss-client.jar? In-Reply-To: <8918a5b7-6ee5-d364-b925-d85b1f7172be@redhat.com> References: <8918a5b7-6ee5-d364-b925-d85b1f7172be@redhat.com> Message-ID: Hello, One thing to note is that one needs the jboss-client.jar to access wildfly via jmx remotely. http://www.mastertheboss.com/jboss-server/wildfly-8/monitoring-wildfly-using-visualvm At least that was the only way I could get it to work. Cheers, Thomas Am 21.08.2017 6:22 nachm. schrieb "Stan Silvert" : We could also think about getting rid of jboss-cli-client.jar. It's not used by jboss-cli.sh when you are running from /bin. It is copied to a remote box when someone wants to use jboss-cli.sh remotely. Removing it would save another 7M. On 8/21/2017 10:05 AM, Bill Burke wrote: > FYI, > > Our distro is 17M bigger because we include jboss.client.jar. This jar > is uber jar by Java clients that want to talk to server (stubs, jndi, > etc.), but its 17M. > > Bill > > _______________________________________________ > 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 Aug 22 00:21:31 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Tue, 22 Aug 2017 06:21:31 +0200 Subject: [keycloak-dev] remove jboss-client.jar? In-Reply-To: References: <8918a5b7-6ee5-d364-b925-d85b1f7172be@redhat.com> Message-ID: If jboss-client.jar is used for JMX I guess we'll need to keep it. Unless there's an alternative way to do that. I find it strange that a jar is needed for a JMX connection. jboss-cli-client.jar should probably be kept as well in case some folks wants to use jboss-cli remotely (which I can imagine some would?). On 21 August 2017 at 19:03, Thomas Darimont wrote: > Hello, > > One thing to note is that one needs the jboss-client.jar to access wildfly > via jmx remotely. > http://www.mastertheboss.com/jboss-server/wildfly-8/ > monitoring-wildfly-using-visualvm > > At least that was the only way I could get it to work. > > Cheers, > Thomas > > > Am 21.08.2017 6:22 nachm. schrieb "Stan Silvert" : > > We could also think about getting rid of jboss-cli-client.jar. It's not > used by jboss-cli.sh when you are running from /bin. It is copied to a > remote box when someone wants to use jboss-cli.sh remotely. Removing > it would save another 7M. > > On 8/21/2017 10:05 AM, Bill Burke wrote: > > FYI, > > > > Our distro is 17M bigger because we include jboss.client.jar. This jar > > is uber jar by Java clients that want to talk to server (stubs, jndi, > > etc.), but its 17M. > > > > Bill > > > > _______________________________________________ > > 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 bburke at redhat.com Tue Aug 22 10:57:30 2017 From: bburke at redhat.com (Bill Burke) Date: Tue, 22 Aug 2017 10:57:30 -0400 Subject: [keycloak-dev] remove jboss-client.jar? In-Reply-To: References: <8918a5b7-6ee5-d364-b925-d85b1f7172be@redhat.com> Message-ID: <670df0b7-6c5b-e2d7-44ad-fa93a2e3d5c6@redhat.com> Why can't you use jconsole?? That only uses jboss-cli-client.jar as far as I can tell. On 8/22/17 12:21 AM, Stian Thorgersen wrote: > If jboss-client.jar is used for JMX I guess we'll need to keep it. Unless > there's an alternative way to do that. I find it strange that a jar is > needed for a JMX connection. > > jboss-cli-client.jar should probably be kept as well in case some folks > wants to use jboss-cli remotely (which I can imagine some would?). > > On 21 August 2017 at 19:03, Thomas Darimont > wrote: > >> Hello, >> >> One thing to note is that one needs the jboss-client.jar to access wildfly >> via jmx remotely. >> http://www.mastertheboss.com/jboss-server/wildfly-8/ >> monitoring-wildfly-using-visualvm >> >> At least that was the only way I could get it to work. >> >> Cheers, >> Thomas >> >> >> Am 21.08.2017 6:22 nachm. schrieb "Stan Silvert" : >> >> We could also think about getting rid of jboss-cli-client.jar. It's not >> used by jboss-cli.sh when you are running from /bin. It is copied to a >> remote box when someone wants to use jboss-cli.sh remotely. Removing >> it would save another 7M. >> >> On 8/21/2017 10:05 AM, Bill Burke wrote: >>> FYI, >>> >>> Our distro is 17M bigger because we include jboss.client.jar. This jar >>> is uber jar by Java clients that want to talk to server (stubs, jndi, >>> etc.), but its 17M. >>> >>> Bill >>> >>> _______________________________________________ >>> 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 >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From ssilvert at redhat.com Tue Aug 22 12:17:44 2017 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 22 Aug 2017 12:17:44 -0400 Subject: [keycloak-dev] remove jboss-client.jar? In-Reply-To: <670df0b7-6c5b-e2d7-44ad-fa93a2e3d5c6@redhat.com> References: <8918a5b7-6ee5-d364-b925-d85b1f7172be@redhat.com> <670df0b7-6c5b-e2d7-44ad-fa93a2e3d5c6@redhat.com> Message-ID: <45378611-0a5a-19cd-faf3-fc3be799bff4@redhat.com> On 8/22/2017 10:57 AM, Bill Burke wrote: > Why can't you use jconsole? That only uses jboss-cli-client.jar as far > as I can tell. You don't even need that unless you want it. When you combine jconsole with jboss-cli-client.jar you get jconsole with embedded CLI GUI. But it's not required if you only want jconsole for jmx. We also have the option of making these jars into an individual download or tell customers to get them from Maven. How much of a benefit do we get by slimming down the Keycloak server? > > > On 8/22/17 12:21 AM, Stian Thorgersen wrote: >> If jboss-client.jar is used for JMX I guess we'll need to keep it. Unless >> there's an alternative way to do that. I find it strange that a jar is >> needed for a JMX connection. >> >> jboss-cli-client.jar should probably be kept as well in case some folks >> wants to use jboss-cli remotely (which I can imagine some would?). >> >> On 21 August 2017 at 19:03, Thomas Darimont >> wrote: >> >>> Hello, >>> >>> One thing to note is that one needs the jboss-client.jar to access wildfly >>> via jmx remotely. >>> http://www.mastertheboss.com/jboss-server/wildfly-8/ >>> monitoring-wildfly-using-visualvm >>> >>> At least that was the only way I could get it to work. >>> >>> Cheers, >>> Thomas >>> >>> >>> Am 21.08.2017 6:22 nachm. schrieb "Stan Silvert" : >>> >>> We could also think about getting rid of jboss-cli-client.jar. It's not >>> used by jboss-cli.sh when you are running from /bin. It is copied to a >>> remote box when someone wants to use jboss-cli.sh remotely. Removing >>> it would save another 7M. >>> >>> On 8/21/2017 10:05 AM, Bill Burke wrote: >>>> FYI, >>>> >>>> Our distro is 17M bigger because we include jboss.client.jar. This jar >>>> is uber jar by Java clients that want to talk to server (stubs, jndi, >>>> etc.), but its 17M. >>>> >>>> Bill >>>> >>>> _______________________________________________ >>>> 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 >>> >> _______________________________________________ >> 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 Aug 23 02:27:10 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 23 Aug 2017 08:27:10 +0200 Subject: [keycloak-dev] Big changes coming to docs Message-ID: As part of unifying Keycloak and RH-SSO documentation we are moving away from Gitbook soon and will use pure AsciiDoctor to build the Keycloak documentation. This will be done after Keycloak 3.3 is released and there will be a period of 1-2 weeks where I don't want anyone to make any changes to the documentation while this work is in progress. So get your docs changes in before 3.3. If they're not there in time hold off until I give the OK. If you make edits to the docs in your own fork you will not easily be able to merge it to the repository after these changes and you will most likely have to re-edit the docs. From mposolda at redhat.com Wed Aug 23 03:50:12 2017 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 23 Aug 2017 09:50:12 +0200 Subject: [keycloak-dev] Adding notBefore to user? In-Reply-To: <33c2d1b5-8028-82de-0145-1850f78c849b@redhat.com> References: <5e3fd697-c004-1b4d-eca6-aae9e7833b3e@redhat.com> <45e6831f-3ca7-5b46-4b41-69be08259c00@redhat.com> <33c2d1b5-8028-82de-0145-1850f78c849b@redhat.com> Message-ID: Thanks for the confirm. Finally added that. Marek On 09/08/17 20:20, Bill Burke wrote: > I think that works then what you are proposing. > > > On 8/9/17 11:08 AM, Marek Posolda wrote: >> I am thinking that logout of single concrete session won't update >> notBefore. Just "Logout all sessions" for concrete user will update >> it for this user. I assume that admin or user usually use "Logout >> all" if he thinks that something was broken (password compromised, >> mobile phone steal etc)? >> >> BTV. Admin console has support for logout of single session as well >> as logout all. However account management has support just for >> "logout all" ATM. Maybe something useful to add? >> >> Marek >> >> On 09/08/17 16:08, Bill Burke wrote: >>> What if the user has multiple sessions and only wants to log out of >>> one? >>> >>> >>> On 8/9/17 6:12 AM, Marek Posolda wrote: >>>> I am thinking about adding notBefore to user. It will be updated when >>>> user logouts in Account management or when admin logouts user in admin >>>> console. >>>> >>>> I am thinking about this because in cross-dc environment, it can >>>> happen >>>> under some circumstances that particular userSession "123" is not >>>> available in infinispan cache on any Keycloak server, however it's >>>> available on the remoteCache on JDG server. So it can happen that: >>>> - Admin press "Logout all sessions", but session 123 won't be affected >>>> as it's available just on remoteCache >>>> - Someone (attacker) sends refresh token for session 123. It will be >>>> loaded from remoteCache store to Keycloak cache and will be treated as >>>> valid session. >>>> >>>> Do you think it's bad idea to add notBefore to user? There may be some >>>> other ways to mitigate the issue if you think it's bad. >>>> >>>> I am thinking about adding it to separate table, so it's persistent >>>> among server restarts even for users from federated user storages. >>>> Something similar to like consents are saved. WDYT? >>>> >>>> Marek >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> > From takashi.norimatsu.ws at hitachi.com Sun Aug 27 22:06:00 2017 From: takashi.norimatsu.ws at hitachi.com (=?utf-8?B?5LmX5p2+6ZqG5b+XIC8gTk9SSU1BVFNV77yMVEFLQVNISQ==?=) Date: Mon, 28 Aug 2017 02:06:00 +0000 Subject: [keycloak-dev] Proposal of using existing authentication and authorization server on behalf of keycloak browser-based authentication In-Reply-To: References: <831D472326678942A9B4BB933AAA103D68CA8DDB@GSjpTK1DCembx01.service.hitachi.net> <831D472326678942A9B4BB933AAA103D68CB9260@GSjpTK1DCembx02.service.hitachi.net> <831D472326678942A9B4BB933AAA103D68CB9AC0@GSjpTK1DCembx02.service.hitachi.net> <831D472326678942A9B4BB933AAA103D68CB9B5D@GSjpTK1DCembx02.service.hitachi.net> Message-ID: <831D472326678942A9B4BB933AAA103D68CC8CB6@GSjpTK1DCembx02.service.hitachi.net> Thank you for your comments. We've found that the custom protocol implementation is not appropriate by considering security aspect. Also, based on your advice, we've decided to implement on our existing authentication server minimum OIDC OP functionalities for Identity Brokering using keycloak's core libraries. Regards Takashi Norimatsu --- From: Stian Thorgersen [mailto:sthorger at redhat.com] Sent: Thursday, August 17, 2017 3:54 PM To: ???? / NORIMATSU?TAKASHI Cc: keycloak-dev at lists.jboss.org Subject: [!]Re: Re: Re: [keycloak-dev] Proposal of using existing authentication and authorization server on behalf of keycloak browser-based authentication OK, I finally understand exactly what you want to contribute, but afraid we'll have to reject it. We can not accept and maintain a custom protocol for many reasons, including: * It's a lot of work to maintain * It needs documenting and understanding by users * It's just a slightly different way to doing things than OIDC. In fact for Identity Brokering there's not that much you need to implement the OIDC part in the IdP * It could contain security vulnerabilities On 17 August 2017 at 08:47, ???? / NORIMATSU?TAKASHI wrote: Hello. >So rather than using standard protocols (OIDC or SAML) you've come up with your own custom protocol that folks would have to implement instead? Yes, but much easier for people than using OIDC/SAML. If OIDC is used for the existing authentication server, following OIDC OP functions would have to be implemented. ? - Authz Code Flow (at least) ? - Authz Code management ? - ID Token/Access Token management ? - JWT ? - JWS ? - key management for JWT Instead, if supporting the simplified protocol such the one I have proposed, only following would have to be implemented ? - Issue temporal opaque ticket ? - Send authenticated user info in return to this ticket Regards Takashi Norimatsu -----Original Message----- From: ???? / NORIMATSU?TAKASHI Sent: Thursday, August 17, 2017 11:24 AM To: 'stian at redhat.com' Cc: 'keycloak-dev at lists.jboss.org' Subject: RE: [!]Re: Re: [keycloak-dev] Proposal of using existing authentication and authorization server on behalf of keycloak browser-based authentication We do NOT intend to propose a "custom"(customer specific) brokering protocol, are proposing a simplified brokering procedure for an external authentication server without implementing OIDC/SAML. This is useful for users who have their existing authentication server. They had to implement OIDC/SAML(very hard) or had to design and implement another procedure(is also not easy). By the proposal, they can integrate their authentication server easily. For example, UMA standard for authorization service is proposed, but seems to be complicated, so keycloak has simplified procedure(entitlement API). Feature is different but situation is the same (simplified OIDC/SAML). ---------- From: Stian Thorgersen [mailto:sthorger at redhat.com] Sent: Tuesday, August 15, 2017 4:49 PM To: ???? / NORIMATSU?TAKASHI Cc: keycloak-dev at lists.jboss.org Subject: [!]Re: Re: [keycloak-dev] Proposal of using existing authentication and authorization server on behalf of keycloak browser-based authentication Afraid I still don't understand what you are trying to contribute to Keycloak. As I said we already allow creating custom identity providers using whatever protocol you want. We can't accept contribution of a custom identity provider which is seems is what you are trying to contribute. On 15 August 2017 at 08:58, ???? / NORIMATSU?TAKASHI wrote: > I'm not really following what you are proposing to contribute to Keycloak. Thank you for comment. This contribution to keycloak is that to enhance competitiveness with proprietary products. In some market, customers have highly customized Web UI for authentication. (e.g. soft keyboard, responsive web design, very sophisticated look and feel). They want to use Authorization server product (such as keycloak) implementing OpenID Connect for securing the customer's API. They want to use existing highly customized authentication server, but do not want to implement OpenID Connect on this authentication server (too much complex and difficult to implement). To meet such needs, proprietary products have the following solution. Proprietary authorization server products have their own procedure (much simpler than OpenID Connect and SAMLv2) to communicate with existing authentication server as below: https://communities.ca.com/blogs/oauth/2016/10/04/howto-integrating-otk-with-external-login-server?et=notification.send https://www.ibm.com/support/knowledgecenter/en/SSMNED_5.0.0/com.ibm.apic.toolkit.doc/tapim_sec_api_config_scheme_oauth_endpoint.html In customer's existing authentication server, customers only have to implement communication with the authorization server according to the procedure prepared by the authorization server product (It is much easier than implementing OpenID Connect or SAMLv2). Customers do not have to implement anything in authorization server side. On the other hand, if keycloak is used, customers have to do following: a) In authorization server (RH SSO), simple procedure to communicate with external authentication server have to be designed and implemented using SPI. b) In customer's existing authentication server, implement procedure prepared by a). -> In proprietary products, a) is prepared, but keycloak is not. Our proposed patch is intended to complement a). --- From: Stian Thorgersen [mailto:sthorger at redhat.com] Sent: Monday, August 14, 2017 7:57 PM To: ???? / NORIMATSU?TAKASHI Cc: keycloak-dev at lists.jboss.org Subject: [!]Re: [keycloak-dev] Proposal of using existing authentication and authorization server on behalf of keycloak browser-based authentication I'm not really following what you are proposing to contribute to Keycloak. We already have the SPI that allows adding a custom provider if your IdP doesn't support SAML or OpenID Connect. On 31 July 2017 at 06:09, ???? / NORIMATSU?TAKASHI wrote: Hello. Previously, I had proposed the feature and its implementation of delegating authentication and authorization to an external existing server on behalf of keycloak's browser-based authentication mechanism, and had gotten advices that it is appropriate to use Identity Brokering for such the feature. I've re-implemented this feature again by Identity Brokering. The description and implementation of this feature is mentioned below. https://github.com/Hitachi/PoV-keycloak-delegate-authn-consent https://github.com/Hitachi/PoV-keycloak-delegate-authn-consent/tree/master/src/keycloak/examples/providers/delegate-authn-consent It can delegate not only authentication but authorization(consent). Kindly review it and provide us some comment and advices. We would like to contribute this feature onto keycloak. Best Regards Takashi Norimatsu Hitachi, Ltd. --- From: Stian Thorgersen [mailto:sthorger at redhat.com] Sent: Thursday, June 29, 2017 6:23 PM To: ???? / NORIMATSU?TAKASHI Cc: keycloak-dev at lists.jboss.org Subject: [!]Re: [keycloak-dev] Proposal of using existing authentication server on behalf of keycloak browser-based authentication There's an SPI to implement your own custom identity brokering provider [1]. [1]?https://github.com/keycloak/keycloak/blob/master/server-spi-private/src/main/java/org/keycloak/broker/provider/IdentityProvider.java On 29 June 2017 at 10:51, ???? / NORIMATSU?TAKASHI wrote: I need to use the authentication server without OIDC/OAuth2/SAMLv2 implementation as an external IdP, in order to integrate existing authentication system. (some commercial products supports such the case) I consulted identity broker's section in keycloak's manual below and found that if I use this feature the external IdP must support OIDC or SAMLv2. https://keycloak.gitbooks.io/documentation/server_admin/topics/identity-broker.html Therefore, I realized it by using redirect based authentication flows. Can identity Brokering can support such the case? Aside from this, I'd like to contribute it to Community extensions and examples. Best Regards Takashi Norimatsu Hitachi, Ltd. --- From: Stian Thorgersen [mailto:sthorger at redhat.com] Sent: Tuesday, June 27, 2017 5:52 PM To: ???? / NORIMATSU?TAKASHI Cc: keycloak-dev at lists.jboss.org Subject: [!]Re: [keycloak-dev] Proposal of using existing authentication server on behalf of keycloak browser-based authentication I'm not in favour of adding this. If it's using redirect based authentication flows it should be done through identity brokering, not authentication flows. It's also a very complex example that we don't want to maintain. We've also in the process of moving all examples away from the main Keycloak repository into a separate quickstart repository. On 27 June 2017 at 08:54, ???? / NORIMATSU?TAKASHI wrote: Hello. Previously, I had proposed the feature of delegating authentication to an external authentication server on behalf of keycloak's browser-based authentication mechanism. I've integrated this feature to keycloak's "examples" packages and send PR (https://github.com/keycloak/keycloak/pull/4260). Hope this PR is reviewed and merged as an example for combining some providers to customize keycloak. Detailed description of this feature is mentioned below. https://github.com/Hitachi/PoV-keycloak-authentication-delegation I am now engaging in integrating this feature to keycloak as product-base default providers, but encounter technical problems about writing arquillian. Would someone tell me how to resolve this problem? [Problem] - I could not find how to run an external authentication server(application running on wildfly 10) during each arquillian test cases. After resolving this problem and writing and running arquillian test cases, I'll send PR for this feature as product-base default providers. Best Regards Takashi Norimatsu Hitachi, Ltd. _______________________________________________ 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 Mon Aug 28 09:49:00 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 28 Aug 2017 15:49:00 +0200 Subject: [keycloak-dev] Docs frozen! Message-ID: Do not make edits to the documentation! We are making big changes to the docs moving away from GitBook to pure AsciiDoctor. As part of that all documentation sources will be converted and any edits will be lost and any changes you have in a clone will most likely be a pain to merge. It'll take a few days and I'll let you all know when it's ready! From mstrukel at redhat.com Mon Aug 28 09:57:20 2017 From: mstrukel at redhat.com (Marko Strukelj) Date: Mon, 28 Aug 2017 15:57:20 +0200 Subject: [keycloak-dev] Change in enabling / disabling features Message-ID: This is a heads up about an upcoming change in how to enable or disable features in Keycloak. Keycloak has a notion of features, which makes it possible to disable certain functionality that is enabled by default, or enable certain functionality that is disabled by default. There are four sets of functionality you can enable or disable as features: impersonation, script, authorization, and docker. See [1] for more info. Currently a file called profile.properties can be used to enable / disable features, or system properties can be used, which override any configuration inside profile.properties as explained in [1]. This is an aberration from how other configuration is specified on the server via standalone.xml. Also, the reason config file is called profile.properties, and not features.properties is because the set of enabled/disabled features is different for upstream project (where all but 'docker' are enabled), for product based on Keycloak - RHSSO (where only 'impersonation' is enabled), and for technology preview versions of RHSSO. This additionally complicates things. The idea is to simplify that and remove the notion of profiles, stop using profile.properties, and move all configuration to standalone.xml where all the available features will be listed with default values: ... ... This is how configuration would look like in Keycloak distribution. In product distributions different features would be enabled / disabled - no more named profiles. However, in order to allow system properties override the idea is to do it slightly differently: We should probably also facilitate transition for current deployments, and take old style system properties into account if they are used - converting them to the new ones before configuration is applied. Deprecated: -Dkeycloak.profile.feature.impersonation=enabled New style: -Dkeycloak.feature.impersonation=true We don't want to keep support for this indefinitely (maybe for one minor version?) so if use of deprecated system properties is detected a warning will be logged. Also, Stian proposed that features not considered stable yet, should carry a suffix '-preview' in the name. So the actual feature name, and system property name may still change for some features. You can follow progress on JIRA issue [2]. - [1] https://keycloak.gitbooks.io/documentation/server_installation/topics/profiles.html [2] https://issues.jboss.org/browse/KEYCLOAK-4994 From sthorger at redhat.com Mon Aug 28 12:41:08 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Mon, 28 Aug 2017 18:41:08 +0200 Subject: [keycloak-dev] Keycloak 3.3.0.CR1 Released Message-ID: We've just released Keycloak 3.3.0.CR1. To download the release go to the Keycloak homepage . HighlightsUpgraded to WildFly 11 CR1 We've upgraded the underlying container to WildFly 11 CR1. Cross DC Support We've done loads of work to support multiple data centers. It's not 100% completed yet, but we'd love it if folks could give it a go and let us know what works well and what doesn't. There will be a blog post soon on how to try this out. More Social We've added support for social login with BitBucket and Gitlab.com. Loads more.. - Dutch translation - thanks to gedejong and Jacob van Lingen - Pass login_hint to identity brokers - thanks to dmnboutin The full list of resolved issues is available in JIRA . Upgrading Before you upgrade remember to backup your database and check the migration guide . Release candidates are not recommended in production and we do not support upgrading from release candidates. From thomas.darimont at googlemail.com Mon Aug 28 20:10:56 2017 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Tue, 29 Aug 2017 02:10:56 +0200 Subject: [keycloak-dev] Proposal for merging user accounts in Keycloak Message-ID: When integrating multiple legacy systems one often finds that a particular user has multiple user accounts. In such scenarios it would be helpful if users could consolidate their user accounts themselves by merging some of them into one. Currently Keycloak doesn't have an official way to merge two existing user accounts. Since I'm currently facing this in a project I thought a bit about how this could be solved in Keycloak. Keycloak could provide a dedicated "merge" sub-page in the account application, e.g. account/merge. There a authenticated user1 could select the account he likes to merge with and verify the ownership of this account. If the ownership could be verified successfully the user1 would be asked for a final merge confirmation. If the user1 confirms the merge then the selected user account (user2) would be merged into the currently logged-in user account (user1). Some logic would then need to decide how to merge the selected user2 into the currently logged-in user1, e.g. by assining roles and / or consents and potentially copy over some user profile values. The account for user2 would then either be marked as merged or deleted. Login with user2 is no longer possible from this point on. This could be supported by a dedicated "user account merge" SPI that could decide whether two accounts can be merged, how the merge is performed and what user information will be merged. This would enable great flexibility and help quite a lot to ease integration of legacy systems. Finally after a successful merge a USER_ACCOUNT_MERGED event with some metadata (about user1, user2 etc.) would be fired to notify other systems about the user account merger. Here are the steps in some more detail: # Authentication 0) Unauthenticated user1 goes to the /account/merge page and gets redirected to the login page. 1) User1 authenticates and gets redirected back to /account/merge # Account Selection / Verification 2) User1 selects an account to merge with, e.g. user2 and verfies ownership E.g. by showing an embedded login form and ask for Username + Password + 2nd Factor if present # Merge 3) Merge the user account 3.0) Ask user whether accounts should be merged (account of user1 will become the remaining / leading account). This is irreversible! 3.1) Avoid account modification for user2 during merge, e.g. deactivate the old user (user2) 3.2) Record some information about the merged user Perhaphs via user attributes or maintain an explicit list of merged users. # Decide what should be merged A built-in logic and / or the user decides what should be merged. 3.4) User Profile information (e.g. complete incomplete fields? E.g. firstname, lastname, mobile, etc.) 3.5) Grant all roles of user2 to user1 3.6) Grant all consents of user2 to user1 3.7) Grant all group memberships of user2 to user1 Credentials of user2 would be ignored. # Conclude the merge 4) Mark user2 as merged or delete user 2 Delete user2 or rename user2 and change email to be able to use that information for user1. 4.1) Propagate user account merge as event Propagate a USER_ACCOUNT_MERGED event via the EventListener infrastructure. The event should contain at least the userId of user1, and the userId of user2 and tells which is now the leading account. This enables downstream systems to get notified about the account merge. WDYT? Cheers, Thomas From thomas.darimont at googlemail.com Tue Aug 29 09:53:59 2017 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Tue, 29 Aug 2017 15:53:59 +0200 Subject: [keycloak-dev] Proposal for merging user accounts in Keycloak In-Reply-To: References: Message-ID: As a quick follow up, I implemented a working PoC for merging user accounts in the following branch: https://github.com/thomasdarimont/keycloak/tree/issue/KEYCLOAK-XXX-merge-user-accounts Cheers, Thomas 2017-08-29 2:10 GMT+02:00 Thomas Darimont : > When integrating multiple legacy systems one often finds that a particular > user > has multiple user accounts. In such scenarios it would be helpful if users > could consolidate their user accounts themselves by merging some of them > into one. > > Currently Keycloak doesn't have an official way to merge two existing user > accounts. > > Since I'm currently facing this in a project I thought a bit about how > this could > be solved in Keycloak. > > Keycloak could provide a dedicated "merge" sub-page in the account > application, > e.g. account/merge. There a authenticated user1 could select the account > he likes > to merge with and verify the ownership of this account. > > If the ownership could be verified successfully the user1 would be asked > for a > final merge confirmation. If the user1 confirms the merge then the > selected user > account (user2) would be merged into the currently logged-in user account > (user1). > > Some logic would then need to decide how to merge the selected user2 into > the > currently logged-in user1, e.g. by assining roles and / or consents and > potentially > copy over some user profile values. > > The account for user2 would then either be marked as merged or deleted. > Login with > user2 is no longer possible from this point on. > > This could be supported by a dedicated "user account merge" SPI that could > decide > whether two accounts can be merged, how the merge is performed and what > user information > will be merged. This would enable great flexibility and help quite a lot > to > ease integration of legacy systems. > > Finally after a successful merge a USER_ACCOUNT_MERGED event with some > metadata > (about user1, user2 etc.) would be fired to notify other systems about the > user account merger. > > Here are the steps in some more detail: > > # Authentication > 0) Unauthenticated user1 goes to the /account/merge page and gets > redirected > to the login page. > > 1) User1 authenticates and gets redirected back to /account/merge > > # Account Selection / Verification > 2) User1 selects an account to merge with, e.g. user2 and verfies ownership > E.g. by showing an embedded login form and ask for Username + Password + > 2nd Factor > if present > > # Merge > 3) Merge the user account > 3.0) Ask user whether accounts should be merged (account of user1 will > become > the remaining / leading account). This is irreversible! > 3.1) Avoid account modification for user2 during merge, e.g. deactivate > the > old user (user2) > 3.2) Record some information about the merged user > Perhaphs via user attributes or maintain an explicit list of merged users. > > # Decide what should be merged > A built-in logic and / or the user decides what should be merged. > 3.4) User Profile information (e.g. complete incomplete fields? > E.g. firstname, lastname, mobile, etc.) > 3.5) Grant all roles of user2 to user1 > 3.6) Grant all consents of user2 to user1 > 3.7) Grant all group memberships of user2 to user1 > Credentials of user2 would be ignored. > > # Conclude the merge > 4) Mark user2 as merged or delete user 2 > Delete user2 or rename user2 and change email to be able to use that > information for user1. > 4.1) Propagate user account merge as event > Propagate a USER_ACCOUNT_MERGED event via the EventListener infrastructure. > The event should contain at least the userId of user1, and the userId of > user2 and > tells which is now the leading account. This enables downstream systems to > get notified > about the account merge. > > WDYT? > > Cheers, > Thomas > From sthorger at redhat.com Wed Aug 30 02:01:24 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 30 Aug 2017 08:01:24 +0200 Subject: [keycloak-dev] Renaming testsuite/integration to testsuite/integration-deprecated In-Reply-To: References: Message-ID: The old testsuite has now been renamed to testsuite-integration. KeycloakServer, MailServer and TotpGenerator was moved to testsuite/utils. On 3 July 2017 at 04:42, Stian Thorgersen wrote: > That'll still be there. Eventually when all the old tests are migrated > it'll be moved to a new tools utils module or something. We're not getting > rid of it though. > > On 30 June 2017 at 21:03, Thomas Darimont > wrote: > >> Will it still be possible to use the embedded KeycloakServer for testing? >> >> I use this a lot for quickly trying out new Keycloak extensions / >> customizations. >> >> Cheers, >> Thomas >> >> 2017-06-30 14:51 GMT+02:00 Stian Thorgersen : >> >>> Unless someone objects I'm going start by renaming testsuite/integration >>> to >>> testsuite/integration-deprecated. Created JIRA >>> https://issues.jboss.org/browse/KEYCLOAK-5123. Last chance to complain. >>> >>> On 8 June 2017 at 08:27, Stian Thorgersen wrote: >>> >>> > I would like to rename testsuite/integration to >>> testsuite/integration-deprecated. >>> > This is to make it clear to external contributors that the testsuite is >>> > deprecated and new tests should be added to testsuite/integration- >>> > arquillian. >>> > >>> > I would also like to rename testsuite/integration-arquillian >>> > to testsuite/integration. >>> > >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> > From sthorger at redhat.com Wed Aug 30 02:14:45 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 30 Aug 2017 08:14:45 +0200 Subject: [keycloak-dev] Docs ready again Message-ID: Docs are now ready for changes again after the recent restructuring. It's now all pure AsciiDoctor and we will no longer use GitBook. Check out the README.md in the repo for instructions on how to build: https://github.com/keycloak/keycloak-documentation/blob/master/README.md Editing the docs is pretty much the same as before, but you don't need to do the hacks with links and images anymore. All features from asciidoctor should now work as well. From sthorger at redhat.com Wed Aug 30 02:28:50 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 30 Aug 2017 08:28:50 +0200 Subject: [keycloak-dev] Change in enabling / disabling features In-Reply-To: References: Message-ID: In standalone.xml I'd use "feature.scripts" sys properties instead of the longer "keycloak.feature.scripts". It's just shorter and simpler and won't cause any conflicts. We need to support the old "keycloak.profile.feature.=enabled|disabled" as is, including if set in profile.properties. This is important in case customers have explicitly disabled impersonation for example. +1 To printing a warning in this case. Then let's remove the old deprecated properties in Keycloak 3.5x as well as the profile.properties. On 28 August 2017 at 15:57, Marko Strukelj wrote: > This is a heads up about an upcoming change in how to enable or disable > features in Keycloak. > > Keycloak has a notion of features, which makes it possible to disable > certain functionality that is enabled by default, or enable certain > functionality that is disabled by default. > > There are four sets of functionality you can enable or disable as features: > impersonation, script, authorization, and docker. See [1] for more info. > > Currently a file called profile.properties can be used to enable / disable > features, or system properties can be used, which override any > configuration inside profile.properties as explained in [1]. > > This is an aberration from how other configuration is specified on the > server via standalone.xml. > > Also, the reason config file is called profile.properties, and not > features.properties is because the set of enabled/disabled features is > different for upstream project (where all but 'docker' are enabled), for > product based on Keycloak - RHSSO (where only 'impersonation' is enabled), > and for technology preview versions of RHSSO. > > This additionally complicates things. The idea is to simplify that and > remove the notion of profiles, stop using profile.properties, and move all > configuration to standalone.xml where all the available features will be > listed with default values: > > > > ... > > > > > > > > > ... > > > > This is how configuration would look like in Keycloak distribution. In > product distributions different features would be enabled / disabled - no > more named profiles. > > However, in order to allow system properties override the idea is to do it > slightly differently: > > > enabled="${keycloak.feature.authorization:true}" /> > enabled="${keycloak.feature.impersonation:true}" /> > > > > > > We should probably also facilitate transition for current deployments, and > take old style system properties into account if they are used - converting > them to the new ones before configuration is applied. > > Deprecated: -Dkeycloak.profile.feature.impersonation=enabled > New style: -Dkeycloak.feature.impersonation=true > > We don't want to keep support for this indefinitely (maybe for one minor > version?) so if use of deprecated system properties is detected a warning > will be logged. > > Also, Stian proposed that features not considered stable yet, should carry > a suffix '-preview' in the name. So the actual feature name, and system > property name may still change for some features. > > You can follow progress on JIRA issue [2]. > > - > > [1] > https://keycloak.gitbooks.io/documentation/server_ > installation/topics/profiles.html > [2] https://issues.jboss.org/browse/KEYCLOAK-4994 > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From sthorger at redhat.com Wed Aug 30 02:50:49 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Wed, 30 Aug 2017 08:50:49 +0200 Subject: [keycloak-dev] Proposal for merging user accounts in Keycloak In-Reply-To: References: Message-ID: Would be nice to have, but I'm worried about how complex it would end up being. It would have to leverage regular login pages and flows as otherwise it'd just be way to complex. We're also working on a new account management console that is HTML5 and uses new account management REST endpoints. Then I could see complications if the user has identity brokering links and also if the user is pulled in from an external user federation store. Would also need to be available to admins to be a complete feature. In the admin console the flow would probably be relatively simple, just open a user, click on merge tab, find the user and click merge. Might want to have some options on how to consolidate the two users there as well. In user account management console I'm not really sure. It seems that it would really be a feature that is not that commonly used, so wonder if it's best just left to admins? If available to users it should definitively be an option that has to be enabled for the realm. The user shouldn't be able to list users, but would have to provide details about the other account. That should just request the merge. To complete the merge the user should have to login as the other user and approve the merge. Afterwards the user would be logged out and able to login as the merged user. As this is a pretty big thing to add I would first want to make sure there's no-one that objects to it and as usual the PR would have to be implemented in a generic way (not just the way you want it ;)) and come complete with all tests and documentations. On 29 August 2017 at 15:53, Thomas Darimont wrote: > As a quick follow up, I implemented a working PoC for merging user accounts > in the following branch: > https://github.com/thomasdarimont/keycloak/tree/ > issue/KEYCLOAK-XXX-merge-user-accounts > > Cheers, > Thomas > > 2017-08-29 2:10 GMT+02:00 Thomas Darimont >: > > > When integrating multiple legacy systems one often finds that a > particular > > user > > has multiple user accounts. In such scenarios it would be helpful if > users > > could consolidate their user accounts themselves by merging some of them > > into one. > > > > Currently Keycloak doesn't have an official way to merge two existing > user > > accounts. > > > > Since I'm currently facing this in a project I thought a bit about how > > this could > > be solved in Keycloak. > > > > Keycloak could provide a dedicated "merge" sub-page in the account > > application, > > e.g. account/merge. There a authenticated user1 could select the account > > he likes > > to merge with and verify the ownership of this account. > > > > If the ownership could be verified successfully the user1 would be asked > > for a > > final merge confirmation. If the user1 confirms the merge then the > > selected user > > account (user2) would be merged into the currently logged-in user account > > (user1). > > > > Some logic would then need to decide how to merge the selected user2 into > > the > > currently logged-in user1, e.g. by assining roles and / or consents and > > potentially > > copy over some user profile values. > > > > The account for user2 would then either be marked as merged or deleted. > > Login with > > user2 is no longer possible from this point on. > > > > This could be supported by a dedicated "user account merge" SPI that > could > > decide > > whether two accounts can be merged, how the merge is performed and what > > user information > > will be merged. This would enable great flexibility and help quite a lot > > to > > ease integration of legacy systems. > > > > Finally after a successful merge a USER_ACCOUNT_MERGED event with some > > metadata > > (about user1, user2 etc.) would be fired to notify other systems about > the > > user account merger. > > > > Here are the steps in some more detail: > > > > # Authentication > > 0) Unauthenticated user1 goes to the /account/merge page and gets > > redirected > > to the login page. > > > > 1) User1 authenticates and gets redirected back to /account/merge > > > > # Account Selection / Verification > > 2) User1 selects an account to merge with, e.g. user2 and verfies > ownership > > E.g. by showing an embedded login form and ask for Username + Password + > > 2nd Factor > > if present > > > > # Merge > > 3) Merge the user account > > 3.0) Ask user whether accounts should be merged (account of user1 will > > become > > the remaining / leading account). This is irreversible! > > 3.1) Avoid account modification for user2 during merge, e.g. deactivate > > the > > old user (user2) > > 3.2) Record some information about the merged user > > Perhaphs via user attributes or maintain an explicit list of merged > users. > > > > # Decide what should be merged > > A built-in logic and / or the user decides what should be merged. > > 3.4) User Profile information (e.g. complete incomplete fields? > > E.g. firstname, lastname, mobile, etc.) > > 3.5) Grant all roles of user2 to user1 > > 3.6) Grant all consents of user2 to user1 > > 3.7) Grant all group memberships of user2 to user1 > > Credentials of user2 would be ignored. > > > > # Conclude the merge > > 4) Mark user2 as merged or delete user 2 > > Delete user2 or rename user2 and change email to be able to use that > > information for user1. > > 4.1) Propagate user account merge as event > > Propagate a USER_ACCOUNT_MERGED event via the EventListener > infrastructure. > > The event should contain at least the userId of user1, and the userId of > > user2 and > > tells which is now the leading account. This enables downstream systems > to > > get notified > > about the account merge. > > > > WDYT? > > > > Cheers, > > Thomas > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From matzew at apache.org Wed Aug 30 03:19:35 2017 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 30 Aug 2017 09:19:35 +0200 Subject: [keycloak-dev] Keycloak 3.3.0.CR1 Released In-Reply-To: References: Message-ID: yay! works great, just updated our dependencies :-) On Mon, Aug 28, 2017 at 6:41 PM, Stian Thorgersen wrote: > We've just released Keycloak 3.3.0.CR1. > > To download the release go to the Keycloak homepage > . > HighlightsUpgraded to WildFly 11 CR1 > > We've upgraded the underlying container to WildFly 11 CR1. > Cross DC Support > > We've done loads of work to support multiple data centers. It's not 100% > completed yet, but we'd love it if folks could give it a go and let us know > what works well and what doesn't. There will be a blog post soon on how to > try this out. > More Social > > We've added support for social login with BitBucket and Gitlab.com. > Loads more.. > > - Dutch translation - thanks to gedejong > and > Jacob van Lingen > - Pass login_hint to identity brokers - thanks to dmnboutin > > > The full list of resolved issues is available in JIRA > 20keycloak%20and%20fixVersion%20%3D%203.3.0.CR1> > . > Upgrading > > Before you upgrade remember to backup your database and check the migration > guide > MigrationFromOlderVersions.html>. > Release candidates are not recommended in production and we do not support > upgrading from release candidates. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ twitter: http://twitter.com/mwessendorf From thomas.darimont at googlemail.com Wed Aug 30 04:46:11 2017 From: thomas.darimont at googlemail.com (Thomas Darimont) Date: Wed, 30 Aug 2017 10:46:11 +0200 Subject: [keycloak-dev] Proposal for merging user accounts in Keycloak In-Reply-To: References: Message-ID: Hello Stian, thanks for the great feedback! Yes merging accounts can be quite complex as it can have many side effects. My PoC implementation is very basic and just demonstrates the idea. A complete implementation would of course span multiple areas. I agree with you that there should be a dedicated realm option "Allow Account Merge" to enable this feature. I've seen the mockups of the new account UI in JIRA - looking forward to see it in action. Some notes about the integrations you mentioned: Admin Console: I agree that this could be integrated quite easily to support the following workflow: 1. Open the user details of a user in the "users" section. 2. Click on (new) Merge tab. The merge tab shows two sections: - "User selection" where the admin can select exactly one user. - "Merge options" where the admin can configure how the merge is performed. 3. Select User 4. Select Merge Options Options could include checkboxes with descriptions, e.g. "Merge Profile", "Merge Roles", "Merge Group Memberships", "Merge federation links", "Merge user attributes" Perhaps one could also indicate whether or not values can be overridden (User Profile: etc.) 5. Perform the merge by clicking "Merge" User Account: I think the need to be able merge user accounts arises quite often in legacy integration scenarios, e.g. when multiple big and partially overlapping user bases from multiple applications are consolidated into one. Therefore I think it should be an operation that's available as self-service to users as well, users usually know their user accounts for different systems. This helps to keep support efforts small. I like your idea of a two phase user merge, first let user1 request to merge with user2. User2 needs to approve the merge. If user2 accepts his user information will be merged into user1 and user2 will be removed. I agree that the user to be merged needs to go through the complete authentication flow in order to proof account ownership. I think this could be done as follows: In the account client there would be a new page "Merge Accounts". On the "Merge Accounts" page there would be sections like "Request Account Merge", "Pending Account Merge" and potentially "Approved Account Merges". In "Request Account Merge" the currently logged in user could enter the username of the user to merge with and request the merge via a "Request Merge" button. The "Pending Account Merge" section could show the recently "Account Merge Request" with some additional information about the user who send the merge request (username, e-mail, firstname, lastname) and some metadata datetime, IP-Address?, etc. Here the user has now the option to "Cancel" or "Accept" the "Account Merge request". The "Approved Merge Requests" is optional and could just show a list of accepted "Account merge requests". Example workflow (happy path) for merging the user account user2 into the leading user account user1. User1 1. User1 logs into the the account application and goes to the "Merge Accounts". 2. User1 would then select a user (user2) and click on "Request Merge". This would register a "Account Merge Request" for the user2. If user2 has an email address configured he would be notified via email with a link to the "Merge Account" page. If the user doesn't have an email there could be a RequiredAction added to user2 to send the user to the "Merge Account" page on next browser login. User2 1. User2 logs into the the account application and goes to the "Merge Accounts", either by clicking on the link in the email or redirected by the required action. 2. The user sees the pending Account Merge request and clicks on "Accept". 3. A confirmation prompt is shown to the user indicating that this operation is irreversible and that his account will be removed after the merge with the account of user1. 4. User confirms the merge and is logged out. Now user1 can re-login and (potentially) sees the merged user information of user2, e.g by visiting the "Merge Account" page and see the "Approved" merge request in the "Approved Merge Requests" section. This workflow would go through the complete authentication flow for both users including all custom authenticators. As shown in my PoC, accepting a merge fires an ACCOUNT_MERGED event to notify other other parties about the merge. When user federation is involved it might be a bit more tricky, as the merge operation might need to be propagated through the federation provider explicitly. Cheers, Thomas 2017-08-30 8:50 GMT+02:00 Stian Thorgersen : > Would be nice to have, but I'm worried about how complex it would end up > being. It would have to leverage regular login pages and flows as otherwise > it'd just be way to complex. We're also working on a new account management > console that is HTML5 and uses new account management REST endpoints. Then > I could see complications if the user has identity brokering links and also > if the user is pulled in from an external user federation store. Would also > need to be available to admins to be a complete feature. > > In the admin console the flow would probably be relatively simple, just > open a user, click on merge tab, find the user and click merge. Might want > to have some options on how to consolidate the two users there as well. > > In user account management console I'm not really sure. It seems that it > would really be a feature that is not that commonly used, so wonder if it's > best just left to admins? If available to users it should definitively be > an option that has to be enabled for the realm. The user shouldn't be able > to list users, but would have to provide details about the other account. > That should just request the merge. To complete the merge the user should > have to login as the other user and approve the merge. Afterwards the user > would be logged out and able to login as the merged user. > > As this is a pretty big thing to add I would first want to make sure > there's no-one that objects to it and as usual the PR would have to be > implemented in a generic way (not just the way you want it ;)) and come > complete with all tests and documentations. > > On 29 August 2017 at 15:53, Thomas Darimont com> wrote: > >> As a quick follow up, I implemented a working PoC for merging user >> accounts >> in the following branch: >> https://github.com/thomasdarimont/keycloak/tree/issue/ >> KEYCLOAK-XXX-merge-user-accounts >> >> Cheers, >> Thomas >> >> 2017-08-29 2:10 GMT+02:00 Thomas Darimont > >: >> >> > When integrating multiple legacy systems one often finds that a >> particular >> > user >> > has multiple user accounts. In such scenarios it would be helpful if >> users >> > could consolidate their user accounts themselves by merging some of them >> > into one. >> > >> > Currently Keycloak doesn't have an official way to merge two existing >> user >> > accounts. >> > >> > Since I'm currently facing this in a project I thought a bit about how >> > this could >> > be solved in Keycloak. >> > >> > Keycloak could provide a dedicated "merge" sub-page in the account >> > application, >> > e.g. account/merge. There a authenticated user1 could select the account >> > he likes >> > to merge with and verify the ownership of this account. >> > >> > If the ownership could be verified successfully the user1 would be asked >> > for a >> > final merge confirmation. If the user1 confirms the merge then the >> > selected user >> > account (user2) would be merged into the currently logged-in user >> account >> > (user1). >> > >> > Some logic would then need to decide how to merge the selected user2 >> into >> > the >> > currently logged-in user1, e.g. by assining roles and / or consents and >> > potentially >> > copy over some user profile values. >> > >> > The account for user2 would then either be marked as merged or deleted. >> > Login with >> > user2 is no longer possible from this point on. >> > >> > This could be supported by a dedicated "user account merge" SPI that >> could >> > decide >> > whether two accounts can be merged, how the merge is performed and what >> > user information >> > will be merged. This would enable great flexibility and help quite a lot >> > to >> > ease integration of legacy systems. >> > >> > Finally after a successful merge a USER_ACCOUNT_MERGED event with some >> > metadata >> > (about user1, user2 etc.) would be fired to notify other systems about >> the >> > user account merger. >> > >> > Here are the steps in some more detail: >> > >> > # Authentication >> > 0) Unauthenticated user1 goes to the /account/merge page and gets >> > redirected >> > to the login page. >> > >> > 1) User1 authenticates and gets redirected back to /account/merge >> > >> > # Account Selection / Verification >> > 2) User1 selects an account to merge with, e.g. user2 and verfies >> ownership >> > E.g. by showing an embedded login form and ask for Username + Password + >> > 2nd Factor >> > if present >> > >> > # Merge >> > 3) Merge the user account >> > 3.0) Ask user whether accounts should be merged (account of user1 will >> > become >> > the remaining / leading account). This is irreversible! >> > 3.1) Avoid account modification for user2 during merge, e.g. deactivate >> > the >> > old user (user2) >> > 3.2) Record some information about the merged user >> > Perhaphs via user attributes or maintain an explicit list of merged >> users. >> > >> > # Decide what should be merged >> > A built-in logic and / or the user decides what should be merged. >> > 3.4) User Profile information (e.g. complete incomplete fields? >> > E.g. firstname, lastname, mobile, etc.) >> > 3.5) Grant all roles of user2 to user1 >> > 3.6) Grant all consents of user2 to user1 >> > 3.7) Grant all group memberships of user2 to user1 >> > Credentials of user2 would be ignored. >> > >> > # Conclude the merge >> > 4) Mark user2 as merged or delete user 2 >> > Delete user2 or rename user2 and change email to be able to use that >> > information for user1. >> > 4.1) Propagate user account merge as event >> > Propagate a USER_ACCOUNT_MERGED event via the EventListener >> infrastructure. >> > The event should contain at least the userId of user1, and the userId of >> > user2 and >> > tells which is now the leading account. This enables downstream systems >> to >> > get notified >> > about the account merge. >> > >> > WDYT? >> > >> > Cheers, >> > Thomas >> > >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > From sthorger at redhat.com Thu Aug 31 14:42:18 2017 From: sthorger at redhat.com (Stian Thorgersen) Date: Thu, 31 Aug 2017 20:42:18 +0200 Subject: [keycloak-dev] Migration guide moved! Message-ID: The upgrade guide from RH-SSO has been moved to keycloak-documentation and now serves as the upgrade guide for both Keycloak and RH-SSO. That means add changes for Keycloak to upgrading/topics/keycloak/changes.adoc and not to the old MigrationFromOlderVersions.adoc file. I've left the old MigrationFromOlderVersions.adoc for now in case there's something that's missing in the new guide, but it's not included in the topics list.