From stian at redhat.com Mon Jun 1 02:40:03 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 1 Jun 2015 02:40:03 -0400 (EDT) Subject: [keycloak-dev] confused on event builder on auth In-Reply-To: <55690719.7030700@redhat.com> References: <55690719.7030700@redhat.com> Message-ID: <1927066216.9544780.1433140803895.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Saturday, 30 May, 2015 2:40:57 AM > Subject: [keycloak-dev] confused on event builder on auth > > What events are we supposed to be logging with the EventBuilder when > authenticating and doing required actions? > > 1. All errors > 2. all required action successes > 3. all login success > 2. Successful authentication prior to required actions? > 3. Success after required actions? That list sounds good to me > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From velias at redhat.com Mon Jun 1 08:03:10 2015 From: velias at redhat.com (Vlastimil Elias) Date: Mon, 01 Jun 2015 14:03:10 +0200 Subject: [keycloak-dev] Proposal of few improvements related to "Social registration" page flows Message-ID: <556C49FE.2030103@redhat.com> Hi, we just advanced to UAT phase of our project where we use Keycloak 1.2.0 final for user management, and we got feedback from testers. They proposed few improvements related to "Social registration" flows over OAuth identity providers (github, google, ...). 1. Perform "Update Profile on First Login" only if some of mandatory user profile fields is missing Current "Update Profile on First Login" setting in "Identity provider" configuration is on/off switch only. But response from some identity providers (like Github, Facebook) differs for distinct users, email is returned sometimes and sometimes not. We would like to show "Update Profile" page on first login only for users without email address (generalized a bit means without some of mandatory user profile info, which is currently email, name and surname) to simplify user flow for other users. Best implementation is probably to change "Update Profile on First Login" option in "Identity provider" configuration from On/Off switch to a select with three values: "On", "On missing only", "Off". 2. Do not perform email verification if email is provided by trusted Identity provider If "Verify email" option is enabled in Settings > Login, then it is applied to all KC users accounts, both created over registration form and as result of social login. We would like to simplify user flow for users who registered over social provider where we can trust email (like google) and skip this step in this case. I see two ways for configuration on per "Identity provider" basis: add new "Trust email" configuration option into "Identity provider" config page, or add special Mapper for providers called "Trust email" which will mark email as verified if provided by given identity provider. 3. Allow to map other informations provided by OAuth Identity providers into Keycloak user profile attributes Identity provider configuration contains "Mappers" configuration already, but only "Hardcoded role" mapper is available here for OAuth providers. We should add something like "Attribute Importer" already available for SAML providers. 4. allow to extend "Update Profile on First Login" page with other fields stored into user profile attributes My colleague created an issue for this already - https://issues.jboss.org/browse/KEYCLOAK-1361 5. Link social account into KC user account if email conflict is detected and user authenticated afterwards When user clicks Social login provider on login page, and social provider returns email which already exists for other KC user, then login page is shown with error message like "User with email already exists. Please login to account management to link the account.". This is really not very user friendly, as user is returned to original page/application after login and it may be a bit complicated for him to go into account management page and link account there. I believe that once user provides correct username and password on this login page then social account should be automatically linked to KC account user just authenticated to. Then user should be redirected to originating application. If this "social account autolink" should be able to survive "Forgot password" flow then even better ;-) What do you think about proposed improvements? I believe they are generic enough to be valuable for all KC users. I can create JIRA issues for them if you agree, and then I should be able to provide PR for 1, 2 ,4 first, then for 3. Feature from topic 5 is a bit complicated so I'm probably not able to help with it. Thanks in advance Vlastimil -- Vlastimil Elias Principal Software Engineer jboss.org Development Team From bburke at redhat.com Mon Jun 1 08:17:35 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 01 Jun 2015 08:17:35 -0400 Subject: [keycloak-dev] Proposal of few improvements related to "Social registration" page flows In-Reply-To: <556C49FE.2030103@redhat.com> References: <556C49FE.2030103@redhat.com> Message-ID: <556C4D5F.9070003@redhat.com> On 6/1/2015 8:03 AM, Vlastimil Elias wrote: > Hi, > > we just advanced to UAT phase of our project where we use Keycloak 1.2.0 > final for user management, and we got feedback from testers. > They proposed few improvements related to "Social registration" flows > over OAuth identity providers (github, google, ...). > > 1. Perform "Update Profile on First Login" only if some of mandatory > user profile fields is missing > Current "Update Profile on First Login" setting in "Identity provider" > configuration is on/off switch only. But response from some identity > providers (like Github, Facebook) differs for distinct users, email is > returned sometimes and sometimes not. We would like to show "Update > Profile" page on first login only for users without email address > (generalized a bit means without some of mandatory user profile info, > which is currently email, name and surname) to simplify user flow for > other users. > > Best implementation is probably to change "Update Profile on First > Login" option in "Identity provider" configuration from On/Off switch to > a select with three values: > "On", "On missing only", "Off". > > > 2. Do not perform email verification if email is provided by trusted > Identity provider > If "Verify email" option is enabled in Settings > Login, then it is > applied to all KC users accounts, both created over registration form > and as result of social login. > We would like to simplify user flow for users who registered over social > provider where we can trust email (like google) and skip this step in > this case. > > I see two ways for configuration on per "Identity provider" basis: add > new "Trust email" configuration option into "Identity provider" config > page, or add special Mapper for providers called "Trust email" which > will mark email as verified if provided by given identity provider. > > 3. Allow to map other informations provided by OAuth Identity providers > into Keycloak user profile attributes > Identity provider configuration contains "Mappers" configuration > already, but only "Hardcoded role" mapper is available here for OAuth > providers. > We should add something like "Attribute Importer" already available for > SAML providers. > You really mean mappers are needed for social providers. Their token formats are all different. This is why we don't have mappers for them. > > 4. allow to extend "Update Profile on First Login" page with other > fields stored into user profile attributes > My colleague created an issue for this already - > https://issues.jboss.org/browse/KEYCLOAK-1361 > > > 5. Link social account into KC user account if email conflict is > detected and user authenticated afterwards > When user clicks Social login provider on login page, and social > provider returns email which already exists for other KC user, then > login page is shown with error message like "User with email already > exists. Please login to account management to link the account.". This > is really not very user friendly, as user is returned to original > page/application after login and it may be a bit complicated for him to > go into account management page and link account there. > I believe that once user provides correct username and password on this > login page then social account should be automatically linked to KC > account user just authenticated to. Then user should be redirected to > originating application. If this "social account autolink" should be > able to survive "Forgot password" flow then even better ;-) > I like the auto-link after login. All good suggestions. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From velias at redhat.com Mon Jun 1 10:06:02 2015 From: velias at redhat.com (Vlastimil Elias) Date: Mon, 01 Jun 2015 16:06:02 +0200 Subject: [keycloak-dev] Proposal of few improvements related to "Social registration" page flows In-Reply-To: <556C4D5F.9070003@redhat.com> References: <556C49FE.2030103@redhat.com> <556C4D5F.9070003@redhat.com> Message-ID: <556C66CA.40202@redhat.com> Hi On 1.6.2015 14:17, Bill Burke wrote: > > On 6/1/2015 8:03 AM, Vlastimil Elias wrote: >> Hi, >> >> we just advanced to UAT phase of our project where we use Keycloak 1.2.0 >> final for user management, and we got feedback from testers. >> They proposed few improvements related to "Social registration" flows >> over OAuth identity providers (github, google, ...). >> >> 1. Perform "Update Profile on First Login" only if some of mandatory >> user profile fields is missing >> Current "Update Profile on First Login" setting in "Identity provider" >> configuration is on/off switch only. But response from some identity >> providers (like Github, Facebook) differs for distinct users, email is >> returned sometimes and sometimes not. We would like to show "Update >> Profile" page on first login only for users without email address >> (generalized a bit means without some of mandatory user profile info, >> which is currently email, name and surname) to simplify user flow for >> other users. >> >> Best implementation is probably to change "Update Profile on First >> Login" option in "Identity provider" configuration from On/Off switch to >> a select with three values: >> "On", "On missing only", "Off". >> >> >> 2. Do not perform email verification if email is provided by trusted >> Identity provider >> If "Verify email" option is enabled in Settings > Login, then it is >> applied to all KC users accounts, both created over registration form >> and as result of social login. >> We would like to simplify user flow for users who registered over social >> provider where we can trust email (like google) and skip this step in >> this case. >> >> I see two ways for configuration on per "Identity provider" basis: add >> new "Trust email" configuration option into "Identity provider" config >> page, or add special Mapper for providers called "Trust email" which >> will mark email as verified if provided by given identity provider. >> >> 3. Allow to map other informations provided by OAuth Identity providers >> into Keycloak user profile attributes >> Identity provider configuration contains "Mappers" configuration >> already, but only "Hardcoded role" mapper is available here for OAuth >> providers. >> We should add something like "Attribute Importer" already available for >> SAML providers. >> > You really mean mappers are needed for social providers. Their token > formats are all different. This is why we don't have mappers for them. User profile returned from social provider is typically flat JSON object (eg for github https://developer.github.com/v3/users/#get-a-single-user), so we can create universal mapper where one configuration property will say name of field in the JSON object and second one will say name of attribute in KC user profile to copy value into. We should also implement some simple dot notation to be able to deeper nest in JSON object returned from social provider if necessary. I looked into all current providers and they use JsonNode to represent profile loaded from social providers, so it should be easy to implement mapper based on field names. Only exception is Twitter provider which uses twitter4j library, but it should be solvable also. Vl. > >> 4. allow to extend "Update Profile on First Login" page with other >> fields stored into user profile attributes >> My colleague created an issue for this already - >> https://issues.jboss.org/browse/KEYCLOAK-1361 >> >> >> 5. Link social account into KC user account if email conflict is >> detected and user authenticated afterwards >> When user clicks Social login provider on login page, and social >> provider returns email which already exists for other KC user, then >> login page is shown with error message like "User with email already >> exists. Please login to account management to link the account.". This >> is really not very user friendly, as user is returned to original >> page/application after login and it may be a bit complicated for him to >> go into account management page and link account there. >> I believe that once user provides correct username and password on this >> login page then social account should be automatically linked to KC >> account user just authenticated to. Then user should be redirected to >> originating application. If this "social account autolink" should be >> able to survive "Forgot password" flow then even better ;-) >> > I like the auto-link after login. All good suggestions. > -- Vlastimil Elias Principal Software Engineer jboss.org Development Team From mstrukel at redhat.com Mon Jun 1 16:38:16 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Mon, 1 Jun 2015 16:38:16 -0400 (EDT) Subject: [keycloak-dev] Minor build issue In-Reply-To: <1346416594.7819210.1433190422262.JavaMail.zimbra@redhat.com> Message-ID: <2033616633.7826358.1433191096884.JavaMail.zimbra@redhat.com> Tomas has found an issue with the build when local maven repository is empty or build hasn't been run since previous version. The issue was introduced by my changes to adapters build - I left a dependency to the artifact I removed - org.keycloak:keycloak-wildfly-adapter-subsystem, and affects distribution/modules. There's a fix ready for merge: https://github.com/keycloak/keycloak/pull/1312 Too bad Travis CI didn't catch it - I propose we set up a local Nexus mirror and clear local repository (rm -rf ~/.m2/repository) for every build. Artifacts would be cached by local Nexus mirror and will be refetched from localhost, rather than from remote servers. - marko From stian at redhat.com Tue Jun 2 02:48:38 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 2 Jun 2015 02:48:38 -0400 (EDT) Subject: [keycloak-dev] Minor build issue In-Reply-To: <2033616633.7826358.1433191096884.JavaMail.zimbra@redhat.com> References: <2033616633.7826358.1433191096884.JavaMail.zimbra@redhat.com> Message-ID: <927597749.10272279.1433227718283.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Marko Strukelj" > To: "keycloak dev" > Sent: Monday, 1 June, 2015 10:38:16 PM > Subject: [keycloak-dev] Minor build issue > > Tomas has found an issue with the build when local maven repository is empty > or build hasn't been run since previous version. > > The issue was introduced by my changes to adapters build - I left a > dependency to the artifact I removed - > org.keycloak:keycloak-wildfly-adapter-subsystem, and affects > distribution/modules. > > There's a fix ready for merge: https://github.com/keycloak/keycloak/pull/1312 > > Too bad Travis CI didn't catch it - I propose we set up a local Nexus mirror > and clear local repository (rm -rf ~/.m2/repository) for every build. > Artifacts would be cached by local Nexus mirror and will be refetched from > localhost, rather than from remote servers. Travis is supposed to catch that. It uses a cache for MVN repo (otherwise it takes to long to run), but after the test it deletes repository/org/keycloak. > > - marko > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From stian at redhat.com Tue Jun 2 03:38:36 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 2 Jun 2015 03:38:36 -0400 (EDT) Subject: [keycloak-dev] Minor build issue In-Reply-To: <927597749.10272279.1433227718283.JavaMail.zimbra@redhat.com> References: <2033616633.7826358.1433191096884.JavaMail.zimbra@redhat.com> <927597749.10272279.1433227718283.JavaMail.zimbra@redhat.com> Message-ID: <1356029501.10289622.1433230716084.JavaMail.zimbra@redhat.com> Haha - was wondering why Travis doesn't catch this - it doesn't even build the dist on purpose. That's the problem, not that it's cached the module. ----- Original Message ----- > From: "Stian Thorgersen" > To: "Marko Strukelj" > Cc: "keycloak dev" > Sent: Tuesday, 2 June, 2015 8:48:38 AM > Subject: Re: [keycloak-dev] Minor build issue > > > > ----- Original Message ----- > > From: "Marko Strukelj" > > To: "keycloak dev" > > Sent: Monday, 1 June, 2015 10:38:16 PM > > Subject: [keycloak-dev] Minor build issue > > > > Tomas has found an issue with the build when local maven repository is > > empty > > or build hasn't been run since previous version. > > > > The issue was introduced by my changes to adapters build - I left a > > dependency to the artifact I removed - > > org.keycloak:keycloak-wildfly-adapter-subsystem, and affects > > distribution/modules. > > > > There's a fix ready for merge: > > https://github.com/keycloak/keycloak/pull/1312 > > > > Too bad Travis CI didn't catch it - I propose we set up a local Nexus > > mirror > > and clear local repository (rm -rf ~/.m2/repository) for every build. > > Artifacts would be cached by local Nexus mirror and will be refetched from > > localhost, rather than from remote servers. > > Travis is supposed to catch that. It uses a cache for MVN repo (otherwise it > takes to long to run), but after the test it deletes > repository/org/keycloak. > > > > > - marko > > _______________________________________________ > > 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 mstrukel at redhat.com Tue Jun 2 04:48:49 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Tue, 2 Jun 2015 04:48:49 -0400 (EDT) Subject: [keycloak-dev] Minor build issue In-Reply-To: <1356029501.10289622.1433230716084.JavaMail.zimbra@redhat.com> References: <2033616633.7826358.1433191096884.JavaMail.zimbra@redhat.com> <927597749.10272279.1433227718283.JavaMail.zimbra@redhat.com> <1356029501.10289622.1433230716084.JavaMail.zimbra@redhat.com> Message-ID: <2117392675.8084592.1433234929035.JavaMail.zimbra@redhat.com> Ah, so the instance running the CI is sloooooow ... and we don't want to wait forever on each PR ... and so -Pdistribution is not enabled ... ----- Original Message ----- > Haha - was wondering why Travis doesn't catch this - it doesn't even build > the dist on purpose. That's the problem, not that it's cached the module. > > ----- Original Message ----- > > From: "Stian Thorgersen" > > To: "Marko Strukelj" > > Cc: "keycloak dev" > > Sent: Tuesday, 2 June, 2015 8:48:38 AM > > Subject: Re: [keycloak-dev] Minor build issue > > > > > > > > ----- Original Message ----- > > > From: "Marko Strukelj" > > > To: "keycloak dev" > > > Sent: Monday, 1 June, 2015 10:38:16 PM > > > Subject: [keycloak-dev] Minor build issue > > > > > > Tomas has found an issue with the build when local maven repository is > > > empty > > > or build hasn't been run since previous version. > > > > > > The issue was introduced by my changes to adapters build - I left a > > > dependency to the artifact I removed - > > > org.keycloak:keycloak-wildfly-adapter-subsystem, and affects > > > distribution/modules. > > > > > > There's a fix ready for merge: > > > https://github.com/keycloak/keycloak/pull/1312 > > > > > > Too bad Travis CI didn't catch it - I propose we set up a local Nexus > > > mirror > > > and clear local repository (rm -rf ~/.m2/repository) for every build. > > > Artifacts would be cached by local Nexus mirror and will be refetched > > > from > > > localhost, rather than from remote servers. > > > > Travis is supposed to catch that. It uses a cache for MVN repo (otherwise > > it > > takes to long to run), but after the test it deletes > > repository/org/keycloak. > > > > > > > > - marko > > > _______________________________________________ > > > 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 stian at redhat.com Tue Jun 2 04:53:55 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 2 Jun 2015 04:53:55 -0400 (EDT) Subject: [keycloak-dev] Minor build issue In-Reply-To: <2117392675.8084592.1433234929035.JavaMail.zimbra@redhat.com> References: <2033616633.7826358.1433191096884.JavaMail.zimbra@redhat.com> <927597749.10272279.1433227718283.JavaMail.zimbra@redhat.com> <1356029501.10289622.1433230716084.JavaMail.zimbra@redhat.com> <2117392675.8084592.1433234929035.JavaMail.zimbra@redhat.com> Message-ID: <2039873952.10323747.1433235235080.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Marko Strukelj" > To: "Stian Thorgersen" > Cc: "keycloak dev" > Sent: Tuesday, 2 June, 2015 10:48:49 AM > Subject: Re: [keycloak-dev] Minor build issue > > Ah, so the instance running the CI is sloooooow ... and we don't want to wait > forever on each PR ... and so -Pdistribution is not enabled ... Nope, Travis isn't that slooow. The build is :( > > ----- Original Message ----- > > Haha - was wondering why Travis doesn't catch this - it doesn't even build > > the dist on purpose. That's the problem, not that it's cached the module. > > > > ----- Original Message ----- > > > From: "Stian Thorgersen" > > > To: "Marko Strukelj" > > > Cc: "keycloak dev" > > > Sent: Tuesday, 2 June, 2015 8:48:38 AM > > > Subject: Re: [keycloak-dev] Minor build issue > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Marko Strukelj" > > > > To: "keycloak dev" > > > > Sent: Monday, 1 June, 2015 10:38:16 PM > > > > Subject: [keycloak-dev] Minor build issue > > > > > > > > Tomas has found an issue with the build when local maven repository is > > > > empty > > > > or build hasn't been run since previous version. > > > > > > > > The issue was introduced by my changes to adapters build - I left a > > > > dependency to the artifact I removed - > > > > org.keycloak:keycloak-wildfly-adapter-subsystem, and affects > > > > distribution/modules. > > > > > > > > There's a fix ready for merge: > > > > https://github.com/keycloak/keycloak/pull/1312 > > > > > > > > Too bad Travis CI didn't catch it - I propose we set up a local Nexus > > > > mirror > > > > and clear local repository (rm -rf ~/.m2/repository) for every build. > > > > Artifacts would be cached by local Nexus mirror and will be refetched > > > > from > > > > localhost, rather than from remote servers. > > > > > > Travis is supposed to catch that. It uses a cache for MVN repo (otherwise > > > it > > > takes to long to run), but after the test it deletes > > > repository/org/keycloak. > > > > > > > > > > > - marko > > > > _______________________________________________ > > > > 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 velias at redhat.com Tue Jun 2 07:41:50 2015 From: velias at redhat.com (Vlastimil Elias) Date: Tue, 02 Jun 2015 13:41:50 +0200 Subject: [keycloak-dev] Proposal of few improvements related to "Social registration" page flows In-Reply-To: <556C4D5F.9070003@redhat.com> References: <556C49FE.2030103@redhat.com> <556C4D5F.9070003@redhat.com> Message-ID: <556D967E.4070207@redhat.com> Hi, I created four new JIRA Enhancement issues (KEYCLOAK-1371 - KEYCLOAK-1374) for my proposals. Cheers Vl On 1.6.2015 14:17, Bill Burke wrote: > > On 6/1/2015 8:03 AM, Vlastimil Elias wrote: >> Hi, >> >> we just advanced to UAT phase of our project where we use Keycloak 1.2.0 >> final for user management, and we got feedback from testers. >> They proposed few improvements related to "Social registration" flows >> over OAuth identity providers (github, google, ...). >> >> 1. Perform "Update Profile on First Login" only if some of mandatory >> user profile fields is missing >> Current "Update Profile on First Login" setting in "Identity provider" >> configuration is on/off switch only. But response from some identity >> providers (like Github, Facebook) differs for distinct users, email is >> returned sometimes and sometimes not. We would like to show "Update >> Profile" page on first login only for users without email address >> (generalized a bit means without some of mandatory user profile info, >> which is currently email, name and surname) to simplify user flow for >> other users. >> >> Best implementation is probably to change "Update Profile on First >> Login" option in "Identity provider" configuration from On/Off switch to >> a select with three values: >> "On", "On missing only", "Off". >> >> >> 2. Do not perform email verification if email is provided by trusted >> Identity provider >> If "Verify email" option is enabled in Settings > Login, then it is >> applied to all KC users accounts, both created over registration form >> and as result of social login. >> We would like to simplify user flow for users who registered over social >> provider where we can trust email (like google) and skip this step in >> this case. >> >> I see two ways for configuration on per "Identity provider" basis: add >> new "Trust email" configuration option into "Identity provider" config >> page, or add special Mapper for providers called "Trust email" which >> will mark email as verified if provided by given identity provider. >> >> 3. Allow to map other informations provided by OAuth Identity providers >> into Keycloak user profile attributes >> Identity provider configuration contains "Mappers" configuration >> already, but only "Hardcoded role" mapper is available here for OAuth >> providers. >> We should add something like "Attribute Importer" already available for >> SAML providers. >> > You really mean mappers are needed for social providers. Their token > formats are all different. This is why we don't have mappers for them. > >> 4. allow to extend "Update Profile on First Login" page with other >> fields stored into user profile attributes >> My colleague created an issue for this already - >> https://issues.jboss.org/browse/KEYCLOAK-1361 >> >> >> 5. Link social account into KC user account if email conflict is >> detected and user authenticated afterwards >> When user clicks Social login provider on login page, and social >> provider returns email which already exists for other KC user, then >> login page is shown with error message like "User with email already >> exists. Please login to account management to link the account.". This >> is really not very user friendly, as user is returned to original >> page/application after login and it may be a bit complicated for him to >> go into account management page and link account there. >> I believe that once user provides correct username and password on this >> login page then social account should be automatically linked to KC >> account user just authenticated to. Then user should be redirected to >> originating application. If this "social account autolink" should be >> able to survive "Forgot password" flow then even better ;-) >> > I like the auto-link after login. All good suggestions. > -- Vlastimil Elias Principal Software Engineer jboss.org Development Team From stian at redhat.com Tue Jun 2 09:04:03 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 2 Jun 2015 09:04:03 -0400 (EDT) Subject: [keycloak-dev] Direct grant always on In-Reply-To: <1848529691.10425200.1433250044239.JavaMail.zimbra@redhat.com> Message-ID: <1561828714.10428066.1433250243879.JavaMail.zimbra@redhat.com> I propose we remove the option to enable/disable direct grant and always have it on. Alternatively we need an option to enable it without using the admin console. This is for users that want to use a CLI, or needs to do some automatic configuration when provisioning a KC. From mposolda at redhat.com Tue Jun 2 09:36:54 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 02 Jun 2015 15:36:54 +0200 Subject: [keycloak-dev] Federation & LDAP caching Message-ID: <556DB176.8060508@redhat.com> We have still open issue https://issues.jboss.org/browse/KEYCLOAK-838 . In shortcut, during authentication of user into LDAP there are 9 same queries to LDAP to load this single user. Similar situation might be for other federation providers. Few ideas to improve: 1) Simple per-request caching at UserFederationManager level - currently each call to "session.users().getUserByXXX()" always call "isValid" on federation provider causing that validation/loading of same user might be done more time per request. With very simple enhancement at UserFederationManager level, we ensure that loading of user will be done just once per request (per KeycloakSession), which is not an issue IMO as KeycloakSession is really short-living object. Note that this is not specific to LDAP, but should improve performance of UserFederation in general. I have very simple patch here https://github.com/mposolda/keycloak/commit/f8302dac0e927756ca0d49a67500f6d5149ac8ae . With this, number of loads to LDAP per authentication is reduced from 9 calls to 3. Any objections against merging it? 2) Global caching - this is obviously much more tricky, but I think that earlier or later we need to address it as (1) might not be sufficient. Few ideas: 2.a) Allow to switch the user cache on top of delegation. Currently we have UserProvider delegation chain like: User Federation => User Cache Provider => JPA/Mongo UserProvider The alternative I mean is, that people will have possibility to configure the chain like: User Cache Provider => User Federation => JPA/Mongo UserProvider By default, the order will be still the same like it's now, however I can imagine that for many LDAP (and other federation) deployments, the admins use them just as read-only store and don't do any direct changes here. Hence there is no reason to always validate/proxy users and ask federation storage if user still exists etc but instead suffer from our already existing cache impl and enjoy improved performance. I propose we will just add on/off switch to admin console, which will allow to specify when cache should be put on top of federation or after (like it's now). We may also need to add the button to clear the cache. WDYT? 2.b) Another alternative is to put cache layer on top of LDAPIdentityStore. TBH I am not the fan of it as it's specific to LDAP and it requires another implementation of caching with all the pitfalls (Figure which items should be invalidated during writes, abstraction to support both "mem" and cluster/infinispan deployments etc...) my proposal is to go with (1) for this release and then look at (2.a) if I have time as it may be another few days of work (so maybe postpone to next release) WDYT, other better ideas to improve? Marek From ssilvert at redhat.com Tue Jun 2 10:11:53 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 02 Jun 2015 10:11:53 -0400 Subject: [keycloak-dev] Direct grant always on In-Reply-To: <1561828714.10428066.1433250243879.JavaMail.zimbra@redhat.com> References: <1561828714.10428066.1433250243879.JavaMail.zimbra@redhat.com> Message-ID: <556DB9A9.4020706@redhat.com> +1 Is there a use case for having it off? On 6/2/2015 9:04 AM, Stian Thorgersen wrote: > I propose we remove the option to enable/disable direct grant and always have it on. Alternatively we need an option to enable it without using the admin console. > > This is for users that want to use a CLI, or needs to do some automatic configuration when provisioning a KC. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Tue Jun 2 10:19:41 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 02 Jun 2015 16:19:41 +0200 Subject: [keycloak-dev] Direct grant always on In-Reply-To: <1561828714.10428066.1433250243879.JavaMail.zimbra@redhat.com> References: <1561828714.10428066.1433250243879.JavaMail.zimbra@redhat.com> Message-ID: <556DBB7D.4070607@redhat.com> Maybe we can have it "true" by default, as it will likely save a lot of pain to many people. However I would not remove it as at least OAuth2 specs doesn't like it very well (Especially see 10.7 https://tools.ietf.org/html/rfc6749#page-57 ). Maybe better alternative is to have the possibility to enable it for master realm with something like the keycloak-bootstrap.json file, which was planned to be added at some point (or maybe even have the option in keycloak-server.json) ? Marek On 2.6.2015 15:04, Stian Thorgersen wrote: > I propose we remove the option to enable/disable direct grant and always have it on. Alternatively we need an option to enable it without using the admin console. > > This is for users that want to use a CLI, or needs to do some automatic configuration when provisioning a KC. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Wed Jun 3 02:24:32 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 3 Jun 2015 02:24:32 -0400 (EDT) Subject: [keycloak-dev] Direct grant always on In-Reply-To: <556DBB7D.4070607@redhat.com> References: <1561828714.10428066.1433250243879.JavaMail.zimbra@redhat.com> <556DBB7D.4070607@redhat.com> Message-ID: <1938225017.10905541.1433312672795.JavaMail.zimbra@redhat.com> IMO it's needed by default and shouldn't be an extra config option. OAuth2 spec says to limit it's use yes, but that's so there's less passwords flying around. Problem is that spec only provides a good solution for web and nothing else. So for CLIs (and even some native apps) you're left with using username+password. Initially it was disabled by default as we thought there was some security implications. However, given a users username and password someone can just the same endpoints as the web based login does. They do pretty much the same thing when invoked from a script, just less user friendly. I.e. curl ../openid-connect/login, scrape the csrf protection value, post it with username and password, then crab the code from the redirect. Anyone that has access to swap the code for the token, would also have access to invoking the direct grant endpoint. ----- Original Message ----- > From: "Marek Posolda" > To: "Stian Thorgersen" , "keycloak dev" > Sent: Tuesday, 2 June, 2015 4:19:41 PM > Subject: Re: [keycloak-dev] Direct grant always on > > Maybe we can have it "true" by default, as it will likely save a lot of > pain to many people. However I would not remove it as at least OAuth2 > specs doesn't like it very well (Especially see 10.7 > https://tools.ietf.org/html/rfc6749#page-57 ). > > Maybe better alternative is to have the possibility to enable it for > master realm with something like the keycloak-bootstrap.json file, which > was planned to be added at some point (or maybe even have the option in > keycloak-server.json) ? > > Marek > > On 2.6.2015 15:04, Stian Thorgersen wrote: > > I propose we remove the option to enable/disable direct grant and always > > have it on. Alternatively we need an option to enable it without using the > > admin console. > > > > This is for users that want to use a CLI, or needs to do some automatic > > configuration when provisioning a KC. > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > From mposolda at redhat.com Wed Jun 3 02:53:09 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 03 Jun 2015 08:53:09 +0200 Subject: [keycloak-dev] Direct grant always on In-Reply-To: <1938225017.10905541.1433312672795.JavaMail.zimbra@redhat.com> References: <1561828714.10428066.1433250243879.JavaMail.zimbra@redhat.com> <556DBB7D.4070607@redhat.com> <1938225017.10905541.1433312672795.JavaMail.zimbra@redhat.com> Message-ID: <556EA455.40205@redhat.com> Yeah, I think you're right when thinking more about it. So +1 from me as well :-) Marek 3.6.2015 08:24, Stian Thorgersen wrote: > IMO it's needed by default and shouldn't be an extra config option. > > OAuth2 spec says to limit it's use yes, but that's so there's less passwords flying around. Problem is that spec only provides a good solution for web and nothing else. So for CLIs (and even some native apps) you're left with using username+password. > > Initially it was disabled by default as we thought there was some security implications. However, given a users username and password someone can just the same endpoints as the web based login does. They do pretty much the same thing when invoked from a script, just less user friendly. I.e. curl ../openid-connect/login, scrape the csrf protection value, post it with username and password, then crab the code from the redirect. Anyone that has access to swap the code for the token, would also have access to invoking the direct grant endpoint. > > ----- Original Message ----- >> From: "Marek Posolda" >> To: "Stian Thorgersen" , "keycloak dev" >> Sent: Tuesday, 2 June, 2015 4:19:41 PM >> Subject: Re: [keycloak-dev] Direct grant always on >> >> Maybe we can have it "true" by default, as it will likely save a lot of >> pain to many people. However I would not remove it as at least OAuth2 >> specs doesn't like it very well (Especially see 10.7 >> https://tools.ietf.org/html/rfc6749#page-57 ). >> >> Maybe better alternative is to have the possibility to enable it for >> master realm with something like the keycloak-bootstrap.json file, which >> was planned to be added at some point (or maybe even have the option in >> keycloak-server.json) ? >> >> Marek >> >> On 2.6.2015 15:04, Stian Thorgersen wrote: >>> I propose we remove the option to enable/disable direct grant and always >>> have it on. Alternatively we need an option to enable it without using the >>> admin console. >>> >>> This is for users that want to use a CLI, or needs to do some automatic >>> configuration when provisioning a KC. >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From matzew at apache.org Wed Jun 3 05:17:18 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 3 Jun 2015 11:17:18 +0200 Subject: [keycloak-dev] Direct grant always on In-Reply-To: <1561828714.10428066.1433250243879.JavaMail.zimbra@redhat.com> References: <1848529691.10425200.1433250044239.JavaMail.zimbra@redhat.com> <1561828714.10428066.1433250243879.JavaMail.zimbra@redhat.com> Message-ID: coming in which version ? :-) -M On Tue, Jun 2, 2015 at 3:04 PM, Stian Thorgersen wrote: > I propose we remove the option to enable/disable direct grant and always > have it on. Alternatively we need an option to enable it without using the > admin console. > > This is for users that want to use a CLI, or needs to do some automatic > configuration when provisioning a KC. > _______________________________________________ > 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/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150603/8e611d8f/attachment.html From stian at redhat.com Wed Jun 3 05:18:53 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 3 Jun 2015 05:18:53 -0400 (EDT) Subject: [keycloak-dev] Direct grant always on In-Reply-To: References: <1848529691.10425200.1433250044239.JavaMail.zimbra@redhat.com> <1561828714.10428066.1433250243879.JavaMail.zimbra@redhat.com> Message-ID: <22185334.11014595.1433323133431.JavaMail.zimbra@redhat.com> 1.3 or never ;) ----- Original Message ----- > From: "Matthias Wessendorf" > To: "Stian Thorgersen" > Cc: "keycloak dev" > Sent: Wednesday, 3 June, 2015 11:17:18 AM > Subject: Re: [keycloak-dev] Direct grant always on > > coming in which version ? :-) > > -M > > On Tue, Jun 2, 2015 at 3:04 PM, Stian Thorgersen wrote: > > > I propose we remove the option to enable/disable direct grant and always > > have it on. Alternatively we need an option to enable it without using the > > admin console. > > > > This is for users that want to use a CLI, or needs to do some automatic > > configuration when provisioning a KC. > > _______________________________________________ > > 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/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > From matzew at apache.org Wed Jun 3 05:32:04 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 3 Jun 2015 11:32:04 +0200 Subject: [keycloak-dev] Direct grant always on In-Reply-To: <22185334.11014595.1433323133431.JavaMail.zimbra@redhat.com> References: <1848529691.10425200.1433250044239.JavaMail.zimbra@redhat.com> <1561828714.10428066.1433250243879.JavaMail.zimbra@redhat.com> <22185334.11014595.1433323133431.JavaMail.zimbra@redhat.com> Message-ID: +1 for doing that on 1.3 :-) On Wed, Jun 3, 2015 at 11:18 AM, Stian Thorgersen wrote: > 1.3 or never ;) > > ----- Original Message ----- > > From: "Matthias Wessendorf" > > To: "Stian Thorgersen" > > Cc: "keycloak dev" > > Sent: Wednesday, 3 June, 2015 11:17:18 AM > > Subject: Re: [keycloak-dev] Direct grant always on > > > > coming in which version ? :-) > > > > -M > > > > On Tue, Jun 2, 2015 at 3:04 PM, Stian Thorgersen > wrote: > > > > > I propose we remove the option to enable/disable direct grant and > always > > > have it on. Alternatively we need an option to enable it without using > the > > > admin console. > > > > > > This is for users that want to use a CLI, or needs to do some automatic > > > configuration when provisioning a KC. > > > _______________________________________________ > > > 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/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150603/0e69d357/attachment-0001.html From akshayransing at gmail.com Wed Jun 3 10:08:20 2015 From: akshayransing at gmail.com (Akshay Ransing) Date: Wed, 3 Jun 2015 19:38:20 +0530 Subject: [keycloak-dev] Client Credential Grant Message-ID: Hi, Can anyone point me towards documentation for using Client Credential Grant way of obtaining for access token for confidential client in Keycloak. I have some APIs on my resource server which are not specific to resource owner but client applications. (closer example can be "Checkout as guest" option on any e-commerce site where user is not interested in signup but do want to access multiple API from resource server) https://tools.ietf.org/html/rfc6749#page-40 *point 4.4* -- Thanks & Regards Akshay Ransing +918793858910 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150603/7972f5b1/attachment.html From stian at redhat.com Wed Jun 3 10:14:51 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 3 Jun 2015 10:14:51 -0400 (EDT) Subject: [keycloak-dev] Client Credential Grant In-Reply-To: References: Message-ID: <390446542.11330884.1433340891736.JavaMail.zimbra@redhat.com> Afraid we don't have this yet. As a work-around until we do I suggest you create a user on behalf of the client and use Resource Owner Password Credentials. ----- Original Message ----- > From: "Akshay Ransing" > To: keycloak-dev at lists.jboss.org > Sent: Wednesday, 3 June, 2015 4:08:20 PM > Subject: [keycloak-dev] Client Credential Grant > > Hi, > > Can anyone point me towards documentation for using Client Credential Grant > way of obtaining for access token for confidential client in Keycloak. > I have some APIs on my resource server which are not specific to resource > owner but client applications. (closer example can be "Checkout as guest" > option on any e-commerce site where user is not interested in signup but do > want to access multiple API from resource server) > > https://tools.ietf.org/html/rfc6749#page-40 point 4.4 > > -- > Thanks & Regards > Akshay Ransing > +918793858910 > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Wed Jun 3 19:00:10 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 03 Jun 2015 19:00:10 -0400 Subject: [keycloak-dev] sticky sessions, clustering, and authentication Message-ID: <556F86FA.6070800@redhat.com> I was thinking a bit about performance in a cluster. Right now a client session is created whenever login is initiated. This ends up requiring the client session to be propagated to the cluster, either through a database insert/update or an infinispan replication. Then, with each authentication/required action step, another insert/update/replication. I was thinking we should have an AuthenticationSession that was in memory only. Then, once all authentication and required actions are finished, then create the usersession and client session. This would require sticky sessions though with a load balancer. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From matthew.casperson at autogeneral.com.au Wed Jun 3 19:33:50 2015 From: matthew.casperson at autogeneral.com.au (Matthew Casperson) Date: Thu, 4 Jun 2015 09:33:50 +1000 Subject: [keycloak-dev] "Windows Security" pop up problem Message-ID: We authenticate against a Windows domain using LDAP (and not using Kerberos). In KeyCloak 1.2.0, this prompt now appears when users are asked to log in. The problem is that this prompt automatically appends the domain to the username, and I can't see any LDAP property that accepts the domain name. We use the sAMAccountName property, which does not include the domain, and looking at https://msdn.microsoft.com/en-us/library/windows/desktop/ms677605(v=vs.85).aspx I don't see any other property that will work with this prompt. We might be able to use userPrincipalName, but none of our users have any experience logging in with an email address, and I'd like to avoid the training overhead of this if possible. So my questions are: 1. Can I disable this prompt and use the standard keycloak form based login? 2. Is there an LDAP field that I can define in the keycloak LDAP federation config that will accept a domain as part of the username? ? -- *Matthew Casperson* *Senior Front End Developer* Technology, Space & Distribution Auto & General Holdings Pty Ltd P: 07) 3377 8751 (Direct: 3377 8751) F: 07) 3377 8833 -- This email is sent by Auto & General Insurance Company Ltd, Auto & General Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body corporate (Auto & General) and is for the intended addressee. The views expressed in this email and attachments (email) reflect the views of the stated author but may not reflect views of Auto & General. This email is confidential and subject to copyright. It may be privileged. If you are not the intended addressee, confidentiality and privilege have not been waived and any use, interference with, or disclosure of this email is unauthorised. If you are not the intended addressee please immediately notify the sender and then delete the email. Auto & General does not warrant that this email is error or virus free. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150604/a2834405/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2015-06-04 at 9.25.08 am.png Type: image/png Size: 23598 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150604/a2834405/attachment-0001.png From mikecirioli at gmail.com Wed Jun 3 19:49:15 2015 From: mikecirioli at gmail.com (mike cirioli) Date: Wed, 03 Jun 2015 19:49:15 -0400 Subject: [keycloak-dev] sticky sessions, clustering, and authentication Message-ID: <556f927e.870a6b0a.8a15.0c4b@mx.google.com> So sticky sessions would be needed only during the authentication phase, and once complete an underlying clustered session would be created?? On Jun 3, 2015 7:00 PM, Bill Burke wrote: > > I was thinking a bit about performance in a cluster.? Right now a client > session is created whenever login is initiated.? This ends up requiring > the client session to be propagated to the cluster, either through a > database insert/update or an infinispan replication.? Then, with each > authentication/required action step, another insert/update/replication. > > I was thinking we should have an AuthenticationSession that was in > memory only.? Then, once all authentication and required actions are > finished, then create the usersession and client session.? This would > require sticky sessions though with a load balancer. > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Thu Jun 4 02:49:03 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 04 Jun 2015 08:49:03 +0200 Subject: [keycloak-dev] sticky sessions, clustering, and authentication In-Reply-To: <556f927e.870a6b0a.8a15.0c4b@mx.google.com> References: <556f927e.870a6b0a.8a15.0c4b@mx.google.com> Message-ID: <556FF4DF.8060009@redhat.com> Question is if the requirement for sticky sessions is not too restrictive? I guess not everyone want to use sticky sessions. Maybe we should offer both possibilities (in-memory + sticky sessions OR AuthenticationSession saved in infinispan and replicated after each request) ? Another question is if overhead of current replication is really so bad to introduce another abstraction and increase code complexity? Marek On 4.6.2015 01:49, mike cirioli wrote: > So sticky sessions would be needed only during the authentication phase, and once complete an underlying clustered session would be created? > > On Jun 3, 2015 7:00 PM, Bill Burke wrote: >> I was thinking a bit about performance in a cluster. Right now a client >> session is created whenever login is initiated. This ends up requiring >> the client session to be propagated to the cluster, either through a >> database insert/update or an infinispan replication. Then, with each >> authentication/required action step, another insert/update/replication. >> >> I was thinking we should have an AuthenticationSession that was in >> memory only. Then, once all authentication and required actions are >> finished, then create the usersession and client session. This would >> require sticky sessions though with a load balancer. >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Thu Jun 4 02:49:41 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 4 Jun 2015 02:49:41 -0400 (EDT) Subject: [keycloak-dev] sticky sessions, clustering, and authentication In-Reply-To: <556F86FA.6070800@redhat.com> References: <556F86FA.6070800@redhat.com> Message-ID: <1486240449.11844879.1433400581045.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Thursday, 4 June, 2015 1:00:10 AM > Subject: [keycloak-dev] sticky sessions, clustering, and authentication > > I was thinking a bit about performance in a cluster. Right now a client > session is created whenever login is initiated. This ends up requiring > the client session to be propagated to the cluster, either through a > database insert/update or an infinispan replication. Then, with each > authentication/required action step, another insert/update/replication. No it doesn't. For client and user sessions we use a distributed Infinispan cache, so only one (or 2-3 if each shard is replicated) node store each session. > > I was thinking we should have an AuthenticationSession that was in > memory only. Then, once all authentication and required actions are > finished, then create the usersession and client session. This would > require sticky sessions though with a load balancer. -1000 > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From stian at redhat.com Thu Jun 4 02:53:44 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 4 Jun 2015 02:53:44 -0400 (EDT) Subject: [keycloak-dev] sticky sessions, clustering, and authentication In-Reply-To: <556FF4DF.8060009@redhat.com> References: <556f927e.870a6b0a.8a15.0c4b@mx.google.com> <556FF4DF.8060009@redhat.com> Message-ID: <1458772596.11846388.1433400824077.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Marek Posolda" > To: "mike cirioli" , "Bill Burke" > Cc: keycloak-dev at lists.jboss.org > Sent: Thursday, 4 June, 2015 8:49:03 AM > Subject: Re: [keycloak-dev] sticky sessions, clustering, and authentication > > Question is if the requirement for sticky sessions is not too > restrictive? I guess not everyone want to use sticky sessions. > > Maybe we should offer both possibilities (in-memory + sticky sessions OR > AuthenticationSession saved in infinispan and replicated after each > request) ? > > Another question is if overhead of current replication is really so bad > to introduce another abstraction and increase code complexity? We're not using a replicated cache - we're using a distributed cache. If anyone is worried about performance Google how Google works (hint: sharding) ;) > > Marek > > On 4.6.2015 01:49, mike cirioli wrote: > > So sticky sessions would be needed only during the authentication phase, > > and once complete an underlying clustered session would be created? > > > > On Jun 3, 2015 7:00 PM, Bill Burke wrote: > >> I was thinking a bit about performance in a cluster. Right now a client > >> session is created whenever login is initiated. This ends up requiring > >> the client session to be propagated to the cluster, either through a > >> database insert/update or an infinispan replication. Then, with each > >> authentication/required action step, another insert/update/replication. > >> > >> I was thinking we should have an AuthenticationSession that was in > >> memory only. Then, once all authentication and required actions are > >> finished, then create the usersession and client session. This would > >> require sticky sessions though with a load balancer. > >> > >> -- > >> Bill Burke > >> JBoss, a division of Red Hat > >> http://bill.burkecentral.com > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From mposolda at redhat.com Thu Jun 4 04:28:15 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 04 Jun 2015 10:28:15 +0200 Subject: [keycloak-dev] sticky sessions, clustering, and authentication In-Reply-To: <1458772596.11846388.1433400824077.JavaMail.zimbra@redhat.com> References: <556f927e.870a6b0a.8a15.0c4b@mx.google.com> <556FF4DF.8060009@redhat.com> <1458772596.11846388.1433400824077.JavaMail.zimbra@redhat.com> Message-ID: <55700C1F.2090808@redhat.com> On 4.6.2015 08:53, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Marek Posolda" >> To: "mike cirioli" , "Bill Burke" >> Cc: keycloak-dev at lists.jboss.org >> Sent: Thursday, 4 June, 2015 8:49:03 AM >> Subject: Re: [keycloak-dev] sticky sessions, clustering, and authentication >> >> Question is if the requirement for sticky sessions is not too >> restrictive? I guess not everyone want to use sticky sessions. >> >> Maybe we should offer both possibilities (in-memory + sticky sessions OR >> AuthenticationSession saved in infinispan and replicated after each >> request) ? >> >> Another question is if overhead of current replication is really so bad >> to introduce another abstraction and increase code complexity? > We're not using a replicated cache - we're using a distributed cache. > > If anyone is worried about performance Google how Google works (hint: sharding) ;) yeah, the performance is the question and at some point I want to look at it a bit more. For the distributed I am a bit worried if it doesn't require more network calls then replicated in some envs. I wonder about the situation like: 1) You open login screen and you're forwarded by LB to node1 where is ClientSession created and saved into cache 2) You confirm login screen but then you're forwarded by LB to node2. Then call to "keycloakSession.sessions().getClientSession()" always perform network call to node1 as my ClientSession is saved on node1. Or am I wrong here? So in shortcut, in distribution there is no any overhead with replicating the session as it's saved always in one node, but there may be much more overhead in lookup for sessions, which are saved on different cluster node (unless I am wrong...) Marek > >> Marek >> >> On 4.6.2015 01:49, mike cirioli wrote: >>> So sticky sessions would be needed only during the authentication phase, >>> and once complete an underlying clustered session would be created? >>> >>> On Jun 3, 2015 7:00 PM, Bill Burke wrote: >>>> I was thinking a bit about performance in a cluster. Right now a client >>>> session is created whenever login is initiated. This ends up requiring >>>> the client session to be propagated to the cluster, either through a >>>> database insert/update or an infinispan replication. Then, with each >>>> authentication/required action step, another insert/update/replication. >>>> >>>> I was thinking we should have an AuthenticationSession that was in >>>> memory only. Then, once all authentication and required actions are >>>> finished, then create the usersession and client session. This would >>>> require sticky sessions though with a load balancer. >>>> >>>> -- >>>> Bill Burke >>>> JBoss, a division of Red Hat >>>> http://bill.burkecentral.com >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From mposolda at redhat.com Thu Jun 4 04:42:35 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 04 Jun 2015 10:42:35 +0200 Subject: [keycloak-dev] "Windows Security" pop up problem In-Reply-To: References: Message-ID: <55700F7B.3030602@redhat.com> On 4.6.2015 01:33, Matthew Casperson wrote: > We authenticate against a Windows domain using LDAP (and not using > Kerberos). > > In KeyCloak 1.2.0, this prompt now appears when users are asked to log > in. The problem is that this prompt automatically appends the domain > to the username, and I can't see any LDAP property that accepts the > domain name. > > We use the sAMAccountName property, which does not include the domain, > and looking at > https://msdn.microsoft.com/en-us/library/windows/desktop/ms677605(v=vs.85).aspx > > I don't see any other property that will work with this prompt. > > We might be able to use userPrincipalName, but none of our users have > any experience logging in with an email address, and I'd like to avoid > the training overhead of this if possible. > > So my questions are: > 1. Can I disable this prompt and use the standard keycloak form based > login? This prompt is displayed when you display keycloak login screen in the browser? Can you doublecheck that your user federation has "Allow kerberos login" switched to off and there is no "Kerberos" credential in required realm credentials? Marek > 2. Is there an LDAP field that I can define in the keycloak LDAP > federation config that will accept a domain as part of the username? > > > ? > > -- > *Matthew Casperson* > *Senior Front End Developer* > Technology, Space & Distribution > Auto & General Holdings Pty Ltd > P: 07) 3377 8751 (Direct: 3377 8751) > F: 07) 3377 8833 > > > > This email is sent by Auto & General Insurance Company Ltd, Auto & General Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body corporate (Auto & General) and is for the intended addressee. > The views expressed in this email and attachments (email) reflect the views of the stated author but may not reflect views of Auto & General. This email is confidential and subject to copyright. > It may be privileged. If you are not the intended addressee, confidentiality and privilege have not been waived and any use, interference with, or disclosure of this email is unauthorised. > If you are not the intended addressee please immediately notify the sender and then delete the email. Auto & General does not warrant that this email is error or virus free. > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150604/7e92e58a/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 23598 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150604/7e92e58a/attachment-0001.png From a.mocioi at gmail.com Thu Jun 4 06:14:59 2015 From: a.mocioi at gmail.com (Horia Mocioi) Date: Thu, 4 Jun 2015 13:14:59 +0300 Subject: [keycloak-dev] Admin REST API create new user Message-ID: Hello, I would like to create a user via Admin REST API using HttpPost. Unfortunately, I was not able to find any example on how to create a user or role. I successfully managed to list roles and user using the example from admin-access-api, but now I would like to create a new user. Can anyone provide an example using HttpPost on how to create a new user? Thank you, Horia -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150604/7b68db7f/attachment.html From stian at redhat.com Thu Jun 4 06:40:42 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 4 Jun 2015 06:40:42 -0400 (EDT) Subject: [keycloak-dev] sticky sessions, clustering, and authentication In-Reply-To: <55700C1F.2090808@redhat.com> References: <556f927e.870a6b0a.8a15.0c4b@mx.google.com> <556FF4DF.8060009@redhat.com> <1458772596.11846388.1433400824077.JavaMail.zimbra@redhat.com> <55700C1F.2090808@redhat.com> Message-ID: <1337888299.11991094.1433414442504.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Marek Posolda" > To: "Stian Thorgersen" > Cc: "mike cirioli" , "Bill Burke" , keycloak-dev at lists.jboss.org > Sent: Thursday, 4 June, 2015 10:28:15 AM > Subject: Re: [keycloak-dev] sticky sessions, clustering, and authentication > > On 4.6.2015 08:53, Stian Thorgersen wrote: > > > > ----- Original Message ----- > >> From: "Marek Posolda" > >> To: "mike cirioli" , "Bill Burke" > >> > >> Cc: keycloak-dev at lists.jboss.org > >> Sent: Thursday, 4 June, 2015 8:49:03 AM > >> Subject: Re: [keycloak-dev] sticky sessions, clustering, and > >> authentication > >> > >> Question is if the requirement for sticky sessions is not too > >> restrictive? I guess not everyone want to use sticky sessions. > >> > >> Maybe we should offer both possibilities (in-memory + sticky sessions OR > >> AuthenticationSession saved in infinispan and replicated after each > >> request) ? > >> > >> Another question is if overhead of current replication is really so bad > >> to introduce another abstraction and increase code complexity? > > We're not using a replicated cache - we're using a distributed cache. > > > > If anyone is worried about performance Google how Google works (hint: > > sharding) ;) > yeah, the performance is the question and at some point I want to look > at it a bit more. For the distributed I am a bit worried if it doesn't > require more network calls then replicated in some envs. I wonder about > the situation like: > > 1) You open login screen and you're forwarded by LB to node1 where is > ClientSession created and saved into cache > 2) You confirm login screen but then you're forwarded by LB to node2. > Then call to "keycloakSession.sessions().getClientSession()" always > perform network call to node1 as my ClientSession is saved on node1. Or > am I wrong here? > > So in shortcut, in distribution there is no any overhead with > replicating the session as it's saved always in one node, but there may > be much more overhead in lookup for sessions, which are saved on > different cluster node (unless I am wrong...) Sticky sessions are horrible and hard to get to work for Keycloak especially as we have two separate calls (browser and app). Only solution without sticky sessions are distributed caches (shards). If Google can make it scale to their level it shouldn't be a problem for us either. What we do maybe need to optimize is how many calls there are. For example atm I think we call once to get client session and another for user session. > > Marek > > > > >> Marek > >> > >> On 4.6.2015 01:49, mike cirioli wrote: > >>> So sticky sessions would be needed only during the authentication phase, > >>> and once complete an underlying clustered session would be created? > >>> > >>> On Jun 3, 2015 7:00 PM, Bill Burke wrote: > >>>> I was thinking a bit about performance in a cluster. Right now a client > >>>> session is created whenever login is initiated. This ends up requiring > >>>> the client session to be propagated to the cluster, either through a > >>>> database insert/update or an infinispan replication. Then, with each > >>>> authentication/required action step, another insert/update/replication. > >>>> > >>>> I was thinking we should have an AuthenticationSession that was in > >>>> memory only. Then, once all authentication and required actions are > >>>> finished, then create the usersession and client session. This would > >>>> require sticky sessions though with a load balancer. > >>>> > >>>> -- > >>>> Bill Burke > >>>> JBoss, a division of Red Hat > >>>> http://bill.burkecentral.com > >>>> _______________________________________________ > >>>> keycloak-dev mailing list > >>>> keycloak-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>> _______________________________________________ > >>> keycloak-dev mailing list > >>> keycloak-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > From stian at redhat.com Thu Jun 4 06:41:46 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 4 Jun 2015 06:41:46 -0400 (EDT) Subject: [keycloak-dev] sticky sessions, clustering, and authentication In-Reply-To: <1337888299.11991094.1433414442504.JavaMail.zimbra@redhat.com> References: <556f927e.870a6b0a.8a15.0c4b@mx.google.com> <556FF4DF.8060009@redhat.com> <1458772596.11846388.1433400824077.JavaMail.zimbra@redhat.com> <55700C1F.2090808@redhat.com> <1337888299.11991094.1433414442504.JavaMail.zimbra@redhat.com> Message-ID: <700246400.11991972.1433414506363.JavaMail.zimbra@redhat.com> End of the day - I'm pretty confident this isn't going to be the worst performance bottleneck we have and until we've done some benchmarking we shouldn't be spending time on this as we have tons of higher priorities. ----- Original Message ----- > From: "Stian Thorgersen" > To: "Marek Posolda" > Cc: "mike cirioli" , "Bill Burke" , keycloak-dev at lists.jboss.org > Sent: Thursday, 4 June, 2015 12:40:42 PM > Subject: Re: [keycloak-dev] sticky sessions, clustering, and authentication > > > > ----- Original Message ----- > > From: "Marek Posolda" > > To: "Stian Thorgersen" > > Cc: "mike cirioli" , "Bill Burke" > > , keycloak-dev at lists.jboss.org > > Sent: Thursday, 4 June, 2015 10:28:15 AM > > Subject: Re: [keycloak-dev] sticky sessions, clustering, and authentication > > > > On 4.6.2015 08:53, Stian Thorgersen wrote: > > > > > > ----- Original Message ----- > > >> From: "Marek Posolda" > > >> To: "mike cirioli" , "Bill Burke" > > >> > > >> Cc: keycloak-dev at lists.jboss.org > > >> Sent: Thursday, 4 June, 2015 8:49:03 AM > > >> Subject: Re: [keycloak-dev] sticky sessions, clustering, and > > >> authentication > > >> > > >> Question is if the requirement for sticky sessions is not too > > >> restrictive? I guess not everyone want to use sticky sessions. > > >> > > >> Maybe we should offer both possibilities (in-memory + sticky sessions OR > > >> AuthenticationSession saved in infinispan and replicated after each > > >> request) ? > > >> > > >> Another question is if overhead of current replication is really so bad > > >> to introduce another abstraction and increase code complexity? > > > We're not using a replicated cache - we're using a distributed cache. > > > > > > If anyone is worried about performance Google how Google works (hint: > > > sharding) ;) > > yeah, the performance is the question and at some point I want to look > > at it a bit more. For the distributed I am a bit worried if it doesn't > > require more network calls then replicated in some envs. I wonder about > > the situation like: > > > > 1) You open login screen and you're forwarded by LB to node1 where is > > ClientSession created and saved into cache > > 2) You confirm login screen but then you're forwarded by LB to node2. > > Then call to "keycloakSession.sessions().getClientSession()" always > > perform network call to node1 as my ClientSession is saved on node1. Or > > am I wrong here? > > > > So in shortcut, in distribution there is no any overhead with > > replicating the session as it's saved always in one node, but there may > > be much more overhead in lookup for sessions, which are saved on > > different cluster node (unless I am wrong...) > > Sticky sessions are horrible and hard to get to work for Keycloak especially > as we have two separate calls (browser and app). > > Only solution without sticky sessions are distributed caches (shards). If > Google can make it scale to their level it shouldn't be a problem for us > either. > > What we do maybe need to optimize is how many calls there are. For example > atm I think we call once to get client session and another for user session. > > > > > Marek > > > > > > > >> Marek > > >> > > >> On 4.6.2015 01:49, mike cirioli wrote: > > >>> So sticky sessions would be needed only during the authentication > > >>> phase, > > >>> and once complete an underlying clustered session would be created? > > >>> > > >>> On Jun 3, 2015 7:00 PM, Bill Burke wrote: > > >>>> I was thinking a bit about performance in a cluster. Right now a > > >>>> client > > >>>> session is created whenever login is initiated. This ends up > > >>>> requiring > > >>>> the client session to be propagated to the cluster, either through a > > >>>> database insert/update or an infinispan replication. Then, with each > > >>>> authentication/required action step, another > > >>>> insert/update/replication. > > >>>> > > >>>> I was thinking we should have an AuthenticationSession that was in > > >>>> memory only. Then, once all authentication and required actions are > > >>>> finished, then create the usersession and client session. This would > > >>>> require sticky sessions though with a load balancer. > > >>>> > > >>>> -- > > >>>> Bill Burke > > >>>> JBoss, a division of Red Hat > > >>>> http://bill.burkecentral.com > > >>>> _______________________________________________ > > >>>> keycloak-dev mailing list > > >>>> keycloak-dev at lists.jboss.org > > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > >>> _______________________________________________ > > >>> keycloak-dev mailing list > > >>> keycloak-dev at lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > >> _______________________________________________ > > >> keycloak-dev mailing list > > >> keycloak-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > >> > > > > > From srossillo at smartling.com Thu Jun 4 07:55:52 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Thu, 4 Jun 2015 07:55:52 -0400 Subject: [keycloak-dev] Admin REST API create new user In-Reply-To: References: Message-ID: Keycloak keycloak = Keycloak.getInstance(?); // your args here UserRepresentation user = new UserRepresentation(); // call user setters try { keycloak.realm(?realm-name").users().create(user); } finally { keycloak.close(); } > On Jun 4, 2015, at 6:14 AM, Horia Mocioi wrote: > > Hello, > > I would like to create a user via Admin REST API using HttpPost. Unfortunately, I was not able to find any example on how to create a user or role. > > I successfully managed to list roles and user using the example from admin-access-api, but now I would like to create a new user. > > Can anyone provide an example using HttpPost on how to create a new user? > > Thank you, > Horia > > -- > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150604/ad2599ea/attachment.html From mposolda at redhat.com Thu Jun 4 08:09:10 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 04 Jun 2015 14:09:10 +0200 Subject: [keycloak-dev] sticky sessions, clustering, and authentication In-Reply-To: <1337888299.11991094.1433414442504.JavaMail.zimbra@redhat.com> References: <556f927e.870a6b0a.8a15.0c4b@mx.google.com> <556FF4DF.8060009@redhat.com> <1458772596.11846388.1433400824077.JavaMail.zimbra@redhat.com> <55700C1F.2090808@redhat.com> <1337888299.11991094.1433414442504.JavaMail.zimbra@redhat.com> Message-ID: <55703FE6.9070901@redhat.com> On 4.6.2015 12:40, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Marek Posolda" >> To: "Stian Thorgersen" >> Cc: "mike cirioli" , "Bill Burke" , keycloak-dev at lists.jboss.org >> Sent: Thursday, 4 June, 2015 10:28:15 AM >> Subject: Re: [keycloak-dev] sticky sessions, clustering, and authentication >> >> On 4.6.2015 08:53, Stian Thorgersen wrote: >>> ----- Original Message ----- >>>> From: "Marek Posolda" >>>> To: "mike cirioli" , "Bill Burke" >>>> >>>> Cc: keycloak-dev at lists.jboss.org >>>> Sent: Thursday, 4 June, 2015 8:49:03 AM >>>> Subject: Re: [keycloak-dev] sticky sessions, clustering, and >>>> authentication >>>> >>>> Question is if the requirement for sticky sessions is not too >>>> restrictive? I guess not everyone want to use sticky sessions. >>>> >>>> Maybe we should offer both possibilities (in-memory + sticky sessions OR >>>> AuthenticationSession saved in infinispan and replicated after each >>>> request) ? >>>> >>>> Another question is if overhead of current replication is really so bad >>>> to introduce another abstraction and increase code complexity? >>> We're not using a replicated cache - we're using a distributed cache. >>> >>> If anyone is worried about performance Google how Google works (hint: >>> sharding) ;) >> yeah, the performance is the question and at some point I want to look >> at it a bit more. For the distributed I am a bit worried if it doesn't >> require more network calls then replicated in some envs. I wonder about >> the situation like: >> >> 1) You open login screen and you're forwarded by LB to node1 where is >> ClientSession created and saved into cache >> 2) You confirm login screen but then you're forwarded by LB to node2. >> Then call to "keycloakSession.sessions().getClientSession()" always >> perform network call to node1 as my ClientSession is saved on node1. Or >> am I wrong here? >> >> So in shortcut, in distribution there is no any overhead with >> replicating the session as it's saved always in one node, but there may >> be much more overhead in lookup for sessions, which are saved on >> different cluster node (unless I am wrong...) > Sticky sessions are horrible and hard to get to work for Keycloak especially as we have two separate calls (browser and app). > > Only solution without sticky sessions are distributed caches (shards). If Google can make it scale to their level it shouldn't be a problem for us either. I didn't mean sticky sessions here, but UserSessions/ClientSessions. Just trying to compare the performance of replication vs. distribution. For large clusters (5+ nodes) distribution is only choice for sure, replicating each item to 5 nodes doesn't scale... However for smaller clusters like 2 nodes, the replication may be better choice than distribution though. With distribution, if you really have network call per "session.sessions().getClientSession()" you may end with 10 network calls per request or so. > > What we do maybe need to optimize is how many calls there are. For example atm I think we call once to get client session and another for user session. +1, maybe we can try to see if ClientSession/UserSession can be saved in KeycloakContext. Marek > >> Marek >> >>>> Marek >>>> >>>> On 4.6.2015 01:49, mike cirioli wrote: >>>>> So sticky sessions would be needed only during the authentication phase, >>>>> and once complete an underlying clustered session would be created? >>>>> >>>>> On Jun 3, 2015 7:00 PM, Bill Burke wrote: >>>>>> I was thinking a bit about performance in a cluster. Right now a client >>>>>> session is created whenever login is initiated. This ends up requiring >>>>>> the client session to be propagated to the cluster, either through a >>>>>> database insert/update or an infinispan replication. Then, with each >>>>>> authentication/required action step, another insert/update/replication. >>>>>> >>>>>> I was thinking we should have an AuthenticationSession that was in >>>>>> memory only. Then, once all authentication and required actions are >>>>>> finished, then create the usersession and client session. This would >>>>>> require sticky sessions though with a load balancer. >>>>>> >>>>>> -- >>>>>> Bill Burke >>>>>> JBoss, a division of Red Hat >>>>>> http://bill.burkecentral.com >>>>>> _______________________________________________ >>>>>> keycloak-dev mailing list >>>>>> keycloak-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >> From stian at redhat.com Thu Jun 4 08:18:26 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 4 Jun 2015 08:18:26 -0400 (EDT) Subject: [keycloak-dev] sticky sessions, clustering, and authentication In-Reply-To: <55703FE6.9070901@redhat.com> References: <556f927e.870a6b0a.8a15.0c4b@mx.google.com> <556FF4DF.8060009@redhat.com> <1458772596.11846388.1433400824077.JavaMail.zimbra@redhat.com> <55700C1F.2090808@redhat.com> <1337888299.11991094.1433414442504.JavaMail.zimbra@redhat.com> <55703FE6.9070901@redhat.com> Message-ID: <1457479255.12041145.1433420306550.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Marek Posolda" > To: "Stian Thorgersen" > Cc: "mike cirioli" , "Bill Burke" , keycloak-dev at lists.jboss.org > Sent: Thursday, 4 June, 2015 2:09:10 PM > Subject: Re: [keycloak-dev] sticky sessions, clustering, and authentication > > On 4.6.2015 12:40, Stian Thorgersen wrote: > > > > ----- Original Message ----- > >> From: "Marek Posolda" > >> To: "Stian Thorgersen" > >> Cc: "mike cirioli" , "Bill Burke" > >> , keycloak-dev at lists.jboss.org > >> Sent: Thursday, 4 June, 2015 10:28:15 AM > >> Subject: Re: [keycloak-dev] sticky sessions, clustering, and > >> authentication > >> > >> On 4.6.2015 08:53, Stian Thorgersen wrote: > >>> ----- Original Message ----- > >>>> From: "Marek Posolda" > >>>> To: "mike cirioli" , "Bill Burke" > >>>> > >>>> Cc: keycloak-dev at lists.jboss.org > >>>> Sent: Thursday, 4 June, 2015 8:49:03 AM > >>>> Subject: Re: [keycloak-dev] sticky sessions, clustering, and > >>>> authentication > >>>> > >>>> Question is if the requirement for sticky sessions is not too > >>>> restrictive? I guess not everyone want to use sticky sessions. > >>>> > >>>> Maybe we should offer both possibilities (in-memory + sticky sessions OR > >>>> AuthenticationSession saved in infinispan and replicated after each > >>>> request) ? > >>>> > >>>> Another question is if overhead of current replication is really so bad > >>>> to introduce another abstraction and increase code complexity? > >>> We're not using a replicated cache - we're using a distributed cache. > >>> > >>> If anyone is worried about performance Google how Google works (hint: > >>> sharding) ;) > >> yeah, the performance is the question and at some point I want to look > >> at it a bit more. For the distributed I am a bit worried if it doesn't > >> require more network calls then replicated in some envs. I wonder about > >> the situation like: > >> > >> 1) You open login screen and you're forwarded by LB to node1 where is > >> ClientSession created and saved into cache > >> 2) You confirm login screen but then you're forwarded by LB to node2. > >> Then call to "keycloakSession.sessions().getClientSession()" always > >> perform network call to node1 as my ClientSession is saved on node1. Or > >> am I wrong here? > >> > >> So in shortcut, in distribution there is no any overhead with > >> replicating the session as it's saved always in one node, but there may > >> be much more overhead in lookup for sessions, which are saved on > >> different cluster node (unless I am wrong...) > > Sticky sessions are horrible and hard to get to work for Keycloak > > especially as we have two separate calls (browser and app). > > > > Only solution without sticky sessions are distributed caches (shards). If > > Google can make it scale to their level it shouldn't be a problem for us > > either. > I didn't mean sticky sessions here, but UserSessions/ClientSessions. > Just trying to compare the performance of replication vs. distribution. > For large clusters (5+ nodes) distribution is only choice for sure, > replicating each item to 5 nodes doesn't scale... > > However for smaller clusters like 2 nodes, the replication may be better > choice than distribution though. With distribution, if you really have > network call per "session.sessions().getClientSession()" you may end > with 10 network calls per request or so. Pretty sure it's the same. Every update to client-session is a message to update. We just need to make sure there's only 1 request to read and 1 to update. > > > > What we do maybe need to optimize is how many calls there are. For example > > atm I think we call once to get client session and another for user > > session. > +1, maybe we can try to see if ClientSession/UserSession can be saved in > KeycloakContext. > > Marek > > > > >> Marek > >> > >>>> Marek > >>>> > >>>> On 4.6.2015 01:49, mike cirioli wrote: > >>>>> So sticky sessions would be needed only during the authentication > >>>>> phase, > >>>>> and once complete an underlying clustered session would be created? > >>>>> > >>>>> On Jun 3, 2015 7:00 PM, Bill Burke wrote: > >>>>>> I was thinking a bit about performance in a cluster. Right now a > >>>>>> client > >>>>>> session is created whenever login is initiated. This ends up > >>>>>> requiring > >>>>>> the client session to be propagated to the cluster, either through a > >>>>>> database insert/update or an infinispan replication. Then, with each > >>>>>> authentication/required action step, another > >>>>>> insert/update/replication. > >>>>>> > >>>>>> I was thinking we should have an AuthenticationSession that was in > >>>>>> memory only. Then, once all authentication and required actions are > >>>>>> finished, then create the usersession and client session. This would > >>>>>> require sticky sessions though with a load balancer. > >>>>>> > >>>>>> -- > >>>>>> Bill Burke > >>>>>> JBoss, a division of Red Hat > >>>>>> http://bill.burkecentral.com > >>>>>> _______________________________________________ > >>>>>> keycloak-dev mailing list > >>>>>> keycloak-dev at lists.jboss.org > >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>>> _______________________________________________ > >>>>> keycloak-dev mailing list > >>>>> keycloak-dev at lists.jboss.org > >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>> _______________________________________________ > >>>> keycloak-dev mailing list > >>>> keycloak-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>> > >> > > From mposolda at redhat.com Thu Jun 4 08:26:36 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 04 Jun 2015 14:26:36 +0200 Subject: [keycloak-dev] sticky sessions, clustering, and authentication In-Reply-To: <1457479255.12041145.1433420306550.JavaMail.zimbra@redhat.com> References: <556f927e.870a6b0a.8a15.0c4b@mx.google.com> <556FF4DF.8060009@redhat.com> <1458772596.11846388.1433400824077.JavaMail.zimbra@redhat.com> <55700C1F.2090808@redhat.com> <1337888299.11991094.1433414442504.JavaMail.zimbra@redhat.com> <55703FE6.9070901@redhat.com> <1457479255.12041145.1433420306550.JavaMail.zimbra@redhat.com> Message-ID: <557043FC.7000101@redhat.com> On 4.6.2015 14:18, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Marek Posolda" >> To: "Stian Thorgersen" >> Cc: "mike cirioli" , "Bill Burke" , keycloak-dev at lists.jboss.org >> Sent: Thursday, 4 June, 2015 2:09:10 PM >> Subject: Re: [keycloak-dev] sticky sessions, clustering, and authentication >> >> On 4.6.2015 12:40, Stian Thorgersen wrote: >>> ----- Original Message ----- >>>> From: "Marek Posolda" >>>> To: "Stian Thorgersen" >>>> Cc: "mike cirioli" , "Bill Burke" >>>> , keycloak-dev at lists.jboss.org >>>> Sent: Thursday, 4 June, 2015 10:28:15 AM >>>> Subject: Re: [keycloak-dev] sticky sessions, clustering, and >>>> authentication >>>> >>>> On 4.6.2015 08:53, Stian Thorgersen wrote: >>>>> ----- Original Message ----- >>>>>> From: "Marek Posolda" >>>>>> To: "mike cirioli" , "Bill Burke" >>>>>> >>>>>> Cc: keycloak-dev at lists.jboss.org >>>>>> Sent: Thursday, 4 June, 2015 8:49:03 AM >>>>>> Subject: Re: [keycloak-dev] sticky sessions, clustering, and >>>>>> authentication >>>>>> >>>>>> Question is if the requirement for sticky sessions is not too >>>>>> restrictive? I guess not everyone want to use sticky sessions. >>>>>> >>>>>> Maybe we should offer both possibilities (in-memory + sticky sessions OR >>>>>> AuthenticationSession saved in infinispan and replicated after each >>>>>> request) ? >>>>>> >>>>>> Another question is if overhead of current replication is really so bad >>>>>> to introduce another abstraction and increase code complexity? >>>>> We're not using a replicated cache - we're using a distributed cache. >>>>> >>>>> If anyone is worried about performance Google how Google works (hint: >>>>> sharding) ;) >>>> yeah, the performance is the question and at some point I want to look >>>> at it a bit more. For the distributed I am a bit worried if it doesn't >>>> require more network calls then replicated in some envs. I wonder about >>>> the situation like: >>>> >>>> 1) You open login screen and you're forwarded by LB to node1 where is >>>> ClientSession created and saved into cache >>>> 2) You confirm login screen but then you're forwarded by LB to node2. >>>> Then call to "keycloakSession.sessions().getClientSession()" always >>>> perform network call to node1 as my ClientSession is saved on node1. Or >>>> am I wrong here? >>>> >>>> So in shortcut, in distribution there is no any overhead with >>>> replicating the session as it's saved always in one node, but there may >>>> be much more overhead in lookup for sessions, which are saved on >>>> different cluster node (unless I am wrong...) >>> Sticky sessions are horrible and hard to get to work for Keycloak >>> especially as we have two separate calls (browser and app). >>> >>> Only solution without sticky sessions are distributed caches (shards). If >>> Google can make it scale to their level it shouldn't be a problem for us >>> either. >> I didn't mean sticky sessions here, but UserSessions/ClientSessions. >> Just trying to compare the performance of replication vs. distribution. >> For large clusters (5+ nodes) distribution is only choice for sure, >> replicating each item to 5 nodes doesn't scale... >> >> However for smaller clusters like 2 nodes, the replication may be better >> choice than distribution though. With distribution, if you really have >> network call per "session.sessions().getClientSession()" you may end >> with 10 network calls per request or so. > Pretty sure it's the same. Every update to client-session is a message to update. We just need to make sure there's only 1 request to read and 1 to update. For writes, you did transaction wrapper in Infinispan session provider to write just one per request or so. For reads, we don't have anything like it. But I agree, we need some benchmarking first... Without it, it is just speculation... Marek > >>> What we do maybe need to optimize is how many calls there are. For example >>> atm I think we call once to get client session and another for user >>> session. >> +1, maybe we can try to see if ClientSession/UserSession can be saved in >> KeycloakContext. >> >> Marek >> >>>> Marek >>>> >>>>>> Marek >>>>>> >>>>>> On 4.6.2015 01:49, mike cirioli wrote: >>>>>>> So sticky sessions would be needed only during the authentication >>>>>>> phase, >>>>>>> and once complete an underlying clustered session would be created? >>>>>>> >>>>>>> On Jun 3, 2015 7:00 PM, Bill Burke wrote: >>>>>>>> I was thinking a bit about performance in a cluster. Right now a >>>>>>>> client >>>>>>>> session is created whenever login is initiated. This ends up >>>>>>>> requiring >>>>>>>> the client session to be propagated to the cluster, either through a >>>>>>>> database insert/update or an infinispan replication. Then, with each >>>>>>>> authentication/required action step, another >>>>>>>> insert/update/replication. >>>>>>>> >>>>>>>> I was thinking we should have an AuthenticationSession that was in >>>>>>>> memory only. Then, once all authentication and required actions are >>>>>>>> finished, then create the usersession and client session. This would >>>>>>>> require sticky sessions though with a load balancer. >>>>>>>> >>>>>>>> -- >>>>>>>> Bill Burke >>>>>>>> JBoss, a division of Red Hat >>>>>>>> http://bill.burkecentral.com >>>>>>>> _______________________________________________ >>>>>>>> keycloak-dev mailing list >>>>>>>> keycloak-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>> _______________________________________________ >>>>>>> keycloak-dev mailing list >>>>>>> keycloak-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> _______________________________________________ >>>>>> keycloak-dev mailing list >>>>>> keycloak-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> >> From stian at redhat.com Thu Jun 4 08:29:48 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 4 Jun 2015 08:29:48 -0400 (EDT) Subject: [keycloak-dev] sticky sessions, clustering, and authentication In-Reply-To: <557043FC.7000101@redhat.com> References: <556f927e.870a6b0a.8a15.0c4b@mx.google.com> <556FF4DF.8060009@redhat.com> <1458772596.11846388.1433400824077.JavaMail.zimbra@redhat.com> <55700C1F.2090808@redhat.com> <1337888299.11991094.1433414442504.JavaMail.zimbra@redhat.com> <55703FE6.9070901@redhat.com> <1457479255.12041145.1433420306550.JavaMail.zimbra@redhat.com> <557043FC.7000101@redhat.com> Message-ID: <1353731754.12046290.1433420988948.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Marek Posolda" > To: "Stian Thorgersen" > Cc: "mike cirioli" , "Bill Burke" , keycloak-dev at lists.jboss.org > Sent: Thursday, 4 June, 2015 2:26:36 PM > Subject: Re: [keycloak-dev] sticky sessions, clustering, and authentication > > On 4.6.2015 14:18, Stian Thorgersen wrote: > > > > ----- Original Message ----- > >> From: "Marek Posolda" > >> To: "Stian Thorgersen" > >> Cc: "mike cirioli" , "Bill Burke" > >> , keycloak-dev at lists.jboss.org > >> Sent: Thursday, 4 June, 2015 2:09:10 PM > >> Subject: Re: [keycloak-dev] sticky sessions, clustering, and > >> authentication > >> > >> On 4.6.2015 12:40, Stian Thorgersen wrote: > >>> ----- Original Message ----- > >>>> From: "Marek Posolda" > >>>> To: "Stian Thorgersen" > >>>> Cc: "mike cirioli" , "Bill Burke" > >>>> , keycloak-dev at lists.jboss.org > >>>> Sent: Thursday, 4 June, 2015 10:28:15 AM > >>>> Subject: Re: [keycloak-dev] sticky sessions, clustering, and > >>>> authentication > >>>> > >>>> On 4.6.2015 08:53, Stian Thorgersen wrote: > >>>>> ----- Original Message ----- > >>>>>> From: "Marek Posolda" > >>>>>> To: "mike cirioli" , "Bill Burke" > >>>>>> > >>>>>> Cc: keycloak-dev at lists.jboss.org > >>>>>> Sent: Thursday, 4 June, 2015 8:49:03 AM > >>>>>> Subject: Re: [keycloak-dev] sticky sessions, clustering, and > >>>>>> authentication > >>>>>> > >>>>>> Question is if the requirement for sticky sessions is not too > >>>>>> restrictive? I guess not everyone want to use sticky sessions. > >>>>>> > >>>>>> Maybe we should offer both possibilities (in-memory + sticky sessions > >>>>>> OR > >>>>>> AuthenticationSession saved in infinispan and replicated after each > >>>>>> request) ? > >>>>>> > >>>>>> Another question is if overhead of current replication is really so > >>>>>> bad > >>>>>> to introduce another abstraction and increase code complexity? > >>>>> We're not using a replicated cache - we're using a distributed cache. > >>>>> > >>>>> If anyone is worried about performance Google how Google works (hint: > >>>>> sharding) ;) > >>>> yeah, the performance is the question and at some point I want to look > >>>> at it a bit more. For the distributed I am a bit worried if it doesn't > >>>> require more network calls then replicated in some envs. I wonder about > >>>> the situation like: > >>>> > >>>> 1) You open login screen and you're forwarded by LB to node1 where is > >>>> ClientSession created and saved into cache > >>>> 2) You confirm login screen but then you're forwarded by LB to node2. > >>>> Then call to "keycloakSession.sessions().getClientSession()" always > >>>> perform network call to node1 as my ClientSession is saved on node1. Or > >>>> am I wrong here? > >>>> > >>>> So in shortcut, in distribution there is no any overhead with > >>>> replicating the session as it's saved always in one node, but there may > >>>> be much more overhead in lookup for sessions, which are saved on > >>>> different cluster node (unless I am wrong...) > >>> Sticky sessions are horrible and hard to get to work for Keycloak > >>> especially as we have two separate calls (browser and app). > >>> > >>> Only solution without sticky sessions are distributed caches (shards). If > >>> Google can make it scale to their level it shouldn't be a problem for us > >>> either. > >> I didn't mean sticky sessions here, but UserSessions/ClientSessions. > >> Just trying to compare the performance of replication vs. distribution. > >> For large clusters (5+ nodes) distribution is only choice for sure, > >> replicating each item to 5 nodes doesn't scale... > >> > >> However for smaller clusters like 2 nodes, the replication may be better > >> choice than distribution though. With distribution, if you really have > >> network call per "session.sessions().getClientSession()" you may end > >> with 10 network calls per request or so. > > Pretty sure it's the same. Every update to client-session is a message to > > update. We just need to make sure there's only 1 request to read and 1 to > > update. > For writes, you did transaction wrapper in Infinispan session provider > to write just one per request or so. For reads, we don't have anything > like it. Clever me :) > > But I agree, we need some benchmarking first... Without it, it is just > speculation... > > Marek > > > >>> What we do maybe need to optimize is how many calls there are. For > >>> example > >>> atm I think we call once to get client session and another for user > >>> session. > >> +1, maybe we can try to see if ClientSession/UserSession can be saved in > >> KeycloakContext. > >> > >> Marek > >> > >>>> Marek > >>>> > >>>>>> Marek > >>>>>> > >>>>>> On 4.6.2015 01:49, mike cirioli wrote: > >>>>>>> So sticky sessions would be needed only during the authentication > >>>>>>> phase, > >>>>>>> and once complete an underlying clustered session would be created? > >>>>>>> > >>>>>>> On Jun 3, 2015 7:00 PM, Bill Burke wrote: > >>>>>>>> I was thinking a bit about performance in a cluster. Right now a > >>>>>>>> client > >>>>>>>> session is created whenever login is initiated. This ends up > >>>>>>>> requiring > >>>>>>>> the client session to be propagated to the cluster, either through a > >>>>>>>> database insert/update or an infinispan replication. Then, with > >>>>>>>> each > >>>>>>>> authentication/required action step, another > >>>>>>>> insert/update/replication. > >>>>>>>> > >>>>>>>> I was thinking we should have an AuthenticationSession that was in > >>>>>>>> memory only. Then, once all authentication and required actions are > >>>>>>>> finished, then create the usersession and client session. This > >>>>>>>> would > >>>>>>>> require sticky sessions though with a load balancer. > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Bill Burke > >>>>>>>> JBoss, a division of Red Hat > >>>>>>>> http://bill.burkecentral.com > >>>>>>>> _______________________________________________ > >>>>>>>> keycloak-dev mailing list > >>>>>>>> keycloak-dev at lists.jboss.org > >>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>>>>> _______________________________________________ > >>>>>>> keycloak-dev mailing list > >>>>>>> keycloak-dev at lists.jboss.org > >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>>>> _______________________________________________ > >>>>>> keycloak-dev mailing list > >>>>>> keycloak-dev at lists.jboss.org > >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>>>> > >> > > From bburke at redhat.com Thu Jun 4 08:40:54 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 04 Jun 2015 08:40:54 -0400 Subject: [keycloak-dev] sticky sessions, clustering, and authentication In-Reply-To: <55703FE6.9070901@redhat.com> References: <556f927e.870a6b0a.8a15.0c4b@mx.google.com> <556FF4DF.8060009@redhat.com> <1458772596.11846388.1433400824077.JavaMail.zimbra@redhat.com> <55700C1F.2090808@redhat.com> <1337888299.11991094.1433414442504.JavaMail.zimbra@redhat.com> <55703FE6.9070901@redhat.com> Message-ID: <55704756.2070604@redhat.com> On 6/4/2015 8:09 AM, Marek Posolda wrote: >> Only solution without sticky sessions are distributed caches (shards). >> If Google can make it scale to their level it shouldn't be a problem >> for us either. > I didn't mean sticky sessions here, but UserSessions/ClientSessions. > Just trying to compare the performance of replication vs. distribution. > For large clusters (5+ nodes) distribution is only choice for sure, > replicating each item to 5 nodes doesn't scale... > > However for smaller clusters like 2 nodes, the replication may be better > choice than distribution though. With distribution, if you really have > network call per "session.sessions().getClientSession()" you may end > with 10 network calls per request or so. >> >> What we do maybe need to optimize is how many calls there are. For >> example atm I think we call once to get client session and another for >> user session. > +1, maybe we can try to see if ClientSession/UserSession can be saved in > KeycloakContext. > Just hitting the login screen causes a replication/distribution for infinispan, db insert for mongo/jpa. There's no way around that because our authentication layer is decoupled from the login protocol (saml, oidc) and we need to store protocol specific metadata for use after authentication is complete. Another thought is to store AuthenticationSession into a signed/encrypted cookie or a query parameter so you could avoid sticky sessions. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Thu Jun 4 08:55:20 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 4 Jun 2015 08:55:20 -0400 (EDT) Subject: [keycloak-dev] sticky sessions, clustering, and authentication In-Reply-To: <55704756.2070604@redhat.com> References: <556f927e.870a6b0a.8a15.0c4b@mx.google.com> <556FF4DF.8060009@redhat.com> <1458772596.11846388.1433400824077.JavaMail.zimbra@redhat.com> <55700C1F.2090808@redhat.com> <1337888299.11991094.1433414442504.JavaMail.zimbra@redhat.com> <55703FE6.9070901@redhat.com> <55704756.2070604@redhat.com> Message-ID: <1069068933.12058336.1433422520138.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: "Marek Posolda" , "Stian Thorgersen" > Cc: "mike cirioli" , keycloak-dev at lists.jboss.org > Sent: Thursday, 4 June, 2015 2:40:54 PM > Subject: Re: [keycloak-dev] sticky sessions, clustering, and authentication > > On 6/4/2015 8:09 AM, Marek Posolda wrote: > >> Only solution without sticky sessions are distributed caches (shards). > >> If Google can make it scale to their level it shouldn't be a problem > >> for us either. > > I didn't mean sticky sessions here, but UserSessions/ClientSessions. > > Just trying to compare the performance of replication vs. distribution. > > For large clusters (5+ nodes) distribution is only choice for sure, > > replicating each item to 5 nodes doesn't scale... > > > > However for smaller clusters like 2 nodes, the replication may be better > > choice than distribution though. With distribution, if you really have > > network call per "session.sessions().getClientSession()" you may end > > with 10 network calls per request or so. > >> > >> What we do maybe need to optimize is how many calls there are. For > >> example atm I think we call once to get client session and another for > >> user session. > > +1, maybe we can try to see if ClientSession/UserSession can be saved in > > KeycloakContext. > > > > Just hitting the login screen causes a replication/distribution for > infinispan, db insert for mongo/jpa. There's no way around that because > our authentication layer is decoupled from the login protocol (saml, > oidc) and we need to store protocol specific metadata for use after > authentication is complete. For a replicate Infinispan cache that's not a problem IMO. At long as it's 1 update per request. I really don't think this is an issue. > > Another thought is to store AuthenticationSession into a > signed/encrypted cookie or a query parameter so you could avoid sticky > sessions. Cookies won't work if the flow is split between two browsers. For example we have loads of users that had one primary browser they use, but another browsers that opens links in emails. So for example reset password. I can also see us wanting to add support for using email as a second factor auth mechanism. Query param has issues with the param being huge. I don't think that's a good solution. > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > From stian at redhat.com Thu Jun 4 09:14:31 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 4 Jun 2015 09:14:31 -0400 (EDT) Subject: [keycloak-dev] sticky sessions, clustering, and authentication In-Reply-To: <1069068933.12058336.1433422520138.JavaMail.zimbra@redhat.com> References: <556f927e.870a6b0a.8a15.0c4b@mx.google.com> <556FF4DF.8060009@redhat.com> <1458772596.11846388.1433400824077.JavaMail.zimbra@redhat.com> <55700C1F.2090808@redhat.com> <1337888299.11991094.1433414442504.JavaMail.zimbra@redhat.com> <55703FE6.9070901@redhat.com> <55704756.2070604@redhat.com> <1069068933.12058336.1433422520138.JavaMail.zimbra@redhat.com> Message-ID: <584667920.12072352.1433423671657.JavaMail.zimbra@redhat.com> By the way this is exactly the sort of stuff Inifinspan is built for so we should leverage it ----- Original Message ----- > From: "Stian Thorgersen" > To: "Bill Burke" > Cc: keycloak-dev at lists.jboss.org > Sent: Thursday, 4 June, 2015 2:55:20 PM > Subject: Re: [keycloak-dev] sticky sessions, clustering, and authentication > > > > ----- Original Message ----- > > From: "Bill Burke" > > To: "Marek Posolda" , "Stian Thorgersen" > > > > Cc: "mike cirioli" , keycloak-dev at lists.jboss.org > > Sent: Thursday, 4 June, 2015 2:40:54 PM > > Subject: Re: [keycloak-dev] sticky sessions, clustering, and authentication > > > > On 6/4/2015 8:09 AM, Marek Posolda wrote: > > >> Only solution without sticky sessions are distributed caches (shards). > > >> If Google can make it scale to their level it shouldn't be a problem > > >> for us either. > > > I didn't mean sticky sessions here, but UserSessions/ClientSessions. > > > Just trying to compare the performance of replication vs. distribution. > > > For large clusters (5+ nodes) distribution is only choice for sure, > > > replicating each item to 5 nodes doesn't scale... > > > > > > However for smaller clusters like 2 nodes, the replication may be better > > > choice than distribution though. With distribution, if you really have > > > network call per "session.sessions().getClientSession()" you may end > > > with 10 network calls per request or so. > > >> > > >> What we do maybe need to optimize is how many calls there are. For > > >> example atm I think we call once to get client session and another for > > >> user session. > > > +1, maybe we can try to see if ClientSession/UserSession can be saved in > > > KeycloakContext. > > > > > > > Just hitting the login screen causes a replication/distribution for > > infinispan, db insert for mongo/jpa. There's no way around that because > > our authentication layer is decoupled from the login protocol (saml, > > oidc) and we need to store protocol specific metadata for use after > > authentication is complete. > > For a replicate Infinispan cache that's not a problem IMO. At long as it's 1 > update per request. I really don't think this is an issue. > > > > > Another thought is to store AuthenticationSession into a > > signed/encrypted cookie or a query parameter so you could avoid sticky > > sessions. > > Cookies won't work if the flow is split between two browsers. For example we > have loads of users that had one primary browser they use, but another > browsers that opens links in emails. So for example reset password. I can > also see us wanting to add support for using email as a second factor auth > mechanism. > > Query param has issues with the param being huge. I don't think that's a good > solution. > > > > > > > > > -- > > Bill Burke > > JBoss, a division of Red Hat > > http://bill.burkecentral.com > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bburke at redhat.com Thu Jun 4 09:31:18 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 04 Jun 2015 09:31:18 -0400 Subject: [keycloak-dev] really need logging Message-ID: <55705326.5050707@redhat.com> I can't stand that we only use events for error declaration. I'm trying to debug a problem and all I get is an event message. I have no idea where the problem happening and I have to guess. Its going to be a real issue for us to debug user problems. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Thu Jun 4 09:35:03 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 4 Jun 2015 09:35:03 -0400 (EDT) Subject: [keycloak-dev] really need logging In-Reply-To: <55705326.5050707@redhat.com> References: <55705326.5050707@redhat.com> Message-ID: <1004158745.12085726.1433424903095.JavaMail.zimbra@redhat.com> +1 Event logging only works for high level stuff, would be great to have better debug logging ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Thursday, 4 June, 2015 3:31:18 PM > Subject: [keycloak-dev] really need logging > > I can't stand that we only use events for error declaration. I'm trying > to debug a problem and all I get is an event message. I have no idea > where the problem happening and I have to guess. Its going to be a real > issue for us to debug user problems. > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From mikecirioli at gmail.com Thu Jun 4 13:28:17 2015 From: mikecirioli at gmail.com (mike cirioli) Date: Thu, 04 Jun 2015 13:28:17 -0400 Subject: [keycloak-dev] sticky sessions, clustering, and authentication In-Reply-To: <556FF4DF.8060009@redhat.com> References: <556f927e.870a6b0a.8a15.0c4b@mx.google.com> <556FF4DF.8060009@redhat.com> Message-ID: <55708AB1.4060306@gmail.com> For my use case, we use sticky sessions at the F5 layer, but rely on the inifinspan cache replication in order to do rolling updates of our cluster. Loosing that ability would be a significant impact for us. -mike On 6/4/15 2:49 AM, Marek Posolda wrote: > Question is if the requirement for sticky sessions is not too restrictive? I guess not everyone want to use sticky sessions. > > Maybe we should offer both possibilities (in-memory + sticky sessions OR AuthenticationSession saved in infinispan and replicated after each request) ? > > Another question is if overhead of current replication is really so bad to introduce another abstraction and increase code complexity? > > Marek > > On 4.6.2015 01:49, mike cirioli wrote: >> So sticky sessions would be needed only during the authentication phase, and once complete an underlying clustered session would be created? >> >> On Jun 3, 2015 7:00 PM, Bill Burke wrote: >>> I was thinking a bit about performance in a cluster. Right now a client >>> session is created whenever login is initiated. This ends up requiring >>> the client session to be propagated to the cluster, either through a >>> database insert/update or an infinispan replication. Then, with each >>> authentication/required action step, another insert/update/replication. >>> >>> I was thinking we should have an AuthenticationSession that was in >>> memory only. Then, once all authentication and required actions are >>> finished, then create the usersession and client session. This would >>> require sticky sessions though with a load balancer. >>> >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- For me there is only the traveling on the paths that have heart, on any path that may have heart. There I travel, and the only worthwhile challenge for me is to traverse its full length. And there I travel?looking,looking, breathlessly. --- Don Juan Matus From matthew.casperson at autogeneral.com.au Thu Jun 4 17:54:56 2015 From: matthew.casperson at autogeneral.com.au (Matthew Casperson) Date: Fri, 5 Jun 2015 07:54:56 +1000 Subject: [keycloak-dev] "Windows Security" pop up problem In-Reply-To: <55700F7B.3030602@redhat.com> References: <55700F7B.3030602@redhat.com> Message-ID: > This prompt is displayed when you display keycloak login screen in the browser? Yes (on Windows anyway, not on a Mac). You can cancel it and log as as you would normally with the Keycloak form. > Can you doublecheck that your user federation has "Allow kerberos login" switched to off and there is no "Kerberos" credential in required realm credentials? This is a screenshot of the config. I did play around with kerberos authentication, but it is definitely turned off now. ? On Thu, Jun 4, 2015 at 6:42 PM, Marek Posolda wrote: > On 4.6.2015 01:33, Matthew Casperson wrote: > > We authenticate against a Windows domain using LDAP (and not using > Kerberos). > > In KeyCloak 1.2.0, this prompt now appears when users are asked to log > in. The problem is that this prompt automatically appends the domain to the > username, and I can't see any LDAP property that accepts the domain name. > > We use the sAMAccountName property, which does not include the domain, > and looking at > https://msdn.microsoft.com/en-us/library/windows/desktop/ms677605(v=vs.85).aspx > I don't see any other property that will work with this prompt. > > We might be able to use userPrincipalName, but none of our users have > any experience logging in with an email address, and I'd like to avoid the > training overhead of this if possible. > > So my questions are: > 1. Can I disable this prompt and use the standard keycloak form based > login? > > This prompt is displayed when you display keycloak login screen in the > browser? Can you doublecheck that your user federation has "Allow kerberos > login" switched to off and there is no "Kerberos" credential in required > realm credentials? > > Marek > > 2. Is there an LDAP field that I can define in the keycloak LDAP > federation config that will accept a domain as part of the username? > > > ? > > -- > *Matthew Casperson* > *Senior Front End Developer* > Technology, Space & Distribution > Auto & General Holdings Pty Ltd > P: 07) 3377 8751 (Direct: 3377 8751) > F: 07) 3377 8833 > > > > This email is sent by Auto & General Insurance Company Ltd, Auto & General Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body corporate (Auto & General) and is for the intended addressee. > The views expressed in this email and attachments (email) reflect the views of the stated author but may not reflect views of Auto & General. This email is confidential and subject to copyright. > It may be privileged. If you are not the intended addressee, confidentiality and privilege have not been waived and any use, interference with, or disclosure of this email is unauthorised. > If you are not the intended addressee please immediately notify the sender and then delete the email. Auto & General does not warrant that this email is error or virus free. > > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -- *Matthew Casperson* *Senior Front End Developer* Technology, Space & Distribution Auto & General Holdings Pty Ltd P: 07) 3377 8751 (Direct: 3377 8751) F: 07) 3377 8833 -- This email is sent by Auto & General Insurance Company Ltd, Auto & General Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body corporate (Auto & General) and is for the intended addressee. The views expressed in this email and attachments (email) reflect the views of the stated author but may not reflect views of Auto & General. This email is confidential and subject to copyright. It may be privileged. If you are not the intended addressee, confidentiality and privilege have not been waived and any use, interference with, or disclosure of this email is unauthorised. If you are not the intended addressee please immediately notify the sender and then delete the email. Auto & General does not warrant that this email is error or virus free. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150605/aae932dd/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 23598 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150605/aae932dd/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2015-06-05 at 7.50.53 am.png Type: image/png Size: 119634 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150605/aae932dd/attachment-0003.png From a.mocioi at gmail.com Fri Jun 5 02:18:45 2015 From: a.mocioi at gmail.com (Horia Mocioi) Date: Fri, 5 Jun 2015 09:18:45 +0300 Subject: [keycloak-dev] Admin REST API create new user In-Reply-To: References: Message-ID: Hello and thank you both for your answers. Very complete. Both of them worked. Thank you again, Horia On Thu, Jun 4, 2015 at 2:55 PM, Scott Rossillo wrote: > > Keycloak keycloak = Keycloak.getInstance(?); // your args here > UserRepresentation user = new UserRepresentation(); > > // call user setters > > try { > keycloak.realm(?realm-name").users().create(user); > } finally { > keycloak.close(); > } > > > On Jun 4, 2015, at 6:14 AM, Horia Mocioi wrote: > > Hello, > > I would like to create a user via Admin REST API using HttpPost. > Unfortunately, I was not able to find any example on how to create a user > or role. > > I successfully managed to list roles and user using the example from > admin-access-api, but now I would like to create a new user. > > Can anyone provide an example using HttpPost on how to create a new user? > > Thank you, > Horia > > -- > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150605/095e6eca/attachment.html From stian at redhat.com Fri Jun 5 07:30:54 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 5 Jun 2015 07:30:54 -0400 (EDT) Subject: [keycloak-dev] Admin recovery update In-Reply-To: <1768741884.12679723.1433503731580.JavaMail.zimbra@redhat.com> Message-ID: <851884044.12680348.1433503854720.JavaMail.zimbra@redhat.com> The hope was to use the new offline CLI mode to add reset admin password and import/export operations. However, it turns out to be a bit of a pain in the ass to do so. For now we'll just have a system property that is used to reset admin pass, similar to how import/export works. Hopefully soon we can improve on this and use the offline CLI mode, or alternatively create a custom script that does this. The main issue with these is datasources are not available. From azenk at umn.edu Fri Jun 5 12:32:02 2015 From: azenk at umn.edu (Andrew Zenk) Date: Fri, 5 Jun 2015 11:32:02 -0500 Subject: [keycloak-dev] Question: Loading list of role members via hibernate Message-ID: I am working on providing a read only ldap interface to the keycloak database via a custom partition for apache directory server . In order to properly populate part of the tree, I will need to be able to pull a list of role members from the database. At present I'm using the keycloak/hibernate libraries to access our mysql database directly. This seems to work well for most things. Though, I can't seem to find a way to get from a role id to a list of the roles members. Based on poking around in the code, it seems like there's an easy way to get the roles that a given user is a member of, but not the reverse. Is there a path that I'm missing? If not, I'd be happy to take a stab at implementing it myself. I'm relatively new to hibernate though so it would likely take me a while to get it right. I'd also be open to accessing the keycloak database using a different interface. This just seemed like the best choice for my use case. -- Andrew Zenk, EIT Polar Geospatial Center University of Minnesota Office: (612) 625-0872 Cell: (612) 414-9617 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150605/b69c365a/attachment.html From stian at redhat.com Mon Jun 8 00:53:29 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 8 Jun 2015 00:53:29 -0400 (EDT) Subject: [keycloak-dev] Question: Loading list of role members via hibernate In-Reply-To: References: Message-ID: <893838155.13285905.1433739209964.JavaMail.zimbra@redhat.com> KeycloakSession has two providers that you should deal with RealmProvider (you can get role details from here) and UserProvider (you can get user role mappings from here). Bear in mind that these are internal SPIs and can be changed between releases without any notice. ----- Original Message ----- > From: "Andrew Zenk" > To: keycloak-dev at lists.jboss.org > Sent: Friday, 5 June, 2015 6:32:02 PM > Subject: [keycloak-dev] Question: Loading list of role members via hibernate > > I am working on providing a read only ldap interface to the keycloak database > via a custom partition for apache directory server . In order to properly > populate part of the tree, I will need to be able to pull a list of role > members from the database. > > At present I'm using the keycloak/hibernate libraries to access our mysql > database directly. This seems to work well for most things. Though, I can't > seem to find a way to get from a role id to a list of the roles members. > Based on poking around in the code, it seems like there's an easy way to get > the roles that a given user is a member of, but not the reverse. Is there a > path that I'm missing? If not, I'd be happy to take a stab at implementing > it myself. I'm relatively new to hibernate though so it would likely take me > a while to get it right. > > I'd also be open to accessing the keycloak database using a different > interface. This just seemed like the best choice for my use case. > > -- > Andrew Zenk, EIT > Polar Geospatial Center > University of Minnesota > Office: (612) 625-0872 > Cell: (612) 414-9617 > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Mon Jun 8 03:08:47 2015 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 08 Jun 2015 09:08:47 +0200 Subject: [keycloak-dev] Admin recovery update In-Reply-To: <851884044.12680348.1433503854720.JavaMail.zimbra@redhat.com> References: <851884044.12680348.1433503854720.JavaMail.zimbra@redhat.com> Message-ID: <55753F7F.4030101@redhat.com> I wonder if we can do something like manually parse the DB configuration from the KeycloakDS configuration in standalone.xml/datasource.xml and then use it to manually connect to database . This is really workaround and probably stupid (also considering that datasource can be configured in standalone.xml, domain.xml or in "ds" file in standalone/deployments etc). But maybe it's the easiest way how to get it working:-) Marek On 5.6.2015 13:30, Stian Thorgersen wrote: > The hope was to use the new offline CLI mode to add reset admin password and import/export operations. However, it turns out to be a bit of a pain in the ass to do so. > > For now we'll just have a system property that is used to reset admin pass, similar to how import/export works. > > Hopefully soon we can improve on this and use the offline CLI mode, or alternatively create a custom script that does this. The main issue with these is datasources are not available. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Mon Jun 8 03:15:20 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 8 Jun 2015 03:15:20 -0400 (EDT) Subject: [keycloak-dev] Admin recovery update In-Reply-To: <55753F7F.4030101@redhat.com> References: <851884044.12680348.1433503854720.JavaMail.zimbra@redhat.com> <55753F7F.4030101@redhat.com> Message-ID: <265285339.13317640.1433747720444.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Marek Posolda" > To: "Stian Thorgersen" , "keycloak dev" > Sent: Monday, 8 June, 2015 9:08:47 AM > Subject: Re: [keycloak-dev] Admin recovery update > > I wonder if we can do something like manually parse the DB configuration > from the KeycloakDS configuration in standalone.xml/datasource.xml and > then use it to manually connect to database . This is really workaround > and probably stupid (also considering that datasource can be configured > in standalone.xml, domain.xml or in "ds" file in standalone/deployments > etc). But maybe it's the easiest way how to get it working:-) -1000 That's a horrible idea ;) > > Marek > > On 5.6.2015 13:30, Stian Thorgersen wrote: > > The hope was to use the new offline CLI mode to add reset admin password > > and import/export operations. However, it turns out to be a bit of a pain > > in the ass to do so. > > > > For now we'll just have a system property that is used to reset admin pass, > > similar to how import/export works. > > > > Hopefully soon we can improve on this and use the offline CLI mode, or > > alternatively create a custom script that does this. The main issue with > > these is datasources are not available. > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > From velias at redhat.com Mon Jun 8 05:25:12 2015 From: velias at redhat.com (Vlastimil Elias) Date: Mon, 08 Jun 2015 11:25:12 +0200 Subject: [keycloak-dev] DefaultCacheUserProvider problem Message-ID: <55755F78.4080001@redhat.com> Hi, I just created https://issues.jboss.org/browse/KEYCLOAK-1411 to cover problem with DefaultCacheUserProvider.addUser methods which return UserModel instance which is not cached/managed by the cache. These problems forced us to disable UserCache in our KC instances for now, which is not very good. I believe this problem is a bit serious as it may cause distinct random operational problems when using KC. Can anybody from core KC team look at it, or should I try to patch the problem myself and provide PR? Cheers Vl. -- Vlastimil Elias Principal Software Engineer jboss.org Development Team From g.leon at betiator.com Mon Jun 8 05:29:47 2015 From: g.leon at betiator.com (George Leon) Date: Mon, 08 Jun 2015 12:29:47 +0300 Subject: [keycloak-dev] Couchbase DB support ? Message-ID: <5575608B.8090804@betiator.com> Hi Keycloak Team , We need to add security to our Wildfly 8.2 and we found keycloak. First big question is it production ready ? Second I need to explore options to add Users DB in Couchbase as we use Couchbase for our back-end storage I see Mongo DB is supported . My question is what would it involve to create a Couchbase DB integration we would be happy to and contribute back once we got it working . Any pointers would be nice . Keep up the great work with Keycloak. I see all the videos and documentation very good and helpful. Regards G.Leon, Betiator Athens Greece From stian at redhat.com Mon Jun 8 06:03:46 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 8 Jun 2015 06:03:46 -0400 (EDT) Subject: [keycloak-dev] Couchbase DB support ? In-Reply-To: <5575608B.8090804@betiator.com> References: <5575608B.8090804@betiator.com> Message-ID: <1687702538.13447210.1433757826667.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "George Leon" > To: keycloak-dev at lists.jboss.org > Cc: stratos at betiator.com > Sent: Monday, 8 June, 2015 11:29:47 AM > Subject: [keycloak-dev] Couchbase DB support ? > > Hi Keycloak Team , > > > We need to add security to our Wildfly 8.2 and we found keycloak. First > big question is it production ready ? Yes - do remember it's an open source community project and currently support is only through user mailing list > Second I need to explore options to add Users DB in Couchbase as we use > Couchbase for our back-end storage I see Mongo DB is supported . > My question is what would it involve to create a Couchbase DB > integration we would be happy to and contribute back once we got it > working . > Any pointers would be nice . As you should use another db for your apps and KC I would recommend against this and instead use a RDMBS or Mongo. If you still want to go ahead, bear in mind that we have two separate dbs in KC. Realm (config and clients) and users (user profiles, passwords and role mappings). To add users only you'd have to implement the UserProvider SPI. This is a relatively simple provider to implement, but bear in mind that it's an internal SPI so can be changed without notice. We do not have the resources to maintain Couchbase DB support so we could not accept this as a contribution and you would have to maintain it yourself. > > Keep up the great work with Keycloak. I see all the videos and > documentation very good and helpful. > > Regards > G.Leon, > Betiator > Athens Greece > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From a.mocioi at gmail.com Mon Jun 8 06:37:04 2015 From: a.mocioi at gmail.com (Horia Mocioi) Date: Mon, 8 Jun 2015 13:37:04 +0300 Subject: [keycloak-dev] question about RDBMS Message-ID: Hello, I have configured KC to use MySQL schema and when starting KC it created 48 tables. But in one mail sent on this list (the one about Couchbase DB) I found out that there a 2 dbs. Can you tell where i can find the second one? I mean in the tables created in MySQL I can see both realm and users tables. Is there any other db? Where is it? Thank you, Horia -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150608/a5cf7027/attachment.html From stian at redhat.com Mon Jun 8 06:53:57 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 8 Jun 2015 06:53:57 -0400 (EDT) Subject: [keycloak-dev] question about RDBMS In-Reply-To: References: Message-ID: <2038913635.13472437.1433760837163.JavaMail.zimbra@redhat.com> They can be split, but by default they're not. For example you can store realm config in RDBMS, while users in Mongo. ----- Original Message ----- > From: "Horia Mocioi" > To: keycloak-dev at lists.jboss.org > Sent: Monday, 8 June, 2015 12:37:04 PM > Subject: [keycloak-dev] question about RDBMS > > Hello, > > I have configured KC to use MySQL schema and when starting KC it created 48 > tables. > > But in one mail sent on this list (the one about Couchbase DB) I found out > that there a 2 dbs. Can you tell where i can find the second one? I mean in > the tables created in MySQL I can see both realm and users tables. > > Is there any other db? Where is it? > > Thank you, > Horia > > -- > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From a.mocioi at gmail.com Mon Jun 8 07:11:42 2015 From: a.mocioi at gmail.com (Horia Mocioi) Date: Mon, 8 Jun 2015 14:11:42 +0300 Subject: [keycloak-dev] question about RDBMS In-Reply-To: <2038913635.13472437.1433760837163.JavaMail.zimbra@redhat.com> References: <2038913635.13472437.1433760837163.JavaMail.zimbra@redhat.com> Message-ID: Got it now, thank you. On Mon, Jun 8, 2015 at 1:53 PM, Stian Thorgersen wrote: > They can be split, but by default they're not. For example you can store > realm config in RDBMS, while users in Mongo. > > ----- Original Message ----- > > From: "Horia Mocioi" > > To: keycloak-dev at lists.jboss.org > > Sent: Monday, 8 June, 2015 12:37:04 PM > > Subject: [keycloak-dev] question about RDBMS > > > > Hello, > > > > I have configured KC to use MySQL schema and when starting KC it created > 48 > > tables. > > > > But in one mail sent on this list (the one about Couchbase DB) I found > out > > that there a 2 dbs. Can you tell where i can find the second one? I mean > in > > the tables created in MySQL I can see both realm and users tables. > > > > Is there any other db? Where is it? > > > > Thank you, > > Horia > > > > -- > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150608/49923e1a/attachment.html From velias at redhat.com Mon Jun 8 07:54:11 2015 From: velias at redhat.com (Vlastimil Elias) Date: Mon, 08 Jun 2015 13:54:11 +0200 Subject: [keycloak-dev] How to assign new client default roles to existing users? Message-ID: <55758263.7060402@redhat.com> Hi, we just found one admin use case which is not covered by existing Keycloak and its Admin GUI. When you create new Client later and define some default role/s for it, then there is not any way how to assign these roles to existing users. Problem is that default roles are assigned to users in DB when they are created. Then admin GUI allows to assign roles for one user only, not too useful when you have hundreds or thousands of users ;-) Only workaround for now is to write script which uses REST API to assign new default roles to all existing users. I see these possible solutions: * do not assign default roles in DB when user is created, but assign them dynamically when user roles are asked - possible cons of this solution is that it does not allow to remove default role from concrete/selected users * keep default roles assignment into DB on user create, but automatically assign new default role to all existing users once it is defined for client * keep default roles assignment into DB on user create, but add some manual bulk role assignment action into Admin GUI, which allows admin to assign role to existing users. WDYT, which solution should be better? Cheers Vlastimil -- Vlastimil Elias Principal Software Engineer jboss.org Development Team -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150608/982b242f/attachment.html From stian at redhat.com Mon Jun 8 08:03:06 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 8 Jun 2015 08:03:06 -0400 (EDT) Subject: [keycloak-dev] How to assign new client default roles to existing users? In-Reply-To: <55758263.7060402@redhat.com> References: <55758263.7060402@redhat.com> Message-ID: <88945958.13512691.1433764986138.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Vlastimil Elias" > To: keycloak-dev at lists.jboss.org > Sent: Monday, 8 June, 2015 1:54:11 PM > Subject: [keycloak-dev] How to assign new client default roles to existing users? > > Hi, > > we just found one admin use case which is not covered by existing Keycloak > and its Admin GUI. > > When you create new Client later and define some default role/s for it, then > there is not any way how to assign these roles to existing users. > Problem is that default roles are assigned to users in DB when they are > created. Then admin GUI allows to assign roles for one user only, not too > useful when you have hundreds or thousands of users ;-) > Only workaround for now is to write script which uses REST API to assign new > default roles to all existing users. > > I see these possible solutions: > > > * do not assign default roles in DB when user is created, but assign them > dynamically when user roles are asked - possible cons of this solution > is that it does not allow to remove default role from concrete/selected > users > * keep default roles assignment into DB on user create, but automatically > assign new default role to all existing users once it is defined for > client > * keep default roles assignment into DB on user create, but add some > manual bulk role assignment action into Admin GUI, which allows admin to > assign role to existing users. > > WDYT, which solution should be better? Or, create a composite role called 'default' and have this as the only default role. Afterwards you can map new roles to this composite role and it'll be reflected for all users that have the 'default' role assigned to them. > > Cheers > > Vlastimil > > -- > Vlastimil Elias > Principal Software Engineer > jboss.org Development Team > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From velias at redhat.com Mon Jun 8 08:23:49 2015 From: velias at redhat.com (Vlastimil Elias) Date: Mon, 08 Jun 2015 14:23:49 +0200 Subject: [keycloak-dev] How to assign new client default roles to existing users? In-Reply-To: <88945958.13512691.1433764986138.JavaMail.zimbra@redhat.com> References: <55758263.7060402@redhat.com> <88945958.13512691.1433764986138.JavaMail.zimbra@redhat.com> Message-ID: <55758955.6050200@redhat.com> Nice workaround, thanks for the tip. I though about it also, but I'm not able to assign this new composite default role to all existing users still ;-) So some of solutions for default roles as I proposed should be good. Thanks Vlastimil On 8.6.2015 14:03, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Vlastimil Elias" >> To: keycloak-dev at lists.jboss.org >> Sent: Monday, 8 June, 2015 1:54:11 PM >> Subject: [keycloak-dev] How to assign new client default roles to existing users? >> >> Hi, >> >> we just found one admin use case which is not covered by existing Keycloak >> and its Admin GUI. >> >> When you create new Client later and define some default role/s for it, then >> there is not any way how to assign these roles to existing users. >> Problem is that default roles are assigned to users in DB when they are >> created. Then admin GUI allows to assign roles for one user only, not too >> useful when you have hundreds or thousands of users ;-) >> Only workaround for now is to write script which uses REST API to assign new >> default roles to all existing users. >> >> I see these possible solutions: >> >> >> * do not assign default roles in DB when user is created, but assign them >> dynamically when user roles are asked - possible cons of this solution >> is that it does not allow to remove default role from concrete/selected >> users >> * keep default roles assignment into DB on user create, but automatically >> assign new default role to all existing users once it is defined for >> client >> * keep default roles assignment into DB on user create, but add some >> manual bulk role assignment action into Admin GUI, which allows admin to >> assign role to existing users. >> >> WDYT, which solution should be better? > Or, create a composite role called 'default' and have this as the only default role. Afterwards you can map new roles to this composite role and it'll be reflected for all users that have the 'default' role assigned to them. > >> Cheers >> >> Vlastimil >> >> -- >> Vlastimil Elias >> Principal Software Engineer >> jboss.org Development Team >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Vlastimil Elias Principal Software Engineer jboss.org Development Team From stian at redhat.com Mon Jun 8 08:31:19 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 8 Jun 2015 08:31:19 -0400 (EDT) Subject: [keycloak-dev] How to assign new client default roles to existing users? In-Reply-To: <55758955.6050200@redhat.com> References: <55758263.7060402@redhat.com> <88945958.13512691.1433764986138.JavaMail.zimbra@redhat.com> <55758955.6050200@redhat.com> Message-ID: <856612014.13557300.1433766679390.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Vlastimil Elias" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Monday, 8 June, 2015 2:23:49 PM > Subject: Re: [keycloak-dev] How to assign new client default roles to existing users? > > Nice workaround, thanks for the tip. > I though about it also, but I'm not able to assign this new composite > default role to all existing users still ;-) It's not a workaround, it's what we had in mind when we added default roles and composite roles ;) > > So some of solutions for default roles as I proposed should be good. Neither of your two first proposals are required as using a composite default role gives the same result. What is required though is support for batch updates in admin console. We don't have resources to do that atm though. I'd suggest you create a default composite role. Then afterwards either use the rest api to add this to all existing users or directly update the db (it should be a relatively simple update). > > Thanks > > Vlastimil > > On 8.6.2015 14:03, Stian Thorgersen wrote: > > > > ----- Original Message ----- > >> From: "Vlastimil Elias" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Monday, 8 June, 2015 1:54:11 PM > >> Subject: [keycloak-dev] How to assign new client default roles to existing > >> users? > >> > >> Hi, > >> > >> we just found one admin use case which is not covered by existing Keycloak > >> and its Admin GUI. > >> > >> When you create new Client later and define some default role/s for it, > >> then > >> there is not any way how to assign these roles to existing users. > >> Problem is that default roles are assigned to users in DB when they are > >> created. Then admin GUI allows to assign roles for one user only, not too > >> useful when you have hundreds or thousands of users ;-) > >> Only workaround for now is to write script which uses REST API to assign > >> new > >> default roles to all existing users. > >> > >> I see these possible solutions: > >> > >> > >> * do not assign default roles in DB when user is created, but assign > >> them > >> dynamically when user roles are asked - possible cons of this > >> solution > >> is that it does not allow to remove default role from > >> concrete/selected > >> users > >> * keep default roles assignment into DB on user create, but > >> automatically > >> assign new default role to all existing users once it is defined for > >> client > >> * keep default roles assignment into DB on user create, but add some > >> manual bulk role assignment action into Admin GUI, which allows admin > >> to > >> assign role to existing users. > >> > >> WDYT, which solution should be better? > > Or, create a composite role called 'default' and have this as the only > > default role. Afterwards you can map new roles to this composite role and > > it'll be reflected for all users that have the 'default' role assigned to > > them. > > > >> Cheers > >> > >> Vlastimil > >> > >> -- > >> Vlastimil Elias > >> Principal Software Engineer > >> jboss.org Development Team > >> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -- > Vlastimil Elias > Principal Software Engineer > jboss.org Development Team > > From velias at redhat.com Mon Jun 8 08:49:49 2015 From: velias at redhat.com (Vlastimil Elias) Date: Mon, 08 Jun 2015 14:49:49 +0200 Subject: [keycloak-dev] How to assign new client default roles to existing users? In-Reply-To: <856612014.13557300.1433766679390.JavaMail.zimbra@redhat.com> References: <55758263.7060402@redhat.com> <88945958.13512691.1433764986138.JavaMail.zimbra@redhat.com> <55758955.6050200@redhat.com> <856612014.13557300.1433766679390.JavaMail.zimbra@redhat.com> Message-ID: <55758F6D.9060709@redhat.com> Thanks for the clarification of composite roles, I'll use it. I agree that batch role updates in Admin GUI should be good solution, and I understand resource constraint. Cheers Vlastimil On 8.6.2015 14:31, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Vlastimil Elias" >> To: "Stian Thorgersen" >> Cc: keycloak-dev at lists.jboss.org >> Sent: Monday, 8 June, 2015 2:23:49 PM >> Subject: Re: [keycloak-dev] How to assign new client default roles to existing users? >> >> Nice workaround, thanks for the tip. >> I though about it also, but I'm not able to assign this new composite >> default role to all existing users still ;-) > It's not a workaround, it's what we had in mind when we added default roles and composite roles ;) > >> So some of solutions for default roles as I proposed should be good. > Neither of your two first proposals are required as using a composite default role gives the same result. What is required though is support for batch updates in admin console. We don't have resources to do that atm though. I'd suggest you create a default composite role. Then afterwards either use the rest api to add this to all existing users or directly update the db (it should be a relatively simple update). > >> Thanks >> >> Vlastimil >> >> On 8.6.2015 14:03, Stian Thorgersen wrote: >>> ----- Original Message ----- >>>> From: "Vlastimil Elias" >>>> To: keycloak-dev at lists.jboss.org >>>> Sent: Monday, 8 June, 2015 1:54:11 PM >>>> Subject: [keycloak-dev] How to assign new client default roles to existing >>>> users? >>>> >>>> Hi, >>>> >>>> we just found one admin use case which is not covered by existing Keycloak >>>> and its Admin GUI. >>>> >>>> When you create new Client later and define some default role/s for it, >>>> then >>>> there is not any way how to assign these roles to existing users. >>>> Problem is that default roles are assigned to users in DB when they are >>>> created. Then admin GUI allows to assign roles for one user only, not too >>>> useful when you have hundreds or thousands of users ;-) >>>> Only workaround for now is to write script which uses REST API to assign >>>> new >>>> default roles to all existing users. >>>> >>>> I see these possible solutions: >>>> >>>> >>>> * do not assign default roles in DB when user is created, but assign >>>> them >>>> dynamically when user roles are asked - possible cons of this >>>> solution >>>> is that it does not allow to remove default role from >>>> concrete/selected >>>> users >>>> * keep default roles assignment into DB on user create, but >>>> automatically >>>> assign new default role to all existing users once it is defined for >>>> client >>>> * keep default roles assignment into DB on user create, but add some >>>> manual bulk role assignment action into Admin GUI, which allows admin >>>> to >>>> assign role to existing users. >>>> >>>> WDYT, which solution should be better? >>> Or, create a composite role called 'default' and have this as the only >>> default role. Afterwards you can map new roles to this composite role and >>> it'll be reflected for all users that have the 'default' role assigned to >>> them. >>> >>>> Cheers >>>> >>>> Vlastimil >>>> >>>> -- >>>> Vlastimil Elias >>>> Principal Software Engineer >>>> jboss.org Development Team >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> -- >> Vlastimil Elias >> Principal Software Engineer >> jboss.org Development Team >> >> -- Vlastimil Elias Principal Software Engineer jboss.org Development Team From stian at redhat.com Mon Jun 8 09:08:34 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 8 Jun 2015 09:08:34 -0400 (EDT) Subject: [keycloak-dev] How to assign new client default roles to existing users? In-Reply-To: <55758F6D.9060709@redhat.com> References: <55758263.7060402@redhat.com> <88945958.13512691.1433764986138.JavaMail.zimbra@redhat.com> <55758955.6050200@redhat.com> <856612014.13557300.1433766679390.JavaMail.zimbra@redhat.com> <55758F6D.9060709@redhat.com> Message-ID: <1203882130.13634151.1433768914033.JavaMail.zimbra@redhat.com> I thought we had an issue for batch updates, but couldn't find one so added https://issues.jboss.org/browse/KEYCLOAK-1413. ----- Original Message ----- > From: "Vlastimil Elias" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Monday, 8 June, 2015 2:49:49 PM > Subject: Re: [keycloak-dev] How to assign new client default roles to existing users? > > Thanks for the clarification of composite roles, I'll use it. > I agree that batch role updates in Admin GUI should be good solution, > and I understand resource constraint. > > Cheers > > Vlastimil > > On 8.6.2015 14:31, Stian Thorgersen wrote: > > > > ----- Original Message ----- > >> From: "Vlastimil Elias" > >> To: "Stian Thorgersen" > >> Cc: keycloak-dev at lists.jboss.org > >> Sent: Monday, 8 June, 2015 2:23:49 PM > >> Subject: Re: [keycloak-dev] How to assign new client default roles to > >> existing users? > >> > >> Nice workaround, thanks for the tip. > >> I though about it also, but I'm not able to assign this new composite > >> default role to all existing users still ;-) > > It's not a workaround, it's what we had in mind when we added default roles > > and composite roles ;) > > > >> So some of solutions for default roles as I proposed should be good. > > Neither of your two first proposals are required as using a composite > > default role gives the same result. What is required though is support for > > batch updates in admin console. We don't have resources to do that atm > > though. I'd suggest you create a default composite role. Then afterwards > > either use the rest api to add this to all existing users or directly > > update the db (it should be a relatively simple update). > > > >> Thanks > >> > >> Vlastimil > >> > >> On 8.6.2015 14:03, Stian Thorgersen wrote: > >>> ----- Original Message ----- > >>>> From: "Vlastimil Elias" > >>>> To: keycloak-dev at lists.jboss.org > >>>> Sent: Monday, 8 June, 2015 1:54:11 PM > >>>> Subject: [keycloak-dev] How to assign new client default roles to > >>>> existing > >>>> users? > >>>> > >>>> Hi, > >>>> > >>>> we just found one admin use case which is not covered by existing > >>>> Keycloak > >>>> and its Admin GUI. > >>>> > >>>> When you create new Client later and define some default role/s for it, > >>>> then > >>>> there is not any way how to assign these roles to existing users. > >>>> Problem is that default roles are assigned to users in DB when they are > >>>> created. Then admin GUI allows to assign roles for one user only, not > >>>> too > >>>> useful when you have hundreds or thousands of users ;-) > >>>> Only workaround for now is to write script which uses REST API to assign > >>>> new > >>>> default roles to all existing users. > >>>> > >>>> I see these possible solutions: > >>>> > >>>> > >>>> * do not assign default roles in DB when user is created, but > >>>> assign > >>>> them > >>>> dynamically when user roles are asked - possible cons of this > >>>> solution > >>>> is that it does not allow to remove default role from > >>>> concrete/selected > >>>> users > >>>> * keep default roles assignment into DB on user create, but > >>>> automatically > >>>> assign new default role to all existing users once it is defined > >>>> for > >>>> client > >>>> * keep default roles assignment into DB on user create, but add > >>>> some > >>>> manual bulk role assignment action into Admin GUI, which allows > >>>> admin > >>>> to > >>>> assign role to existing users. > >>>> > >>>> WDYT, which solution should be better? > >>> Or, create a composite role called 'default' and have this as the only > >>> default role. Afterwards you can map new roles to this composite role and > >>> it'll be reflected for all users that have the 'default' role assigned to > >>> them. > >>> > >>>> Cheers > >>>> > >>>> Vlastimil > >>>> > >>>> -- > >>>> Vlastimil Elias > >>>> Principal Software Engineer > >>>> jboss.org Development Team > >>>> > >>>> _______________________________________________ > >>>> keycloak-dev mailing list > >>>> keycloak-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> -- > >> Vlastimil Elias > >> Principal Software Engineer > >> jboss.org Development Team > >> > >> > > -- > Vlastimil Elias > Principal Software Engineer > jboss.org Development Team > > From g.leon at betiator.com Tue Jun 9 07:03:45 2015 From: g.leon at betiator.com (George Leon) Date: Tue, 09 Jun 2015 14:03:45 +0300 Subject: [keycloak-dev] Keycloak benchmarks / Performance Guide Message-ID: <5576C811.8010906@betiator.com> Hi Keycloak Team , We are evaluating to use in production and have 2) questions 1) Any information on Keycloak benchmarks would help us decide what Hardware we will need for example 1 Wildfly/Keycloak server with 4 cores CPU with 8GB memory and 1 separate Mysql DB with 4 cores CPU with 8GB with JDBC data connection pooling set to 30 connections say for example can handle ?????? concurrent user longings . 2) What server-cache is used and what control will we have like configuration options other than maxSize Also what unit is maxSize memory in ? Docs Reference : http://keycloak.github.io/docs/userguide/html/server_cache.html Thanks again and Great work with Keycloak G.Leon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150609/78778df4/attachment.html From stian at redhat.com Tue Jun 9 07:19:53 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 9 Jun 2015 07:19:53 -0400 (EDT) Subject: [keycloak-dev] Keycloak benchmarks / Performance Guide In-Reply-To: <5576C811.8010906@betiator.com> References: <5576C811.8010906@betiator.com> Message-ID: <786162699.14346288.1433848793872.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "George Leon" > To: keycloak-dev at lists.jboss.org > Cc: "George Karoulas" , stratos at betiator.com > Sent: Tuesday, 9 June, 2015 1:03:45 PM > Subject: [keycloak-dev] Keycloak benchmarks / Performance Guide > > Hi Keycloak Team , > > We are evaluating to use in production and have 2) questions > > 1) > Any information on Keycloak benchmarks would help us decide what Hardware > we will need for example > 1 Wildfly/Keycloak server with 4 cores CPU with 8GB memory and > 1 separate Mysql DB with 4 cores CPU with 8GB with JDBC data connection > pooling set to 30 connections say > for example can handle ?????? concurrent user longings . We have only done limited benchmarks currently and what hardware you need would be very related to what your usage is (number of users, how often they login/logout, token timeouts etc.). In production you should consider having a cluster with at least 2 nodes for availability, this would also help with performance. Keycloak doesn't require a sticky load balancer, services can verify tokens without request to KC, etc. so it should scale well. > > 2) > What server-cache is used and what control will we have like configuration > options other than maxSize > Also what unit is maxSize memory in ? In production I recommend using the Infinispan cache, not the basic in-mem cache. This will also give you more control of cache eviction, etc.. See http://keycloak.github.io/docs/userguide/html/clustering.html > Docs Reference : > http://keycloak.github.io/docs/userguide/html/server_cache.html Thanks again > and Great work with Keycloak > G.Leon > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Tue Jun 9 07:40:28 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 9 Jun 2015 07:40:28 -0400 (EDT) Subject: [keycloak-dev] keycloak-dev is not for user-related issues In-Reply-To: <844141137.14354676.1433849940790.JavaMail.zimbra@redhat.com> Message-ID: <1025810.14355104.1433850028962.JavaMail.zimbra@redhat.com> Please, refrain from using keycloak-dev mailing list for user-related issues. This mailing list is for discussing development-related issues and is mainly aimed at core Keycloak developers and contributors. For user-related issues please use the keycloak-user mailing list (https://lists.jboss.org/mailman/listinfo/keycloak-user). Thanks, Stian From giriraj.sharma27 at gmail.com Tue Jun 9 16:33:07 2015 From: giriraj.sharma27 at gmail.com (Giriraj Sharma) Date: Wed, 10 Jun 2015 02:03:07 +0530 Subject: [keycloak-dev] Enabling SSL over keycloak/wildfly server Message-ID: When Let?s Encrypt based on ACME (Automated Certificate Management Environment) spec launches in mid-2015, enabling HTTPS for any site will be as easy as installing a small piece of certificate management software on the server: $ sudo apt-get install lets-encrypt $ lets-encrypt example.com That?s all there is to it! https://example.com is immediately live. Automatic renew and on demand revocation are equally easier. A sample let's encrypt SSL client demo is here . For documentation, check here . Let's encrypt is free, open and automated with out of box support for apache/nginx and standalone support for other web servers. It automatically configures an app deployed on apache or nginx with a single command with absolute no human intervention. Its stand alone mode (for other web servers) generates SSL cert for the app(domain) which can be manually configured/installed or a better method will be installation via an automated script(like for keycloak server). Currently, Let?s Encrypt provides a developer preview only intended for testers and developers. It, at present installs certs signed by the TEST CA, which might generate exception warnings in client browsers. But, they have announced to come out with final solution by Mid 2015. As Keycloak will be requiring SSL, let's encrypt standalone support with a script for automatic installation of cert on keycloak/wildfly server might come out as one easier rescue. Cheers, -- Giriraj Sharma about.me/girirajsharma Giriraj Sharma, Department of Computer Science National Institute of Technology Hamirpur Himachal Pradesh, India 177005 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150610/14dd958d/attachment-0001.html From stian at redhat.com Wed Jun 10 03:19:27 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 10 Jun 2015 03:19:27 -0400 (EDT) Subject: [keycloak-dev] Hide internal clients and roles In-Reply-To: <1366571983.14983549.1433920553133.JavaMail.zimbra@redhat.com> Message-ID: <2031633068.14985543.1433920767880.JavaMail.zimbra@redhat.com> I propose we add an attribute 'kc_internal' to internal clients (security-admin-console, master-realm, account, broker) and hide these from the clients table. We should also do this to internal roles 'admin' and 'create-realm' so these roles are not displayed in realm roles list. They would only be hidden from this page, but still be visible in user role mapping, scope mappings and default roles. From velias at redhat.com Wed Jun 10 07:39:53 2015 From: velias at redhat.com (Vlastimil Elias) Date: Wed, 10 Jun 2015 13:39:53 +0200 Subject: [keycloak-dev] Hide internal clients and roles In-Reply-To: <2031633068.14985543.1433920767880.JavaMail.zimbra@redhat.com> References: <2031633068.14985543.1433920767880.JavaMail.zimbra@redhat.com> Message-ID: <55782209.4010605@redhat.com> Please keep at least 'account' client visible. I can imagine usecases when KC admin wants to disable it. Also it will be hard to find correct URL of the account management app if it will be hidden. Cheers Vl. On 10.6.2015 09:19, Stian Thorgersen wrote: > I propose we add an attribute 'kc_internal' to internal clients (security-admin-console, master-realm, account, broker) and hide these from the clients table. > > We should also do this to internal roles 'admin' and 'create-realm' so these roles are not displayed in realm roles list. They would only be hidden from this page, but still be visible in user role mapping, scope mappings and default roles. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Vlastimil Elias Principal Software Engineer jboss.org Development Team From mposolda at redhat.com Wed Jun 10 09:46:23 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 10 Jun 2015 15:46:23 +0200 Subject: [keycloak-dev] Hide internal clients and roles In-Reply-To: <2031633068.14985543.1433920767880.JavaMail.zimbra@redhat.com> References: <2031633068.14985543.1433920767880.JavaMail.zimbra@redhat.com> Message-ID: <55783FAF.7060807@redhat.com> I am like 50/50 . I can imagine this has some advantages as people won't be easily able to delete system clients/roles and break their keycloak server. On the other hand, when I am admin, I might be confused why some roles are not in the roles list, but are in default roles list etc? Also if someone really knows what he is doing, this might be unwanted restriction - for example people may want to add more composite roles into "admin" role or they want to disable account client as Vlasta pointed etc. Marek On 10.6.2015 09:19, Stian Thorgersen wrote: > I propose we add an attribute 'kc_internal' to internal clients (security-admin-console, master-realm, account, broker) and hide these from the clients table. > > We should also do this to internal roles 'admin' and 'create-realm' so these roles are not displayed in realm roles list. They would only be hidden from this page, but still be visible in user role mapping, scope mappings and default roles. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Wed Jun 10 09:48:27 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 10 Jun 2015 09:48:27 -0400 (EDT) Subject: [keycloak-dev] Hide internal clients and roles In-Reply-To: <55783FAF.7060807@redhat.com> References: <2031633068.14985543.1433920767880.JavaMail.zimbra@redhat.com> <55783FAF.7060807@redhat.com> Message-ID: <2006215136.15340623.1433944107137.JavaMail.zimbra@redhat.com> Maybe by default we hide them, but have an option to view? Disabling account client is probably better done with a realm option than removing the client though. ----- Original Message ----- > From: "Marek Posolda" > To: "Stian Thorgersen" , "keycloak dev" > Sent: Wednesday, 10 June, 2015 3:46:23 PM > Subject: Re: [keycloak-dev] Hide internal clients and roles > > I am like 50/50 . I can imagine this has some advantages as people won't > be easily able to delete system clients/roles and break their keycloak > server. > > On the other hand, when I am admin, I might be confused why some roles > are not in the roles list, but are in default roles list etc? Also if > someone really knows what he is doing, this might be unwanted > restriction - for example people may want to add more composite roles > into "admin" role or they want to disable account client as Vlasta > pointed etc. > > Marek > > On 10.6.2015 09:19, Stian Thorgersen wrote: > > I propose we add an attribute 'kc_internal' to internal clients > > (security-admin-console, master-realm, account, broker) and hide these > > from the clients table. > > > > We should also do this to internal roles 'admin' and 'create-realm' so > > these roles are not displayed in realm roles list. They would only be > > hidden from this page, but still be visible in user role mapping, scope > > mappings and default roles. > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > From mposolda at redhat.com Wed Jun 10 09:56:36 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 10 Jun 2015 15:56:36 +0200 Subject: [keycloak-dev] Hide internal clients and roles In-Reply-To: <2006215136.15340623.1433944107137.JavaMail.zimbra@redhat.com> References: <2031633068.14985543.1433920767880.JavaMail.zimbra@redhat.com> <55783FAF.7060807@redhat.com> <2006215136.15340623.1433944107137.JavaMail.zimbra@redhat.com> Message-ID: <55784214.9040200@redhat.com> On 10.6.2015 15:48, Stian Thorgersen wrote: > Maybe by default we hide them, but have an option to view? yeah. Or display them in the list, but with some different color/flag and when someone click on it, it will display some confirmation dialog with "You are trying to access internal client. Are you sure you know what are doing?" or something like that. But I am not sure about the usability of this though... Marek > > Disabling account client is probably better done with a realm option than removing the client though. > > ----- Original Message ----- >> From: "Marek Posolda" >> To: "Stian Thorgersen" , "keycloak dev" >> Sent: Wednesday, 10 June, 2015 3:46:23 PM >> Subject: Re: [keycloak-dev] Hide internal clients and roles >> >> I am like 50/50 . I can imagine this has some advantages as people won't >> be easily able to delete system clients/roles and break their keycloak >> server. >> >> On the other hand, when I am admin, I might be confused why some roles >> are not in the roles list, but are in default roles list etc? Also if >> someone really knows what he is doing, this might be unwanted >> restriction - for example people may want to add more composite roles >> into "admin" role or they want to disable account client as Vlasta >> pointed etc. >> >> Marek >> >> On 10.6.2015 09:19, Stian Thorgersen wrote: >>> I propose we add an attribute 'kc_internal' to internal clients >>> (security-admin-console, master-realm, account, broker) and hide these >>> from the clients table. >>> >>> We should also do this to internal roles 'admin' and 'create-realm' so >>> these roles are not displayed in realm roles list. They would only be >>> hidden from this page, but still be visible in user role mapping, scope >>> mappings and default roles. >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From stian at redhat.com Wed Jun 10 10:02:08 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 10 Jun 2015 10:02:08 -0400 (EDT) Subject: [keycloak-dev] Hide internal clients and roles In-Reply-To: <55784214.9040200@redhat.com> References: <2031633068.14985543.1433920767880.JavaMail.zimbra@redhat.com> <55783FAF.7060807@redhat.com> <2006215136.15340623.1433944107137.JavaMail.zimbra@redhat.com> <55784214.9040200@redhat.com> Message-ID: <1879334887.15355804.1433944928769.JavaMail.zimbra@redhat.com> I think we should make the console easier to use for regular users so I reckon we should not display them by default, then have an option to view them for advanced users. This would also allow us to have a "Blank Slate" page when a user installs a new server or creates a new realm. In this case instead of showing an empty table we can show a piece of text that describes what clients are, etc. This was one of the recommendations we got from UXC guys (see https://www.patternfly.org/patterns/blank-slate/) ----- Original Message ----- > From: "Marek Posolda" > To: "Stian Thorgersen" > Cc: "keycloak dev" > Sent: Wednesday, 10 June, 2015 3:56:36 PM > Subject: Re: [keycloak-dev] Hide internal clients and roles > > On 10.6.2015 15:48, Stian Thorgersen wrote: > > Maybe by default we hide them, but have an option to view? > yeah. Or display them in the list, but with some different color/flag > and when someone click on it, it will display some confirmation dialog > with "You are trying to access internal client. Are you sure you know > what are doing?" or something like that. But I am not sure about the > usability of this though... > > Marek > > > > Disabling account client is probably better done with a realm option than > > removing the client though. > > > > ----- Original Message ----- > >> From: "Marek Posolda" > >> To: "Stian Thorgersen" , "keycloak dev" > >> > >> Sent: Wednesday, 10 June, 2015 3:46:23 PM > >> Subject: Re: [keycloak-dev] Hide internal clients and roles > >> > >> I am like 50/50 . I can imagine this has some advantages as people won't > >> be easily able to delete system clients/roles and break their keycloak > >> server. > >> > >> On the other hand, when I am admin, I might be confused why some roles > >> are not in the roles list, but are in default roles list etc? Also if > >> someone really knows what he is doing, this might be unwanted > >> restriction - for example people may want to add more composite roles > >> into "admin" role or they want to disable account client as Vlasta > >> pointed etc. > >> > >> Marek > >> > >> On 10.6.2015 09:19, Stian Thorgersen wrote: > >>> I propose we add an attribute 'kc_internal' to internal clients > >>> (security-admin-console, master-realm, account, broker) and hide these > >>> from the clients table. > >>> > >>> We should also do this to internal roles 'admin' and 'create-realm' so > >>> these roles are not displayed in realm roles list. They would only be > >>> hidden from this page, but still be visible in user role mapping, scope > >>> mappings and default roles. > >>> _______________________________________________ > >>> keycloak-dev mailing list > >>> keycloak-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > From mposolda at redhat.com Wed Jun 10 10:07:36 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 10 Jun 2015 16:07:36 +0200 Subject: [keycloak-dev] Hide internal clients and roles In-Reply-To: <1879334887.15355804.1433944928769.JavaMail.zimbra@redhat.com> References: <2031633068.14985543.1433920767880.JavaMail.zimbra@redhat.com> <55783FAF.7060807@redhat.com> <2006215136.15340623.1433944107137.JavaMail.zimbra@redhat.com> <55784214.9040200@redhat.com> <1879334887.15355804.1433944928769.JavaMail.zimbra@redhat.com> Message-ID: <557844A8.4090800@redhat.com> +1 On 10.6.2015 16:02, Stian Thorgersen wrote: > I think we should make the console easier to use for regular users so I reckon we should not display them by default, then have an option to view them for advanced users. > > This would also allow us to have a "Blank Slate" page when a user installs a new server or creates a new realm. In this case instead of showing an empty table we can show a piece of text that describes what clients are, etc. This was one of the recommendations we got from UXC guys (see https://www.patternfly.org/patterns/blank-slate/) > > ----- Original Message ----- >> From: "Marek Posolda" >> To: "Stian Thorgersen" >> Cc: "keycloak dev" >> Sent: Wednesday, 10 June, 2015 3:56:36 PM >> Subject: Re: [keycloak-dev] Hide internal clients and roles >> >> On 10.6.2015 15:48, Stian Thorgersen wrote: >>> Maybe by default we hide them, but have an option to view? >> yeah. Or display them in the list, but with some different color/flag >> and when someone click on it, it will display some confirmation dialog >> with "You are trying to access internal client. Are you sure you know >> what are doing?" or something like that. But I am not sure about the >> usability of this though... >> >> Marek >>> Disabling account client is probably better done with a realm option than >>> removing the client though. >>> >>> ----- Original Message ----- >>>> From: "Marek Posolda" >>>> To: "Stian Thorgersen" , "keycloak dev" >>>> >>>> Sent: Wednesday, 10 June, 2015 3:46:23 PM >>>> Subject: Re: [keycloak-dev] Hide internal clients and roles >>>> >>>> I am like 50/50 . I can imagine this has some advantages as people won't >>>> be easily able to delete system clients/roles and break their keycloak >>>> server. >>>> >>>> On the other hand, when I am admin, I might be confused why some roles >>>> are not in the roles list, but are in default roles list etc? Also if >>>> someone really knows what he is doing, this might be unwanted >>>> restriction - for example people may want to add more composite roles >>>> into "admin" role or they want to disable account client as Vlasta >>>> pointed etc. >>>> >>>> Marek >>>> >>>> On 10.6.2015 09:19, Stian Thorgersen wrote: >>>>> I propose we add an attribute 'kc_internal' to internal clients >>>>> (security-admin-console, master-realm, account, broker) and hide these >>>>> from the clients table. >>>>> >>>>> We should also do this to internal roles 'admin' and 'create-realm' so >>>>> these roles are not displayed in realm roles list. They would only be >>>>> hidden from this page, but still be visible in user role mapping, scope >>>>> mappings and default roles. >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From bburke at redhat.com Wed Jun 10 10:08:16 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 10 Jun 2015 10:08:16 -0400 Subject: [keycloak-dev] Hide internal clients and roles In-Reply-To: <55783FAF.7060807@redhat.com> References: <2031633068.14985543.1433920767880.JavaMail.zimbra@redhat.com> <55783FAF.7060807@redhat.com> Message-ID: <557844D0.3010004@redhat.com> I think security-admin-console and realm-management should be merged in non-Master realms. In master realm, rename everything to -security-admin-console. Finally, an internal role or client would not be able to be deleted. I don't think you should hide any roles ever. I don't see why you would want to. I do think you should make internal clients and roles unremovable. On 6/10/2015 9:46 AM, Marek Posolda wrote: > I am like 50/50 . I can imagine this has some advantages as people won't > be easily able to delete system clients/roles and break their keycloak > server. > > On the other hand, when I am admin, I might be confused why some roles > are not in the roles list, but are in default roles list etc? Also if > someone really knows what he is doing, this might be unwanted > restriction - for example people may want to add more composite roles > into "admin" role or they want to disable account client as Vlasta > pointed etc. > > Marek > > On 10.6.2015 09:19, Stian Thorgersen wrote: >> I propose we add an attribute 'kc_internal' to internal clients (security-admin-console, master-realm, account, broker) and hide these from the clients table. >> >> We should also do this to internal roles 'admin' and 'create-realm' so these roles are not displayed in realm roles list. They would only be hidden from this page, but still be visible in user role mapping, scope mappings and default roles. >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Wed Jun 10 10:15:48 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 10 Jun 2015 10:15:48 -0400 (EDT) Subject: [keycloak-dev] Hide internal clients and roles In-Reply-To: <557844D0.3010004@redhat.com> References: <2031633068.14985543.1433920767880.JavaMail.zimbra@redhat.com> <55783FAF.7060807@redhat.com> <557844D0.3010004@redhat.com> Message-ID: <1607122411.15372251.1433945748101.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Wednesday, 10 June, 2015 4:08:16 PM > Subject: Re: [keycloak-dev] Hide internal clients and roles > > I think security-admin-console and realm-management should be merged in > non-Master realms. In master realm, rename everything to > -security-admin-console. Finally, an internal role or client > would not be able to be deleted. > > I don't think you should hide any roles ever. I don't see why you would > want to. I do think you should make internal clients and roles unremovable. Hiding the internal realm roles would enable a "blank slate" page on the realm roles list. Alternatively, and I actually think this is a better idea, is to make the admin and create-realm roles roles of the master-security-admin-console realm rather than realm roles. In that case all we need is "internal" clients and an option to view/hide them on the clients list. Which one is it btw "an internal role or client would not be able to be deleted" or "I do think you should make internal clients and roles unremovable"? > > > > On 6/10/2015 9:46 AM, Marek Posolda wrote: > > I am like 50/50 . I can imagine this has some advantages as people won't > > be easily able to delete system clients/roles and break their keycloak > > server. > > > > On the other hand, when I am admin, I might be confused why some roles > > are not in the roles list, but are in default roles list etc? Also if > > someone really knows what he is doing, this might be unwanted > > restriction - for example people may want to add more composite roles > > into "admin" role or they want to disable account client as Vlasta > > pointed etc. > > > > Marek > > > > On 10.6.2015 09:19, Stian Thorgersen wrote: > >> I propose we add an attribute 'kc_internal' to internal clients > >> (security-admin-console, master-realm, account, broker) and hide these > >> from the clients table. > >> > >> We should also do this to internal roles 'admin' and 'create-realm' so > >> these roles are not displayed in realm roles list. They would only be > >> hidden from this page, but still be visible in user role mapping, scope > >> mappings and default roles. > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From ssilvert at redhat.com Wed Jun 10 10:34:21 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Wed, 10 Jun 2015 10:34:21 -0400 Subject: [keycloak-dev] Hide internal clients and roles In-Reply-To: <1607122411.15372251.1433945748101.JavaMail.zimbra@redhat.com> References: <2031633068.14985543.1433920767880.JavaMail.zimbra@redhat.com> <55783FAF.7060807@redhat.com> <557844D0.3010004@redhat.com> <1607122411.15372251.1433945748101.JavaMail.zimbra@redhat.com> Message-ID: <55784AED.2020208@redhat.com> On 6/10/2015 10:15 AM, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Wednesday, 10 June, 2015 4:08:16 PM >> Subject: Re: [keycloak-dev] Hide internal clients and roles >> >> I think security-admin-console and realm-management should be merged in >> non-Master realms. In master realm, rename everything to >> -security-admin-console. Finally, an internal role or client >> would not be able to be deleted. >> >> I don't think you should hide any roles ever. I don't see why you would >> want to. I do think you should make internal clients and roles unremovable. > Hiding the internal realm roles would enable a "blank slate" page on the realm roles list. Alternatively, and I actually think this is a better idea, is to make the admin and create-realm roles roles of the master-security-admin-console realm rather than realm roles. In that case all we need is "internal" clients and an option to view/hide them on the clients list. > > Which one is it btw "an internal role or client would not be able to be deleted" or "I do think you should make internal clients and roles unremovable"? I'm not sure I understand what you are saying here. I think I agree with Bill on this one. First principle is that you should never be able to do something from the UI that cripples the operation of the system. But what applies to the UI also applies to the API. Operations like deleting the admin user or deleting the admin role should be forbidden at both the UI and the API level. I don't understand how hiding things helps the user. Instead, keep them visible and thus encourage the user to learn about them. > >> >> >> On 6/10/2015 9:46 AM, Marek Posolda wrote: >>> I am like 50/50 . I can imagine this has some advantages as people won't >>> be easily able to delete system clients/roles and break their keycloak >>> server. >>> >>> On the other hand, when I am admin, I might be confused why some roles >>> are not in the roles list, but are in default roles list etc? Also if >>> someone really knows what he is doing, this might be unwanted >>> restriction - for example people may want to add more composite roles >>> into "admin" role or they want to disable account client as Vlasta >>> pointed etc. >>> >>> Marek >>> >>> On 10.6.2015 09:19, Stian Thorgersen wrote: >>>> I propose we add an attribute 'kc_internal' to internal clients >>>> (security-admin-console, master-realm, account, broker) and hide these >>>> from the clients table. >>>> >>>> We should also do this to internal roles 'admin' and 'create-realm' so >>>> these roles are not displayed in realm roles list. They would only be >>>> hidden from this page, but still be visible in user role mapping, scope >>>> mappings and default roles. >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Wed Jun 10 10:39:11 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 10 Jun 2015 10:39:11 -0400 Subject: [keycloak-dev] Hide internal clients and roles In-Reply-To: <1607122411.15372251.1433945748101.JavaMail.zimbra@redhat.com> References: <2031633068.14985543.1433920767880.JavaMail.zimbra@redhat.com> <55783FAF.7060807@redhat.com> <557844D0.3010004@redhat.com> <1607122411.15372251.1433945748101.JavaMail.zimbra@redhat.com> Message-ID: <55784C0F.5080103@redhat.com> On 6/10/2015 10:15 AM, Stian Thorgersen wrote: > > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Wednesday, 10 June, 2015 4:08:16 PM >> Subject: Re: [keycloak-dev] Hide internal clients and roles >> >> I think security-admin-console and realm-management should be merged in >> non-Master realms. In master realm, rename everything to >> -security-admin-console. Finally, an internal role or client >> would not be able to be deleted. >> >> I don't think you should hide any roles ever. I don't see why you would >> want to. I do think you should make internal clients and roles unremovable. > > Hiding the internal realm roles would enable a "blank slate" page on the realm roles list. Alternatively, and I actually think this is a better idea, is to make the admin and create-realm roles roles of the master-security-admin-console realm rather than realm roles. In that case all we need is "internal" clients and an option to view/hide them on the clients list. > Do you like the idea of merging security-admin-console and realm-management? +1 to moving "admin" and "create-realm" to master-security-admin-console. The "blank slate" page could be displayed if there is no *non* internal-clients/roles. There could be a button or link on the Blank Slate page "View built-in clients" along with "create client". I don't know if it is better to have a "hide built-in clients" checkbox on the client list page, or to just show them by default. > Which one is it btw "an internal role or client would not be able to be deleted" or "I do think you should make internal clients and roles unremovable"? Sorry, I repeated myself without realizing. internal things should not be deletable or removable, right? -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Wed Jun 10 10:48:17 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 10 Jun 2015 10:48:17 -0400 Subject: [keycloak-dev] verify email is skipped if no email Message-ID: <55784E31.3010104@redhat.com> The verify email required action is skipped if the user has no email. Is this the right behavior? Should the user instead be required to enter in an email address that can be verified? -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From matzew at apache.org Wed Jun 10 11:54:28 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 10 Jun 2015 17:54:28 +0200 Subject: [keycloak-dev] Error on EAP 6.4 Message-ID: Hi, trying to update UPS to 1.3.0.Final(-SNAPSHOT), I am getting an exception. When accessing this URL: http://localhost:8080/auth/admin/aerogear/console/ and after logging in I see some error - looks like JAX-RS 2.0 dependency, but EAP is 1.1, no? 17:46:31,638 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth].[Keycloak REST Interface]] (http-/0.0.0.0:8080-4) JBWEB000236: Servlet.service() for servlet Keycloak REST Interface threw exception: java.lang.RuntimeException: request path: /auth/admin/realms/aerogear at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:54) [keycloak-services-1.3.0.Final-SNAPSHOT.jar:1.3.0.Final-SNAPSHOT] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] Caused by: org.jboss.resteasy.spi.UnhandledException: java.lang.NoClassDefFoundError: javax/ws/rs/BadRequestException at org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:364) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:232) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:208) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:556) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:523) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41) [keycloak-services-1.3.0.Final-SNAPSHOT.jar:1.3.0.Final-SNAPSHOT] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:40) [keycloak-services-1.3.0.Final-SNAPSHOT.jar:1.3.0.Final-SNAPSHOT] ... 15 more Caused by: java.lang.NoClassDefFoundError: javax/ws/rs/BadRequestException at org.keycloak.services.resources.admin.RealmsAdminResource.getRealmAdmin(RealmsAdminResource.java:232) [keycloak-services-1.3.0.Final-SNAPSHOT.jar:1.3.0.Final-SNAPSHOT] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_65] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_65] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_65] at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65] at org.jboss.resteasy.core.ResourceLocator.createResource(ResourceLocator.java:64) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:105) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:153) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:91) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:541) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] ... 27 more Caused by: java.lang.ClassNotFoundException: javax.ws.rs.BadRequestException from [Module "deployment.auth-server.war:main" from Service Module Loader] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.6.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.6.Final-redhat-1] ... 37 more -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150610/aaf33363/attachment-0001.html From mstrukel at redhat.com Wed Jun 10 13:04:23 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Wed, 10 Jun 2015 13:04:23 -0400 (EDT) Subject: [keycloak-dev] Error on EAP 6.4 In-Reply-To: References: Message-ID: <1477016577.13647752.1433955863473.JavaMail.zimbra@redhat.com> Remarkably I've just been dealing with the same issue while porting keycloak-server support from Wildfly 9 to EAP 6 as well. Looks like just a bad import, and probably messed up or leaking dependencies in our poms ... --- services/src/main/java/org/keycloak/services/resources/admin/RealmAdminResource.java (date 1433857801000) +++ services/src/main/java/org/keycloak/services/resources/admin/RealmAdminResource.java (revision ) @@ -2,6 +2,7 @@ import org.jboss.logging.Logger; import org.jboss.resteasy.annotations.cache.NoCache; +import org.jboss.resteasy.spi.BadRequestException; import org.jboss.resteasy.spi.NotFoundException; import org.jboss.resteasy.spi.ResteasyProviderFactory; import org.keycloak.ClientConnection; @@ -35,7 +36,6 @@ import org.keycloak.services.ErrorResponse; import org.keycloak.timer.TimerProvider; -import javax.ws.rs.BadRequestException; import javax.ws.rs.Consumes; import javax.ws.rs.DELETE; import javax.ws.rs.GET; ----- Original Message ----- > Hi, > > trying to update UPS to 1.3.0.Final(-SNAPSHOT), I am getting an exception. > > When accessing this URL: > http://localhost:8080/auth/admin/aerogear/console/ > > and after logging in I see some error - looks like JAX-RS 2.0 dependency, but > EAP is 1.1, no? > > > > 17:46:31,638 ERROR > [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth].[Keycloak > REST Interface]] (http-/0.0.0.0:8080-4) JBWEB000236: Servlet.service() for > servlet Keycloak REST Interface threw exception: java.lang.RuntimeException: > request path: /auth/admin/realms/aerogear > at > org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:54) > [keycloak-services-1.3.0.Final-SNAPSHOT.jar:1.3.0.Final-SNAPSHOT] > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at > org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) > [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at > org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) > [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at > org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) > [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] > Caused by: org.jboss.resteasy.spi.UnhandledException: > java.lang.NoClassDefFoundError: javax/ws/rs/BadRequestException > at > org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:364) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at > org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:232) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at > org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:208) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at > org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:556) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:523) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) > [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2] > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at > org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41) > [keycloak-services-1.3.0.Final-SNAPSHOT.jar:1.3.0.Final-SNAPSHOT] > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at > org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:40) > [keycloak-services-1.3.0.Final-SNAPSHOT.jar:1.3.0.Final-SNAPSHOT] > ... 15 more > Caused by: java.lang.NoClassDefFoundError: javax/ws/rs/BadRequestException > at > org.keycloak.services.resources.admin.RealmsAdminResource.getRealmAdmin(RealmsAdminResource.java:232) > [keycloak-services-1.3.0.Final-SNAPSHOT.jar:1.3.0.Final-SNAPSHOT] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [rt.jar:1.7.0_65] > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > [rt.jar:1.7.0_65] > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [rt.jar:1.7.0_65] > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65] > at > org.jboss.resteasy.core.ResourceLocator.createResource(ResourceLocator.java:64) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:105) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at > org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:153) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:91) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at > org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:541) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > ... 27 more > Caused by: java.lang.ClassNotFoundException: javax.ws.rs.BadRequestException > from [Module "deployment.auth-server.war:main" from Service Module Loader] > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) > [jboss-modules.jar:1.3.6.Final-redhat-1] > at > org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) > [jboss-modules.jar:1.3.6.Final-redhat-1] > at > org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) > [jboss-modules.jar:1.3.6.Final-redhat-1] > at > org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) > [jboss-modules.jar:1.3.6.Final-redhat-1] > at > org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) > [jboss-modules.jar:1.3.6.Final-redhat-1] > ... 37 more > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Wed Jun 10 13:13:57 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 10 Jun 2015 13:13:57 -0400 (EDT) Subject: [keycloak-dev] verify email is skipped if no email In-Reply-To: <55784E31.3010104@redhat.com> References: <55784E31.3010104@redhat.com> Message-ID: <163079184.15527287.1433956437362.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Wednesday, 10 June, 2015 4:48:17 PM > Subject: [keycloak-dev] verify email is skipped if no email > > The verify email required action is skipped if the user has no email. > Is this the right behavior? Should the user instead be required to > enter in an email address that can be verified? +1 It doesn't really make sense to require users to verify their email, but at the same time not require users to enter one > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From stian at redhat.com Wed Jun 10 13:15:04 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 10 Jun 2015 13:15:04 -0400 (EDT) Subject: [keycloak-dev] Error on EAP 6.4 In-Reply-To: <1477016577.13647752.1433955863473.JavaMail.zimbra@redhat.com> References: <1477016577.13647752.1433955863473.JavaMail.zimbra@redhat.com> Message-ID: <333100300.15527610.1433956504991.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Marko Strukelj" > To: "Matthias Wessendorf" > Cc: keycloak-dev at lists.jboss.org > Sent: Wednesday, 10 June, 2015 7:04:23 PM > Subject: Re: [keycloak-dev] Error on EAP 6.4 > > Remarkably I've just been dealing with the same issue while porting > keycloak-server support from Wildfly 9 to EAP 6 as well. > > Looks like just a bad import, and probably messed up or leaking dependencies > in our poms ... Did you fix it? > > --- > services/src/main/java/org/keycloak/services/resources/admin/RealmAdminResource.java > (date 1433857801000) > +++ > services/src/main/java/org/keycloak/services/resources/admin/RealmAdminResource.java > (revision ) > @@ -2,6 +2,7 @@ > > import org.jboss.logging.Logger; > import org.jboss.resteasy.annotations.cache.NoCache; > +import org.jboss.resteasy.spi.BadRequestException; > import org.jboss.resteasy.spi.NotFoundException; > import org.jboss.resteasy.spi.ResteasyProviderFactory; > import org.keycloak.ClientConnection; > @@ -35,7 +36,6 @@ > import org.keycloak.services.ErrorResponse; > import org.keycloak.timer.TimerProvider; > > -import javax.ws.rs.BadRequestException; > import javax.ws.rs.Consumes; > import javax.ws.rs.DELETE; > import javax.ws.rs.GET; > > ----- Original Message ----- > > Hi, > > > > trying to update UPS to 1.3.0.Final(-SNAPSHOT), I am getting an exception. > > > > When accessing this URL: > > http://localhost:8080/auth/admin/aerogear/console/ > > > > and after logging in I see some error - looks like JAX-RS 2.0 dependency, > > but > > EAP is 1.1, no? > > > > > > > > 17:46:31,638 ERROR > > [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth].[Keycloak > > REST Interface]] (http-/0.0.0.0:8080-4) JBWEB000236: Servlet.service() for > > servlet Keycloak REST Interface threw exception: > > java.lang.RuntimeException: > > request path: /auth/admin/realms/aerogear > > at > > org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:54) > > [keycloak-services-1.3.0.Final-SNAPSHOT.jar:1.3.0.Final-SNAPSHOT] > > at > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > at > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > at > > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > at > > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > at > > org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) > > [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > > at > > org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) > > [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > > at > > org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) > > [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > > at > > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > at > > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > at > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > at > > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > at > > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > at > > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] > > Caused by: org.jboss.resteasy.spi.UnhandledException: > > java.lang.NoClassDefFoundError: javax/ws/rs/BadRequestException > > at > > org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:364) > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > at > > org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:232) > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > at > > org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:208) > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > at > > org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:556) > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > at > > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:523) > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > at > > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > at > > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > at > > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > at > > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) > > [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2] > > at > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > at > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > at > > org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41) > > [keycloak-services-1.3.0.Final-SNAPSHOT.jar:1.3.0.Final-SNAPSHOT] > > at > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > at > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > at > > org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:40) > > [keycloak-services-1.3.0.Final-SNAPSHOT.jar:1.3.0.Final-SNAPSHOT] > > ... 15 more > > Caused by: java.lang.NoClassDefFoundError: javax/ws/rs/BadRequestException > > at > > org.keycloak.services.resources.admin.RealmsAdminResource.getRealmAdmin(RealmsAdminResource.java:232) > > [keycloak-services-1.3.0.Final-SNAPSHOT.jar:1.3.0.Final-SNAPSHOT] > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > [rt.jar:1.7.0_65] > > at > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > [rt.jar:1.7.0_65] > > at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > [rt.jar:1.7.0_65] > > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65] > > at > > org.jboss.resteasy.core.ResourceLocator.createResource(ResourceLocator.java:64) > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > at org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:105) > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > at > > org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:153) > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > at org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:91) > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > at > > org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:541) > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > ... 27 more > > Caused by: java.lang.ClassNotFoundException: > > javax.ws.rs.BadRequestException > > from [Module "deployment.auth-server.war:main" from Service Module Loader] > > at > > org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) > > [jboss-modules.jar:1.3.6.Final-redhat-1] > > at > > org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) > > [jboss-modules.jar:1.3.6.Final-redhat-1] > > at > > org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) > > [jboss-modules.jar:1.3.6.Final-redhat-1] > > at > > org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) > > [jboss-modules.jar:1.3.6.Final-redhat-1] > > at > > org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) > > [jboss-modules.jar:1.3.6.Final-redhat-1] > > ... 37 more > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > _______________________________________________ > > 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 stian at redhat.com Wed Jun 10 13:25:11 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 10 Jun 2015 13:25:11 -0400 (EDT) Subject: [keycloak-dev] Hide internal clients and roles In-Reply-To: <55784C0F.5080103@redhat.com> References: <2031633068.14985543.1433920767880.JavaMail.zimbra@redhat.com> <55783FAF.7060807@redhat.com> <557844D0.3010004@redhat.com> <1607122411.15372251.1433945748101.JavaMail.zimbra@redhat.com> <55784C0F.5080103@redhat.com> Message-ID: <155544962.15532267.1433957111431.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Wednesday, 10 June, 2015 4:39:11 PM > Subject: Re: [keycloak-dev] Hide internal clients and roles > > > > On 6/10/2015 10:15 AM, Stian Thorgersen wrote: > > > > > > ----- Original Message ----- > >> From: "Bill Burke" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Wednesday, 10 June, 2015 4:08:16 PM > >> Subject: Re: [keycloak-dev] Hide internal clients and roles > >> > >> I think security-admin-console and realm-management should be merged in > >> non-Master realms. In master realm, rename everything to > >> -security-admin-console. Finally, an internal role or client > >> would not be able to be deleted. > >> > >> I don't think you should hide any roles ever. I don't see why you would > >> want to. I do think you should make internal clients and roles > >> unremovable. > > > > Hiding the internal realm roles would enable a "blank slate" page on the > > realm roles list. Alternatively, and I actually think this is a better > > idea, is to make the admin and create-realm roles roles of the > > master-security-admin-console realm rather than realm roles. In that case > > all we need is "internal" clients and an option to view/hide them on the > > clients list. > > > > Do you like the idea of merging security-admin-console and realm-management? > > +1 to moving "admin" and "create-realm" to master-security-admin-console. Yep, I think that's cleaner. Maybe just call it 'realm-admin-master'? > > The "blank slate" page could be displayed if there is no *non* > internal-clients/roles. There could be a button or link on the Blank > Slate page "View built-in clients" along with "create client". I don't > know if it is better to have a "hide built-in clients" checkbox on the > client list page, or to just show them by default. > > > Which one is it btw "an internal role or client would not be able to be > > deleted" or "I do think you should make internal clients and roles > > unremovable"? > > Sorry, I repeated myself without realizing. internal things should not > be deletable or removable, right? Hehe, I read one wrongly so I thought you where saying they should not be able to delete and at the same time they should be removable. I agree - it should not be possible to delete internal stuff. What about we add an attribute to internal clients so we can show that they are internal in the client list. Also, we know when to display the clean slate if there's only internal clients. We can also use the internal attribute to limit options that can be changed for such clients. > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > From matzew at apache.org Thu Jun 11 02:53:54 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 11 Jun 2015 08:53:54 +0200 Subject: [keycloak-dev] Error on EAP 6.4 In-Reply-To: <333100300.15527610.1433956504991.JavaMail.zimbra@redhat.com> References: <1477016577.13647752.1433955863473.JavaMail.zimbra@redhat.com> <333100300.15527610.1433956504991.JavaMail.zimbra@redhat.com> Message-ID: Hi Marko, I have locally tested, and it works. Send a fix for the import: https://github.com/keycloak/keycloak/pull/1356 On Wed, Jun 10, 2015 at 7:15 PM, Stian Thorgersen wrote: > > > ----- Original Message ----- > > From: "Marko Strukelj" > > To: "Matthias Wessendorf" > > Cc: keycloak-dev at lists.jboss.org > > Sent: Wednesday, 10 June, 2015 7:04:23 PM > > Subject: Re: [keycloak-dev] Error on EAP 6.4 > > > > Remarkably I've just been dealing with the same issue while porting > > keycloak-server support from Wildfly 9 to EAP 6 as well. > > > > Looks like just a bad import, and probably messed up or leaking > dependencies > > in our poms ... > > Did you fix it? > > > > > --- > > > services/src/main/java/org/keycloak/services/resources/admin/RealmAdminResource.java > > (date 1433857801000) > > +++ > > > services/src/main/java/org/keycloak/services/resources/admin/RealmAdminResource.java > > (revision ) > > @@ -2,6 +2,7 @@ > > > > import org.jboss.logging.Logger; > > import org.jboss.resteasy.annotations.cache.NoCache; > > +import org.jboss.resteasy.spi.BadRequestException; > > import org.jboss.resteasy.spi.NotFoundException; > > import org.jboss.resteasy.spi.ResteasyProviderFactory; > > import org.keycloak.ClientConnection; > > @@ -35,7 +36,6 @@ > > import org.keycloak.services.ErrorResponse; > > import org.keycloak.timer.TimerProvider; > > > > -import javax.ws.rs.BadRequestException; > > import javax.ws.rs.Consumes; > > import javax.ws.rs.DELETE; > > import javax.ws.rs.GET; > > > > ----- Original Message ----- > > > Hi, > > > > > > trying to update UPS to 1.3.0.Final(-SNAPSHOT), I am getting an > exception. > > > > > > When accessing this URL: > > > http://localhost:8080/auth/admin/aerogear/console/ > > > > > > and after logging in I see some error - looks like JAX-RS 2.0 > dependency, > > > but > > > EAP is 1.1, no? > > > > > > > > > > > > 17:46:31,638 ERROR > > > > [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth].[Keycloak > > > REST Interface]] (http-/0.0.0.0:8080-4) JBWEB000236: > Servlet.service() for > > > servlet Keycloak REST Interface threw exception: > > > java.lang.RuntimeException: > > > request path: /auth/admin/realms/aerogear > > > at > > > > org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:54) > > > [keycloak-services-1.3.0.Final-SNAPSHOT.jar:1.3.0.Final-SNAPSHOT] > > > at > > > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > at > > > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > at > > > > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > at > > > > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > at > > > > org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) > > > [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > > > at > > > > org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) > > > [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > > > at > > > > org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) > > > [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > > > at > > > > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > at > > > > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > at > > > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > at > > > > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > at > > > > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > at > > > > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > at > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] > > > Caused by: org.jboss.resteasy.spi.UnhandledException: > > > java.lang.NoClassDefFoundError: javax/ws/rs/BadRequestException > > > at > > > > org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:364) > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > at > > > > org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:232) > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > at > > > > org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:208) > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > at > > > > org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:556) > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > at > > > > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:523) > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > at > > > > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > at > > > > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > at > > > > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > at > > > > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) > > > > [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2] > > > at > > > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > at > > > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > at > > > > org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41) > > > [keycloak-services-1.3.0.Final-SNAPSHOT.jar:1.3.0.Final-SNAPSHOT] > > > at > > > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > at > > > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > at > > > > org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:40) > > > [keycloak-services-1.3.0.Final-SNAPSHOT.jar:1.3.0.Final-SNAPSHOT] > > > ... 15 more > > > Caused by: java.lang.NoClassDefFoundError: > javax/ws/rs/BadRequestException > > > at > > > > org.keycloak.services.resources.admin.RealmsAdminResource.getRealmAdmin(RealmsAdminResource.java:232) > > > [keycloak-services-1.3.0.Final-SNAPSHOT.jar:1.3.0.Final-SNAPSHOT] > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > > [rt.jar:1.7.0_65] > > > at > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > > [rt.jar:1.7.0_65] > > > at > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > > [rt.jar:1.7.0_65] > > > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65] > > > at > > > > org.jboss.resteasy.core.ResourceLocator.createResource(ResourceLocator.java:64) > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > at > org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:105) > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > at > > > > org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:153) > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > at > org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:91) > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > at > > > > org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:541) > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > ... 27 more > > > Caused by: java.lang.ClassNotFoundException: > > > javax.ws.rs.BadRequestException > > > from [Module "deployment.auth-server.war:main" from Service Module > Loader] > > > at > > > > org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) > > > [jboss-modules.jar:1.3.6.Final-redhat-1] > > > at > > > > org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) > > > [jboss-modules.jar:1.3.6.Final-redhat-1] > > > at > > > > org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) > > > [jboss-modules.jar:1.3.6.Final-redhat-1] > > > at > > > > org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) > > > [jboss-modules.jar:1.3.6.Final-redhat-1] > > > at > > > > org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) > > > [jboss-modules.jar:1.3.6.Final-redhat-1] > > > ... 37 more > > > > > > > > > > > > -- > > > Matthias Wessendorf > > > > > > blog: http://matthiaswessendorf.wordpress.com/ > > > sessions: http://www.slideshare.net/mwessendorf > > > twitter: http://twitter.com/mwessendorf > > > > > > _______________________________________________ > > > 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 > > > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150611/cbfd699b/attachment-0001.html From mstrukel at redhat.com Thu Jun 11 03:15:09 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Thu, 11 Jun 2015 03:15:09 -0400 (EDT) Subject: [keycloak-dev] Error on EAP 6.4 In-Reply-To: References: <1477016577.13647752.1433955863473.JavaMail.zimbra@redhat.com> <333100300.15527610.1433956504991.JavaMail.zimbra@redhat.com> Message-ID: <1697142449.182221.1434006909172.JavaMail.zimbra@redhat.com> Yeah, seems to work for me as well. Looks like this was an isolated issue, and not a broader incompatibility problem. ----- Original Message ----- > Hi Marko, > > I have locally tested, and it works. > Send a fix for the import: https://github.com/keycloak/keycloak/pull/1356 > > On Wed, Jun 10, 2015 at 7:15 PM, Stian Thorgersen wrote: > > > > > > > ----- Original Message ----- > > > From: "Marko Strukelj" > > > To: "Matthias Wessendorf" > > > Cc: keycloak-dev at lists.jboss.org > > > Sent: Wednesday, 10 June, 2015 7:04:23 PM > > > Subject: Re: [keycloak-dev] Error on EAP 6.4 > > > > > > Remarkably I've just been dealing with the same issue while porting > > > keycloak-server support from Wildfly 9 to EAP 6 as well. > > > > > > Looks like just a bad import, and probably messed up or leaking > > dependencies > > > in our poms ... > > > > Did you fix it? > > > > > > > > --- > > > > > services/src/main/java/org/keycloak/services/resources/admin/RealmAdminResource.java > > > (date 1433857801000) > > > +++ > > > > > services/src/main/java/org/keycloak/services/resources/admin/RealmAdminResource.java > > > (revision ) > > > @@ -2,6 +2,7 @@ > > > > > > import org.jboss.logging.Logger; > > > import org.jboss.resteasy.annotations.cache.NoCache; > > > +import org.jboss.resteasy.spi.BadRequestException; > > > import org.jboss.resteasy.spi.NotFoundException; > > > import org.jboss.resteasy.spi.ResteasyProviderFactory; > > > import org.keycloak.ClientConnection; > > > @@ -35,7 +36,6 @@ > > > import org.keycloak.services.ErrorResponse; > > > import org.keycloak.timer.TimerProvider; > > > > > > -import javax.ws.rs.BadRequestException; > > > import javax.ws.rs.Consumes; > > > import javax.ws.rs.DELETE; > > > import javax.ws.rs.GET; > > > > > > ----- Original Message ----- > > > > Hi, > > > > > > > > trying to update UPS to 1.3.0.Final(-SNAPSHOT), I am getting an > > exception. > > > > > > > > When accessing this URL: > > > > http://localhost:8080/auth/admin/aerogear/console/ > > > > > > > > and after logging in I see some error - looks like JAX-RS 2.0 > > dependency, > > > > but > > > > EAP is 1.1, no? > > > > > > > > > > > > > > > > 17:46:31,638 ERROR > > > > > > [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth].[Keycloak > > > > REST Interface]] (http-/0.0.0.0:8080-4) JBWEB000236: > > Servlet.service() for > > > > servlet Keycloak REST Interface threw exception: > > > > java.lang.RuntimeException: > > > > request path: /auth/admin/realms/aerogear > > > > at > > > > > > org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:54) > > > > [keycloak-services-1.3.0.Final-SNAPSHOT.jar:1.3.0.Final-SNAPSHOT] > > > > at > > > > > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) > > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > > at > > > > > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) > > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > > at > > > > > > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) > > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > > at > > > > > > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) > > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > > at > > > > > > org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) > > > > [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > > > > at > > > > > > org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) > > > > [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > > > > at > > > > > > org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) > > > > [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > > > > at > > > > > > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) > > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > > at > > > > > > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) > > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > > at > > > > > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) > > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > > at > > > > > > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) > > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > > at > > > > > > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) > > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > > at > > > > > > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) > > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > > at > > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) > > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] > > > > Caused by: org.jboss.resteasy.spi.UnhandledException: > > > > java.lang.NoClassDefFoundError: javax/ws/rs/BadRequestException > > > > at > > > > > > org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:364) > > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > > at > > > > > > org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:232) > > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > > at > > > > > > org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:208) > > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > > at > > > > > > org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:556) > > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > > at > > > > > > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:523) > > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > > at > > > > > > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) > > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > > at > > > > > > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) > > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > > at > > > > > > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) > > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > > at > > > > > > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) > > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) > > > > > > [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2] > > > > at > > > > > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) > > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > > at > > > > > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) > > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > > at > > > > > > org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41) > > > > [keycloak-services-1.3.0.Final-SNAPSHOT.jar:1.3.0.Final-SNAPSHOT] > > > > at > > > > > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) > > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > > at > > > > > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) > > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > > at > > > > > > org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:40) > > > > [keycloak-services-1.3.0.Final-SNAPSHOT.jar:1.3.0.Final-SNAPSHOT] > > > > ... 15 more > > > > Caused by: java.lang.NoClassDefFoundError: > > javax/ws/rs/BadRequestException > > > > at > > > > > > org.keycloak.services.resources.admin.RealmsAdminResource.getRealmAdmin(RealmsAdminResource.java:232) > > > > [keycloak-services-1.3.0.Final-SNAPSHOT.jar:1.3.0.Final-SNAPSHOT] > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > > > [rt.jar:1.7.0_65] > > > > at > > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > > > [rt.jar:1.7.0_65] > > > > at > > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > > > [rt.jar:1.7.0_65] > > > > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65] > > > > at > > > > > > org.jboss.resteasy.core.ResourceLocator.createResource(ResourceLocator.java:64) > > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > > at > > org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:105) > > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > > at > > > > > > org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:153) > > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > > at > > org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:91) > > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > > at > > > > > > org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:541) > > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > > ... 27 more > > > > Caused by: java.lang.ClassNotFoundException: > > > > javax.ws.rs.BadRequestException > > > > from [Module "deployment.auth-server.war:main" from Service Module > > Loader] > > > > at > > > > > > org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) > > > > [jboss-modules.jar:1.3.6.Final-redhat-1] > > > > at > > > > > > org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) > > > > [jboss-modules.jar:1.3.6.Final-redhat-1] > > > > at > > > > > > org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) > > > > [jboss-modules.jar:1.3.6.Final-redhat-1] > > > > at > > > > > > org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) > > > > [jboss-modules.jar:1.3.6.Final-redhat-1] > > > > at > > > > > > org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) > > > > [jboss-modules.jar:1.3.6.Final-redhat-1] > > > > ... 37 more > > > > > > > > > > > > > > > > -- > > > > Matthias Wessendorf > > > > > > > > blog: http://matthiaswessendorf.wordpress.com/ > > > > sessions: http://www.slideshare.net/mwessendorf > > > > twitter: http://twitter.com/mwessendorf > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > From stian at redhat.com Thu Jun 11 03:37:15 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 11 Jun 2015 03:37:15 -0400 (EDT) Subject: [keycloak-dev] Error on EAP 6.4 In-Reply-To: <1697142449.182221.1434006909172.JavaMail.zimbra@redhat.com> References: <1477016577.13647752.1433955863473.JavaMail.zimbra@redhat.com> <333100300.15527610.1433956504991.JavaMail.zimbra@redhat.com> <1697142449.182221.1434006909172.JavaMail.zimbra@redhat.com> Message-ID: <1964235177.15780511.1434008235897.JavaMail.zimbra@redhat.com> To prevent this happening again I'll set the RestEasy version from EAP 6.4 as the main version. We'll only use the latest RestEasy in the testsuite (temporary until we have everything moved to Arquillian) and for the jaxrs-oauth-client integration (that requires resteasy-client which is only available in 3). ----- Original Message ----- > From: "Marko Strukelj" > To: "Matthias Wessendorf" > Cc: "Stian Thorgersen" , keycloak-dev at lists.jboss.org > Sent: Thursday, 11 June, 2015 9:15:09 AM > Subject: Re: [keycloak-dev] Error on EAP 6.4 > > Yeah, seems to work for me as well. Looks like this was an isolated issue, > and not a broader incompatibility problem. > > ----- Original Message ----- > > Hi Marko, > > > > I have locally tested, and it works. > > Send a fix for the import: https://github.com/keycloak/keycloak/pull/1356 > > > > On Wed, Jun 10, 2015 at 7:15 PM, Stian Thorgersen wrote: > > > > > > > > > > > ----- Original Message ----- > > > > From: "Marko Strukelj" > > > > To: "Matthias Wessendorf" > > > > Cc: keycloak-dev at lists.jboss.org > > > > Sent: Wednesday, 10 June, 2015 7:04:23 PM > > > > Subject: Re: [keycloak-dev] Error on EAP 6.4 > > > > > > > > Remarkably I've just been dealing with the same issue while porting > > > > keycloak-server support from Wildfly 9 to EAP 6 as well. > > > > > > > > Looks like just a bad import, and probably messed up or leaking > > > dependencies > > > > in our poms ... > > > > > > Did you fix it? > > > > > > > > > > > --- > > > > > > > services/src/main/java/org/keycloak/services/resources/admin/RealmAdminResource.java > > > > (date 1433857801000) > > > > +++ > > > > > > > services/src/main/java/org/keycloak/services/resources/admin/RealmAdminResource.java > > > > (revision ) > > > > @@ -2,6 +2,7 @@ > > > > > > > > import org.jboss.logging.Logger; > > > > import org.jboss.resteasy.annotations.cache.NoCache; > > > > +import org.jboss.resteasy.spi.BadRequestException; > > > > import org.jboss.resteasy.spi.NotFoundException; > > > > import org.jboss.resteasy.spi.ResteasyProviderFactory; > > > > import org.keycloak.ClientConnection; > > > > @@ -35,7 +36,6 @@ > > > > import org.keycloak.services.ErrorResponse; > > > > import org.keycloak.timer.TimerProvider; > > > > > > > > -import javax.ws.rs.BadRequestException; > > > > import javax.ws.rs.Consumes; > > > > import javax.ws.rs.DELETE; > > > > import javax.ws.rs.GET; > > > > > > > > ----- Original Message ----- > > > > > Hi, > > > > > > > > > > trying to update UPS to 1.3.0.Final(-SNAPSHOT), I am getting an > > > exception. > > > > > > > > > > When accessing this URL: > > > > > http://localhost:8080/auth/admin/aerogear/console/ > > > > > > > > > > and after logging in I see some error - looks like JAX-RS 2.0 > > > dependency, > > > > > but > > > > > EAP is 1.1, no? > > > > > > > > > > > > > > > > > > > > 17:46:31,638 ERROR > > > > > > > > [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth].[Keycloak > > > > > REST Interface]] (http-/0.0.0.0:8080-4) JBWEB000236: > > > Servlet.service() for > > > > > servlet Keycloak REST Interface threw exception: > > > > > java.lang.RuntimeException: > > > > > request path: /auth/admin/realms/aerogear > > > > > at > > > > > > > > org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:54) > > > > > [keycloak-services-1.3.0.Final-SNAPSHOT.jar:1.3.0.Final-SNAPSHOT] > > > > > at > > > > > > > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) > > > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > > > at > > > > > > > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) > > > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > > > at > > > > > > > > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) > > > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > > > at > > > > > > > > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) > > > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > > > at > > > > > > > > org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) > > > > > [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > > > > > at > > > > > > > > org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) > > > > > [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > > > > > at > > > > > > > > org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) > > > > > [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > > > > > at > > > > > > > > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) > > > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > > > at > > > > > > > > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) > > > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > > > at > > > > > > > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) > > > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > > > at > > > > > > > > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) > > > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > > > at > > > > > > > > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) > > > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > > > at > > > > > > > > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) > > > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > > > at > > > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) > > > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > > > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] > > > > > Caused by: org.jboss.resteasy.spi.UnhandledException: > > > > > java.lang.NoClassDefFoundError: javax/ws/rs/BadRequestException > > > > > at > > > > > > > > org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:364) > > > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > > > at > > > > > > > > org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:232) > > > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > > > at > > > > > > > > org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:208) > > > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > > > at > > > > > > > > org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:556) > > > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > > > at > > > > > > > > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:523) > > > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > > > at > > > > > > > > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) > > > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > > > at > > > > > > > > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) > > > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > > > at > > > > > > > > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) > > > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > > > at > > > > > > > > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) > > > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) > > > > > > > > [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2] > > > > > at > > > > > > > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) > > > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > > > at > > > > > > > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) > > > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > > > at > > > > > > > > org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41) > > > > > [keycloak-services-1.3.0.Final-SNAPSHOT.jar:1.3.0.Final-SNAPSHOT] > > > > > at > > > > > > > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) > > > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > > > at > > > > > > > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) > > > > > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > > > > > at > > > > > > > > org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:40) > > > > > [keycloak-services-1.3.0.Final-SNAPSHOT.jar:1.3.0.Final-SNAPSHOT] > > > > > ... 15 more > > > > > Caused by: java.lang.NoClassDefFoundError: > > > javax/ws/rs/BadRequestException > > > > > at > > > > > > > > org.keycloak.services.resources.admin.RealmsAdminResource.getRealmAdmin(RealmsAdminResource.java:232) > > > > > [keycloak-services-1.3.0.Final-SNAPSHOT.jar:1.3.0.Final-SNAPSHOT] > > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > > > > [rt.jar:1.7.0_65] > > > > > at > > > > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > > > > [rt.jar:1.7.0_65] > > > > > at > > > > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > > > > [rt.jar:1.7.0_65] > > > > > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65] > > > > > at > > > > > > > > org.jboss.resteasy.core.ResourceLocator.createResource(ResourceLocator.java:64) > > > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > > > at > > > org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:105) > > > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > > > at > > > > > > > > org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:153) > > > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > > > at > > > org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:91) > > > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > > > at > > > > > > > > org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:541) > > > > > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > > > > > ... 27 more > > > > > Caused by: java.lang.ClassNotFoundException: > > > > > javax.ws.rs.BadRequestException > > > > > from [Module "deployment.auth-server.war:main" from Service Module > > > Loader] > > > > > at > > > > > > > > org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) > > > > > [jboss-modules.jar:1.3.6.Final-redhat-1] > > > > > at > > > > > > > > org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) > > > > > [jboss-modules.jar:1.3.6.Final-redhat-1] > > > > > at > > > > > > > > org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) > > > > > [jboss-modules.jar:1.3.6.Final-redhat-1] > > > > > at > > > > > > > > org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) > > > > > [jboss-modules.jar:1.3.6.Final-redhat-1] > > > > > at > > > > > > > > org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) > > > > > [jboss-modules.jar:1.3.6.Final-redhat-1] > > > > > ... 37 more > > > > > > > > > > > > > > > > > > > > -- > > > > > Matthias Wessendorf > > > > > > > > > > blog: http://matthiaswessendorf.wordpress.com/ > > > > > sessions: http://www.slideshare.net/mwessendorf > > > > > twitter: http://twitter.com/mwessendorf > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > From velias at redhat.com Thu Jun 11 03:57:05 2015 From: velias at redhat.com (Vlastimil Elias) Date: Thu, 11 Jun 2015 09:57:05 +0200 Subject: [keycloak-dev] verify email is skipped if no email In-Reply-To: <55793EF6.7060009@redhat.com> References: <55793EF6.7060009@redhat.com> Message-ID: <55793F51.9050901@redhat.com> This is covered by https://issues.jboss.org/browse/KEYCLOAK-1371 which allows to configure Identity provider to Show "update profile" page on first login only when some mandatory field is missing. For now user profile mandatory fields are hardcoded (email, first and last name). It should be cool to allow configuration of which user profile fields are mandatory. Vl. On 10.6.2015 19:13, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Wednesday, 10 June, 2015 4:48:17 PM >> Subject: [keycloak-dev] verify email is skipped if no email >> >> The verify email required action is skipped if the user has no email. >> Is this the right behavior? Should the user instead be required to >> enter in an email address that can be verified? > +1 It doesn't really make sense to require users to verify their email, but at the same time not require users to enter one > >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Vlastimil Elias Principal Software Engineer jboss.org Development Team From stian at redhat.com Thu Jun 11 03:58:13 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 11 Jun 2015 03:58:13 -0400 (EDT) Subject: [keycloak-dev] verify email is skipped if no email In-Reply-To: <55793F51.9050901@redhat.com> References: <55793EF6.7060009@redhat.com> <55793F51.9050901@redhat.com> Message-ID: <432218402.15788132.1434009493299.JavaMail.zimbra@redhat.com> I reckon we need a way for a realm to define what profiles are available for a user, which are required, and to be able to add verification for each field. We can then use the verification to find out what details are missing and show only the required fields on the update profile form. ----- Original Message ----- > From: "Vlastimil Elias" > To: keycloak-dev at lists.jboss.org > Sent: Thursday, 11 June, 2015 9:57:05 AM > Subject: Re: [keycloak-dev] verify email is skipped if no email > > > > This is covered by https://issues.jboss.org/browse/KEYCLOAK-1371 which > allows to configure Identity provider to Show "update profile" page on > first login only when some mandatory field is missing. For now user > profile mandatory fields are hardcoded (email, first and last name). It > should be cool to allow configuration of which user profile fields are > mandatory. > > Vl. > > > On 10.6.2015 19:13, Stian Thorgersen wrote: > > > > ----- Original Message ----- > >> From: "Bill Burke" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Wednesday, 10 June, 2015 4:48:17 PM > >> Subject: [keycloak-dev] verify email is skipped if no email > >> > >> The verify email required action is skipped if the user has no email. > >> Is this the right behavior? Should the user instead be required to > >> enter in an email address that can be verified? > > +1 It doesn't really make sense to require users to verify their email, but > > at the same time not require users to enter one > > > >> -- > >> Bill Burke > >> JBoss, a division of Red Hat > >> http://bill.burkecentral.com > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -- > Vlastimil Elias > Principal Software Engineer > jboss.org Development Team > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From mposolda at redhat.com Thu Jun 11 04:45:37 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 11 Jun 2015 10:45:37 +0200 Subject: [keycloak-dev] Generic servlet adapter? Message-ID: <55794AB1.2090702@redhat.com> I wonder if we should have some generic HttpServlet based adapter? It can be used for all the servlet containers, where we don't have proper adapter. We can create just HttpServletFilter and after the authentication, send forward the wrapped HttpServletRequest with few overriden methods (getRemoteUser, isUserInRole, logout, ...). The disadvantage is that it's not tightly coupled with the container security (propagation to EJB etc) and security-constraints in web.xml won't work, so we will need to use something different (init-parameters in the filter maybe). I know we have proxy, but maybe this will fit even better for some environments? Marek From ssilvert at redhat.com Thu Jun 11 10:06:59 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Thu, 11 Jun 2015 10:06:59 -0400 Subject: [keycloak-dev] Localized terms and conditions Message-ID: <55799603.4060900@redhat.com> Not sure if you heard my last comments. Just showing the AdSense T&C: https://www.google.com/adsense/localized-terms Looks like text should not be in localized templates. They should just be flat files assignable by the user's self-identified locale. Stan From ssilvert at redhat.com Thu Jun 11 10:37:39 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Thu, 11 Jun 2015 10:37:39 -0400 Subject: [keycloak-dev] Localized terms and conditions In-Reply-To: <55799603.4060900@redhat.com> References: <55799603.4060900@redhat.com> Message-ID: <55799D33.2050600@redhat.com> Why not just have the administrator specify a URL for each locale? Then we don't need to store any actual T&C text. We just pull it in from the URL. On 6/11/2015 10:06 AM, Stan Silvert wrote: > Not sure if you heard my last comments. Just showing the AdSense T&C: > https://www.google.com/adsense/localized-terms > > Looks like text should not be in localized templates. They should just > be flat files assignable by the user's self-identified locale. > > Stan > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Thu Jun 11 10:38:26 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 11 Jun 2015 10:38:26 -0400 (EDT) Subject: [keycloak-dev] Localized terms and conditions In-Reply-To: <55799603.4060900@redhat.com> References: <55799603.4060900@redhat.com> Message-ID: <1039488917.15987476.1434033506610.JavaMail.zimbra@redhat.com> I think we just include terms and conditions page which just outputs a single message. Then in the message bundle we'll just have: terms=

Terms & Conditions

Including internationalized versions of that short empty message. ----- Original Message ----- > From: "Stan Silvert" > To: keycloak-dev at lists.jboss.org > Sent: Thursday, 11 June, 2015 4:06:59 PM > Subject: [keycloak-dev] Localized terms and conditions > > Not sure if you heard my last comments. Just showing the AdSense T&C: > https://www.google.com/adsense/localized-terms > > Looks like text should not be in localized templates. They should just > be flat files assignable by the user's self-identified locale. > > Stan > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From fadiabdeen at gmail.com Thu Jun 11 15:49:21 2015 From: fadiabdeen at gmail.com (Fadi Abdin) Date: Thu, 11 Jun 2015 15:49:21 -0400 Subject: [keycloak-dev] Token is not active Message-ID: When my keycloak server run for few days, it start acting weird and start returning "Token is not active" when i just issued the token. org.keycloak.VerificationException: Token is not active. My server is synced with a time server so the system date should be always valid. The solution is to restart keycloak. Have anyone faced this issue before ?? this issue is driving me crazy and i cant figure it out, i appreciate some help . . Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150611/385fff02/attachment.html From niko at n-k.de Fri Jun 12 06:06:17 2015 From: niko at n-k.de (=?utf-8?Q?Niko_K=C3=B6bler?=) Date: Fri, 12 Jun 2015 12:06:17 +0200 Subject: [keycloak-dev] Selection of displaying max rows in admin console Message-ID: Hi, currently it?s only possible to show 5 users on one page in the admin console. When having a huge amount of users, it?s sometimes difficult to navigate through the appropriate users. Having a selection box to select the rows per page, would be a great benefit when administering the users. It?s not a big effort, I could do this and provide a PR. Any thoughts about this? - Niko From stian at redhat.com Fri Jun 12 06:30:05 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 12 Jun 2015 06:30:05 -0400 (EDT) Subject: [keycloak-dev] Selection of displaying max rows in admin console In-Reply-To: References: Message-ID: <774128594.16452953.1434105005832.JavaMail.zimbra@redhat.com> We'll be refreshing all tables soon. The plan is to display 20 results per-page and also display the number of pages. ----- Original Message ----- > From: "Niko K?bler" > To: keycloak-dev at lists.jboss.org > Sent: Friday, 12 June, 2015 12:06:17 PM > Subject: [keycloak-dev] Selection of displaying max rows in admin console > > Hi, > > currently it?s only possible to show 5 users on one page in the admin > console. > When having a huge amount of users, it?s sometimes difficult to navigate > through the appropriate users. > Having a selection box to select the rows per page, would be a great benefit > when administering the users. > > It?s not a big effort, I could do this and provide a PR. > > Any thoughts about this? > > - Niko > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Fri Jun 12 08:37:43 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 12 Jun 2015 08:37:43 -0400 (EDT) Subject: [keycloak-dev] Start committing for 1.4 Message-ID: <1148704784.16508010.1434112663515.JavaMail.zimbra@redhat.com> I've created a branch for 1.3, which will be released early next week. So go ahead and commit stuff for 1.4 :) From velias at redhat.com Fri Jun 12 09:11:42 2015 From: velias at redhat.com (Vlastimil Elias) Date: Fri, 12 Jun 2015 15:11:42 +0200 Subject: [keycloak-dev] verify email is skipped if no email In-Reply-To: <432218402.15788132.1434009493299.JavaMail.zimbra@redhat.com> References: <55793EF6.7060009@redhat.com> <55793F51.9050901@redhat.com> <432218402.15788132.1434009493299.JavaMail.zimbra@redhat.com> Message-ID: <557ADA8E.7080704@redhat.com> Hi On 11.6.2015 09:58, Stian Thorgersen wrote: > I reckon we need a way for a realm to define what profiles are available for a user, which are required, and to be able to add verification for each field. +100. Verification of fields defined this way should be performed for submit of all related forms - "register user", "update profile" in acc mgm and "update profile on first login". But config of required should also be used to evaluate "Show "update profile" page on first login only when some mandatory field is missing" feature. > We can then use the verification to find out what details are missing and show only the required fields on the update profile form. It depends on usecase. For example in our case we prefer to show all user profile fields on "update profile on first login" form and only visually mark which are mandatory, so users must add missing mandatory values there, but he can also change existing one or add optional values if he wants. Vl. > > > ----- Original Message ----- >> From: "Vlastimil Elias" >> To: keycloak-dev at lists.jboss.org >> Sent: Thursday, 11 June, 2015 9:57:05 AM >> Subject: Re: [keycloak-dev] verify email is skipped if no email >> >> >> >> This is covered by https://issues.jboss.org/browse/KEYCLOAK-1371 which >> allows to configure Identity provider to Show "update profile" page on >> first login only when some mandatory field is missing. For now user >> profile mandatory fields are hardcoded (email, first and last name). It >> should be cool to allow configuration of which user profile fields are >> mandatory. >> >> Vl. >> >> >> On 10.6.2015 19:13, Stian Thorgersen wrote: >>> ----- Original Message ----- >>>> From: "Bill Burke" >>>> To: keycloak-dev at lists.jboss.org >>>> Sent: Wednesday, 10 June, 2015 4:48:17 PM >>>> Subject: [keycloak-dev] verify email is skipped if no email >>>> >>>> The verify email required action is skipped if the user has no email. >>>> Is this the right behavior? Should the user instead be required to >>>> enter in an email address that can be verified? >>> +1 It doesn't really make sense to require users to verify their email, but >>> at the same time not require users to enter one >>> >>>> -- >>>> Bill Burke >>>> JBoss, a division of Red Hat >>>> http://bill.burkecentral.com >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> -- >> Vlastimil Elias >> Principal Software Engineer >> jboss.org Development Team >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> -- Vlastimil Elias Principal Software Engineer jboss.org Development Team From bburke at redhat.com Mon Jun 15 08:58:53 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 15 Jun 2015 08:58:53 -0400 Subject: [keycloak-dev] meet about auth spi before commit? Message-ID: <557ECC0D.2070003@redhat.com> Can I commit the auth spi after I fix my 10 merge conflicts? Or do we need to meet so I can explain the changes before I commit? -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Mon Jun 15 09:16:34 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 15 Jun 2015 09:16:34 -0400 (EDT) Subject: [keycloak-dev] meet about auth spi before commit? In-Reply-To: <557ECC0D.2070003@redhat.com> References: <557ECC0D.2070003@redhat.com> Message-ID: <670065953.17902677.1434374194083.JavaMail.zimbra@redhat.com> Go for it! ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Monday, 15 June, 2015 2:58:53 PM > Subject: [keycloak-dev] meet about auth spi before commit? > > Can I commit the auth spi after I fix my 10 merge conflicts? Or do we > need to meet so I can explain the changes before I commit? > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bburke at redhat.com Mon Jun 15 09:51:37 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 15 Jun 2015 09:51:37 -0400 Subject: [keycloak-dev] auth spi merged Message-ID: <557ED869.4010102@redhat.com> Big changes on how we do authentication. I still need to use this new model for direct grant. There's still a bit of worked to do around Events and ClientSessionCode. I'd like to do a presentation on it Thursday. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Mon Jun 15 10:11:36 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 15 Jun 2015 10:11:36 -0400 Subject: [keycloak-dev] bring back ability to disable direct grant Message-ID: <557EDD18.5000001@redhat.com> I was thinking about recaptcha support. The purpose of recaptcha is to make sure a bot is not trying to log into system. Really good for something like registration, but also very useful for regular logins for extra security. Recaptcha would elleviate the need for Brute Force Protector. This thing is though, if you still have direct grant, then putting in recaptcha at login is pointless as an attacker can just go through direct grant. Can we bring back the ability to disable direct grant? -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From srossillo at smartling.com Mon Jun 15 10:49:05 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Mon, 15 Jun 2015 10:49:05 -0400 Subject: [keycloak-dev] Unable to assign roles from a federation provider Message-ID: <4154AAD4-3C42-422B-8FD5-FAA21732B91B@smartling.com> Hey all, I was going to create a JIRA for this, but just want to make sure it?s an actual bug. We are not able to assign roles to a user from a federation provider. For example, we expected something like this to work from UserFederationProvider. getUserByUsername(RealmModel realm, String username): if (remoteUser.getRoles() != null) { for (String roleName : remoteUser.getRoles()) { RoleModel role = realm.getRole(roleName); userModel.getRoleMappings().add(role); // doesn?t work userModel.getRealmRoleMappings().add(role); // doesn?t work } } However, nothing but the default role is assigned even when we confirm additional roles are assigned to remoteUser and realm.getRole() returns a valid RoleModel. Create JIRA or should we be assigning roles from a UserFederationProvider in another way? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150615/945cd8d1/attachment.html From tkyjovsk at redhat.com Mon Jun 15 13:14:03 2015 From: tkyjovsk at redhat.com (Tomas Kyjovsky) Date: Mon, 15 Jun 2015 13:14:03 -0400 (EDT) Subject: [keycloak-dev] Propagating system props to keycloak.json on WildFly In-Reply-To: <649687355.14112120.1434386936105.JavaMail.zimbra@redhat.com> Message-ID: <331239023.14123792.1434388443248.JavaMail.zimbra@redhat.com> While working on arquillian adapter tests I hit a problem when deploying some of the test servlets to standalone WF. The original AdapterTest sets some system props that are later used by "session-portal" and "input-portal": [1-3]. AdapterTest.java: // Test that replacing system properties works for adapters System.setProperty("app.server.base.url", "http://localhost:8081"); System.setProperty("my.host.name", "localhost"); App's keycloak.json: "auth-server-url" : "http://${my.host.name}:8081/auth", While this works on embedded container, with a standalone WF I get this error during deployment: IllegalArgumentException: Illegal character in authority at index 7: http://${my.host.name}:8180/auth Any ideas on how to proceed? Do I just need to set the actual values in keycloak.json before test as it is done for the other test apps? Regards, Tomas [1] https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/test/java/org/keycloak/testsuite/adapter/AdapterTest.java#L81 [2] https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/test/resources/adapter-test/session-keycloak.json#L5 [3] https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/test/java/org/keycloak/testsuite/adapter/InputServlet.java#L18 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: stack-trace.txt Url: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150615/f6078097/attachment.txt From stian at redhat.com Mon Jun 15 13:43:17 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 15 Jun 2015 13:43:17 -0400 (EDT) Subject: [keycloak-dev] bring back ability to disable direct grant In-Reply-To: <557EDD18.5000001@redhat.com> References: <557EDD18.5000001@redhat.com> Message-ID: <2012172930.18641823.1434390197887.JavaMail.zimbra@redhat.com> recaptcha are not seen as secure, they just make it slightly harder. Brute-force protection and intrusion detection are still needed. IMO recaptcha's are a false sense of security and the only thing they do are bug the shit out of users. Direct grant should definitively be enabled by default, but I don't have any objections to having an option to disable it. ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Monday, 15 June, 2015 4:11:36 PM > Subject: [keycloak-dev] bring back ability to disable direct grant > > I was thinking about recaptcha support. The purpose of recaptcha is to > make sure a bot is not trying to log into system. Really good for > something like registration, but also very useful for regular logins for > extra security. Recaptcha would elleviate the need for Brute Force > Protector. > > This thing is though, if you still have direct grant, then putting in > recaptcha at login is pointless as an attacker can just go through > direct grant. > > Can we bring back the ability to disable direct grant? > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From stian at redhat.com Mon Jun 15 13:46:59 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 15 Jun 2015 13:46:59 -0400 (EDT) Subject: [keycloak-dev] Propagating system props to keycloak.json on WildFly In-Reply-To: <331239023.14123792.1434388443248.JavaMail.zimbra@redhat.com> References: <331239023.14123792.1434388443248.JavaMail.zimbra@redhat.com> Message-ID: <208145020.18643181.1434390419116.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Tomas Kyjovsky" > To: keycloak-dev at lists.jboss.org > Sent: Monday, 15 June, 2015 7:14:03 PM > Subject: [keycloak-dev] Propagating system props to keycloak.json on WildFly > > While working on arquillian adapter tests I hit a problem when deploying some > of the test servlets to standalone WF. > > The original AdapterTest sets some system props that are later used by > "session-portal" and "input-portal": [1-3]. > > AdapterTest.java: > // Test that replacing system properties works for adapters > System.setProperty("app.server.base.url", "http://localhost:8081"); > System.setProperty("my.host.name", "localhost"); > > App's keycloak.json: > "auth-server-url" : "http://${my.host.name}:8081/auth", > > > While this works on embedded container, with a standalone WF I get this error > during deployment: > > IllegalArgumentException: Illegal character in authority at index 7: > http://${my.host.name}:8180/auth > > Any ideas on how to proceed? > Do I just need to set the actual values in keycloak.json before test as it is > done for the other test apps? Yes, if I remember correctly if the sys prop doesn't exist it just leaves it alone (and http://${my.host.name}:8180/auth isn't a valid url). Actually, we need to make sure that this test (or another test) uses this property as that's a feature of keycloak.json that you can refer to sys props and env variables. > > > Regards, > Tomas > > > [1] > https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/test/java/org/keycloak/testsuite/adapter/AdapterTest.java#L81 > [2] > https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/test/resources/adapter-test/session-keycloak.json#L5 > [3] > https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/test/java/org/keycloak/testsuite/adapter/InputServlet.java#L18 > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Mon Jun 15 16:08:26 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 15 Jun 2015 16:08:26 -0400 Subject: [keycloak-dev] 2 places to edit modules now? Message-ID: <557F30BA.5070700@redhat.com> Module definition is now done in 3 places? Copies of one another? eap6-service-overlay server-feature-pack adapter-feature-pack This is very very error prone guys. I guarantee somebody will forget to update something. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From matzew at apache.org Mon Jun 15 21:37:04 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 16 Jun 2015 03:37:04 +0200 Subject: [keycloak-dev] Keycloak Admin Console - Pixel fu? Message-ID: Hi, looking at the Keycloak Admin Console from the (standalone) OpenShift cartridge, I think the logo is a bit cut-off: https://www.dropbox.com/s/axlw08h5emyz6fp/Screen%20Shot%202015-06-16%20at%2003.15.18.png?dl=0 Is that on intention? Or something wrong w/ PatternFly, or the default theme? Greetings, Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150616/870d32d5/attachment-0001.html From stian at redhat.com Tue Jun 16 01:06:06 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 16 Jun 2015 01:06:06 -0400 (EDT) Subject: [keycloak-dev] Keycloak Admin Console - Pixel fu? In-Reply-To: References: Message-ID: <1955419640.19051652.1434431166073.JavaMail.zimbra@redhat.com> It's the intention ;) The space for the logo wasn't big enough for the full logo and I didn't want to increase the height. ----- Original Message ----- > From: "Matthias Wessendorf" > To: keycloak-dev at lists.jboss.org > Sent: Tuesday, 16 June, 2015 3:37:04 AM > Subject: [keycloak-dev] Keycloak Admin Console - Pixel fu? > > Hi, > > looking at the Keycloak Admin Console from the (standalone) OpenShift > cartridge, I think the logo is a bit cut-off: > https://www.dropbox.com/s/axlw08h5emyz6fp/Screen%20Shot%202015-06-16%20at%2003.15.18.png?dl=0 > > Is that on intention? Or something wrong w/ PatternFly, or the default theme? > > Greetings, > Matthias > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Tue Jun 16 01:14:04 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 16 Jun 2015 01:14:04 -0400 (EDT) Subject: [keycloak-dev] 2 places to edit modules now? In-Reply-To: <557F30BA.5070700@redhat.com> References: <557F30BA.5070700@redhat.com> Message-ID: <1867903653.19069324.1434431644548.JavaMail.zimbra@redhat.com> Yep, I know. It sucks! The aim is to improve on it if we can, but we have some issue on feature-packs and also there's some differences. With regards to server bits, there's two places: * feature-packs/server-feature-pack * server-overlay/eap6/eap6-server-modules The problem is that the way modules are defined in feature-packs are different. I don't think we can build modules for EAP6 from the WF9 feature-pack. It's probably not worth the effort finding out either as EAP6 support is only temporary. With regards to adapters there's even more places, but much less modules: * as7-eap6-adapter/as7-modules * wf8-adapter/wf8-modules * wf9-adapter/wf9-modules adapter-feature-pack isn't actually used by adapter dists yet as we don't yet know how to build a "add-on" zip from feature packs. Once we figure that out "wf9-adapter/wf9-modules" will go. There's a few difference between the modules built for each adapter, so not sure it makes sense to have the same for all or not. ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Monday, 15 June, 2015 10:08:26 PM > Subject: [keycloak-dev] 2 places to edit modules now? > > Module definition is now done in 3 places? Copies of one another? > > eap6-service-overlay > server-feature-pack > adapter-feature-pack > > This is very very error prone guys. I guarantee somebody will forget to > update something. > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From tkyjovsk at redhat.com Tue Jun 16 07:17:33 2015 From: tkyjovsk at redhat.com (Tomas Kyjovsky) Date: Tue, 16 Jun 2015 07:17:33 -0400 (EDT) Subject: [keycloak-dev] Propagating system props to keycloak.json on WildFly In-Reply-To: <208145020.18643181.1434390419116.JavaMail.zimbra@redhat.com> References: <331239023.14123792.1434388443248.JavaMail.zimbra@redhat.com> <208145020.18643181.1434390419116.JavaMail.zimbra@redhat.com> Message-ID: <1833660212.14494900.1434453453546.JavaMail.zimbra@redhat.com> ----- Original Message ----- > > > ----- Original Message ----- > > From: "Tomas Kyjovsky" > > To: keycloak-dev at lists.jboss.org > > Sent: Monday, 15 June, 2015 7:14:03 PM > > Subject: [keycloak-dev] Propagating system props to keycloak.json on > > WildFly > > > > While working on arquillian adapter tests I hit a problem when deploying > > some > > of the test servlets to standalone WF. > > > > The original AdapterTest sets some system props that are later used by > > "session-portal" and "input-portal": [1-3]. > > > > AdapterTest.java: > > // Test that replacing system properties works for adapters > > System.setProperty("app.server.base.url", "http://localhost:8081"); > > System.setProperty("my.host.name", "localhost"); > > > > App's keycloak.json: > > "auth-server-url" : "http://${my.host.name}:8081/auth", > > > > > > While this works on embedded container, with a standalone WF I get this > > error > > during deployment: > > > > IllegalArgumentException: Illegal character in authority at index 7: > > http://${my.host.name}:8180/auth > > > > Any ideas on how to proceed? > > Do I just need to set the actual values in keycloak.json before test as it > > is > > done for the other test apps? > > Yes, if I remember correctly if the sys prop doesn't exist it just leaves it > alone (and http://${my.host.name}:8180/auth isn't a valid url). > > Actually, we need to make sure that this test (or another test) uses this > property as that's a feature of keycloak.json that you can refer to sys > props and env variables. Problem was on my side - I passed the system props to the wrong container (keycloak server instead of the app server). I fixed it and it works fine now. > > > > > > > Regards, > > Tomas > > > > > > [1] > > https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/test/java/org/keycloak/testsuite/adapter/AdapterTest.java#L81 > > [2] > > https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/test/resources/adapter-test/session-keycloak.json#L5 > > [3] > > https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/test/java/org/keycloak/testsuite/adapter/InputServlet.java#L18 > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From ssilvert at redhat.com Tue Jun 16 08:18:30 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 16 Jun 2015 08:18:30 -0400 Subject: [keycloak-dev] 2 places to edit modules now? In-Reply-To: <557F30BA.5070700@redhat.com> References: <557F30BA.5070700@redhat.com> Message-ID: <55801416.7050503@redhat.com> Cross-posting to wildfly-dev. It sounds like we need a way to standardize module.xml definitions across projects and have them accessible from maven GAV's. These module.xml files are rarely different between projects and it doesn't make sense for each feature pack to define its own copy. On 6/15/2015 4:08 PM, Bill Burke wrote: > Module definition is now done in 3 places? Copies of one another? > > eap6-service-overlay > server-feature-pack > adapter-feature-pack > > This is very very error prone guys. I guarantee somebody will forget to > update something. > > From ssilvert at redhat.com Tue Jun 16 09:24:50 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 16 Jun 2015 09:24:50 -0400 Subject: [keycloak-dev] [wildfly-dev] 2 places to edit modules now? In-Reply-To: References: <557F30BA.5070700@redhat.com> <55801416.7050503@redhat.com> Message-ID: <558023A2.3080103@redhat.com> On 6/16/2015 8:36 AM, Toma? Cerar wrote: > A feature-pack can extend another feature pack, > I am sure you guys know that. > > so you could have "keycloak-base" feature pack that all other 3 extend. > > the base would than have all common modules defined. > and other 3 extra specializations. That's an OK approach if there is a well-defined base of modules that several projects use. But that's really not the case. In any feature pack I should be able to just list the artifacts I'm using and it provides a default module.xml file for that. > > -- > tomaz > > On Tue, Jun 16, 2015 at 2:18 PM, Stan Silvert > wrote: > > Cross-posting to wildfly-dev. > > It sounds like we need a way to standardize module.xml definitions > across projects and have them accessible from maven GAV's. These > module.xml files are rarely different between projects and it doesn't > make sense for each feature pack to define its own copy. > > On 6/15/2015 4:08 PM, Bill Burke wrote: > > Module definition is now done in 3 places? Copies of one another? > > > > eap6-service-overlay > > server-feature-pack > > adapter-feature-pack > > > > This is very very error prone guys. I guarantee somebody will > forget to > > update something. > > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150616/5e01dadb/attachment.html From mstrukel at redhat.com Tue Jun 16 09:48:06 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Tue, 16 Jun 2015 09:48:06 -0400 (EDT) Subject: [keycloak-dev] [wildfly-dev] 2 places to edit modules now? In-Reply-To: <558023A2.3080103@redhat.com> References: <557F30BA.5070700@redhat.com> <55801416.7050503@redhat.com> <558023A2.3080103@redhat.com> Message-ID: <1071170582.2821893.1434462486816.JavaMail.zimbra@redhat.com> I see two issues here ... 1. For Keycloak we are targetting previous wildfly / eap versions as well. Feature packs functionality targets Wildfly 9+ IIUC so we can't use it for previous versions. 2. We support distribution packaging we call overlay distribution ... where all we provide is modules + configuration resources which users simply unzip into existing wildfly / eap directory. I'm not sure feature packs support this at all. For example, can I do a feature pack that only produces a set of modules, and where I can specify which jboss-modules version to target? Currently we use old school modules generation (ant plugin, build.xml, lib.xml) for previous versions of wildfly / eap, and feature pack for Wildfly 9 where we cheat for overlay distributions by doing full pack and only copy modules from it into our distribution archive. ----- Original Message ----- > On 6/16/2015 8:36 AM, Toma? Cerar wrote: > > > > A feature-pack can extend another feature pack, > I am sure you guys know that. > > so you could have "keycloak-base" feature pack that all other 3 extend. > > the base would than have all common modules defined. > and other 3 extra specializations. > That's an OK approach if there is a well-defined base of modules that several > projects use. But that's really not the case. > > In any feature pack I should be able to just list the artifacts I'm using and > it provides a default module.xml file for that. > > > > > -- > tomaz > > On Tue, Jun 16, 2015 at 2:18 PM, Stan Silvert < ssilvert at redhat.com > wrote: > > > Cross-posting to wildfly-dev. > > It sounds like we need a way to standardize module.xml definitions > across projects and have them accessible from maven GAV's. These > module.xml files are rarely different between projects and it doesn't > make sense for each feature pack to define its own copy. > > On 6/15/2015 4:08 PM, Bill Burke wrote: > > Module definition is now done in 3 places? Copies of one another? > > > > eap6-service-overlay > > server-feature-pack > > adapter-feature-pack > > > > This is very very error prone guys. I guarantee somebody will forget to > > update something. > > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From pmensik at redhat.com Tue Jun 16 11:58:38 2015 From: pmensik at redhat.com (Petr Mensik) Date: Tue, 16 Jun 2015 11:58:38 -0400 (EDT) Subject: [keycloak-dev] How to remove expired user sessions? In-Reply-To: <910888893.2817495.1434470083323.JavaMail.zimbra@redhat.com> Message-ID: <704510145.2820647.1434470318283.JavaMail.zimbra@redhat.com> Hello guys, I came across this while I was rewriting integration tests to Arquillian. There is a code which calls KeycloakSession#sessions().removeExpiredUserSessions(realm) (in AdapterTestStragetegy), is there any equivalent of this in the UI of admin console or a call through REST API (via org.keycloak.admin.client.Keycloak) ? Because I haven't been able to find neither of these options. Thanks a lot for help. Petr Mensik | IRC: pmensik Quality Engineer | Quality Engineering Red Hat Czech, s.r.o. 612 45 Brno, Czech Republic From bburke at redhat.com Tue Jun 16 12:58:09 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 16 Jun 2015 12:58:09 -0400 Subject: [keycloak-dev] How to remove expired user sessions? In-Reply-To: <704510145.2820647.1434470318283.JavaMail.zimbra@redhat.com> References: <704510145.2820647.1434470318283.JavaMail.zimbra@redhat.com> Message-ID: <558055A1.8090905@redhat.com> Nothing. Log a jira please. Something we should have. On 6/16/2015 11:58 AM, Petr Mensik wrote: > Hello guys, > > I came across this while I was rewriting integration tests to Arquillian. There is a code which calls KeycloakSession#sessions().removeExpiredUserSessions(realm) (in AdapterTestStragetegy), is there any equivalent of this in the UI of admin console or a call through REST API (via org.keycloak.admin.client.Keycloak) ? Because I haven't been able to find neither of these options. Thanks a lot for help. > > Petr Mensik | IRC: pmensik > Quality Engineer | Quality Engineering > > Red Hat Czech, s.r.o. > 612 45 Brno, Czech Republic > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From mposolda at redhat.com Wed Jun 17 06:20:05 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 17 Jun 2015 12:20:05 +0200 Subject: [keycloak-dev] Unable to assign roles from a federation provider In-Reply-To: <4154AAD4-3C42-422B-8FD5-FAA21732B91B@smartling.com> References: <4154AAD4-3C42-422B-8FD5-FAA21732B91B@smartling.com> Message-ID: <558149D5.5040106@redhat.com> Hi, you should use method "userModel.grantRole(role)" to add new role mapping. Methods "getRoleMappings" and "getRealmRoleMappings" are used just for reading existing role mappings of user. Marek On 15.6.2015 16:49, Scott Rossillo wrote: > Hey all, > > I was going to create a JIRA for this, but just want to make sure it?s > an actual bug. We are not able to assign roles to a user from a > federation provider. > > For example, we expected something like this to work > from UserFederationProvider. getUserByUsername(RealmModel realm, > String username): > > if (remoteUser.getRoles() != null) { > for (String roleName : remoteUser.getRoles()) { > RoleModel role = realm.getRole(roleName); > userModel.getRoleMappings().add(role); // doesn?t work > userModel.getRealmRoleMappings().add(role); // doesn?t work > } > } > > However, nothing but the default role is assigned even when we confirm > additional roles are assigned to remoteUser and realm.getRole() > returns a valid RoleModel. > > Create JIRA or should we be assigning roles from a > UserFederationProvider in another way? > > Thanks > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150617/da0995c3/attachment-0001.html From slaskawi at redhat.com Wed Jun 17 10:16:27 2015 From: slaskawi at redhat.com (=?UTF-8?B?U2ViYXN0aWFuIMWBYXNrYXdpZWM=?=) Date: Wed, 17 Jun 2015 16:16:27 +0200 Subject: [keycloak-dev] Keycloak and WebSockets Message-ID: <5581813B.8060301@redhat.com> Hey! I would like to ask if it is possible to secure a WebSocket endpoint (which is deployed on Wildfly/EAP) using Keycloak? The client part is written in Angular JS, so I would be also interested in Angular JS WebSocket integration. Thanks Sebastian From supittma at redhat.com Wed Jun 17 10:41:23 2015 From: supittma at redhat.com (Summers Pittman) Date: Wed, 17 Jun 2015 10:41:23 -0400 Subject: [keycloak-dev] Keycloak and WebSockets In-Reply-To: <5581813B.8060301@redhat.com> References: <5581813B.8060301@redhat.com> Message-ID: On Wed, Jun 17, 2015 at 10:16 AM, Sebastian ?askawiec wrote: > Hey! > > I would like to ask if it is possible to secure a WebSocket endpoint > (which is deployed on Wildfly/EAP) using Keycloak? > Yes. > > The client part is written in Angular JS, so I would be also interested > in Angular JS WebSocket integration. > > Thanks > Sebastian > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150617/cb52d672/attachment.html From supittma at redhat.com Wed Jun 17 10:44:44 2015 From: supittma at redhat.com (Summers Pittman) Date: Wed, 17 Jun 2015 10:44:44 -0400 Subject: [keycloak-dev] Keycloak and WebSockets In-Reply-To: References: <5581813B.8060301@redhat.com> Message-ID: Damnit, I thought I had some code ready to show you. Give me five minutes (sorry about one wording you) On Wed, Jun 17, 2015 at 10:41 AM, Summers Pittman wrote: > > On Wed, Jun 17, 2015 at 10:16 AM, Sebastian ?askawiec > wrote: > >> Hey! >> >> I would like to ask if it is possible to secure a WebSocket endpoint >> (which is deployed on Wildfly/EAP) using Keycloak? >> > Yes. > >> >> The client part is written in Angular JS, so I would be also interested >> in Angular JS WebSocket integration. >> >> Thanks >> Sebastian >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150617/e7af9e93/attachment.html From supittma at redhat.com Wed Jun 17 14:55:44 2015 From: supittma at redhat.com (Summers Pittman) Date: Wed, 17 Jun 2015 14:55:44 -0400 Subject: [keycloak-dev] Keycloak and WebSockets In-Reply-To: References: <5581813B.8060301@redhat.com> Message-ID: https://github.com/secondsun/wildfly-secured-websocket magic is in the web.xml, your local app server needs to be using KeyCloak module 1.2.0. oidc will take you to google's sso. On Wed, Jun 17, 2015 at 10:44 AM, Summers Pittman wrote: > Damnit, I thought I had some code ready to show you. Give me five minutes > (sorry about one wording you) > > On Wed, Jun 17, 2015 at 10:41 AM, Summers Pittman > wrote: > >> >> On Wed, Jun 17, 2015 at 10:16 AM, Sebastian ?askawiec < >> slaskawi at redhat.com> wrote: >> >>> Hey! >>> >>> I would like to ask if it is possible to secure a WebSocket endpoint >>> (which is deployed on Wildfly/EAP) using Keycloak? >>> >> Yes. >> >>> >>> The client part is written in Angular JS, so I would be also interested >>> in Angular JS WebSocket integration. >>> >>> Thanks >>> Sebastian >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150617/27a932a5/attachment.html From stian at redhat.com Thu Jun 18 02:04:27 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 18 Jun 2015 02:04:27 -0400 (EDT) Subject: [keycloak-dev] Simplifying realm model In-Reply-To: <385933137.20855369.1434607019577.JavaMail.zimbra@redhat.com> Message-ID: <1953167599.20857714.1434607467311.JavaMail.zimbra@redhat.com> Maintaining and updating the realm model is a PITA. There's multiple implementations each with their own adapters and entities. We also have migration to deal with. All in all we spend a significant amount of time updating the model, creating migrations and testing/fixing. How about everything for a realm is just stored as a single blob (RealmRepresentation) and everything for a client the same (ClientRepresentation)? We could have a single realm model provider that used the json representation classes. It would delegate storing to a much simpler realm store. The realm store would just be a key to value store. The value would just be the serialized json. Implementing this and maintaining it would be much simpler. Comments? Is this worth looking at? From stian at redhat.com Thu Jun 18 02:16:10 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 18 Jun 2015 02:16:10 -0400 (EDT) Subject: [keycloak-dev] 1.3.0.Final released Message-ID: <1634319053.20879598.1434608170616.JavaMail.zimbra@redhat.com> http://blog.keycloak.org/2015/06/keycloak-130final-released.html From slaskawi at redhat.com Thu Jun 18 02:52:43 2015 From: slaskawi at redhat.com (=?UTF-8?B?U2ViYXN0aWFuIMWBYXNrYXdpZWM=?=) Date: Thu, 18 Jun 2015 08:52:43 +0200 Subject: [keycloak-dev] Keycloak and WebSockets In-Reply-To: References: <5581813B.8060301@redhat.com> Message-ID: <55826ABB.7080507@redhat.com> Thanks Summers! That was exactly what I've been looking for! Sebastian On 06/17/2015 08:55 PM, Summers Pittman wrote: > https://github.com/secondsun/wildfly-secured-websocket > > magic is in the web.xml, your local app server needs to be using > KeyCloak module 1.2.0. > > oidc will take you to google's sso. > > On Wed, Jun 17, 2015 at 10:44 AM, Summers Pittman > wrote: > > Damnit, I thought I had some code ready to show you. Give me five > minutes (sorry about one wording you) > > On Wed, Jun 17, 2015 at 10:41 AM, Summers Pittman > > wrote: > > > On Wed, Jun 17, 2015 at 10:16 AM, Sebastian ?askawiec > > wrote: > > Hey! > > I would like to ask if it is possible to secure a > WebSocket endpoint > (which is deployed on Wildfly/EAP) using Keycloak? > > Yes. > > > The client part is written in Angular JS, so I would be > also interested > in Angular JS WebSocket integration. > > Thanks > Sebastian > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150618/0afa37ad/attachment-0001.html From stian at redhat.com Thu Jun 18 03:21:47 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 18 Jun 2015 03:21:47 -0400 (EDT) Subject: [keycloak-dev] Keycloak 1.3.0 release broken In-Reply-To: <1573846276.20943235.1434612067204.JavaMail.zimbra@redhat.com> Message-ID: <381788803.20943439.1434612107672.JavaMail.zimbra@redhat.com> Sorry everyone, Looks like I've pushed the button a bit to quick this time. The Keycloak 1.3.0 release is completely broken. Fix coming and 1.3.1 will be released soon. Cheers, Stian From mposolda at redhat.com Thu Jun 18 04:59:42 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 18 Jun 2015 10:59:42 +0200 Subject: [keycloak-dev] Simplifying realm model In-Reply-To: <1953167599.20857714.1434607467311.JavaMail.zimbra@redhat.com> References: <1953167599.20857714.1434607467311.JavaMail.zimbra@redhat.com> Message-ID: <5582887E.4020406@redhat.com> +1 to go this way for realm model. For users+userSessions I would likely keep it in current form due to performance reasons, but for realm model I am not seeing any issue to store it in blob as realm model doesn't contain big amount of data. I am seeing just advantages and much simpler migration and DB maintenance, which is currently pain. Marek On 18.6.2015 08:04, Stian Thorgersen wrote: > Maintaining and updating the realm model is a PITA. There's multiple implementations each with their own adapters and entities. We also have migration to deal with. > > All in all we spend a significant amount of time updating the model, creating migrations and testing/fixing. > > How about everything for a realm is just stored as a single blob (RealmRepresentation) and everything for a client the same (ClientRepresentation)? > > We could have a single realm model provider that used the json representation classes. It would delegate storing to a much simpler realm store. > > The realm store would just be a key to value store. The value would just be the serialized json. Implementing this and maintaining it would be much simpler. > > Comments? Is this worth looking at? > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Thu Jun 18 05:19:44 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 18 Jun 2015 05:19:44 -0400 (EDT) Subject: [keycloak-dev] Simplifying realm model In-Reply-To: <5582887E.4020406@redhat.com> References: <1953167599.20857714.1434607467311.JavaMail.zimbra@redhat.com> <5582887E.4020406@redhat.com> Message-ID: <891520174.20983513.1434619184239.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Marek Posolda" > To: "Stian Thorgersen" , "keycloak dev" > Sent: Thursday, 18 June, 2015 10:59:42 AM > Subject: Re: [keycloak-dev] Simplifying realm model > > +1 to go this way for realm model. For users+userSessions I would likely > keep it in current form due to performance reasons, but for realm model > I am not seeing any issue to store it in blob as realm model doesn't > contain big amount of data. I am seeing just advantages and much simpler > migration and DB maintenance, which is currently pain. Yep, user model is much simpler in either case and isn't such a pain. We could probably clean it up a bit, but would certainly keep a proper schema for it with many tables and such. > > Marek > > On 18.6.2015 08:04, Stian Thorgersen wrote: > > Maintaining and updating the realm model is a PITA. There's multiple > > implementations each with their own adapters and entities. We also have > > migration to deal with. > > > > All in all we spend a significant amount of time updating the model, > > creating migrations and testing/fixing. > > > > How about everything for a realm is just stored as a single blob > > (RealmRepresentation) and everything for a client the same > > (ClientRepresentation)? > > > > We could have a single realm model provider that used the json > > representation classes. It would delegate storing to a much simpler realm > > store. > > > > The realm store would just be a key to value store. The value would just be > > the serialized json. Implementing this and maintaining it would be much > > simpler. > > > > Comments? Is this worth looking at? > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > From stian at redhat.com Thu Jun 18 05:42:30 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 18 Jun 2015 05:42:30 -0400 (EDT) Subject: [keycloak-dev] Keycloak 1.3.1.Final released Message-ID: <1560632927.20989725.1434620550424.JavaMail.zimbra@redhat.com> http://blog.keycloak.org/2015/06/keycloak-131final-released.html From bburke at redhat.com Thu Jun 18 08:47:04 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 18 Jun 2015 08:47:04 -0400 Subject: [keycloak-dev] Simplifying realm model In-Reply-To: <891520174.20983513.1434619184239.JavaMail.zimbra@redhat.com> References: <1953167599.20857714.1434607467311.JavaMail.zimbra@redhat.com> <5582887E.4020406@redhat.com> <891520174.20983513.1434619184239.JavaMail.zimbra@redhat.com> Message-ID: <5582BDC8.3000805@redhat.com> This would make things easier to store custom data too. It could be extended to places where custom data could be prevalent. For example, credential storage. But here are the disadvantages: * Do we have to worry about concurrency issues more though? All you need is 2 concurrent admins modifying different settings in the realm for one to overwrite the other. For example, one admin could be adding a role, another could be configuring an identity provider. Sure, these kind of concurrency issues exist now, but they are isolated because realm model data is in different tables. Minimally, you would need some kind of optimistic locking scheme that provided a non-cryptic error message when there were collisions. * Admins would never be able to modify the database directly. On 6/18/2015 5:19 AM, Stian Thorgersen wrote: > > > ----- Original Message ----- >> From: "Marek Posolda" >> To: "Stian Thorgersen" , "keycloak dev" >> Sent: Thursday, 18 June, 2015 10:59:42 AM >> Subject: Re: [keycloak-dev] Simplifying realm model >> >> +1 to go this way for realm model. For users+userSessions I would likely >> keep it in current form due to performance reasons, but for realm model >> I am not seeing any issue to store it in blob as realm model doesn't >> contain big amount of data. I am seeing just advantages and much simpler >> migration and DB maintenance, which is currently pain. > > Yep, user model is much simpler in either case and isn't such a pain. We could probably clean it up a bit, but would certainly keep a proper schema for it with many tables and such. > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From vainnkiitta at gmail.com Thu Jun 18 09:47:13 2015 From: vainnkiitta at gmail.com (John) Date: Thu, 18 Jun 2015 19:17:13 +0530 Subject: [keycloak-dev] Error while building Keycloak 1.3.1 sources. Message-ID: Hi All, I have downloaded source of keycloak 1.3.1 ver. I am doing mvn install but getting following error. [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 45.121s [INFO] Finished at: Thu Jun 18 19:02:12 IST 2015 [INFO] Final Memory: 215M/865M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal on project keycloak-testsuite-security-proxy: Could not resolve dependencies for project org.keycloak:keycloak-testsuite-security-proxy:jar:1.3.1.Final: Could not find artifact org.keycloak:keycloak-testsuite-integration:jar:tests:1.3.1.Final in jboss-earlyaccess-repository (http://maven.repository.redhat.com/earlyaccess/all/) -> [Help 1] Any help appreciated. Thanks, John From stian at redhat.com Thu Jun 18 10:00:57 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 18 Jun 2015 10:00:57 -0400 (EDT) Subject: [keycloak-dev] Auth SPI is awesome! In-Reply-To: <1971383588.21241669.1434636039818.JavaMail.zimbra@redhat.com> Message-ID: <332514902.21242153.1434636057924.JavaMail.zimbra@redhat.com> Bill, Didn't get a chance to say this on the call, but I reckon the new SPI is awesome :) From bburke at redhat.com Thu Jun 18 10:05:46 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 18 Jun 2015 10:05:46 -0400 Subject: [keycloak-dev] Auth SPI is awesome! In-Reply-To: <332514902.21242153.1434636057924.JavaMail.zimbra@redhat.com> References: <332514902.21242153.1434636057924.JavaMail.zimbra@redhat.com> Message-ID: <5582D03A.1080302@redhat.com> I'm sorry it took so long. Month of May was insane for kids stuff. So many activities and school responsibilities. I was really distracted. On 6/18/2015 10:00 AM, Stian Thorgersen wrote: > Bill, > > Didn't get a chance to say this on the call, but I reckon the new SPI is awesome :) > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Thu Jun 18 10:08:32 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 18 Jun 2015 10:08:32 -0400 (EDT) Subject: [keycloak-dev] Simplifying realm model In-Reply-To: <5582BDC8.3000805@redhat.com> References: <1953167599.20857714.1434607467311.JavaMail.zimbra@redhat.com> <5582887E.4020406@redhat.com> <891520174.20983513.1434619184239.JavaMail.zimbra@redhat.com> <5582BDC8.3000805@redhat.com> Message-ID: <1473970272.21257323.1434636512872.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Thursday, 18 June, 2015 2:47:04 PM > Subject: Re: [keycloak-dev] Simplifying realm model > > This would make things easier to store custom data too. It could be > extended to places where custom data could be prevalent. For example, > credential storage. > > But here are the disadvantages: > > * Do we have to worry about concurrency issues more though? All you > need is 2 concurrent admins modifying different settings in the realm > for one to overwrite the other. For example, one admin could be adding > a role, another could be configuring an identity provider. Sure, these > kind of concurrency issues exist now, but they are isolated because > realm model data is in different tables. Minimally, you would need some > kind of optimistic locking scheme that provided a non-cryptic error > message when there were collisions. Yep, that's one of the bigger issues. What I had in mind was to use optimistic locking and also make rest endpoints retry an operation before returning an error to the admin. For example adding an identity provider would still be a separate rest endpoint, so if it fails to add it to the realm due to an optimistic locking exception it can simply retry adding it. > > * Admins would never be able to modify the database directly. I don't think that's a problem - in theory they could as it would just be a json doc so they could get it, change it, write it ;) > > On 6/18/2015 5:19 AM, Stian Thorgersen wrote: > > > > > > ----- Original Message ----- > >> From: "Marek Posolda" > >> To: "Stian Thorgersen" , "keycloak dev" > >> > >> Sent: Thursday, 18 June, 2015 10:59:42 AM > >> Subject: Re: [keycloak-dev] Simplifying realm model > >> > >> +1 to go this way for realm model. For users+userSessions I would likely > >> keep it in current form due to performance reasons, but for realm model > >> I am not seeing any issue to store it in blob as realm model doesn't > >> contain big amount of data. I am seeing just advantages and much simpler > >> migration and DB maintenance, which is currently pain. > > > > Yep, user model is much simpler in either case and isn't such a pain. We > > could probably clean it up a bit, but would certainly keep a proper schema > > for it with many tables and such. > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From stian at redhat.com Thu Jun 18 10:09:54 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 18 Jun 2015 10:09:54 -0400 (EDT) Subject: [keycloak-dev] Error while building Keycloak 1.3.1 sources. In-Reply-To: References: Message-ID: <1804904374.21258960.1434636594843.JavaMail.zimbra@redhat.com> What are the exact commands you're running? ----- Original Message ----- > From: "John" > To: keycloak-dev at lists.jboss.org > Sent: Thursday, 18 June, 2015 3:47:13 PM > Subject: [keycloak-dev] Error while building Keycloak 1.3.1 sources. > > Hi All, > > I have downloaded source of keycloak 1.3.1 ver. > > I am doing mvn install but getting following error. > > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 45.121s > [INFO] Finished at: Thu Jun 18 19:02:12 IST 2015 > [INFO] Final Memory: 215M/865M > [INFO] > ------------------------------------------------------------------------ > [ERROR] Failed to execute goal on project > keycloak-testsuite-security-proxy: Could not resolve dependencies for > project org.keycloak:keycloak-testsuite-security-proxy:jar:1.3.1.Final: > Could not find artifact > org.keycloak:keycloak-testsuite-integration:jar:tests:1.3.1.Final in > jboss-earlyaccess-repository > (http://maven.repository.redhat.com/earlyaccess/all/) -> [Help 1] > > Any help appreciated. > > Thanks, > John > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From stian at redhat.com Thu Jun 18 10:12:18 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 18 Jun 2015 10:12:18 -0400 (EDT) Subject: [keycloak-dev] Auth SPI is awesome! In-Reply-To: <5582D03A.1080302@redhat.com> References: <332514902.21242153.1434636057924.JavaMail.zimbra@redhat.com> <5582D03A.1080302@redhat.com> Message-ID: <255349993.21261661.1434636738597.JavaMail.zimbra@redhat.com> Good things comes to those who wait ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Thursday, 18 June, 2015 4:05:46 PM > Subject: Re: [keycloak-dev] Auth SPI is awesome! > > I'm sorry it took so long. Month of May was insane for kids stuff. So > many activities and school responsibilities. I was really distracted. > > On 6/18/2015 10:00 AM, Stian Thorgersen wrote: > > Bill, > > > > Didn't get a chance to say this on the call, but I reckon the new SPI is > > awesome :) > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From vainnkiitta at gmail.com Thu Jun 18 10:33:12 2015 From: vainnkiitta at gmail.com (John) Date: Thu, 18 Jun 2015 20:03:12 +0530 Subject: [keycloak-dev] Error while building Keycloak 1.3.1 sources. In-Reply-To: <1804904374.21258960.1434636594843.JavaMail.zimbra@redhat.com> References: <1804904374.21258960.1434636594843.JavaMail.zimbra@redhat.com> Message-ID: Using mvn install -Dmaven.test.skip=true My maven version Apache Maven 3.0.5 Maven home: /usr/share/maven Java version: 1.7.0_79, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre Default locale: en_IN, platform encoding: UTF-8 OS name: "linux", version: "3.13.0-55-generic", arch: "amd64", family: "unix" On Thu, Jun 18, 2015 at 7:39 PM, Stian Thorgersen wrote: > What are the exact commands you're running? > > ----- Original Message ----- >> From: "John" >> To: keycloak-dev at lists.jboss.org >> Sent: Thursday, 18 June, 2015 3:47:13 PM >> Subject: [keycloak-dev] Error while building Keycloak 1.3.1 sources. >> >> Hi All, >> >> I have downloaded source of keycloak 1.3.1 ver. >> >> I am doing mvn install but getting following error. >> >> [INFO] >> ------------------------------------------------------------------------ >> [INFO] BUILD FAILURE >> [INFO] >> ------------------------------------------------------------------------ >> [INFO] Total time: 45.121s >> [INFO] Finished at: Thu Jun 18 19:02:12 IST 2015 >> [INFO] Final Memory: 215M/865M >> [INFO] >> ------------------------------------------------------------------------ >> [ERROR] Failed to execute goal on project >> keycloak-testsuite-security-proxy: Could not resolve dependencies for >> project org.keycloak:keycloak-testsuite-security-proxy:jar:1.3.1.Final: >> Could not find artifact >> org.keycloak:keycloak-testsuite-integration:jar:tests:1.3.1.Final in >> jboss-earlyaccess-repository >> (http://maven.repository.redhat.com/earlyaccess/all/) -> [Help 1] >> >> Any help appreciated. >> >> Thanks, >> John >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150618/f154b839/attachment.html From mposolda at redhat.com Thu Jun 18 10:34:24 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 18 Jun 2015 16:34:24 +0200 Subject: [keycloak-dev] Auth SPI is awesome! In-Reply-To: <332514902.21242153.1434636057924.JavaMail.zimbra@redhat.com> References: <332514902.21242153.1434636057924.JavaMail.zimbra@redhat.com> Message-ID: <5582D6F0.3060206@redhat.com> +1 Marek On 18.6.2015 16:00, Stian Thorgersen wrote: > Bill, > > Didn't get a chance to say this on the call, but I reckon the new SPI is awesome :) > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Thu Jun 18 11:54:02 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 18 Jun 2015 11:54:02 -0400 Subject: [keycloak-dev] kerberos retry issue we talked about Message-ID: <5582E99A.40609@redhat.com> Hitting the cancel button works. Hitting the cancel button sends you back to the app, which sends you back to keycloak and starts a new client session. So that would work fine. What doesn't work is refreshing the page. Kerberos won't be attempted again. Would it be ok that any browser page refresh might completely reset the authentication flow and the user has to re login? If so, I think I have a solution to the problem, but it would take quite a bit of refactoring of the auth spi...Not another two months of work :) But probably another few days or a week. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Thu Jun 18 13:45:28 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 18 Jun 2015 13:45:28 -0400 (EDT) Subject: [keycloak-dev] kerberos retry issue we talked about In-Reply-To: <5582E99A.40609@redhat.com> References: <5582E99A.40609@redhat.com> Message-ID: <1198354491.21734087.1434649528141.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Thursday, 18 June, 2015 5:54:02 PM > Subject: [keycloak-dev] kerberos retry issue we talked about > > Hitting the cancel button works. Hitting the cancel button sends you > back to the app, which sends you back to keycloak and starts a new > client session. So that would work fine. > > What doesn't work is refreshing the page. Kerberos won't be attempted > again. Would it be ok that any browser page refresh might completely > reset the authentication flow and the user has to re login? If so, I > think I have a solution to the problem, but it would take quite a bit of > refactoring of the auth spi...Not another two months of work :) But > probably another few days or a week. As long as the user is actively refreshing the page that works, but I wonder if there's cases where it could break things. For example if there's high load on the system and some requests time out, then when user retries the request they end up in the beginning of the login flow again. Why could it not just continue the flow at the step it's on? Basically a challenge wouldn't count as moving on. So when password authenticator sends the challenge for the first request, you'd still be on stage 0 when the user refreshes the page. > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bburke at redhat.com Thu Jun 18 15:36:14 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 18 Jun 2015 15:36:14 -0400 Subject: [keycloak-dev] kerberos retry issue we talked about In-Reply-To: <1198354491.21734087.1434649528141.JavaMail.zimbra@redhat.com> References: <5582E99A.40609@redhat.com> <1198354491.21734087.1434649528141.JavaMail.zimbra@redhat.com> Message-ID: <55831DAE.7060800@redhat.com> On 6/18/2015 1:45 PM, Stian Thorgersen wrote: > > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Thursday, 18 June, 2015 5:54:02 PM >> Subject: [keycloak-dev] kerberos retry issue we talked about >> >> Hitting the cancel button works. Hitting the cancel button sends you >> back to the app, which sends you back to keycloak and starts a new >> client session. So that would work fine. >> >> What doesn't work is refreshing the page. Kerberos won't be attempted >> again. Would it be ok that any browser page refresh might completely >> reset the authentication flow and the user has to re login? If so, I >> think I have a solution to the problem, but it would take quite a bit of >> refactoring of the auth spi...Not another two months of work :) But >> probably another few days or a week. > > As long as the user is actively refreshing the page that works, but I wonder if there's cases where it could break things. For example if there's high load on the system and some requests time out, then when user retries the request they end up in the beginning of the login flow again. > Nothing would break, the user would just have to start over. If there is only 1 login form, then this isn't an issue at all. BTW, OIDC has an issue with this too if the user hits a browser refresh in the middle of the code_to_token exchange. Since the code can only be exchanged once, the browser refresh will be a second request and fail. SAML doesn't have this issue because there is no out of band callback to the server. Honestly, I think it makes the algorithm much easier, simpler, and safer if there is a complete client session reset on a page refresh. > Why could it not just continue the flow at the step it's on? Basically a challenge wouldn't count as moving on. So when password authenticator sends the challenge for the first request, you'd still be on stage 0 when the user refreshes the page. > You're forgetting the original problem. We want Kerberos to be re-attempted on a page refresh. The algorithm would have to know where it had to go back and retry. Forms are contained in a nested flow. How would you know when to hop back up to the parent flow and retry things? It just gets real complicated. There's a few problems with browser page refresh: * On a page refresh, the exact request is resubmitted. This means a POST sends a POST to the previous authenticator's URL action. * You need to guard against an attacker trying to jump around in a flow. * What about back button? Also, What I"m doing right now is to change the ClientSEssionCode every form challenge. So, page refresh is actually completely broken now :( Man, I need to rethink this. Actually even within the old code, refresh page was broken when you went from authentication to the required action page and then hit refresh. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Thu Jun 18 16:35:18 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 18 Jun 2015 16:35:18 -0400 Subject: [keycloak-dev] auth timeout behavior change Message-ID: <55832B86.7090209@redhat.com> Right now, if there is a timeout between actions when logging in, we show an error page. I think I'd rather we just reset the ClientSession and start over from the beginning. Might be a bit more user friendly. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From srossillo at smartling.com Thu Jun 18 16:44:15 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Thu, 18 Jun 2015 16:44:15 -0400 Subject: [keycloak-dev] auth timeout behavior change In-Reply-To: <55832B86.7090209@redhat.com> References: <55832B86.7090209@redhat.com> Message-ID: <2382DE96-F5F5-4B98-98FC-ABC0FCC1DF73@smartling.com> The current behavior is less than ideal and not a good user experience, but what happens if the session on client times out? It?s not going to be able to reconcile the state on redirect after login. Maybe the behavior should be configurable? Maybe I?m missing something. What do you mean by reset the ClientSession and start over from the beginning? Where is the beginning? ~ Scott > On Jun 18, 2015, at 4:35 PM, Bill Burke wrote: > > Right now, if there is a timeout between actions when logging in, we > show an error page. I think I'd rather we just reset the ClientSession > and start over from the beginning. Might be a bit more user friendly. > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Thu Jun 18 16:47:28 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 18 Jun 2015 16:47:28 -0400 Subject: [keycloak-dev] auth timeout behavior change In-Reply-To: <2382DE96-F5F5-4B98-98FC-ABC0FCC1DF73@smartling.com> References: <55832B86.7090209@redhat.com> <2382DE96-F5F5-4B98-98FC-ABC0FCC1DF73@smartling.com> Message-ID: <55832E60.9090909@redhat.com> We have a timeout between login actions. For example, you enter your username password, get redirected to OTP form, wait 5 minutes, then a timeout happens. You are currently booted out with an Error page. The ClientSession can still exist as it may not have been reaped by the reaper thread yet. On 6/18/2015 4:44 PM, Scott Rossillo wrote: > The current behavior is less than ideal and not a good user experience, but what happens if the session on client times out? It?s not going to be able to reconcile the state on redirect after login. Maybe the behavior should be configurable? Maybe I?m missing something. What do you mean by reset the ClientSession and start over from the beginning? Where is the beginning? > > ~ Scott > > >> On Jun 18, 2015, at 4:35 PM, Bill Burke wrote: >> >> Right now, if there is a timeout between actions when logging in, we >> show an error page. I think I'd rather we just reset the ClientSession >> and start over from the beginning. Might be a bit more user friendly. >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Fri Jun 19 03:47:10 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 19 Jun 2015 03:47:10 -0400 (EDT) Subject: [keycloak-dev] kerberos retry issue we talked about In-Reply-To: <55831DAE.7060800@redhat.com> References: <5582E99A.40609@redhat.com> <1198354491.21734087.1434649528141.JavaMail.zimbra@redhat.com> <55831DAE.7060800@redhat.com> Message-ID: <1623151965.22257770.1434700030739.JavaMail.zimbra@redhat.com> I guess we should just always go back to step 1 then. We could do this both for page refreshes and maybe even login timeouts? ----- Original Message ----- > From: "Bill Burke" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Thursday, 18 June, 2015 9:36:14 PM > Subject: Re: [keycloak-dev] kerberos retry issue we talked about > > > > On 6/18/2015 1:45 PM, Stian Thorgersen wrote: > > > > > > ----- Original Message ----- > >> From: "Bill Burke" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Thursday, 18 June, 2015 5:54:02 PM > >> Subject: [keycloak-dev] kerberos retry issue we talked about > >> > >> Hitting the cancel button works. Hitting the cancel button sends you > >> back to the app, which sends you back to keycloak and starts a new > >> client session. So that would work fine. > >> > >> What doesn't work is refreshing the page. Kerberos won't be attempted > >> again. Would it be ok that any browser page refresh might completely > >> reset the authentication flow and the user has to re login? If so, I > >> think I have a solution to the problem, but it would take quite a bit of > >> refactoring of the auth spi...Not another two months of work :) But > >> probably another few days or a week. > > > > As long as the user is actively refreshing the page that works, but I > > wonder if there's cases where it could break things. For example if > > there's high load on the system and some requests time out, then when user > > retries the request they end up in the beginning of the login flow again. > > > > Nothing would break, the user would just have to start over. If there > is only 1 login form, then this isn't an issue at all. > > BTW, OIDC has an issue with this too if the user hits a browser refresh > in the middle of the code_to_token exchange. Since the code can only be > exchanged once, the browser refresh will be a second request and fail. > SAML doesn't have this issue because there is no out of band callback to > the server. > > Honestly, I think it makes the algorithm much easier, simpler, and safer > if there is a complete client session reset on a page refresh. > > > Why could it not just continue the flow at the step it's on? Basically a > > challenge wouldn't count as moving on. So when password authenticator > > sends the challenge for the first request, you'd still be on stage 0 when > > the user refreshes the page. > > > > You're forgetting the original problem. We want Kerberos to be > re-attempted on a page refresh. The algorithm would have to know where > it had to go back and retry. Forms are contained in a nested flow. How > would you know when to hop back up to the parent flow and retry things? > It just gets real complicated. > > There's a few problems with browser page refresh: > > * On a page refresh, the exact request is resubmitted. This means a > POST sends a POST to the previous authenticator's URL action. > * You need to guard against an attacker trying to jump around in a flow. > * What about back button? > > Also, What I"m doing right now is to change the ClientSEssionCode every > form challenge. So, page refresh is actually completely broken now :( > Man, I need to rethink this. Actually even within the old code, refresh > page was broken when you went from authentication to the required action > page and then hit refresh. > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > From stian at redhat.com Fri Jun 19 03:47:57 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 19 Jun 2015 03:47:57 -0400 (EDT) Subject: [keycloak-dev] auth timeout behavior change In-Reply-To: <55832B86.7090209@redhat.com> References: <55832B86.7090209@redhat.com> Message-ID: <1738967500.22257952.1434700077090.JavaMail.zimbra@redhat.com> +1 Just replied the same in a separate email ;) ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Thursday, 18 June, 2015 10:35:18 PM > Subject: [keycloak-dev] auth timeout behavior change > > Right now, if there is a timeout between actions when logging in, we > show an error page. I think I'd rather we just reset the ClientSession > and start over from the beginning. Might be a bit more user friendly. > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From mposolda at redhat.com Fri Jun 19 04:40:35 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 19 Jun 2015 10:40:35 +0200 Subject: [keycloak-dev] Simplifying realm model In-Reply-To: <1473970272.21257323.1434636512872.JavaMail.zimbra@redhat.com> References: <1953167599.20857714.1434607467311.JavaMail.zimbra@redhat.com> <5582887E.4020406@redhat.com> <891520174.20983513.1434619184239.JavaMail.zimbra@redhat.com> <5582BDC8.3000805@redhat.com> <1473970272.21257323.1434636512872.JavaMail.zimbra@redhat.com> Message-ID: <5583D583.7020300@redhat.com> To me, it doesn't look like very big issue. IMO realm model is quite small and doesn't contain gazillion of objects like users or userSession models. Everything in realm model can be edited just by admin users and I think that many deployments have just very small number of admin users (if not just one). With respect to all of this, the probability of concurrent edit seems to be corner case. Hence I hope we can handle optimistic locking in one place in the code in model and maybe just throw an exception with message for the admin to retry it himself? I wouldn't do any retry logic directly in the code of all rest endpoints. The increased complexity of the code doesn't worth to handle the corner case IMO. Marek On 18.6.2015 16:08, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Thursday, 18 June, 2015 2:47:04 PM >> Subject: Re: [keycloak-dev] Simplifying realm model >> >> This would make things easier to store custom data too. It could be >> extended to places where custom data could be prevalent. For example, >> credential storage. >> >> But here are the disadvantages: >> >> * Do we have to worry about concurrency issues more though? All you >> need is 2 concurrent admins modifying different settings in the realm >> for one to overwrite the other. For example, one admin could be adding >> a role, another could be configuring an identity provider. Sure, these >> kind of concurrency issues exist now, but they are isolated because >> realm model data is in different tables. Minimally, you would need some >> kind of optimistic locking scheme that provided a non-cryptic error >> message when there were collisions. > Yep, that's one of the bigger issues. > > What I had in mind was to use optimistic locking and also make rest endpoints retry an operation before returning an error to the admin. > > For example adding an identity provider would still be a separate rest endpoint, so if it fails to add it to the realm due to an optimistic locking exception it can simply retry adding it. > >> * Admins would never be able to modify the database directly. > I don't think that's a problem - in theory they could as it would just be a json doc so they could get it, change it, write it ;) > >> On 6/18/2015 5:19 AM, Stian Thorgersen wrote: >>> >>> ----- Original Message ----- >>>> From: "Marek Posolda" >>>> To: "Stian Thorgersen" , "keycloak dev" >>>> >>>> Sent: Thursday, 18 June, 2015 10:59:42 AM >>>> Subject: Re: [keycloak-dev] Simplifying realm model >>>> >>>> +1 to go this way for realm model. For users+userSessions I would likely >>>> keep it in current form due to performance reasons, but for realm model >>>> I am not seeing any issue to store it in blob as realm model doesn't >>>> contain big amount of data. I am seeing just advantages and much simpler >>>> migration and DB maintenance, which is currently pain. >>> Yep, user model is much simpler in either case and isn't such a pain. We >>> could probably clean it up a bit, but would certainly keep a proper schema >>> for it with many tables and such. >>> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Fri Jun 19 04:56:08 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 19 Jun 2015 10:56:08 +0200 Subject: [keycloak-dev] kerberos retry issue we talked about In-Reply-To: <1623151965.22257770.1434700030739.JavaMail.zimbra@redhat.com> References: <5582E99A.40609@redhat.com> <1198354491.21734087.1434649528141.JavaMail.zimbra@redhat.com> <55831DAE.7060800@redhat.com> <1623151965.22257770.1434700030739.JavaMail.zimbra@redhat.com> Message-ID: <5583D928.4040706@redhat.com> I wonder if ClientSession should track the state of all authentication mechanisms? Then on refresh, you don't need to retry those, which were already successfully finished. Example: You want both password and TOTP authentication. After login with username/password on form1, user will see form2 with TOTP. When he do refresh at this stage, he won't be put into the password screen (form1) because ClientSession has already PASSWORD mechanism in state SUCCESS . But the mechanisms, which are not in SUCCESS but in ATTEMPTED state (Cookie, Kerberos, ...) will be tried again and then user is put directly into TOTP form (form2). Marek On 19.6.2015 09:47, Stian Thorgersen wrote: > I guess we should just always go back to step 1 then. We could do this both for page refreshes and maybe even login timeouts? > > ----- Original Message ----- >> From: "Bill Burke" >> To: "Stian Thorgersen" >> Cc: keycloak-dev at lists.jboss.org >> Sent: Thursday, 18 June, 2015 9:36:14 PM >> Subject: Re: [keycloak-dev] kerberos retry issue we talked about >> >> >> >> On 6/18/2015 1:45 PM, Stian Thorgersen wrote: >>> >>> ----- Original Message ----- >>>> From: "Bill Burke" >>>> To: keycloak-dev at lists.jboss.org >>>> Sent: Thursday, 18 June, 2015 5:54:02 PM >>>> Subject: [keycloak-dev] kerberos retry issue we talked about >>>> >>>> Hitting the cancel button works. Hitting the cancel button sends you >>>> back to the app, which sends you back to keycloak and starts a new >>>> client session. So that would work fine. >>>> >>>> What doesn't work is refreshing the page. Kerberos won't be attempted >>>> again. Would it be ok that any browser page refresh might completely >>>> reset the authentication flow and the user has to re login? If so, I >>>> think I have a solution to the problem, but it would take quite a bit of >>>> refactoring of the auth spi...Not another two months of work :) But >>>> probably another few days or a week. >>> As long as the user is actively refreshing the page that works, but I >>> wonder if there's cases where it could break things. For example if >>> there's high load on the system and some requests time out, then when user >>> retries the request they end up in the beginning of the login flow again. >>> >> Nothing would break, the user would just have to start over. If there >> is only 1 login form, then this isn't an issue at all. >> >> BTW, OIDC has an issue with this too if the user hits a browser refresh >> in the middle of the code_to_token exchange. Since the code can only be >> exchanged once, the browser refresh will be a second request and fail. >> SAML doesn't have this issue because there is no out of band callback to >> the server. >> >> Honestly, I think it makes the algorithm much easier, simpler, and safer >> if there is a complete client session reset on a page refresh. >> >>> Why could it not just continue the flow at the step it's on? Basically a >>> challenge wouldn't count as moving on. So when password authenticator >>> sends the challenge for the first request, you'd still be on stage 0 when >>> the user refreshes the page. >>> >> You're forgetting the original problem. We want Kerberos to be >> re-attempted on a page refresh. The algorithm would have to know where >> it had to go back and retry. Forms are contained in a nested flow. How >> would you know when to hop back up to the parent flow and retry things? >> It just gets real complicated. >> >> There's a few problems with browser page refresh: >> >> * On a page refresh, the exact request is resubmitted. This means a >> POST sends a POST to the previous authenticator's URL action. >> * You need to guard against an attacker trying to jump around in a flow. >> * What about back button? >> >> Also, What I"m doing right now is to change the ClientSEssionCode every >> form challenge. So, page refresh is actually completely broken now :( >> Man, I need to rethink this. Actually even within the old code, refresh >> page was broken when you went from authentication to the required action >> page and then hit refresh. >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Fri Jun 19 05:05:44 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 19 Jun 2015 05:05:44 -0400 (EDT) Subject: [keycloak-dev] Simplifying realm model In-Reply-To: <5583D583.7020300@redhat.com> References: <1953167599.20857714.1434607467311.JavaMail.zimbra@redhat.com> <5582887E.4020406@redhat.com> <891520174.20983513.1434619184239.JavaMail.zimbra@redhat.com> <5582BDC8.3000805@redhat.com> <1473970272.21257323.1434636512872.JavaMail.zimbra@redhat.com> <5583D583.7020300@redhat.com> Message-ID: <1719530352.22320641.1434704744268.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Marek Posolda" > To: "Stian Thorgersen" , "Bill Burke" > Cc: keycloak-dev at lists.jboss.org > Sent: Friday, 19 June, 2015 10:40:35 AM > Subject: Re: [keycloak-dev] Simplifying realm model > > To me, it doesn't look like very big issue. > > IMO realm model is quite small and doesn't contain gazillion of objects > like users or userSession models. Everything in realm model can be > edited just by admin users and I think that many deployments have just > very small number of admin users (if not just one). > > With respect to all of this, the probability of concurrent edit seems to > be corner case. Hence I hope we can handle optimistic locking in one > place in the code in model and maybe just throw an exception with > message for the admin to retry it himself? I wouldn't do any retry logic > directly in the code of all rest endpoints. The increased complexity of > the code doesn't worth to handle the corner case IMO. You're probably right. Thinking about it some more the way that the admin console works it's actually broken now anyways and changing it to what's proposed with an optimistic lock would be an improvement. Take the following scenario for instance: 1. Admin1 opens the realm login settings page 2. Admin2 opens the realm login settings page 3. Admin1 enables self-registration and saves it 4. Admin2 enables remember-me and saves it Both step 3 and step 4 submit the same realm representation. In step 4 the realm representation will have self-registration disabled and remember-me enabled. This will override the change made in step 3. Now the same scenario above if we had optimistic locking in place and had the version in the realm representation sent to the admin console we could at least give an error to admin2 instead of overriding changes done by admin1. That's an improvement IMO. > > Marek > > > On 18.6.2015 16:08, Stian Thorgersen wrote: > > > > ----- Original Message ----- > >> From: "Bill Burke" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Thursday, 18 June, 2015 2:47:04 PM > >> Subject: Re: [keycloak-dev] Simplifying realm model > >> > >> This would make things easier to store custom data too. It could be > >> extended to places where custom data could be prevalent. For example, > >> credential storage. > >> > >> But here are the disadvantages: > >> > >> * Do we have to worry about concurrency issues more though? All you > >> need is 2 concurrent admins modifying different settings in the realm > >> for one to overwrite the other. For example, one admin could be adding > >> a role, another could be configuring an identity provider. Sure, these > >> kind of concurrency issues exist now, but they are isolated because > >> realm model data is in different tables. Minimally, you would need some > >> kind of optimistic locking scheme that provided a non-cryptic error > >> message when there were collisions. > > Yep, that's one of the bigger issues. > > > > What I had in mind was to use optimistic locking and also make rest > > endpoints retry an operation before returning an error to the admin. > > > > For example adding an identity provider would still be a separate rest > > endpoint, so if it fails to add it to the realm due to an optimistic > > locking exception it can simply retry adding it. > > > >> * Admins would never be able to modify the database directly. > > I don't think that's a problem - in theory they could as it would just be a > > json doc so they could get it, change it, write it ;) > > > >> On 6/18/2015 5:19 AM, Stian Thorgersen wrote: > >>> > >>> ----- Original Message ----- > >>>> From: "Marek Posolda" > >>>> To: "Stian Thorgersen" , "keycloak dev" > >>>> > >>>> Sent: Thursday, 18 June, 2015 10:59:42 AM > >>>> Subject: Re: [keycloak-dev] Simplifying realm model > >>>> > >>>> +1 to go this way for realm model. For users+userSessions I would likely > >>>> keep it in current form due to performance reasons, but for realm model > >>>> I am not seeing any issue to store it in blob as realm model doesn't > >>>> contain big amount of data. I am seeing just advantages and much simpler > >>>> migration and DB maintenance, which is currently pain. > >>> Yep, user model is much simpler in either case and isn't such a pain. We > >>> could probably clean it up a bit, but would certainly keep a proper > >>> schema > >>> for it with many tables and such. > >>> > >> -- > >> Bill Burke > >> JBoss, a division of Red Hat > >> http://bill.burkecentral.com > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > From mposolda at redhat.com Fri Jun 19 05:34:55 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 19 Jun 2015 11:34:55 +0200 Subject: [keycloak-dev] Simplifying realm model In-Reply-To: <1719530352.22320641.1434704744268.JavaMail.zimbra@redhat.com> References: <1953167599.20857714.1434607467311.JavaMail.zimbra@redhat.com> <5582887E.4020406@redhat.com> <891520174.20983513.1434619184239.JavaMail.zimbra@redhat.com> <5582BDC8.3000805@redhat.com> <1473970272.21257323.1434636512872.JavaMail.zimbra@redhat.com> <5583D583.7020300@redhat.com> <1719530352.22320641.1434704744268.JavaMail.zimbra@redhat.com> Message-ID: <5583E23F.50201@redhat.com> On 19.6.2015 11:05, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Marek Posolda" >> To: "Stian Thorgersen" , "Bill Burke" >> Cc: keycloak-dev at lists.jboss.org >> Sent: Friday, 19 June, 2015 10:40:35 AM >> Subject: Re: [keycloak-dev] Simplifying realm model >> >> To me, it doesn't look like very big issue. >> >> IMO realm model is quite small and doesn't contain gazillion of objects >> like users or userSession models. Everything in realm model can be >> edited just by admin users and I think that many deployments have just >> very small number of admin users (if not just one). >> >> With respect to all of this, the probability of concurrent edit seems to >> be corner case. Hence I hope we can handle optimistic locking in one >> place in the code in model and maybe just throw an exception with >> message for the admin to retry it himself? I wouldn't do any retry logic >> directly in the code of all rest endpoints. The increased complexity of >> the code doesn't worth to handle the corner case IMO. > You're probably right. > > Thinking about it some more the way that the admin console works it's actually broken now anyways and changing it to what's proposed with an optimistic lock would be an improvement. > > Take the following scenario for instance: > > 1. Admin1 opens the realm login settings page > 2. Admin2 opens the realm login settings page > 3. Admin1 enables self-registration and saves it > 4. Admin2 enables remember-me and saves it > > Both step 3 and step 4 submit the same realm representation. In step 4 the realm representation will have self-registration disabled and remember-me enabled. This will override the change made in step 3. > > Now the same scenario above if we had optimistic locking in place and had the version in the realm representation sent to the admin console we could at least give an error to admin2 instead of overriding changes done by admin1. That's an improvement IMO. +1 Marek > >> Marek >> >> >> On 18.6.2015 16:08, Stian Thorgersen wrote: >>> ----- Original Message ----- >>>> From: "Bill Burke" >>>> To: keycloak-dev at lists.jboss.org >>>> Sent: Thursday, 18 June, 2015 2:47:04 PM >>>> Subject: Re: [keycloak-dev] Simplifying realm model >>>> >>>> This would make things easier to store custom data too. It could be >>>> extended to places where custom data could be prevalent. For example, >>>> credential storage. >>>> >>>> But here are the disadvantages: >>>> >>>> * Do we have to worry about concurrency issues more though? All you >>>> need is 2 concurrent admins modifying different settings in the realm >>>> for one to overwrite the other. For example, one admin could be adding >>>> a role, another could be configuring an identity provider. Sure, these >>>> kind of concurrency issues exist now, but they are isolated because >>>> realm model data is in different tables. Minimally, you would need some >>>> kind of optimistic locking scheme that provided a non-cryptic error >>>> message when there were collisions. >>> Yep, that's one of the bigger issues. >>> >>> What I had in mind was to use optimistic locking and also make rest >>> endpoints retry an operation before returning an error to the admin. >>> >>> For example adding an identity provider would still be a separate rest >>> endpoint, so if it fails to add it to the realm due to an optimistic >>> locking exception it can simply retry adding it. >>> >>>> * Admins would never be able to modify the database directly. >>> I don't think that's a problem - in theory they could as it would just be a >>> json doc so they could get it, change it, write it ;) >>> >>>> On 6/18/2015 5:19 AM, Stian Thorgersen wrote: >>>>> ----- Original Message ----- >>>>>> From: "Marek Posolda" >>>>>> To: "Stian Thorgersen" , "keycloak dev" >>>>>> >>>>>> Sent: Thursday, 18 June, 2015 10:59:42 AM >>>>>> Subject: Re: [keycloak-dev] Simplifying realm model >>>>>> >>>>>> +1 to go this way for realm model. For users+userSessions I would likely >>>>>> keep it in current form due to performance reasons, but for realm model >>>>>> I am not seeing any issue to store it in blob as realm model doesn't >>>>>> contain big amount of data. I am seeing just advantages and much simpler >>>>>> migration and DB maintenance, which is currently pain. >>>>> Yep, user model is much simpler in either case and isn't such a pain. We >>>>> could probably clean it up a bit, but would certainly keep a proper >>>>> schema >>>>> for it with many tables and such. >>>>> >>>> -- >>>> Bill Burke >>>> JBoss, a division of Red Hat >>>> http://bill.burkecentral.com >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From prabhalar at yahoo.com Fri Jun 19 05:37:19 2015 From: prabhalar at yahoo.com (Raghu Prabhala) Date: Fri, 19 Jun 2015 09:37:19 +0000 (UTC) Subject: [keycloak-dev] Simplifying realm model In-Reply-To: <5583D583.7020300@redhat.com> References: <5583D583.7020300@redhat.com> Message-ID: <141949930.1762790.1434706639047.JavaMail.yahoo@mail.yahoo.com> +1. Just give a heads-up to the Admin logging in that there are?other Admins already logged in and?making changes. ? From: Marek Posolda To: Stian Thorgersen ; Bill Burke Cc: keycloak-dev at lists.jboss.org Sent: Friday, June 19, 2015 4:40 AM Subject: Re: [keycloak-dev] Simplifying realm model To me, it doesn't look like very big issue. IMO realm model is quite small and doesn't contain gazillion of objects like users or userSession models. Everything in realm model can be edited just by admin users and I think that many deployments have just very small number of admin users (if not just one). With respect to all of this, the probability of concurrent edit seems to be corner case. Hence I hope we can handle optimistic locking in one place in the code in model and maybe just throw an exception with message for the admin to retry it himself? I wouldn't do any retry logic directly in the code of all rest endpoints. The increased complexity of the code doesn't worth to handle the corner case IMO. Marek On 18.6.2015 16:08, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Thursday, 18 June, 2015 2:47:04 PM >> Subject: Re: [keycloak-dev] Simplifying realm model >> >> This would make things easier to store custom data too.? It could be >> extended to places where custom data could be prevalent.? For example, >> credential storage. >> >> But here are the disadvantages: >> >> * Do we have to worry about concurrency issues more though?? All you >> need is 2 concurrent admins modifying different settings in the realm >> for one to overwrite the other.? For example, one admin could be adding >> a role, another could be configuring an identity provider.? Sure, these >> kind of concurrency issues exist now, but they are isolated because >> realm model data is in different tables.? Minimally, you would need some >> kind of optimistic locking scheme that provided a non-cryptic error >> message when there were collisions. > Yep, that's one of the bigger issues. > > What I had in mind was to use optimistic locking and also make rest endpoints retry an operation before returning an error to the admin. > > For example adding an identity provider would still be a separate rest endpoint, so if it fails to add it to the realm due to an optimistic locking exception it can simply retry adding it. > >> * Admins would never be able to modify the database directly. > I don't think that's a problem - in theory they could as it would just be a json doc so they could get it, change it, write it ;) > >> On 6/18/2015 5:19 AM, Stian Thorgersen wrote: >>> >>> ----- Original Message ----- >>>> From: "Marek Posolda" >>>> To: "Stian Thorgersen" , "keycloak dev" >>>> >>>> Sent: Thursday, 18 June, 2015 10:59:42 AM >>>> Subject: Re: [keycloak-dev] Simplifying realm model >>>> >>>> +1 to go this way for realm model. For users+userSessions I would likely >>>> keep it in current form due to performance reasons, but for realm model >>>> I am not seeing any issue to store it in blob as realm model doesn't >>>> contain big amount of data. I am seeing just advantages and much simpler >>>> migration and DB maintenance, which is currently pain. >>> Yep, user model is much simpler in either case and isn't such a pain. We >>> could probably clean it up a bit, but would certainly keep a proper schema >>> for it with many tables and such. >>> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150619/2d2aa7eb/attachment-0001.html From vainnkiitta at gmail.com Fri Jun 19 06:24:26 2015 From: vainnkiitta at gmail.com (John) Date: Fri, 19 Jun 2015 15:54:26 +0530 Subject: [keycloak-dev] Error while building Keycloak 1.3.1 sources. In-Reply-To: References: <1804904374.21258960.1434636594843.JavaMail.zimbra@redhat.com> Message-ID: Hi, After spending hours finally manged to get this working. There were two issue found. 1) For the first time run mvn install without skipping tests "-Dmaven.test.skip=true" Later on you may skip tests 2) To build distribution it needs maven version 3.3.3 else gives error java.lang.ClassNotFoundException: org.eclipse.aether.RepositorySystem Can we have documentation for building from sources. Thanks, John On Thu, Jun 18, 2015 at 8:03 PM, John wrote: > Using mvn install -Dmaven.test.skip=true > > My maven version > Apache Maven 3.0.5 > Maven home: /usr/share/maven > Java version: 1.7.0_79, vendor: Oracle Corporation > Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre > Default locale: en_IN, platform encoding: UTF-8 > OS name: "linux", version: "3.13.0-55-generic", arch: "amd64", family: > "unix" > > > > > On Thu, Jun 18, 2015 at 7:39 PM, Stian Thorgersen > wrote: > > What are the exact commands you're running? > > > > ----- Original Message ----- > >> From: "John" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Thursday, 18 June, 2015 3:47:13 PM > >> Subject: [keycloak-dev] Error while building Keycloak 1.3.1 sources. > >> > >> Hi All, > >> > >> I have downloaded source of keycloak 1.3.1 ver. > >> > >> I am doing mvn install but getting following error. > >> > >> [INFO] > >> ------------------------------------------------------------------------ > >> [INFO] BUILD FAILURE > >> [INFO] > >> ------------------------------------------------------------------------ > >> [INFO] Total time: 45.121s > >> [INFO] Finished at: Thu Jun 18 19:02:12 IST 2015 > >> [INFO] Final Memory: 215M/865M > >> [INFO] > >> ------------------------------------------------------------------------ > >> [ERROR] Failed to execute goal on project > >> keycloak-testsuite-security-proxy: Could not resolve dependencies for > >> project org.keycloak:keycloak-testsuite-security-proxy:jar:1.3.1.Final: > >> Could not find artifact > >> org.keycloak:keycloak-testsuite-integration:jar:tests:1.3.1.Final in > >> jboss-earlyaccess-repository > >> (http://maven.repository.redhat.com/earlyaccess/all/) -> [Help 1] > >> > >> Any help appreciated. > >> > >> Thanks, > >> John > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150619/1e1813ad/attachment.html From stian at redhat.com Fri Jun 19 06:38:03 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 19 Jun 2015 06:38:03 -0400 (EDT) Subject: [keycloak-dev] Error while building Keycloak 1.3.1 sources. In-Reply-To: References: <1804904374.21258960.1434636594843.JavaMail.zimbra@redhat.com> Message-ID: <1251522858.22434039.1434710283749.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "John" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Friday, 19 June, 2015 12:24:26 PM > Subject: Re: [keycloak-dev] Error while building Keycloak 1.3.1 sources. > > Hi, > > After spending hours finally manged to get this working. > There were two issue found. > > 1) For the first time run mvn install without skipping tests > "-Dmaven.test.skip=true" Later on you may skip tests That shouldn't be required - please create a jira and we'll fix it > > 2) To build distribution it needs maven version 3.3.3 else gives error > java.lang.ClassNotFoundException: org.eclipse.aether.RepositorySystem We have a hacking on Keycloak doc [1], but it doesn't specify required maven version. We do require 3.3.x+. Please create a jira and we'll update this as well. [1] https://github.com/keycloak/keycloak/blob/master/misc/HackingOnKeycloak.md Even better it would be great if you sent PRs for these issues as well as the JIRAs ;) > > Can we have documentation for building from sources. > > Thanks, > John > > > On Thu, Jun 18, 2015 at 8:03 PM, John wrote: > > > Using mvn install -Dmaven.test.skip=true > > > > My maven version > > Apache Maven 3.0.5 > > Maven home: /usr/share/maven > > Java version: 1.7.0_79, vendor: Oracle Corporation > > Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre > > Default locale: en_IN, platform encoding: UTF-8 > > OS name: "linux", version: "3.13.0-55-generic", arch: "amd64", family: > > "unix" > > > > > > > > > > On Thu, Jun 18, 2015 at 7:39 PM, Stian Thorgersen > > wrote: > > > What are the exact commands you're running? > > > > > > ----- Original Message ----- > > >> From: "John" > > >> To: keycloak-dev at lists.jboss.org > > >> Sent: Thursday, 18 June, 2015 3:47:13 PM > > >> Subject: [keycloak-dev] Error while building Keycloak 1.3.1 sources. > > >> > > >> Hi All, > > >> > > >> I have downloaded source of keycloak 1.3.1 ver. > > >> > > >> I am doing mvn install but getting following error. > > >> > > >> [INFO] > > >> ------------------------------------------------------------------------ > > >> [INFO] BUILD FAILURE > > >> [INFO] > > >> ------------------------------------------------------------------------ > > >> [INFO] Total time: 45.121s > > >> [INFO] Finished at: Thu Jun 18 19:02:12 IST 2015 > > >> [INFO] Final Memory: 215M/865M > > >> [INFO] > > >> ------------------------------------------------------------------------ > > >> [ERROR] Failed to execute goal on project > > >> keycloak-testsuite-security-proxy: Could not resolve dependencies for > > >> project org.keycloak:keycloak-testsuite-security-proxy:jar:1.3.1.Final: > > >> Could not find artifact > > >> org.keycloak:keycloak-testsuite-integration:jar:tests:1.3.1.Final in > > >> jboss-earlyaccess-repository > > >> (http://maven.repository.redhat.com/earlyaccess/all/) -> [Help 1] > > >> > > >> Any help appreciated. > > >> > > >> Thanks, > > >> John > > >> _______________________________________________ > > >> keycloak-dev mailing list > > >> keycloak-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > >> > > > From mposolda at redhat.com Fri Jun 19 07:17:20 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 19 Jun 2015 13:17:20 +0200 Subject: [keycloak-dev] Error while building Keycloak 1.3.1 sources. In-Reply-To: <1251522858.22434039.1434710283749.JavaMail.zimbra@redhat.com> References: <1804904374.21258960.1434636594843.JavaMail.zimbra@redhat.com> <1251522858.22434039.1434710283749.JavaMail.zimbra@redhat.com> Message-ID: <5583FA40.1030509@redhat.com> Will it help if you use: mvn clean install -DskipTests=true instead of "maven.test.skip" ? AFAIK the "skipTests" won't run the tests, but it will still build all test dependencies, so it should be fine. At least I am using it quite often and not seeing issues. When "maven.test.skip" won't run the tests and won't build dependencies, which I understand that doesn't work as various modules have dependency on "keycloak-testsuite-integration" , which contains all the base test classes used in tests of other modules. Marek On 19.6.2015 12:38, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "John" >> To: "Stian Thorgersen" >> Cc: keycloak-dev at lists.jboss.org >> Sent: Friday, 19 June, 2015 12:24:26 PM >> Subject: Re: [keycloak-dev] Error while building Keycloak 1.3.1 sources. >> >> Hi, >> >> After spending hours finally manged to get this working. >> There were two issue found. >> >> 1) For the first time run mvn install without skipping tests >> "-Dmaven.test.skip=true" Later on you may skip tests > That shouldn't be required - please create a jira and we'll fix it > >> 2) To build distribution it needs maven version 3.3.3 else gives error >> java.lang.ClassNotFoundException: org.eclipse.aether.RepositorySystem > We have a hacking on Keycloak doc [1], but it doesn't specify required maven version. We do require 3.3.x+. Please create a jira and we'll update this as well. > > [1] https://github.com/keycloak/keycloak/blob/master/misc/HackingOnKeycloak.md > > > Even better it would be great if you sent PRs for these issues as well as the JIRAs ;) > >> Can we have documentation for building from sources. >> >> Thanks, >> John >> >> >> On Thu, Jun 18, 2015 at 8:03 PM, John wrote: >> >>> Using mvn install -Dmaven.test.skip=true >>> >>> My maven version >>> Apache Maven 3.0.5 >>> Maven home: /usr/share/maven >>> Java version: 1.7.0_79, vendor: Oracle Corporation >>> Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre >>> Default locale: en_IN, platform encoding: UTF-8 >>> OS name: "linux", version: "3.13.0-55-generic", arch: "amd64", family: >>> "unix" >>> >>> >>> >>> >>> On Thu, Jun 18, 2015 at 7:39 PM, Stian Thorgersen >>> wrote: >>>> What are the exact commands you're running? >>>> >>>> ----- Original Message ----- >>>>> From: "John" >>>>> To: keycloak-dev at lists.jboss.org >>>>> Sent: Thursday, 18 June, 2015 3:47:13 PM >>>>> Subject: [keycloak-dev] Error while building Keycloak 1.3.1 sources. >>>>> >>>>> Hi All, >>>>> >>>>> I have downloaded source of keycloak 1.3.1 ver. >>>>> >>>>> I am doing mvn install but getting following error. >>>>> >>>>> [INFO] >>>>> ------------------------------------------------------------------------ >>>>> [INFO] BUILD FAILURE >>>>> [INFO] >>>>> ------------------------------------------------------------------------ >>>>> [INFO] Total time: 45.121s >>>>> [INFO] Finished at: Thu Jun 18 19:02:12 IST 2015 >>>>> [INFO] Final Memory: 215M/865Mhttps://github.com/keycloak/keycloak/tree/master/examples/js-console >>>>> [INFO] >>>>> ------------------------------------------------------------------------ >>>>> [ERROR] Failed to execute goal on project >>>>> keycloak-testsuite-security-proxy: Could not resolve dependencies for >>>>> project org.keycloak:keycloak-testsuite-security-proxy:jar:1.3.1.Final: >>>>> Could not find artifact >>>>> org.keycloak:keycloak-testsuite-integration:jar:tests:1.3.1.Final in >>>>> jboss-earlyaccess-repository >>>>> (http://maven.repository.redhat.com/earlyaccess/all/) -> [Help 1] >>>>> >>>>> Any help appreciated. >>>>> >>>>> Thanks, >>>>> John >>>>> _______________________________________________ >>>>> 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 vainnkiitta at gmail.com Fri Jun 19 07:49:54 2015 From: vainnkiitta at gmail.com (John) Date: Fri, 19 Jun 2015 17:19:54 +0530 Subject: [keycloak-dev] Error while building Keycloak 1.3.1 sources. In-Reply-To: <5583FA40.1030509@redhat.com> References: <1804904374.21258960.1434636594843.JavaMail.zimbra@redhat.com> <1251522858.22434039.1434710283749.JavaMail.zimbra@redhat.com> <5583FA40.1030509@redhat.com> Message-ID: Hi Marek, Even I am used to build with mvn clean install -DskipTests=true but this issue happen only for first time build after extracting sources tarball and empty .m2/repository. Once it is built successfully with mvn install*,* after that I can build with mvn clean install -DskipTests=true every next time. For maven version surely I will create JIRA as this should mentioned somewhere because Ubuntu14.04 LTS has very old version of maven in repo than mvn_3.3.x Thanks for response and happy to see LDAP mappers John On Fri, Jun 19, 2015 at 4:47 PM, Marek Posolda wrote: > Will it help if you use: > mvn clean install -DskipTests=true > > instead of "maven.test.skip" ? > > AFAIK the "skipTests" won't run the tests, but it will still build all > test dependencies, so it should be fine. At least I am using it quite often > and not seeing issues. > > When "maven.test.skip" won't run the tests and won't build dependencies, > which I understand that doesn't work as various modules have dependency on > "keycloak-testsuite-integration" , which contains all the base test classes > used in tests of other modules. > > Marek > > > On 19.6.2015 12:38, Stian Thorgersen wrote: > >> >> ----- Original Message ----- >> >>> From: "John" >>> To: "Stian Thorgersen" >>> Cc: keycloak-dev at lists.jboss.org >>> Sent: Friday, 19 June, 2015 12:24:26 PM >>> Subject: Re: [keycloak-dev] Error while building Keycloak 1.3.1 sources. >>> >>> Hi, >>> >>> After spending hours finally manged to get this working. >>> There were two issue found. >>> >>> 1) For the first time run mvn install without skipping tests >>> "-Dmaven.test.skip=true" Later on you may skip tests >>> >> That shouldn't be required - please create a jira and we'll fix it >> >> 2) To build distribution it needs maven version 3.3.3 else gives error >>> java.lang.ClassNotFoundException: org.eclipse.aether.RepositorySystem >>> >> We have a hacking on Keycloak doc [1], but it doesn't specify required >> maven version. We do require 3.3.x+. Please create a jira and we'll update >> this as well. >> >> [1] >> https://github.com/keycloak/keycloak/blob/master/misc/HackingOnKeycloak.md >> >> >> Even better it would be great if you sent PRs for these issues as well as >> the JIRAs ;) >> >> Can we have documentation for building from sources. >>> >>> Thanks, >>> John >>> >>> >>> On Thu, Jun 18, 2015 at 8:03 PM, John wrote: >>> >>> Using mvn install -Dmaven.test.skip=true >>>> >>>> My maven version >>>> Apache Maven 3.0.5 >>>> Maven home: /usr/share/maven >>>> Java version: 1.7.0_79, vendor: Oracle Corporation >>>> Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre >>>> Default locale: en_IN, platform encoding: UTF-8 >>>> OS name: "linux", version: "3.13.0-55-generic", arch: "amd64", family: >>>> "unix" >>>> >>>> >>>> >>>> >>>> On Thu, Jun 18, 2015 at 7:39 PM, Stian Thorgersen >>>> wrote: >>>> >>>>> What are the exact commands you're running? >>>>> >>>>> ----- Original Message ----- >>>>> >>>>>> From: "John" >>>>>> To: keycloak-dev at lists.jboss.org >>>>>> Sent: Thursday, 18 June, 2015 3:47:13 PM >>>>>> Subject: [keycloak-dev] Error while building Keycloak 1.3.1 sources. >>>>>> >>>>>> Hi All, >>>>>> >>>>>> I have downloaded source of keycloak 1.3.1 ver. >>>>>> >>>>>> I am doing mvn install but getting following error. >>>>>> >>>>>> [INFO] >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> [INFO] BUILD FAILURE >>>>>> [INFO] >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> [INFO] Total time: 45.121s >>>>>> [INFO] Finished at: Thu Jun 18 19:02:12 IST 2015 >>>>>> [INFO] Final Memory: 215M/865Mhttps:// >>>>>> github.com/keycloak/keycloak/tree/master/examples/js-console >>>>>> [INFO] >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> [ERROR] Failed to execute goal on project >>>>>> keycloak-testsuite-security-proxy: Could not resolve dependencies for >>>>>> project >>>>>> org.keycloak:keycloak-testsuite-security-proxy:jar:1.3.1.Final: >>>>>> Could not find artifact >>>>>> org.keycloak:keycloak-testsuite-integration:jar:tests:1.3.1.Final in >>>>>> jboss-earlyaccess-repository >>>>>> (http://maven.repository.redhat.com/earlyaccess/all/) -> [Help 1] >>>>>> >>>>>> Any help appreciated. >>>>>> >>>>>> Thanks, >>>>>> John >>>>>> _______________________________________________ >>>>>> 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150619/811ee694/attachment-0001.html From ssilvert at redhat.com Fri Jun 19 07:58:37 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 19 Jun 2015 07:58:37 -0400 Subject: [keycloak-dev] Error while building Keycloak 1.3.1 sources. In-Reply-To: References: <1804904374.21258960.1434636594843.JavaMail.zimbra@redhat.com> Message-ID: <558403ED.1070309@redhat.com> On 6/19/2015 6:24 AM, John wrote: > Hi, > > After spending hours finally manged to get this working. > There were two issue found. > > 1) For the first time run mvn install without skipping tests > "-Dmaven.test.skip=true" Later on you may skip tests > > 2) To build distribution it needs maven version 3.3.3 else gives error > java.lang.ClassNotFoundException: org.eclipse.aether.RepositorySystem > > Can we have documentation for building from sources. Or use the Enforcer plugin to mandate proper Maven version. > > Thanks, > John > > > On Thu, Jun 18, 2015 at 8:03 PM, John > wrote: > > Using mvn install -Dmaven.test.skip=true > > My maven version > Apache Maven 3.0.5 > Maven home: /usr/share/maven > Java version: 1.7.0_79, vendor: Oracle Corporation > Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre > Default locale: en_IN, platform encoding: UTF-8 > OS name: "linux", version: "3.13.0-55-generic", arch: "amd64", > family: "unix" > > > > > On Thu, Jun 18, 2015 at 7:39 PM, Stian Thorgersen > > wrote: > > What are the exact commands you're running? > > > > ----- Original Message ----- > >> From: "John" > > >> To: keycloak-dev at lists.jboss.org > > >> Sent: Thursday, 18 June, 2015 3:47:13 PM > >> Subject: [keycloak-dev] Error while building Keycloak 1.3.1 > sources. > >> > >> Hi All, > >> > >> I have downloaded source of keycloak 1.3.1 ver. > >> > >> I am doing mvn install but getting following error. > >> > >> [INFO] > >> > ------------------------------------------------------------------------ > >> [INFO] BUILD FAILURE > >> [INFO] > >> > ------------------------------------------------------------------------ > >> [INFO] Total time: 45.121s > >> [INFO] Finished at: Thu Jun 18 19:02:12 IST 2015 > >> [INFO] Final Memory: 215M/865M > >> [INFO] > >> > ------------------------------------------------------------------------ > >> [ERROR] Failed to execute goal on project > >> keycloak-testsuite-security-proxy: Could not resolve > dependencies for > >> project > org.keycloak:keycloak-testsuite-security-proxy:jar:1.3.1.Final: > >> Could not find artifact > >> > org.keycloak:keycloak-testsuite-integration:jar:tests:1.3.1.Final in > >> jboss-earlyaccess-repository > >> (http://maven.repository.redhat.com/earlyaccess/all/) -> [Help 1] > >> > >> Any help appreciated. > >> > >> Thanks, > >> John > >> _______________________________________________ > >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150619/cba2e2d3/attachment.html From ssilvert at redhat.com Fri Jun 19 08:15:10 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 19 Jun 2015 08:15:10 -0400 Subject: [keycloak-dev] Auth SPI is awesome! In-Reply-To: <332514902.21242153.1434636057924.JavaMail.zimbra@redhat.com> References: <332514902.21242153.1434636057924.JavaMail.zimbra@redhat.com> Message-ID: <558407CE.5000001@redhat.com> Was the call recorded? I'd like to watch. On 6/18/2015 10:00 AM, Stian Thorgersen wrote: > Bill, > > Didn't get a chance to say this on the call, but I reckon the new SPI is awesome :) > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Fri Jun 19 08:57:26 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 19 Jun 2015 08:57:26 -0400 Subject: [keycloak-dev] Error while building Keycloak 1.3.1 sources. In-Reply-To: <1251522858.22434039.1434710283749.JavaMail.zimbra@redhat.com> References: <1804904374.21258960.1434636594843.JavaMail.zimbra@redhat.com> <1251522858.22434039.1434710283749.JavaMail.zimbra@redhat.com> Message-ID: <558411B6.8060404@redhat.com> We require Maven 3.3.x? Still works for me with mvn 3.1.1 :) -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From mposolda at redhat.com Fri Jun 19 09:03:46 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 19 Jun 2015 15:03:46 +0200 Subject: [keycloak-dev] Error while building Keycloak 1.3.1 sources. In-Reply-To: <558411B6.8060404@redhat.com> References: <1804904374.21258960.1434636594843.JavaMail.zimbra@redhat.com> <1251522858.22434039.1434710283749.JavaMail.zimbra@redhat.com> <558411B6.8060404@redhat.com> Message-ID: <55841332.6090300@redhat.com> Same here, I have 3.1.1 as well :-) But maybe 3.0.5 is too old (the one which John originally used) Marek On 19.6.2015 14:57, Bill Burke wrote: > We require Maven 3.3.x? Still works for me with mvn 3.1.1 :) > From bburke at redhat.com Fri Jun 19 09:13:51 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 19 Jun 2015 09:13:51 -0400 Subject: [keycloak-dev] Simplifying realm model In-Reply-To: <1719530352.22320641.1434704744268.JavaMail.zimbra@redhat.com> References: <1953167599.20857714.1434607467311.JavaMail.zimbra@redhat.com> <5582887E.4020406@redhat.com> <891520174.20983513.1434619184239.JavaMail.zimbra@redhat.com> <5582BDC8.3000805@redhat.com> <1473970272.21257323.1434636512872.JavaMail.zimbra@redhat.com> <5583D583.7020300@redhat.com> <1719530352.22320641.1434704744268.JavaMail.zimbra@redhat.com> Message-ID: <5584158F.6060905@redhat.com> On 6/19/2015 5:05 AM, Stian Thorgersen wrote: > > > ----- Original Message ----- >> From: "Marek Posolda" >> To: "Stian Thorgersen" , "Bill Burke" >> Cc: keycloak-dev at lists.jboss.org >> Sent: Friday, 19 June, 2015 10:40:35 AM >> Subject: Re: [keycloak-dev] Simplifying realm model >> >> To me, it doesn't look like very big issue. >> >> IMO realm model is quite small and doesn't contain gazillion of objects >> like users or userSession models. Everything in realm model can be >> edited just by admin users and I think that many deployments have just >> very small number of admin users (if not just one). >> >> With respect to all of this, the probability of concurrent edit seems to >> be corner case. Hence I hope we can handle optimistic locking in one >> place in the code in model and maybe just throw an exception with >> message for the admin to retry it himself? I wouldn't do any retry logic >> directly in the code of all rest endpoints. The increased complexity of >> the code doesn't worth to handle the corner case IMO. > > You're probably right. > > Thinking about it some more the way that the admin console works it's actually broken now anyways and changing it to what's proposed with an optimistic lock would be an improvement. > > Take the following scenario for instance: > > 1. Admin1 opens the realm login settings page > 2. Admin2 opens the realm login settings page > 3. Admin1 enables self-registration and saves it > 4. Admin2 enables remember-me and saves it > > Both step 3 and step 4 submit the same realm representation. In step 4 the realm representation will have self-registration disabled and remember-me enabled. This will override the change made in step 3. > > Now the same scenario above if we had optimistic locking in place and had the version in the realm representation sent to the admin console we could at least give an error to admin2 instead of overriding changes done by admin1. That's an improvement IMO. > Lol that we already have this problem... :) If we do this approach, we'll have to add a version property to all json docs. the admin REST api has gotten quite large.... -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Fri Jun 19 09:15:24 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 19 Jun 2015 09:15:24 -0400 Subject: [keycloak-dev] kerberos retry issue we talked about In-Reply-To: <5583D928.4040706@redhat.com> References: <5582E99A.40609@redhat.com> <1198354491.21734087.1434649528141.JavaMail.zimbra@redhat.com> <55831DAE.7060800@redhat.com> <1623151965.22257770.1434700030739.JavaMail.zimbra@redhat.com> <5583D928.4040706@redhat.com> Message-ID: <558415EC.3030402@redhat.com> On 6/19/2015 4:56 AM, Marek Posolda wrote: > I wonder if ClientSession should track the state of all authentication > mechanisms? Then on refresh, you don't need to retry those, which were > already successfully finished. > > Example: You want both password and TOTP authentication. After login > with username/password on form1, user will see form2 with TOTP. When he > do refresh at this stage, he won't be put into the password screen > (form1) because ClientSession has already PASSWORD mechanism in state > SUCCESS . But the mechanisms, which are not in SUCCESS but in ATTEMPTED > state (Cookie, Kerberos, ...) will be tried again and then user is put > directly into TOTP form (form2). > The problem is what if after page refresh, a different user is logged in with Kerberos than what you logged in with password? You'd have to know exactly how to clean up the ClientSession to get to a valid state. Also we may have Authenticators where retrying ATTEMPTED might be a bad thing. Doing this makes me nervous as this makes the algorithm more complex and I think that we'll miss something and get something wrong in the algorithm. For example, you would have to make sure that for ALTERNATIVES, you don't re-attempt them if an ALTERNATIVE later in the flow wasn't successful. I'm worried there are other cases like that or that an Authenticator would have to have knowledge about the flow and code for it. Let me explain how page refresh is detected. The "action url" of a login form is /authenticate?code={code}&execution={execution}. When the login form sends a challenge it sets the "current execution" of the ClientSession. It also specifies the "execution" query parameter in the action URL. If the "execution" query param matches the "current execution", then the action is processed by the Authenticator, and the Flow continues where it left off. If the "execution" param doesn't match, then there was probably a page refresh or somebody hit a back button or an attacker is trying to bypass the flow. There are two options which I can easily implement for page refresh: a) A page refresh resets the client session b) A page refresh reiterates on the flow, skipping any authenticators already processed. It would *NOT* re-attempt ATTEMPTED authenticators. For a) Kerberos would be retried, but you would have to log in from the beginning. For b) Kerberos would not be retried, but you could continue where you left off. IMO, I would prefer b) because there is already a "cancel" button on the login form which can reset the flow. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From mposolda at redhat.com Fri Jun 19 10:08:07 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 19 Jun 2015 16:08:07 +0200 Subject: [keycloak-dev] kerberos retry issue we talked about In-Reply-To: <558415EC.3030402@redhat.com> References: <5582E99A.40609@redhat.com> <1198354491.21734087.1434649528141.JavaMail.zimbra@redhat.com> <55831DAE.7060800@redhat.com> <1623151965.22257770.1434700030739.JavaMail.zimbra@redhat.com> <5583D928.4040706@redhat.com> <558415EC.3030402@redhat.com> Message-ID: <55842247.9010906@redhat.com> Fact is that for production environment using Kerberos (FreeIPA or Windows domain backed by ActiveDirectory) the kerberos ticket is usually tight to the desktop login of user and user either has it or not. The flow with "display the form, then kinit from CMD to obtain kerberos ticket and then refresh the page to retry kerberos" is probably something more for development use. From the possibilities, the (a) seems to me slightly better? For example if you accidentally have 2 opened tabs with the login form in the browser and you login successfully in tab1, you will have SSO cookie, so refresh on tab2 should retry the cookie and logged you successfully. In case (b) it won't logged you because cookie won't be retried. But not sure if this is not corner case as well ;-) Marek On 19.6.2015 15:15, Bill Burke wrote: > On 6/19/2015 4:56 AM, Marek Posolda wrote: >> I wonder if ClientSession should track the state of all authentication >> mechanisms? Then on refresh, you don't need to retry those, which were >> already successfully finished. >> >> Example: You want both password and TOTP authentication. After login >> with username/password on form1, user will see form2 with TOTP. When he >> do refresh at this stage, he won't be put into the password screen >> (form1) because ClientSession has already PASSWORD mechanism in state >> SUCCESS . But the mechanisms, which are not in SUCCESS but in ATTEMPTED >> state (Cookie, Kerberos, ...) will be tried again and then user is put >> directly into TOTP form (form2). >> > > The problem is what if after page refresh, a different user is logged > in with Kerberos than what you logged in with password? You'd have to > know exactly how to clean up the ClientSession to get to a valid > state. Also we may have Authenticators where retrying ATTEMPTED might > be a bad thing. Doing this makes me nervous as this makes the > algorithm more complex and I think that we'll miss something and get > something wrong in the algorithm. For example, you would have to make > sure that for ALTERNATIVES, you don't re-attempt them if an > ALTERNATIVE later in the flow wasn't successful. I'm worried there > are other cases like that or that an Authenticator would have to have > knowledge about the flow and code for it. > > > Let me explain how page refresh is detected. The "action url" of a > login form is /authenticate?code={code}&execution={execution}. When > the login form sends a challenge it sets the "current execution" of > the ClientSession. It also specifies the "execution" query parameter > in the action URL. If the "execution" query param matches the > "current execution", then the action is processed by the > Authenticator, and the Flow continues where it left off. If the > "execution" param doesn't match, then there was probably a page > refresh or somebody hit a back button or an attacker is trying to > bypass the flow. > > There are two options which I can easily implement for page refresh: > > a) A page refresh resets the client session > b) A page refresh reiterates on the flow, skipping any authenticators > already processed. It would *NOT* re-attempt ATTEMPTED authenticators. > > For a) Kerberos would be retried, but you would have to log in from > the beginning. For b) Kerberos would not be retried, but you could > continue where you left off. IMO, I would prefer b) because there is > already a "cancel" button on the login form which can reset the flow. > > > From bburke at redhat.com Fri Jun 19 10:40:56 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 19 Jun 2015 10:40:56 -0400 Subject: [keycloak-dev] kerberos retry issue we talked about In-Reply-To: <55842247.9010906@redhat.com> References: <5582E99A.40609@redhat.com> <1198354491.21734087.1434649528141.JavaMail.zimbra@redhat.com> <55831DAE.7060800@redhat.com> <1623151965.22257770.1434700030739.JavaMail.zimbra@redhat.com> <5583D928.4040706@redhat.com> <558415EC.3030402@redhat.com> <55842247.9010906@redhat.com> Message-ID: <558429F8.3020304@redhat.com> On 6/19/2015 10:08 AM, Marek Posolda wrote: > Fact is that for production environment using Kerberos (FreeIPA or > Windows domain backed by ActiveDirectory) the kerberos ticket is usually > tight to the desktop login of user and user either has it or not. The > flow with "display the form, then kinit from CMD to obtain kerberos > ticket and then refresh the page to retry kerberos" is probably > something more for development use. > > From the possibilities, the (a) seems to me slightly better? For > example if you accidentally have 2 opened tabs with the login form in > the browser and you login successfully in tab1, you will have SSO > cookie, so refresh on tab2 should retry the cookie and logged you > successfully. In case (b) it won't logged you because cookie won't be > retried. But not sure if this is not corner case as well ;-) > Ok, we'll reset the client session on a refresh. Its already set up that way in master. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From ssilvert at redhat.com Fri Jun 19 18:19:46 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 19 Jun 2015 18:19:46 -0400 Subject: [keycloak-dev] Error while building Keycloak 1.3.1 sources. In-Reply-To: <558403ED.1070309@redhat.com> References: <1804904374.21258960.1434636594843.JavaMail.zimbra@redhat.com> <558403ED.1070309@redhat.com> Message-ID: <55849582.6020605@redhat.com> On 6/19/2015 7:58 AM, Stan Silvert wrote: > On 6/19/2015 6:24 AM, John wrote: >> Hi, >> >> After spending hours finally manged to get this working. >> There were two issue found. >> >> 1) For the first time run mvn install without skipping tests >> "-Dmaven.test.skip=true" Later on you may skip tests >> >> 2) To build distribution it needs maven version 3.3.3 else gives error >> java.lang.ClassNotFoundException: org.eclipse.aether.RepositorySystem >> >> Can we have documentation for building from sources. > Or use the Enforcer plugin to mandate proper Maven version. This will ensure nobody runs into that problem again: https://github.com/keycloak/keycloak/pull/1407 >> >> Thanks, >> John >> >> >> On Thu, Jun 18, 2015 at 8:03 PM, John > > wrote: >> >> Using mvn install -Dmaven.test.skip=true >> >> My maven version >> Apache Maven 3.0.5 >> Maven home: /usr/share/maven >> Java version: 1.7.0_79, vendor: Oracle Corporation >> Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre >> Default locale: en_IN, platform encoding: UTF-8 >> OS name: "linux", version: "3.13.0-55-generic", arch: "amd64", >> family: "unix" >> >> >> >> >> On Thu, Jun 18, 2015 at 7:39 PM, Stian Thorgersen >> > wrote: >> > What are the exact commands you're running? >> > >> > ----- Original Message ----- >> >> From: "John" > > >> >> To: keycloak-dev at lists.jboss.org >> >> >> Sent: Thursday, 18 June, 2015 3:47:13 PM >> >> Subject: [keycloak-dev] Error while building Keycloak 1.3.1 >> sources. >> >> >> >> Hi All, >> >> >> >> I have downloaded source of keycloak 1.3.1 ver. >> >> >> >> I am doing mvn install but getting following error. >> >> >> >> [INFO] >> >> >> ------------------------------------------------------------------------ >> >> [INFO] BUILD FAILURE >> >> [INFO] >> >> >> ------------------------------------------------------------------------ >> >> [INFO] Total time: 45.121s >> >> [INFO] Finished at: Thu Jun 18 19:02:12 IST 2015 >> >> [INFO] Final Memory: 215M/865M >> >> [INFO] >> >> >> ------------------------------------------------------------------------ >> >> [ERROR] Failed to execute goal on project >> >> keycloak-testsuite-security-proxy: Could not resolve >> dependencies for >> >> project >> org.keycloak:keycloak-testsuite-security-proxy:jar:1.3.1.Final: >> >> Could not find artifact >> >> >> org.keycloak:keycloak-testsuite-integration:jar:tests:1.3.1.Final in >> >> jboss-earlyaccess-repository >> >> (http://maven.repository.redhat.com/earlyaccess/all/) -> [Help 1] >> >> >> >> Any help appreciated. >> >> >> >> Thanks, >> >> John >> >> _______________________________________________ >> >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150619/20c33450/attachment.html From giriraj.sharma27 at gmail.com Sun Jun 21 15:47:18 2015 From: giriraj.sharma27 at gmail.com (Giriraj Sharma) Date: Mon, 22 Jun 2015 01:17:18 +0530 Subject: [keycloak-dev] Let's Encrypt (Enabling SSL over keycloak) Launch Schedule Message-ID: Let?s Encrypt has reached a point where they are ready to announce their launch schedule. - First certificate: Week of July 27, 2015 - General availability: Week of September 14, 2015 https://letsencrypt.org/2015/06/16/lets-encrypt-launch-schedule.html -- Giriraj Sharma about.me/girirajsharma Giriraj Sharma, Department of Computer Science National Institute of Technology Hamirpur Himachal Pradesh, India 177005 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150622/06f854ab/attachment.html From velias at redhat.com Mon Jun 22 03:03:46 2015 From: velias at redhat.com (Vlastimil Elias) Date: Mon, 22 Jun 2015 09:03:46 +0200 Subject: [keycloak-dev] auth timeout behavior change In-Reply-To: <55832B86.7090209@redhat.com> References: <55832B86.7090209@redhat.com> Message-ID: <5587B352.8050409@redhat.com> +1, we hit this problem on our site, users are not happy seeing the error page, we had to customize it to give them some meaningful flow. Some info message should be shown to the user to inform him that timeout occurred not to be too surprised what is going on. Vl. On 18.6.2015 22:35, Bill Burke wrote: > Right now, if there is a timeout between actions when logging in, we > show an error page. I think I'd rather we just reset the ClientSession > and start over from the beginning. Might be a bit more user friendly. > -- Vlastimil Elias Principal Software Engineer jboss.org Development Team From mposolda at redhat.com Mon Jun 22 09:14:36 2015 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 22 Jun 2015 15:14:36 +0200 Subject: [keycloak-dev] Handle multivalued LDAP attributes on UserModel Message-ID: <55880A3C.9060803@redhat.com> LDAP allows to have multiple values of same attribute per single user. There is usecase to map all the values of some LDAP attribute to UserModel and then also to access token of particular user. For example, user has LDAP attribute "applications" with 2 values "sales" and "finance". Then in application there is code like this: List values = accessToken.getOtherClaims().get("applications"); which should then return 2 values "sales" and "finance" . The main issue here is mapping of multiple LDAP attributes to the UserModel, because "attributes" on UserModel currently support single String value per attribute. I can see 2 possibilities to address this: 1) Change "attributes" map on UserModel to be MultivaluedMap and support multiple String values per single key. This may require some migration, however for JPA it can be easy. We just need to support multiple values per single key and user in USER_ATTRIBUTES table (This breaks some normal form, but looks better to me than introducing another table like USER_ATTRIBUTE_VALUES as this will require migration changes again) 2) Use some delimiter for UserModel attribute value. So in previous example, the value of attribute "applications" on the user will be "sales###finance" (assuming that ### is delimiter). Then there will be protocol mapper, which will be able to parse delimiter and create again 2 values "sales" and "finance" to be used in access token. I am slightly for using (1) . What do you think? Any better ideas? Thanks, Marek From bburke at redhat.com Mon Jun 22 09:26:40 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 22 Jun 2015 09:26:40 -0400 Subject: [keycloak-dev] Handle multivalued LDAP attributes on UserModel In-Reply-To: <55880A3C.9060803@redhat.com> References: <55880A3C.9060803@redhat.com> Message-ID: <55880D10.8050608@redhat.com> I'm for #1. BTW, mappers don't support list at all they assume user attributes are just key/value pairs. On 6/22/2015 9:14 AM, Marek Posolda wrote: > LDAP allows to have multiple values of same attribute per single user. > There is usecase to map all the values of some LDAP attribute to > UserModel and then also to access token of particular user. > > For example, user has LDAP attribute "applications" with 2 values > "sales" and "finance". Then in application there is code like this: > > List values = accessToken.getOtherClaims().get("applications"); > > which should then return 2 values "sales" and "finance" . > > The main issue here is mapping of multiple LDAP attributes to the > UserModel, because "attributes" on UserModel currently support single > String value per attribute. I can see 2 possibilities to address this: > > 1) Change "attributes" map on UserModel to be MultivaluedMap and support > multiple String values per single key. This may require some migration, > however for JPA it can be easy. We just need to support multiple values > per single key and user in USER_ATTRIBUTES table (This breaks some > normal form, but looks better to me than introducing another table like > USER_ATTRIBUTE_VALUES as this will require migration changes again) > > 2) Use some delimiter for UserModel attribute value. So in previous > example, the value of attribute "applications" on the user will be > "sales###finance" (assuming that ### is delimiter). Then there will be > protocol mapper, which will be able to parse delimiter and create again > 2 values "sales" and "finance" to be used in access token. > > I am slightly for using (1) . What do you think? Any better ideas? > > Thanks, > Marek > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From sebastian.rose at aoe.com Mon Jun 22 09:45:03 2015 From: sebastian.rose at aoe.com (Sebastian Rose) Date: Mon, 22 Jun 2015 15:45:03 +0200 Subject: [keycloak-dev] Attachments/Links for general business terms Message-ID: <1B725C3C52B62D42A8A766BB4EFFCA2C4DFC816337@srv-mail01.aoemedia.lan> Hi there, i try to solve another customer requirement (with keycloak). We have to deal with general business terms as part of the registration. When a user accepts the general business terms during registration we have to send these general business terms text as part of the verification email as a link or as an attched pdf. What i have seen in the code might be extendible to attach a link or a pdf (not yet decided). 1) Link - if we simply would have this link as part of the template texts we need to redeploy these when the general business terms change. I would prefer to call an external service to resolve the correct url. 2) PDF - The service mentioned above can answer with a pdf. The pdf can then be attached/given to the mail process. Any comments are welcome... Best, Sebastian [cid:image001.jpg at 01D0AD01.8EDF0F20] Sebastian Rose Developer AOE GmbH LuisenForum, Kirchgasse 6 65185 Wiesbaden Germany Tel. +49 6122 70 70 7 -234 Fax. +49 6122 70 70 7 -199 e-Mail: sebastian.rose at aoe.com Web: http://www.aoe.com/ Pflichtangaben laut Handelsgesetz ?37a / Aktiengesetz ?35a USt-ID Nr.: DE250247455 Handelsregister: Wiesbaden B Handelsregister Nr.: 22567 Stammsitz: Wiesbaden Creditreform: 625.0209354 Gesch?ftsf?hrer: Kian Toyouri Gould Diese E-Mail Nachricht enth?lt vertrauliche und/oder rechtlich gesch?tzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. This e-mail message may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150622/f011b3c8/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 6344 bytes Desc: image001.jpg Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150622/f011b3c8/attachment.jpg From stian at redhat.com Tue Jun 23 11:09:48 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 23 Jun 2015 11:09:48 -0400 (EDT) Subject: [keycloak-dev] Error while building Keycloak 1.3.1 sources. In-Reply-To: <55849582.6020605@redhat.com> References: <1804904374.21258960.1434636594843.JavaMail.zimbra@redhat.com> <558403ED.1070309@redhat.com> <55849582.6020605@redhat.com> Message-ID: <1340875423.24301796.1435072188613.JavaMail.zimbra@redhat.com> Enforcer plugin looks like the way to go, but maybe we don't need to set it to 3.3.3? If it works on 3.1.x for others. My personal preference would just say go with Maven 3.3.x, but are there anyone that objects to that? ----- Original Message ----- > From: "Stan Silvert" > To: keycloak-dev at lists.jboss.org > Sent: Saturday, 20 June, 2015 12:19:46 AM > Subject: Re: [keycloak-dev] Error while building Keycloak 1.3.1 sources. > > On 6/19/2015 7:58 AM, Stan Silvert wrote: > > > > On 6/19/2015 6:24 AM, John wrote: > > > > Hi, > > After spending hours finally manged to get this working. > There were two issue found. > > 1) For the first time run mvn install without skipping tests > "-Dmaven.test.skip=true" Later on you may skip tests > > 2) To build distribution it needs maven version 3.3.3 else gives error > java.lang.ClassNotFoundException: org.eclipse.aether.RepositorySystem > > Can we have documentation for building from sources. > Or use the Enforcer plugin to mandate proper Maven version. > This will ensure nobody runs into that problem again: > https://github.com/keycloak/keycloak/pull/1407 > > > > > > > Thanks, > John > > > On Thu, Jun 18, 2015 at 8:03 PM, John < vainnkiitta at gmail.com > wrote: > > > > Using mvn install -Dmaven.test.skip=true > > My maven version > Apache Maven 3.0.5 > Maven home: /usr/share/maven > Java version: 1.7.0_79, vendor: Oracle Corporation > Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre > Default locale: en_IN, platform encoding: UTF-8 > OS name: "linux", version: "3.13.0-55-generic", arch: "amd64", family: "unix" > > > > > On Thu, Jun 18, 2015 at 7:39 PM, Stian Thorgersen < stian at redhat.com > wrote: > > What are the exact commands you're running? > > > > ----- Original Message ----- > >> From: "John" < vainnkiitta at gmail.com > > >> To: keycloak-dev at lists.jboss.org > >> Sent: Thursday, 18 June, 2015 3:47:13 PM > >> Subject: [keycloak-dev] Error while building Keycloak 1.3.1 sources. > >> > >> Hi All, > >> > >> I have downloaded source of keycloak 1.3.1 ver. > >> > >> I am doing mvn install but getting following error. > >> > >> [INFO] > >> ------------------------------------------------------------------------ > >> [INFO] BUILD FAILURE > >> [INFO] > >> ------------------------------------------------------------------------ > >> [INFO] Total time: 45.121s > >> [INFO] Finished at: Thu Jun 18 19:02:12 IST 2015 > >> [INFO] Final Memory: 215M/865M > >> [INFO] > >> ------------------------------------------------------------------------ > >> [ERROR] Failed to execute goal on project > >> keycloak-testsuite-security-proxy: Could not resolve dependencies for > >> project org.keycloak:keycloak-testsuite-security-proxy:jar:1.3.1.Final: > >> Could not find artifact > >> org.keycloak:keycloak-testsuite-integration:jar:tests:1.3.1.Final in > >> jboss-earlyaccess-repository > >> ( http://maven.repository.redhat.com/earlyaccess/all/ ) -> [Help 1] > >> > >> Any help appreciated. > >> > >> Thanks, > >> John > >> _______________________________________________ > >> 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 Jun 23 11:34:24 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 23 Jun 2015 11:34:24 -0400 Subject: [keycloak-dev] Error while building Keycloak 1.3.1 sources. In-Reply-To: <1340875423.24301796.1435072188613.JavaMail.zimbra@redhat.com> References: <1804904374.21258960.1434636594843.JavaMail.zimbra@redhat.com> <558403ED.1070309@redhat.com> <55849582.6020605@redhat.com> <1340875423.24301796.1435072188613.JavaMail.zimbra@redhat.com> Message-ID: <55897C80.2040301@redhat.com> On 6/23/2015 11:09 AM, Stian Thorgersen wrote: > Enforcer plugin looks like the way to go, but maybe we don't need to set it to 3.3.3? If it works on 3.1.x for others. > > My personal preference would just say go with Maven 3.3.x, but are there anyone that objects to that? No objection from me. The PR I sent sets it to 3.1.1. I can easily update that before it is merged. > > ----- Original Message ----- >> From: "Stan Silvert" >> To: keycloak-dev at lists.jboss.org >> Sent: Saturday, 20 June, 2015 12:19:46 AM >> Subject: Re: [keycloak-dev] Error while building Keycloak 1.3.1 sources. >> >> On 6/19/2015 7:58 AM, Stan Silvert wrote: >> >> >> >> On 6/19/2015 6:24 AM, John wrote: >> >> >> >> Hi, >> >> After spending hours finally manged to get this working. >> There were two issue found. >> >> 1) For the first time run mvn install without skipping tests >> "-Dmaven.test.skip=true" Later on you may skip tests >> >> 2) To build distribution it needs maven version 3.3.3 else gives error >> java.lang.ClassNotFoundException: org.eclipse.aether.RepositorySystem >> >> Can we have documentation for building from sources. >> Or use the Enforcer plugin to mandate proper Maven version. >> This will ensure nobody runs into that problem again: >> https://github.com/keycloak/keycloak/pull/1407 >> >> >> >> >> >> >> Thanks, >> John >> >> >> On Thu, Jun 18, 2015 at 8:03 PM, John < vainnkiitta at gmail.com > wrote: >> >> >> >> Using mvn install -Dmaven.test.skip=true >> >> My maven version >> Apache Maven 3.0.5 >> Maven home: /usr/share/maven >> Java version: 1.7.0_79, vendor: Oracle Corporation >> Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre >> Default locale: en_IN, platform encoding: UTF-8 >> OS name: "linux", version: "3.13.0-55-generic", arch: "amd64", family: "unix" >> >> >> >> >> On Thu, Jun 18, 2015 at 7:39 PM, Stian Thorgersen < stian at redhat.com > wrote: >>> What are the exact commands you're running? >>> >>> ----- Original Message ----- >>>> From: "John" < vainnkiitta at gmail.com > >>>> To: keycloak-dev at lists.jboss.org >>>> Sent: Thursday, 18 June, 2015 3:47:13 PM >>>> Subject: [keycloak-dev] Error while building Keycloak 1.3.1 sources. >>>> >>>> Hi All, >>>> >>>> I have downloaded source of keycloak 1.3.1 ver. >>>> >>>> I am doing mvn install but getting following error. >>>> >>>> [INFO] >>>> ------------------------------------------------------------------------ >>>> [INFO] BUILD FAILURE >>>> [INFO] >>>> ------------------------------------------------------------------------ >>>> [INFO] Total time: 45.121s >>>> [INFO] Finished at: Thu Jun 18 19:02:12 IST 2015 >>>> [INFO] Final Memory: 215M/865M >>>> [INFO] >>>> ------------------------------------------------------------------------ >>>> [ERROR] Failed to execute goal on project >>>> keycloak-testsuite-security-proxy: Could not resolve dependencies for >>>> project org.keycloak:keycloak-testsuite-security-proxy:jar:1.3.1.Final: >>>> Could not find artifact >>>> org.keycloak:keycloak-testsuite-integration:jar:tests:1.3.1.Final in >>>> jboss-earlyaccess-repository >>>> ( http://maven.repository.redhat.com/earlyaccess/all/ ) -> [Help 1] >>>> >>>> Any help appreciated. >>>> >>>> Thanks, >>>> John >>>> _______________________________________________ >>>> 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 stian at redhat.com Tue Jun 23 12:42:00 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 23 Jun 2015 12:42:00 -0400 (EDT) Subject: [keycloak-dev] Error while building Keycloak 1.3.1 sources. In-Reply-To: <55897C80.2040301@redhat.com> References: <1804904374.21258960.1434636594843.JavaMail.zimbra@redhat.com> <558403ED.1070309@redhat.com> <55849582.6020605@redhat.com> <1340875423.24301796.1435072188613.JavaMail.zimbra@redhat.com> <55897C80.2040301@redhat.com> Message-ID: <1913864526.24367171.1435077720205.JavaMail.zimbra@redhat.com> That's better, let's go with 3.1.1. No reason to require a higher version than we actually need. ----- Original Message ----- > From: "Stan Silvert" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Tuesday, 23 June, 2015 5:34:24 PM > Subject: Re: [keycloak-dev] Error while building Keycloak 1.3.1 sources. > > On 6/23/2015 11:09 AM, Stian Thorgersen wrote: > > Enforcer plugin looks like the way to go, but maybe we don't need to set it > > to 3.3.3? If it works on 3.1.x for others. > > > > My personal preference would just say go with Maven 3.3.x, but are there > > anyone that objects to that? > No objection from me. The PR I sent sets it to 3.1.1. I can easily > update that before it is merged. > > > > ----- Original Message ----- > >> From: "Stan Silvert" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Saturday, 20 June, 2015 12:19:46 AM > >> Subject: Re: [keycloak-dev] Error while building Keycloak 1.3.1 sources. > >> > >> On 6/19/2015 7:58 AM, Stan Silvert wrote: > >> > >> > >> > >> On 6/19/2015 6:24 AM, John wrote: > >> > >> > >> > >> Hi, > >> > >> After spending hours finally manged to get this working. > >> There were two issue found. > >> > >> 1) For the first time run mvn install without skipping tests > >> "-Dmaven.test.skip=true" Later on you may skip tests > >> > >> 2) To build distribution it needs maven version 3.3.3 else gives error > >> java.lang.ClassNotFoundException: org.eclipse.aether.RepositorySystem > >> > >> Can we have documentation for building from sources. > >> Or use the Enforcer plugin to mandate proper Maven version. > >> This will ensure nobody runs into that problem again: > >> https://github.com/keycloak/keycloak/pull/1407 > >> > >> > >> > >> > >> > >> > >> Thanks, > >> John > >> > >> > >> On Thu, Jun 18, 2015 at 8:03 PM, John < vainnkiitta at gmail.com > wrote: > >> > >> > >> > >> Using mvn install -Dmaven.test.skip=true > >> > >> My maven version > >> Apache Maven 3.0.5 > >> Maven home: /usr/share/maven > >> Java version: 1.7.0_79, vendor: Oracle Corporation > >> Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre > >> Default locale: en_IN, platform encoding: UTF-8 > >> OS name: "linux", version: "3.13.0-55-generic", arch: "amd64", family: > >> "unix" > >> > >> > >> > >> > >> On Thu, Jun 18, 2015 at 7:39 PM, Stian Thorgersen < stian at redhat.com > > >> wrote: > >>> What are the exact commands you're running? > >>> > >>> ----- Original Message ----- > >>>> From: "John" < vainnkiitta at gmail.com > > >>>> To: keycloak-dev at lists.jboss.org > >>>> Sent: Thursday, 18 June, 2015 3:47:13 PM > >>>> Subject: [keycloak-dev] Error while building Keycloak 1.3.1 sources. > >>>> > >>>> Hi All, > >>>> > >>>> I have downloaded source of keycloak 1.3.1 ver. > >>>> > >>>> I am doing mvn install but getting following error. > >>>> > >>>> [INFO] > >>>> ------------------------------------------------------------------------ > >>>> [INFO] BUILD FAILURE > >>>> [INFO] > >>>> ------------------------------------------------------------------------ > >>>> [INFO] Total time: 45.121s > >>>> [INFO] Finished at: Thu Jun 18 19:02:12 IST 2015 > >>>> [INFO] Final Memory: 215M/865M > >>>> [INFO] > >>>> ------------------------------------------------------------------------ > >>>> [ERROR] Failed to execute goal on project > >>>> keycloak-testsuite-security-proxy: Could not resolve dependencies for > >>>> project org.keycloak:keycloak-testsuite-security-proxy:jar:1.3.1.Final: > >>>> Could not find artifact > >>>> org.keycloak:keycloak-testsuite-integration:jar:tests:1.3.1.Final in > >>>> jboss-earlyaccess-repository > >>>> ( http://maven.repository.redhat.com/earlyaccess/all/ ) -> [Help 1] > >>>> > >>>> Any help appreciated. > >>>> > >>>> Thanks, > >>>> John > >>>> _______________________________________________ > >>>> 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 mposolda at redhat.com Tue Jun 23 16:07:54 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 23 Jun 2015 22:07:54 +0200 Subject: [keycloak-dev] Handle multivalued LDAP attributes on UserModel In-Reply-To: <55880D10.8050608@redhat.com> References: <55880A3C.9060803@redhat.com> <55880D10.8050608@redhat.com> Message-ID: <5589BC9A.2050200@redhat.com> Yeah, support in protocol mapper is next step... I can change existing UserAttributeMapper implementation to support multiple values. I can add new on/off config property "Is multivalued" . When off, it will read just single value of attribute from UserModel as it's now. When on, it will read all the values and will use List in access token (it will be list of all items of same type like List , List etc. Type is already provided by "Claim JSON Type" config property). Another possibility is to create another implementation of Protocol mapper for support multivalued, but I don't think it's needed... WDYT? Marek On 22/06/15 15:26, Bill Burke wrote: > I'm for #1. BTW, mappers don't support list at all they assume user > attributes are just key/value pairs. > > On 6/22/2015 9:14 AM, Marek Posolda wrote: >> LDAP allows to have multiple values of same attribute per single user. >> There is usecase to map all the values of some LDAP attribute to >> UserModel and then also to access token of particular user. >> >> For example, user has LDAP attribute "applications" with 2 values >> "sales" and "finance". Then in application there is code like this: >> >> List values = accessToken.getOtherClaims().get("applications"); >> >> which should then return 2 values "sales" and "finance" . >> >> The main issue here is mapping of multiple LDAP attributes to the >> UserModel, because "attributes" on UserModel currently support single >> String value per attribute. I can see 2 possibilities to address this: >> >> 1) Change "attributes" map on UserModel to be MultivaluedMap and support >> multiple String values per single key. This may require some migration, >> however for JPA it can be easy. We just need to support multiple values >> per single key and user in USER_ATTRIBUTES table (This breaks some >> normal form, but looks better to me than introducing another table like >> USER_ATTRIBUTE_VALUES as this will require migration changes again) >> >> 2) Use some delimiter for UserModel attribute value. So in previous >> example, the value of attribute "applications" on the user will be >> "sales###finance" (assuming that ### is delimiter). Then there will be >> protocol mapper, which will be able to parse delimiter and create again >> 2 values "sales" and "finance" to be used in access token. >> >> I am slightly for using (1) . What do you think? Any better ideas? >> >> Thanks, >> Marek >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From matzew at apache.org Thu Jun 25 06:34:33 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 25 Jun 2015 12:34:33 +0200 Subject: [keycloak-dev] MySQL 5.6 Message-ID: Hi, I did run KC 1.3.1 w/ latest Docker image (5.6) on EAP 6.4, and I am getting this warning: 10:50:55,579 WARN [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] (ServerService Thread Pool -- 72) Database does not support drop with cascade Did anyone notice - or try - this too? -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150625/234b6765/attachment.html From mposolda at redhat.com Thu Jun 25 08:49:57 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 25 Jun 2015 14:49:57 +0200 Subject: [keycloak-dev] MySQL 5.6 In-Reply-To: References: Message-ID: <558BF8F5.6030602@redhat.com> Yes, I am seeing it too. It shouldn't affect any functionality. Whole testsuite is passing fine with MySQL inspite of those warnings. Or do you see some other consequences? But possibly there might be some uncleaned objects in schema (indexes, constraints, etc) from tables, which were dropped during migration. I don't have idea if it's the case or not. Maybe we should investigate and doublecheck this? Feel free to create JIRA for that. Marek On 25.6.2015 12:34, Matthias Wessendorf wrote: > Hi, > > I did run KC 1.3.1 w/ latest Docker image (5.6) on EAP 6.4, and I am > getting this warning: > 10:50:55,579 WARN > [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] > (ServerService Thread Pool -- 72) Database does not support drop with > cascade > > Did anyone notice - or try - this too? > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150625/15725d26/attachment.html From matthew.casperson at autogeneral.com.au Sun Jun 28 19:45:48 2015 From: matthew.casperson at autogeneral.com.au (Matthew Casperson) Date: Mon, 29 Jun 2015 09:45:48 +1000 Subject: [keycloak-dev] Tomcat 7 Adapter crashes on startup Message-ID: I have been seeing this a bit recently (I'm using KeyCloak 1.2.0). I haven't tracked down a reproducible test case yet, but I'm wondering if there are situations where Tomcat will attempt to stop the value before it is started, which leads to nodesRegistrationManagement being null. Maybe it is worth adding a null check in AbstractKeycloakAuthenticatorValve.beforeStop()? java.lang.NullPointerException at org.keycloak.adapters.tomcat.AbstractKeycloakAuthenticatorValve.beforeStop(AbstractKeycloakAuthenticatorValve.java:130) at org.keycloak.adapters.tomcat.AbstractKeycloakAuthenticatorValve.lifecycleEvent(AbstractKeycloakAuthenticatorValve.java:67) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:226) at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:272) at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:1041) at org.apache.catalina.startup.HostConfig.deleteRedeployResources(HostConfig.java:1300) at org.apache.catalina.startup.HostConfig.checkResources(HostConfig.java:1251) at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1460) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:301) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) at org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:1445) at org.apache.catalina.manager.ManagerServlet.undeploy(ManagerServlet.java:1381) at org.apache.catalina.manager.HTMLManagerServlet.undeploy(HTMLManagerServlet.java:674) at org.apache.catalina.manager.HTMLManagerServlet.doPost(HTMLManagerServlet.java:215) at javax.servlet.http.HttpServlet.service(HttpServlet.java:647) at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.filters.CsrfPreventionFilter.doFilter(CsrfPreventionFilter.java:213) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:581) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) -- *Matthew Casperson* *Senior Front End Developer* Technology, Space & Distribution Auto & General Holdings Pty Ltd P: 07) 3377 8751 (Direct: 3377 8751) F: 07) 3377 8833 -- This email is sent by Auto & General Insurance Company Ltd, Auto & General Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body corporate (Auto & General) and is for the intended addressee. The views expressed in this email and attachments (email) reflect the views of the stated author but may not reflect views of Auto & General. This email is confidential and subject to copyright. It may be privileged. If you are not the intended addressee, confidentiality and privilege have not been waived and any use, interference with, or disclosure of this email is unauthorised. If you are not the intended addressee please immediately notify the sender and then delete the email. Auto & General does not warrant that this email is error or virus free. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150629/df9d6a49/attachment-0001.html From matthew.casperson at autogeneral.com.au Sun Jun 28 20:46:36 2015 From: matthew.casperson at autogeneral.com.au (Matthew Casperson) Date: Mon, 29 Jun 2015 10:46:36 +1000 Subject: [keycloak-dev] Tomcat 7 Adapter crashes on startup In-Reply-To: References: Message-ID: Looking at this a bit closer it seems that Tomcat 7.0.35 will call stop() if the lifecycle state is set to FAILED. http://grepcode.com/file/repo1.maven.org/maven2/org.apache.tomcat/tomcat-catalina/7.0.35/org/apache/catalina/util/LifecycleBase.java line 141. On Mon, Jun 29, 2015 at 9:45 AM, Matthew Casperson < matthew.casperson at autogeneral.com.au> wrote: > I have been seeing this a bit recently (I'm using KeyCloak 1.2.0). I > haven't tracked down a reproducible test case yet, but I'm wondering if > there are situations where Tomcat will attempt to stop the value before it > is started, which leads to nodesRegistrationManagement being null. > > Maybe it is worth adding a null check in > AbstractKeycloakAuthenticatorValve.beforeStop()? > > java.lang.NullPointerException > at > org.keycloak.adapters.tomcat.AbstractKeycloakAuthenticatorValve.beforeStop(AbstractKeycloakAuthenticatorValve.java:130) > at > org.keycloak.adapters.tomcat.AbstractKeycloakAuthenticatorValve.lifecycleEvent(AbstractKeycloakAuthenticatorValve.java:67) > at > org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) > at > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) > at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:226) > at > org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:272) > at > org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:1041) > at > org.apache.catalina.startup.HostConfig.deleteRedeployResources(HostConfig.java:1300) > at > org.apache.catalina.startup.HostConfig.checkResources(HostConfig.java:1251) > at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1460) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at > org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:301) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) > at > com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) > at > org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:1445) > at > org.apache.catalina.manager.ManagerServlet.undeploy(ManagerServlet.java:1381) > at > org.apache.catalina.manager.HTMLManagerServlet.undeploy(HTMLManagerServlet.java:674) > at > org.apache.catalina.manager.HTMLManagerServlet.doPost(HTMLManagerServlet.java:215) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:647) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at > org.apache.catalina.filters.CsrfPreventionFilter.doFilter(CsrfPreventionFilter.java:213) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at > org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) > at > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:581) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) > at > org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004) > at > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) > at > org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > > -- > *Matthew Casperson* > *Senior Front End Developer* > Technology, Space & Distribution > Auto & General Holdings Pty Ltd > P: 07) 3377 8751 (Direct: 3377 8751) > F: 07) 3377 8833 > > > -- *Matthew Casperson* *Senior Front End Developer* Technology, Space & Distribution Auto & General Holdings Pty Ltd P: 07) 3377 8751 (Direct: 3377 8751) F: 07) 3377 8833 -- This email is sent by Auto & General Insurance Company Ltd, Auto & General Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body corporate (Auto & General) and is for the intended addressee. The views expressed in this email and attachments (email) reflect the views of the stated author but may not reflect views of Auto & General. This email is confidential and subject to copyright. It may be privileged. If you are not the intended addressee, confidentiality and privilege have not been waived and any use, interference with, or disclosure of this email is unauthorised. If you are not the intended addressee please immediately notify the sender and then delete the email. Auto & General does not warrant that this email is error or virus free. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150629/affd5702/attachment.html From matzew at apache.org Mon Jun 29 04:03:14 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 29 Jun 2015 10:03:14 +0200 Subject: [keycloak-dev] MySQL 5.6 In-Reply-To: <558BF8F5.6030602@redhat.com> References: <558BF8F5.6030602@redhat.com> Message-ID: Hi Marek, I saw that you have test w/ 5.6 and yeah, it seemed to work for me too :-) I created a minor JIRA for this: https://issues.jboss.org/browse/KEYCLOAK-1506 IMO it's not the end of the world if this warning stays :-) On Thu, Jun 25, 2015 at 2:49 PM, Marek Posolda wrote: > Yes, I am seeing it too. It shouldn't affect any functionality. Whole > testsuite is passing fine with MySQL inspite of those warnings. Or do you > see some other consequences? > > But possibly there might be some uncleaned objects in schema (indexes, > constraints, etc) from tables, which were dropped during migration. I don't > have idea if it's the case or not. Maybe we should investigate and > doublecheck this? Feel free to create JIRA for that. > > Marek > > > > On 25.6.2015 12:34, Matthias Wessendorf wrote: > > Hi, > > I did run KC 1.3.1 w/ latest Docker image (5.6) on EAP 6.4, and I am > getting this warning: > 10:50:55,579 WARN > [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] > (ServerService Thread Pool -- 72) Database does not support drop with > cascade > > Did anyone notice - or try - this too? > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150629/3cb8fd16/attachment.html From mstrukel at redhat.com Mon Jun 29 04:13:14 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Mon, 29 Jun 2015 04:13:14 -0400 (EDT) Subject: [keycloak-dev] Tomcat 7 Adapter crashes on startup In-Reply-To: References: Message-ID: <964041929.10151354.1435565594250.JavaMail.zimbra@redhat.com> Makes perfect sense to add a null check. Could you open a JIRA for this? Or even provide a fix :) Thanks. ----- Original Message ----- > Looking at this a bit closer it seems that Tomcat 7.0.35 will call stop() if > the lifecycle state is set to FAILED. > > http://grepcode.com/file/repo1.maven.org/maven2/org.apache.tomcat/tomcat-catalina/7.0.35/org/apache/catalina/util/LifecycleBase.java > line 141. > > On Mon, Jun 29, 2015 at 9:45 AM, Matthew Casperson < > matthew.casperson at autogeneral.com.au > wrote: > > > > I have been seeing this a bit recently (I'm using KeyCloak 1.2.0). I haven't > tracked down a reproducible test case yet, but I'm wondering if there are > situations where Tomcat will attempt to stop the value before it is started, > which leads to nodesRegistrationManagement being null. > > Maybe it is worth adding a null check in > AbstractKeycloakAuthenticatorValve.beforeStop()? > > java.lang.NullPointerException > at > org.keycloak.adapters.tomcat.AbstractKeycloakAuthenticatorValve.beforeStop(AbstractKeycloakAuthenticatorValve.java:130) > at > org.keycloak.adapters.tomcat.AbstractKeycloakAuthenticatorValve.lifecycleEvent(AbstractKeycloakAuthenticatorValve.java:67) > at > org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) > at > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) > at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:226) > at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:272) > at > org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:1041) > at > org.apache.catalina.startup.HostConfig.deleteRedeployResources(HostConfig.java:1300) > at > org.apache.catalina.startup.HostConfig.checkResources(HostConfig.java:1251) > at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1460) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at > org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:301) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) > at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) > at org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:1445) > at > org.apache.catalina.manager.ManagerServlet.undeploy(ManagerServlet.java:1381) > at > org.apache.catalina.manager.HTMLManagerServlet.undeploy(HTMLManagerServlet.java:674) > at > org.apache.catalina.manager.HTMLManagerServlet.doPost(HTMLManagerServlet.java:215) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:647) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at > org.apache.catalina.filters.CsrfPreventionFilter.doFilter(CsrfPreventionFilter.java:213) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at > org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) > at > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:581) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) > at > org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004) > at > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) > at > org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > > -- > Matthew Casperson > Senior Front End Developer > Technology, Space & Distribution > Auto & General Holdings Pty Ltd > P: 07) 3377 8751 (Direct: 3377 8751 ) > F: 07) 3377 8833 > > > > > > -- > Matthew Casperson > Senior Front End Developer > Technology, Space & Distribution > Auto & General Holdings Pty Ltd > P: 07) 3377 8751 (Direct: 3377 8751 ) > F: 07) 3377 8833 > > > > This email is sent by Auto & General Insurance Company Ltd, Auto & General > Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body > corporate (Auto & General) and is for the intended addressee. > The views expressed in this email and attachments (email) reflect the views > of the stated author but may not reflect views of Auto & General. This email > is confidential and subject to copyright. > It may be privileged. If you are not the intended addressee, confidentiality > and privilege have not been waived and any use, interference with, or > disclosure of this email is unauthorised. > If you are not the intended addressee please immediately notify the sender > and then delete the email. Auto & General does not warrant that this email > is error or virus free. > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From dalvarez at inventiaplus.com Mon Jun 29 06:56:14 2015 From: dalvarez at inventiaplus.com (=?UTF-8?Q?David_=C3=81lvarez?=) Date: Mon, 29 Jun 2015 11:56:14 +0100 Subject: [keycloak-dev] Locale propagation from secured application Message-ID: Hi! We have a Keycloak secured application. This application is a multilingual application. In the application a free access zone is defined and a link to "login" is available to users can access to a private area. In that scenario we need that the user selected language in application will be applied in Keycloak login page. When a user require a login action this code is executed: [...] response.encodeRedirectURL("/index.xhtml"); req.authenticate(response); [...] Can we force an locale use in authenticate? Default locale value from Keycloak configuration is allways applied. Thanks a lot! -- David Alvarez Cabal dalvarez at inventiaplus.com www.inventiaplus.com * 928 702 054* *ADVERTENCIA* La informaci?n contenida en este correo electr?nico, y en su caso, cualquier fichero anexo al mismo, son de car?cter privado y confidencial siendo para uso exclusivo de su destinatario. Si usted no es el destinatario correcto, el empleado o agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicaci?n por error, le informamos que est? totalmente prohibida cualquier divulgaci?n, distribuci?n o reproducci?n de esta comunicaci?n seg?n la legislaci?n vigente y le rogamos que nos lo notifique inmediatamente, procediendo a su destrucci?n sin continuar su lectura. Le informamos que su direcci?n de correo electr?nico, as? como el resto de los datos de car?cter personal de la tarjeta de visita que nos facilite, podr?an ser objeto de tratamiento automatizado en nuestros ficheros, con la finalidad de gestionar la agenda de contactos de INVENTIA PLUS, S.L.. Vd. podr? en cualquier momento ejercer sus derechos de acceso, rectificaci?n, cancelaci?n y oposici?n en los t?rminos establecidos en la Ley Org?nica 15/1999 mediante notificaci?n escrita a la siguiente direcci?n: c/ Pintor, n? 8, Pol. Ind. Salinetas, 35219, Telde, Las Palmas. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150629/d9db9b69/attachment.html From ssilvert at redhat.com Mon Jun 29 16:35:27 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Mon, 29 Jun 2015 16:35:27 -0400 Subject: [keycloak-dev] Idle timeout notificaion Message-ID: <5591AC0F.70102@redhat.com> It's common for applications to notify the user if their login session has timed out due to inactivity. Then the app typically presents a popup notification and possibly an option to refresh the session. There is a customer who wants to do this for several applications in the same realm. Is this something that Keycloak could/should provide or at least help with? I'm thinking that maybe a bit of javascript could register with the Keycloak server for a notification. Stan From bburke at redhat.com Mon Jun 29 17:26:17 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 29 Jun 2015 17:26:17 -0400 Subject: [keycloak-dev] Idle timeout notificaion In-Reply-To: <5591AC0F.70102@redhat.com> References: <5591AC0F.70102@redhat.com> Message-ID: <5591B7F9.6020700@redhat.com> We do need some way to listen at the adapter level for a logout event sent by the auth server. Undertow and Tomcat and Jetty all have ways to listen for session invalidation events I believe too. Not sure if the servlet spec has something standard. On 6/29/2015 4:35 PM, Stan Silvert wrote: > It's common for applications to notify the user if their login session > has timed out due to inactivity. Then the app typically presents a > popup notification and possibly an option to refresh the session. > > There is a customer who wants to do this for several applications in the > same realm. Is this something that Keycloak could/should provide or at > least help with? I'm thinking that maybe a bit of javascript could > register with the Keycloak server for a notification. > > Stan > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From matthew.casperson at autogeneral.com.au Mon Jun 29 17:37:32 2015 From: matthew.casperson at autogeneral.com.au (Matthew Casperson) Date: Tue, 30 Jun 2015 07:37:32 +1000 Subject: [keycloak-dev] Tomcat 7 Adapter crashes on startup In-Reply-To: <964041929.10151354.1435565594250.JavaMail.zimbra@redhat.com> References: <964041929.10151354.1435565594250.JavaMail.zimbra@redhat.com> Message-ID: Created https://issues.jboss.org/browse/KEYCLOAK-1507. Cheers Matt On Mon, Jun 29, 2015 at 6:13 PM, Marko Strukelj wrote: > Makes perfect sense to add a null check. Could you open a JIRA for this? > Or even provide a fix :) > > Thanks. > > ----- Original Message ----- > > Looking at this a bit closer it seems that Tomcat 7.0.35 will call > stop() if > > the lifecycle state is set to FAILED. > > > > > http://grepcode.com/file/repo1.maven.org/maven2/org.apache.tomcat/tomcat-catalina/7.0.35/org/apache/catalina/util/LifecycleBase.java > > line 141. > > > > On Mon, Jun 29, 2015 at 9:45 AM, Matthew Casperson < > > matthew.casperson at autogeneral.com.au > wrote: > > > > > > > > I have been seeing this a bit recently (I'm using KeyCloak 1.2.0). I > haven't > > tracked down a reproducible test case yet, but I'm wondering if there are > > situations where Tomcat will attempt to stop the value before it is > started, > > which leads to nodesRegistrationManagement being null. > > > > Maybe it is worth adding a null check in > > AbstractKeycloakAuthenticatorValve.beforeStop()? > > > > java.lang.NullPointerException > > at > > > org.keycloak.adapters.tomcat.AbstractKeycloakAuthenticatorValve.beforeStop(AbstractKeycloakAuthenticatorValve.java:130) > > at > > > org.keycloak.adapters.tomcat.AbstractKeycloakAuthenticatorValve.lifecycleEvent(AbstractKeycloakAuthenticatorValve.java:67) > > at > > > org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) > > at > > > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) > > at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:226) > > at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:272) > > at > > > org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:1041) > > at > > > org.apache.catalina.startup.HostConfig.deleteRedeployResources(HostConfig.java:1300) > > at > > > org.apache.catalina.startup.HostConfig.checkResources(HostConfig.java:1251) > > at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1460) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > > at > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:483) > > at > > > org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:301) > > at > > > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) > > at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) > > at > org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:1445) > > at > > > org.apache.catalina.manager.ManagerServlet.undeploy(ManagerServlet.java:1381) > > at > > > org.apache.catalina.manager.HTMLManagerServlet.undeploy(HTMLManagerServlet.java:674) > > at > > > org.apache.catalina.manager.HTMLManagerServlet.doPost(HTMLManagerServlet.java:215) > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:647) > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) > > at > > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) > > at > > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > > at > > > org.apache.catalina.filters.CsrfPreventionFilter.doFilter(CsrfPreventionFilter.java:213) > > at > > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > > at > > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > > at > > > org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108) > > at > > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > > at > > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > > at > > > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) > > at > > > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) > > at > > > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:581) > > at > > > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) > > at > > > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) > > at > > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) > > at > > > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) > > at > > > org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004) > > at > > > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) > > at > > > org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312) > > at > > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > > at > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > > at java.lang.Thread.run(Thread.java:745) > > > > -- > > Matthew Casperson > > Senior Front End Developer > > Technology, Space & Distribution > > Auto & General Holdings Pty Ltd > > P: 07) 3377 8751 (Direct: 3377 8751 ) > > F: 07) 3377 8833 > > > > > > > > > > > > -- > > Matthew Casperson > > Senior Front End Developer > > Technology, Space & Distribution > > Auto & General Holdings Pty Ltd > > P: 07) 3377 8751 (Direct: 3377 8751 ) > > F: 07) 3377 8833 > > > > > > > > This email is sent by Auto & General Insurance Company Ltd, Auto & > General > > Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body > > corporate (Auto & General) and is for the intended addressee. > > The views expressed in this email and attachments (email) reflect the > views > > of the stated author but may not reflect views of Auto & General. This > email > > is confidential and subject to copyright. > > It may be privileged. If you are not the intended addressee, > confidentiality > > and privilege have not been waived and any use, interference with, or > > disclosure of this email is unauthorised. > > If you are not the intended addressee please immediately notify the > sender > > and then delete the email. Auto & General does not warrant that this > email > > is error or virus free. > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- *Matthew Casperson* *Senior Front End Developer* Technology, Space & Distribution Auto & General Holdings Pty Ltd P: 07) 3377 8751 (Direct: 3377 8751) F: 07) 3377 8833 -- This email is sent by Auto & General Insurance Company Ltd, Auto & General Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body corporate (Auto & General) and is for the intended addressee. The views expressed in this email and attachments (email) reflect the views of the stated author but may not reflect views of Auto & General. This email is confidential and subject to copyright. It may be privileged. If you are not the intended addressee, confidentiality and privilege have not been waived and any use, interference with, or disclosure of this email is unauthorised. If you are not the intended addressee please immediately notify the sender and then delete the email. Auto & General does not warrant that this email is error or virus free. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150630/ec6b2fe3/attachment-0001.html From ssilvert at redhat.com Mon Jun 29 17:39:24 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Mon, 29 Jun 2015 17:39:24 -0400 Subject: [keycloak-dev] Idle timeout notificaion In-Reply-To: <5591B7F9.6020700@redhat.com> References: <5591AC0F.70102@redhat.com> <5591B7F9.6020700@redhat.com> Message-ID: <5591BB0C.5030209@redhat.com> On 6/29/2015 5:26 PM, Bill Burke wrote: > We do need some way to listen at the adapter level for a logout event > sent by the auth server. Undertow and Tomcat and Jetty all have ways to > listen for session invalidation events I believe too. Not sure if the > servlet spec has something standard. Yes, the servlet spec has HttpSessionListener with a sessionDestroyed() callback. We could come up with some javascript that you put on the client side that registers with the adapter and gets notified of session invalidation. I'm just wondering if it's something we should provide or not. > > On 6/29/2015 4:35 PM, Stan Silvert wrote: >> It's common for applications to notify the user if their login session >> has timed out due to inactivity. Then the app typically presents a >> popup notification and possibly an option to refresh the session. >> >> There is a customer who wants to do this for several applications in the >> same realm. Is this something that Keycloak could/should provide or at >> least help with? I'm thinking that maybe a bit of javascript could >> register with the Keycloak server for a notification. >> >> Stan >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From bburke at redhat.com Mon Jun 29 20:34:57 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 29 Jun 2015 20:34:57 -0400 Subject: [keycloak-dev] Idle timeout notificaion In-Reply-To: <5591BB0C.5030209@redhat.com> References: <5591AC0F.70102@redhat.com> <5591B7F9.6020700@redhat.com> <5591BB0C.5030209@redhat.com> Message-ID: <5591E431.8050802@redhat.com> On 6/29/2015 5:39 PM, Stan Silvert wrote: > On 6/29/2015 5:26 PM, Bill Burke wrote: >> We do need some way to listen at the adapter level for a logout event >> sent by the auth server. Undertow and Tomcat and Jetty all have ways to >> listen for session invalidation events I believe too. Not sure if the >> servlet spec has something standard. > Yes, the servlet spec has HttpSessionListener with a sessionDestroyed() > callback. > > We could come up with some javascript that you put on the client side > that registers with the adapter and gets notified of session > invalidation. I'm just wondering if it's something we should provide or > not. Javascript adapter already checks for logout. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From srossillo at smartling.com Mon Jun 29 22:57:15 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Mon, 29 Jun 2015 22:57:15 -0400 Subject: [keycloak-dev] Deleting a user fails without error Message-ID: <7A4EBA83-23AB-4FE0-849A-985BDF4A7A09@smartling.com> In 1.2.0, an HTTP delete on ?/auth/admin/realms/{realm}/users/{username}? returns a 200 OK, but the user still exists. A second call usually succeeds at actually deleting the user. Seems like a bug. Thoughts? ~ Scott From larsfrauenrath at web.de Tue Jun 30 05:46:42 2015 From: larsfrauenrath at web.de (lars frauenrath) Date: Tue, 30 Jun 2015 11:46:42 +0200 Subject: [keycloak-dev] Login-Page Message-ID: An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150630/9a41d50d/attachment.html From bburke at redhat.com Tue Jun 30 07:00:03 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 30 Jun 2015 07:00:03 -0400 Subject: [keycloak-dev] Login-Page In-Reply-To: References: Message-ID: <559276B3.4040907@redhat.com> You have to redirect, or there is no SSO. On 6/30/2015 5:46 AM, lars frauenrath wrote: > Hello everyone, > I am using KeyCloak with a Wildfly 8. > Is it possible to integrate the login page of keycloak to the login page > of my application (without redirect or something else) ? > So, I want to for exmaple include the whole keycloak login page into a > part of my login page. > Thanks. > Best regards, > Lars > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From ramtinova at gmail.com Tue Jun 30 07:05:30 2015 From: ramtinova at gmail.com (Reza Rasouli) Date: Tue, 30 Jun 2015 15:35:30 +0430 Subject: [keycloak-dev] Login-Page In-Reply-To: <559276B3.4040907@redhat.com> References: <559276B3.4040907@redhat.com> Message-ID: take a look :? http://docs.jboss.org/keycloak/docs/1.0-rc-1/userguide/html/admin-rest-api.html ? On Tue, Jun 30, 2015 at 3:30 PM, Bill Burke wrote: > You have to redirect, or there is no SSO. > > On 6/30/2015 5:46 AM, lars frauenrath wrote: > > Hello everyone, > > I am using KeyCloak with a Wildfly 8. > > Is it possible to integrate the login page of keycloak to the login page > > of my application (without redirect or something else) ? > > So, I want to for exmaple include the whole keycloak login page into a > > part of my login page. > > Thanks. > > Best regards, > > Lars > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- *Warm Regards,* *Reza Rasouli.* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150630/a492d561/attachment.html From ssilvert at redhat.com Tue Jun 30 08:23:59 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 30 Jun 2015 08:23:59 -0400 Subject: [keycloak-dev] Idle timeout notificaion In-Reply-To: <5591E431.8050802@redhat.com> References: <5591AC0F.70102@redhat.com> <5591B7F9.6020700@redhat.com> <5591BB0C.5030209@redhat.com> <5591E431.8050802@redhat.com> Message-ID: <55928A5F.2070001@redhat.com> On 6/29/2015 8:34 PM, Bill Burke wrote: > > On 6/29/2015 5:39 PM, Stan Silvert wrote: >> On 6/29/2015 5:26 PM, Bill Burke wrote: >>> We do need some way to listen at the adapter level for a logout event >>> sent by the auth server. Undertow and Tomcat and Jetty all have ways to >>> listen for session invalidation events I believe too. Not sure if the >>> servlet spec has something standard. >> Yes, the servlet spec has HttpSessionListener with a sessionDestroyed() >> callback. >> >> We could come up with some javascript that you put on the client side >> that registers with the adapter and gets notified of session >> invalidation. I'm just wondering if it's something we should provide or >> not. > Javascript adapter already checks for logout. > What would you suggest for apps that use the other adapters? From mposolda at redhat.com Tue Jun 30 08:27:42 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 30 Jun 2015 14:27:42 +0200 Subject: [keycloak-dev] Deleting a user fails without error In-Reply-To: <7A4EBA83-23AB-4FE0-849A-985BDF4A7A09@smartling.com> References: <7A4EBA83-23AB-4FE0-849A-985BDF4A7A09@smartling.com> Message-ID: <55928B3E.6020106@redhat.com> Hi Scott, I've just tried this with latest Keycloak master and deleting the user from admin console works fine (I used default JPA with HSQLDB database). Can you also check with admin console? If deleting through admin console works fine, then there is likely something bad in the way you're invoking the REST endpoint. BTV. in latest master you're supposed to invoke the REST endpoint with user id instead of "username" as last parameter. But I am not sure if it was really username in 1.2.0 and it changed to ID in latest version... Marek On 30.6.2015 04:57, Scott Rossillo wrote: > In 1.2.0, an HTTP delete on ?/auth/admin/realms/{realm}/users/{username}? returns a 200 OK, but the user still exists. A second call usually succeeds at actually deleting the user. Seems like a bug. > > Thoughts? > > ~ Scott > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Tue Jun 30 09:02:55 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 30 Jun 2015 15:02:55 +0200 Subject: [keycloak-dev] Handle multivalued LDAP attributes on UserModel In-Reply-To: <5589BC9A.2050200@redhat.com> References: <55880A3C.9060803@redhat.com> <55880D10.8050608@redhat.com> <5589BC9A.2050200@redhat.com> Message-ID: <5592937F.4040202@redhat.com> I've pushed this to latest master. Changes: - there is support for multiple values of single attribute on UserModel. So attributes is now Map> . There is also methods like "setSingleAttribute" and "getFirstAttribute" for easier work with singlevalued attributes similarly like on MultivaluedMap - there is support for map multiple values of LDAP attribute to the multiple values of this UserModel attribute - there is switch "multivalued" on UserAttribute protocol mapper (just added the support to OIDC based UserAttributeMapper for now). When it's on, it sets the List of all the values of attribute as the value of claim on id token (or access token) Still some possible todos: - Migration and documentation - Maybe LDAP example (will send separate email) - Maybe more proper support for multiple attributes in our UI (registration form, account management, admin console). Right now, it just displays the first value and user has possibility to edit just this one. I am not sure if it's the priority to improve this... Marek On 23.6.2015 22:07, Marek Posolda wrote: > Yeah, support in protocol mapper is next step... > > I can change existing UserAttributeMapper implementation to support > multiple values. I can add new on/off config property "Is multivalued" . > When off, it will read just single value of attribute from UserModel as > it's now. When on, it will read all the values and will use List in > access token (it will be list of all items of same type like > List , List etc. Type is already provided by "Claim JSON > Type" config property). > > Another possibility is to create another implementation of Protocol > mapper for support multivalued, but I don't think it's needed... > > WDYT? > > Marek > > On 22/06/15 15:26, Bill Burke wrote: >> I'm for #1. BTW, mappers don't support list at all they assume user >> attributes are just key/value pairs. >> >> On 6/22/2015 9:14 AM, Marek Posolda wrote: >>> LDAP allows to have multiple values of same attribute per single user. >>> There is usecase to map all the values of some LDAP attribute to >>> UserModel and then also to access token of particular user. >>> >>> For example, user has LDAP attribute "applications" with 2 values >>> "sales" and "finance". Then in application there is code like this: >>> >>> List values = accessToken.getOtherClaims().get("applications"); >>> >>> which should then return 2 values "sales" and "finance" . >>> >>> The main issue here is mapping of multiple LDAP attributes to the >>> UserModel, because "attributes" on UserModel currently support single >>> String value per attribute. I can see 2 possibilities to address this: >>> >>> 1) Change "attributes" map on UserModel to be MultivaluedMap and support >>> multiple String values per single key. This may require some migration, >>> however for JPA it can be easy. We just need to support multiple values >>> per single key and user in USER_ATTRIBUTES table (This breaks some >>> normal form, but looks better to me than introducing another table like >>> USER_ATTRIBUTE_VALUES as this will require migration changes again) >>> >>> 2) Use some delimiter for UserModel attribute value. So in previous >>> example, the value of attribute "applications" on the user will be >>> "sales###finance" (assuming that ### is delimiter). Then there will be >>> protocol mapper, which will be able to parse delimiter and create again >>> 2 values "sales" and "finance" to be used in access token. >>> >>> I am slightly for using (1) . What do you think? Any better ideas? >>> >>> Thanks, >>> 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 Tue Jun 30 09:12:41 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 30 Jun 2015 15:12:41 +0200 Subject: [keycloak-dev] Packaging of ApacheDS for examples? Message-ID: <559295C9.3040409@redhat.com> I am thinking about adding LDAP example, which can be used as a base for LDAP mappers based blog and screencast. It will contain the application to show some claims (also both singlevalued and multivalued attributes). It will also contain JSON realm with UserFederation configuration pointing to our ApacheDS and LDIF with some simple users for testing. I already added end-to-end test to the testsuite (LDAPMultipleAttributesTest.ldapPortalEndToEndTest ) The only possible problem is how to easily bootstrap ApacheDS based LDAP servers in user's environment. I am thinking about 3 approaches: a) Point to the embedded ApacheDS server from our testsuite. This will be easy to do and it's what Kerberos example is already doing . Problem is that it requires people to checkout the keycloak sources through github and build them through maven, so not very user friendly b) Create docker image for ApacheDS servers (one for ldap example and another for kerberos). Not sure if it's fine to require users to install docker (even more pain might be on windows, when they need boot2docker or something...) c) Packaging with ApacheDS based servers directly into our example package, so people can just run something like: java -jar keycloak-examples/ldap/apacheds-embedded.jar -Dldif.location=keycloak-examples/ldap/example.ldif and similarly for kerberos. For me it's easiest to go with (a) but not sure about usability... Regarding usability (c) looks best but it's much more work. WDYT? Marek -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150630/4c770e95/attachment.html From srossillo at smartling.com Tue Jun 30 09:18:02 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Tue, 30 Jun 2015 13:18:02 +0000 Subject: [keycloak-dev] Deleting a user fails without error In-Reply-To: <55928B3E.6020106@redhat.com> References: <7A4EBA83-23AB-4FE0-849A-985BDF4A7A09@smartling.com> <55928B3E.6020106@redhat.com> Message-ID: Yes it changed in 1.3 to ID. We're making the same API call as the admin console does only we're doing it right after the user is created if they don't meet certain criteria in client. These are social logins. We're using MySQL but that shouldn't matter. Perhaps something Keycloack server side is holding reference to the user. I'll try to provide more information in a few days but wasn't sure if anyone saw this behavior before. Thanks, Scott On Tue, Jun 30, 2015 at 8:27 AM Marek Posolda wrote: > Hi Scott, > > I've just tried this with latest Keycloak master and deleting the user > from admin console works fine (I used default JPA with HSQLDB database). > > Can you also check with admin console? If deleting through admin console > works fine, then there is likely something bad in the way you're > invoking the REST endpoint. > > BTV. in latest master you're supposed to invoke the REST endpoint with > user id instead of "username" as last parameter. But I am not sure if it > was really username in 1.2.0 and it changed to ID in latest version... > > Marek > > > On 30.6.2015 04:57, Scott Rossillo wrote: > > In 1.2.0, an HTTP delete on > ?/auth/admin/realms/{realm}/users/{username}? returns a 200 OK, but the > user still exists. A second call usually succeeds at actually deleting the > user. Seems like a bug. > > > > Thoughts? > > > > ~ Scott > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150630/533a6f77/attachment.html From bburke at redhat.com Tue Jun 30 09:22:39 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 30 Jun 2015 09:22:39 -0400 Subject: [keycloak-dev] Idle timeout notificaion In-Reply-To: <55928A5F.2070001@redhat.com> References: <5591AC0F.70102@redhat.com> <5591B7F9.6020700@redhat.com> <5591BB0C.5030209@redhat.com> <5591E431.8050802@redhat.com> <55928A5F.2070001@redhat.com> Message-ID: <5592981F.4040309@redhat.com> On 6/30/2015 8:23 AM, Stan Silvert wrote: > On 6/29/2015 8:34 PM, Bill Burke wrote: >> >> On 6/29/2015 5:39 PM, Stan Silvert wrote: >>> On 6/29/2015 5:26 PM, Bill Burke wrote: >>>> We do need some way to listen at the adapter level for a logout event >>>> sent by the auth server. Undertow and Tomcat and Jetty all have ways to >>>> listen for session invalidation events I believe too. Not sure if the >>>> servlet spec has something standard. >>> Yes, the servlet spec has HttpSessionListener with a sessionDestroyed() >>> callback. >>> >>> We could come up with some javascript that you put on the client side >>> that registers with the adapter and gets notified of session >>> invalidation. I'm just wondering if it's something we should provide or >>> not. >> Javascript adapter already checks for logout. >> > What would you suggest for apps that use the other adapters? They should use regular servlet means to timeout the session. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From ssilvert at redhat.com Tue Jun 30 11:00:52 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 30 Jun 2015 11:00:52 -0400 Subject: [keycloak-dev] Idle timeout notificaion In-Reply-To: <5592981F.4040309@redhat.com> References: <5591AC0F.70102@redhat.com> <5591B7F9.6020700@redhat.com> <5591BB0C.5030209@redhat.com> <5591E431.8050802@redhat.com> <55928A5F.2070001@redhat.com> <5592981F.4040309@redhat.com> Message-ID: <5592AF24.4040403@redhat.com> On 6/30/2015 9:22 AM, Bill Burke wrote: > > On 6/30/2015 8:23 AM, Stan Silvert wrote: >> On 6/29/2015 8:34 PM, Bill Burke wrote: >>> On 6/29/2015 5:39 PM, Stan Silvert wrote: >>>> On 6/29/2015 5:26 PM, Bill Burke wrote: >>>>> We do need some way to listen at the adapter level for a logout event >>>>> sent by the auth server. Undertow and Tomcat and Jetty all have ways to >>>>> listen for session invalidation events I believe too. Not sure if the >>>>> servlet spec has something standard. >>>> Yes, the servlet spec has HttpSessionListener with a sessionDestroyed() >>>> callback. >>>> >>>> We could come up with some javascript that you put on the client side >>>> that registers with the adapter and gets notified of session >>>> invalidation. I'm just wondering if it's something we should provide or >>>> not. >>> Javascript adapter already checks for logout. >>> >> What would you suggest for apps that use the other adapters? > They should use regular servlet means to timeout the session. > That's not what I'm asking about. I'm asking if we should provide a standard callback to the client when the timeout occurs. The client wants to provide a notification to the user about the session timeout. Right now, it is up to each application to build their own infrastructure for doing that. But we could provide an out of the box solution that works for the entire realm. What we would need is a standard way for the client to register a callback with our adapters. Or it could register the callback with the Keycloak server. (Or a heartbeat instead of a callback. There are many ways to do this.) The main point is that Keycloak could provide a realm-wide solution. That's what the customer is wanting. From bburke at redhat.com Tue Jun 30 13:42:41 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 30 Jun 2015 13:42:41 -0400 Subject: [keycloak-dev] Idle timeout notificaion In-Reply-To: <5592AF24.4040403@redhat.com> References: <5591AC0F.70102@redhat.com> <5591B7F9.6020700@redhat.com> <5591BB0C.5030209@redhat.com> <5591E431.8050802@redhat.com> <55928A5F.2070001@redhat.com> <5592981F.4040309@redhat.com> <5592AF24.4040403@redhat.com> Message-ID: <5592D511.9050901@redhat.com> On 6/30/2015 11:00 AM, Stan Silvert wrote: > On 6/30/2015 9:22 AM, Bill Burke wrote: >> >> On 6/30/2015 8:23 AM, Stan Silvert wrote: >>> On 6/29/2015 8:34 PM, Bill Burke wrote: >>>> On 6/29/2015 5:39 PM, Stan Silvert wrote: >>>>> On 6/29/2015 5:26 PM, Bill Burke wrote: >>>>>> We do need some way to listen at the adapter level for a logout event >>>>>> sent by the auth server. Undertow and Tomcat and Jetty all have ways to >>>>>> listen for session invalidation events I believe too. Not sure if the >>>>>> servlet spec has something standard. >>>>> Yes, the servlet spec has HttpSessionListener with a sessionDestroyed() >>>>> callback. >>>>> >>>>> We could come up with some javascript that you put on the client side >>>>> that registers with the adapter and gets notified of session >>>>> invalidation. I'm just wondering if it's something we should provide or >>>>> not. >>>> Javascript adapter already checks for logout. >>>> >>> What would you suggest for apps that use the other adapters? >> They should use regular servlet means to timeout the session. >> > That's not what I'm asking about. I'm asking if we should provide a > standard callback to the client when the timeout occurs. > > The client wants to provide a notification to the user about the session > timeout. Right now, it is up to each application to build their own > infrastructure for doing that. For a servlet app, this "infrastructure" already exists. As you said before, you can set up an HttpSessionListener. For a javascript app, our javascript adapter already handles this. > But we could provide an out of the box > solution that works for the entire realm. What we would need is a > standard way for the client to register a callback with our adapters. > Or it could register the callback with the Keycloak server. (Or a > heartbeat instead of a callback. There are many ways to do this.) > > The main point is that Keycloak could provide a realm-wide solution. > That's what the customer is wanting. Our background session expiration task currently just wipes away the sessions in Keycloak server. If it was changed to performing a backchannel logout, then the adapters would always get notified and again, the app developer can just implement an HttpSessionListener. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From ssilvert at redhat.com Tue Jun 30 14:10:00 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 30 Jun 2015 14:10:00 -0400 Subject: [keycloak-dev] Idle timeout notificaion In-Reply-To: <5592D511.9050901@redhat.com> References: <5591AC0F.70102@redhat.com> <5591B7F9.6020700@redhat.com> <5591BB0C.5030209@redhat.com> <5591E431.8050802@redhat.com> <55928A5F.2070001@redhat.com> <5592981F.4040309@redhat.com> <5592AF24.4040403@redhat.com> <5592D511.9050901@redhat.com> Message-ID: <5592DB78.7050806@redhat.com> On 6/30/2015 1:42 PM, Bill Burke wrote: > > On 6/30/2015 11:00 AM, Stan Silvert wrote: >> On 6/30/2015 9:22 AM, Bill Burke wrote: >>> On 6/30/2015 8:23 AM, Stan Silvert wrote: >>>> On 6/29/2015 8:34 PM, Bill Burke wrote: >>>>> On 6/29/2015 5:39 PM, Stan Silvert wrote: >>>>>> On 6/29/2015 5:26 PM, Bill Burke wrote: >>>>>>> We do need some way to listen at the adapter level for a logout event >>>>>>> sent by the auth server. Undertow and Tomcat and Jetty all have ways to >>>>>>> listen for session invalidation events I believe too. Not sure if the >>>>>>> servlet spec has something standard. >>>>>> Yes, the servlet spec has HttpSessionListener with a sessionDestroyed() >>>>>> callback. >>>>>> >>>>>> We could come up with some javascript that you put on the client side >>>>>> that registers with the adapter and gets notified of session >>>>>> invalidation. I'm just wondering if it's something we should provide or >>>>>> not. >>>>> Javascript adapter already checks for logout. >>>>> >>>> What would you suggest for apps that use the other adapters? >>> They should use regular servlet means to timeout the session. >>> >> That's not what I'm asking about. I'm asking if we should provide a >> standard callback to the client when the timeout occurs. >> >> The client wants to provide a notification to the user about the session >> timeout. Right now, it is up to each application to build their own >> infrastructure for doing that. > For a servlet app, this "infrastructure" already exists. As you said > before, you can set up an HttpSessionListener. For a javascript app, > our javascript adapter already handles this. And how does the user get notified? > >> But we could provide an out of the box >> solution that works for the entire realm. What we would need is a >> standard way for the client to register a callback with our adapters. >> Or it could register the callback with the Keycloak server. (Or a >> heartbeat instead of a callback. There are many ways to do this.) >> >> The main point is that Keycloak could provide a realm-wide solution. >> That's what the customer is wanting. > Our background session expiration task currently just wipes away the > sessions in Keycloak server. If it was changed to performing a > backchannel logout, then the adapters would always get notified and > again, the app developer can just implement an HttpSessionListener. > > > From bburke at redhat.com Tue Jun 30 14:25:47 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 30 Jun 2015 14:25:47 -0400 Subject: [keycloak-dev] Idle timeout notificaion In-Reply-To: <5592DB78.7050806@redhat.com> References: <5591AC0F.70102@redhat.com> <5591B7F9.6020700@redhat.com> <5591BB0C.5030209@redhat.com> <5591E431.8050802@redhat.com> <55928A5F.2070001@redhat.com> <5592981F.4040309@redhat.com> <5592AF24.4040403@redhat.com> <5592D511.9050901@redhat.com> <5592DB78.7050806@redhat.com> Message-ID: <5592DF2B.6020801@redhat.com> On 6/30/2015 2:10 PM, Stan Silvert wrote: > And how does the user get notified? What do you expect to happen here? With a servlet app there is no notification from the server to the user. There is no "push" in traditional servlet apps. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From ssilvert at redhat.com Tue Jun 30 14:33:01 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 30 Jun 2015 14:33:01 -0400 Subject: [keycloak-dev] Idle timeout notificaion In-Reply-To: <5592DF2B.6020801@redhat.com> References: <5591AC0F.70102@redhat.com> <5591B7F9.6020700@redhat.com> <5591BB0C.5030209@redhat.com> <5591E431.8050802@redhat.com> <55928A5F.2070001@redhat.com> <5592981F.4040309@redhat.com> <5592AF24.4040403@redhat.com> <5592D511.9050901@redhat.com> <5592DB78.7050806@redhat.com> <5592DF2B.6020801@redhat.com> Message-ID: <5592E0DD.7060105@redhat.com> On 6/30/2015 2:25 PM, Bill Burke wrote: > > On 6/30/2015 2:10 PM, Stan Silvert wrote: >> And how does the user get notified? > What do you expect to happen here? With a servlet app there is no > notification from the server to the user. There is no "push" in > traditional servlet apps. > The requirement is that for any application in the realm, the user will be notified if the session has timed out. This is a pretty common requirement, even with servlet apps. I don't know if this must be implemented as a push notification. Polling would work too. The customer feels like this is something Keycloak should provide. From bburke at redhat.com Tue Jun 30 18:26:52 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 30 Jun 2015 18:26:52 -0400 Subject: [keycloak-dev] Idle timeout notificaion In-Reply-To: <5592E0DD.7060105@redhat.com> References: <5591AC0F.70102@redhat.com> <5591B7F9.6020700@redhat.com> <5591BB0C.5030209@redhat.com> <5591E431.8050802@redhat.com> <55928A5F.2070001@redhat.com> <5592981F.4040309@redhat.com> <5592AF24.4040403@redhat.com> <5592D511.9050901@redhat.com> <5592DB78.7050806@redhat.com> <5592DF2B.6020801@redhat.com> <5592E0DD.7060105@redhat.com> Message-ID: <559317AC.5000101@redhat.com> On 6/30/2015 2:33 PM, Stan Silvert wrote: > On 6/30/2015 2:25 PM, Bill Burke wrote: >> >> On 6/30/2015 2:10 PM, Stan Silvert wrote: >>> And how does the user get notified? >> What do you expect to happen here? With a servlet app there is no >> notification from the server to the user. There is no "push" in >> traditional servlet apps. >> > The requirement is that for any application in the realm, the user will > be notified if the session has timed out. This is a pretty common > requirement, even with servlet apps. > Again, you expect this to work? If the "user" is a browser, there is no way to notify them other than the iframe + javascript trick that is provided by OpenID Connect and provided support for keycloak.js -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Tue Jun 30 18:31:12 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 30 Jun 2015 18:31:12 -0400 Subject: [keycloak-dev] Idle timeout notificaion In-Reply-To: <559317AC.5000101@redhat.com> References: <5591AC0F.70102@redhat.com> <5591B7F9.6020700@redhat.com> <5591BB0C.5030209@redhat.com> <5591E431.8050802@redhat.com> <55928A5F.2070001@redhat.com> <5592981F.4040309@redhat.com> <5592AF24.4040403@redhat.com> <5592D511.9050901@redhat.com> <5592DB78.7050806@redhat.com> <5592DF2B.6020801@redhat.com> <5592E0DD.7060105@redhat.com> <559317AC.5000101@redhat.com> Message-ID: <559318B0.1090007@redhat.com> On 6/30/2015 6:26 PM, Bill Burke wrote: > Again, you expect this to work? If the "user" is a browser, there is no > way to notify them other than the iframe + javascript trick that is > provided by OpenID Connect and provided support for keycloak.js Sorry, I mistyped: Again, *how* do you expect this to work? If the "user" is a browser, there is no way to notify them other than the iframe + javascript trick that is provided by OpenID Connect and provided support for keycloak.js -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com