From bburke at redhat.com Mon Dec 2 22:32:41 2013 From: bburke at redhat.com (Bill Burke) Date: Mon, 02 Dec 2013 22:32:41 -0500 Subject: [keycloak-dev] Keycloak presentation and demo screencast Message-ID: <529D50D9.2060809@redhat.com> I put together a screencast presentation and demo of Keycloak. I'm using free screencast software so the presentation comes in two parts: part 1: http://www.youtube.com/watch?v=B-qIkB9lsLs&feature=youtu.be&hd=1 part 2: http://www.youtube.com/watch?v=QgWgUg5F_JQ&feature=youtu.be&hd=1 Also, I'm not the best presenter in the world, but I think this is good enough for now. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From theute at redhat.com Tue Dec 3 05:24:52 2013 From: theute at redhat.com (Thomas Heute) Date: Tue, 03 Dec 2013 11:24:52 +0100 Subject: [keycloak-dev] Keycloak presentation and demo screencast In-Reply-To: <529D50D9.2060809@redhat.com> References: <529D50D9.2060809@redhat.com> Message-ID: <529DB174.5060909@redhat.com> Only watched the part 1, but very cool :) Well done team KC ! On 12/03/2013 04:32 AM, Bill Burke wrote: > I put together a screencast presentation and demo of Keycloak. I'm > using free screencast software so the presentation comes in two parts: > > part 1: > > http://www.youtube.com/watch?v=B-qIkB9lsLs&feature=youtu.be&hd=1 > > part 2: > > http://www.youtube.com/watch?v=QgWgUg5F_JQ&feature=youtu.be&hd=1 > > Also, I'm not the best presenter in the world, but I think this is good > enough for now. > From stian at redhat.com Tue Dec 3 08:13:32 2013 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 3 Dec 2013 08:13:32 -0500 (EST) Subject: [keycloak-dev] Configure password policy for realm In-Reply-To: <1620348350.22426818.1386076007053.JavaMail.root@redhat.com> Message-ID: <629287105.22432040.1386076412238.JavaMail.root@redhat.com> I've added an option to configure a password policy for a realm. The password policy is defined as a single string, for example: "length and digits and lowerCase and upperCase" Would require a password of minimum length 8 that contains at least one numerical digit, one lower case and one upper case. The available policies at the moment are: * length * digits * lowerCase * upperCase * specialChars All take an optional single integer argument, for example: "length(12) and specialChars(2)" Would require a password of minimum length 12 that contains at least 2 special characters. The only operator supported (at least at the moment) is 'and', so you couldn't for example have a policy that is: "length(24) or ( length(12) and specialChars(4) )" This is just something minimal for M1 and we can tweak it later. One thing that is quite common is to make sure it doesn't contain words from the dictionary for example. Villiam is working on improving the way it's defined in the admin console to make it more user friendly (and less error prone). From bburke at redhat.com Tue Dec 3 15:50:33 2013 From: bburke at redhat.com (Bill Burke) Date: Tue, 03 Dec 2013 15:50:33 -0500 Subject: [keycloak-dev] Configure password policy for realm In-Reply-To: <629287105.22432040.1386076412238.JavaMail.root@redhat.com> References: <629287105.22432040.1386076412238.JavaMail.root@redhat.com> Message-ID: <529E4419.7080207@redhat.com> Very nice. On 12/3/2013 8:13 AM, Stian Thorgersen wrote: > I've added an option to configure a password policy for a realm. > > The password policy is defined as a single string, for example: > > "length and digits and lowerCase and upperCase" > > Would require a password of minimum length 8 that contains at least one numerical digit, one lower case and one upper case. > > The available policies at the moment are: > > * length > * digits > * lowerCase > * upperCase > * specialChars > > All take an optional single integer argument, for example: > > "length(12) and specialChars(2)" > > Would require a password of minimum length 12 that contains at least 2 special characters. > > The only operator supported (at least at the moment) is 'and', so you couldn't for example have a policy that is: > > "length(24) or ( length(12) and specialChars(4) )" > > This is just something minimal for M1 and we can tweak it later. One thing that is quite common is to make sure it doesn't contain words from the dictionary for example. > > Villiam is working on improving the way it's defined in the admin console to make it more user friendly (and less error prone). > _______________________________________________ > 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 Dec 4 13:15:09 2013 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 4 Dec 2013 13:15:09 -0500 (EST) Subject: [keycloak-dev] M1 progress In-Reply-To: <1604932421.23526407.1386180461838.JavaMail.root@redhat.com> Message-ID: <1752553959.23530224.1386180909783.JavaMail.root@redhat.com> Keycloak is looking pretty good now, and it looks like we're in good shape to release M1 this week. One thing I don't like is the realms being looked up based on a generated id. I really don't like urls being '../realms/32450982309/tokens/..' instead of '../realms/myrealm/tokens/..'. We can easily fix this by letting users set the id in the admin console. We should also display the id throughout as well as the name. If there's no objections I'll sort this out tomorrow. From bburke at redhat.com Wed Dec 4 14:45:26 2013 From: bburke at redhat.com (Bill Burke) Date: Wed, 04 Dec 2013 14:45:26 -0500 Subject: [keycloak-dev] M1 progress In-Reply-To: <1752553959.23530224.1386180909783.JavaMail.root@redhat.com> References: <1752553959.23530224.1386180909783.JavaMail.root@redhat.com> Message-ID: <529F8656.7030406@redhat.com> Being able to change an ID is not a good idea. DB constraints et. al. -1. Let's keep realm Name and ID in the data model, but just set the ID to be the name on creating. But only for realms, not anything else please. It should be possible to have same app names in different realms. On 12/4/2013 1:15 PM, Stian Thorgersen wrote: > Keycloak is looking pretty good now, and it looks like we're in good shape to release M1 this week. > > One thing I don't like is the realms being looked up based on a generated id. I really don't like urls being '../realms/32450982309/tokens/..' instead of '../realms/myrealm/tokens/..'. We can easily fix this by letting users set the id in the admin console. We should also display the id throughout as well as the name. If there's no objections I'll sort this out tomorrow. > _______________________________________________ > 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 bburke at redhat.com Wed Dec 4 14:51:39 2013 From: bburke at redhat.com (Bill Burke) Date: Wed, 04 Dec 2013 14:51:39 -0500 Subject: [keycloak-dev] working on distro and docs Message-ID: <529F87CB.7030101@redhat.com> I'll be putting together docs today and tomorrow. IN parallel i'll flesh out the distro more, which will probably uncover a bunch of other things we haven't thought of. Its ok if we're not perfect just as long as people don't have problems installing and running the demo. This *WILL* be an ALPHA release. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Wed Dec 4 14:52:51 2013 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 4 Dec 2013 14:52:51 -0500 (EST) Subject: [keycloak-dev] M1 progress In-Reply-To: <529F8656.7030406@redhat.com> References: <1752553959.23530224.1386180909783.JavaMail.root@redhat.com> <529F8656.7030406@redhat.com> Message-ID: <1492816304.23604391.1386186771626.JavaMail.root@redhat.com> I agree what you're proposing is better - I'll do it that way.. What's your thoughts on M1? Can we release to Maven on Friday? Nice vid's btw :) ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Wednesday, 4 December, 2013 7:45:26 PM > Subject: Re: [keycloak-dev] M1 progress > > Being able to change an ID is not a good idea. DB constraints et. al. > -1. > > Let's keep realm Name and ID in the data model, but just set the ID to > be the name on creating. But only for realms, not anything else please. > It should be possible to have same app names in different realms. > > > On 12/4/2013 1:15 PM, Stian Thorgersen wrote: > > Keycloak is looking pretty good now, and it looks like we're in good shape > > to release M1 this week. > > > > One thing I don't like is the realms being looked up based on a generated > > id. I really don't like urls being '../realms/32450982309/tokens/..' > > instead of '../realms/myrealm/tokens/..'. We can easily fix this by > > letting users set the id in the admin console. We should also display the > > id throughout as well as the name. If there's no objections I'll sort this > > out tomorrow. > > _______________________________________________ > > 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 bburke at redhat.com Wed Dec 4 14:54:48 2013 From: bburke at redhat.com (Bill Burke) Date: Wed, 04 Dec 2013 14:54:48 -0500 Subject: [keycloak-dev] M1 progress In-Reply-To: <1492816304.23604391.1386186771626.JavaMail.root@redhat.com> References: <1752553959.23530224.1386180909783.JavaMail.root@redhat.com> <529F8656.7030406@redhat.com> <1492816304.23604391.1386186771626.JavaMail.root@redhat.com> Message-ID: <529F8888.2070302@redhat.com> I don't know. There still may be a lot of issues around the distro that need to be fixed. I often discover how crappy things are when I document things. On 12/4/2013 2:52 PM, Stian Thorgersen wrote: > I agree what you're proposing is better - I'll do it that way.. > > What's your thoughts on M1? Can we release to Maven on Friday? > > Nice vid's btw :) > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Wednesday, 4 December, 2013 7:45:26 PM >> Subject: Re: [keycloak-dev] M1 progress >> >> Being able to change an ID is not a good idea. DB constraints et. al. >> -1. >> >> Let's keep realm Name and ID in the data model, but just set the ID to >> be the name on creating. But only for realms, not anything else please. >> It should be possible to have same app names in different realms. >> >> >> On 12/4/2013 1:15 PM, Stian Thorgersen wrote: >>> Keycloak is looking pretty good now, and it looks like we're in good shape >>> to release M1 this week. >>> >>> One thing I don't like is the realms being looked up based on a generated >>> id. I really don't like urls being '../realms/32450982309/tokens/..' >>> instead of '../realms/myrealm/tokens/..'. We can easily fix this by >>> letting users set the id in the admin console. We should also display the >>> id throughout as well as the name. If there's no objections I'll sort this >>> out tomorrow. >>> _______________________________________________ >>> 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 >> -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Wed Dec 4 15:14:14 2013 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 4 Dec 2013 15:14:14 -0500 (EST) Subject: [keycloak-dev] M1 progress In-Reply-To: <529F8888.2070302@redhat.com> References: <1752553959.23530224.1386180909783.JavaMail.root@redhat.com> <529F8656.7030406@redhat.com> <1492816304.23604391.1386186771626.JavaMail.root@redhat.com> <529F8888.2070302@redhat.com> Message-ID: <1067790055.23618995.1386188054745.JavaMail.root@redhat.com> Ok - if you find crap just let me know, I'm fairly good with a shovel ;) I'd like it in Nexus on Friday though, it doesn't have to be M1, a timestamp would do. ----- Original Message ----- > From: "Bill Burke" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Wednesday, 4 December, 2013 7:54:48 PM > Subject: Re: [keycloak-dev] M1 progress > > I don't know. There still may be a lot of issues around the distro that > need to be fixed. I often discover how crappy things are when I > document things. > > On 12/4/2013 2:52 PM, Stian Thorgersen wrote: > > I agree what you're proposing is better - I'll do it that way.. > > > > What's your thoughts on M1? Can we release to Maven on Friday? > > > > Nice vid's btw :) > > > > ----- Original Message ----- > >> From: "Bill Burke" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Wednesday, 4 December, 2013 7:45:26 PM > >> Subject: Re: [keycloak-dev] M1 progress > >> > >> Being able to change an ID is not a good idea. DB constraints et. al. > >> -1. > >> > >> Let's keep realm Name and ID in the data model, but just set the ID to > >> be the name on creating. But only for realms, not anything else please. > >> It should be possible to have same app names in different realms. > >> > >> > >> On 12/4/2013 1:15 PM, Stian Thorgersen wrote: > >>> Keycloak is looking pretty good now, and it looks like we're in good > >>> shape > >>> to release M1 this week. > >>> > >>> One thing I don't like is the realms being looked up based on a generated > >>> id. I really don't like urls being '../realms/32450982309/tokens/..' > >>> instead of '../realms/myrealm/tokens/..'. We can easily fix this by > >>> letting users set the id in the admin console. We should also display the > >>> id throughout as well as the name. If there's no objections I'll sort > >>> this > >>> out tomorrow. > >>> _______________________________________________ > >>> 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 > >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > From stian at redhat.com Thu Dec 5 06:40:38 2013 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 5 Dec 2013 06:40:38 -0500 (EST) Subject: [keycloak-dev] View all users for a realm In-Reply-To: <467555287.24120956.1386243532534.JavaMail.root@redhat.com> Message-ID: <873497915.24121368.1386243638270.JavaMail.root@redhat.com> ATM it's only possible to search for users. It should be possible to also view all users for a realm. I propose that we make the users page show all users when there's no search set. In the future this and all other tables should support pagination, including pagination support on the rest endpoints, so that would solve the issue of loading a huge amount of users. From ssilvert at redhat.com Thu Dec 5 11:25:24 2013 From: ssilvert at redhat.com (ssilvert at redhat.com) Date: Thu, 05 Dec 2013 11:25:24 -0500 Subject: [keycloak-dev] Getting demo to run Message-ID: <52A0A8F4.7050507@redhat.com> I'm trying to get the demo to run on WildFly master. I ran into a compilation problem and submitted this PR so it would compile: https://github.com/keycloak/keycloak/pull/122 Now it builds OK, but when I do mvn jboss-as:deploy, I get the errors below on WildFly. Is this what I should be doing to get started? Should I be trying this on EAP 6 instead? 11:22:17,891 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./auth-se rver.UndertowDeploymentInfoService: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentI nfoService: java.lang.ClassNotFoundException: org.keycloak.services.listeners.MongoRunnerListener from [Module "deployment.auth-server.war:main" from Service Module Loade r] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:772) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:217) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15] at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15] Caused by: java.lang.ClassNotFoundException: org.keycloak.services.listeners.MongoRunnerListener from [Module "deployment.auth-server.war:main" from Service Module Loader ] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197) [jboss-modules.jar:1.3.0.Final] at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) [jboss-modules.jar:1.3.0.Final] at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) [jboss-modules.jar:1.3.0.Final] at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) [jboss-modules.jar:1.3.0.Final] at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) [jboss-modules.jar:1.3.0.Final] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.addListener(UndertowDeploymentInfoService.java:1035) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:640) ... 6 more 11:22:17,936 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 5) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "a uth-server.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoSer vice" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService: java.lang.Clas sNotFoundException: org.keycloak.services.listeners.MongoRunnerListener from [Module \"deployment.auth-server.war:main\" from Service Module Loader] Caused by: java.lang.ClassNotFoundException: org.keycloak.services.listeners.MongoRunnerListener from [Module \"deployment.auth-server.war:main\" from Service Module Loader]"}} 11:22:17,946 ERROR [org.jboss.as.server] (management-handler-thread - 5) JBAS015870: Deploy of deployment "auth-server.war" was rolled back with the following failure mes sage: {"JBAS014671: Failed services" => {"jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService" => "org.jboss.msc.service.StartExcep tion in service jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService: java.lang.ClassNotFoundException: org.keycloak.services. listeners.MongoRunnerListener from [Module \"deployment.auth-server.war:main\" from Service Module Loader] Caused by: java.lang.ClassNotFoundException: org.keycloak.services.listeners.MongoRunnerListener from [Module \"deployment.auth-server.war:main\" from Service Module Loader]"}} From gcardoso at redhat.com Thu Dec 5 11:34:34 2013 From: gcardoso at redhat.com (Gabriel Cardoso) Date: Thu, 5 Dec 2013 14:34:34 -0200 Subject: [keycloak-dev] View all users for a realm In-Reply-To: <873497915.24121368.1386243638270.JavaMail.root@redhat.com> References: <873497915.24121368.1386243638270.JavaMail.root@redhat.com> Message-ID: <8533AE6D-C059-47A9-9F88-F57C760CB082@redhat.com> This is much better from the usability perspective. The way it is, the admin creates an user and does not see him listed in the table. This may lead him to try to create the same user again ;) Gabriel On Dec 5, 2013, at 9:40 AM, Stian Thorgersen wrote: > ATM it's only possible to search for users. It should be possible to also view all users for a realm. > > I propose that we make the users page show all users when there's no search set. In the future this and all other tables should support pagination, including pagination support on the rest endpoints, so that would solve the issue of loading a huge amount of users. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Gabriel Cardoso GateIn Portal | User Experience Designer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20131205/5b6a0b3e/attachment.html From gcardoso at redhat.com Thu Dec 5 11:51:24 2013 From: gcardoso at redhat.com (Gabriel Cardoso) Date: Thu, 5 Dec 2013 14:51:24 -0200 Subject: [keycloak-dev] M1 progress In-Reply-To: <1067790055.23618995.1386188054745.JavaMail.root@redhat.com> References: <1752553959.23530224.1386180909783.JavaMail.root@redhat.com> <529F8656.7030406@redhat.com> <1492816304.23604391.1386186771626.JavaMail.root@redhat.com> <529F8888.2070302@redhat.com> <1067790055.23618995.1386188054745.JavaMail.root@redhat.com> Message-ID: <3216BFE0-1C1A-4606-BDF0-03292D60D8A7@redhat.com> I've just checked with Matt Carrano (from the RCUE team) if we could launch Keycloak with the RCUE layout and he told us to go ahead with this :) He just mentioned that there might be some licensing requirements around the incorporation of Bootstrap. Do you guys know if we need to do something? It is an Apache license. Gabriel On Dec 4, 2013, at 6:14 PM, Stian Thorgersen wrote: > Ok - if you find crap just let me know, I'm fairly good with a shovel ;) > > I'd like it in Nexus on Friday though, it doesn't have to be M1, a timestamp would do. > > ----- Original Message ----- >> From: "Bill Burke" >> To: "Stian Thorgersen" >> Cc: keycloak-dev at lists.jboss.org >> Sent: Wednesday, 4 December, 2013 7:54:48 PM >> Subject: Re: [keycloak-dev] M1 progress >> >> I don't know. There still may be a lot of issues around the distro that >> need to be fixed. I often discover how crappy things are when I >> document things. >> >> On 12/4/2013 2:52 PM, Stian Thorgersen wrote: >>> I agree what you're proposing is better - I'll do it that way.. >>> >>> What's your thoughts on M1? Can we release to Maven on Friday? >>> >>> Nice vid's btw :) >>> >>> ----- Original Message ----- >>>> From: "Bill Burke" >>>> To: keycloak-dev at lists.jboss.org >>>> Sent: Wednesday, 4 December, 2013 7:45:26 PM >>>> Subject: Re: [keycloak-dev] M1 progress >>>> >>>> Being able to change an ID is not a good idea. DB constraints et. al. >>>> -1. >>>> >>>> Let's keep realm Name and ID in the data model, but just set the ID to >>>> be the name on creating. But only for realms, not anything else please. >>>> It should be possible to have same app names in different realms. >>>> >>>> >>>> On 12/4/2013 1:15 PM, Stian Thorgersen wrote: >>>>> Keycloak is looking pretty good now, and it looks like we're in good >>>>> shape >>>>> to release M1 this week. >>>>> >>>>> One thing I don't like is the realms being looked up based on a generated >>>>> id. I really don't like urls being '../realms/32450982309/tokens/..' >>>>> instead of '../realms/myrealm/tokens/..'. We can easily fix this by >>>>> letting users set the id in the admin console. We should also display the >>>>> id throughout as well as the name. If there's no objections I'll sort >>>>> this >>>>> out tomorrow. >>>>> _______________________________________________ >>>>> 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 >>>> >> >> -- >> 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 -- Gabriel Cardoso GateIn Portal | User Experience Designer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20131205/09955873/attachment-0001.html From gcardoso at redhat.com Thu Dec 5 12:11:56 2013 From: gcardoso at redhat.com (Gabriel Cardoso) Date: Thu, 5 Dec 2013 15:11:56 -0200 Subject: [keycloak-dev] Keycloak presentation and demo screencast In-Reply-To: <529DB174.5060909@redhat.com> References: <529D50D9.2060809@redhat.com> <529DB174.5060909@redhat.com> Message-ID: Bill, I think you presented well. Is quite explanatory and you speak into a good rhythm :) Well done! On Dec 3, 2013, at 8:24 AM, Thomas Heute wrote: > Only watched the part 1, but very cool :) Well done team KC ! > > On 12/03/2013 04:32 AM, Bill Burke wrote: >> I put together a screencast presentation and demo of Keycloak. I'm >> using free screencast software so the presentation comes in two parts: >> >> part 1: >> >> http://www.youtube.com/watch?v=B-qIkB9lsLs&feature=youtu.be&hd=1 >> >> part 2: >> >> http://www.youtube.com/watch?v=QgWgUg5F_JQ&feature=youtu.be&hd=1 >> >> Also, I'm not the best presenter in the world, but I think this is good >> enough for now. >> > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Gabriel Cardoso GateIn Portal | User Experience Designer From gcardoso at redhat.com Thu Dec 5 12:15:12 2013 From: gcardoso at redhat.com (Gabriel Cardoso) Date: Thu, 5 Dec 2013 15:15:12 -0200 Subject: [keycloak-dev] Configure password policy for realm In-Reply-To: <629287105.22432040.1386076412238.JavaMail.root@redhat.com> References: <629287105.22432040.1386076412238.JavaMail.root@redhat.com> Message-ID: > Villiam is working on improving the way it's defined in the admin console to make it more user friendly (and less error prone). Good idea :) -- Gabriel Cardoso GateIn Portal | User Experience Designer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20131205/c9dda150/attachment.html From mposolda at redhat.com Thu Dec 5 12:15:30 2013 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 05 Dec 2013 18:15:30 +0100 Subject: [keycloak-dev] Keycloak presentation and demo screencast In-Reply-To: References: <529D50D9.2060809@redhat.com> <529DB174.5060909@redhat.com> Message-ID: <52A0B4B2.2030807@redhat.com> +1 On 5.12.2013 18:11, Gabriel Cardoso wrote: > Bill, I think you presented well. Is quite explanatory and you speak into a good rhythm :) > > Well done! > > On Dec 3, 2013, at 8:24 AM, Thomas Heute wrote: > >> Only watched the part 1, but very cool :) Well done team KC ! >> >> On 12/03/2013 04:32 AM, Bill Burke wrote: >>> I put together a screencast presentation and demo of Keycloak. I'm >>> using free screencast software so the presentation comes in two parts: >>> >>> part 1: >>> >>> http://www.youtube.com/watch?v=B-qIkB9lsLs&feature=youtu.be&hd=1 >>> >>> part 2: >>> >>> http://www.youtube.com/watch?v=QgWgUg5F_JQ&feature=youtu.be&hd=1 >>> >>> Also, I'm not the best presenter in the world, but I think this is good >>> enough for now. >>> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -- > Gabriel Cardoso > GateIn Portal | User Experience Designer > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Thu Dec 5 12:30:12 2013 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 05 Dec 2013 18:30:12 +0100 Subject: [keycloak-dev] Getting demo to run In-Reply-To: <52A0A8F4.7050507@redhat.com> References: <52A0A8F4.7050507@redhat.com> Message-ID: <52A0B824.7080901@redhat.com> Hi, I think that you can simply comment MongoRunnerListener in this file https://github.com/keycloak/keycloak/blob/master/examples/wildfly-demo/server/src/main/webapp/WEB-INF/web.xml as Mongo based model is not used actually. Keycloak is actually using JPA model by default. Marek On 5.12.2013 17:25, ssilvert at redhat.com wrote: > I'm trying to get the demo to run on WildFly master. I ran into a > compilation problem and submitted this PR so it would compile: > https://github.com/keycloak/keycloak/pull/122 > > Now it builds OK, but when I do mvn jboss-as:deploy, I get the errors > below on WildFly. Is this what I should be doing to get started? > Should I be trying this on EAP 6 instead? > > 11:22:17,891 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) > MSC000001: Failed to start service > jboss.undertow.deployment.default-server.default-host./auth-se > rver.UndertowDeploymentInfoService: org.jboss.msc.service.StartException > in service > jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentI > nfoService: java.lang.ClassNotFoundException: > org.keycloak.services.listeners.MongoRunnerListener from [Module > "deployment.auth-server.war:main" from Service Module Loade > r] > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:772) > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:217) > at > org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1] > at > org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > [rt.jar:1.7.0_15] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > [rt.jar:1.7.0_15] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15] > Caused by: java.lang.ClassNotFoundException: > org.keycloak.services.listeners.MongoRunnerListener from [Module > "deployment.auth-server.war:main" from Service Module Loader > ] > at > org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197) [jboss-modules.jar:1.3.0.Final] > at > org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) > [jboss-modules.jar:1.3.0.Final] > at > org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) > [jboss-modules.jar:1.3.0.Final] > at > org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) > [jboss-modules.jar:1.3.0.Final] > at > org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) > [jboss-modules.jar:1.3.0.Final] > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.addListener(UndertowDeploymentInfoService.java:1035) > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:640) > ... 6 more > > 11:22:17,936 ERROR [org.jboss.as.controller.management-operation] > (management-handler-thread - 5) JBAS014613: Operation ("deploy") failed > - address: ([("deployment" => "a > uth-server.war")]) - failure description: {"JBAS014671: Failed services" > => > {"jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoSer > vice" => "org.jboss.msc.service.StartException in service > jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService: > java.lang.Clas > sNotFoundException: org.keycloak.services.listeners.MongoRunnerListener > from [Module \"deployment.auth-server.war:main\" from Service Module Loader] > Caused by: java.lang.ClassNotFoundException: > org.keycloak.services.listeners.MongoRunnerListener from [Module > \"deployment.auth-server.war:main\" from Service Module > Loader]"}} > 11:22:17,946 ERROR [org.jboss.as.server] (management-handler-thread - 5) > JBAS015870: Deploy of deployment "auth-server.war" was rolled back with > the following failure mes > sage: > {"JBAS014671: Failed services" => > {"jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService" > => "org.jboss.msc.service.StartExcep > tion in service > jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService: > java.lang.ClassNotFoundException: org.keycloak.services. > listeners.MongoRunnerListener from [Module > \"deployment.auth-server.war:main\" from Service Module Loader] > Caused by: java.lang.ClassNotFoundException: > org.keycloak.services.listeners.MongoRunnerListener from [Module > \"deployment.auth-server.war:main\" from Service Module > Loader]"}} > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Thu Dec 5 12:32:45 2013 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 05 Dec 2013 18:32:45 +0100 Subject: [keycloak-dev] Getting demo to run In-Reply-To: <52A0B824.7080901@redhat.com> References: <52A0A8F4.7050507@redhat.com> <52A0B824.7080901@redhat.com> Message-ID: <52A0B8BD.7030004@redhat.com> btw. I think that it would be better to run AS7 demo https://github.com/keycloak/keycloak/tree/master/examples/as7-eap-demo, which should work without issues on AS7/EAP6. You just need to patch resteasy to newest version as mentioned in README instructions. Marek On 5.12.2013 18:30, Marek Posolda wrote: > Hi, > > I think that you can simply comment MongoRunnerListener in this file > https://github.com/keycloak/keycloak/blob/master/examples/wildfly-demo/server/src/main/webapp/WEB-INF/web.xml > as Mongo based model is not used actually. Keycloak is actually using > JPA model by default. > > Marek > > On 5.12.2013 17:25, ssilvert at redhat.com wrote: >> I'm trying to get the demo to run on WildFly master. I ran into a >> compilation problem and submitted this PR so it would compile: >> https://github.com/keycloak/keycloak/pull/122 >> >> Now it builds OK, but when I do mvn jboss-as:deploy, I get the errors >> below on WildFly. Is this what I should be doing to get started? >> Should I be trying this on EAP 6 instead? >> >> 11:22:17,891 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) >> MSC000001: Failed to start service >> jboss.undertow.deployment.default-server.default-host./auth-se >> rver.UndertowDeploymentInfoService: org.jboss.msc.service.StartException >> in service >> jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentI >> nfoService: java.lang.ClassNotFoundException: >> org.keycloak.services.listeners.MongoRunnerListener from [Module >> "deployment.auth-server.war:main" from Service Module Loade >> r] >> at >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:772) >> at >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:217) >> at >> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) >> [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1] >> at >> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) >> [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1] >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >> [rt.jar:1.7.0_15] >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >> [rt.jar:1.7.0_15] >> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15] >> Caused by: java.lang.ClassNotFoundException: >> org.keycloak.services.listeners.MongoRunnerListener from [Module >> "deployment.auth-server.war:main" from Service Module Loader >> ] >> at >> org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197) [jboss-modules.jar:1.3.0.Final] >> at >> org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) >> [jboss-modules.jar:1.3.0.Final] >> at >> org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) >> [jboss-modules.jar:1.3.0.Final] >> at >> org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) >> [jboss-modules.jar:1.3.0.Final] >> at >> org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) >> [jboss-modules.jar:1.3.0.Final] >> at >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.addListener(UndertowDeploymentInfoService.java:1035) >> at >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:640) >> ... 6 more >> >> 11:22:17,936 ERROR [org.jboss.as.controller.management-operation] >> (management-handler-thread - 5) JBAS014613: Operation ("deploy") failed >> - address: ([("deployment" => "a >> uth-server.war")]) - failure description: {"JBAS014671: Failed services" >> => >> {"jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoSer >> vice" => "org.jboss.msc.service.StartException in service >> jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService: >> java.lang.Clas >> sNotFoundException: org.keycloak.services.listeners.MongoRunnerListener >> from [Module \"deployment.auth-server.war:main\" from Service Module Loader] >> Caused by: java.lang.ClassNotFoundException: >> org.keycloak.services.listeners.MongoRunnerListener from [Module >> \"deployment.auth-server.war:main\" from Service Module >> Loader]"}} >> 11:22:17,946 ERROR [org.jboss.as.server] (management-handler-thread - 5) >> JBAS015870: Deploy of deployment "auth-server.war" was rolled back with >> the following failure mes >> sage: >> {"JBAS014671: Failed services" => >> {"jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService" >> => "org.jboss.msc.service.StartExcep >> tion in service >> jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService: >> java.lang.ClassNotFoundException: org.keycloak.services. >> listeners.MongoRunnerListener from [Module >> \"deployment.auth-server.war:main\" from Service Module Loader] >> Caused by: java.lang.ClassNotFoundException: >> org.keycloak.services.listeners.MongoRunnerListener from [Module >> \"deployment.auth-server.war:main\" from Service Module >> Loader]"}} >> _______________________________________________ >> 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 Dec 5 12:55:06 2013 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 5 Dec 2013 12:55:06 -0500 (EST) Subject: [keycloak-dev] Getting demo to run In-Reply-To: <52A0A8F4.7050507@redhat.com> References: <52A0A8F4.7050507@redhat.com> Message-ID: <805662947.24727563.1386266106717.JavaMail.root@redhat.com> ATM WildFly isn't supported as we're having some issues with it. Hopefully once a new version of WildFly is released we can get it working. In the mean time, the easiest way to get it to run is to build the dist based on AS7: # mvn clean install -Prelease-as7 # dist-as7/target/keycloak-1.0-alpha-1/bin/standalone.sh Then open up http://localhost:8080/auth-server/admin/index.hml and login with admin/admin ----- Original Message ----- > From: ssilvert at redhat.com > To: keycloak-dev at lists.jboss.org > Sent: Thursday, 5 December, 2013 4:25:24 PM > Subject: [keycloak-dev] Getting demo to run > > I'm trying to get the demo to run on WildFly master. I ran into a > compilation problem and submitted this PR so it would compile: > https://github.com/keycloak/keycloak/pull/122 > > Now it builds OK, but when I do mvn jboss-as:deploy, I get the errors > below on WildFly. Is this what I should be doing to get started? > Should I be trying this on EAP 6 instead? > > 11:22:17,891 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) > MSC000001: Failed to start service > jboss.undertow.deployment.default-server.default-host./auth-se > rver.UndertowDeploymentInfoService: org.jboss.msc.service.StartException > in service > jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentI > nfoService: java.lang.ClassNotFoundException: > org.keycloak.services.listeners.MongoRunnerListener from [Module > "deployment.auth-server.war:main" from Service Module Loade > r] > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:772) > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:217) > at > org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1] > at > org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > [rt.jar:1.7.0_15] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > [rt.jar:1.7.0_15] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15] > Caused by: java.lang.ClassNotFoundException: > org.keycloak.services.listeners.MongoRunnerListener from [Module > "deployment.auth-server.war:main" from Service Module Loader > ] > at > org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197) > [jboss-modules.jar:1.3.0.Final] > at > org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) > [jboss-modules.jar:1.3.0.Final] > at > org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) > [jboss-modules.jar:1.3.0.Final] > at > org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) > [jboss-modules.jar:1.3.0.Final] > at > org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) > [jboss-modules.jar:1.3.0.Final] > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.addListener(UndertowDeploymentInfoService.java:1035) > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:640) > ... 6 more > > 11:22:17,936 ERROR [org.jboss.as.controller.management-operation] > (management-handler-thread - 5) JBAS014613: Operation ("deploy") failed > - address: ([("deployment" => "a > uth-server.war")]) - failure description: {"JBAS014671: Failed services" > => > {"jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoSer > vice" => "org.jboss.msc.service.StartException in service > jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService: > java.lang.Clas > sNotFoundException: org.keycloak.services.listeners.MongoRunnerListener > from [Module \"deployment.auth-server.war:main\" from Service Module Loader] > Caused by: java.lang.ClassNotFoundException: > org.keycloak.services.listeners.MongoRunnerListener from [Module > \"deployment.auth-server.war:main\" from Service Module > Loader]"}} > 11:22:17,946 ERROR [org.jboss.as.server] (management-handler-thread - 5) > JBAS015870: Deploy of deployment "auth-server.war" was rolled back with > the following failure mes > sage: > {"JBAS014671: Failed services" => > {"jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService" > => "org.jboss.msc.service.StartExcep > tion in service > jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService: > java.lang.ClassNotFoundException: org.keycloak.services. > listeners.MongoRunnerListener from [Module > \"deployment.auth-server.war:main\" from Service Module Loader] > Caused by: java.lang.ClassNotFoundException: > org.keycloak.services.listeners.MongoRunnerListener from [Module > \"deployment.auth-server.war:main\" from Service Module > Loader]"}} > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From ssilvert at redhat.com Thu Dec 5 13:13:16 2013 From: ssilvert at redhat.com (ssilvert at redhat.com) Date: Thu, 05 Dec 2013 13:13:16 -0500 Subject: [keycloak-dev] Getting demo to run In-Reply-To: <805662947.24727563.1386266106717.JavaMail.root@redhat.com> References: <52A0A8F4.7050507@redhat.com> <805662947.24727563.1386266106717.JavaMail.root@redhat.com> Message-ID: <52A0C23C.70902@redhat.com> On 12/5/2013 12:55 PM, Stian Thorgersen wrote: > ATM WildFly isn't supported as we're having some issues with it. Hopefully once a new version of WildFly is released we can get it working. What are the WildFly issues? Maybe I can help resolve them or at least find out when the issues will be fixed. If possible, I'd like Keycloak to stay in sync with WildFly because that is the platform I need to work on. I'm actually targeting WildFly 9. In the mean time, I'll try to get it running on EAP 6. > > In the mean time, the easiest way to get it to run is to build the dist based on AS7: > > # mvn clean install -Prelease-as7 > # dist-as7/target/keycloak-1.0-alpha-1/bin/standalone.sh > > Then open up http://localhost:8080/auth-server/admin/index.hml and login with admin/admin > > ----- Original Message ----- >> From: ssilvert at redhat.com >> To: keycloak-dev at lists.jboss.org >> Sent: Thursday, 5 December, 2013 4:25:24 PM >> Subject: [keycloak-dev] Getting demo to run >> >> I'm trying to get the demo to run on WildFly master. I ran into a >> compilation problem and submitted this PR so it would compile: >> https://github.com/keycloak/keycloak/pull/122 >> >> Now it builds OK, but when I do mvn jboss-as:deploy, I get the errors >> below on WildFly. Is this what I should be doing to get started? >> Should I be trying this on EAP 6 instead? >> >> 11:22:17,891 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) >> MSC000001: Failed to start service >> jboss.undertow.deployment.default-server.default-host./auth-se >> rver.UndertowDeploymentInfoService: org.jboss.msc.service.StartException >> in service >> jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentI >> nfoService: java.lang.ClassNotFoundException: >> org.keycloak.services.listeners.MongoRunnerListener from [Module >> "deployment.auth-server.war:main" from Service Module Loade >> r] >> at >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:772) >> at >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:217) >> at >> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) >> [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1] >> at >> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) >> [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1] >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >> [rt.jar:1.7.0_15] >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >> [rt.jar:1.7.0_15] >> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15] >> Caused by: java.lang.ClassNotFoundException: >> org.keycloak.services.listeners.MongoRunnerListener from [Module >> "deployment.auth-server.war:main" from Service Module Loader >> ] >> at >> org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197) >> [jboss-modules.jar:1.3.0.Final] >> at >> org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) >> [jboss-modules.jar:1.3.0.Final] >> at >> org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) >> [jboss-modules.jar:1.3.0.Final] >> at >> org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) >> [jboss-modules.jar:1.3.0.Final] >> at >> org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) >> [jboss-modules.jar:1.3.0.Final] >> at >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.addListener(UndertowDeploymentInfoService.java:1035) >> at >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:640) >> ... 6 more >> >> 11:22:17,936 ERROR [org.jboss.as.controller.management-operation] >> (management-handler-thread - 5) JBAS014613: Operation ("deploy") failed >> - address: ([("deployment" => "a >> uth-server.war")]) - failure description: {"JBAS014671: Failed services" >> => >> {"jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoSer >> vice" => "org.jboss.msc.service.StartException in service >> jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService: >> java.lang.Clas >> sNotFoundException: org.keycloak.services.listeners.MongoRunnerListener >> from [Module \"deployment.auth-server.war:main\" from Service Module Loader] >> Caused by: java.lang.ClassNotFoundException: >> org.keycloak.services.listeners.MongoRunnerListener from [Module >> \"deployment.auth-server.war:main\" from Service Module >> Loader]"}} >> 11:22:17,946 ERROR [org.jboss.as.server] (management-handler-thread - 5) >> JBAS015870: Deploy of deployment "auth-server.war" was rolled back with >> the following failure mes >> sage: >> {"JBAS014671: Failed services" => >> {"jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService" >> => "org.jboss.msc.service.StartExcep >> tion in service >> jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService: >> java.lang.ClassNotFoundException: org.keycloak.services. >> listeners.MongoRunnerListener from [Module >> \"deployment.auth-server.war:main\" from Service Module Loader] >> Caused by: java.lang.ClassNotFoundException: >> org.keycloak.services.listeners.MongoRunnerListener from [Module >> \"deployment.auth-server.war:main\" from Service Module >> Loader]"}} >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From bburke at redhat.com Thu Dec 5 13:39:11 2013 From: bburke at redhat.com (Bill Burke) Date: Thu, 05 Dec 2013 13:39:11 -0500 Subject: [keycloak-dev] View all users for a realm In-Reply-To: <8533AE6D-C059-47A9-9F88-F57C760CB082@redhat.com> References: <873497915.24121368.1386243638270.JavaMail.root@redhat.com> <8533AE6D-C059-47A9-9F88-F57C760CB082@redhat.com> Message-ID: <52A0C84F.7080800@redhat.com> Well, he won't see the user if there are N number of users already. On 12/5/2013 11:34 AM, Gabriel Cardoso wrote: > This is much better from the usability perspective. The way it is, the > admin creates an user and does not see him listed in the table. This may > lead him to try to create the same user again ;) > > Gabriel > > On Dec 5, 2013, at 9:40 AM, Stian Thorgersen wrote: > >> ATM it's only possible to search for users. It should be possible to >> also view all users for a realm. >> >> I propose that we make the users page show all users when there's no >> search set. In the future this and all other tables should support >> pagination, including pagination support on the rest endpoints, so >> that would solve the issue of loading a huge amount of users. >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -- > Gabriel Cardoso > GateIn Portal | User Experience Designer > > > > > _______________________________________________ > 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 bburke at redhat.com Thu Dec 5 13:41:57 2013 From: bburke at redhat.com (Bill Burke) Date: Thu, 05 Dec 2013 13:41:57 -0500 Subject: [keycloak-dev] Getting demo to run In-Reply-To: <52A0A8F4.7050507@redhat.com> References: <52A0A8F4.7050507@redhat.com> Message-ID: <52A0C8F5.80204@redhat.com> Wildfly demo does not work because there is a bug in Wildfly beta 1 regarding http sessions so I stopped developing it. Undertow does not set the jsessionid cookie path correctly so sessions are blow away if you switch between different deploye dWARS on the same wildfly instance. I've been waiting for Wildfly beta2 to finish up the Wildfly integration because of this. You'll have to try out the demo on AS7 or EAP 6.x. On 12/5/2013 11:25 AM, ssilvert at redhat.com wrote: > I'm trying to get the demo to run on WildFly master. I ran into a > compilation problem and submitted this PR so it would compile: > https://github.com/keycloak/keycloak/pull/122 > > Now it builds OK, but when I do mvn jboss-as:deploy, I get the errors > below on WildFly. Is this what I should be doing to get started? > Should I be trying this on EAP 6 instead? > > 11:22:17,891 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) > MSC000001: Failed to start service > jboss.undertow.deployment.default-server.default-host./auth-se > rver.UndertowDeploymentInfoService: org.jboss.msc.service.StartException > in service > jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentI > nfoService: java.lang.ClassNotFoundException: > org.keycloak.services.listeners.MongoRunnerListener from [Module > "deployment.auth-server.war:main" from Service Module Loade > r] > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:772) > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:217) > at > org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1] > at > org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > [rt.jar:1.7.0_15] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > [rt.jar:1.7.0_15] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15] > Caused by: java.lang.ClassNotFoundException: > org.keycloak.services.listeners.MongoRunnerListener from [Module > "deployment.auth-server.war:main" from Service Module Loader > ] > at > org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197) [jboss-modules.jar:1.3.0.Final] > at > org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) > [jboss-modules.jar:1.3.0.Final] > at > org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) > [jboss-modules.jar:1.3.0.Final] > at > org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) > [jboss-modules.jar:1.3.0.Final] > at > org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) > [jboss-modules.jar:1.3.0.Final] > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.addListener(UndertowDeploymentInfoService.java:1035) > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:640) > ... 6 more > > 11:22:17,936 ERROR [org.jboss.as.controller.management-operation] > (management-handler-thread - 5) JBAS014613: Operation ("deploy") failed > - address: ([("deployment" => "a > uth-server.war")]) - failure description: {"JBAS014671: Failed services" > => > {"jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoSer > vice" => "org.jboss.msc.service.StartException in service > jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService: > java.lang.Clas > sNotFoundException: org.keycloak.services.listeners.MongoRunnerListener > from [Module \"deployment.auth-server.war:main\" from Service Module Loader] > Caused by: java.lang.ClassNotFoundException: > org.keycloak.services.listeners.MongoRunnerListener from [Module > \"deployment.auth-server.war:main\" from Service Module > Loader]"}} > 11:22:17,946 ERROR [org.jboss.as.server] (management-handler-thread - 5) > JBAS015870: Deploy of deployment "auth-server.war" was rolled back with > the following failure mes > sage: > {"JBAS014671: Failed services" => > {"jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService" > => "org.jboss.msc.service.StartExcep > tion in service > jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService: > java.lang.ClassNotFoundException: org.keycloak.services. > listeners.MongoRunnerListener from [Module > \"deployment.auth-server.war:main\" from Service Module Loader] > Caused by: java.lang.ClassNotFoundException: > org.keycloak.services.listeners.MongoRunnerListener from [Module > \"deployment.auth-server.war:main\" from Service Module > Loader]"}} > _______________________________________________ > 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 Dec 5 13:47:27 2013 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 5 Dec 2013 13:47:27 -0500 (EST) Subject: [keycloak-dev] Getting demo to run In-Reply-To: <52A0C8F5.80204@redhat.com> References: <52A0A8F4.7050507@redhat.com> <52A0C8F5.80204@redhat.com> Message-ID: <1041241135.24769888.1386269247233.JavaMail.root@redhat.com> It should work on EAP 6, but you need to define a datasource + upgrade Resteasy to 3.0.5.Final. The dist-as7 does that for you. You can also run in standalone in dev-mode with: # mvn clean install # mvn -pl testsuite/integration -Pkeycloak-server exec:java ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Thursday, 5 December, 2013 6:41:57 PM > Subject: Re: [keycloak-dev] Getting demo to run > > Wildfly demo does not work because there is a bug in Wildfly beta 1 > regarding http sessions so I stopped developing it. Undertow does not > set the jsessionid cookie path correctly so sessions are blow away if > you switch between different deploye dWARS on the same wildfly instance. > > I've been waiting for Wildfly beta2 to finish up the Wildfly integration > because of this. > > You'll have to try out the demo on AS7 or EAP 6.x. > > On 12/5/2013 11:25 AM, ssilvert at redhat.com wrote: > > I'm trying to get the demo to run on WildFly master. I ran into a > > compilation problem and submitted this PR so it would compile: > > https://github.com/keycloak/keycloak/pull/122 > > > > Now it builds OK, but when I do mvn jboss-as:deploy, I get the errors > > below on WildFly. Is this what I should be doing to get started? > > Should I be trying this on EAP 6 instead? > > > > 11:22:17,891 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) > > MSC000001: Failed to start service > > jboss.undertow.deployment.default-server.default-host./auth-se > > rver.UndertowDeploymentInfoService: org.jboss.msc.service.StartException > > in service > > jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentI > > nfoService: java.lang.ClassNotFoundException: > > org.keycloak.services.listeners.MongoRunnerListener from [Module > > "deployment.auth-server.war:main" from Service Module Loade > > r] > > at > > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:772) > > at > > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:217) > > at > > org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > > [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1] > > at > > org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > > [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1] > > at > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > > [rt.jar:1.7.0_15] > > at > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > > [rt.jar:1.7.0_15] > > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15] > > Caused by: java.lang.ClassNotFoundException: > > org.keycloak.services.listeners.MongoRunnerListener from [Module > > "deployment.auth-server.war:main" from Service Module Loader > > ] > > at > > org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197) > > [jboss-modules.jar:1.3.0.Final] > > at > > org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) > > [jboss-modules.jar:1.3.0.Final] > > at > > org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) > > [jboss-modules.jar:1.3.0.Final] > > at > > org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) > > [jboss-modules.jar:1.3.0.Final] > > at > > org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) > > [jboss-modules.jar:1.3.0.Final] > > at > > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.addListener(UndertowDeploymentInfoService.java:1035) > > at > > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:640) > > ... 6 more > > > > 11:22:17,936 ERROR [org.jboss.as.controller.management-operation] > > (management-handler-thread - 5) JBAS014613: Operation ("deploy") failed > > - address: ([("deployment" => "a > > uth-server.war")]) - failure description: {"JBAS014671: Failed services" > > => > > {"jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoSer > > vice" => "org.jboss.msc.service.StartException in service > > jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService: > > java.lang.Clas > > sNotFoundException: org.keycloak.services.listeners.MongoRunnerListener > > from [Module \"deployment.auth-server.war:main\" from Service Module > > Loader] > > Caused by: java.lang.ClassNotFoundException: > > org.keycloak.services.listeners.MongoRunnerListener from [Module > > \"deployment.auth-server.war:main\" from Service Module > > Loader]"}} > > 11:22:17,946 ERROR [org.jboss.as.server] (management-handler-thread - 5) > > JBAS015870: Deploy of deployment "auth-server.war" was rolled back with > > the following failure mes > > sage: > > {"JBAS014671: Failed services" => > > {"jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService" > > => "org.jboss.msc.service.StartExcep > > tion in service > > jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService: > > java.lang.ClassNotFoundException: org.keycloak.services. > > listeners.MongoRunnerListener from [Module > > \"deployment.auth-server.war:main\" from Service Module Loader] > > Caused by: java.lang.ClassNotFoundException: > > org.keycloak.services.listeners.MongoRunnerListener from [Module > > \"deployment.auth-server.war:main\" from Service Module > > Loader]"}} > > _______________________________________________ > > 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 Thu Dec 5 14:07:40 2013 From: ssilvert at redhat.com (ssilvert at redhat.com) Date: Thu, 05 Dec 2013 14:07:40 -0500 Subject: [keycloak-dev] Getting demo to run In-Reply-To: <1041241135.24769888.1386269247233.JavaMail.root@redhat.com> References: <52A0A8F4.7050507@redhat.com> <52A0C8F5.80204@redhat.com> <1041241135.24769888.1386269247233.JavaMail.root@redhat.com> Message-ID: <52A0CEFC.4010406@redhat.com> On 12/5/2013 1:47 PM, Stian Thorgersen wrote: > It should work on EAP 6, but you need to define a datasource + upgrade Resteasy to 3.0.5.Final. The dist-as7 does that for you. What is dist-as7 and where do I find it? Do I need to build it? If so, how? Also, the RestEasy doc says, "The Resteasy distribution comes with a zip file called resteasy-jboss-modules-3.0.4.Final.zip". I downloaded the resteasy-jaxrs-3.0.5.Final-all.zip. There was no zip file inside. So I guess I downloaded the wrong file? If so, where do I get the correct one? > > You can also run in standalone in dev-mode with: > > # mvn clean install > # mvn -pl testsuite/integration -Pkeycloak-server exec:java > > > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Thursday, 5 December, 2013 6:41:57 PM >> Subject: Re: [keycloak-dev] Getting demo to run >> >> Wildfly demo does not work because there is a bug in Wildfly beta 1 >> regarding http sessions so I stopped developing it. Undertow does not >> set the jsessionid cookie path correctly so sessions are blow away if >> you switch between different deploye dWARS on the same wildfly instance. >> >> I've been waiting for Wildfly beta2 to finish up the Wildfly integration >> because of this. >> >> You'll have to try out the demo on AS7 or EAP 6.x. >> >> On 12/5/2013 11:25 AM, ssilvert at redhat.com wrote: >>> I'm trying to get the demo to run on WildFly master. I ran into a >>> compilation problem and submitted this PR so it would compile: >>> https://github.com/keycloak/keycloak/pull/122 >>> >>> Now it builds OK, but when I do mvn jboss-as:deploy, I get the errors >>> below on WildFly. Is this what I should be doing to get started? >>> Should I be trying this on EAP 6 instead? >>> >>> 11:22:17,891 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) >>> MSC000001: Failed to start service >>> jboss.undertow.deployment.default-server.default-host./auth-se >>> rver.UndertowDeploymentInfoService: org.jboss.msc.service.StartException >>> in service >>> jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentI >>> nfoService: java.lang.ClassNotFoundException: >>> org.keycloak.services.listeners.MongoRunnerListener from [Module >>> "deployment.auth-server.war:main" from Service Module Loade >>> r] >>> at >>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:772) >>> at >>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:217) >>> at >>> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) >>> [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1] >>> at >>> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) >>> [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1] >>> at >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>> [rt.jar:1.7.0_15] >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>> [rt.jar:1.7.0_15] >>> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15] >>> Caused by: java.lang.ClassNotFoundException: >>> org.keycloak.services.listeners.MongoRunnerListener from [Module >>> "deployment.auth-server.war:main" from Service Module Loader >>> ] >>> at >>> org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197) >>> [jboss-modules.jar:1.3.0.Final] >>> at >>> org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) >>> [jboss-modules.jar:1.3.0.Final] >>> at >>> org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) >>> [jboss-modules.jar:1.3.0.Final] >>> at >>> org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) >>> [jboss-modules.jar:1.3.0.Final] >>> at >>> org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) >>> [jboss-modules.jar:1.3.0.Final] >>> at >>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.addListener(UndertowDeploymentInfoService.java:1035) >>> at >>> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:640) >>> ... 6 more >>> >>> 11:22:17,936 ERROR [org.jboss.as.controller.management-operation] >>> (management-handler-thread - 5) JBAS014613: Operation ("deploy") failed >>> - address: ([("deployment" => "a >>> uth-server.war")]) - failure description: {"JBAS014671: Failed services" >>> => >>> {"jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoSer >>> vice" => "org.jboss.msc.service.StartException in service >>> jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService: >>> java.lang.Clas >>> sNotFoundException: org.keycloak.services.listeners.MongoRunnerListener >>> from [Module \"deployment.auth-server.war:main\" from Service Module >>> Loader] >>> Caused by: java.lang.ClassNotFoundException: >>> org.keycloak.services.listeners.MongoRunnerListener from [Module >>> \"deployment.auth-server.war:main\" from Service Module >>> Loader]"}} >>> 11:22:17,946 ERROR [org.jboss.as.server] (management-handler-thread - 5) >>> JBAS015870: Deploy of deployment "auth-server.war" was rolled back with >>> the following failure mes >>> sage: >>> {"JBAS014671: Failed services" => >>> {"jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService" >>> => "org.jboss.msc.service.StartExcep >>> tion in service >>> jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService: >>> java.lang.ClassNotFoundException: org.keycloak.services. >>> listeners.MongoRunnerListener from [Module >>> \"deployment.auth-server.war:main\" from Service Module Loader] >>> Caused by: java.lang.ClassNotFoundException: >>> org.keycloak.services.listeners.MongoRunnerListener from [Module >>> \"deployment.auth-server.war:main\" from Service Module >>> Loader]"}} >>> _______________________________________________ >>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20131205/daf44f9c/attachment-0001.html From stian at redhat.com Thu Dec 5 14:07:44 2013 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 5 Dec 2013 14:07:44 -0500 (EST) Subject: [keycloak-dev] View all users for a realm In-Reply-To: <52A0C84F.7080800@redhat.com> References: <873497915.24121368.1386243638270.JavaMail.root@redhat.com> <8533AE6D-C059-47A9-9F88-F57C760CB082@redhat.com> <52A0C84F.7080800@redhat.com> Message-ID: <1006249887.24781209.1386270464926.JavaMail.root@redhat.com> I should have included the reason why I want it ;) ATM there's no way for an admin to list all users. I think we should either view all users by default, or add "View all" button next to the search. I'm happy with either, and I'd probably prefer the last option TBH. ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Thursday, 5 December, 2013 6:39:11 PM > Subject: Re: [keycloak-dev] View all users for a realm > > Well, he won't see the user if there are N number of users already. > > On 12/5/2013 11:34 AM, Gabriel Cardoso wrote: > > This is much better from the usability perspective. The way it is, the > > admin creates an user and does not see him listed in the table. This may > > lead him to try to create the same user again ;) > > > > Gabriel > > > > On Dec 5, 2013, at 9:40 AM, Stian Thorgersen wrote: > > > >> ATM it's only possible to search for users. It should be possible to > >> also view all users for a realm. > >> > >> I propose that we make the users page show all users when there's no > >> search set. In the future this and all other tables should support > >> pagination, including pagination support on the rest endpoints, so > >> that would solve the issue of loading a huge amount of users. > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > -- > > Gabriel Cardoso > > GateIn Portal | User Experience Designer > > > > > > > > > > _______________________________________________ > > 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 gcardoso at redhat.com Thu Dec 5 14:10:52 2013 From: gcardoso at redhat.com (Gabriel Cardoso) Date: Thu, 5 Dec 2013 17:10:52 -0200 Subject: [keycloak-dev] View all users for a realm In-Reply-To: <1006249887.24781209.1386270464926.JavaMail.root@redhat.com> References: <873497915.24121368.1386243638270.JavaMail.root@redhat.com> <8533AE6D-C059-47A9-9F88-F57C760CB082@redhat.com> <52A0C84F.7080800@redhat.com> <1006249887.24781209.1386270464926.JavaMail.root@redhat.com> Message-ID: <6B50331E-84BA-4F57-9562-EC4629283AB4@redhat.com> If we don't list all users by default, it would be good to update the page's header to "Search Users" On Dec 5, 2013, at 5:07 PM, Stian Thorgersen wrote: > I should have included the reason why I want it ;) > > ATM there's no way for an admin to list all users. I think we should either view all users by default, or add "View all" button next to the search. I'm happy with either, and I'd probably prefer the last option TBH. > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Thursday, 5 December, 2013 6:39:11 PM >> Subject: Re: [keycloak-dev] View all users for a realm >> >> Well, he won't see the user if there are N number of users already. >> >> On 12/5/2013 11:34 AM, Gabriel Cardoso wrote: >>> This is much better from the usability perspective. The way it is, the >>> admin creates an user and does not see him listed in the table. This may >>> lead him to try to create the same user again ;) >>> >>> Gabriel >>> >>> On Dec 5, 2013, at 9:40 AM, Stian Thorgersen wrote: >>> >>>> ATM it's only possible to search for users. It should be possible to >>>> also view all users for a realm. >>>> >>>> I propose that we make the users page show all users when there's no >>>> search set. In the future this and all other tables should support >>>> pagination, including pagination support on the rest endpoints, so >>>> that would solve the issue of loading a huge amount of users. >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> -- >>> Gabriel Cardoso >>> GateIn Portal | User Experience Designer >>> >>> >>> >>> >>> _______________________________________________ >>> 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 -- Gabriel Cardoso GateIn Portal | User Experience Designer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20131205/fcf0d278/attachment.html From ssilvert at redhat.com Thu Dec 5 14:32:15 2013 From: ssilvert at redhat.com (ssilvert at redhat.com) Date: Thu, 05 Dec 2013 14:32:15 -0500 Subject: [keycloak-dev] Getting demo to run In-Reply-To: <52A0C8F5.80204@redhat.com> References: <52A0A8F4.7050507@redhat.com> <52A0C8F5.80204@redhat.com> Message-ID: <52A0D4BF.1020203@redhat.com> On 12/5/2013 1:41 PM, Bill Burke wrote: > Wildfly demo does not work because there is a bug in Wildfly beta 1 > regarding http sessions so I stopped developing it. Undertow does not > set the jsessionid cookie path correctly so sessions are blow away if > you switch between different deploye dWARS on the same wildfly instance. > > I've been waiting for Wildfly beta2 to finish up the Wildfly integration > because of this. You mean this one? https://issues.jboss.org/browse/UNDERTOW-130 I checked. It should be fixed in Undertow and integrated into WildFly master now. > > You'll have to try out the demo on AS7 or EAP 6.x. > > On 12/5/2013 11:25 AM, ssilvert at redhat.com wrote: >> I'm trying to get the demo to run on WildFly master. I ran into a >> compilation problem and submitted this PR so it would compile: >> https://github.com/keycloak/keycloak/pull/122 >> >> Now it builds OK, but when I do mvn jboss-as:deploy, I get the errors >> below on WildFly. Is this what I should be doing to get started? >> Should I be trying this on EAP 6 instead? >> >> 11:22:17,891 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) >> MSC000001: Failed to start service >> jboss.undertow.deployment.default-server.default-host./auth-se >> rver.UndertowDeploymentInfoService: org.jboss.msc.service.StartException >> in service >> jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentI >> nfoService: java.lang.ClassNotFoundException: >> org.keycloak.services.listeners.MongoRunnerListener from [Module >> "deployment.auth-server.war:main" from Service Module Loade >> r] >> at >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:772) >> at >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:217) >> at >> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) >> [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1] >> at >> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) >> [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1] >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >> [rt.jar:1.7.0_15] >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >> [rt.jar:1.7.0_15] >> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15] >> Caused by: java.lang.ClassNotFoundException: >> org.keycloak.services.listeners.MongoRunnerListener from [Module >> "deployment.auth-server.war:main" from Service Module Loader >> ] >> at >> org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197) [jboss-modules.jar:1.3.0.Final] >> at >> org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) >> [jboss-modules.jar:1.3.0.Final] >> at >> org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) >> [jboss-modules.jar:1.3.0.Final] >> at >> org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) >> [jboss-modules.jar:1.3.0.Final] >> at >> org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) >> [jboss-modules.jar:1.3.0.Final] >> at >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.addListener(UndertowDeploymentInfoService.java:1035) >> at >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:640) >> ... 6 more >> >> 11:22:17,936 ERROR [org.jboss.as.controller.management-operation] >> (management-handler-thread - 5) JBAS014613: Operation ("deploy") failed >> - address: ([("deployment" => "a >> uth-server.war")]) - failure description: {"JBAS014671: Failed services" >> => >> {"jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoSer >> vice" => "org.jboss.msc.service.StartException in service >> jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService: >> java.lang.Clas >> sNotFoundException: org.keycloak.services.listeners.MongoRunnerListener >> from [Module \"deployment.auth-server.war:main\" from Service Module Loader] >> Caused by: java.lang.ClassNotFoundException: >> org.keycloak.services.listeners.MongoRunnerListener from [Module >> \"deployment.auth-server.war:main\" from Service Module >> Loader]"}} >> 11:22:17,946 ERROR [org.jboss.as.server] (management-handler-thread - 5) >> JBAS015870: Deploy of deployment "auth-server.war" was rolled back with >> the following failure mes >> sage: >> {"JBAS014671: Failed services" => >> {"jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService" >> => "org.jboss.msc.service.StartExcep >> tion in service >> jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService: >> java.lang.ClassNotFoundException: org.keycloak.services. >> listeners.MongoRunnerListener from [Module >> \"deployment.auth-server.war:main\" from Service Module Loader] >> Caused by: java.lang.ClassNotFoundException: >> org.keycloak.services.listeners.MongoRunnerListener from [Module >> \"deployment.auth-server.war:main\" from Service Module >> Loader]"}} >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From bburke at redhat.com Thu Dec 5 14:34:39 2013 From: bburke at redhat.com (Bill Burke) Date: Thu, 05 Dec 2013 14:34:39 -0500 Subject: [keycloak-dev] Getting demo to run In-Reply-To: <52A0C8F5.80204@redhat.com> References: <52A0A8F4.7050507@redhat.com> <52A0C8F5.80204@redhat.com> Message-ID: <52A0D54F.8000808@redhat.com> On 12/5/2013 1:41 PM, Bill Burke wrote: > Wildfly demo does not work because there is a bug in Wildfly beta 1 > regarding http sessions so I stopped developing it. Undertow does not > set the jsessionid cookie path correctly so sessions are blow away if > you switch between different deploye dWARS on the same wildfly instance. > > I've been waiting for Wildfly beta2 to finish up the Wildfly integration > because of this. > > You'll have to try out the demo on AS7 or EAP 6.x. > Also, the undertow security SPIs are in flux between Wildfly Beta1 and Wildfly Beta 2(master). There's also talk on the Undertow list of changing some of the other SPIs that I'm currently using. So, I have to kind of wait for that stuff to settle to finish up the Wildfly adapter. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Thu Dec 5 14:35:10 2013 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 5 Dec 2013 14:35:10 -0500 (EST) Subject: [keycloak-dev] Getting demo to run In-Reply-To: <52A0CEFC.4010406@redhat.com> References: <52A0A8F4.7050507@redhat.com> <52A0C8F5.80204@redhat.com> <1041241135.24769888.1386269247233.JavaMail.root@redhat.com> <52A0CEFC.4010406@redhat.com> Message-ID: <1859713376.24850408.1386272110750.JavaMail.root@redhat.com> ----- Original Message ----- > From: ssilvert at redhat.com > To: keycloak-dev at lists.jboss.org > Sent: Thursday, 5 December, 2013 7:07:40 PM > Subject: Re: [keycloak-dev] Getting demo to run > > On 12/5/2013 1:47 PM, Stian Thorgersen wrote: > > > > It should work on EAP 6, but you need to define a datasource + upgrade > Resteasy to 3.0.5.Final. The dist-as7 does that for you. > What is dist-as7 and where do I find it? Do I need to build it? If so, how? You can build it with: # mvn clean install -Prelease-as7 # dist-as7/target/keycloak-1.0-alpha-1/bin/standalone.sh You can also download it from https://www.dropbox.com/s/a3g75gdn2bdexjf/keycloak-1.0-alpha-1.tar.gz - this is a temporary dl and a snapshot not the alpha release! > > Also, the RestEasy doc says, " The Resteasy distribution comes with a zip > file called resteasy-jboss-modules-3.0.4.Final.zip". I downloaded the > resteasy-jaxrs-3.0.5.Final-all.zip. There was no zip file inside. So I guess > I downloaded the wrong file? If so, where do I get the correct one? This is the one I use in dist-as7: http://switch.dl.sourceforge.net/project/resteasy/Resteasy%20JAX-RS/3.0.5.Final/resteasy-jaxrs-3.0.5.Final-all.zip The datasource you need to add is: jdbc:h2:${jboss.server.data.dir}/keycloak;AUTO_SERVER=TRUE h2 sa sa > > > > You can also run in standalone in dev-mode with: > > # mvn clean install > # mvn -pl testsuite/integration -Pkeycloak-server exec:java > > > > ----- Original Message ----- > > > > From: "Bill Burke" To: keycloak-dev at lists.jboss.org Sent: > Thursday, 5 December, 2013 6:41:57 PM > Subject: Re: [keycloak-dev] Getting demo to run > > Wildfly demo does not work because there is a bug in Wildfly beta 1 > regarding http sessions so I stopped developing it. Undertow does not > set the jsessionid cookie path correctly so sessions are blow away if > you switch between different deploye dWARS on the same wildfly instance. > > I've been waiting for Wildfly beta2 to finish up the Wildfly integration > because of this. > > You'll have to try out the demo on AS7 or EAP 6.x. > > On 12/5/2013 11:25 AM, ssilvert at redhat.com wrote: > > > > I'm trying to get the demo to run on WildFly master. I ran into a > compilation problem and submitted this PR so it would compile: > https://github.com/keycloak/keycloak/pull/122 Now it builds OK, but when I > do mvn jboss-as:deploy, I get the errors > below on WildFly. Is this what I should be doing to get started? > Should I be trying this on EAP 6 instead? > > 11:22:17,891 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) > MSC000001: Failed to start service > jboss.undertow.deployment.default-server.default-host./auth-se > rver.UndertowDeploymentInfoService: org.jboss.msc.service.StartException > in service > jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentI > nfoService: java.lang.ClassNotFoundException: > org.keycloak.services.listeners.MongoRunnerListener from [Module > "deployment.auth-server.war:main" from Service Module Loade > r] > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:772) > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:217) > at > org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1] > at > org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > [rt.jar:1.7.0_15] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > [rt.jar:1.7.0_15] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15] > Caused by: java.lang.ClassNotFoundException: > org.keycloak.services.listeners.MongoRunnerListener from [Module > "deployment.auth-server.war:main" from Service Module Loader > ] > at > org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197) > [jboss-modules.jar:1.3.0.Final] > at > org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) > [jboss-modules.jar:1.3.0.Final] > at > org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) > [jboss-modules.jar:1.3.0.Final] > at > org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) > [jboss-modules.jar:1.3.0.Final] > at > org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) > [jboss-modules.jar:1.3.0.Final] > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.addListener(UndertowDeploymentInfoService.java:1035) > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:640) > ... 6 more > > 11:22:17,936 ERROR [org.jboss.as.controller.management-operation] > (management-handler-thread - 5) JBAS014613: Operation ("deploy") failed > - address: ([("deployment" => "a > uth-server.war")]) - failure description: {"JBAS014671: Failed services" > => > {"jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoSer > vice" => "org.jboss.msc.service.StartException in service > jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService: > java.lang.Clas > sNotFoundException: org.keycloak.services.listeners.MongoRunnerListener > from [Module \"deployment.auth-server.war:main\" from Service Module > Loader] > Caused by: java.lang.ClassNotFoundException: > org.keycloak.services.listeners.MongoRunnerListener from [Module > \"deployment.auth-server.war:main\" from Service Module > Loader]"}} > 11:22:17,946 ERROR [org.jboss.as.server] (management-handler-thread - 5) > JBAS015870: Deploy of deployment "auth-server.war" was rolled back with > the following failure mes > sage: > {"JBAS014671: Failed services" => > {"jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService" > => "org.jboss.msc.service.StartExcep > tion in service > jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService: > java.lang.ClassNotFoundException: org.keycloak.services. > listeners.MongoRunnerListener from [Module > \"deployment.auth-server.war:main\" from Service Module Loader] > Caused by: java.lang.ClassNotFoundException: > org.keycloak.services.listeners.MongoRunnerListener from [Module > \"deployment.auth-server.war:main\" from Service Module > Loader]"}} > _______________________________________________ > 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 > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bburke at redhat.com Thu Dec 5 14:53:10 2013 From: bburke at redhat.com (Bill Burke) Date: Thu, 05 Dec 2013 14:53:10 -0500 Subject: [keycloak-dev] resteasy dependencies before Alpha 1 Message-ID: <52A0D9A6.8040502@redhat.com> I'm thnking it might be a good idea to take some time to remove the Resteasy dependencies from the AS7 adapter. Upgrading to Resteasy 3 would probably be a big deal to many EAP/AS7 users. I was able to finally figure out the correct exclusion metadata to put in jboss-deployment-structure.xml so that I could just bundle Resteasy 3 with the Keycloak Server WAR. Might also want to figure out how to trim down the AS7 distro to make a smaller download. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From ssilvert at redhat.com Thu Dec 5 14:56:41 2013 From: ssilvert at redhat.com (ssilvert at redhat.com) Date: Thu, 05 Dec 2013 14:56:41 -0500 Subject: [keycloak-dev] Getting demo to run In-Reply-To: <1859713376.24850408.1386272110750.JavaMail.root@redhat.com> References: <52A0A8F4.7050507@redhat.com> <52A0C8F5.80204@redhat.com> <1041241135.24769888.1386269247233.JavaMail.root@redhat.com> <52A0CEFC.4010406@redhat.com> <1859713376.24850408.1386272110750.JavaMail.root@redhat.com> Message-ID: <52A0DA79.9030007@redhat.com> On 12/5/2013 2:35 PM, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: ssilvert at redhat.com >> To: keycloak-dev at lists.jboss.org >> Sent: Thursday, 5 December, 2013 7:07:40 PM >> Subject: Re: [keycloak-dev] Getting demo to run >> >> On 12/5/2013 1:47 PM, Stian Thorgersen wrote: >> >> >> >> It should work on EAP 6, but you need to define a datasource + upgrade >> Resteasy to 3.0.5.Final. The dist-as7 does that for you. >> What is dist-as7 and where do I find it? Do I need to build it? If so, how? > You can build it with: > > # mvn clean install -Prelease-as7 Stupid me. I didn't realize I would need to set a profile. Should have thought of that. Getting closer. So now I'm running dist-as7, but when I deploy the wars I get: 14:50:07,042 ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-5) Context [/customer-portal] startup failed due to previous errors: java.lang.NoClassDefFoundError: org/apache/h at org.jboss.resteasy.client.jaxrs.ResteasyClientBuilder.initDefaultEngine(ResteasyClientBuilder.java:413) [resteasy-client-3.0.5.Final.jar:] at org.jboss.resteasy.client.jaxrs.ResteasyClientBuilder.build(ResteasyClientBuilder.java:318) [resteasy-client-3.0.5.Final.jar:] at org.keycloak.adapters.config.ManagedResourceConfigLoader.initClient(ManagedResourceConfigLoader.java:180) [keycloak-core-1.0-alpha-1.jar:] at org.keycloak.adapters.config.ManagedResourceConfigLoader.init(ManagedResourceConfigLoader.java:79) [keycloak-core-1.0-alpha-1.jar:] at org.keycloak.adapters.as7.OAuthManagedResourceValve.init(OAuthManagedResourceValve.java:71) [keycloak-as7-adapter-1.0-alpha-1.jar:] at org.keycloak.adapters.as7.OAuthManagedResourceValve.lifecycleEvent(OAuthManagedResourceValve.java:66) [keycloak-as7-adapter-1.0-alpha-1.jar:] at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:115) [jbossweb-7.0.13.Final.jar:] at org.apache.catalina.core.StandardContext.start(StandardContext.java:3845) [jbossweb-7.0.13.Final.jar:] at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:90) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15] at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15] Caused by: java.lang.ClassNotFoundException: org.apache.http.impl.conn.PoolingClientConnectionManager from [Module "org.jboss.resteasy.resteasy-jaxrs:main" from local module loader @3efd2905 (roots .0-alpha-1\modules)] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468) at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120) ... 14 more 14:50:07,232 ERROR [org.apache.catalina.core.StandardContext] (MSC service thread 1-5) Context [/customer-portal] startup failed due to previous errors 14:50:07,237 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC00001: Failed to start service jboss.web.deployment.default-host./customer-portal: org.jboss.msc.service.StartException i l: JBAS018040: Failed to start context at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:95) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15] > # dist-as7/target/keycloak-1.0-alpha-1/bin/standalone.sh > > You can also download it from https://www.dropbox.com/s/a3g75gdn2bdexjf/keycloak-1.0-alpha-1.tar.gz - this is a temporary dl and a snapshot not the alpha release! > >> Also, the RestEasy doc says, " The Resteasy distribution comes with a zip >> file called resteasy-jboss-modules-3.0.4.Final.zip". I downloaded the >> resteasy-jaxrs-3.0.5.Final-all.zip. There was no zip file inside. So I guess >> I downloaded the wrong file? If so, where do I get the correct one? > This is the one I use in dist-as7: > > http://switch.dl.sourceforge.net/project/resteasy/Resteasy%20JAX-RS/3.0.5.Final/resteasy-jaxrs-3.0.5.Final-all.zip > > The datasource you need to add is: > > > jdbc:h2:${jboss.server.data.dir}/keycloak;AUTO_SERVER=TRUE > h2 > > sa > sa > > > >> >> >> You can also run in standalone in dev-mode with: >> >> # mvn clean install >> # mvn -pl testsuite/integration -Pkeycloak-server exec:java >> >> >> >> ----- Original Message ----- >> >> >> >> From: "Bill Burke" To: keycloak-dev at lists.jboss.org Sent: >> Thursday, 5 December, 2013 6:41:57 PM >> Subject: Re: [keycloak-dev] Getting demo to run >> >> Wildfly demo does not work because there is a bug in Wildfly beta 1 >> regarding http sessions so I stopped developing it. Undertow does not >> set the jsessionid cookie path correctly so sessions are blow away if >> you switch between different deploye dWARS on the same wildfly instance. >> >> I've been waiting for Wildfly beta2 to finish up the Wildfly integration >> because of this. >> >> You'll have to try out the demo on AS7 or EAP 6.x. >> >> On 12/5/2013 11:25 AM, ssilvert at redhat.com wrote: >> >> >> >> I'm trying to get the demo to run on WildFly master. I ran into a >> compilation problem and submitted this PR so it would compile: >> https://github.com/keycloak/keycloak/pull/122 Now it builds OK, but when I >> do mvn jboss-as:deploy, I get the errors >> below on WildFly. Is this what I should be doing to get started? >> Should I be trying this on EAP 6 instead? >> >> 11:22:17,891 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-6) >> MSC000001: Failed to start service >> jboss.undertow.deployment.default-server.default-host./auth-se >> rver.UndertowDeploymentInfoService: org.jboss.msc.service.StartException >> in service >> jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentI >> nfoService: java.lang.ClassNotFoundException: >> org.keycloak.services.listeners.MongoRunnerListener from [Module >> "deployment.auth-server.war:main" from Service Module Loade >> r] >> at >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:772) >> at >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:217) >> at >> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) >> [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1] >> at >> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) >> [jboss-msc-1.2.0.CR1.jar:1.2.0.CR1] >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >> [rt.jar:1.7.0_15] >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >> [rt.jar:1.7.0_15] >> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15] >> Caused by: java.lang.ClassNotFoundException: >> org.keycloak.services.listeners.MongoRunnerListener from [Module >> "deployment.auth-server.war:main" from Service Module Loader >> ] >> at >> org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197) >> [jboss-modules.jar:1.3.0.Final] >> at >> org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) >> [jboss-modules.jar:1.3.0.Final] >> at >> org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) >> [jboss-modules.jar:1.3.0.Final] >> at >> org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) >> [jboss-modules.jar:1.3.0.Final] >> at >> org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) >> [jboss-modules.jar:1.3.0.Final] >> at >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.addListener(UndertowDeploymentInfoService.java:1035) >> at >> org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:640) >> ... 6 more >> >> 11:22:17,936 ERROR [org.jboss.as.controller.management-operation] >> (management-handler-thread - 5) JBAS014613: Operation ("deploy") failed >> - address: ([("deployment" => "a >> uth-server.war")]) - failure description: {"JBAS014671: Failed services" >> => >> {"jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoSer >> vice" => "org.jboss.msc.service.StartException in service >> jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService: >> java.lang.Clas >> sNotFoundException: org.keycloak.services.listeners.MongoRunnerListener >> from [Module \"deployment.auth-server.war:main\" from Service Module >> Loader] >> Caused by: java.lang.ClassNotFoundException: >> org.keycloak.services.listeners.MongoRunnerListener from [Module >> \"deployment.auth-server.war:main\" from Service Module >> Loader]"}} >> 11:22:17,946 ERROR [org.jboss.as.server] (management-handler-thread - 5) >> JBAS015870: Deploy of deployment "auth-server.war" was rolled back with >> the following failure mes >> sage: >> {"JBAS014671: Failed services" => >> {"jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService" >> => "org.jboss.msc.service.StartExcep >> tion in service >> jboss.undertow.deployment.default-server.default-host./auth-server.UndertowDeploymentInfoService: >> java.lang.ClassNotFoundException: org.keycloak.services. >> listeners.MongoRunnerListener from [Module >> \"deployment.auth-server.war:main\" from Service Module Loader] >> Caused by: java.lang.ClassNotFoundException: >> org.keycloak.services.listeners.MongoRunnerListener from [Module >> \"deployment.auth-server.war:main\" from Service Module >> Loader]"}} >> _______________________________________________ >> 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 >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From ssilvert at redhat.com Thu Dec 5 14:57:20 2013 From: ssilvert at redhat.com (ssilvert at redhat.com) Date: Thu, 05 Dec 2013 14:57:20 -0500 Subject: [keycloak-dev] Getting demo to run In-Reply-To: <52A0D54F.8000808@redhat.com> References: <52A0A8F4.7050507@redhat.com> <52A0C8F5.80204@redhat.com> <52A0D54F.8000808@redhat.com> Message-ID: <52A0DAA0.2060205@redhat.com> On 12/5/2013 2:34 PM, Bill Burke wrote: > > On 12/5/2013 1:41 PM, Bill Burke wrote: >> Wildfly demo does not work because there is a bug in Wildfly beta 1 >> regarding http sessions so I stopped developing it. Undertow does not >> set the jsessionid cookie path correctly so sessions are blow away if >> you switch between different deploye dWARS on the same wildfly instance. >> >> I've been waiting for Wildfly beta2 to finish up the Wildfly integration >> because of this. >> >> You'll have to try out the demo on AS7 or EAP 6.x. >> > Also, the undertow security SPIs are in flux between Wildfly Beta1 and > Wildfly Beta 2(master). There's also talk on the Undertow list of > changing some of the other SPIs that I'm currently using. So, I have to > kind of wait for that stuff to settle to finish up the Wildfly adapter. > > OK. I'll stick to EAP 6 for awhile. From stian at redhat.com Thu Dec 5 14:59:28 2013 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 5 Dec 2013 14:59:28 -0500 (EST) Subject: [keycloak-dev] resteasy dependencies before Alpha 1 In-Reply-To: <52A0D9A6.8040502@redhat.com> References: <52A0D9A6.8040502@redhat.com> Message-ID: <1946081466.24875168.1386273568246.JavaMail.root@redhat.com> How are you planning that folks should run the examples? Will they use the dist and deploy/configure it to that (there's support for using -Dkeycloak.import=)? Or use the server.wars from the examples? I really don't understand why there's still DemoApplication and server WARs in the examples. Sounds like a release tomorrow is not going to happen. Could you setup Nexus and do a timstamped release for me tomorrow? I haven't managed to get write access to Nexus yet myself, so I can't do it.. ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Thursday, 5 December, 2013 7:53:10 PM > Subject: [keycloak-dev] resteasy dependencies before Alpha 1 > > I'm thnking it might be a good idea to take some time to remove the > Resteasy dependencies from the AS7 adapter. Upgrading to Resteasy 3 > would probably be a big deal to many EAP/AS7 users. > > I was able to finally figure out the correct exclusion metadata to put > in jboss-deployment-structure.xml so that I could just bundle Resteasy 3 > with the Keycloak Server WAR. > > Might also want to figure out how to trim down the AS7 distro to make a > smaller download. Good luck ;) > > -- > 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 Thu Dec 5 15:24:09 2013 From: ssilvert at redhat.com (ssilvert at redhat.com) Date: Thu, 05 Dec 2013 15:24:09 -0500 Subject: [keycloak-dev] Getting demo to run In-Reply-To: <52A0DA79.9030007@redhat.com> References: <52A0A8F4.7050507@redhat.com> <52A0C8F5.80204@redhat.com> <1041241135.24769888.1386269247233.JavaMail.root@redhat.com> <52A0CEFC.4010406@redhat.com> <1859713376.24850408.1386272110750.JavaMail.root@redhat.com> <52A0DA79.9030007@redhat.com> Message-ID: <52A0E0E9.7020409@redhat.com> On 12/5/2013 2:56 PM, ssilvert at redhat.com wrote: > Caused by: java.lang.ClassNotFoundException: > org.apache.http.impl.conn.PoolingClientConnectionManager from [Module > "org.jboss.resteasy.resteasy-jaxrs:main" from local module loader > @3efd2905 (roots > .0-alpha-1\modules)] This happens when deploying customer-portal. Any ideas? From bburke at redhat.com Thu Dec 5 15:47:45 2013 From: bburke at redhat.com (Bill Burke) Date: Thu, 05 Dec 2013 15:47:45 -0500 Subject: [keycloak-dev] Getting demo to run In-Reply-To: <52A0E0E9.7020409@redhat.com> References: <52A0A8F4.7050507@redhat.com> <52A0C8F5.80204@redhat.com> <1041241135.24769888.1386269247233.JavaMail.root@redhat.com> <52A0CEFC.4010406@redhat.com> <1859713376.24850408.1386272110750.JavaMail.root@redhat.com> <52A0DA79.9030007@redhat.com> <52A0E0E9.7020409@redhat.com> Message-ID: <52A0E671.6050106@redhat.com> On 12/5/2013 3:24 PM, ssilvert at redhat.com wrote: > On 12/5/2013 2:56 PM, ssilvert at redhat.com wrote: >> Caused by: java.lang.ClassNotFoundException: >> org.apache.http.impl.conn.PoolingClientConnectionManager from [Module >> "org.jboss.resteasy.resteasy-jaxrs:main" from local module loader >> @3efd2905 (roots >> .0-alpha-1\modules)] > This happens when deploying customer-portal. Any ideas? I've never used distro-as7/ THese directions work and are what I do to run the demo: https://github.com/keycloak/keycloak/tree/master/examples/as7-eap-demo Errata: * Resteasy 3.0.5 instead of 3.0.4 * There is no admin console registration page, only a login. username: admin password: admin It will ask you to change the admin password. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From ssilvert at redhat.com Thu Dec 5 16:03:46 2013 From: ssilvert at redhat.com (ssilvert at redhat.com) Date: Thu, 05 Dec 2013 16:03:46 -0500 Subject: [keycloak-dev] Getting demo to run In-Reply-To: <52A0E671.6050106@redhat.com> References: <52A0A8F4.7050507@redhat.com> <52A0C8F5.80204@redhat.com> <1041241135.24769888.1386269247233.JavaMail.root@redhat.com> <52A0CEFC.4010406@redhat.com> <1859713376.24850408.1386272110750.JavaMail.root@redhat.com> <52A0DA79.9030007@redhat.com> <52A0E0E9.7020409@redhat.com> <52A0E671.6050106@redhat.com> Message-ID: <52A0EA32.6010908@redhat.com> Where do I find the RestEasy distribution containing resteasy-jboss-modules-3.0.5.Final.zip? I've downloaded RestEasy and there is no zip file in it. On 12/5/2013 3:47 PM, Bill Burke wrote: > > On 12/5/2013 3:24 PM, ssilvert at redhat.com wrote: >> On 12/5/2013 2:56 PM, ssilvert at redhat.com wrote: >>> Caused by: java.lang.ClassNotFoundException: >>> org.apache.http.impl.conn.PoolingClientConnectionManager from [Module >>> "org.jboss.resteasy.resteasy-jaxrs:main" from local module loader >>> @3efd2905 (roots >>> .0-alpha-1\modules)] >> This happens when deploying customer-portal. Any ideas? > I've never used distro-as7/ > > THese directions work and are what I do to run the demo: > > https://github.com/keycloak/keycloak/tree/master/examples/as7-eap-demo > > Errata: > > * Resteasy 3.0.5 instead of 3.0.4 > * There is no admin console registration page, only a login. > > username: admin > password: admin > > It will ask you to change the admin password. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20131205/52a64560/attachment-0001.html From bburke at redhat.com Thu Dec 5 16:06:32 2013 From: bburke at redhat.com (Bill Burke) Date: Thu, 05 Dec 2013 16:06:32 -0500 Subject: [keycloak-dev] Getting demo to run In-Reply-To: <52A0EA32.6010908@redhat.com> References: <52A0A8F4.7050507@redhat.com> <52A0C8F5.80204@redhat.com> <1041241135.24769888.1386269247233.JavaMail.root@redhat.com> <52A0CEFC.4010406@redhat.com> <1859713376.24850408.1386272110750.JavaMail.root@redhat.com> <52A0DA79.9030007@redhat.com> <52A0E0E9.7020409@redhat.com> <52A0E671.6050106@redhat.com> <52A0EA32.6010908@redhat.com> Message-ID: <52A0EAD8.7080400@redhat.com> http://sourceforge.net/projects/resteasy/files/Resteasy%20JAX-RS/3.0.5.Final/resteasy-jaxrs-3.0.5.Final-all.zip/download It has the modules.zip file in it. I just downloaded it and unziped it and there it is. On 12/5/2013 4:03 PM, ssilvert at redhat.com wrote: > Where do I find the RestEasy distribution containing > resteasy-jboss-modules-3.0.5.Final.zip? I've downloaded RestEasy and > there is no zip file in it. > > On 12/5/2013 3:47 PM, Bill Burke wrote: >> >> On 12/5/2013 3:24 PM,ssilvert at redhat.com wrote: >>> On 12/5/2013 2:56 PM,ssilvert at redhat.com wrote: >>>> Caused by: java.lang.ClassNotFoundException: >>>> org.apache.http.impl.conn.PoolingClientConnectionManager from [Module >>>> "org.jboss.resteasy.resteasy-jaxrs:main" from local module loader >>>> @3efd2905 (roots >>>> .0-alpha-1\modules)] >>> This happens when deploying customer-portal. Any ideas? >> I've never used distro-as7/ >> >> THese directions work and are what I do to run the demo: >> >> https://github.com/keycloak/keycloak/tree/master/examples/as7-eap-demo >> >> Errata: >> >> * Resteasy 3.0.5 instead of 3.0.4 >> * There is no admin console registration page, only a login. >> >> username: admin >> password: admin >> >> It will ask you to change the admin password. >> > > > > _______________________________________________ > 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 ssilvert at redhat.com Thu Dec 5 16:30:50 2013 From: ssilvert at redhat.com (ssilvert at redhat.com) Date: Thu, 05 Dec 2013 16:30:50 -0500 Subject: [keycloak-dev] Getting demo to run In-Reply-To: <52A0EAD8.7080400@redhat.com> References: <52A0A8F4.7050507@redhat.com> <52A0C8F5.80204@redhat.com> <1041241135.24769888.1386269247233.JavaMail.root@redhat.com> <52A0CEFC.4010406@redhat.com> <1859713376.24850408.1386272110750.JavaMail.root@redhat.com> <52A0DA79.9030007@redhat.com> <52A0E0E9.7020409@redhat.com> <52A0E671.6050106@redhat.com> <52A0EA32.6010908@redhat.com> <52A0EAD8.7080400@redhat.com> Message-ID: <52A0F08A.1080209@redhat.com> Finally working. Thanks for your help and patience guys. On 12/5/2013 4:06 PM, Bill Burke wrote: > http://sourceforge.net/projects/resteasy/files/Resteasy%20JAX-RS/3.0.5.Final/resteasy-jaxrs-3.0.5.Final-all.zip/download > > It has the modules.zip file in it. I just downloaded it and unziped it > and there it is. > > On 12/5/2013 4:03 PM, ssilvert at redhat.com wrote: >> Where do I find the RestEasy distribution containing >> resteasy-jboss-modules-3.0.5.Final.zip? I've downloaded RestEasy and >> there is no zip file in it. >> >> On 12/5/2013 3:47 PM, Bill Burke wrote: >>> On 12/5/2013 3:24 PM,ssilvert at redhat.com wrote: >>>> On 12/5/2013 2:56 PM,ssilvert at redhat.com wrote: >>>>> Caused by: java.lang.ClassNotFoundException: >>>>> org.apache.http.impl.conn.PoolingClientConnectionManager from [Module >>>>> "org.jboss.resteasy.resteasy-jaxrs:main" from local module loader >>>>> @3efd2905 (roots >>>>> .0-alpha-1\modules)] >>>> This happens when deploying customer-portal. Any ideas? >>> I've never used distro-as7/ >>> >>> THese directions work and are what I do to run the demo: >>> >>> https://github.com/keycloak/keycloak/tree/master/examples/as7-eap-demo >>> >>> Errata: >>> >>> * Resteasy 3.0.5 instead of 3.0.4 >>> * There is no admin console registration page, only a login. >>> >>> username: admin >>> password: admin >>> >>> It will ask you to change the admin password. >>> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From bburke at redhat.com Thu Dec 5 20:25:11 2013 From: bburke at redhat.com (Bill Burke) Date: Thu, 05 Dec 2013 20:25:11 -0500 Subject: [keycloak-dev] resteasy dependencies before Alpha 1 In-Reply-To: <1946081466.24875168.1386273568246.JavaMail.root@redhat.com> References: <52A0D9A6.8040502@redhat.com> <1946081466.24875168.1386273568246.JavaMail.root@redhat.com> Message-ID: <52A12777.4010801@redhat.com> On 12/5/2013 2:59 PM, Stian Thorgersen wrote: > How are you planning that folks should run the examples? Will they use the dist and deploy/configure it to that (there's support for using -Dkeycloak.import=)? Or use the server.wars from the examples? I really don't understand why there's still DemoApplication and server WARs in the examples. > Yeah, I'm running behind this week. In-laws didn't leave until Tuesday. That's probably what we'll have to do. > Sounds like a release tomorrow is not going to happen. Could you setup Nexus and do a timstamped release for me tomorrow? I haven't managed to get write access to Nexus yet myself, so I can't do it.. > Yes, I'll do that. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From mcaspers at redhat.com Thu Dec 5 20:50:42 2013 From: mcaspers at redhat.com (Matt Casperson) Date: Thu, 5 Dec 2013 20:50:42 -0500 (EST) Subject: [keycloak-dev] Can KeyCloack be used without any passwords? In-Reply-To: <1721749635.1123162.1386293808149.JavaMail.root@redhat.com> Message-ID: <1216079021.1124829.1386294642732.JavaMail.root@redhat.com> I'd just like to say that KeyCloak looks like a great project. It will be nice not to have to reinvent the account management wheel every time you write an app. I have a couple of questions about KeyCloak: 1. After playing with the demo it looks like first time social logins require a local user account to be created. Is this a fixed requirement, or is it possible for people to log in from Google/Twitter/Facebook without a local user account? Or at least with a local account that has no password? I ask because ideally we would like to never deal with any user passwords whatsoever, and defer all password management to external services. 2. Do you expect the LDAP or AD support to work like a social login i.e. will users with local network accounts be required to create a KeyCloak user account in addition to their network account? 3. Is it possible to associate multiple social logins with a single account? Something like what Stack Exchange does where you can add a Google and a Facebook account to your existing SE account. Regards Matthew Casperson RHCE, RHCJA # 111-072-237 Red Hat Engineering Content Services Brisbane, Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20131205/4d6cb5e2/attachment.html From mcaspers at redhat.com Thu Dec 5 21:02:47 2013 From: mcaspers at redhat.com (Matt Casperson) Date: Thu, 5 Dec 2013 21:02:47 -0500 (EST) Subject: [keycloak-dev] Can KeyCloack be used without any passwords? In-Reply-To: <1216079021.1124829.1386294642732.JavaMail.root@redhat.com> References: <1216079021.1124829.1386294642732.JavaMail.root@redhat.com> Message-ID: <1761659165.1125842.1386295367312.JavaMail.root@redhat.com> Ok, just came across https://github.com/keycloak/keycloak/wiki/Registration-Authentication-with-social-providers-and-linking-of-social-accounts which answers some of these questions. Regards Matthew Casperson RHCE, RHCJA # 111-072-237 Engineering Content Services Brisbane, Australia ----- Original Message ----- From: "Matt Casperson" To: keycloak-dev at lists.jboss.org Sent: Friday, 6 December, 2013 11:50:42 AM Subject: [keycloak-dev] Can KeyCloack be used without any passwords? I'd just like to say that KeyCloak looks like a great project. It will be nice not to have to reinvent the account management wheel every time you write an app. I have a couple of questions about KeyCloak: 1. After playing with the demo it looks like first time social logins require a local user account to be created. Is this a fixed requirement, or is it possible for people to log in from Google/Twitter/Facebook without a local user account? Or at least with a local account that has no password? I ask because ideally we would like to never deal with any user passwords whatsoever, and defer all password management to external services. 2. Do you expect the LDAP or AD support to work like a social login i.e. will users with local network accounts be required to create a KeyCloak user account in addition to their network account? 3. Is it possible to associate multiple social logins with a single account? Something like what Stack Exchange does where you can add a Google and a Facebook account to your existing SE account. Regards Matthew Casperson RHCE, RHCJA # 111-072-237 Red Hat Engineering Content Services Brisbane, Australia _______________________________________________ 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/20131205/a8736d96/attachment.html From stian at redhat.com Fri Dec 6 04:38:48 2013 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 6 Dec 2013 04:38:48 -0500 (EST) Subject: [keycloak-dev] Can KeyCloack be used without any passwords? In-Reply-To: <1216079021.1124829.1386294642732.JavaMail.root@redhat.com> References: <1216079021.1124829.1386294642732.JavaMail.root@redhat.com> Message-ID: <226202651.25267890.1386322728588.JavaMail.root@redhat.com> Thanks for your feedback. The social integration is not complete yet, but we plan to add support for more networks and the ability to link multiple social logins with the same account soon. Yes, when a user first logs in with a social login we create an account. It doesn't have a password set, so by default the user can only login with the social login. The user can set a password if the user wants through the account management. Also, there's an option to require users to review their profile on first login with social login. For example Twitter doesn't provide email address, so if you require emails for user you can use this option to make sure all users will provide one. Made me think that someone may want to only allow social logins and completely disable password logins. We could provide an option to enable this, which would mean that on the login form only the social logins would be shown, and in the account management the reset password option wouldn't be displayed. Is that something you're interested in? With regards to LDAP/AD we haven't decided exactly how that'll work, but the current thinking is that we'll sync users to/from an LDAP/AD server into the Keycloak store. This will be fully automated and run in the background to provide a more or less consistent view between LDAP/AD and Keycloak. ----- Original Message ----- > From: "Matt Casperson" > To: keycloak-dev at lists.jboss.org > Sent: Friday, 6 December, 2013 1:50:42 AM > Subject: [keycloak-dev] Can KeyCloack be used without any passwords? > > I'd just like to say that KeyCloak looks like a great project. It will be > nice not to have to reinvent the account management wheel every time you > write an app. > > I have a couple of questions about KeyCloak: > > 1. After playing with the demo it looks like first time social logins require > a local user account to be created. Is this a fixed requirement, or is it > possible for people to log in from Google/Twitter/Facebook without a local > user account? Or at least with a local account that has no password? I ask > because ideally we would like to never deal with any user passwords > whatsoever, and defer all password management to external services. > > 2. Do you expect the LDAP or AD support to work like a social login i.e. will > users with local network accounts be required to create a KeyCloak user > account in addition to their network account? > > 3. Is it possible to associate multiple social logins with a single account? > Something like what Stack Exchange does where you can add a Google and a > Facebook account to your existing SE account. > > Regards > > Matthew Casperson > RHCE, RHCJA # 111-072-237 > Red Hat Engineering Content Services > Brisbane, Australia > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bburke at redhat.com Fri Dec 6 08:45:41 2013 From: bburke at redhat.com (Bill Burke) Date: Fri, 06 Dec 2013 08:45:41 -0500 Subject: [keycloak-dev] Can KeyCloack be used without any passwords? In-Reply-To: <226202651.25267890.1386322728588.JavaMail.root@redhat.com> References: <1216079021.1124829.1386294642732.JavaMail.root@redhat.com> <226202651.25267890.1386322728588.JavaMail.root@redhat.com> Message-ID: <52A1D505.8050407@redhat.com> Created a JIRA for social-only login: https://issues.jboss.org/browse/KEYCLOAK-211 On 12/6/2013 4:38 AM, Stian Thorgersen wrote: > Thanks for your feedback. The social integration is not complete yet, but we plan to add support for more networks and the ability to link multiple social logins with the same account soon. > > Yes, when a user first logs in with a social login we create an account. It doesn't have a password set, so by default the user can only login with the social login. The user can set a password if the user wants through the account management. Also, there's an option to require users to review their profile on first login with social login. For example Twitter doesn't provide email address, so if you require emails for user you can use this option to make sure all users will provide one. > > Made me think that someone may want to only allow social logins and completely disable password logins. We could provide an option to enable this, which would mean that on the login form only the social logins would be shown, and in the account management the reset password option wouldn't be displayed. Is that something you're interested in? > > With regards to LDAP/AD we haven't decided exactly how that'll work, but the current thinking is that we'll sync users to/from an LDAP/AD server into the Keycloak store. This will be fully automated and run in the background to provide a more or less consistent view between LDAP/AD and Keycloak. > > ----- Original Message ----- >> From: "Matt Casperson" >> To: keycloak-dev at lists.jboss.org >> Sent: Friday, 6 December, 2013 1:50:42 AM >> Subject: [keycloak-dev] Can KeyCloack be used without any passwords? >> >> I'd just like to say that KeyCloak looks like a great project. It will be >> nice not to have to reinvent the account management wheel every time you >> write an app. >> >> I have a couple of questions about KeyCloak: >> >> 1. After playing with the demo it looks like first time social logins require >> a local user account to be created. Is this a fixed requirement, or is it >> possible for people to log in from Google/Twitter/Facebook without a local >> user account? Or at least with a local account that has no password? I ask >> because ideally we would like to never deal with any user passwords >> whatsoever, and defer all password management to external services. >> >> 2. Do you expect the LDAP or AD support to work like a social login i.e. will >> users with local network accounts be required to create a KeyCloak user >> account in addition to their network account? >> >> 3. Is it possible to associate multiple social logins with a single account? >> Something like what Stack Exchange does where you can add a Google and a >> Facebook account to your existing SE account. >> >> Regards >> >> Matthew Casperson >> RHCE, RHCJA # 111-072-237 >> Red Hat Engineering Content Services >> Brisbane, Australia >> >> >> _______________________________________________ >> 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 bburke at redhat.com Fri Dec 6 09:47:16 2013 From: bburke at redhat.com (Bill Burke) Date: Fri, 06 Dec 2013 09:47:16 -0500 Subject: [keycloak-dev] timestamp repo release Message-ID: <52A1E374.7050209@redhat.com> Stian wanted a timestamp release: 1.0-alpha-1-12062013 Should be in repo now. Source also tagged with same name. Still working on things, hope to release alpha 1 early next week. Apologies for the delays. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From vrockai at redhat.com Fri Dec 6 10:32:58 2013 From: vrockai at redhat.com (Viliam Rockai) Date: Fri, 06 Dec 2013 16:32:58 +0100 Subject: [keycloak-dev] timestamp repo release In-Reply-To: <52A1E374.7050209@redhat.com> References: <52A1E374.7050209@redhat.com> Message-ID: <52A1EE2A.8020208@redhat.com> On 12/06/2013 03:47 PM, Bill Burke wrote: > Stian wanted a timestamp release: > > 1.0-alpha-1-12062013 > > Should be in repo now. Source also tagged with same name. > > Still working on things, hope to release alpha 1 early next week. > Apologies for the delays. I've retested the admin-console stuff yesterday and found many many small bugs (already created JIRAs for most of them), which I'm resolving right now. Something like two more days would be nice for me, too. > > From stian at redhat.com Fri Dec 6 12:34:13 2013 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 6 Dec 2013 12:34:13 -0500 (EST) Subject: [keycloak-dev] timestamp repo release In-Reply-To: <52A1E374.7050209@redhat.com> References: <52A1E374.7050209@redhat.com> Message-ID: <528961265.25672771.1386351253749.JavaMail.root@redhat.com> Thanks, Marek has also found a bunch of issues that'll need fixing for M1. With Christmas being pretty close now, and most people going into holiday mode, I was thinking it might be better to hold off until the New Years? We could still circulate a timestamped version internally though. For the website we should make it use the bootstrap theme that WildFly and Hibernate uses, it looks a bit more fresh then what we have now. Also, we need a logo! Once we've done the release it would be great to do a series of blog posts, and maybe some shorter videos that shows off a single feature (2 min length ish) ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Friday, 6 December, 2013 2:47:16 PM > Subject: [keycloak-dev] timestamp repo release > > Stian wanted a timestamp release: > > 1.0-alpha-1-12062013 > > Should be in repo now. Source also tagged with same name. > > Still working on things, hope to release alpha 1 early next week. > Apologies for the delays. > > > -- > 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 mcaspers at redhat.com Fri Dec 6 16:35:09 2013 From: mcaspers at redhat.com (Matt Casperson) Date: Fri, 6 Dec 2013 16:35:09 -0500 (EST) Subject: [keycloak-dev] Can KeyCloack be used without any passwords? In-Reply-To: <226202651.25267890.1386322728588.JavaMail.root@redhat.com> References: <1216079021.1124829.1386294642732.JavaMail.root@redhat.com> <226202651.25267890.1386322728588.JavaMail.root@redhat.com> Message-ID: <537985085.1619764.1386365709639.JavaMail.root@redhat.com> >Made me think that someone may want to only allow social logins and completely disable password logins. We could provide an option to enable this, which would mean that on the login form only the social logins would be shown, and in the account management the reset password option wouldn't be displayed. Is that something you're interested in? Most definitely. One of the goals we have is to eliminate the need for "yet another password", and disabling the ability to login via a site specific account goes a long way to eliminating that. For internal deployments there is no need for a local account, as there is always going to be a central user database to defer to. Which in turns gives us an administration team to deal with account management, a HR team to deal with incoming and outgoing employees, and a security team to deal with password policies. Out in public I think acceptance of social logins has reached a point where local accounts are now an inconvenience rather than a preference. And you benefit from all the hard work that that companies like Google have done with 2 factor authentication and account switching. These are all features that a small dev team would never have time to implement themselves. It also means we never have to be responsible for maintaining a password database. Every day it seems like there is news of another couple of million passwords stolen, with a high percentage subsequently decrypted, and a high percentage of those found to be shared with multiple other services. Simply not storing any user passwords is a good way to ensure you never have to send out a bulk "please change all your passwords" email. If KeyCloak could give us the ability to defer account and password management entirely to social logins or an existing LDAP/AD database with something as simple as a toggle in the admin console, it would be a huge win. Regards Matthew Casperson RHCE, RHCJA # 111-072-237 Engineering Content Services Brisbane, Australia ----- Original Message ----- From: "Stian Thorgersen" To: "Matt Casperson" Cc: keycloak-dev at lists.jboss.org Sent: Friday, 6 December, 2013 7:38:48 PM Subject: Re: [keycloak-dev] Can KeyCloack be used without any passwords? Thanks for your feedback. The social integration is not complete yet, but we plan to add support for more networks and the ability to link multiple social logins with the same account soon. Yes, when a user first logs in with a social login we create an account. It doesn't have a password set, so by default the user can only login with the social login. The user can set a password if the user wants through the account management. Also, there's an option to require users to review their profile on first login with social login. For example Twitter doesn't provide email address, so if you require emails for user you can use this option to make sure all users will provide one. Made me think that someone may want to only allow social logins and completely disable password logins. We could provide an option to enable this, which would mean that on the login form only the social logins would be shown, and in the account management the reset password option wouldn't be displayed. Is that something you're interested in? With regards to LDAP/AD we haven't decided exactly how that'll work, but the current thinking is that we'll sync users to/from an LDAP/AD server into the Keycloak store. This will be fully automated and run in the background to provide a more or less consistent view between LDAP/AD and Keycloak. ----- Original Message ----- > From: "Matt Casperson" > To: keycloak-dev at lists.jboss.org > Sent: Friday, 6 December, 2013 1:50:42 AM > Subject: [keycloak-dev] Can KeyCloack be used without any passwords? > > I'd just like to say that KeyCloak looks like a great project. It will be > nice not to have to reinvent the account management wheel every time you > write an app. > > I have a couple of questions about KeyCloak: > > 1. After playing with the demo it looks like first time social logins require > a local user account to be created. Is this a fixed requirement, or is it > possible for people to log in from Google/Twitter/Facebook without a local > user account? Or at least with a local account that has no password? I ask > because ideally we would like to never deal with any user passwords > whatsoever, and defer all password management to external services. > > 2. Do you expect the LDAP or AD support to work like a social login i.e. will > users with local network accounts be required to create a KeyCloak user > account in addition to their network account? > > 3. Is it possible to associate multiple social logins with a single account? > Something like what Stack Exchange does where you can add a Google and a > Facebook account to your existing SE account. > > Regards > > Matthew Casperson > RHCE, RHCJA # 111-072-237 > Red Hat Engineering Content Services > Brisbane, Australia > > > _______________________________________________ > 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/20131206/11ae1df5/attachment.html From bburke at redhat.com Fri Dec 6 17:54:21 2013 From: bburke at redhat.com (Bill Burke) Date: Fri, 06 Dec 2013 17:54:21 -0500 Subject: [keycloak-dev] Can KeyCloack be used without any passwords? In-Reply-To: <537985085.1619764.1386365709639.JavaMail.root@redhat.com> References: <1216079021.1124829.1386294642732.JavaMail.root@redhat.com> <226202651.25267890.1386322728588.JavaMail.root@redhat.com> <537985085.1619764.1386365709639.JavaMail.root@redhat.com> Message-ID: <52A2559D.2030500@redhat.com> On 12/6/2013 4:35 PM, Matt Casperson wrote: > If KeyCloak could give us the ability to defer account and password > management entirely to social logins or an existing LDAP/AD database > with something as simple as a toggle in the admin console, it would be a > huge win. > Keycloak aims to be an SSO solution, not an SSO adapter. For non-social deployments, account management is a huge part of what Keycloak does. Maybe I'm naive in thinking admins will want to use Keycloak to management accounts though. Even for social deployments, there's a lot of account management involved, i.e. managing oauth grants, registering devices, all things we want to be able to do. What is stored in LDAP/AD databases usually? user/password/credentials only? What about permissions/role mappings? Is doing a background sync to an LDAP/AD database not something people are going to want to do? Syncing means credentials are copied. Bill -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Fri Dec 6 18:00:09 2013 From: bburke at redhat.com (Bill Burke) Date: Fri, 06 Dec 2013 18:00:09 -0500 Subject: [keycloak-dev] realm import/upload implemented Message-ID: <52A256F9.1090504@redhat.com> Stian made a great point earlier. "How are you planning to run the demo?" Booting up the keycloak server with a System property is, well, kinda hacky/lame and not useful beyond demo purposes. So... I implemented realm import, file upload on the "CREATE REALM" page. So, on the create realm page, there are 2 fieldsets. One allows you to upload a json file, the other allows you to create a realm with a specific name. Importing/upload currently brings you to the realm list page. I'll fix that to redirect if possible. This new page may need some design. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Fri Dec 6 18:52:07 2013 From: bburke at redhat.com (Bill Burke) Date: Fri, 06 Dec 2013 18:52:07 -0500 Subject: [keycloak-dev] timestamp repo release In-Reply-To: <528961265.25672771.1386351253749.JavaMail.root@redhat.com> References: <52A1E374.7050209@redhat.com> <528961265.25672771.1386351253749.JavaMail.root@redhat.com> Message-ID: <52A26327.2080804@redhat.com> On 12/6/2013 12:34 PM, Stian Thorgersen wrote: > Thanks, > > Marek has also found a bunch of issues that'll need fixing for M1. > I don't see any blocker bugs. > With Christmas being pretty close now, and most people going into holiday mode, I was thinking it might be better to hold off until the New Years? We could still circulate a timestamped version internally though. > Nah. We have enough to do an alpha release. The bulk of the work is making install/bootstrap/distro/demo as ironclad and as easy to use and setup as possible. As well as the initial documentation. IMO, we have enough working features to release an alpha. > For the website we should make it use the bootstrap theme that WildFly and Hibernate uses, it looks a bit more fresh then what we have now. Also, we need a logo! > Need to find out where they host these sites. Not sure if its openshift or not. FYI, I did buy keycloak.org about 8 months ago. It points to jboss.org/keycloak at the moment. > Once we've done the release it would be great to do a series of blog posts, and maybe some shorter videos that shows off a single feature (2 min length ish) > I'm planning on doing a vid tutorial on the 2 demos. One is our current demo all set up via a file import. The other is actually manually setting up the demo via the admin console (creating the realm, apps, roles, users, role mappings, oauth client, scope, etc...) I wanted the doco to link to these 2 min vids too. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Sat Dec 7 05:20:09 2013 From: stian at redhat.com (Stian Thorgersen) Date: Sat, 7 Dec 2013 05:20:09 -0500 (EST) Subject: [keycloak-dev] timestamp repo release In-Reply-To: <52A26327.2080804@redhat.com> References: <52A1E374.7050209@redhat.com> <528961265.25672771.1386351253749.JavaMail.root@redhat.com> <52A26327.2080804@redhat.com> Message-ID: <1631192692.25972634.1386411609082.JavaMail.root@redhat.com> Maybe I didn't make it clear enough, but the reason I was thinking to hold off until after Christmas is that I think it might have a bigger impact if released in January. I certainly will be reading less blogs, emails, etc. over the holidays, and would assume that quite a lot of other people would as well. ----- Original Message ----- > From: "Bill Burke" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Friday, 6 December, 2013 11:52:07 PM > Subject: Re: [keycloak-dev] timestamp repo release > > > > On 12/6/2013 12:34 PM, Stian Thorgersen wrote: > > Thanks, > > > > Marek has also found a bunch of issues that'll need fixing for M1. > > > > I don't see any blocker bugs. > > > With Christmas being pretty close now, and most people going into holiday > > mode, I was thinking it might be better to hold off until the New Years? > > We could still circulate a timestamped version internally though. > > > > Nah. We have enough to do an alpha release. The bulk of the work is > making install/bootstrap/distro/demo as ironclad and as easy to use and > setup as possible. As well as the initial documentation. IMO, we have > enough working features to release an alpha. > > > For the website we should make it use the bootstrap theme that WildFly and > > Hibernate uses, it looks a bit more fresh then what we have now. Also, we > > need a logo! > > > > Need to find out where they host these sites. Not sure if its openshift > or not. FYI, I did buy keycloak.org about 8 months ago. It points to > jboss.org/keycloak at the moment. > > > Once we've done the release it would be great to do a series of blog posts, > > and maybe some shorter videos that shows off a single feature (2 min > > length ish) > > > > I'm planning on doing a vid tutorial on the 2 demos. One is our current > demo all set up via a file import. The other is actually manually > setting up the demo via the admin console (creating the realm, apps, > roles, users, role mappings, oauth client, scope, etc...) > > I wanted the doco to link to these 2 min vids too. > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > From stian at redhat.com Sat Dec 7 05:26:14 2013 From: stian at redhat.com (Stian Thorgersen) Date: Sat, 7 Dec 2013 05:26:14 -0500 (EST) Subject: [keycloak-dev] realm import/upload implemented In-Reply-To: <52A256F9.1090504@redhat.com> References: <52A256F9.1090504@redhat.com> Message-ID: <268738801.25973492.1386411974554.JavaMail.root@redhat.com> Nice :) It does indeed need some design touches, Gabriel? ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Friday, 6 December, 2013 11:00:09 PM > Subject: [keycloak-dev] realm import/upload implemented > > Stian made a great point earlier. "How are you planning to run the > demo?" Booting up the keycloak server with a System property is, well, > kinda hacky/lame and not useful beyond demo purposes. > > So... > > I implemented realm import, file upload on the "CREATE REALM" page. So, > on the create realm page, there are 2 fieldsets. One allows you to > upload a json file, the other allows you to create a realm with a > specific name. Importing/upload currently brings you to the realm list > page. I'll fix that to redirect if possible. > > This new page may need some design. > -- > 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 mcaspers at redhat.com Sat Dec 7 15:20:51 2013 From: mcaspers at redhat.com (Matt Casperson) Date: Sat, 7 Dec 2013 15:20:51 -0500 (EST) Subject: [keycloak-dev] Can KeyCloack be used without any passwords? In-Reply-To: <52A2559D.2030500@redhat.com> References: <1216079021.1124829.1386294642732.JavaMail.root@redhat.com> <226202651.25267890.1386322728588.JavaMail.root@redhat.com> <537985085.1619764.1386365709639.JavaMail.root@redhat.com> <52A2559D.2030500@redhat.com> Message-ID: <983318239.1700119.1386447651518.JavaMail.root@redhat.com> I certainly don't mean to downplay the value of being able to manage accounts. Being able to assign custom roles that are not reflected in LDAP/AD is going to be important, and necessary for social logins. And even though we would prefer not deal with local passwords, being able to support that feature with a toggle in a UI is a selling point. Regards Matthew Casperson RHCE, RHCJA # 111-072-237 Engineering Content Services Brisbane, Australia ----- Original Message ----- From: "Bill Burke" To: keycloak-dev at lists.jboss.org Sent: Saturday, 7 December, 2013 8:54:21 AM Subject: Re: [keycloak-dev] Can KeyCloack be used without any passwords? On 12/6/2013 4:35 PM, Matt Casperson wrote: > If KeyCloak could give us the ability to defer account and password > management entirely to social logins or an existing LDAP/AD database > with something as simple as a toggle in the admin console, it would be a > huge win. > Keycloak aims to be an SSO solution, not an SSO adapter. For non-social deployments, account management is a huge part of what Keycloak does. Maybe I'm naive in thinking admins will want to use Keycloak to management accounts though. Even for social deployments, there's a lot of account management involved, i.e. managing oauth grants, registering devices, all things we want to be able to do. What is stored in LDAP/AD databases usually? user/password/credentials only? What about permissions/role mappings? Is doing a background sync to an LDAP/AD database not something people are going to want to do? Syncing means credentials are copied. Bill -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20131207/1b8ad53e/attachment.html From mcaspers at redhat.com Sun Dec 8 16:44:03 2013 From: mcaspers at redhat.com (Matt Casperson) Date: Sun, 8 Dec 2013 16:44:03 -0500 (EST) Subject: [keycloak-dev] Can a master list of roles be retrieved? In-Reply-To: <945843192.1756456.1386538667528.JavaMail.root@redhat.com> Message-ID: <115012175.1756661.1386539043493.JavaMail.root@redhat.com> If I wanted my client application's UI to be able to authorise roles to perform certain actions, could I query a KeyCloak server for the master list? An example might be listing all the roles so I could select those that should be able to edit a particular record. So rather than manually syncing a list of roles between my application and KeyCloak, I would query the KeyCloak server for the current list of roles to ensure that I always have an accurate list. Regards Matthew Casperson RHCE, RHCJA # 111-072-237 Engineering Content Services Brisbane, Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20131208/cefc3c8b/attachment.html From gcardoso at redhat.com Mon Dec 9 08:28:25 2013 From: gcardoso at redhat.com (Gabriel Cardoso) Date: Mon, 9 Dec 2013 11:28:25 -0200 Subject: [keycloak-dev] timestamp repo release In-Reply-To: <1631192692.25972634.1386411609082.JavaMail.root@redhat.com> References: <52A1E374.7050209@redhat.com> <528961265.25672771.1386351253749.JavaMail.root@redhat.com> <52A26327.2080804@redhat.com> <1631192692.25972634.1386411609082.JavaMail.root@redhat.com> Message-ID: <72A180F1-684F-4287-AC28-D7BA04476CE5@redhat.com> I share the same view as you, Stian. Also, new year, new project, sounds better :) On Dec 7, 2013, at 8:20 AM, Stian Thorgersen wrote: > Maybe I didn't make it clear enough, but the reason I was thinking to hold off until after Christmas is that I think it might have a bigger impact if released in January. I certainly will be reading less blogs, emails, etc. over the holidays, and would assume that quite a lot of other people would as well. > > ----- Original Message ----- >> From: "Bill Burke" >> To: "Stian Thorgersen" >> Cc: keycloak-dev at lists.jboss.org >> Sent: Friday, 6 December, 2013 11:52:07 PM >> Subject: Re: [keycloak-dev] timestamp repo release >> >> >> >> On 12/6/2013 12:34 PM, Stian Thorgersen wrote: >>> Thanks, >>> >>> Marek has also found a bunch of issues that'll need fixing for M1. >>> >> >> I don't see any blocker bugs. >> >>> With Christmas being pretty close now, and most people going into holiday >>> mode, I was thinking it might be better to hold off until the New Years? >>> We could still circulate a timestamped version internally though. >>> >> >> Nah. We have enough to do an alpha release. The bulk of the work is >> making install/bootstrap/distro/demo as ironclad and as easy to use and >> setup as possible. As well as the initial documentation. IMO, we have >> enough working features to release an alpha. >> >>> For the website we should make it use the bootstrap theme that WildFly and >>> Hibernate uses, it looks a bit more fresh then what we have now. Also, we >>> need a logo! >>> >> >> Need to find out where they host these sites. Not sure if its openshift >> or not. FYI, I did buy keycloak.org about 8 months ago. It points to >> jboss.org/keycloak at the moment. >> >>> Once we've done the release it would be great to do a series of blog posts, >>> and maybe some shorter videos that shows off a single feature (2 min >>> length ish) >>> >> >> I'm planning on doing a vid tutorial on the 2 demos. One is our current >> demo all set up via a file import. The other is actually manually >> setting up the demo via the admin console (creating the realm, apps, >> roles, users, role mappings, oauth client, scope, etc...) >> >> I wanted the doco to link to these 2 min vids too. >> >> -- >> 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 -- Gabriel Cardoso GateIn Portal | User Experience Designer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20131209/455fab63/attachment.html From bburke at redhat.com Mon Dec 9 08:50:51 2013 From: bburke at redhat.com (Bill Burke) Date: Mon, 09 Dec 2013 08:50:51 -0500 Subject: [keycloak-dev] Can a master list of roles be retrieved? In-Reply-To: <115012175.1756661.1386539043493.JavaMail.root@redhat.com> References: <115012175.1756661.1386539043493.JavaMail.root@redhat.com> Message-ID: <52A5CABB.5060900@redhat.com> I don't know why you'd want to sync with any master list, but you could. The Keycloak Admin REST interface is itself an application with roles assign to it. Each application is itself a User. So you'd just assign a Admin API role and the application could query for anything it wanted (based on its permissions). Most applications will inheritantly know which roles they require. Role mappings are contained within the token they receive from the auth-server. They idea is that security-wise, applications become stateless. This is especially important for REST services that aim to be completely stateless. On 12/8/2013 4:44 PM, Matt Casperson wrote: > If I wanted my client application's UI to be able to authorise roles to > perform certain actions, could I query a KeyCloak server for the master > list? > > An example might be listing all the roles so I could select those that > should be able to edit a particular record. So rather than manually > syncing a list of roles between my application and KeyCloak, I would > query the KeyCloak server for the current list of roles to ensure that I > always have an accurate list. > > Regards > > Matthew Casperson > RHCE, RHCJA # 111-072-237 > > Engineering Content Services > Brisbane, Australia > > > > _______________________________________________ > 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 bburke at redhat.com Mon Dec 9 08:51:22 2013 From: bburke at redhat.com (Bill Burke) Date: Mon, 09 Dec 2013 08:51:22 -0500 Subject: [keycloak-dev] timestamp repo release In-Reply-To: <72A180F1-684F-4287-AC28-D7BA04476CE5@redhat.com> References: <52A1E374.7050209@redhat.com> <528961265.25672771.1386351253749.JavaMail.root@redhat.com> <52A26327.2080804@redhat.com> <1631192692.25972634.1386411609082.JavaMail.root@redhat.com> <72A180F1-684F-4287-AC28-D7BA04476CE5@redhat.com> Message-ID: <52A5CADA.3060009@redhat.com> You win. We'll release early January. I honestly have a bunch of Resteasy work to do this week anyways. On 12/9/2013 8:28 AM, Gabriel Cardoso wrote: > I share the same view as you, Stian. Also, new year, new project, > sounds better :) > > On Dec 7, 2013, at 8:20 AM, Stian Thorgersen wrote: > >> Maybe I didn't make it clear enough, but the reason I was thinking to >> hold off until after Christmas is that I think it might have a bigger >> impact if released in January. I certainly will be reading less blogs, >> emails, etc. over the holidays, and would assume that quite a lot of >> other people would as well. >> >> ----- Original Message ----- >>> From: "Bill Burke" > >>> To: "Stian Thorgersen" > >>> Cc: keycloak-dev at lists.jboss.org >>> Sent: Friday, 6 December, 2013 11:52:07 PM >>> Subject: Re: [keycloak-dev] timestamp repo release >>> >>> >>> >>> On 12/6/2013 12:34 PM, Stian Thorgersen wrote: >>>> Thanks, >>>> >>>> Marek has also found a bunch of issues that'll need fixing for M1. >>>> >>> >>> I don't see any blocker bugs. >>> >>>> With Christmas being pretty close now, and most people going into >>>> holiday >>>> mode, I was thinking it might be better to hold off until the New Years? >>>> We could still circulate a timestamped version internally though. >>>> >>> >>> Nah. We have enough to do an alpha release. The bulk of the work is >>> making install/bootstrap/distro/demo as ironclad and as easy to use and >>> setup as possible. As well as the initial documentation. IMO, we have >>> enough working features to release an alpha. >>> >>>> For the website we should make it use the bootstrap theme that >>>> WildFly and >>>> Hibernate uses, it looks a bit more fresh then what we have now. >>>> Also, we >>>> need a logo! >>>> >>> >>> Need to find out where they host these sites. Not sure if its openshift >>> or not. FYI, I did buy keycloak.org about 8 >>> months ago. It points to >>> jboss.org/keycloak at the moment. >>> >>>> Once we've done the release it would be great to do a series of blog >>>> posts, >>>> and maybe some shorter videos that shows off a single feature (2 min >>>> length ish) >>>> >>> >>> I'm planning on doing a vid tutorial on the 2 demos. One is our current >>> demo all set up via a file import. The other is actually manually >>> setting up the demo via the admin console (creating the realm, apps, >>> roles, users, role mappings, oauth client, scope, etc...) >>> >>> I wanted the doco to link to these 2 min vids too. >>> >>> -- >>> 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 > > > -- > Gabriel Cardoso > GateIn Portal | User Experience Designer > > > > > _______________________________________________ > 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 bburke at redhat.com Mon Dec 9 10:01:45 2013 From: bburke at redhat.com (Bill Burke) Date: Mon, 09 Dec 2013 10:01:45 -0500 Subject: [keycloak-dev] timestamp repo release In-Reply-To: <52A5CADA.3060009@redhat.com> References: <52A1E374.7050209@redhat.com> <528961265.25672771.1386351253749.JavaMail.root@redhat.com> <52A26327.2080804@redhat.com> <1631192692.25972634.1386411609082.JavaMail.root@redhat.com> <72A180F1-684F-4287-AC28-D7BA04476CE5@redhat.com> <52A5CADA.3060009@redhat.com> Message-ID: <52A5DB59.7090107@redhat.com> Delaying now, we can distribute with Wildfly instead. Beta2/CR1 should be ready so I'll be able to finish the wildfly adapter. On 12/9/2013 8:51 AM, Bill Burke wrote: > You win. We'll release early January. I honestly have a bunch of > Resteasy work to do this week anyways. > > On 12/9/2013 8:28 AM, Gabriel Cardoso wrote: >> I share the same view as you, Stian. Also, new year, new project, >> sounds better :) >> >> On Dec 7, 2013, at 8:20 AM, Stian Thorgersen wrote: >> >>> Maybe I didn't make it clear enough, but the reason I was thinking to >>> hold off until after Christmas is that I think it might have a bigger >>> impact if released in January. I certainly will be reading less blogs, >>> emails, etc. over the holidays, and would assume that quite a lot of >>> other people would as well. >>> >>> ----- Original Message ----- >>>> From: "Bill Burke" > >>>> To: "Stian Thorgersen" > >>>> Cc: keycloak-dev at lists.jboss.org >>>> Sent: Friday, 6 December, 2013 11:52:07 PM >>>> Subject: Re: [keycloak-dev] timestamp repo release >>>> >>>> >>>> >>>> On 12/6/2013 12:34 PM, Stian Thorgersen wrote: >>>>> Thanks, >>>>> >>>>> Marek has also found a bunch of issues that'll need fixing for M1. >>>>> >>>> >>>> I don't see any blocker bugs. >>>> >>>>> With Christmas being pretty close now, and most people going into >>>>> holiday >>>>> mode, I was thinking it might be better to hold off until the New Years? >>>>> We could still circulate a timestamped version internally though. >>>>> >>>> >>>> Nah. We have enough to do an alpha release. The bulk of the work is >>>> making install/bootstrap/distro/demo as ironclad and as easy to use and >>>> setup as possible. As well as the initial documentation. IMO, we have >>>> enough working features to release an alpha. >>>> >>>>> For the website we should make it use the bootstrap theme that >>>>> WildFly and >>>>> Hibernate uses, it looks a bit more fresh then what we have now. >>>>> Also, we >>>>> need a logo! >>>>> >>>> >>>> Need to find out where they host these sites. Not sure if its openshift >>>> or not. FYI, I did buy keycloak.org about 8 >>>> months ago. It points to >>>> jboss.org/keycloak at the moment. >>>> >>>>> Once we've done the release it would be great to do a series of blog >>>>> posts, >>>>> and maybe some shorter videos that shows off a single feature (2 min >>>>> length ish) >>>>> >>>> >>>> I'm planning on doing a vid tutorial on the 2 demos. One is our current >>>> demo all set up via a file import. The other is actually manually >>>> setting up the demo via the admin console (creating the realm, apps, >>>> roles, users, role mappings, oauth client, scope, etc...) >>>> >>>> I wanted the doco to link to these 2 min vids too. >>>> >>>> -- >>>> 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 >> >> >> -- >> Gabriel Cardoso >> GateIn Portal | User Experience Designer >> >> >> >> >> _______________________________________________ >> 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 ssilvert at redhat.com Mon Dec 9 13:07:52 2013 From: ssilvert at redhat.com (ssilvert at redhat.com) Date: Mon, 09 Dec 2013 13:07:52 -0500 Subject: [keycloak-dev] Can a master list of roles be retrieved? In-Reply-To: <52A5CABB.5060900@redhat.com> References: <115012175.1756661.1386539043493.JavaMail.root@redhat.com> <52A5CABB.5060900@redhat.com> Message-ID: <52A606F8.8000501@redhat.com> On 12/9/2013 8:50 AM, Bill Burke wrote: > I don't know why you'd want to sync with any master list, but you could. > The Keycloak Admin REST interface is itself an application with roles > assign to it. Each application is itself a User. So you'd just assign > a Admin API role and the application could query for anything it wanted > (based on its permissions). > > Most applications will inheritantly know which roles they require. Role > mappings are contained within the token they receive from the > auth-server. They idea is that security-wise, applications become > stateless. This is especially important for REST services that aim to > be completely stateless. I'd go even further. I think an application will ALWAYS know which roles it requires. I just can't think of a time where that is not true except for the degenerate case where the application is built without any roles at all. The example of selecting which roles should edit a particular record doesn't make sense to me. Keycloak wouldn't define that because Keycloak doesn't understand what those records are used for. The application has to define those roles because the application understands the context. It seems to me that any sync that must be done should actually go the other direction. A Keycloak subsystem (which I'm starting on today), should attempt to find out which roles are declared in the application and then let Keycloak know about them at deploy time. > > On 12/8/2013 4:44 PM, Matt Casperson wrote: >> If I wanted my client application's UI to be able to authorise roles to >> perform certain actions, could I query a KeyCloak server for the master >> list? >> >> An example might be listing all the roles so I could select those that >> should be able to edit a particular record. So rather than manually >> syncing a list of roles between my application and KeyCloak, I would >> query the KeyCloak server for the current list of roles to ensure that I >> always have an accurate list. >> >> Regards >> >> Matthew Casperson >> RHCE, RHCJA # 111-072-237 >> >> Engineering Content Services >> Brisbane, Australia >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From ssilvert at redhat.com Mon Dec 9 14:19:30 2013 From: ssilvert at redhat.com (ssilvert at redhat.com) Date: Mon, 09 Dec 2013 14:19:30 -0500 Subject: [keycloak-dev] Keycloak subsystem Message-ID: <52A617C2.2050907@redhat.com> In Thunderlips, we have a requirement that console applications should not be required to know where the Keycloak server resides at build time. Furthermore, an administrator should not need to crack open a WAR to include this information. Instead, the application should learn about its environment at deploy time. Picketlink already has this capability, but I think we can go beyond what it currently offers. The basic idea for the Keycloak subsystem is that no application should ever need to define anything about authentication. At development time, the application should not need to know anything about Keycloak or really anything about authentication at all. The application should only need to know about authorization and the roles it wants to define. So using the Keycloak subsystem, an application will not be required to use: * keycloak.json * jboss-web.xml * jboss-deployment-structure.xml (Did I leave anything out? It looks like this is what an app currently needs to work with Keycloak.) >From the Keycloak admin UI, you will be able to choose an application and add it to a Keycloak realm. When that application is deployed, the Keycloak subsystem adds all that used to be defined in keycloak.json, jboss-web.xml, and jboss-deployment-structure.xml. The big picture is that a developer never needs to think about authentication. And an administrators never need to crack open a WAR or worry about what authentication was built into some WAR he wants to deploy. WDYT? Stan From bburke at redhat.com Mon Dec 9 14:39:25 2013 From: bburke at redhat.com (Bill Burke) Date: Mon, 09 Dec 2013 14:39:25 -0500 Subject: [keycloak-dev] Keycloak subsystem In-Reply-To: <52A617C2.2050907@redhat.com> References: <52A617C2.2050907@redhat.com> Message-ID: <52A61C6D.5000406@redhat.com> Yes, definitely all features I envisioned we would have. The only thing I'm not sure how to handle is application credentials. I think Picketlink is doing something very similar via WS Trust. Not sure though as I've stayed clear from WS-* pretty much. OAuth protocol requires that applications ("clients") have their own credentials. They send these credentials when an Auth Code is turned into an Auth Token. Maybe we need something like a "Server Instance" that is allowed to request auth tokens on behalf of an application. On 12/9/2013 2:19 PM, ssilvert at redhat.com wrote: > In Thunderlips, we have a requirement that console applications should > not be required to know where the Keycloak server resides at build > time. Furthermore, an administrator should not need to crack open a WAR > to include this information. Instead, the application should learn > about its environment at deploy time. > > Picketlink already has this capability, but I think we can go beyond > what it currently offers. The basic idea for the Keycloak subsystem is > that no application should ever need to define anything about > authentication. At development time, the application should not need to > know anything about Keycloak or really anything about authentication at > all. The application should only need to know about authorization and > the roles it wants to define. > > So using the Keycloak subsystem, an application will not be required to use: > * keycloak.json > * jboss-web.xml > * jboss-deployment-structure.xml > (Did I leave anything out? It looks like this is what an app currently > needs to work with Keycloak.) > >>From the Keycloak admin UI, you will be able to choose an application > and add it to a Keycloak realm. When that application is deployed, the > Keycloak subsystem adds all that used to be defined in keycloak.json, > jboss-web.xml, and jboss-deployment-structure.xml. > > The big picture is that a developer never needs to think about > authentication. And an administrators never need to crack open a WAR or > worry about what authentication was built into some WAR he wants to deploy. > > WDYT? > > 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 bburke at redhat.com Mon Dec 9 14:40:32 2013 From: bburke at redhat.com (Bill Burke) Date: Mon, 09 Dec 2013 14:40:32 -0500 Subject: [keycloak-dev] can finish up wildfly adapter Message-ID: <52A61CB0.30508@redhat.com> Stuart tells me that the security and deployment SPIs should be all set. So I can finish up the Wildfly adapter now. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From ssilvert at redhat.com Mon Dec 9 15:00:46 2013 From: ssilvert at redhat.com (ssilvert at redhat.com) Date: Mon, 09 Dec 2013 15:00:46 -0500 Subject: [keycloak-dev] can finish up wildfly adapter In-Reply-To: <52A61CB0.30508@redhat.com> References: <52A61CB0.30508@redhat.com> Message-ID: <52A6216E.2060900@redhat.com> On 12/9/2013 2:40 PM, Bill Burke wrote: > Stuart tells me that the security and deployment SPIs should be all set. > So I can finish up the Wildfly adapter now. Great! How important is it to target EAP 6 for the Keycloak subsystem? I'd prefer to only write it for WildFly/Undertow. From gcardoso at redhat.com Mon Dec 9 15:14:07 2013 From: gcardoso at redhat.com (Gabriel Cardoso) Date: Mon, 9 Dec 2013 18:14:07 -0200 Subject: [keycloak-dev] Cancel button in the login page Message-ID: <9046F10B-5BE2-4655-85D4-ADB4888A91E0@redhat.com> What is the reason for a Cancel button in the login page? Called my attention see a Cancel button when accessing to the login page immediately after opening the browser. Also, clicking on it redirected me to a empty white screen. -- Gabriel Cardoso GateIn Portal | User Experience Designer From mcaspers at redhat.com Mon Dec 9 18:06:28 2013 From: mcaspers at redhat.com (Matt Casperson) Date: Mon, 9 Dec 2013 18:06:28 -0500 (EST) Subject: [keycloak-dev] Can a master list of roles be retrieved? In-Reply-To: <52A606F8.8000501@redhat.com> References: <115012175.1756661.1386539043493.JavaMail.root@redhat.com> <52A5CABB.5060900@redhat.com> <52A606F8.8000501@redhat.com> Message-ID: <1904756015.2469228.1386630388188.JavaMail.root@redhat.com> I was thinking about roles like user groups in a file system, which may not be the correct use of roles, but in any case syncing from the app to KeyCloak is a better solution. Regards Matthew Casperson RHCE, RHCJA # 111-072-237 Engineering Content Services Brisbane, Australia ----- Original Message ----- From: ssilvert at redhat.com To: keycloak-dev at lists.jboss.org Sent: Tuesday, 10 December, 2013 4:07:52 AM Subject: Re: [keycloak-dev] Can a master list of roles be retrieved? On 12/9/2013 8:50 AM, Bill Burke wrote: > I don't know why you'd want to sync with any master list, but you could. > The Keycloak Admin REST interface is itself an application with roles > assign to it. Each application is itself a User. So you'd just assign > a Admin API role and the application could query for anything it wanted > (based on its permissions). > > Most applications will inheritantly know which roles they require. Role > mappings are contained within the token they receive from the > auth-server. They idea is that security-wise, applications become > stateless. This is especially important for REST services that aim to > be completely stateless. I'd go even further. I think an application will ALWAYS know which roles it requires. I just can't think of a time where that is not true except for the degenerate case where the application is built without any roles at all. The example of selecting which roles should edit a particular record doesn't make sense to me. Keycloak wouldn't define that because Keycloak doesn't understand what those records are used for. The application has to define those roles because the application understands the context. It seems to me that any sync that must be done should actually go the other direction. A Keycloak subsystem (which I'm starting on today), should attempt to find out which roles are declared in the application and then let Keycloak know about them at deploy time. > > On 12/8/2013 4:44 PM, Matt Casperson wrote: >> If I wanted my client application's UI to be able to authorise roles to >> perform certain actions, could I query a KeyCloak server for the master >> list? >> >> An example might be listing all the roles so I could select those that >> should be able to edit a particular record. So rather than manually >> syncing a list of roles between my application and KeyCloak, I would >> query the KeyCloak server for the current list of roles to ensure that I >> always have an accurate list. >> >> Regards >> >> Matthew Casperson >> RHCE, RHCJA # 111-072-237 >> >> Engineering Content Services >> Brisbane, Australia >> >> >> >> _______________________________________________ >> 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/20131209/edf88229/attachment-0001.html From gcardoso at redhat.com Mon Dec 9 21:42:01 2013 From: gcardoso at redhat.com (Gabriel Cardoso) Date: Tue, 10 Dec 2013 00:42:01 -0200 Subject: [keycloak-dev] Consistency and standards Message-ID: <73A481F1-6D78-4D27-BFC3-94E22E3458AF@redhat.com> When adding new elements to the interface, it is important to maintain consistency, using the same standards already used in the interface. Here are two examples: Standard: main action at the right side Inconsistency: main action at the left side in the login screen Standard: dark tooltip Inconsistency: white tooltip in the credentials page Could you guys update them to follow the standards? Also, if you have any doubt when implementing something new, let me know. Gabriel -- Gabriel Cardoso GateIn Portal | User Experience Designer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20131210/567779f6/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2013-12-10 at 12.34.00 AM.png Type: image/png Size: 11085 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20131210/567779f6/attachment-0004.png -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2013-12-10 at 12.34.48 AM.png Type: image/png Size: 9903 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20131210/567779f6/attachment-0005.png -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2013-12-10 at 12.37.14 AM.png Type: image/png Size: 11347 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20131210/567779f6/attachment-0006.png -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2013-12-10 at 12.38.12 AM.png Type: image/png Size: 13680 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20131210/567779f6/attachment-0007.png From gcardoso at redhat.com Mon Dec 9 22:42:40 2013 From: gcardoso at redhat.com (Gabriel Cardoso) Date: Tue, 10 Dec 2013 01:42:40 -0200 Subject: [keycloak-dev] realm import/upload implemented In-Reply-To: <268738801.25973492.1386411974554.JavaMail.root@redhat.com> References: <52A256F9.1090504@redhat.com> <268738801.25973492.1386411974554.JavaMail.root@redhat.com> Message-ID: Definitely! I'll work on a design for it :) On Dec 7, 2013, at 8:26 AM, Stian Thorgersen wrote: > Nice :) > > It does indeed need some design touches, Gabriel? > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Friday, 6 December, 2013 11:00:09 PM >> Subject: [keycloak-dev] realm import/upload implemented >> >> Stian made a great point earlier. "How are you planning to run the >> demo?" Booting up the keycloak server with a System property is, well, >> kinda hacky/lame and not useful beyond demo purposes. >> >> So... >> >> I implemented realm import, file upload on the "CREATE REALM" page. So, >> on the create realm page, there are 2 fieldsets. One allows you to >> upload a json file, the other allows you to create a realm with a >> specific name. Importing/upload currently brings you to the realm list >> page. I'll fix that to redirect if possible. >> >> This new page may need some design. >> -- >> 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 -- Gabriel Cardoso GateIn Portal | User Experience Designer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20131210/2cc88099/attachment.html From stian at redhat.com Tue Dec 10 04:25:35 2013 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 10 Dec 2013 04:25:35 -0500 (EST) Subject: [keycloak-dev] Cancel button in the login page In-Reply-To: <9046F10B-5BE2-4655-85D4-ADB4888A91E0@redhat.com> References: <9046F10B-5BE2-4655-85D4-ADB4888A91E0@redhat.com> Message-ID: <1674616197.27481345.1386667535680.JavaMail.root@redhat.com> It takes the user back to the application without login ----- Original Message ----- > From: "Gabriel Cardoso" > To: keycloak-dev at lists.jboss.org > Sent: Monday, 9 December, 2013 8:14:07 PM > Subject: [keycloak-dev] Cancel button in the login page > > What is the reason for a Cancel button in the login page? > > Called my attention see a Cancel button when accessing to the login page > immediately after opening the browser. Also, clicking on it redirected me to > a empty white screen. > > -- > Gabriel Cardoso > GateIn Portal | User Experience Designer > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From stian at redhat.com Tue Dec 10 04:40:13 2013 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 10 Dec 2013 04:40:13 -0500 (EST) Subject: [keycloak-dev] Consistency and standards In-Reply-To: <73A481F1-6D78-4D27-BFC3-94E22E3458AF@redhat.com> References: <73A481F1-6D78-4D27-BFC3-94E22E3458AF@redhat.com> Message-ID: <109679351.27487481.1386668413707.JavaMail.root@redhat.com> Why is the main action on the right side? That's the opposite of what the html spec does (first button is the default button) + it doesn't make sense in a left-to-right language ----- Original Message ----- > From: "Gabriel Cardoso" > To: keycloak-dev at lists.jboss.org > Sent: Tuesday, 10 December, 2013 2:42:01 AM > Subject: [keycloak-dev] Consistency and standards > > When adding new elements to the interface, it is important to maintain > consistency, using the same standards already used in the interface. Here > are two examples: > > Standard: main action at the right side > Inconsistency: main action at the left side in the login screen > > > > > Standard: dark tooltip > > Inconsistency: white tooltip in the credentials page > > Could you guys update them to follow the standards? > > Also, if you have any doubt when implementing something new, let me know. > > Gabriel > > -- > Gabriel Cardoso > GateIn Portal | User Experience Designer > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From mposolda at redhat.com Tue Dec 10 11:20:32 2013 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 10 Dec 2013 17:20:32 +0100 Subject: [keycloak-dev] Require SSL option Message-ID: <52A73F50.1050508@redhat.com> Hi, I would like to ask what exactly is semantics of realm option "Require SSL"? My first impression is that if this option is enabled, then access to URI like "http://localhost:8080/auth-server/rest/realms/demo/..." should be allowed just with 'https' protocol instead of plain 'http'. Actually http access to realm is enabled and login works. Option is used just for securing cookies like KEYCLOAK_IDENTITY, so that SSO reauthentication with cookies is effectively disabled. But shouldn't we rename this option to something "Use secured cookie" then? Name "Require SSL" seems to be confusing IMO. There is also one more issue https://issues.jboss.org/browse/KEYCLOAK-227 due to the fact that option doesn't affect just KEYCLOAK_IDENTITY cookie but also KEYCLOAK_ACCOUNT_IDENTITY, which means that I am always redirected back to login form after successful login in case that login has been triggered for AccountManagement application. WDYT? Marek From mposolda at redhat.com Tue Dec 10 11:30:50 2013 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 10 Dec 2013 17:30:50 +0100 Subject: [keycloak-dev] timestamp repo release In-Reply-To: <52A5CADA.3060009@redhat.com> References: <52A1E374.7050209@redhat.com> <528961265.25672771.1386351253749.JavaMail.root@redhat.com> <52A26327.2080804@redhat.com> <1631192692.25972634.1386411609082.JavaMail.root@redhat.com> <72A180F1-684F-4287-AC28-D7BA04476CE5@redhat.com> <52A5CADA.3060009@redhat.com> Message-ID: <52A741BA.3060603@redhat.com> In case you are not aware, I would like to point you to https://issues.jboss.org/browse/KEYCLOAK-223 which looks like a Resteasy packaging issue. Actually I reported it to KEYCLOAK jira because I reproduced it during deployment of Keycloak:-) Marek On 9.12.2013 14:51, Bill Burke wrote: > You win. We'll release early January. I honestly have a bunch of > Resteasy work to do this week anyways. > > On 12/9/2013 8:28 AM, Gabriel Cardoso wrote: >> I share the same view as you, Stian. Also, new year, new project, >> sounds better :) >> >> On Dec 7, 2013, at 8:20 AM, Stian Thorgersen wrote: >> >>> Maybe I didn't make it clear enough, but the reason I was thinking to >>> hold off until after Christmas is that I think it might have a bigger >>> impact if released in January. I certainly will be reading less blogs, >>> emails, etc. over the holidays, and would assume that quite a lot of >>> other people would as well. >>> >>> ----- Original Message ----- >>>> From: "Bill Burke" > >>>> To: "Stian Thorgersen" > >>>> Cc: keycloak-dev at lists.jboss.org >>>> Sent: Friday, 6 December, 2013 11:52:07 PM >>>> Subject: Re: [keycloak-dev] timestamp repo release >>>> >>>> >>>> >>>> On 12/6/2013 12:34 PM, Stian Thorgersen wrote: >>>>> Thanks, >>>>> >>>>> Marek has also found a bunch of issues that'll need fixing for M1. >>>>> >>>> I don't see any blocker bugs. >>>> >>>>> With Christmas being pretty close now, and most people going into >>>>> holiday >>>>> mode, I was thinking it might be better to hold off until the New Years? >>>>> We could still circulate a timestamped version internally though. >>>>> >>>> Nah. We have enough to do an alpha release. The bulk of the work is >>>> making install/bootstrap/distro/demo as ironclad and as easy to use and >>>> setup as possible. As well as the initial documentation. IMO, we have >>>> enough working features to release an alpha. >>>> >>>>> For the website we should make it use the bootstrap theme that >>>>> WildFly and >>>>> Hibernate uses, it looks a bit more fresh then what we have now. >>>>> Also, we >>>>> need a logo! >>>>> >>>> Need to find out where they host these sites. Not sure if its openshift >>>> or not. FYI, I did buy keycloak.org about 8 >>>> months ago. It points to >>>> jboss.org/keycloak at the moment. >>>> >>>>> Once we've done the release it would be great to do a series of blog >>>>> posts, >>>>> and maybe some shorter videos that shows off a single feature (2 min >>>>> length ish) >>>>> >>>> I'm planning on doing a vid tutorial on the 2 demos. One is our current >>>> demo all set up via a file import. The other is actually manually >>>> setting up the demo via the admin console (creating the realm, apps, >>>> roles, users, role mappings, oauth client, scope, etc...) >>>> >>>> I wanted the doco to link to these 2 min vids too. >>>> >>>> -- >>>> 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 >> >> -- >> Gabriel Cardoso >> GateIn Portal | User Experience Designer >> >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From mposolda at redhat.com Tue Dec 10 11:45:59 2013 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 10 Dec 2013 17:45:59 +0100 Subject: [keycloak-dev] Feedback on examples Message-ID: <52A74547.2000203@redhat.com> I have few points regarding example applications: - For third-party oauth client example, there is not possibility to configure stuff through JSON but everything is hardcoded in classes Bootstrap and ProductDatabaseClient. There are also some strange comments in code like "This is the worst code ever" etc :-) This is not so ideal IMO as I expect that people will often look to the source code of these examples for inspiration. I believe that OAuth clients should also have something like ManagedResourceConfigLoader for Applications. - For the "third-party" OAuth client, I don't like the fact that when user press "Cancel" in OAuth grant page, there is exception in server.log and Tomcat error page displayed. I believe the behaviour should be more user-friendly. - Examples "customer-portal", "product-portal", "database-service" and "oauth-client" are using package "org.jboss.reasteasy..." instead of "org.keycloak..." Any thoughts? Let me know if I should create JIRA or help with fixing those. Marek -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20131210/e1ef4aca/attachment.html From gcardoso at redhat.com Tue Dec 10 11:32:52 2013 From: gcardoso at redhat.com (Gabriel Cardoso) Date: Tue, 10 Dec 2013 14:32:52 -0200 Subject: [keycloak-dev] Cancel button in the login page In-Reply-To: <1674616197.27481345.1386667535680.JavaMail.root@redhat.com> References: <9046F10B-5BE2-4655-85D4-ADB4888A91E0@redhat.com> <1674616197.27481345.1386667535680.JavaMail.root@redhat.com> Message-ID: > It takes the user back to the application without login Shouldn't this be for the SaaS login instead of the admin console login? -- Gabriel Cardoso GateIn Portal | User Experience Designer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20131210/c0bbb4dc/attachment-0001.html From gcardoso at redhat.com Tue Dec 10 12:18:00 2013 From: gcardoso at redhat.com (Gabriel Cardoso) Date: Tue, 10 Dec 2013 15:18:00 -0200 Subject: [keycloak-dev] Consistency and standards In-Reply-To: <109679351.27487481.1386668413707.JavaMail.root@redhat.com> References: <73A481F1-6D78-4D27-BFC3-94E22E3458AF@redhat.com> <109679351.27487481.1386668413707.JavaMail.root@redhat.com> Message-ID: <78EEA8B9-22F1-4C04-B3C8-BD4B4C283307@redhat.com> > Why is the main action on the right side? That's the opposite of what the html spec does (first button is the default button) + it doesn't make sense in a left-to-right language This was defined by the RCUE team. Since the color of the primary action is blue, the visual weight dictates the order of reading, even being at the right side, so I don't see this as a problem. Also, other good interfaces do the same, like Mac OS. I declared the primary action in the HTML first because it will be read first in a screen reader. In this case, the order is important. Gabriel > > ----- Original Message ----- >> From: "Gabriel Cardoso" >> To: keycloak-dev at lists.jboss.org >> Sent: Tuesday, 10 December, 2013 2:42:01 AM >> Subject: [keycloak-dev] Consistency and standards >> >> When adding new elements to the interface, it is important to maintain >> consistency, using the same standards already used in the interface. Here >> are two examples: >> >> Standard: main action at the right side >> Inconsistency: main action at the left side in the login screen >> >> >> >> >> Standard: dark tooltip >> >> Inconsistency: white tooltip in the credentials page >> >> Could you guys update them to follow the standards? >> >> Also, if you have any doubt when implementing something new, let me know. >> >> Gabriel >> >> -- >> Gabriel Cardoso >> GateIn Portal | User Experience Designer >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> -- Gabriel Cardoso GateIn Portal | User Experience Designer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20131210/700893be/attachment.html From stian at redhat.com Tue Dec 10 12:27:10 2013 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 10 Dec 2013 12:27:10 -0500 (EST) Subject: [keycloak-dev] Cancel button in the login page In-Reply-To: References: <9046F10B-5BE2-4655-85D4-ADB4888A91E0@redhat.com> <1674616197.27481345.1386667535680.JavaMail.root@redhat.com> Message-ID: <477054182.27848450.1386696430457.JavaMail.root@redhat.com> I assume by SaaS login you mean realm login? No, there's no difference. There's is however some types of applications where a cancel button doesn't make sense, and that's when an application requires a login. For example the admin console redirects the user directly to the login screen as you can't do anything unless you login. There's not much point in that case to show a cancel button as it would just take you back to an error screen. So the cancel button should be configurable. ----- Original Message ----- > From: "Gabriel Cardoso" > To: keycloak-dev at lists.jboss.org > Sent: Tuesday, 10 December, 2013 4:32:52 PM > Subject: Re: [keycloak-dev] Cancel button in the login page > > > > > It takes the user back to the application without login > Shouldn't this be for the SaaS login instead of the admin console login? > > -- > Gabriel Cardoso > GateIn Portal | User Experience Designer > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From gcardoso at redhat.com Tue Dec 10 13:26:05 2013 From: gcardoso at redhat.com (Gabriel Cardoso) Date: Tue, 10 Dec 2013 16:26:05 -0200 Subject: [keycloak-dev] Cancel button in the login page In-Reply-To: <477054182.27848450.1386696430457.JavaMail.root@redhat.com> References: <9046F10B-5BE2-4655-85D4-ADB4888A91E0@redhat.com> <1674616197.27481345.1386667535680.JavaMail.root@redhat.com> <477054182.27848450.1386696430457.JavaMail.root@redhat.com> Message-ID: > I assume by SaaS login you mean realm login? Yes, that's it. > No, there's no difference. There's is however some types of applications where a cancel button doesn't make sense, and that's when an application requires a login. For example the admin console redirects the user directly to the login screen as you can't do anything unless you login. There's not much point in that case to show a cancel button as it would just take you back to an error screen. So the cancel button should be configurable. That's good, since the Cancel button in the admin console does not make sense at all. Gabriel -- Gabriel Cardoso GateIn Portal | User Experience Designer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20131210/c835f30f/attachment.html From bburke at redhat.com Wed Dec 11 08:05:43 2013 From: bburke at redhat.com (Bill Burke) Date: Wed, 11 Dec 2013 08:05:43 -0500 Subject: [keycloak-dev] Require SSL option In-Reply-To: <52A73F50.1050508@redhat.com> References: <52A73F50.1050508@redhat.com> Message-ID: <52A86327.6070006@redhat.com> Require SSL means that all interaction with Keycloak server is required to be HTTPS. All redirect URLs must also use the HTTPS protocol. Like you said, it also will set "secure" on any set Cookies, but that's only part of it. Other than renaming it to "Require HTTPS", i think the name is appropriate. On 12/10/2013 11:20 AM, Marek Posolda wrote: > Hi, > > I would like to ask what exactly is semantics of realm option "Require > SSL"? My first impression is that if this option is enabled, then access > to URI like "http://localhost:8080/auth-server/rest/realms/demo/..." > should be allowed just with 'https' protocol instead of plain 'http'. > Actually http access to realm is enabled and login works. Option is used > just for securing cookies like KEYCLOAK_IDENTITY, so that SSO > reauthentication with cookies is effectively disabled. But shouldn't we > rename this option to something "Use secured cookie" then? Name "Require > SSL" seems to be confusing IMO. > > There is also one more issue > https://issues.jboss.org/browse/KEYCLOAK-227 due to the fact that option > doesn't affect just KEYCLOAK_IDENTITY cookie but also > KEYCLOAK_ACCOUNT_IDENTITY, which means that I am always redirected back > to login form after successful login in case that login has been > triggered for AccountManagement application. > > WDYT? > 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 bburke at redhat.com Wed Dec 11 08:10:48 2013 From: bburke at redhat.com (Bill Burke) Date: Wed, 11 Dec 2013 08:10:48 -0500 Subject: [keycloak-dev] Feedback on examples In-Reply-To: <52A74547.2000203@redhat.com> References: <52A74547.2000203@redhat.com> Message-ID: <52A86458.9060509@redhat.com> On 12/10/2013 11:45 AM, Marek Posolda wrote: > I have few points regarding example applications: > > - For third-party oauth client example, there is not possibility to > configure stuff through JSON but everything is hardcoded in classes > Bootstrap and ProductDatabaseClient. There are also some strange > comments in code like "This is the worst code ever" etc :-) This is not > so ideal IMO as I expect that people will often look to the source code > of these examples for inspiration. I believe that OAuth clients should > also have something like ManagedResourceConfigLoader for Applications. > Feel free to write a better example with CDI or Spring and expand out the oauth client framework code. > - For the "third-party" OAuth client, I don't like the fact that when > user press "Cancel" in OAuth grant page, there is exception in > server.log and Tomcat error page displayed. I believe the behaviour > should be more user-friendly. > Again, feel free to expand on the third-party app to display something better. > - Examples "customer-portal", "product-portal", "database-service" and > "oauth-client" are using package "org.jboss.reasteasy..." instead of > "org.keycloak..." > Yeah, holdover from Resteasy code I migrated from. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From mposolda at redhat.com Wed Dec 11 08:34:44 2013 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 11 Dec 2013 14:34:44 +0100 Subject: [keycloak-dev] Require SSL option In-Reply-To: <52A86327.6070006@redhat.com> References: <52A73F50.1050508@redhat.com> <52A86327.6070006@redhat.com> Message-ID: <52A869F4.4060902@redhat.com> ah ok. Thanks. Currently it's used just for cookies. It's allowed to have http redirect URLs and authenticate into Keycloak with plain HTTP protocol. So should I create JIRA to improve that and add more strict checks based on protocol? Marek On 11.12.2013 14:05, Bill Burke wrote: > Require SSL means that all interaction with Keycloak server is required > to be HTTPS. All redirect URLs must also use the HTTPS protocol. Like > you said, it also will set "secure" on any set Cookies, but that's only > part of it. Other than renaming it to "Require HTTPS", i think the name > is appropriate. > > On 12/10/2013 11:20 AM, Marek Posolda wrote: >> Hi, >> >> I would like to ask what exactly is semantics of realm option "Require >> SSL"? My first impression is that if this option is enabled, then access >> to URI like "http://localhost:8080/auth-server/rest/realms/demo/..." >> should be allowed just with 'https' protocol instead of plain 'http'. >> Actually http access to realm is enabled and login works. Option is used >> just for securing cookies like KEYCLOAK_IDENTITY, so that SSO >> reauthentication with cookies is effectively disabled. But shouldn't we >> rename this option to something "Use secured cookie" then? Name "Require >> SSL" seems to be confusing IMO. >> >> There is also one more issue >> https://issues.jboss.org/browse/KEYCLOAK-227 due to the fact that option >> doesn't affect just KEYCLOAK_IDENTITY cookie but also >> KEYCLOAK_ACCOUNT_IDENTITY, which means that I am always redirected back >> to login form after successful login in case that login has been >> triggered for AccountManagement application. >> >> WDYT? >> Marek >> >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From bburke at redhat.com Wed Dec 11 08:54:09 2013 From: bburke at redhat.com (Bill Burke) Date: Wed, 11 Dec 2013 08:54:09 -0500 Subject: [keycloak-dev] Require SSL option In-Reply-To: <52A869F4.4060902@redhat.com> References: <52A73F50.1050508@redhat.com> <52A86327.6070006@redhat.com> <52A869F4.4060902@redhat.com> Message-ID: <52A86E81.6060709@redhat.com> I think there is a JIRA somewhere to make sure that SSL checks are made if this flag is set. On 12/11/2013 8:34 AM, Marek Posolda wrote: > ah ok. Thanks. Currently it's used just for cookies. It's allowed to > have http redirect URLs and authenticate into Keycloak with plain HTTP > protocol. So should I create JIRA to improve that and add more strict > checks based on protocol? > > Marek > > On 11.12.2013 14:05, Bill Burke wrote: >> Require SSL means that all interaction with Keycloak server is required >> to be HTTPS. All redirect URLs must also use the HTTPS protocol. Like >> you said, it also will set "secure" on any set Cookies, but that's only >> part of it. Other than renaming it to "Require HTTPS", i think the name >> is appropriate. >> >> On 12/10/2013 11:20 AM, Marek Posolda wrote: >>> Hi, >>> >>> I would like to ask what exactly is semantics of realm option "Require >>> SSL"? My first impression is that if this option is enabled, then access >>> to URI like "http://localhost:8080/auth-server/rest/realms/demo/..." >>> should be allowed just with 'https' protocol instead of plain 'http'. >>> Actually http access to realm is enabled and login works. Option is used >>> just for securing cookies like KEYCLOAK_IDENTITY, so that SSO >>> reauthentication with cookies is effectively disabled. But shouldn't we >>> rename this option to something "Use secured cookie" then? Name "Require >>> SSL" seems to be confusing IMO. >>> >>> There is also one more issue >>> https://issues.jboss.org/browse/KEYCLOAK-227 due to the fact that option >>> doesn't affect just KEYCLOAK_IDENTITY cookie but also >>> KEYCLOAK_ACCOUNT_IDENTITY, which means that I am always redirected back >>> to login form after successful login in case that login has been >>> triggered for AccountManagement application. >>> >>> WDYT? >>> 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 amendonc at redhat.com Wed Dec 11 09:48:03 2013 From: amendonc at redhat.com (Alexandre Mendonca) Date: Wed, 11 Dec 2013 09:48:03 -0500 (EST) Subject: [keycloak-dev] View all users for a realm In-Reply-To: <6B50331E-84BA-4F57-9562-EC4629283AB4@redhat.com> References: <873497915.24121368.1386243638270.JavaMail.root@redhat.com> <8533AE6D-C059-47A9-9F88-F57C760CB082@redhat.com> <52A0C84F.7080800@redhat.com> <1006249887.24781209.1386270464926.JavaMail.root@redhat.com> <6B50331E-84BA-4F57-9562-EC4629283AB4@redhat.com> Message-ID: <1185164294.5219831.1386773283840.JavaMail.root@redhat.com> +1 on listing users. With pagination and the possibility for sorting by last created/modified we can cover the scenario Gabriel referred to. Alexandre ----- Original Message ----- From: "Gabriel Cardoso" To: keycloak-dev at lists.jboss.org Sent: Thursday, December 5, 2013 7:10:52 PM Subject: Re: [keycloak-dev] View all users for a realm If we don't list all users by default, it would be good to update the page's header to "Search Users" On Dec 5, 2013, at 5:07 PM, Stian Thorgersen wrote: I should have included the reason why I want it ;) ATM there's no way for an admin to list all users. I think we should either view all users by default, or add "View all" button next to the search. I'm happy with either, and I'd probably prefer the last option TBH. ----- Original Message -----
From: "Bill Burke" < bburke at redhat.com >
To: keycloak-dev at lists.jboss.org
Sent: Thursday, 5 December, 2013 6:39:11 PM
Subject: Re: [keycloak-dev] View all users for a realm
Well, he won't see the user if there are N number of users already.
On 12/5/2013 11:34 AM, Gabriel Cardoso wrote:
This is much better from the usability perspective. The way it is, the
admin creates an user and does not see him listed in the table. This may
lead him to try to create the same user again ;)
Gabriel
On Dec 5, 2013, at 9:40 AM, Stian Thorgersen wrote:
ATM it's only possible to search for users. It should be possible to
also view all users for a realm.
I propose that we make the users page show all users when there's no
search set. In the future this and all other tables should support
pagination, including pagination support on the rest endpoints, so
that would solve the issue of loading a huge amount of users.
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org < mailto:keycloak-dev at lists.jboss.org >
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Gabriel Cardoso
GateIn Portal | User Experience Designer
_______________________________________________
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
-- Gabriel Cardoso GateIn Portal | User Experience Designer _______________________________________________ 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/20131211/fa66655f/attachment.html From stian at redhat.com Wed Dec 11 13:29:13 2013 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 11 Dec 2013 13:29:13 -0500 (EST) Subject: [keycloak-dev] Can KeyCloack be used without any passwords? In-Reply-To: <983318239.1700119.1386447651518.JavaMail.root@redhat.com> References: <1216079021.1124829.1386294642732.JavaMail.root@redhat.com> <226202651.25267890.1386322728588.JavaMail.root@redhat.com> <537985085.1619764.1386365709639.JavaMail.root@redhat.com> <52A2559D.2030500@redhat.com> <983318239.1700119.1386447651518.JavaMail.root@redhat.com> Message-ID: <432172043.29011639.1386786553403.JavaMail.root@redhat.com> I just realized why there may have been some confusion on the social login and creation of users. Showing the registration form on first social login is optional, but the option to disable has disappeared from the admin console. I've just committed a fix for this. ----- Original Message ----- > From: "Matt Casperson" > To: "Bill Burke" > Cc: keycloak-dev at lists.jboss.org > Sent: Saturday, 7 December, 2013 8:20:51 PM > Subject: Re: [keycloak-dev] Can KeyCloack be used without any passwords? > > I certainly don't mean to downplay the value of being able to manage > accounts. Being able to assign custom roles that are not reflected in > LDAP/AD is going to be important, and necessary for social logins. And even > though we would prefer not deal with local passwords, being able to support > that feature with a toggle in a UI is a selling point. > > Regards > > Matthew Casperson > RHCE, RHCJA # 111-072-237 > Engineering Content Services > Brisbane, Australia > > > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Saturday, 7 December, 2013 8:54:21 AM > Subject: Re: [keycloak-dev] Can KeyCloack be used without any passwords? > > On 12/6/2013 4:35 PM, Matt Casperson wrote: > > If KeyCloak could give us the ability to defer account and password > > management entirely to social logins or an existing LDAP/AD database > > with something as simple as a toggle in the admin console, it would be a > > huge win. > > > > Keycloak aims to be an SSO solution, not an SSO adapter. > > For non-social deployments, account management is a huge part of what > Keycloak does. Maybe I'm naive in thinking admins will want to use > Keycloak to management accounts though. > > Even for social deployments, there's a lot of account management > involved, i.e. managing oauth grants, registering devices, all things we > want to be able to do. > > > What is stored in LDAP/AD databases usually? user/password/credentials > only? What about permissions/role mappings? Is doing a background sync > to an LDAP/AD database not something people are going to want to do? > Syncing means credentials are copied. > > Bill > > -- > 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 Wed Dec 11 14:27:31 2013 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 11 Dec 2013 14:27:31 -0500 (EST) Subject: [keycloak-dev] Cancel button on login form In-Reply-To: <1005472289.29094415.1386789885668.JavaMail.root@redhat.com> Message-ID: <399889774.29095884.1386790051006.JavaMail.root@redhat.com> I added a cancel button to the login form. It results in a redirect to "?error=access_denied". Problem with it is that it doesn't make sense for all applications to have it. This mainly applies to applications that require a login, for example the admin console. Question is what do we do for those? Some alternatives: * Add an optional query param to login that disables it (.../tokens/login?nocancel) * Add a config option to the app that's set through admin console * Leave it and make the app show a sensible error message - "You're required to login blah blah, click here to login" Thoughts? From gcardoso at redhat.com Wed Dec 11 15:05:47 2013 From: gcardoso at redhat.com (Gabriel Cardoso) Date: Wed, 11 Dec 2013 18:05:47 -0200 Subject: [keycloak-dev] View all users for a realm In-Reply-To: <1185164294.5219831.1386773283840.JavaMail.root@redhat.com> References: <873497915.24121368.1386243638270.JavaMail.root@redhat.com> <8533AE6D-C059-47A9-9F88-F57C760CB082@redhat.com> <52A0C84F.7080800@redhat.com> <1006249887.24781209.1386270464926.JavaMail.root@redhat.com> <6B50331E-84BA-4F57-9562-EC4629283AB4@redhat.com> <1185164294.5219831.1386773283840.JavaMail.root@redhat.com> Message-ID: <51E2FBAF-5A97-4B08-80F7-31802E69E734@redhat.com> I implemented a new design for the button "View all" in the users list. Now the button looks like a link and it is next to the search box. Gabriel On Dec 11, 2013, at 12:48 PM, Alexandre Mendonca wrote: > +1 on listing users. With pagination and the possibility for sorting by last created/modified we can cover the scenario Gabriel referred to. > > Alexandre > > From: "Gabriel Cardoso" > To: keycloak-dev at lists.jboss.org > Sent: Thursday, December 5, 2013 7:10:52 PM > Subject: Re: [keycloak-dev] View all users for a realm > > If we don't list all users by default, it would be good to update the page's header to "Search Users" > > On Dec 5, 2013, at 5:07 PM, Stian Thorgersen wrote: > > I should have included the reason why I want it ;) > > ATM there's no way for an admin to list all users. I think we should either view all users by default, or add "View all" button next to the search. I'm happy with either, and I'd probably prefer the last option TBH. > > ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Thursday, 5 December, 2013 6:39:11 PM > Subject: Re: [keycloak-dev] View all users for a realm > > Well, he won't see the user if there are N number of users already. > > On 12/5/2013 11:34 AM, Gabriel Cardoso wrote: > This is much better from the usability perspective. The way it is, the > admin creates an user and does not see him listed in the table. This may > lead him to try to create the same user again ;) > > Gabriel > > On Dec 5, 2013, at 9:40 AM, Stian Thorgersen wrote: > > ATM it's only possible to search for users. It should be possible to > also view all users for a realm. > > I propose that we make the users page show all users when there's no > search set. In the future this and all other tables should support > pagination, including pagination support on the rest endpoints, so > that would solve the issue of loading a huge amount of users. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -- > Gabriel Cardoso > GateIn Portal | User Experience Designer > > > > > _______________________________________________ > 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 > > > -- > Gabriel Cardoso > GateIn Portal | User Experience Designer > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Gabriel Cardoso GateIn Portal | User Experience Designer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20131211/f046d8ed/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2013-12-11 at 6.05.09 PM.png Type: image/png Size: 23472 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20131211/f046d8ed/attachment-0001.png From gcardoso at redhat.com Wed Dec 11 15:10:02 2013 From: gcardoso at redhat.com (Gabriel Cardoso) Date: Wed, 11 Dec 2013 18:10:02 -0200 Subject: [keycloak-dev] Can KeyCloack be used without any passwords? In-Reply-To: <432172043.29011639.1386786553403.JavaMail.root@redhat.com> References: <1216079021.1124829.1386294642732.JavaMail.root@redhat.com> <226202651.25267890.1386322728588.JavaMail.root@redhat.com> <537985085.1619764.1386365709639.JavaMail.root@redhat.com> <52A2559D.2030500@redhat.com> <983318239.1700119.1386447651518.JavaMail.root@redhat.com> <432172043.29011639.1386786553403.JavaMail.root@redhat.com> Message-ID: To keep the alignment between the label and the element at its right, labels that occupy two lines must have the class="two-lines" ;) On Dec 11, 2013, at 4:29 PM, Stian Thorgersen wrote: > I just realized why there may have been some confusion on the social login and creation of users. > > Showing the registration form on first social login is optional, but the option to disable has disappeared from the admin console. I've just committed a fix for this. > > ----- Original Message ----- >> From: "Matt Casperson" >> To: "Bill Burke" >> Cc: keycloak-dev at lists.jboss.org >> Sent: Saturday, 7 December, 2013 8:20:51 PM >> Subject: Re: [keycloak-dev] Can KeyCloack be used without any passwords? >> >> I certainly don't mean to downplay the value of being able to manage >> accounts. Being able to assign custom roles that are not reflected in >> LDAP/AD is going to be important, and necessary for social logins. And even >> though we would prefer not deal with local passwords, being able to support >> that feature with a toggle in a UI is a selling point. >> >> Regards >> >> Matthew Casperson >> RHCE, RHCJA # 111-072-237 >> Engineering Content Services >> Brisbane, Australia >> >> >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Saturday, 7 December, 2013 8:54:21 AM >> Subject: Re: [keycloak-dev] Can KeyCloack be used without any passwords? >> >> On 12/6/2013 4:35 PM, Matt Casperson wrote: >>> If KeyCloak could give us the ability to defer account and password >>> management entirely to social logins or an existing LDAP/AD database >>> with something as simple as a toggle in the admin console, it would be a >>> huge win. >>> >> >> Keycloak aims to be an SSO solution, not an SSO adapter. >> >> For non-social deployments, account management is a huge part of what >> Keycloak does. Maybe I'm naive in thinking admins will want to use >> Keycloak to management accounts though. >> >> Even for social deployments, there's a lot of account management >> involved, i.e. managing oauth grants, registering devices, all things we >> want to be able to do. >> >> >> What is stored in LDAP/AD databases usually? user/password/credentials >> only? What about permissions/role mappings? Is doing a background sync >> to an LDAP/AD database not something people are going to want to do? >> Syncing means credentials are copied. >> >> Bill >> >> -- >> 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 -- Gabriel Cardoso GateIn Portal | User Experience Designer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20131211/d4a62009/attachment.html From gcardoso at redhat.com Wed Dec 11 15:13:55 2013 From: gcardoso at redhat.com (Gabriel Cardoso) Date: Wed, 11 Dec 2013 18:13:55 -0200 Subject: [keycloak-dev] Cancel button on login form In-Reply-To: <399889774.29095884.1386790051006.JavaMail.root@redhat.com> References: <399889774.29095884.1386790051006.JavaMail.root@redhat.com> Message-ID: To avoid bad usability, I would NOT go with the last option. On Dec 11, 2013, at 5:27 PM, Stian Thorgersen wrote: > I added a cancel button to the login form. It results in a redirect to "?error=access_denied". > > Problem with it is that it doesn't make sense for all applications to have it. This mainly applies to applications that require a login, for example the admin console. Question is what do we do for those? Some alternatives: > > * Add an optional query param to login that disables it (.../tokens/login?nocancel) > * Add a config option to the app that's set through admin console > * Leave it and make the app show a sensible error message - "You're required to login blah blah, click here to login" > > Thoughts? > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Gabriel Cardoso GateIn Portal | User Experience Designer From bburke at redhat.com Wed Dec 11 16:01:27 2013 From: bburke at redhat.com (Bill Burke) Date: Wed, 11 Dec 2013 16:01:27 -0500 Subject: [keycloak-dev] Cancel button on login form In-Reply-To: <399889774.29095884.1386790051006.JavaMail.root@redhat.com> References: <399889774.29095884.1386790051006.JavaMail.root@redhat.com> Message-ID: <52A8D2A7.2030700@redhat.com> On 12/11/2013 2:27 PM, Stian Thorgersen wrote: > I added a cancel button to the login form. It results in a redirect to "?error=access_denied". > > Problem with it is that it doesn't make sense for all applications to have it. This mainly applies to applications that require a login, for example the admin console. Question is what do we do for those? Some alternatives: > This is not a problem IMO. Let the application decide how it wants to handle a cancel. > * Add an optional query param to login that disables it (.../tokens/login?nocancel) > * Add a config option to the app that's set through admin console > * Leave it and make the app show a sensible error message - "You're required to login blah blah, click here to login" > or * redirect to "?error=cancelled" or * redirect to "?cancelled=true" or from openid connect * redirect to "?error=interaction_required" Admin console would see this and just redirect back to the login page. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From ssilvert at redhat.com Wed Dec 11 17:08:53 2013 From: ssilvert at redhat.com (ssilvert at redhat.com) Date: Wed, 11 Dec 2013 17:08:53 -0500 Subject: [keycloak-dev] Cancel button on login form In-Reply-To: <52A8D2A7.2030700@redhat.com> References: <399889774.29095884.1386790051006.JavaMail.root@redhat.com> <52A8D2A7.2030700@redhat.com> Message-ID: <52A8E275.7080901@redhat.com> On 12/11/2013 4:01 PM, Bill Burke wrote: > > On 12/11/2013 2:27 PM, Stian Thorgersen wrote: >> I added a cancel button to the login form. It results in a redirect to "?error=access_denied". >> >> Problem with it is that it doesn't make sense for all applications to have it. This mainly applies to applications that require a login, for example the admin console. Question is what do we do for those? Some alternatives: >> > This is not a problem IMO. Let the application decide how it wants to > handle a cancel. I think there should still be some default behavior. I'm thinking about the case where an application was written without any security in mind. You just have this unsecured app that you want to hide behind SSO. That application wouldn't know what to do. > >> * Add an optional query param to login that disables it (.../tokens/login?nocancel) >> * Add a config option to the app that's set through admin console >> * Leave it and make the app show a sensible error message - "You're required to login blah blah, click here to login" >> > or > > * redirect to "?error=cancelled" > > or > > * redirect to "?cancelled=true" > > or from openid connect > > * redirect to "?error=interaction_required" > > Admin console would see this and just redirect back to the login page. > > > From stian at redhat.com Thu Dec 12 03:35:24 2013 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 12 Dec 2013 03:35:24 -0500 (EST) Subject: [keycloak-dev] View all users for a realm In-Reply-To: <51E2FBAF-5A97-4B08-80F7-31802E69E734@redhat.com> References: <873497915.24121368.1386243638270.JavaMail.root@redhat.com> <8533AE6D-C059-47A9-9F88-F57C760CB082@redhat.com> <52A0C84F.7080800@redhat.com> <1006249887.24781209.1386270464926.JavaMail.root@redhat.com> <6B50331E-84BA-4F57-9562-EC4629283AB4@redhat.com> <1185164294.5219831.1386773283840.JavaMail.root@redhat.com> <51E2FBAF-5A97-4B08-80F7-31802E69E734@redhat.com> Message-ID: <119063067.29655737.1386837324006.JavaMail.root@redhat.com> Looks much better, thanks ----- Original Message ----- > From: "Gabriel Cardoso" > To: keycloak-dev at lists.jboss.org > Sent: Wednesday, 11 December, 2013 8:05:47 PM > Subject: Re: [keycloak-dev] View all users for a realm > > I implemented a new design for the button "View all" in the users list. > Now the button looks like a link and it is next to the search box. > > > Gabriel > > On Dec 11, 2013, at 12:48 PM, Alexandre Mendonca wrote: > > > > > +1 on listing users. With pagination and the possibility for sorting by last > created/modified we can cover the scenario Gabriel referred to. > > Alexandre > > > From: "Gabriel Cardoso" < gcardoso at redhat.com > > To: keycloak-dev at lists.jboss.org > Sent: Thursday, December 5, 2013 7:10:52 PM > Subject: Re: [keycloak-dev] View all users for a realm > > If we don't list all users by default, it would be good to update the page's > header to "Search Users" > > On Dec 5, 2013, at 5:07 PM, Stian Thorgersen wrote: > > > > > I should have included the reason why I want it ;) > > ATM there's no way for an admin to list all users. I think we should either > view all users by default, or add "View all" button next to the search. I'm > happy with either, and I'd probably prefer the last option TBH. > > ----- Original Message ----- > > > From: "Bill Burke" < bburke at redhat.com > > > > To: keycloak-dev at lists.jboss.org > > > Sent: Thursday, 5 December, 2013 6:39:11 PM > > > Subject: Re: [keycloak-dev] View all users for a realm > > > > > > Well, he won't see the user if there are N number of users already. > > > > > > On 12/5/2013 11:34 AM, Gabriel Cardoso wrote: > > > > > This is much better from the usability perspective. The way it is, the > > > > > admin creates an user and does not see him listed in the table. This may > > > > > lead him to try to create the same user again ;) > > > > > > > > > > Gabriel > > > > > > > > > > On Dec 5, 2013, at 9:40 AM, Stian Thorgersen wrote: > > > > > > > > > > > > ATM it's only possible to search for users. It should be possible to > > > > > > > also view all users for a realm. > > > > > > > > > > > > > > I propose that we make the users page show all users when there's no > > > > > > > search set. In the future this and all other tables should support > > > > > > > pagination, including pagination support on the rest endpoints, so > > > > > > > that would solve the issue of loading a huge amount of users. > > > > > > > _______________________________________________ > > > > > > > keycloak-dev mailing list > > > > > > > keycloak-dev at lists.jboss.org < mailto:keycloak-dev at lists.jboss.org > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > -- > > > > > Gabriel Cardoso > > > > > GateIn Portal | User Experience Designer > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 > > > -- > Gabriel Cardoso > GateIn Portal | User Experience Designer > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Gabriel Cardoso > GateIn Portal | User Experience Designer > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Thu Dec 12 03:46:05 2013 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 12 Dec 2013 03:46:05 -0500 (EST) Subject: [keycloak-dev] Cancel button on login form In-Reply-To: <52A8E275.7080901@redhat.com> References: <399889774.29095884.1386790051006.JavaMail.root@redhat.com> <52A8D2A7.2030700@redhat.com> <52A8E275.7080901@redhat.com> Message-ID: <760793727.29659431.1386837965457.JavaMail.root@redhat.com> ----- Original Message ----- > From: ssilvert at redhat.com > To: keycloak-dev at lists.jboss.org > Sent: Wednesday, 11 December, 2013 10:08:53 PM > Subject: Re: [keycloak-dev] Cancel button on login form > > On 12/11/2013 4:01 PM, Bill Burke wrote: > > > > On 12/11/2013 2:27 PM, Stian Thorgersen wrote: > >> I added a cancel button to the login form. It results in a redirect to > >> "?error=access_denied". > >> > >> Problem with it is that it doesn't make sense for all applications to have > >> it. This mainly applies to applications that require a login, for example > >> the admin console. Question is what do we do for those? Some > >> alternatives: > >> > > This is not a problem IMO. Let the application decide how it wants to > > handle a cancel. > I think there should still be some default behavior. I'm thinking about > the case where an application was written without any security in mind. > You just have this unsecured app that you want to hide behind SSO. That > application wouldn't know what to do. Makes sense, but wouldn't that be handled by the adapter? > > > >> * Add an optional query param to login that disables it > >> (.../tokens/login?nocancel) > >> * Add a config option to the app that's set through admin console > >> * Leave it and make the app show a sensible error message - "You're > >> required to login blah blah, click here to login" > >> > > or > > > > * redirect to "?error=cancelled" > > > > or > > > > * redirect to "?cancelled=true" > > > > or from openid connect > > > > * redirect to "?error=interaction_required" > > > > Admin console would see this and just redirect back to the login page. > > > > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From mposolda at redhat.com Thu Dec 12 04:02:18 2013 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 12 Dec 2013 10:02:18 +0100 Subject: [keycloak-dev] Cancel button on login form In-Reply-To: <52A8D2A7.2030700@redhat.com> References: <399889774.29095884.1386790051006.JavaMail.root@redhat.com> <52A8D2A7.2030700@redhat.com> Message-ID: <52A97B9A.3090406@redhat.com> On 11.12.2013 22:01, Bill Burke wrote: > > On 12/11/2013 2:27 PM, Stian Thorgersen wrote: >> I added a cancel button to the login form. It results in a redirect to "?error=access_denied". >> >> Problem with it is that it doesn't make sense for all applications to have it. This mainly applies to applications that require a login, for example the admin console. Question is what do we do for those? Some alternatives: >> > This is not a problem IMO. Let the application decide how it wants to > handle a cancel. > >> * Add an optional query param to login that disables it (.../tokens/login?nocancel) >> * Add a config option to the app that's set through admin console >> * Leave it and make the app show a sensible error message - "You're required to login blah blah, click here to login" >> > or > > * redirect to "?error=cancelled" > > or > > * redirect to "?cancelled=true" > > or from openid connect > > * redirect to "?error=interaction_required" > > Admin console would see this and just redirect back to the login page. hmm... It seems that this could result in strange behaviour regarding usability. User press "cancel" button and then he will be redirected back to login page. So from the user perspective, only result will be empty username/password field. I think that some combination of those options will be best. We can add both query parameter like /tokens/login?nocancel, which will be used for apps like admin console, which really requires login. And having something like ?error=cancelled would be also useful, so that applications/oauth-clients can see the difference between: - error=cancelled, which is used when user press cancel button on login page - error=access_denied, which is used when user doesn't accept grants on oauth grant page. Marek From amendonc at redhat.com Thu Dec 12 08:27:42 2013 From: amendonc at redhat.com (Alexandre Mendonca) Date: Thu, 12 Dec 2013 08:27:42 -0500 (EST) Subject: [keycloak-dev] View all users for a realm In-Reply-To: <119063067.29655737.1386837324006.JavaMail.root@redhat.com> References: <873497915.24121368.1386243638270.JavaMail.root@redhat.com> <8533AE6D-C059-47A9-9F88-F57C760CB082@redhat.com> <52A0C84F.7080800@redhat.com> <1006249887.24781209.1386270464926.JavaMail.root@redhat.com> <6B50331E-84BA-4F57-9562-EC4629283AB4@redhat.com> <1185164294.5219831.1386773283840.JavaMail.root@redhat.com> <51E2FBAF-5A97-4B08-80F7-31802E69E734@redhat.com> <119063067.29655737.1386837324006.JavaMail.root@redhat.com> Message-ID: <914822194.5747787.1386854862387.JavaMail.root@redhat.com> I'll implement this as part of fix for https://issues.jboss.org/browse/KEYCLOAK-127, if nobody has started with it. Alexandre ----- Original Message ----- From: "Stian Thorgersen" To: "Gabriel Cardoso" Cc: keycloak-dev at lists.jboss.org Sent: Thursday, December 12, 2013 8:35:24 AM Subject: Re: [keycloak-dev] View all users for a realm Looks much better, thanks ----- Original Message ----- > From: "Gabriel Cardoso" > To: keycloak-dev at lists.jboss.org > Sent: Wednesday, 11 December, 2013 8:05:47 PM > Subject: Re: [keycloak-dev] View all users for a realm > > I implemented a new design for the button "View all" in the users list. > Now the button looks like a link and it is next to the search box. > > > Gabriel > > On Dec 11, 2013, at 12:48 PM, Alexandre Mendonca wrote: > > > > > +1 on listing users. With pagination and the possibility for sorting by last > created/modified we can cover the scenario Gabriel referred to. > > Alexandre > > > From: "Gabriel Cardoso" < gcardoso at redhat.com > > To: keycloak-dev at lists.jboss.org > Sent: Thursday, December 5, 2013 7:10:52 PM > Subject: Re: [keycloak-dev] View all users for a realm > > If we don't list all users by default, it would be good to update the page's > header to "Search Users" > > On Dec 5, 2013, at 5:07 PM, Stian Thorgersen wrote: > > > > > I should have included the reason why I want it ;) > > ATM there's no way for an admin to list all users. I think we should either > view all users by default, or add "View all" button next to the search. I'm > happy with either, and I'd probably prefer the last option TBH. > > ----- Original Message ----- > > > From: "Bill Burke" < bburke at redhat.com > > > > To: keycloak-dev at lists.jboss.org > > > Sent: Thursday, 5 December, 2013 6:39:11 PM > > > Subject: Re: [keycloak-dev] View all users for a realm > > > > > > Well, he won't see the user if there are N number of users already. > > > > > > On 12/5/2013 11:34 AM, Gabriel Cardoso wrote: > > > > > This is much better from the usability perspective. The way it is, the > > > > > admin creates an user and does not see him listed in the table. This may > > > > > lead him to try to create the same user again ;) > > > > > > > > > > Gabriel > > > > > > > > > > On Dec 5, 2013, at 9:40 AM, Stian Thorgersen wrote: > > > > > > > > > > > > ATM it's only possible to search for users. It should be possible to > > > > > > > also view all users for a realm. > > > > > > > > > > > > > > I propose that we make the users page show all users when there's no > > > > > > > search set. In the future this and all other tables should support > > > > > > > pagination, including pagination support on the rest endpoints, so > > > > > > > that would solve the issue of loading a huge amount of users. > > > > > > > _______________________________________________ > > > > > > > keycloak-dev mailing list > > > > > > > keycloak-dev at lists.jboss.org < mailto:keycloak-dev at lists.jboss.org > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > -- > > > > > Gabriel Cardoso > > > > > GateIn Portal | User Experience Designer > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 > > > -- > Gabriel Cardoso > GateIn Portal | User Experience Designer > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Gabriel Cardoso > GateIn Portal | User Experience Designer > > > > _______________________________________________ > 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/20131212/4606ea52/attachment.html From ssilvert at redhat.com Thu Dec 12 08:57:27 2013 From: ssilvert at redhat.com (ssilvert at redhat.com) Date: Thu, 12 Dec 2013 08:57:27 -0500 Subject: [keycloak-dev] Cancel button on login form In-Reply-To: <760793727.29659431.1386837965457.JavaMail.root@redhat.com> References: <399889774.29095884.1386790051006.JavaMail.root@redhat.com> <52A8D2A7.2030700@redhat.com> <52A8E275.7080901@redhat.com> <760793727.29659431.1386837965457.JavaMail.root@redhat.com> Message-ID: <52A9C0C7.9080009@redhat.com> On 12/12/2013 3:46 AM, Stian Thorgersen wrote: > ----- Original Message ----- >> From: ssilvert at redhat.com >> To: keycloak-dev at lists.jboss.org >> Sent: Wednesday, 11 December, 2013 10:08:53 PM >> Subject: Re: [keycloak-dev] Cancel button on login form >> >> On 12/11/2013 4:01 PM, Bill Burke wrote: >>> On 12/11/2013 2:27 PM, Stian Thorgersen wrote: >>>> I added a cancel button to the login form. It results in a redirect to >>>> "?error=access_denied". >>>> >>>> Problem with it is that it doesn't make sense for all applications to have >>>> it. This mainly applies to applications that require a login, for example >>>> the admin console. Question is what do we do for those? Some >>>> alternatives: >>>> >>> This is not a problem IMO. Let the application decide how it wants to >>> handle a cancel. >> I think there should still be some default behavior. I'm thinking about >> the case where an application was written without any security in mind. >> You just have this unsecured app that you want to hide behind SSO. That >> application wouldn't know what to do. > Makes sense, but wouldn't that be handled by the adapter? Yes, I think that's where default behavior would probably live. > >>>> * Add an optional query param to login that disables it >>>> (.../tokens/login?nocancel) >>>> * Add a config option to the app that's set through admin console >>>> * Leave it and make the app show a sensible error message - "You're >>>> required to login blah blah, click here to login" >>>> >>> or >>> >>> * redirect to "?error=cancelled" >>> >>> or >>> >>> * redirect to "?cancelled=true" >>> >>> or from openid connect >>> >>> * redirect to "?error=interaction_required" >>> >>> Admin console would see this and just redirect back to the login page. >>> >>> >>> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From stian at redhat.com Thu Dec 12 09:09:59 2013 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 12 Dec 2013 09:09:59 -0500 (EST) Subject: [keycloak-dev] View all users for a realm In-Reply-To: <914822194.5747787.1386854862387.JavaMail.root@redhat.com> References: <873497915.24121368.1386243638270.JavaMail.root@redhat.com> <52A0C84F.7080800@redhat.com> <1006249887.24781209.1386270464926.JavaMail.root@redhat.com> <6B50331E-84BA-4F57-9562-EC4629283AB4@redhat.com> <1185164294.5219831.1386773283840.JavaMail.root@redhat.com> <51E2FBAF-5A97-4B08-80F7-31802E69E734@redhat.com> <119063067.29655737.1386837324006.JavaMail.root@redhat.com> <914822194.5747787.1386854862387.JavaMail.root@redhat.com> Message-ID: <1708619793.29841107.1386857399564.JavaMail.root@redhat.com> It's already added I believe For KEYCLOAK-127 that would only work after the user has clicked on view all users, or searched ----- Original Message ----- > From: "Alexandre Mendonca" > To: "Stian Thorgersen" > Cc: "Gabriel Cardoso" , keycloak-dev at lists.jboss.org > Sent: Thursday, 12 December, 2013 1:27:42 PM > Subject: Re: [keycloak-dev] View all users for a realm > > I'll implement this as part of fix for > https://issues.jboss.org/browse/KEYCLOAK-127, if nobody has started with it. > > Alexandre > > ----- Original Message ----- > > From: "Stian Thorgersen" > To: "Gabriel Cardoso" > Cc: keycloak-dev at lists.jboss.org > Sent: Thursday, December 12, 2013 8:35:24 AM > Subject: Re: [keycloak-dev] View all users for a realm > > Looks much better, thanks > > ----- Original Message ----- > > From: "Gabriel Cardoso" > > To: keycloak-dev at lists.jboss.org > > Sent: Wednesday, 11 December, 2013 8:05:47 PM > > Subject: Re: [keycloak-dev] View all users for a realm > > > > I implemented a new design for the button "View all" in the users list. > > Now the button looks like a link and it is next to the search box. > > > > > > Gabriel > > > > On Dec 11, 2013, at 12:48 PM, Alexandre Mendonca wrote: > > > > > > > > > > +1 on listing users. With pagination and the possibility for sorting by > > last > > created/modified we can cover the scenario Gabriel referred to. > > > > Alexandre > > > > > > From: "Gabriel Cardoso" < gcardoso at redhat.com > > > To: keycloak-dev at lists.jboss.org > > Sent: Thursday, December 5, 2013 7:10:52 PM > > Subject: Re: [keycloak-dev] View all users for a realm > > > > If we don't list all users by default, it would be good to update the > > page's > > header to "Search Users" > > > > On Dec 5, 2013, at 5:07 PM, Stian Thorgersen wrote: > > > > > > > > > > I should have included the reason why I want it ;) > > > > ATM there's no way for an admin to list all users. I think we should either > > view all users by default, or add "View all" button next to the search. I'm > > happy with either, and I'd probably prefer the last option TBH. > > > > ----- Original Message ----- > > > > > > From: "Bill Burke" < bburke at redhat.com > > > > > > > To: keycloak-dev at lists.jboss.org > > > > > > Sent: Thursday, 5 December, 2013 6:39:11 PM > > > > > > Subject: Re: [keycloak-dev] View all users for a realm > > > > > > > > > > > > Well, he won't see the user if there are N number of users already. > > > > > > > > > > > > On 12/5/2013 11:34 AM, Gabriel Cardoso wrote: > > > > > > > > > > This is much better from the usability perspective. The way it is, the > > > > > > > > > > admin creates an user and does not see him listed in the table. This may > > > > > > > > > > lead him to try to create the same user again ;) > > > > > > > > > > > > > > > > > > > > Gabriel > > > > > > > > > > > > > > > > > > > > On Dec 5, 2013, at 9:40 AM, Stian Thorgersen wrote: > > > > > > > > > > > > > > > > > > > > > > > > ATM it's only possible to search for users. It should be possible to > > > > > > > > > > > > > > also view all users for a realm. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I propose that we make the users page show all users when there's no > > > > > > > > > > > > > > search set. In the future this and all other tables should support > > > > > > > > > > > > > > pagination, including pagination support on the rest endpoints, so > > > > > > > > > > > > > > that would solve the issue of loading a huge amount of users. > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > keycloak-dev mailing list > > > > > > > > > > > > > > keycloak-dev at lists.jboss.org < mailto:keycloak-dev at lists.jboss.org > > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Gabriel Cardoso > > > > > > > > > > GateIn Portal | User Experience Designer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > 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 > > > > > > -- > > Gabriel Cardoso > > GateIn Portal | User Experience Designer > > > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > -- > > Gabriel Cardoso > > GateIn Portal | User Experience Designer > > > > > > > > _______________________________________________ > > 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 amendonc at redhat.com Thu Dec 12 11:44:23 2013 From: amendonc at redhat.com (Alexandre Mendonca) Date: Thu, 12 Dec 2013 11:44:23 -0500 (EST) Subject: [keycloak-dev] View all users for a realm In-Reply-To: <1708619793.29841107.1386857399564.JavaMail.root@redhat.com> References: <873497915.24121368.1386243638270.JavaMail.root@redhat.com> <1006249887.24781209.1386270464926.JavaMail.root@redhat.com> <6B50331E-84BA-4F57-9562-EC4629283AB4@redhat.com> <1185164294.5219831.1386773283840.JavaMail.root@redhat.com> <51E2FBAF-5A97-4B08-80F7-31802E69E734@redhat.com> <119063067.29655737.1386837324006.JavaMail.root@redhat.com> <914822194.5747787.1386854862387.JavaMail.root@redhat.com> <1708619793.29841107.1386857399564.JavaMail.root@redhat.com> Message-ID: <524028272.5867325.1386866663650.JavaMail.root@redhat.com> Well, breaking KEYCLOAK-127 into pieces: - Hide users table when there is no user [...] This is already done. - [...] and present a feedback message This is also done, although the message "Your search returned no results. Try modifying the query and try again." is not appropriate for the "View all users" action. Relying on search == null to show a different message doesn't work since as soon the user starts typing on the search box it switches to the original message, causing the impression it's a real-time search. Do you think anything should be done regarding this or can we leave it as it is and mark as fixed ? It can be fixed by creating a lastSearch var to keep track and use it on the message show, not sure it's worth it.. Alexandre ----- Original Message ----- From: "Stian Thorgersen" To: "Alexandre Mendonca" Cc: "Gabriel Cardoso" , keycloak-dev at lists.jboss.org Sent: Thursday, December 12, 2013 2:09:59 PM Subject: Re: [keycloak-dev] View all users for a realm It's already added I believe For KEYCLOAK-127 that would only work after the user has clicked on view all users, or searched ----- Original Message ----- > From: "Alexandre Mendonca" > To: "Stian Thorgersen" > Cc: "Gabriel Cardoso" , keycloak-dev at lists.jboss.org > Sent: Thursday, 12 December, 2013 1:27:42 PM > Subject: Re: [keycloak-dev] View all users for a realm > > I'll implement this as part of fix for > https://issues.jboss.org/browse/KEYCLOAK-127, if nobody has started with it. > > Alexandre > > ----- Original Message ----- > > From: "Stian Thorgersen" > To: "Gabriel Cardoso" > Cc: keycloak-dev at lists.jboss.org > Sent: Thursday, December 12, 2013 8:35:24 AM > Subject: Re: [keycloak-dev] View all users for a realm > > Looks much better, thanks > > ----- Original Message ----- > > From: "Gabriel Cardoso" > > To: keycloak-dev at lists.jboss.org > > Sent: Wednesday, 11 December, 2013 8:05:47 PM > > Subject: Re: [keycloak-dev] View all users for a realm > > > > I implemented a new design for the button "View all" in the users list. > > Now the button looks like a link and it is next to the search box. > > > > > > Gabriel > > > > On Dec 11, 2013, at 12:48 PM, Alexandre Mendonca wrote: > > > > > > > > > > +1 on listing users. With pagination and the possibility for sorting by > > last > > created/modified we can cover the scenario Gabriel referred to. > > > > Alexandre > > > > > > From: "Gabriel Cardoso" < gcardoso at redhat.com > > > To: keycloak-dev at lists.jboss.org > > Sent: Thursday, December 5, 2013 7:10:52 PM > > Subject: Re: [keycloak-dev] View all users for a realm > > > > If we don't list all users by default, it would be good to update the > > page's > > header to "Search Users" > > > > On Dec 5, 2013, at 5:07 PM, Stian Thorgersen wrote: > > > > > > > > > > I should have included the reason why I want it ;) > > > > ATM there's no way for an admin to list all users. I think we should either > > view all users by default, or add "View all" button next to the search. I'm > > happy with either, and I'd probably prefer the last option TBH. > > > > ----- Original Message ----- > > > > > > From: "Bill Burke" < bburke at redhat.com > > > > > > > To: keycloak-dev at lists.jboss.org > > > > > > Sent: Thursday, 5 December, 2013 6:39:11 PM > > > > > > Subject: Re: [keycloak-dev] View all users for a realm > > > > > > > > > > > > Well, he won't see the user if there are N number of users already. > > > > > > > > > > > > On 12/5/2013 11:34 AM, Gabriel Cardoso wrote: > > > > > > > > > > This is much better from the usability perspective. The way it is, the > > > > > > > > > > admin creates an user and does not see him listed in the table. This may > > > > > > > > > > lead him to try to create the same user again ;) > > > > > > > > > > > > > > > > > > > > Gabriel > > > > > > > > > > > > > > > > > > > > On Dec 5, 2013, at 9:40 AM, Stian Thorgersen wrote: > > > > > > > > > > > > > > > > > > > > > > > > ATM it's only possible to search for users. It should be possible to > > > > > > > > > > > > > > also view all users for a realm. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I propose that we make the users page show all users when there's no > > > > > > > > > > > > > > search set. In the future this and all other tables should support > > > > > > > > > > > > > > pagination, including pagination support on the rest endpoints, so > > > > > > > > > > > > > > that would solve the issue of loading a huge amount of users. > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > > keycloak-dev mailing list > > > > > > > > > > > > > > keycloak-dev at lists.jboss.org < mailto:keycloak-dev at lists.jboss.org > > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Gabriel Cardoso > > > > > > > > > > GateIn Portal | User Experience Designer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > 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 > > > > > > -- > > Gabriel Cardoso > > GateIn Portal | User Experience Designer > > > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > -- > > Gabriel Cardoso > > GateIn Portal | User Experience Designer > > > > > > > > _______________________________________________ > > 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/20131212/aca65e02/attachment-0001.html From mposolda at redhat.com Thu Dec 12 12:35:00 2013 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 12 Dec 2013 18:35:00 +0100 Subject: [keycloak-dev] Feedback on examples In-Reply-To: <52A86458.9060509@redhat.com> References: <52A74547.2000203@redhat.com> <52A86458.9060509@redhat.com> Message-ID: <52A9F3C4.9070505@redhat.com> On 11.12.2013 14:10, Bill Burke wrote: > > On 12/10/2013 11:45 AM, Marek Posolda wrote: >> I have few points regarding example applications: >> >> - For third-party oauth client example, there is not possibility to >> configure stuff through JSON but everything is hardcoded in classes >> Bootstrap and ProductDatabaseClient. There are also some strange >> comments in code like "This is the worst code ever" etc :-) This is not >> so ideal IMO as I expect that people will often look to the source code >> of these examples for inspiration. I believe that OAuth clients should >> also have something like ManagedResourceConfigLoader for Applications. >> > Feel free to write a better example with CDI or Spring and expand out > the oauth client framework code. I've send PR https://github.com/keycloak/keycloak/pull/134 . Third-party application rewritten to use CDI+JSF and now it read the configuration from JSON file. I've added ManagedOAuthClientConfigLoader (subclass of ManagedResourceConfigLoader) for support of reading configuration of OAuth clients from JSON files. I've also created JIRA https://issues.jboss.org/browse/KEYCLOAK-231 and implemented it in my PR as currently our adapters (both OAuthClient and Applications) don't have any support for sending "scope" parameter to Keycloak server. So now if you have something like this in keycloak.json configuration of your application or oauth-client: "scope" : { "realm" : [ "user" ] } Then auth URL to keycloak will have scope parameter included with those scopes specified in configuration. Marek > >> - For the "third-party" OAuth client, I don't like the fact that when >> user press "Cancel" in OAuth grant page, there is exception in >> server.log and Tomcat error page displayed. I believe the behaviour >> should be more user-friendly. >> > Again, feel free to expand on the third-party app to display something > better. > >> - Examples "customer-portal", "product-portal", "database-service" and >> "oauth-client" are using package "org.jboss.reasteasy..." instead of >> "org.keycloak..." >> > Yeah, holdover from Resteasy code I migrated from. > > From mposolda at redhat.com Thu Dec 12 12:42:31 2013 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 12 Dec 2013 18:42:31 +0100 Subject: [keycloak-dev] Require SSL option In-Reply-To: <52A86E81.6060709@redhat.com> References: <52A73F50.1050508@redhat.com> <52A86327.6070006@redhat.com> <52A869F4.4060902@redhat.com> <52A86E81.6060709@redhat.com> Message-ID: <52A9F587.6080206@redhat.com> I did not found any related JIRA so created https://issues.jboss.org/browse/KEYCLOAK-232 . Marek On 11.12.2013 14:54, Bill Burke wrote: > I think there is a JIRA somewhere to make sure that SSL checks are > made if this flag is set. > > On 12/11/2013 8:34 AM, Marek Posolda wrote: >> ah ok. Thanks. Currently it's used just for cookies. It's allowed to >> have http redirect URLs and authenticate into Keycloak with plain HTTP >> protocol. So should I create JIRA to improve that and add more strict >> checks based on protocol? >> >> Marek >> >> On 11.12.2013 14:05, Bill Burke wrote: >>> Require SSL means that all interaction with Keycloak server is required >>> to be HTTPS. All redirect URLs must also use the HTTPS protocol. Like >>> you said, it also will set "secure" on any set Cookies, but that's only >>> part of it. Other than renaming it to "Require HTTPS", i think the >>> name >>> is appropriate. >>> >>> On 12/10/2013 11:20 AM, Marek Posolda wrote: >>>> Hi, >>>> >>>> I would like to ask what exactly is semantics of realm option "Require >>>> SSL"? My first impression is that if this option is enabled, then >>>> access >>>> to URI like "http://localhost:8080/auth-server/rest/realms/demo/..." >>>> should be allowed just with 'https' protocol instead of plain 'http'. >>>> Actually http access to realm is enabled and login works. Option is >>>> used >>>> just for securing cookies like KEYCLOAK_IDENTITY, so that SSO >>>> reauthentication with cookies is effectively disabled. But >>>> shouldn't we >>>> rename this option to something "Use secured cookie" then? Name >>>> "Require >>>> SSL" seems to be confusing IMO. >>>> >>>> There is also one more issue >>>> https://issues.jboss.org/browse/KEYCLOAK-227 due to the fact that >>>> option >>>> doesn't affect just KEYCLOAK_IDENTITY cookie but also >>>> KEYCLOAK_ACCOUNT_IDENTITY, which means that I am always redirected >>>> back >>>> to login form after successful login in case that login has been >>>> triggered for AccountManagement application. >>>> >>>> WDYT? >>>> Marek >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >> > From ssilvert at redhat.com Thu Dec 12 14:40:14 2013 From: ssilvert at redhat.com (ssilvert at redhat.com) Date: Thu, 12 Dec 2013 14:40:14 -0500 Subject: [keycloak-dev] Required fields? Message-ID: <52AA111E.5040303@redhat.com> I'm working on letting the user specify the keycloak.json attributes from the keycloak subsystem. Each attribute in ManagedResourceConfig becomes something you can change by editing standalone.xml or using CLI. I just need to know which attributes required for a keycloak deployment. https://raw.github.com/keycloak/keycloak/master/core/src/main/java/org/keycloak/adapters/config/ManagedResourceConfig.java >From the code in ManagedResourceConfigLoader, it looks like the required fields are: realm resource realm-public-key auth-url code-url Is that correct? Stan From bburke at redhat.com Thu Dec 12 15:14:18 2013 From: bburke at redhat.com (Bill Burke) Date: Thu, 12 Dec 2013 15:14:18 -0500 Subject: [keycloak-dev] Required fields? In-Reply-To: <52AA111E.5040303@redhat.com> References: <52AA111E.5040303@redhat.com> Message-ID: <52AA191A.7060808@redhat.com> Are you doing it like PL had it and specifying the WAR name? There's really two sets of config: Realm config (* if required): realm* realm-public-key* auth-url* code-url* ssl-not-required allow-any-hostname disable-trust-manager truststore (* if ssl and disable-trust-manager not set) truststore-password (* if ssl and disable-trust-manager not set) connection-pool-size Application config: resource use-resource-role-mappings credentials bearer-only Could be defined in both places to provide a default value (realm level) and override (app level) enable-cors client-keystore client-keystore-password client-key-password cors-max-age cors-allowed-headers cors-allowed-methods expose-token Also a ResteasyClient (or Apache Http Client) should be created per realm or per Wildfly/EAP instance and shared by each application. There's also some refactoring that needs to be done here. i.e. auth-url/code-urls should be combined into a realm url. FYI, I'm about to refactor AS7/EAP adapter to either use an older version of Resteasy or Apache HTtp Client. I don't want to required patching Resteasy to 3.0.5 for AS7/EAP applications. On 12/12/2013 2:40 PM, ssilvert at redhat.com wrote: > I'm working on letting the user specify the keycloak.json attributes > from the keycloak subsystem. Each attribute in ManagedResourceConfig > becomes something you can change by editing standalone.xml or using CLI. > > I just need to know which attributes required for a keycloak deployment. > https://raw.github.com/keycloak/keycloak/master/core/src/main/java/org/keycloak/adapters/config/ManagedResourceConfig.java > >>From the code in ManagedResourceConfigLoader, it looks like the required > fields are: > realm > resource > realm-public-key > auth-url > code-url > > Is that correct? > > 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 bburke at redhat.com Thu Dec 12 15:18:17 2013 From: bburke at redhat.com (Bill Burke) Date: Thu, 12 Dec 2013 15:18:17 -0500 Subject: [keycloak-dev] Feedback on examples In-Reply-To: <52A9F3C4.9070505@redhat.com> References: <52A74547.2000203@redhat.com> <52A86458.9060509@redhat.com> <52A9F3C4.9070505@redhat.com> Message-ID: <52AA1A09.3080705@redhat.com> On 12/12/2013 12:35 PM, Marek Posolda wrote: > On 11.12.2013 14:10, Bill Burke wrote: >> >> On 12/10/2013 11:45 AM, Marek Posolda wrote: >>> I have few points regarding example applications: >>> >>> - For third-party oauth client example, there is not possibility to >>> configure stuff through JSON but everything is hardcoded in classes >>> Bootstrap and ProductDatabaseClient. There are also some strange >>> comments in code like "This is the worst code ever" etc :-) This is not >>> so ideal IMO as I expect that people will often look to the source code >>> of these examples for inspiration. I believe that OAuth clients should >>> also have something like ManagedResourceConfigLoader for Applications. >>> >> Feel free to write a better example with CDI or Spring and expand out >> the oauth client framework code. > I've send PR https://github.com/keycloak/keycloak/pull/134 . Third-party > application rewritten to use CDI+JSF and now it read the configuration > from JSON file. I've added ManagedOAuthClientConfigLoader (subclass of > ManagedResourceConfigLoader) for support of reading configuration of > OAuth clients from JSON files. > > I've also created JIRA https://issues.jboss.org/browse/KEYCLOAK-231 and > implemented it in my PR as currently our adapters (both OAuthClient and > Applications) don't have any support for sending "scope" parameter to > Keycloak server. > > So now if you have something like this in keycloak.json configuration of > your application or oauth-client: > "scope" : { > "realm" : [ "user" ] > } > I'm not sure we need a "scope" parameter. Scope is already configured and defined within the admin console for each application and/or oauth client. Apps/oauth clients just can't ask for any role they want, they must have permission to ask for that role. The only purpose a "scope" parameter would provide would be to reduce the size of the access token. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From ssilvert at redhat.com Thu Dec 12 16:01:13 2013 From: ssilvert at redhat.com (ssilvert at redhat.com) Date: Thu, 12 Dec 2013 16:01:13 -0500 Subject: [keycloak-dev] Required fields? In-Reply-To: <52AA191A.7060808@redhat.com> References: <52AA111E.5040303@redhat.com> <52AA191A.7060808@redhat.com> Message-ID: <52AA2419.7080608@redhat.com> On 12/12/2013 3:14 PM, Bill Burke wrote: > Are you doing it like PL had it and specifying the WAR name? It's the deployment name, which is usually the same as the WAR name. It's the same idea as PL's subsystem. At deployment time, we dynamically add everything you would normally need to specify inside the deployment. I'm focusing on WildFly for now. Any ETA on when that will be ready? I can do EAP6 if you think it's a must-have. If we support EAP6 we will not be able to manage the subsystem from the Keycloak admin console. The only way you would be able to do it is by editing standalone.xml/domain.xml, or issuing CLI commands. With WildFly we will (hopefully) have CORS support and we can manage the subsystem from the Keycloak admin console. Thanks for the explanation of the attributes. All that looks good. I'm not sure what to do about the RestEasy client. How is creation and sharing of the client done today? > There's > really two sets of config: > > Realm config (* if required): > > realm* > realm-public-key* > auth-url* > code-url* > ssl-not-required > allow-any-hostname > disable-trust-manager > truststore (* if ssl and disable-trust-manager not set) > truststore-password (* if ssl and disable-trust-manager not set) > connection-pool-size > > > Application config: > > resource > use-resource-role-mappings > credentials > bearer-only > > Could be defined in both places to provide a default value (realm level) > and override (app level) > > enable-cors > client-keystore > client-keystore-password > client-key-password > cors-max-age > cors-allowed-headers > cors-allowed-methods > expose-token > > Also a ResteasyClient (or Apache Http Client) should be created per > realm or per Wildfly/EAP instance and shared by each application. > There's also some refactoring that needs to be done here. i.e. > auth-url/code-urls should be combined into a realm url. > > FYI, I'm about to refactor AS7/EAP adapter to either use an older > version of Resteasy or Apache HTtp Client. I don't want to required > patching Resteasy to 3.0.5 for AS7/EAP applications. > > > > > On 12/12/2013 2:40 PM, ssilvert at redhat.com wrote: >> I'm working on letting the user specify the keycloak.json attributes >> from the keycloak subsystem. Each attribute in ManagedResourceConfig >> becomes something you can change by editing standalone.xml or using CLI. >> >> I just need to know which attributes required for a keycloak deployment. >> https://raw.github.com/keycloak/keycloak/master/core/src/main/java/org/keycloak/adapters/config/ManagedResourceConfig.java >> >> >From the code in ManagedResourceConfigLoader, it looks like the required >> fields are: >> realm >> resource >> realm-public-key >> auth-url >> code-url >> >> Is that correct? >> >> Stan >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From bburke at redhat.com Thu Dec 12 16:08:47 2013 From: bburke at redhat.com (Bill Burke) Date: Thu, 12 Dec 2013 16:08:47 -0500 Subject: [keycloak-dev] Required fields? In-Reply-To: <52AA2419.7080608@redhat.com> References: <52AA111E.5040303@redhat.com> <52AA191A.7060808@redhat.com> <52AA2419.7080608@redhat.com> Message-ID: <52AA25DF.2060802@redhat.com> On 12/12/2013 4:01 PM, ssilvert at redhat.com wrote: > On 12/12/2013 3:14 PM, Bill Burke wrote: >> Are you doing it like PL had it and specifying the WAR name? > It's the deployment name, which is usually the same as the WAR name. > It's the same idea as PL's subsystem. At deployment time, we > dynamically add everything you would normally need to specify inside the > deployment. > > I'm focusing on WildFly for now. Any ETA on when that will be ready? > Looks like Wildfly master has the latest Undertow. We're kind of dependent on Wildfly beta 2 being released if we want to provide anything in Alpha 1. > I can do EAP6 if you think it's a must-have. If we support EAP6 we will > not be able to manage the subsystem from the Keycloak admin console. > The only way you would be able to do it is by editing > standalone.xml/domain.xml, or issuing CLI commands. > I think we would want some kind of subsystem for EAP so we can provide some more centralized configuration and sharing of system resources. > With WildFly we will (hopefully) have CORS support and we can manage the > subsystem from the Keycloak admin console. > > Thanks for the explanation of the attributes. All that looks good. > > I'm not sure what to do about the RestEasy client. How is creation and > sharing of the client done today? Client is created per war deployment right now. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From mposolda at redhat.com Fri Dec 13 04:14:37 2013 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 13 Dec 2013 10:14:37 +0100 Subject: [keycloak-dev] Feedback on examples In-Reply-To: <52AA1A09.3080705@redhat.com> References: <52A74547.2000203@redhat.com> <52A86458.9060509@redhat.com> <52A9F3C4.9070505@redhat.com> <52AA1A09.3080705@redhat.com> Message-ID: <52AACFFD.3040406@redhat.com> On 12.12.2013 21:18, Bill Burke wrote: > > > On 12/12/2013 12:35 PM, Marek Posolda wrote: >> On 11.12.2013 14:10, Bill Burke wrote: >>> >>> On 12/10/2013 11:45 AM, Marek Posolda wrote: >>>> I have few points regarding example applications: >>>> >>>> - For third-party oauth client example, there is not possibility to >>>> configure stuff through JSON but everything is hardcoded in classes >>>> Bootstrap and ProductDatabaseClient. There are also some strange >>>> comments in code like "This is the worst code ever" etc :-) This is >>>> not >>>> so ideal IMO as I expect that people will often look to the source >>>> code >>>> of these examples for inspiration. I believe that OAuth clients should >>>> also have something like ManagedResourceConfigLoader for Applications. >>>> >>> Feel free to write a better example with CDI or Spring and expand out >>> the oauth client framework code. >> I've send PR https://github.com/keycloak/keycloak/pull/134 . Third-party >> application rewritten to use CDI+JSF and now it read the configuration >> from JSON file. I've added ManagedOAuthClientConfigLoader (subclass of >> ManagedResourceConfigLoader) for support of reading configuration of >> OAuth clients from JSON files. >> >> I've also created JIRA https://issues.jboss.org/browse/KEYCLOAK-231 and >> implemented it in my PR as currently our adapters (both OAuthClient and >> Applications) don't have any support for sending "scope" parameter to >> Keycloak server. >> >> So now if you have something like this in keycloak.json configuration of >> your application or oauth-client: >> "scope" : { >> "realm" : [ "user" ] >> } >> > > I'm not sure we need a "scope" parameter. Scope is already configured > and defined within the admin console for each application and/or oauth > client. Apps/oauth clients just can't ask for any role they want, > they must have permission to ask for that role. The only purpose a > "scope" parameter would provide would be to reduce the size of the > access token. > Parameter "scope" is currently supported on auth-server side and in OAuth2 specs, so it makes sense to have some support for it also on apps/oauth-clients side IMO. One use-case could be reducing the size of access token. Another use-case is, that administrator of particular application/oauth-client doesn't have admin permission of the Keycloak SSO server against he wants to authenticate (due to some corporate policy or whatever), so in this case only possibility for him to reduce required scopes is through the "scope" parameter. I think it's important especially for oauth-clients as users need to accept all scopes in OAuth grant screen and the more permissions are required, the less is the chance that user doesn't want to grant that permissions. Marek From stian at redhat.com Fri Dec 13 07:58:55 2013 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 13 Dec 2013 07:58:55 -0500 (EST) Subject: [keycloak-dev] Feedback on examples In-Reply-To: <52AACFFD.3040406@redhat.com> References: <52A74547.2000203@redhat.com> <52A86458.9060509@redhat.com> <52A9F3C4.9070505@redhat.com> <52AA1A09.3080705@redhat.com> <52AACFFD.3040406@redhat.com> Message-ID: <645020501.30621325.1386939535529.JavaMail.root@redhat.com> There's also another use-case for it. An application may have permission to ask for a lot of scopes, but where only a subset of those are relevant to most users. It should then only ask for the scopes that are specifically required per-user. ----- Original Message ----- > From: "Marek Posolda" > To: "Bill Burke" > Cc: keycloak-dev at lists.jboss.org > Sent: Friday, 13 December, 2013 9:14:37 AM > Subject: Re: [keycloak-dev] Feedback on examples > > On 12.12.2013 21:18, Bill Burke wrote: > > > > > > On 12/12/2013 12:35 PM, Marek Posolda wrote: > >> On 11.12.2013 14:10, Bill Burke wrote: > >>> > >>> On 12/10/2013 11:45 AM, Marek Posolda wrote: > >>>> I have few points regarding example applications: > >>>> > >>>> - For third-party oauth client example, there is not possibility to > >>>> configure stuff through JSON but everything is hardcoded in classes > >>>> Bootstrap and ProductDatabaseClient. There are also some strange > >>>> comments in code like "This is the worst code ever" etc :-) This is > >>>> not > >>>> so ideal IMO as I expect that people will often look to the source > >>>> code > >>>> of these examples for inspiration. I believe that OAuth clients should > >>>> also have something like ManagedResourceConfigLoader for Applications. > >>>> > >>> Feel free to write a better example with CDI or Spring and expand out > >>> the oauth client framework code. > >> I've send PR https://github.com/keycloak/keycloak/pull/134 . Third-party > >> application rewritten to use CDI+JSF and now it read the configuration > >> from JSON file. I've added ManagedOAuthClientConfigLoader (subclass of > >> ManagedResourceConfigLoader) for support of reading configuration of > >> OAuth clients from JSON files. > >> > >> I've also created JIRA https://issues.jboss.org/browse/KEYCLOAK-231 and > >> implemented it in my PR as currently our adapters (both OAuthClient and > >> Applications) don't have any support for sending "scope" parameter to > >> Keycloak server. > >> > >> So now if you have something like this in keycloak.json configuration of > >> your application or oauth-client: > >> "scope" : { > >> "realm" : [ "user" ] > >> } > >> > > > > I'm not sure we need a "scope" parameter. Scope is already configured > > and defined within the admin console for each application and/or oauth > > client. Apps/oauth clients just can't ask for any role they want, > > they must have permission to ask for that role. The only purpose a > > "scope" parameter would provide would be to reduce the size of the > > access token. > > > Parameter "scope" is currently supported on auth-server side and in > OAuth2 specs, so it makes sense to have some support for it also on > apps/oauth-clients side IMO. > > One use-case could be reducing the size of access token. Another > use-case is, that administrator of particular application/oauth-client > doesn't have admin permission of the Keycloak SSO server against he > wants to authenticate (due to some corporate policy or whatever), so in > this case only possibility for him to reduce required scopes is through > the "scope" parameter. I think it's important especially for > oauth-clients as users need to accept all scopes in OAuth grant screen > and the more permissions are required, the less is the chance that user > doesn't want to grant that permissions. > > Marek > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bburke at redhat.com Fri Dec 13 19:22:21 2013 From: bburke at redhat.com (Bill Burke) Date: Fri, 13 Dec 2013 19:22:21 -0500 Subject: [keycloak-dev] Somebody broke build Message-ID: <52ABA4BD.6040804@redhat.com> Tests in error: changePassword(org.keycloak.testsuite.forms.AccountTest): No link found with text: Logout(..) -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Fri Dec 13 19:57:22 2013 From: bburke at redhat.com (Bill Burke) Date: Fri, 13 Dec 2013 19:57:22 -0500 Subject: [keycloak-dev] Somebody broke build In-Reply-To: <52ABA4BD.6040804@redhat.com> References: <52ABA4BD.6040804@redhat.com> Message-ID: <52ABACF2.5070308@redhat.com> It is @Ignored in master. Please fix it: https://issues.jboss.org/browse/KEYCLOAK-235 On 12/13/2013 7:22 PM, Bill Burke wrote: > Tests in error: > changePassword(org.keycloak.testsuite.forms.AccountTest): No link > found with text: Logout(..) > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Fri Dec 13 19:58:58 2013 From: bburke at redhat.com (Bill Burke) Date: Fri, 13 Dec 2013 19:58:58 -0500 Subject: [keycloak-dev] started adapter refactor Message-ID: <52ABAD52.2090509@redhat.com> I renamed some files in keycloak-core and also moved some to a new module keycloak-adapter-core. This may screw up some of your work so please fetch/merge. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Fri Dec 13 20:27:52 2013 From: bburke at redhat.com (Bill Burke) Date: Fri, 13 Dec 2013 20:27:52 -0500 Subject: [keycloak-dev] removing resteasy from adapter requires: Message-ID: <52ABB418.8060805@redhat.com> removing resteasy dependencies from adapter dependencies requires: * Forking and gutting JOSE-JWT module so we can have JSON web signatures (and maybe JWE later too) * Forking UriBuilder. There's a lot of functionality there that will make our code easier. * Forking some of UriInfo as again, a lot of helper methods there that will make our coding easier. * Relying on Apache Http Client APIs compatible with 4.1.2. This version is compatible with the version that comes in both AS7 and EAP and Wildfly. Wildfly may upgrade to 4.3 and I don't know if this version maintains backward compatibility with 4.1.2. I just don't think using java.net.URL for client HTTP is very feasible and I distinctly remember having problems with connection caching and things like that. I thought about using the Resteasy client that comes with AS7, EAP, Wildfly, but I'm worried that users may upgrade Resteasy to an incompatible version. I'm also still going to use Jackson 1.9.x. Jackson 2.x uses an entirely different package name so we're safe relying on it. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Sat Dec 14 07:45:06 2013 From: stian at redhat.com (Stian Thorgersen) Date: Sat, 14 Dec 2013 07:45:06 -0500 (EST) Subject: [keycloak-dev] removing resteasy from adapter requires: In-Reply-To: <52ABB418.8060805@redhat.com> References: <52ABB418.8060805@redhat.com> Message-ID: <1268432685.31360569.1387025106338.JavaMail.root@redhat.com> IMO this is all things we'd need to do any ways. I'd leave it until after M1 though, so we can do it properly (I'll send a separate email). ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Saturday, 14 December, 2013 1:27:52 AM > Subject: [keycloak-dev] removing resteasy from adapter requires: > > removing resteasy dependencies from adapter dependencies requires: > > * Forking and gutting JOSE-JWT module so we can have JSON web signatures > (and maybe JWE later too) > * Forking UriBuilder. There's a lot of functionality there that will > make our code easier. > * Forking some of UriInfo as again, a lot of helper methods there that > will make our coding easier. > * Relying on Apache Http Client APIs compatible with 4.1.2. This > version is compatible with the version that comes in both AS7 and EAP > and Wildfly. Wildfly may upgrade to 4.3 and I don't know if this > version maintains backward compatibility with 4.1.2. I just don't think > using java.net.URL for client HTTP is very feasible and I distinctly > remember having problems with connection caching and things like that. > > I thought about using the Resteasy client that comes with AS7, EAP, > Wildfly, but I'm worried that users may upgrade Resteasy to an > incompatible version. > > I'm also still going to use Jackson 1.9.x. Jackson 2.x uses an entirely > different package name so we're safe relying on it. > -- > 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 Sat Dec 14 07:57:46 2013 From: stian at redhat.com (Stian Thorgersen) Date: Sat, 14 Dec 2013 07:57:46 -0500 (EST) Subject: [keycloak-dev] Keycloak server environments In-Reply-To: <651179698.31360635.1387025192976.JavaMail.root@redhat.com> Message-ID: <1640303656.31360978.1387025866443.JavaMail.root@redhat.com> Currently Keycloak runs on Undertow and relies heavily on Resteasy. This doesn't work for the LiveOak project in the long run. After M1 I would like to create a Keycloak core that doesn't depend on Undertow or Resteasy. This should provide most of the logic except for wiring-up endpoints. For WildFly/EAP I would assume we'd provide endpoints using Undertow/Resteasy. Those would live in the Keycloak project. Then me and Marek will provide endpoints using Liveoak, these would live in the Liveoak project. Further, for some dependencies I'd also like to make these pluggable. For example http client and json processing. Not sure what libraries would be required, but I basically don't want to bring in yet-another-library if one exists in Liveoak that can do the job. In summary what I want to do is to make sure Keycloak can be run on both WildFly/EAP and LiveOak and at the same time: * Share as much as possible of the code * Implement REST endpoints in Liveoak with the minimum amount of code * Reduce the amount of dependencies Keycloak introduces in Liveoak From stian at redhat.com Sat Dec 14 08:35:04 2013 From: stian at redhat.com (Stian Thorgersen) Date: Sat, 14 Dec 2013 08:35:04 -0500 (EST) Subject: [keycloak-dev] Somebody broke build In-Reply-To: <52ABACF2.5070308@redhat.com> References: <52ABA4BD.6040804@redhat.com> <52ABACF2.5070308@redhat.com> Message-ID: <888348650.31362994.1387028104244.JavaMail.root@redhat.com> My bad, I merged a PR from Gabriel without running the tests first. It would be great to have tests run automatically for PR's. Can you set that up, or do you want me to look into it? ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Saturday, 14 December, 2013 12:57:22 AM > Subject: Re: [keycloak-dev] Somebody broke build > > It is @Ignored in master. Please fix it: > > https://issues.jboss.org/browse/KEYCLOAK-235 > > On 12/13/2013 7:22 PM, Bill Burke wrote: > > Tests in error: > > changePassword(org.keycloak.testsuite.forms.AccountTest): No link > > found with text: Logout(..) > > > > -- > 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 gcardoso at redhat.com Mon Dec 16 08:43:07 2013 From: gcardoso at redhat.com (Gabriel Cardoso) Date: Mon, 16 Dec 2013 11:43:07 -0200 Subject: [keycloak-dev] Somebody broke build In-Reply-To: <888348650.31362994.1387028104244.JavaMail.root@redhat.com> References: <52ABA4BD.6040804@redhat.com> <52ABACF2.5070308@redhat.com> <888348650.31362994.1387028104244.JavaMail.root@redhat.com> Message-ID: Sorry guys. That's probably the side effect of a designer working on the code ;) I've just asked Stian how do I run the tests. Gabriel On Dec 14, 2013, at 11:35 AM, Stian Thorgersen wrote: > My bad, I merged a PR from Gabriel without running the tests first. > > It would be great to have tests run automatically for PR's. Can you set that up, or do you want me to look into it? > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Saturday, 14 December, 2013 12:57:22 AM >> Subject: Re: [keycloak-dev] Somebody broke build >> >> It is @Ignored in master. Please fix it: >> >> https://issues.jboss.org/browse/KEYCLOAK-235 >> >> On 12/13/2013 7:22 PM, Bill Burke wrote: >>> Tests in error: >>> changePassword(org.keycloak.testsuite.forms.AccountTest): No link >>> found with text: Logout(..) >>> >> >> -- >> 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 -- Gabriel Cardoso GateIn Portal | User Experience Designer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20131216/ec19126a/attachment-0001.html From bburke at redhat.com Mon Dec 16 08:46:20 2013 From: bburke at redhat.com (Bill Burke) Date: Mon, 16 Dec 2013 08:46:20 -0500 Subject: [keycloak-dev] removing resteasy from adapter requires: In-Reply-To: <1268432685.31360569.1387025106338.JavaMail.root@redhat.com> References: <52ABB418.8060805@redhat.com> <1268432685.31360569.1387025106338.JavaMail.root@redhat.com> Message-ID: <52AF042C.6020702@redhat.com> Needs to be done for M1 as upgrading Resteasy may not be an option for AS7/EAP users. This is purely at the adapter level. And I'm sure I'm capable of doing it properly :) On 12/14/2013 7:45 AM, Stian Thorgersen wrote: > IMO this is all things we'd need to do any ways. I'd leave it until after M1 though, so we can do it properly (I'll send a separate email). > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Saturday, 14 December, 2013 1:27:52 AM >> Subject: [keycloak-dev] removing resteasy from adapter requires: >> >> removing resteasy dependencies from adapter dependencies requires: >> >> * Forking and gutting JOSE-JWT module so we can have JSON web signatures >> (and maybe JWE later too) >> * Forking UriBuilder. There's a lot of functionality there that will >> make our code easier. >> * Forking some of UriInfo as again, a lot of helper methods there that >> will make our coding easier. >> * Relying on Apache Http Client APIs compatible with 4.1.2. This >> version is compatible with the version that comes in both AS7 and EAP >> and Wildfly. Wildfly may upgrade to 4.3 and I don't know if this >> version maintains backward compatibility with 4.1.2. I just don't think >> using java.net.URL for client HTTP is very feasible and I distinctly >> remember having problems with connection caching and things like that. >> >> I thought about using the Resteasy client that comes with AS7, EAP, >> Wildfly, but I'm worried that users may upgrade Resteasy to an >> incompatible version. >> >> I'm also still going to use Jackson 1.9.x. Jackson 2.x uses an entirely >> different package name so we're safe relying on it. >> -- >> 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 bburke at redhat.com Mon Dec 16 08:52:22 2013 From: bburke at redhat.com (Bill Burke) Date: Mon, 16 Dec 2013 08:52:22 -0500 Subject: [keycloak-dev] Keycloak server environments In-Reply-To: <1640303656.31360978.1387025866443.JavaMail.root@redhat.com> References: <1640303656.31360978.1387025866443.JavaMail.root@redhat.com> Message-ID: <52AF0596.1090102@redhat.com> Do what you want, but I think its silly to not just adapt LiveOak to use Resteasy/JAX-RS. If LiveOak supports BIO/Streams, it would be easy to adapt Resteasy to run in that environment. Its already been done for Netty 3 and 4, JDK HTTP, and even Grizzly. On 12/14/2013 7:57 AM, Stian Thorgersen wrote: > Currently Keycloak runs on Undertow and relies heavily on Resteasy. This doesn't work for the LiveOak project in the long run. > > After M1 I would like to create a Keycloak core that doesn't depend on Undertow or Resteasy. This should provide most of the logic except for wiring-up endpoints. For WildFly/EAP I would assume we'd provide endpoints using Undertow/Resteasy. Those would live in the Keycloak project. Then me and Marek will provide endpoints using Liveoak, these would live in the Liveoak project. > > Further, for some dependencies I'd also like to make these pluggable. For example http client and json processing. Not sure what libraries would be required, but I basically don't want to bring in yet-another-library if one exists in Liveoak that can do the job. > > In summary what I want to do is to make sure Keycloak can be run on both WildFly/EAP and LiveOak and at the same time: > > * Share as much as possible of the code > * Implement REST endpoints in Liveoak with the minimum amount of code > * Reduce the amount of dependencies Keycloak introduces in Liveoak > _______________________________________________ > 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 bburke at redhat.com Mon Dec 16 09:09:53 2013 From: bburke at redhat.com (Bill Burke) Date: Mon, 16 Dec 2013 09:09:53 -0500 Subject: [keycloak-dev] Keycloak server environments In-Reply-To: <52AF0596.1090102@redhat.com> References: <1640303656.31360978.1387025866443.JavaMail.root@redhat.com> <52AF0596.1090102@redhat.com> Message-ID: <52AF09B1.7060001@redhat.com> On 12/16/2013 8:52 AM, Bill Burke wrote: > Do what you want, but I think its silly to not just adapt LiveOak to use > Resteasy/JAX-RS. If LiveOak supports BIO/Streams, it would be easy to > adapt Resteasy to run in that environment. Its already been done for > Netty 3 and 4, JDK HTTP, and even Grizzly. > That being said, the code does need refactoring to get the bits that aren't JAX-RS specific into a Java API that could be used. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Mon Dec 16 09:47:18 2013 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 16 Dec 2013 09:47:18 -0500 (EST) Subject: [keycloak-dev] removing resteasy from adapter requires: In-Reply-To: <52AF042C.6020702@redhat.com> References: <52ABB418.8060805@redhat.com> <1268432685.31360569.1387025106338.JavaMail.root@redhat.com> <52AF042C.6020702@redhat.com> Message-ID: <1029281376.31916891.1387205238417.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Monday, 16 December, 2013 1:46:20 PM > Subject: Re: [keycloak-dev] removing resteasy from adapter requires: > > Needs to be done for M1 as upgrading Resteasy may not be an option for > AS7/EAP users. > > This is purely at the adapter level. And I'm sure I'm capable of doing > it properly :) Forgot that Resteasy needs to be upgraded in AS7 atm, so makes perfect sense to do it now. I was thinking that you where doing some clean-up/refactoring ;) > > On 12/14/2013 7:45 AM, Stian Thorgersen wrote: > > IMO this is all things we'd need to do any ways. I'd leave it until after > > M1 though, so we can do it properly (I'll send a separate email). > > > > ----- Original Message ----- > >> From: "Bill Burke" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Saturday, 14 December, 2013 1:27:52 AM > >> Subject: [keycloak-dev] removing resteasy from adapter requires: > >> > >> removing resteasy dependencies from adapter dependencies requires: > >> > >> * Forking and gutting JOSE-JWT module so we can have JSON web signatures > >> (and maybe JWE later too) > >> * Forking UriBuilder. There's a lot of functionality there that will > >> make our code easier. > >> * Forking some of UriInfo as again, a lot of helper methods there that > >> will make our coding easier. > >> * Relying on Apache Http Client APIs compatible with 4.1.2. This > >> version is compatible with the version that comes in both AS7 and EAP > >> and Wildfly. Wildfly may upgrade to 4.3 and I don't know if this > >> version maintains backward compatibility with 4.1.2. I just don't think > >> using java.net.URL for client HTTP is very feasible and I distinctly > >> remember having problems with connection caching and things like that. > >> > >> I thought about using the Resteasy client that comes with AS7, EAP, > >> Wildfly, but I'm worried that users may upgrade Resteasy to an > >> incompatible version. > >> > >> I'm also still going to use Jackson 1.9.x. Jackson 2.x uses an entirely > >> different package name so we're safe relying on it. > >> -- > >> 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 bburke at redhat.com Mon Dec 16 11:27:28 2013 From: bburke at redhat.com (Bill Burke) Date: Mon, 16 Dec 2013 11:27:28 -0500 Subject: [keycloak-dev] big refactor to remove resteasy jose/jwt Message-ID: <52AF29F0.3040201@redhat.com> Okay, I forked jose-jwt module for Resteasy and remove JAX-RS specific stuff. Had to touch a bunch of files outside of "core" module. I also started the process of moving JAX-RS stuff out of "core" module so I created a new "core-jaxrs" module. This module may be temporary, not sure. "core" no longer depends on Resteasy/JAX-RS. Next I'll be working more on the adapters to refactor out resteasy. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Mon Dec 16 11:31:18 2013 From: bburke at redhat.com (Bill Burke) Date: Mon, 16 Dec 2013 11:31:18 -0500 Subject: [keycloak-dev] examples/as7-eap6-demo/server files Message-ID: <52AF2AD6.2030800@redhat.com> Please don't delete these. I need to move what I've done to your "server" module. This WAR is a prototype on how to define JBoss Modules exclusions so that Resteasy 3 can be included directly within the Keycloak Server WAR. This will allow us to distribute the same WAR for AS7, EAP, and Wildfly. Bill -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From Anil.Saldhana at redhat.com Mon Dec 16 11:31:51 2013 From: Anil.Saldhana at redhat.com (Anil Saldhana) Date: Mon, 16 Dec 2013 10:31:51 -0600 Subject: [keycloak-dev] big refactor to remove resteasy jose/jwt In-Reply-To: <52AF29F0.3040201@redhat.com> References: <52AF29F0.3040201@redhat.com> Message-ID: <52AF2AF7.1050201@redhat.com> I wanted to ask the team about independent jars to deal with: a) JOSE/JWT. b) Object Model for OpenID Connect I know KeyCloak/RESTEasy has code for this. Would it be a good idea to have these extracted out into independent KeyCloak minor projects => jars? On 12/16/2013 10:27 AM, Bill Burke wrote: > Okay, > > I forked jose-jwt module for Resteasy and remove JAX-RS specific stuff. > Had to touch a bunch of files outside of "core" module. I also > started the process of moving JAX-RS stuff out of "core" module so I > created a new "core-jaxrs" module. This module may be temporary, not sure. > > "core" no longer depends on Resteasy/JAX-RS. > > Next I'll be working more on the adapters to refactor out resteasy. > > From gcardoso at redhat.com Mon Dec 16 15:34:19 2013 From: gcardoso at redhat.com (Gabriel Cardoso) Date: Mon, 16 Dec 2013 18:34:19 -0200 Subject: [keycloak-dev] realm import/upload implemented In-Reply-To: References: <52A256F9.1090504@redhat.com> <268738801.25973492.1386411974554.JavaMail.root@redhat.com> Message-ID: <22DDE71A-7507-4B33-B0DC-0B1BFDC12A69@redhat.com> Hi guys, I proposed a new design for this component and implemented it in my client-side version: http://ejsclient-cardosogabriel.rhcloud.com/application-settings.html The user will initially see the button (above). After he chooses the file, the name of the file is displayed, with an option to change the file chosen (below). If he clicks on change, he sees the button again (above). Since we are not presenting the native input file (it is invisible above the button), the name of the file is not displayed after choosing a file. So we would have to get this name and "print" it on the screen. What do you guys think? Let's go for this solution? Gabriel On Dec 10, 2013, at 1:42 AM, Gabriel Cardoso wrote: > Definitely! I'll work on a design for it :) > > On Dec 7, 2013, at 8:26 AM, Stian Thorgersen wrote: > >> Nice :) >> >> It does indeed need some design touches, Gabriel? >> >> ----- Original Message ----- >>> From: "Bill Burke" >>> To: keycloak-dev at lists.jboss.org >>> Sent: Friday, 6 December, 2013 11:00:09 PM >>> Subject: [keycloak-dev] realm import/upload implemented >>> >>> Stian made a great point earlier. "How are you planning to run the >>> demo?" Booting up the keycloak server with a System property is, well, >>> kinda hacky/lame and not useful beyond demo purposes. >>> >>> So... >>> >>> I implemented realm import, file upload on the "CREATE REALM" page. So, >>> on the create realm page, there are 2 fieldsets. One allows you to >>> upload a json file, the other allows you to create a realm with a >>> specific name. Importing/upload currently brings you to the realm list >>> page. I'll fix that to redirect if possible. >>> >>> This new page may need some design. >>> -- >>> 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 > > > -- > Gabriel Cardoso > GateIn Portal | User Experience Designer > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Gabriel Cardoso GateIn Portal | User Experience Designer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20131216/fe240c9a/attachment-0001.html From bburke at redhat.com Tue Dec 17 11:07:07 2013 From: bburke at redhat.com (Bill Burke) Date: Tue, 17 Dec 2013 11:07:07 -0500 Subject: [keycloak-dev] realm import/upload implemented In-Reply-To: <22DDE71A-7507-4B33-B0DC-0B1BFDC12A69@redhat.com> References: <52A256F9.1090504@redhat.com> <268738801.25973492.1386411974554.JavaMail.root@redhat.com> <22DDE71A-7507-4B33-B0DC-0B1BFDC12A69@redhat.com> Message-ID: <52B076AB.7020202@redhat.com> I like your "Import Realm" fieldset. I don't like the other fieldsets though. It is *WAY* too much information on the page. I want either to import or enter a name of a new realm. On 12/16/2013 3:34 PM, Gabriel Cardoso wrote: > Hi guys, > > I proposed a new design for this component and implemented it in my > client-side version: > http://ejsclient-cardosogabriel.rhcloud.com/application-settings.html > > The user will initially see the button (above). After he chooses the > file, the name of the file is displayed, with an option to change the > file chosen (below). If he clicks on change, he sees the button again > (above). > > Since we are not presenting the native input file (it is invisible above > the button), the name of the file is not displayed after choosing a > file. So we would have to get this name and "print" it on the screen. > > What do you guys think? Let's go for this solution? > > Gabriel > > On Dec 10, 2013, at 1:42 AM, Gabriel Cardoso wrote: > >> Definitely! I'll work on a design for it :) >> >> On Dec 7, 2013, at 8:26 AM, Stian Thorgersen wrote: >> >>> Nice :) >>> >>> It does indeed need some design touches, Gabriel? >>> >>> ----- Original Message ----- >>>> From: "Bill Burke" > >>>> To: keycloak-dev at lists.jboss.org >>>> Sent: Friday, 6 December, 2013 11:00:09 PM >>>> Subject: [keycloak-dev] realm import/upload implemented >>>> >>>> Stian made a great point earlier. "How are you planning to run the >>>> demo?" Booting up the keycloak server with a System property is, well, >>>> kinda hacky/lame and not useful beyond demo purposes. >>>> >>>> So... >>>> >>>> I implemented realm import, file upload on the "CREATE REALM" page. So, >>>> on the create realm page, there are 2 fieldsets. One allows you to >>>> upload a json file, the other allows you to create a realm with a >>>> specific name. Importing/upload currently brings you to the realm list >>>> page. I'll fix that to redirect if possible. >>>> >>>> This new page may need some design. >>>> -- >>>> 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 >> >> >> -- >> Gabriel Cardoso >> GateIn Portal | User Experience Designer >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > -- > Gabriel Cardoso > GateIn Portal | User Experience Designer > > > > > _______________________________________________ > 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 gcardoso at redhat.com Tue Dec 17 11:52:14 2013 From: gcardoso at redhat.com (Gabriel Cardoso) Date: Tue, 17 Dec 2013 14:52:14 -0200 Subject: [keycloak-dev] realm import/upload implemented In-Reply-To: <52B076AB.7020202@redhat.com> References: <52A256F9.1090504@redhat.com> <268738801.25973492.1386411974554.JavaMail.root@redhat.com> <22DDE71A-7507-4B33-B0DC-0B1BFDC12A69@redhat.com> <52B076AB.7020202@redhat.com> Message-ID: Please ignore all the other field sets, I just put the "Import Realm" fieldset in a page I already had ;) Ok, so I will implement the component and put it commented in the code, so the feature will keep available until you don't implement the logics for my component. I'll open a JIRA for that. Gabriel On Dec 17, 2013, at 2:07 PM, Bill Burke wrote: > I like your "Import Realm" fieldset. I don't like the other fieldsets > though. It is *WAY* too much information on the page. I want either to > import or enter a name of a new realm. > > On 12/16/2013 3:34 PM, Gabriel Cardoso wrote: >> Hi guys, >> >> I proposed a new design for this component and implemented it in my >> client-side version: >> http://ejsclient-cardosogabriel.rhcloud.com/application-settings.html >> >> The user will initially see the button (above). After he chooses the >> file, the name of the file is displayed, with an option to change the >> file chosen (below). If he clicks on change, he sees the button again >> (above). >> >> Since we are not presenting the native input file (it is invisible above >> the button), the name of the file is not displayed after choosing a >> file. So we would have to get this name and "print" it on the screen. >> >> What do you guys think? Let's go for this solution? >> >> Gabriel >> >> On Dec 10, 2013, at 1:42 AM, Gabriel Cardoso wrote: >> >>> Definitely! I'll work on a design for it :) >>> >>> On Dec 7, 2013, at 8:26 AM, Stian Thorgersen wrote: >>> >>>> Nice :) >>>> >>>> It does indeed need some design touches, Gabriel? >>>> >>>> ----- Original Message ----- >>>>> From: "Bill Burke" > >>>>> To: keycloak-dev at lists.jboss.org >>>>> Sent: Friday, 6 December, 2013 11:00:09 PM >>>>> Subject: [keycloak-dev] realm import/upload implemented >>>>> >>>>> Stian made a great point earlier. "How are you planning to run the >>>>> demo?" Booting up the keycloak server with a System property is, well, >>>>> kinda hacky/lame and not useful beyond demo purposes. >>>>> >>>>> So... >>>>> >>>>> I implemented realm import, file upload on the "CREATE REALM" page. So, >>>>> on the create realm page, there are 2 fieldsets. One allows you to >>>>> upload a json file, the other allows you to create a realm with a >>>>> specific name. Importing/upload currently brings you to the realm list >>>>> page. I'll fix that to redirect if possible. >>>>> >>>>> This new page may need some design. >>>>> -- >>>>> 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 >>> >>> >>> -- >>> Gabriel Cardoso >>> GateIn Portal | User Experience Designer >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> -- >> Gabriel Cardoso >> GateIn Portal | User Experience Designer >> >> >> >> >> _______________________________________________ >> 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 -- Gabriel Cardoso GateIn Portal | User Experience Designer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20131217/706f9961/attachment.html From bburke at redhat.com Tue Dec 17 12:31:57 2013 From: bburke at redhat.com (Bill Burke) Date: Tue, 17 Dec 2013 12:31:57 -0500 Subject: [keycloak-dev] Adapter refactor Step 1 complete Message-ID: <52B08A8D.2050305@redhat.com> Resteasy has been factored out of all the adapters. The demo also no longer requires Resteasy, nor does it require a Resteasy upgrade to 3.0. So, it now runs out of the box with AS 7.1.1 and EAP 6.1 There's a lot more new modules. keycloak-core-jaxrs - Which may go away keycloak-adapter-core keycloak-jaxrs-oauth-client keycloak-servlet-oauth-client We do now heavily depend on Apache Client 4.1.2 which is compatible with 4.2.1. But, I can't see a way around that as using java.net.URL is not feasible. Next, I'm going to finish up the Undertow/Wildfly adapter because I need to make sure the refactored Undertow Security SPIs will still work with Keycloak. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From ssilvert at redhat.com Tue Dec 17 15:01:00 2013 From: ssilvert at redhat.com (ssilvert at redhat.com) Date: Tue, 17 Dec 2013 15:01:00 -0500 Subject: [keycloak-dev] Required fields? In-Reply-To: <52AA191A.7060808@redhat.com> References: <52AA111E.5040303@redhat.com> <52AA191A.7060808@redhat.com> Message-ID: <52B0AD7C.5080606@redhat.com> Bill, When you have a moment, can you pick some reasonable defaults for all these? null (undefined) is OK as a default for most attributes, but it doesn't really make sense for booleans. In a subsystem, if you leave a boolean undefined then it is unclear to the user how the runtime will treat it. On 12/12/2013 3:14 PM, Bill Burke wrote: > Are you doing it like PL had it and specifying the WAR name? There's > really two sets of config: > > Realm config (* if required): > > realm* > realm-public-key* > auth-url* > code-url* > ssl-not-required > allow-any-hostname > disable-trust-manager > truststore (* if ssl and disable-trust-manager not set) > truststore-password (* if ssl and disable-trust-manager not set) > connection-pool-size > > > Application config: > > resource > use-resource-role-mappings > credentials > bearer-only > > Could be defined in both places to provide a default value (realm level) > and override (app level) > > enable-cors > client-keystore > client-keystore-password > client-key-password > cors-max-age > cors-allowed-headers > cors-allowed-methods > expose-token > > Also a ResteasyClient (or Apache Http Client) should be created per > realm or per Wildfly/EAP instance and shared by each application. > There's also some refactoring that needs to be done here. i.e. > auth-url/code-urls should be combined into a realm url. > > FYI, I'm about to refactor AS7/EAP adapter to either use an older > version of Resteasy or Apache HTtp Client. I don't want to required > patching Resteasy to 3.0.5 for AS7/EAP applications. > > > > > On 12/12/2013 2:40 PM, ssilvert at redhat.com wrote: >> I'm working on letting the user specify the keycloak.json attributes >> from the keycloak subsystem. Each attribute in ManagedResourceConfig >> becomes something you can change by editing standalone.xml or using CLI. >> >> I just need to know which attributes required for a keycloak deployment. >> https://raw.github.com/keycloak/keycloak/master/core/src/main/java/org/keycloak/adapters/config/ManagedResourceConfig.java >> >> >From the code in ManagedResourceConfigLoader, it looks like the required >> fields are: >> realm >> resource >> realm-public-key >> auth-url >> code-url >> >> Is that correct? >> >> Stan >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From psilva at redhat.com Wed Dec 18 06:37:02 2013 From: psilva at redhat.com (Pedro Igor Silva) Date: Wed, 18 Dec 2013 06:37:02 -0500 (EST) Subject: [keycloak-dev] Congratulations Message-ID: <1508674600.44028670.1387366622471.JavaMail.root@redhat.com> Hi guys, I've watched Bill's videos about KeyCloak. KeyCloak looks awesome ! Congrats. Regards. Pedro Igor From bburke at redhat.com Wed Dec 18 09:11:08 2013 From: bburke at redhat.com (Bill Burke) Date: Wed, 18 Dec 2013 09:11:08 -0500 Subject: [keycloak-dev] Congratulations In-Reply-To: <1508674600.44028670.1387366622471.JavaMail.root@redhat.com> References: <1508674600.44028670.1387366622471.JavaMail.root@redhat.com> Message-ID: <52B1ACFC.5070906@redhat.com> Thanks. I hope you see where we're headed now...Going forward we need to figure out how Picketlink IDM API fits in. We have an configurable option to use it, but it is not the primary option right now. I and others have ideas, we'll talk after Christmas. On 12/18/2013 6:37 AM, Pedro Igor Silva wrote: > Hi guys, > > I've watched Bill's videos about KeyCloak. KeyCloak looks awesome ! Congrats. > > Regards. > Pedro Igor > _______________________________________________ > 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 Dec 18 12:41:55 2013 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 18 Dec 2013 12:41:55 -0500 (EST) Subject: [keycloak-dev] Keycloak server environments In-Reply-To: <52AF09B1.7060001@redhat.com> References: <1640303656.31360978.1387025866443.JavaMail.root@redhat.com> <52AF0596.1090102@redhat.com> <52AF09B1.7060001@redhat.com> Message-ID: <14640465.34684808.1387388515934.JavaMail.root@redhat.com> Resteasy/JAX-RS on LiveOak makes as much sense as margarine on butter. LiveOak is a container for REST resources and doesn't provide direct access to BIO/Streams. ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Monday, 16 December, 2013 2:09:53 PM > Subject: Re: [keycloak-dev] Keycloak server environments > > > > On 12/16/2013 8:52 AM, Bill Burke wrote: > > Do what you want, but I think its silly to not just adapt LiveOak to use > > Resteasy/JAX-RS. If LiveOak supports BIO/Streams, it would be easy to > > adapt Resteasy to run in that environment. Its already been done for > > Netty 3 and 4, JDK HTTP, and even Grizzly. > > > > That being said, the code does need refactoring to get the bits that > aren't JAX-RS specific into a Java API that could be used. > > > -- > 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 Wed Dec 18 12:57:03 2013 From: bburke at redhat.com (Bill Burke) Date: Wed, 18 Dec 2013 12:57:03 -0500 Subject: [keycloak-dev] Keycloak server environments In-Reply-To: <14640465.34684808.1387388515934.JavaMail.root@redhat.com> References: <1640303656.31360978.1387025866443.JavaMail.root@redhat.com> <52AF0596.1090102@redhat.com> <52AF09B1.7060001@redhat.com> <14640465.34684808.1387388515934.JavaMail.root@redhat.com> Message-ID: <52B1E1EF.5090408@redhat.com> Again, create extra work for yourself if you want to...But if LiveOak is using Netty or Undertow, no reason JAX-RS can't be plugged in. Its funny how Vert.x can place so much importance on polyglot, yet can't support a simple REST framework. On 12/18/2013 12:41 PM, Stian Thorgersen wrote: > Resteasy/JAX-RS on LiveOak makes as much sense as margarine on butter. LiveOak is a container for REST resources and doesn't provide direct access to BIO/Streams. > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Monday, 16 December, 2013 2:09:53 PM >> Subject: Re: [keycloak-dev] Keycloak server environments >> >> >> >> On 12/16/2013 8:52 AM, Bill Burke wrote: >>> Do what you want, but I think its silly to not just adapt LiveOak to use >>> Resteasy/JAX-RS. If LiveOak supports BIO/Streams, it would be easy to >>> adapt Resteasy to run in that environment. Its already been done for >>> Netty 3 and 4, JDK HTTP, and even Grizzly. >>> >> >> That being said, the code does need refactoring to get the bits that >> aren't JAX-RS specific into a Java API that could be used. >> >> >> -- >> 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 bburke at redhat.com Wed Dec 18 18:20:46 2013 From: bburke at redhat.com (Bill Burke) Date: Wed, 18 Dec 2013 18:20:46 -0500 Subject: [keycloak-dev] wildfly/undertow adapter mostly working Message-ID: <52B22DCE.6010109@redhat.com> Requires GIT master branch of Wildfly (beta2). * boot wildfly $ cd examples/wildfly-demo $ mvn clean install $ mvn jboss-as:deploy I still have to implement logout for the adapter and test CORS stuff. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From mposolda at redhat.com Thu Dec 19 00:50:57 2013 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 19 Dec 2013 06:50:57 +0100 Subject: [keycloak-dev] realm import/upload implemented In-Reply-To: References: <52A256F9.1090504@redhat.com> <268738801.25973492.1386411974554.JavaMail.root@redhat.com> <22DDE71A-7507-4B33-B0DC-0B1BFDC12A69@redhat.com> <52B076AB.7020202@redhat.com> Message-ID: <52B28941.2000903@redhat.com> I wonder if we also want to support export existing realms to JSON file in admin console? Might be useful especially for migration between environments (from stage to production etc) Marek On 17.12.2013 17:52, Gabriel Cardoso wrote: > Please ignore all the other field sets, I just put the "Import Realm" > fieldset in a page I already had ;) > > Ok, so I will implement the component and put it commented in the > code, so the feature will keep available until you don't implement the > logics for my component. > > I'll open a JIRA for that. > > Gabriel > > On Dec 17, 2013, at 2:07 PM, Bill Burke wrote: > >> I like your "Import Realm" fieldset. I don't like the other fieldsets >> though. It is *WAY* too much information on the page. I want either to >> import or enter a name of a new realm. >> >> On 12/16/2013 3:34 PM, Gabriel Cardoso wrote: >>> Hi guys, >>> >>> I proposed a new design for this component and implemented it in my >>> client-side version: >>> http://ejsclient-cardosogabriel.rhcloud.com/application-settings.html >>> >>> The user will initially see the button (above). After he chooses the >>> file, the name of the file is displayed, with an option to change the >>> file chosen (below). If he clicks on change, he sees the button again >>> (above). >>> >>> Since we are not presenting the native input file (it is invisible above >>> the button), the name of the file is not displayed after choosing a >>> file. So we would have to get this name and "print" it on the screen. >>> >>> What do you guys think? Let's go for this solution? >>> >>> Gabriel >>> >>> On Dec 10, 2013, at 1:42 AM, Gabriel Cardoso wrote: >>> >>>> Definitely! I'll work on a design for it :) >>>> >>>> On Dec 7, 2013, at 8:26 AM, Stian Thorgersen wrote: >>>> >>>>> Nice :) >>>>> >>>>> It does indeed need some design touches, Gabriel? >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Bill Burke" >>>>>> > >>>>>> To: keycloak-dev at lists.jboss.org >>>>>> >>>>>> >>>>>> Sent: Friday, 6 December, 2013 11:00:09 PM >>>>>> Subject: [keycloak-dev] realm import/upload implemented >>>>>> >>>>>> Stian made a great point earlier. "How are you planning to run the >>>>>> demo?" Booting up the keycloak server with a System property is, >>>>>> well, >>>>>> kinda hacky/lame and not useful beyond demo purposes. >>>>>> >>>>>> So... >>>>>> >>>>>> I implemented realm import, file upload on the "CREATE REALM" >>>>>> page. So, >>>>>> on the create realm page, there are 2 fieldsets. One allows you to >>>>>> upload a json file, the other allows you to create a realm with a >>>>>> specific name. Importing/upload currently brings you to the >>>>>> realm list >>>>>> page. I'll fix that to redirect if possible. >>>>>> >>>>>> This new page may need some design. >>>>>> -- >>>>>> 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 >>>> >>>> >>>> -- >>>> Gabriel Cardoso >>>> GateIn Portal | User Experience Designer >>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> -- >>> Gabriel Cardoso >>> GateIn Portal | User Experience Designer >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > > > -- > Gabriel Cardoso > GateIn Portal | User Experience Designer > > > > > _______________________________________________ > 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/20131219/e23da0a2/attachment-0001.html From stian at redhat.com Thu Dec 19 03:42:32 2013 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 19 Dec 2013 03:42:32 -0500 (EST) Subject: [keycloak-dev] realm import/upload implemented In-Reply-To: <52B28941.2000903@redhat.com> References: <52A256F9.1090504@redhat.com> <268738801.25973492.1386411974554.JavaMail.root@redhat.com> <22DDE71A-7507-4B33-B0DC-0B1BFDC12A69@redhat.com> <52B076AB.7020202@redhat.com> <52B28941.2000903@redhat.com> Message-ID: <1546673075.35244997.1387442552091.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Marek Posolda" > To: "Gabriel Cardoso" > Cc: keycloak-dev at lists.jboss.org > Sent: Thursday, 19 December, 2013 5:50:57 AM > Subject: Re: [keycloak-dev] realm import/upload implemented > > I wonder if we also want to support export existing realms to JSON file in > admin console? Might be useful especially for migration between environments > (from stage to production etc) +1 > > Marek > > On 17.12.2013 17:52, Gabriel Cardoso wrote: > > > > Please ignore all the other field sets, I just put the "Import Realm" > fieldset in a page I already had ;) > > Ok, so I will implement the component and put it commented in the code, so > the feature will keep available until you don't implement the logics for my > component. > > I'll open a JIRA for that. > > Gabriel > > On Dec 17, 2013, at 2:07 PM, Bill Burke wrote: > > > > > I like your "Import Realm" fieldset. I don't like the other fieldsets > though. It is *WAY* too much information on the page. I want either to > import or enter a name of a new realm. > > On 12/16/2013 3:34 PM, Gabriel Cardoso wrote: > > > Hi guys, > > > > > > I proposed a new design for this component and implemented it in my > > > client-side version: > > > http://ejsclient-cardosogabriel.rhcloud.com/application-settings.html > > > > > > The user will initially see the button (above). After he chooses the > > > file, the name of the file is displayed, with an option to change the > > > file chosen (below). If he clicks on change, he sees the button again > > > (above). > > > > > > Since we are not presenting the native input file (it is invisible above > > > the button), the name of the file is not displayed after choosing a > > > file. So we would have to get this name and "print" it on the screen. > > > > > > What do you guys think? Let's go for this solution? > > > > > > Gabriel > > > > > > On Dec 10, 2013, at 1:42 AM, Gabriel Cardoso wrote: > > > > > > > > Definitely! I'll work on a design for it :) > > > > > > > > > > On Dec 7, 2013, at 8:26 AM, Stian Thorgersen wrote: > > > > > > > > > > > > Nice :) > > > > > > > > > > > > > > It does indeed need some design touches, Gabriel? > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > From: "Bill Burke" < bburke at redhat.com < mailto:bburke at redhat.com >> > > > > > > > > > To: keycloak-dev at lists.jboss.org < mailto:keycloak-dev at lists.jboss.org > > > > > > > > > > Sent: Friday, 6 December, 2013 11:00:09 PM > > > > > > > > > Subject: [keycloak-dev] realm import/upload implemented > > > > > > > > > > > > > > > > > > Stian made a great point earlier. "How are you planning to run the > > > > > > > > > demo?" Booting up the keycloak server with a System property is, well, > > > > > > > > > kinda hacky/lame and not useful beyond demo purposes. > > > > > > > > > > > > > > > > > > So... > > > > > > > > > > > > > > > > > > I implemented realm import, file upload on the "CREATE REALM" page. So, > > > > > > > > > on the create realm page, there are 2 fieldsets. One allows you to > > > > > > > > > upload a json file, the other allows you to create a realm with a > > > > > > > > > specific name. Importing/upload currently brings you to the realm list > > > > > > > > > page. I'll fix that to redirect if possible. > > > > > > > > > > > > > > > > > > This new page may need some design. > > > > > > > > > -- > > > > > > > > > Bill Burke > > > > > > > > > JBoss, a division of Red Hat > > > > > > > > > http://bill.burkecentral.com < http://bill.burkecentral.com/ > > > > > > > > > > _______________________________________________ > > > > > > > > > keycloak-dev mailing list > > > > > > > > > keycloak-dev at lists.jboss.org < mailto:keycloak-dev at lists.jboss.org > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > keycloak-dev mailing list > > > > > > > keycloak-dev at lists.jboss.org < mailto:keycloak-dev at lists.jboss.org > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > -- > > > > > Gabriel Cardoso > > > > > GateIn Portal | User Experience Designer > > > > > > > > > > > > > > > _______________________________________________ > > > > > keycloak-dev mailing list > > > > > keycloak-dev at lists.jboss.org < mailto:keycloak-dev at lists.jboss.org > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > -- > > > Gabriel Cardoso > > > GateIn Portal | User Experience Designer > > > > > > > > > > > > > > > _______________________________________________ > > > 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 > > > -- > Gabriel Cardoso > GateIn Portal | User Experience Designer > > > > > _______________________________________________ > 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 Dec 19 09:14:15 2013 From: bburke at redhat.com (Bill Burke) Date: Thu, 19 Dec 2013 09:14:15 -0500 Subject: [keycloak-dev] realm import/upload implemented In-Reply-To: <1546673075.35244997.1387442552091.JavaMail.root@redhat.com> References: <52A256F9.1090504@redhat.com> <268738801.25973492.1386411974554.JavaMail.root@redhat.com> <22DDE71A-7507-4B33-B0DC-0B1BFDC12A69@redhat.com> <52B076AB.7020202@redhat.com> <52B28941.2000903@redhat.com> <1546673075.35244997.1387442552091.JavaMail.root@redhat.com> Message-ID: <52B2FF37.5030404@redhat.com> On 12/19/2013 3:42 AM, Stian Thorgersen wrote: > > > ----- Original Message ----- >> From: "Marek Posolda" >> To: "Gabriel Cardoso" >> Cc: keycloak-dev at lists.jboss.org >> Sent: Thursday, 19 December, 2013 5:50:57 AM >> Subject: Re: [keycloak-dev] realm import/upload implemented >> >> I wonder if we also want to support export existing realms to JSON file in >> admin console? Might be useful especially for migration between environments >> (from stage to production etc) > > +1 > I thought about this long ago, that any export facility should only be available locally and not remotely. Maybe I'm just overparanoid? Bill -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Thu Dec 19 10:41:24 2013 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 19 Dec 2013 10:41:24 -0500 (EST) Subject: [keycloak-dev] realm import/upload implemented In-Reply-To: <52B2FF37.5030404@redhat.com> References: <52A256F9.1090504@redhat.com> <22DDE71A-7507-4B33-B0DC-0B1BFDC12A69@redhat.com> <52B076AB.7020202@redhat.com> <52B28941.2000903@redhat.com> <1546673075.35244997.1387442552091.JavaMail.root@redhat.com> <52B2FF37.5030404@redhat.com> Message-ID: <1011258256.35663346.1387467684693.JavaMail.root@redhat.com> If someone can access the REST endpoints they can quite easily do an "export" themselves. What should not be exposed through the REST endpoints is the private key or any credentials. So an export will not work fully. Export/import would require re-generating keys + resetting all user/app/client passwords. Even hashed passwords can be cracked so we shouldn't have a REST endpoint exposing them.. ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Thursday, 19 December, 2013 2:14:15 PM > Subject: Re: [keycloak-dev] realm import/upload implemented > > > > On 12/19/2013 3:42 AM, Stian Thorgersen wrote: > > > > > > ----- Original Message ----- > >> From: "Marek Posolda" > >> To: "Gabriel Cardoso" > >> Cc: keycloak-dev at lists.jboss.org > >> Sent: Thursday, 19 December, 2013 5:50:57 AM > >> Subject: Re: [keycloak-dev] realm import/upload implemented > >> > >> I wonder if we also want to support export existing realms to JSON file in > >> admin console? Might be useful especially for migration between > >> environments > >> (from stage to production etc) > > > > +1 > > > > I thought about this long ago, that any export facility should only be > available locally and not remotely. Maybe I'm just overparanoid? > > Bill > > > -- > 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 Dec 19 10:49:00 2013 From: bburke at redhat.com (Bill Burke) Date: Thu, 19 Dec 2013 10:49:00 -0500 Subject: [keycloak-dev] realm import/upload implemented In-Reply-To: <1011258256.35663346.1387467684693.JavaMail.root@redhat.com> References: <52A256F9.1090504@redhat.com> <22DDE71A-7507-4B33-B0DC-0B1BFDC12A69@redhat.com> <52B076AB.7020202@redhat.com> <52B28941.2000903@redhat.com> <1546673075.35244997.1387442552091.JavaMail.root@redhat.com> <52B2FF37.5030404@redhat.com> <1011258256.35663346.1387467684693.JavaMail.root@redhat.com> Message-ID: <52B3156C.8070107@redhat.com> Ya, i was talking solely about private keys and credentials. I think a "full" export might also be needed for migration. For example if the persistence model changes between Keycloak 1.0 and Keycloak 2.0 or users want to completely change their backend database type, i.e. RDBMS - Mongo. On 12/19/2013 10:41 AM, Stian Thorgersen wrote: > If someone can access the REST endpoints they can quite easily do an "export" themselves. > > What should not be exposed through the REST endpoints is the private key or any credentials. So an export will not work fully. Export/import would require re-generating keys + resetting all user/app/client passwords. Even hashed passwords can be cracked so we shouldn't have a REST endpoint exposing them.. > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Thursday, 19 December, 2013 2:14:15 PM >> Subject: Re: [keycloak-dev] realm import/upload implemented >> >> >> >> On 12/19/2013 3:42 AM, Stian Thorgersen wrote: >>> >>> >>> ----- Original Message ----- >>>> From: "Marek Posolda" >>>> To: "Gabriel Cardoso" >>>> Cc: keycloak-dev at lists.jboss.org >>>> Sent: Thursday, 19 December, 2013 5:50:57 AM >>>> Subject: Re: [keycloak-dev] realm import/upload implemented >>>> >>>> I wonder if we also want to support export existing realms to JSON file in >>>> admin console? Might be useful especially for migration between >>>> environments >>>> (from stage to production etc) >>> >>> +1 >>> >> >> I thought about this long ago, that any export facility should only be >> available locally and not remotely. Maybe I'm just overparanoid? >> >> Bill >> >> >> -- >> 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 Thu Dec 19 11:03:27 2013 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 19 Dec 2013 11:03:27 -0500 (EST) Subject: [keycloak-dev] realm import/upload implemented In-Reply-To: <52B3156C.8070107@redhat.com> References: <52A256F9.1090504@redhat.com> <52B076AB.7020202@redhat.com> <52B28941.2000903@redhat.com> <1546673075.35244997.1387442552091.JavaMail.root@redhat.com> <52B2FF37.5030404@redhat.com> <1011258256.35663346.1387467684693.JavaMail.root@redhat.com> <52B3156C.8070107@redhat.com> Message-ID: <647572902.35683453.1387469007293.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Thursday, 19 December, 2013 3:49:00 PM > Subject: Re: [keycloak-dev] realm import/upload implemented > > Ya, i was talking solely about private keys and credentials. > > I think a "full" export might also be needed for migration. For example > if the persistence model changes between Keycloak 1.0 and Keycloak 2.0 > or users want to completely change their backend database type, i.e. > RDBMS - Mongo. +1 > > > On 12/19/2013 10:41 AM, Stian Thorgersen wrote: > > If someone can access the REST endpoints they can quite easily do an > > "export" themselves. > > > > What should not be exposed through the REST endpoints is the private key or > > any credentials. So an export will not work fully. Export/import would > > require re-generating keys + resetting all user/app/client passwords. Even > > hashed passwords can be cracked so we shouldn't have a REST endpoint > > exposing them.. > > > > ----- Original Message ----- > >> From: "Bill Burke" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Thursday, 19 December, 2013 2:14:15 PM > >> Subject: Re: [keycloak-dev] realm import/upload implemented > >> > >> > >> > >> On 12/19/2013 3:42 AM, Stian Thorgersen wrote: > >>> > >>> > >>> ----- Original Message ----- > >>>> From: "Marek Posolda" > >>>> To: "Gabriel Cardoso" > >>>> Cc: keycloak-dev at lists.jboss.org > >>>> Sent: Thursday, 19 December, 2013 5:50:57 AM > >>>> Subject: Re: [keycloak-dev] realm import/upload implemented > >>>> > >>>> I wonder if we also want to support export existing realms to JSON file > >>>> in > >>>> admin console? Might be useful especially for migration between > >>>> environments > >>>> (from stage to production etc) > >>> > >>> +1 > >>> > >> > >> I thought about this long ago, that any export facility should only be > >> available locally and not remotely. Maybe I'm just overparanoid? > >> > >> Bill > >> > >> > >> -- > >> 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 bburke at redhat.com Thu Dec 19 18:38:22 2013 From: bburke at redhat.com (Bill Burke) Date: Thu, 19 Dec 2013 18:38:22 -0500 Subject: [keycloak-dev] wildfly/undertow adapter mostly working In-Reply-To: <52B22DCE.6010109@redhat.com> References: <52B22DCE.6010109@redhat.com> Message-ID: <52B3836E.2090201@redhat.com> logout implemented. Need to test CORS next and refactor the adapter a bit afterwards. On 12/18/2013 6:20 PM, Bill Burke wrote: > Requires GIT master branch of Wildfly (beta2). > > * boot wildfly > > $ cd examples/wildfly-demo > $ mvn clean install > $ mvn jboss-as:deploy > > I still have to implement logout for the adapter and test CORS stuff. > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bruno at abstractj.org Fri Dec 20 07:17:26 2013 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 20 Dec 2013 10:17:26 -0200 Subject: [keycloak-dev] [off-topic] - Keycloak on AeroGear Message-ID: Good morning guys, FYI I?ve started to migrate everything related with ag-security to Keycloak (http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Keycloak-on-AeroGear-td5663.html). I hope to upstream/contribute with our needs during our development. Congratulations about the project. -- abstractj From stian at redhat.com Fri Dec 20 08:22:52 2013 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 20 Dec 2013 08:22:52 -0500 (EST) Subject: [keycloak-dev] [off-topic] - Keycloak on AeroGear In-Reply-To: References: Message-ID: <184023756.36418808.1387545772329.JavaMail.root@redhat.com> Excellent news, and feel free to ask as many questions as you'd like! We're also using Keycloak in LiveOak, and there's a JS library there. That may be reusable in AeroGear as well. Some feedback on it would be great. https://github.com/liveoak-io/liveoak/blob/master/clients/javascript/src/main/javascript/auth/client.js BTW I usually hang out in #aerogear as stianst ----- Original Message ----- > From: "Bruno Oliveira" > To: keycloak-dev at lists.jboss.org > Sent: Friday, 20 December, 2013 12:17:26 PM > Subject: [keycloak-dev] [off-topic] - Keycloak on AeroGear > > Good morning guys, FYI I?ve started to migrate everything related with > ag-security to Keycloak > (http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Keycloak-on-AeroGear-td5663.html). > I hope to upstream/contribute with our needs during our development. > > Congratulations about the project. > > -- > abstractj > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From sblanc at redhat.com Fri Dec 20 08:31:13 2013 From: sblanc at redhat.com (Sebastien Blanc) Date: Fri, 20 Dec 2013 14:31:13 +0100 Subject: [keycloak-dev] [off-topic] - Keycloak on AeroGear In-Reply-To: <184023756.36418808.1387545772329.JavaMail.root@redhat.com> References: <184023756.36418808.1387545772329.JavaMail.root@redhat.com> Message-ID: <52B446A1.3080908@redhat.com> On 12/20/2013 02:22 PM, Stian Thorgersen wrote: > Excellent news, and feel free to ask as many questions as you'd like! > > We're also using Keycloak in LiveOak, and there's a JS library there. That may be reusable in AeroGear as well. Some feedback on it would be great. > > https://github.com/liveoak-io/liveoak/blob/master/clients/javascript/src/main/javascript/auth/client.js > > BTW I usually hang out in #aerogear as stianst > > ----- Original Message ----- >> From: "Bruno Oliveira" >> To: keycloak-dev at lists.jboss.org >> Sent: Friday, 20 December, 2013 12:17:26 PM >> Subject: [keycloak-dev] [off-topic] - Keycloak on AeroGear >> >> Good morning guys, FYI I?ve started to migrate everything related with >> ag-security to Keycloak >> (http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Keycloak-on-AeroGear-td5663.html). >> I hope to upstream/contribute with our needs during our development. >> >> Congratulations about the project. >> >> -- >> abstractj >> >> _______________________________________________ >> 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 We just added oauth support on AeroGear-Javascript : https://github.com/aerogear/aerogear-js/blob/master/src/authorization/adapters/oauth2.js We could do some mutual feedback/review and offer then the ultimate killer client ;) Seb -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20131220/5ae57411/attachment.html From bburke at redhat.com Fri Dec 20 09:14:42 2013 From: bburke at redhat.com (Bill Burke) Date: Fri, 20 Dec 2013 09:14:42 -0500 Subject: [keycloak-dev] [off-topic] - Keycloak on AeroGear In-Reply-To: <52B446A1.3080908@redhat.com> References: <184023756.36418808.1387545772329.JavaMail.root@redhat.com> <52B446A1.3080908@redhat.com> Message-ID: <52B450D2.5010803@redhat.com> On 12/20/2013 8:31 AM, Sebastien Blanc wrote: > We just added oauth support on AeroGear-Javascript : > https://github.com/aerogear/aerogear-js/blob/master/src/authorization/adapters/oauth2.js > We could do some mutual feedback/review and offer then the ultimate > killer client ;) Stian has done a lot of work around this too. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Fri Dec 20 09:18:14 2013 From: bburke at redhat.com (Bill Burke) Date: Fri, 20 Dec 2013 09:18:14 -0500 Subject: [keycloak-dev] [off-topic] - Keycloak on AeroGear In-Reply-To: References: Message-ID: <52B451A6.3070609@redhat.com> Bruno, I'm also interested in your key management work. Client-cert support is also something on the TODO list. We also need to have a talk with Aerogear to brainstorm on how to secure/manage devices. I have some ideas around both the UI and the protocol. Nothing concrete yet. On 12/20/2013 7:17 AM, Bruno Oliveira wrote: > Good morning guys, FYI I?ve started to migrate everything related with ag-security to Keycloak (http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Keycloak-on-AeroGear-td5663.html). I hope to upstream/contribute with our needs during our development. > > Congratulations about the project. > > -- > abstractj > > _______________________________________________ > 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 bruno at abstractj.org Fri Dec 20 09:32:45 2013 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 20 Dec 2013 12:32:45 -0200 Subject: [keycloak-dev] [off-topic] - Keycloak on AeroGear In-Reply-To: <52B451A6.3070609@redhat.com> References: <52B451A6.3070609@redhat.com> Message-ID: Thanks a lot guys, count me in, I would love to hear your ideas. I?m planning to start testing OAuth2 with AeroGear on the next week.? -- abstractj On December 20, 2013 at 12:18:13 PM, Bill Burke (bburke at redhat.com) wrote: > > Bruno, I'm also interested in your key management work. Client-cert > support is also something on the TODO list. We also need to have > a talk > with Aerogear to brainstorm on how to secure/manage devices. > I have > some ideas around both the UI and the protocol. Nothing concrete > yet. > > On 12/20/2013 7:17 AM, Bruno Oliveira wrote: > > Good morning guys, FYI I?ve started to migrate everything related > with ag-security to Keycloak (http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Keycloak-on-AeroGear-td5663.html). > I hope to upstream/contribute with our needs during our development. > > > > Congratulations about the project. > > > > -- > > abstractj > > > > _______________________________________________ > > 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 stian at redhat.com Fri Dec 20 11:12:56 2013 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 20 Dec 2013 11:12:56 -0500 (EST) Subject: [keycloak-dev] #Keycloak on freenode In-Reply-To: <1121355487.36608273.1387555956752.JavaMail.root@redhat.com> Message-ID: <563406943.36608455.1387555976278.JavaMail.root@redhat.com> I've started #keycloak on freenode. You're all welcome to join me :) From bburke at redhat.com Fri Dec 20 11:39:50 2013 From: bburke at redhat.com (Bill Burke) Date: Fri, 20 Dec 2013 11:39:50 -0500 Subject: [keycloak-dev] #Keycloak on freenode In-Reply-To: <563406943.36608455.1387555976278.JavaMail.root@redhat.com> References: <563406943.36608455.1387555976278.JavaMail.root@redhat.com> Message-ID: <52B472D6.2000206@redhat.com> I just hope discussions remain on the email list. People need to be able to participate asynchronously especially considering many of us are in different timezones or work weird hours. On 12/20/2013 11:12 AM, Stian Thorgersen wrote: > I've started #keycloak on freenode. > > You're all welcome to join me :) > _______________________________________________ > 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 Dec 20 12:03:59 2013 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 20 Dec 2013 12:03:59 -0500 (EST) Subject: [keycloak-dev] #Keycloak on freenode In-Reply-To: <52B472D6.2000206@redhat.com> References: <563406943.36608455.1387555976278.JavaMail.root@redhat.com> <52B472D6.2000206@redhat.com> Message-ID: <1814134766.36704713.1387559039745.JavaMail.root@redhat.com> I agree that people not present in #keycloak at a time of a discussion should be included. That doesn't mean we can't have discussions on #keycloak though. Instead a discussion should be summarized and sent to the mailing list if appropriate. ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Friday, 20 December, 2013 4:39:50 PM > Subject: Re: [keycloak-dev] #Keycloak on freenode > > I just hope discussions remain on the email list. People need to be > able to participate asynchronously especially considering many of us are > in different timezones or work weird hours. > > On 12/20/2013 11:12 AM, Stian Thorgersen wrote: > > I've started #keycloak on freenode. > > > > You're all welcome to join me :) > > _______________________________________________ > > 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 Anil.Saldhana at redhat.com Fri Dec 20 15:13:51 2013 From: Anil.Saldhana at redhat.com (Anil Saldhana) Date: Fri, 20 Dec 2013 14:13:51 -0600 Subject: [keycloak-dev] [off-topic] - Keycloak on AeroGear In-Reply-To: <52B451A6.3070609@redhat.com> References: <52B451A6.3070609@redhat.com> Message-ID: <52B4A4FF.9020304@redhat.com> Hi Bill/Bruno, I think this is a great idea. Managing keys/certificates is going to be very critical. EJBCA may be good to CRUD x509 certificates. Regards, Anil On 12/20/2013 08:18 AM, Bill Burke wrote: > Bruno, I'm also interested in your key management work. Client-cert > support is also something on the TODO list. We also need to have a talk > with Aerogear to brainstorm on how to secure/manage devices. I have > some ideas around both the UI and the protocol. Nothing concrete yet. > > On 12/20/2013 7:17 AM, Bruno Oliveira wrote: >> Good morning guys, FYI I?ve started to migrate everything related with ag-security to Keycloak (http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Keycloak-on-AeroGear-td5663.html). I hope to upstream/contribute with our needs during our development. >> >> Congratulations about the project. >> >> -- >> abstractj From Anil.Saldhana at redhat.com Fri Dec 20 15:23:10 2013 From: Anil.Saldhana at redhat.com (Anil Saldhana) Date: Fri, 20 Dec 2013 14:23:10 -0600 Subject: [keycloak-dev] Certificate Management, Directory Services and Device Registration In-Reply-To: <52B4A4FF.9020304@redhat.com> References: <52B451A6.3070609@redhat.com> <52B4A4FF.9020304@redhat.com> Message-ID: <52B4A72E.3060703@redhat.com> Bill brought out some thoughts in my mind which I want to capture here to see what your thoughts are: * Certificate Management - We need a good system to CRUD certificates. The only good Java based oss I have seen is EJBCA. * Directory Server/Services - We have ApacheDS and OpenDS (or the ForgeRock version) as two possibilities in Java based directory servers. I am unsure if we have really explored building a solution for directory services. * Device Registration - BaaS may be at play here. - Apache UserGrid is incubating. * OTP - FreeOTP is a new project at fedora for iOS/Android apps based on google authenticator. - both KeyCloak and Aerogear have a solution for integrating OTP based authentication. Anything else? On 12/20/2013 02:13 PM, Anil Saldhana wrote: > Hi Bill/Bruno, > I think this is a great idea. Managing keys/certificates is going > to be very critical. > > EJBCA may be good to CRUD x509 certificates. > > Regards, > Anil > > On 12/20/2013 08:18 AM, Bill Burke wrote: >> Bruno, I'm also interested in your key management work. Client-cert >> support is also something on the TODO list. We also need to have a talk >> with Aerogear to brainstorm on how to secure/manage devices. I have >> some ideas around both the UI and the protocol. Nothing concrete yet. >> >> On 12/20/2013 7:17 AM, Bruno Oliveira wrote: >>> Good morning guys, FYI I?ve started to migrate everything related with ag-security to Keycloak (http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Keycloak-on-AeroGear-td5663.html). I hope to upstream/contribute with our needs during our development. >>> >>> Congratulations about the project. >>> >>> -- >>> abstractj > From Anil.Saldhana at redhat.com Fri Dec 20 15:27:16 2013 From: Anil.Saldhana at redhat.com (Anil Saldhana) Date: Fri, 20 Dec 2013 14:27:16 -0600 Subject: [keycloak-dev] Certificate Management, Directory Services and Device Registration In-Reply-To: <52B4A72E.3060703@redhat.com> References: <52B451A6.3070609@redhat.com> <52B4A4FF.9020304@redhat.com> <52B4A72E.3060703@redhat.com> Message-ID: <52B4A824.1010005@redhat.com> Some of this is what I hear from users, customers and the industry. Also see below: On 12/20/2013 02:23 PM, Anil Saldhana wrote: > Bill brought out some thoughts in my mind which I want to capture here > to see what your thoughts are: > > * Certificate Management > - We need a good system to CRUD certificates. The only good Java based > oss I have seen is EJBCA. > > * Directory Server/Services > - We have ApacheDS and OpenDS (or the ForgeRock version) as two > possibilities in Java based directory servers. I am unsure if we have > really explored building a solution for directory services. * Another important consideration is Active Directory. It is an ecosystem - has LDAP, Kerberos/SPNego, SAML, WSTrust etc. I think we really need some type of Open Source solution to this ecosystem. The core starts with directory services or a facade. > * Device Registration > - BaaS may be at play here. > - Apache UserGrid is incubating. > > * OTP > - FreeOTP is a new project at fedora for iOS/Android apps based on > google authenticator. > - both KeyCloak and Aerogear have a solution for integrating OTP based > authentication. > > > Anything else? > > On 12/20/2013 02:13 PM, Anil Saldhana wrote: >> Hi Bill/Bruno, >> I think this is a great idea. Managing keys/certificates is going >> to be very critical. >> >> EJBCA may be good to CRUD x509 certificates. >> >> Regards, >> Anil >> >> On 12/20/2013 08:18 AM, Bill Burke wrote: >>> Bruno, I'm also interested in your key management work. Client-cert >>> support is also something on the TODO list. We also need to have a talk >>> with Aerogear to brainstorm on how to secure/manage devices. I have >>> some ideas around both the UI and the protocol. Nothing concrete yet. >>> >>> On 12/20/2013 7:17 AM, Bruno Oliveira wrote: >>>> Good morning guys, FYI I?ve started to migrate everything related with ag-security to Keycloak (http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Keycloak-on-AeroGear-td5663.html). I hope to upstream/contribute with our needs during our development. >>>> >>>> Congratulations about the project. >>>> >>>> -- >>>> abstractj >> From bburke at redhat.com Fri Dec 20 15:32:42 2013 From: bburke at redhat.com (Bill Burke) Date: Fri, 20 Dec 2013 15:32:42 -0500 Subject: [keycloak-dev] Certificate Management, Directory Services and Device Registration In-Reply-To: <52B4A72E.3060703@redhat.com> References: <52B451A6.3070609@redhat.com> <52B4A4FF.9020304@redhat.com> <52B4A72E.3060703@redhat.com> Message-ID: <52B4A96A.2000701@redhat.com> On 12/20/2013 3:23 PM, Anil Saldhana wrote: > Bill brought out some thoughts in my mind which I want to capture here > to see what your thoughts are: > > * Certificate Management > - We need a good system to CRUD certificates. The only good Java based > oss I have seen is EJBCA. > Becoming a CA is way down the road, but my thoughts were that a realm could just create client-certs signed with the realm's keypair using Bouncycastle APIs. There would be an option to download the truststore for the realm (for Java apps). And a text pkcs format (forget the actual name) for non-Java apps. > * Directory Server/Services > - We have ApacheDS and OpenDS (or the ForgeRock version) as two > possibilities in Java based directory servers. I am unsure if we have > really explored building a solution for directory services. > This is more part of federation no? We need to brainstorm how we want to approach federation. There's some who think the current Picketlink approach won't work and that other security products out there do syncing. Maybe we'll have to do both. I have some architectural ideas around this. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Fri Dec 20 15:42:06 2013 From: bburke at redhat.com (Bill Burke) Date: Fri, 20 Dec 2013 15:42:06 -0500 Subject: [keycloak-dev] Certificate Management, Directory Services and Device Registration In-Reply-To: <52B4A824.1010005@redhat.com> References: <52B451A6.3070609@redhat.com> <52B4A4FF.9020304@redhat.com> <52B4A72E.3060703@redhat.com> <52B4A824.1010005@redhat.com> Message-ID: <52B4AB9E.4080108@redhat.com> On 12/20/2013 3:27 PM, Anil Saldhana wrote: > Some of this is what I hear from users, customers and the industry. Also > see below: > > On 12/20/2013 02:23 PM, Anil Saldhana wrote: >> Bill brought out some thoughts in my mind which I want to capture here >> to see what your thoughts are: >> >> * Certificate Management >> - We need a good system to CRUD certificates. The only good Java based >> oss I have seen is EJBCA. >> >> * Directory Server/Services >> - We have ApacheDS and OpenDS (or the ForgeRock version) as two >> possibilities in Java based directory servers. I am unsure if we have >> really explored building a solution for directory services. > * Another important consideration is Active Directory. It is an > ecosystem - has LDAP, Kerberos/SPNego, SAML, WSTrust etc. I think we > really need some type of Open Source solution to this ecosystem. The > core starts with directory services or a facade. > A huge part of Keycloak's value-add is it provides the UI for login, registration, acct/credential/device/realm management. If these AD/LDAP services are read-only, then there's not a lot Keycloak can offer you. Also, for Keycloak 1.0.Final, we're focusing solely on securing Web Apps and RESTful services. We can't have too many tangents or feature creep. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From Anil.Saldhana at redhat.com Fri Dec 20 15:50:18 2013 From: Anil.Saldhana at redhat.com (Anil Saldhana) Date: Fri, 20 Dec 2013 14:50:18 -0600 Subject: [keycloak-dev] Certificate Management, Directory Services and Device Registration In-Reply-To: <52B4A96A.2000701@redhat.com> References: <52B451A6.3070609@redhat.com> <52B4A4FF.9020304@redhat.com> <52B4A72E.3060703@redhat.com> <52B4A96A.2000701@redhat.com> Message-ID: <52B4AD8A.4010704@redhat.com> On 12/20/2013 02:32 PM, Bill Burke wrote: > > On 12/20/2013 3:23 PM, Anil Saldhana wrote: >> Bill brought out some thoughts in my mind which I want to capture here >> to see what your thoughts are: >> >> * Certificate Management >> - We need a good system to CRUD certificates. The only good Java based >> oss I have seen is EJBCA. >> > Becoming a CA is way down the road, but my thoughts were that a realm > could just create client-certs signed with the realm's keypair using > Bouncycastle APIs. There would be an option to download the truststore > for the realm (for Java apps). And a text pkcs format (forget the > actual name) for non-Java apps. Good idea. But having a CA that helps users manage their certificates within a particular corporate domain, may be important for an integrated solution. CRUD/export-import truststores/keystores. > > >> * Directory Server/Services >> - We have ApacheDS and OpenDS (or the ForgeRock version) as two >> possibilities in Java based directory servers. I am unsure if we have >> really explored building a solution for directory services. >> > This is more part of federation no? We need to brainstorm how we want > to approach federation. There's some who think the current Picketlink > approach won't work and that other security products out there do > syncing. Maybe we'll have to do both. I have some architectural ideas > around this. Great. I am glad you are thinking along these lines. I will be looking out for your architectural ideas. Like the other reply I sent, what is really missing in the OSS world, is an integrated platform such as the Active Directory ecosystem. To summarize, it makes sense to have an integrated, administered solution that is hopefully written in Java (no OS/Native issues) that helps the modern enterprise that deal with REST/Mobile client usecases. From Anil.Saldhana at redhat.com Fri Dec 20 15:52:00 2013 From: Anil.Saldhana at redhat.com (Anil Saldhana) Date: Fri, 20 Dec 2013 14:52:00 -0600 Subject: [keycloak-dev] Certificate Management, Directory Services and Device Registration In-Reply-To: <52B4AB9E.4080108@redhat.com> References: <52B451A6.3070609@redhat.com> <52B4A4FF.9020304@redhat.com> <52B4A72E.3060703@redhat.com> <52B4A824.1010005@redhat.com> <52B4AB9E.4080108@redhat.com> Message-ID: <52B4ADF0.7040703@redhat.com> On 12/20/2013 02:42 PM, Bill Burke wrote: > > On 12/20/2013 3:27 PM, Anil Saldhana wrote: >> Some of this is what I hear from users, customers and the industry. Also >> see below: >> >> On 12/20/2013 02:23 PM, Anil Saldhana wrote: >>> Bill brought out some thoughts in my mind which I want to capture here >>> to see what your thoughts are: >>> >>> * Certificate Management >>> - We need a good system to CRUD certificates. The only good Java based >>> oss I have seen is EJBCA. >>> >>> * Directory Server/Services >>> - We have ApacheDS and OpenDS (or the ForgeRock version) as two >>> possibilities in Java based directory servers. I am unsure if we have >>> really explored building a solution for directory services. >> * Another important consideration is Active Directory. It is an >> ecosystem - has LDAP, Kerberos/SPNego, SAML, WSTrust etc. I think we >> really need some type of Open Source solution to this ecosystem. The >> core starts with directory services or a facade. >> > A huge part of Keycloak's value-add is it provides the UI for login, > registration, acct/credential/device/realm management. If these AD/LDAP > services are read-only, then there's not a lot Keycloak can offer you. Rather than viewing them as read-only services, I view them as directory services that your ecosystem of apps (internal as well as external) ranging from browsers to mobile can utilize. > Also, for Keycloak 1.0.Final, we're focusing solely on securing Web Apps > and RESTful services. We can't have too many tangents or feature creep. > Agreed - long term thinking. From bburke at redhat.com Fri Dec 20 16:05:12 2013 From: bburke at redhat.com (Bill Burke) Date: Fri, 20 Dec 2013 16:05:12 -0500 Subject: [keycloak-dev] Certificate Management, Directory Services and Device Registration In-Reply-To: <52B4AD8A.4010704@redhat.com> References: <52B451A6.3070609@redhat.com> <52B4A4FF.9020304@redhat.com> <52B4A72E.3060703@redhat.com> <52B4A96A.2000701@redhat.com> <52B4AD8A.4010704@redhat.com> Message-ID: <52B4B108.6000007@redhat.com> On 12/20/2013 3:50 PM, Anil Saldhana wrote: > On 12/20/2013 02:32 PM, Bill Burke wrote: >> >> On 12/20/2013 3:23 PM, Anil Saldhana wrote: >>> Bill brought out some thoughts in my mind which I want to capture here >>> to see what your thoughts are: >>> >>> * Certificate Management >>> - We need a good system to CRUD certificates. The only good Java based >>> oss I have seen is EJBCA. >>> >> Becoming a CA is way down the road, but my thoughts were that a realm >> could just create client-certs signed with the realm's keypair using >> Bouncycastle APIs. There would be an option to download the truststore >> for the realm (for Java apps). And a text pkcs format (forget the >> actual name) for non-Java apps. > Good idea. But having a CA that helps users manage their certificates > within a particular corporate domain, may be important for an integrated > solution. > CRUD/export-import truststores/keystores. > Short term. Yes, I want to be able to manage user certificates. This is something Bruno/Aerogear is really interested in too. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Mon Dec 23 04:21:56 2013 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 23 Dec 2013 04:21:56 -0500 (EST) Subject: [keycloak-dev] Certificate Management, Directory Services and Device Registration In-Reply-To: <52B4AB9E.4080108@redhat.com> References: <52B451A6.3070609@redhat.com> <52B4A4FF.9020304@redhat.com> <52B4A72E.3060703@redhat.com> <52B4A824.1010005@redhat.com> <52B4AB9E.4080108@redhat.com> Message-ID: <1641766950.37813169.1387790516491.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Friday, 20 December, 2013 8:42:06 PM > Subject: Re: [keycloak-dev] Certificate Management, Directory Services and Device Registration > > > > On 12/20/2013 3:27 PM, Anil Saldhana wrote: > > Some of this is what I hear from users, customers and the industry. Also > > see below: > > > > On 12/20/2013 02:23 PM, Anil Saldhana wrote: > >> Bill brought out some thoughts in my mind which I want to capture here > >> to see what your thoughts are: > >> > >> * Certificate Management > >> - We need a good system to CRUD certificates. The only good Java based > >> oss I have seen is EJBCA. EJBCA is a no-go as it's looks like it's heavily dependent on JavaEE. For LiveOak we need whatever libraries we use to be non-JavaEE. > >> > >> * Directory Server/Services > >> - We have ApacheDS and OpenDS (or the ForgeRock version) as two > >> possibilities in Java based directory servers. I am unsure if we have > >> really explored building a solution for directory services. > > * Another important consideration is Active Directory. It is an > > ecosystem - has LDAP, Kerberos/SPNego, SAML, WSTrust etc. I think we > > really need some type of Open Source solution to this ecosystem. The > > core starts with directory services or a facade. > > > > A huge part of Keycloak's value-add is it provides the UI for login, > registration, acct/credential/device/realm management. If these AD/LDAP > services are read-only, then there's not a lot Keycloak can offer you. > > Also, for Keycloak 1.0.Final, we're focusing solely on securing Web Apps > and RESTful services. We can't have too many tangents or feature creep. We can't wait to long to support mobile devices (at least Android and iOS). These would be required by both LiveOak and AeroGear. Not sure if that's before or after a 1.0.Final though. AeroGear guys can probably help us out here though, as they're working on OAuth2 libraries. > > -- > 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 Anil.Saldhana at redhat.com Mon Dec 23 11:11:25 2013 From: Anil.Saldhana at redhat.com (Anil Saldhana) Date: Mon, 23 Dec 2013 10:11:25 -0600 Subject: [keycloak-dev] Certificate Management, Directory Services and Device Registration In-Reply-To: <1641766950.37813169.1387790516491.JavaMail.root@redhat.com> References: <52B451A6.3070609@redhat.com> <52B4A4FF.9020304@redhat.com> <52B4A72E.3060703@redhat.com> <52B4A824.1010005@redhat.com> <52B4AB9E.4080108@redhat.com> <1641766950.37813169.1387790516491.JavaMail.root@redhat.com> Message-ID: <52B860AD.4060906@redhat.com> On 12/23/2013 03:21 AM, Stian Thorgersen wrote: > ----- Original Message ----- >> >From: "Bill Burke" >> >To:keycloak-dev at lists.jboss.org >> >Sent: Friday, 20 December, 2013 8:42:06 PM >> >Subject: Re: [keycloak-dev] Certificate Management, Directory Services and Device Registration >> > >> > >> > >> >On 12/20/2013 3:27 PM, Anil Saldhana wrote: >>> > >Some of this is what I hear from users, customers and the industry. Also >>> > >see below: >>> > > >>> > >On 12/20/2013 02:23 PM, Anil Saldhana wrote: >>>> > >>Bill brought out some thoughts in my mind which I want to capture here >>>> > >>to see what your thoughts are: >>>> > >> >>>> > >>* Certificate Management >>>> > >>- We need a good system to CRUD certificates. The only good Java based >>>> > >>oss I have seen is EJBCA. > EJBCA is a no-go as it's looks like it's heavily dependent on JavaEE. For LiveOak we need whatever libraries we use to be non-JavaEE. Stian - let me take a guess here. You think maybe writing a thin REST based system for certificate management is better? EJBCA is an old project. I guess they started out as EJB based services. > >>>> > >> >>>> > >>* Directory Server/Services >>>> > >>- We have ApacheDS and OpenDS (or the ForgeRock version) as two >>>> > >>possibilities in Java based directory servers. I am unsure if we have >>>> > >>really explored building a solution for directory services. >>> > >* Another important consideration is Active Directory. It is an >>> > >ecosystem - has LDAP, Kerberos/SPNego, SAML, WSTrust etc. I think we >>> > >really need some type of Open Source solution to this ecosystem. The >>> > >core starts with directory services or a facade. >>> > > >> > >> >A huge part of Keycloak's value-add is it provides the UI for login, >> >registration, acct/credential/device/realm management. If these AD/LDAP >> >services are read-only, then there's not a lot Keycloak can offer you. >> > >> >Also, for Keycloak 1.0.Final, we're focusing solely on securing Web Apps >> >and RESTful services. We can't have too many tangents or feature creep. > We can't wait to long to support mobile devices (at least Android and iOS). These would be required by both LiveOak and AeroGear. Not sure if that's before or after a 1.0.Final though. AeroGear guys can probably help us out here though, as they're working on OAuth2 libraries. Agree. Having REST based MBaaS dealing with mobile devices may be critical. Apache UserGrid is the new entrant in the oss space. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20131223/3b9e6aa5/attachment-0001.html