From mposolda at redhat.com Mon May 4 14:18:00 2015 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 04 May 2015 20:18:00 +0200 Subject: [keycloak-dev] Issue with SAML backchannel logout and JPA userSessions Message-ID: <5547B7D8.8030004@redhat.com> Bill, I've created https://issues.jboss.org/browse/KEYCLOAK-1260 . It was causing tests failures with -Pjpa so I've temporarily disabled backchannelSupport for SAML broker test as a workaround. I guess it's not a blocker for CR1 release as it happens just with JPA UserSessions and with SAML backchannel logout. Just wanted to let you know. Marek From bburke at redhat.com Mon May 4 14:23:48 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 04 May 2015 14:23:48 -0400 Subject: [keycloak-dev] Issue with SAML backchannel logout and JPA userSessions In-Reply-To: <5547B7D8.8030004@redhat.com> References: <5547B7D8.8030004@redhat.com> Message-ID: <5547B934.5020005@redhat.com> I don't think you should be disabling tests. If it is failing then it should be fixed. On 5/4/2015 2:18 PM, Marek Posolda wrote: > Bill, > > I've created https://issues.jboss.org/browse/KEYCLOAK-1260 . It was > causing tests failures with -Pjpa so I've temporarily disabled > backchannelSupport for SAML broker test as a workaround. > > I guess it's not a blocker for CR1 release as it happens just with JPA > UserSessions and with SAML backchannel logout. Just wanted to let you know. > > 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 mposolda at redhat.com Mon May 4 14:29:53 2015 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 04 May 2015 20:29:53 +0200 Subject: [keycloak-dev] Issue with SAML backchannel logout and JPA userSessions In-Reply-To: <5547B934.5020005@redhat.com> References: <5547B7D8.8030004@redhat.com> <5547B934.5020005@redhat.com> Message-ID: <5547BAA1.9020009@redhat.com> I did not disable the whole test, just this config switch: https://github.com/keycloak/keycloak/blob/master/testsuite/integration/src/test/resources/broker-test/test-realm-with-broker.json#L124 More info in JIRA. If you don't have time, I can look at it tomorrow or just postpone to next release. But at this moment, I am not sure what the proper solution should be. Marek On 4.5.2015 20:23, Bill Burke wrote: > I don't think you should be disabling tests. If it is failing then it > should be fixed. > > On 5/4/2015 2:18 PM, Marek Posolda wrote: >> Bill, >> >> I've created https://issues.jboss.org/browse/KEYCLOAK-1260 . It was >> causing tests failures with -Pjpa so I've temporarily disabled >> backchannelSupport for SAML broker test as a workaround. >> >> I guess it's not a blocker for CR1 release as it happens just with JPA >> UserSessions and with SAML backchannel logout. Just wanted to let you know. >> >> Marek >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From leonardo.zanivan at gmail.com Mon May 4 14:42:49 2015 From: leonardo.zanivan at gmail.com (Leonardo Loch Zanivan) Date: Mon, 04 May 2015 18:42:49 +0000 Subject: [keycloak-dev] Bearer token size Message-ID: Hi, I have a big problem here because of bearer token size. I'm using keycloak within a SaaS application, so I need create alot of realms. After 30 realms created, the bearer token issued for master admin user has more than 8kb. It's huge for a single header, Apache limits 8kb headers by default. With 1000 realms, the bearer token of master admin user will have 3.5mb. It'll be impossible to use keycloak in production, it occurs because "resource_access" property has all realms with all possible roles. It's possible to create wildcard "*" for "resource_access" to prevent that problem? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150504/28a6aeb9/attachment.html From bburke at redhat.com Mon May 4 14:59:35 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 04 May 2015 14:59:35 -0400 Subject: [keycloak-dev] Bearer token size In-Reply-To: References: Message-ID: <5547C197.2070702@redhat.com> Log a JIRA. We don't have a workaround for this. On 5/4/2015 2:42 PM, Leonardo Loch Zanivan wrote: > Hi, > > I have a big problem here because of bearer token size. > > I'm using keycloak within a SaaS application, so I need create alot of > realms. > > After 30 realms created, the bearer token issued for master admin user > has more than 8kb. > It's huge for a single header, Apache limits 8kb headers by default. > With 1000 realms, the bearer token of master admin user will have 3.5mb. > It'll be impossible to use keycloak in production, it occurs because > "resource_access" property has all realms with all possible roles. > > It's possible to create wildcard "*" for "resource_access" to prevent > that problem? > > > _______________________________________________ > 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 Tue May 5 05:57:19 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 5 May 2015 05:57:19 -0400 (EDT) Subject: [keycloak-dev] Master ready for 1.3 Message-ID: <270478067.12967289.1430819839758.JavaMail.zimbra@redhat.com> GitHub repo is ready to receive new stuff for 1.3 From stian at redhat.com Tue May 5 06:03:18 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 5 May 2015 06:03:18 -0400 (EDT) Subject: [keycloak-dev] Release ready, but Nexus down Message-ID: <1578456637.12969644.1430820198468.JavaMail.zimbra@redhat.com> 1.2.0.CR1 release is ready to go, but Nexus is down, so will have to wait until it's back up to release :( From stian at redhat.com Tue May 5 06:21:20 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 5 May 2015 06:21:20 -0400 (EDT) Subject: [keycloak-dev] Keycloak 1.2.0.CR1 Released Message-ID: <1424346669.12975071.1430821280430.JavaMail.zimbra@redhat.com> See http://blog.keycloak.org/2015/05/keycloak-120cr1-released.html for details From leonardo.zanivan at gmail.com Tue May 5 08:31:05 2015 From: leonardo.zanivan at gmail.com (Leonardo Loch Zanivan) Date: Tue, 05 May 2015 12:31:05 +0000 Subject: [keycloak-dev] Bearer token size In-Reply-To: <5547C197.2070702@redhat.com> References: <5547C197.2070702@redhat.com> Message-ID: https://issues.jboss.org/browse/KEYCLOAK-1268 On Mon, May 4, 2015 at 3:59 PM Bill Burke wrote: > Log a JIRA. We don't have a workaround for this. > > On 5/4/2015 2:42 PM, Leonardo Loch Zanivan wrote: > > Hi, > > > > I have a big problem here because of bearer token size. > > > > I'm using keycloak within a SaaS application, so I need create alot of > > realms. > > > > After 30 realms created, the bearer token issued for master admin user > > has more than 8kb. > > It's huge for a single header, Apache limits 8kb headers by default. > > With 1000 realms, the bearer token of master admin user will have 3.5mb. > > It'll be impossible to use keycloak in production, it occurs because > > "resource_access" property has all realms with all possible roles. > > > > It's possible to create wildcard "*" for "resource_access" to prevent > > that problem? > > > > > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150505/e85199cc/attachment-0001.html From bburke at redhat.com Tue May 5 09:39:23 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 05 May 2015 09:39:23 -0400 Subject: [keycloak-dev] branching plan? Message-ID: <5548C80B.1060004@redhat.com> Is 1.2 being branched? What is the plan? I don't think any of us are doing anything major prior to May 11th. Just do 1.2.Final in master? -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Tue May 5 09:57:27 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 5 May 2015 09:57:27 -0400 (EDT) Subject: [keycloak-dev] branching plan? In-Reply-To: <5548C80B.1060004@redhat.com> References: <5548C80B.1060004@redhat.com> Message-ID: <233740155.13222641.1430834247914.JavaMail.zimbra@redhat.com> Let's do a branch so master is free for dev. I want to merge admin audit events soon. ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Tuesday, May 5, 2015 3:39:23 PM > Subject: [keycloak-dev] branching plan? > > Is 1.2 being branched? What is the plan? I don't think any of us are > doing anything major prior to May 11th. Just do 1.2.Final in master? > -- > 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 Tue May 5 10:03:17 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 5 May 2015 10:03:17 -0400 (EDT) Subject: [keycloak-dev] branching plan? In-Reply-To: <233740155.13222641.1430834247914.JavaMail.zimbra@redhat.com> References: <5548C80B.1060004@redhat.com> <233740155.13222641.1430834247914.JavaMail.zimbra@redhat.com> Message-ID: <974639560.13279907.1430834597089.JavaMail.zimbra@redhat.com> Added 1.2.0 branch ----- Original Message ----- > From: "Stian Thorgersen" > To: "Bill Burke" > Cc: keycloak-dev at lists.jboss.org > Sent: Tuesday, May 5, 2015 3:57:27 PM > Subject: Re: [keycloak-dev] branching plan? > > Let's do a branch so master is free for dev. I want to merge admin audit > events soon. > > ----- Original Message ----- > > From: "Bill Burke" > > To: keycloak-dev at lists.jboss.org > > Sent: Tuesday, May 5, 2015 3:39:23 PM > > Subject: [keycloak-dev] branching plan? > > > > Is 1.2 being branched? What is the plan? I don't think any of us are > > doing anything major prior to May 11th. Just do 1.2.Final in master? > > -- > > 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 srossillo at smartling.com Tue May 5 11:12:26 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Tue, 5 May 2015 11:12:26 -0400 Subject: [keycloak-dev] branching plan? In-Reply-To: <974639560.13279907.1430834597089.JavaMail.zimbra@redhat.com> References: <5548C80B.1060004@redhat.com> <233740155.13222641.1430834247914.JavaMail.zimbra@redhat.com> <974639560.13279907.1430834597089.JavaMail.zimbra@redhat.com> Message-ID: <21DB08A7-D760-43E9-9E13-FFE5F44E8B8C@smartling.com> I try to get a few more PRs your way this week to polish up the Spring Security adapter and add documentation. ~ Scott > On May 5, 2015, at 10:03 AM, Stian Thorgersen wrote: > > Added 1.2.0 branch > > ----- Original Message ----- >> From: "Stian Thorgersen" >> To: "Bill Burke" >> Cc: keycloak-dev at lists.jboss.org >> Sent: Tuesday, May 5, 2015 3:57:27 PM >> Subject: Re: [keycloak-dev] branching plan? >> >> Let's do a branch so master is free for dev. I want to merge admin audit >> events soon. >> >> ----- Original Message ----- >>> From: "Bill Burke" >>> To: keycloak-dev at lists.jboss.org >>> Sent: Tuesday, May 5, 2015 3:39:23 PM >>> Subject: [keycloak-dev] branching plan? >>> >>> Is 1.2 being branched? What is the plan? I don't think any of us are >>> doing anything major prior to May 11th. Just do 1.2.Final in master? >>> -- >>> 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 Tue May 5 12:32:24 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 05 May 2015 12:32:24 -0400 Subject: [keycloak-dev] OOTB session-jpa not viable? Message-ID: <5548F098.8070208@redhat.com> In tracking down a bug I found that in certain cases the database (H2?) that comes with Wildfly will perform table-level locks. It definitely does a table lock in transactions that require inserts. Not sure if it happens on regular row updates. Makes me feel like we have been really lucky altogether that we haven't run into problems so far. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From mposolda at redhat.com Tue May 5 13:31:43 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 05 May 2015 19:31:43 +0200 Subject: [keycloak-dev] OOTB session-jpa not viable? In-Reply-To: <5548F098.8070208@redhat.com> References: <5548F098.8070208@redhat.com> Message-ID: <5548FE7F.9070305@redhat.com> Unfortunately the test is failing on all RDBMS, not just H2 :-( I did debugging with MySQL yesterday and saw that UserSessionEntity was successfully deleted in chained backchannel logout request, but transaction in original request failed due to foreign key (UserSessionNote couldn't be added to already deleted UserSession) As mentioned in private mail, I see this possible solutions: 1) When parent broker receives logout request from child broker, the parent shouldn't send another backchannel logout request to the same child broker again. 2) Add the flag to UserSession before it sends backchannel logout request to parent broker. When parent broker sends logout request back to the child, the child broker will see the flag on UserSession and it won't try to remove it. It looks that (2) is better as it will work with 3rd party parent brokers as well. Basically (1) requires handling the situation on parent broker, but with 3rd party parent brokers, we don't have control if they implement this. Marek On 5.5.2015 18:32, Bill Burke wrote: > In tracking down a bug I found that in certain cases the database (H2?) > that comes with Wildfly will perform table-level locks. It definitely > does a table lock in transactions that require inserts. Not sure if it > happens on regular row updates. > > Makes me feel like we have been really lucky altogether that we haven't > run into problems so far. From leonardo.zanivan at gmail.com Tue May 5 13:38:33 2015 From: leonardo.zanivan at gmail.com (Leonardo Loch Zanivan) Date: Tue, 05 May 2015 17:38:33 +0000 Subject: [keycloak-dev] OOTB session-jpa not viable? In-Reply-To: <5548FE7F.9070305@redhat.com> References: <5548F098.8070208@redhat.com> <5548FE7F.9070305@redhat.com> Message-ID: It's a common behavior for tables without primary keys. The database lock all table on insert/update/delete. I looked in my postgresql keycloak database and found alot of tables without PK: composite_role, databasechangelog, fed_providers, realm_application, realm_default_roles Please add PK in all tables, in relationship tables manytomany add a composite PK (embedded id). On Tue, May 5, 2015 at 2:31 PM Marek Posolda wrote: > Unfortunately the test is failing on all RDBMS, not just H2 :-( > > I did debugging with MySQL yesterday and saw that UserSessionEntity was > successfully deleted in chained backchannel logout request, but > transaction in original request failed due to foreign key > (UserSessionNote couldn't be added to already deleted UserSession) > > As mentioned in private mail, I see this possible solutions: > > 1) When parent broker receives logout request from child broker, the > parent shouldn't send another backchannel logout request to the same > child broker again. > > 2) Add the flag to UserSession before it sends backchannel logout > request to parent broker. When parent broker sends logout request back > to the child, the child broker will see the flag on UserSession and it > won't try to remove it. > > It looks that (2) is better as it will work with 3rd party parent > brokers as well. Basically (1) requires handling the situation on parent > broker, but with 3rd party parent brokers, we don't have control if they > implement this. > > Marek > > On 5.5.2015 18:32, Bill Burke wrote: > > In tracking down a bug I found that in certain cases the database (H2?) > > that comes with Wildfly will perform table-level locks. It definitely > > does a table lock in transactions that require inserts. Not sure if it > > happens on regular row updates. > > > > Makes me feel like we have been really lucky altogether that we haven't > > run into problems so far. > > _______________________________________________ > 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/20150505/bb01f57e/attachment.html From bburke at redhat.com Tue May 5 13:48:51 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 05 May 2015 13:48:51 -0400 Subject: [keycloak-dev] OOTB session-jpa not viable? In-Reply-To: <5548FE7F.9070305@redhat.com> References: <5548F098.8070208@redhat.com> <5548FE7F.9070305@redhat.com> Message-ID: <55490283.6040409@redhat.com> On 5/5/2015 1:31 PM, Marek Posolda wrote: > Unfortunately the test is failing on all RDBMS, not just H2 :-( > > I did debugging with MySQL yesterday and saw that UserSessionEntity was > successfully deleted in chained backchannel logout request, but > transaction in original request failed due to foreign key > (UserSessionNote couldn't be added to already deleted UserSession) > I have fixed this problem in my local repo. For OIDC I was checking the state of the UserSession to see if it was in a LOGGING_OUT state. If it was, I wouldn't delete the user session. I forgot to do this for SAML... Unfortunately, once I fixed this problem I ran into table locks: 1. Application initiates logout 2. Keycloak receives app request, adds a UserSession note (this locks the UserSessionEntity table) 3. In same request, keycloak invokes a backchannel broker logout. Note, this request has not committed the current KeycloakSession and the UserSEssionEntity table is still locked 4. Keycloak receives the broker backchannel logout request. Tries to delete the broker's UserSession which tries to delete all UserSessionNotes. UserSessionEntity table is already locked...BANG! Deadlock! fail! Table locks scare the shit out of me. They are a nightmare to fix and often can't be fixed without massive rearchitecture. In this situation though I believe I can fix the problem by committing the transaction in Step #3 before invoking the backchannel broker logout request. Then, restarting the session thereafter. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From leonardo.zanivan at gmail.com Tue May 5 14:22:46 2015 From: leonardo.zanivan at gmail.com (Leonardo Loch Zanivan) Date: Tue, 05 May 2015 18:22:46 +0000 Subject: [keycloak-dev] OOTB session-jpa not viable? In-Reply-To: <55490283.6040409@redhat.com> References: <5548F098.8070208@redhat.com> <5548FE7F.9070305@redhat.com> <55490283.6040409@redhat.com> Message-ID: Another common source of table locks are delete operations in tables with foreign keys without index. On Tue, May 5, 2015 at 2:49 PM Bill Burke wrote: > > > On 5/5/2015 1:31 PM, Marek Posolda wrote: > > Unfortunately the test is failing on all RDBMS, not just H2 :-( > > > > I did debugging with MySQL yesterday and saw that UserSessionEntity was > > successfully deleted in chained backchannel logout request, but > > transaction in original request failed due to foreign key > > (UserSessionNote couldn't be added to already deleted UserSession) > > > > I have fixed this problem in my local repo. For OIDC I was checking the > state of the UserSession to see if it was in a LOGGING_OUT state. If it > was, I wouldn't delete the user session. I forgot to do this for SAML... > > Unfortunately, once I fixed this problem I ran into table locks: > > 1. Application initiates logout > 2. Keycloak receives app request, adds a UserSession note (this locks > the UserSessionEntity table) > 3. In same request, keycloak invokes a backchannel broker logout. Note, > this request has not committed the current KeycloakSession and the > UserSEssionEntity table is still locked > 4. Keycloak receives the broker backchannel logout request. Tries to > delete the broker's UserSession which tries to delete all > UserSessionNotes. UserSessionEntity table is already locked...BANG! > Deadlock! fail! > > Table locks scare the shit out of me. They are a nightmare to fix and > often can't be fixed without massive rearchitecture. > > In this situation though I believe I can fix the problem by committing > the transaction in Step #3 before invoking the backchannel broker logout > request. Then, restarting the session thereafter. > > > -- > 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/20150505/78cb464a/attachment-0001.html From mposolda at redhat.com Tue May 5 14:29:46 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 05 May 2015 20:29:46 +0200 Subject: [keycloak-dev] OOTB session-jpa not viable? In-Reply-To: <55490283.6040409@redhat.com> References: <5548F098.8070208@redhat.com> <5548FE7F.9070305@redhat.com> <55490283.6040409@redhat.com> Message-ID: <55490C1A.1000204@redhat.com> On 5.5.2015 19:48, Bill Burke wrote: > > > On 5/5/2015 1:31 PM, Marek Posolda wrote: >> Unfortunately the test is failing on all RDBMS, not just H2 :-( >> >> I did debugging with MySQL yesterday and saw that UserSessionEntity was >> successfully deleted in chained backchannel logout request, but >> transaction in original request failed due to foreign key >> (UserSessionNote couldn't be added to already deleted UserSession) >> > > I have fixed this problem in my local repo. For OIDC I was checking > the state of the UserSession to see if it was in a LOGGING_OUT state. > If it was, I wouldn't delete the user session. I forgot to do this > for SAML... > > Unfortunately, once I fixed this problem I ran into table locks: > > 1. Application initiates logout > 2. Keycloak receives app request, adds a UserSession note (this locks > the UserSessionEntity table) > 3. In same request, keycloak invokes a backchannel broker logout. > Note, this request has not committed the current KeycloakSession and > the UserSEssionEntity table is still locked > 4. Keycloak receives the broker backchannel logout request. Tries to > delete the broker's UserSession which tries to delete all > UserSessionNotes. UserSessionEntity table is already locked...BANG! > Deadlock! fail! > > Table locks scare the shit out of me. They are a nightmare to fix and > often can't be fixed without massive rearchitecture. > > In this situation though I believe I can fix the problem by committing > the transaction in Step #3 before invoking the backchannel broker > logout request. Then, restarting the session thereafter. > > Looks like a workaround, but hopefully should help to avoid these issues... Still I wonder if it couldn't be handled in step 4 ? When Keycloak receives broker backchannel logout request and it knows that UserSession is already in LOGGING_OUT state, it shouldn't try to delete it? This UserSession will be deleted later in the original logout request from application once it finishes backchannel request. Or maybe I don't understand it properly? Marek From matthew.casperson at autogeneral.com.au Tue May 5 18:59:03 2015 From: matthew.casperson at autogeneral.com.au (Matthew Casperson) Date: Wed, 6 May 2015 08:59:03 +1000 Subject: [keycloak-dev] Problem upgrading from 1.2.0.Beta1 to CR1 Message-ID: I received this error after copying the h2 database from my existing 1.2.0.Beta1 deployment into a fresh copy of CR1. Maybe a bug with the upgrade process? jboss.undertow.deployment.default-server.default-host./auth: Failed to start service at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_65] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_65] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] Caused by: java.lang.RuntimeException: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:160) at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211) at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295) at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236) at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:79) at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:220) at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:125) at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:508) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:88) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] ... 3 more Caused by: org.keycloak.models.ModelException: javax.persistence.PersistenceException: org.hibernate.PropertyAccessException: Null value was assigned to a property of primitive type setter of org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly at org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:44) at org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:34) at com.sun.proxy.$Proxy57.find(Unknown Source) at org.keycloak.models.jpa.JpaRealmProvider.getRealm(JpaRealmProvider.java:63) at org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:163) at org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:40) at org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:31) at org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:160) at org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:85) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_65] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_65] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_65] at java.lang.reflect.Constructor.newInstance(Constructor.java:526) [rt.jar:1.7.0_65] at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148) ... 18 more Caused by: javax.persistence.PersistenceException: org.hibernate.PropertyAccessException: Null value was assigned to a property of primitive type setter of org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763) at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1694) at org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1141) at org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1068) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_65] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_65] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_65] at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65] at org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:32) ... 30 more Caused by: org.hibernate.PropertyAccessException: Null value was assigned to a property of primitive type setter of org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly at org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:126) at org.hibernate.tuple.entity.AbstractEntityTuplizer.setPropertyValues(AbstractEntityTuplizer.java:713) at org.hibernate.tuple.entity.PojoEntityTuplizer.setPropertyValues(PojoEntityTuplizer.java:362) at org.hibernate.persister.entity.AbstractEntityPersister.setPropertyValues(AbstractEntityPersister.java:4718) at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:188) at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:144) at org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.performTwoPhaseLoad(AbstractRowReader.java:244) at org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.finishUp(AbstractRowReader.java:215) at org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:140) at org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:138) at org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:102) at org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:186) at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:4126) at org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:503) at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:468) at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:213) at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:275) at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:151) at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1070) at org.hibernate.internal.SessionImpl.access$2000(SessionImpl.java:176) at org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2551) at org.hibernate.internal.SessionImpl.get(SessionImpl.java:955) at org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1110) ... 36 more Caused by: java.lang.IllegalArgumentException: Can not set boolean field org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly to null value at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164) [rt.jar:1.7.0_65] at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168) [rt.jar:1.7.0_65] at sun.reflect.UnsafeBooleanFieldAccessorImpl.set(UnsafeBooleanFieldAccessorImpl.java:80) [rt.jar:1.7.0_65] at java.lang.reflect.Field.set(Field.java:741) [rt.jar:1.7.0_65] at org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:122) ... 58 more -- *Matthew Casperson* *Senior Front End Developer* Technology, Space & Distribution Auto & General Holdings Pty Ltd P: 07) 3377 8751 (Direct: 3377 8751) F: 07) 3377 8833 -- This email is sent by Auto & General Insurance Company Ltd, Auto & General Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body corporate (Auto & General) and is for the intended addressee. The views expressed in this email and attachments (email) reflect the views of the stated author but may not reflect views of Auto & General. This email is confidential and subject to copyright. It may be privileged. If you are not the intended addressee, confidentiality and privilege have not been waived and any use, interference with, or disclosure of this email is unauthorised. If you are not the intended addressee please immediately notify the sender and then delete the email. Auto & General does not warrant that this email is error or virus free. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150506/78b4c759/attachment.html From bburke at redhat.com Tue May 5 19:20:50 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 05 May 2015 19:20:50 -0400 Subject: [keycloak-dev] OOTB session-jpa not viable? In-Reply-To: <55490C1A.1000204@redhat.com> References: <5548F098.8070208@redhat.com> <5548FE7F.9070305@redhat.com> <55490283.6040409@redhat.com> <55490C1A.1000204@redhat.com> Message-ID: <55495052.90103@redhat.com> On 5/5/2015 2:29 PM, Marek Posolda wrote: > On 5.5.2015 19:48, Bill Burke wrote: >> >> >> On 5/5/2015 1:31 PM, Marek Posolda wrote: >>> Unfortunately the test is failing on all RDBMS, not just H2 :-( >>> >>> I did debugging with MySQL yesterday and saw that UserSessionEntity was >>> successfully deleted in chained backchannel logout request, but >>> transaction in original request failed due to foreign key >>> (UserSessionNote couldn't be added to already deleted UserSession) >>> >> >> I have fixed this problem in my local repo. For OIDC I was checking >> the state of the UserSession to see if it was in a LOGGING_OUT state. >> If it was, I wouldn't delete the user session. I forgot to do this >> for SAML... >> >> Unfortunately, once I fixed this problem I ran into table locks: >> >> 1. Application initiates logout >> 2. Keycloak receives app request, adds a UserSession note (this locks >> the UserSessionEntity table) >> 3. In same request, keycloak invokes a backchannel broker logout. >> Note, this request has not committed the current KeycloakSession and >> the UserSEssionEntity table is still locked >> 4. Keycloak receives the broker backchannel logout request. Tries to >> delete the broker's UserSession which tries to delete all >> UserSessionNotes. UserSessionEntity table is already locked...BANG! >> Deadlock! fail! >> >> Table locks scare the shit out of me. They are a nightmare to fix and >> often can't be fixed without massive rearchitecture. >> >> In this situation though I believe I can fix the problem by committing >> the transaction in Step #3 before invoking the backchannel broker >> logout request. Then, restarting the session thereafter. >> >> > Looks like a workaround, but hopefully should help to avoid these issues... > > Still I wonder if it couldn't be handled in step 4 ? When Keycloak > receives broker backchannel logout request and it knows that UserSession > is already in LOGGING_OUT state, it shouldn't try to delete it? This > UserSession will be deleted later in the original logout request from > application once it finishes backchannel request. Or maybe I don't > understand it properly? > Again, I fixed that. The problem is that there is a table lock deadlock. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From mposolda at redhat.com Wed May 6 04:18:09 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 06 May 2015 10:18:09 +0200 Subject: [keycloak-dev] Problem upgrading from 1.2.0.Beta1 to CR1 In-Reply-To: References: Message-ID: <5549CE41.9000609@redhat.com> I tested upgrade with MySQL but not seeing any issues. Going to try with H2 as well. By the way, are you using H2 in production? Marek On 6.5.2015 00:59, Matthew Casperson wrote: > I received this error after copying the h2 database from my existing 1.2.0.Beta1 deployment into a fresh copy of CR1. > Maybe a bug with the upgrade process? > jboss.undertow.deployment.default-server.default-host./auth: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_65] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_65] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] > Caused by: java.lang.RuntimeException: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) > at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:160) > at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211) > at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295) > at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236) > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112) > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) > at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) > at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:79) > at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) > at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:220) > at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:125) > at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:508) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:88) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > ... 3 more > Caused by: org.keycloak.models.ModelException: javax.persistence.PersistenceException: org.hibernate.PropertyAccessException: Null value was assigned to a property of primitive type setter of org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly > at org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:44) > at org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:34) > at com.sun.proxy.$Proxy57.find(Unknown Source) > at org.keycloak.models.jpa.JpaRealmProvider.getRealm(JpaRealmProvider.java:63) > at org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:163) > at org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:40) > at org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:31) > at org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:160) > at org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:85) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_65] > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_65] > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_65] > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) [rt.jar:1.7.0_65] > at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148) > ... 18 more > Caused by: javax.persistence.PersistenceException: org.hibernate.PropertyAccessException: Null value was assigned to a property of primitive type setter of org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly > at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763) > at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1694) > at org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1141) > at org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1068) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_65] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_65] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_65] > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65] > at org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:32) > ... 30 more > Caused by: org.hibernate.PropertyAccessException: Null value was assigned to a property of primitive type setter of org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly > at org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:126) > at org.hibernate.tuple.entity.AbstractEntityTuplizer.setPropertyValues(AbstractEntityTuplizer.java:713) > at org.hibernate.tuple.entity.PojoEntityTuplizer.setPropertyValues(PojoEntityTuplizer.java:362) > at org.hibernate.persister.entity.AbstractEntityPersister.setPropertyValues(AbstractEntityPersister.java:4718) > at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:188) > at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:144) > at org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.performTwoPhaseLoad(AbstractRowReader.java:244) > at org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.finishUp(AbstractRowReader.java:215) > at org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:140) > at org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:138) > at org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:102) > at org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:186) > at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:4126) > at org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:503) > at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:468) > at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:213) > at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:275) > at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:151) > at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1070) > at org.hibernate.internal.SessionImpl.access$2000(SessionImpl.java:176) > at org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2551) > at org.hibernate.internal.SessionImpl.get(SessionImpl.java:955) > at org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1110) > ... 36 more > Caused by: java.lang.IllegalArgumentException: Can not set boolean field org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly to null value > at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164) [rt.jar:1.7.0_65] > at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168) [rt.jar:1.7.0_65] > at sun.reflect.UnsafeBooleanFieldAccessorImpl.set(UnsafeBooleanFieldAccessorImpl.java:80) [rt.jar:1.7.0_65] > at java.lang.reflect.Field.set(Field.java:741) [rt.jar:1.7.0_65] > at org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:122) > ... 58 more > > -- > *Matthew Casperson* > *Senior Front End Developer* > Technology, Space & Distribution > Auto & General Holdings Pty Ltd > P: 07) 3377 8751 (Direct: 3377 8751) > F: 07) 3377 8833 > > > > This email is sent by Auto & General Insurance Company Ltd, Auto & General Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body corporate (Auto & General) and is for the intended addressee. > The views expressed in this email and attachments (email) reflect the views of the stated author but may not reflect views of Auto & General. This email is confidential and subject to copyright. > It may be privileged. If you are not the intended addressee, confidentiality and privilege have not been waived and any use, interference with, or disclosure of this email is unauthorised. > If you are not the intended addressee please immediately notify the sender and then delete the email. Auto & General does not warrant that this email is error or virus free. > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150506/acdf9fca/attachment.html From mposolda at redhat.com Wed May 6 04:48:59 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 06 May 2015 10:48:59 +0200 Subject: [keycloak-dev] Problem upgrading from 1.2.0.Beta1 to CR1 In-Reply-To: <5549CE41.9000609@redhat.com> References: <5549CE41.9000609@redhat.com> Message-ID: <5549D57B.9090307@redhat.com> I am not able to reproduce even with H2. The steps I did: - Started keycloak-appliance 1.2.0.Beta1 and import some data to it through keycloak admin console - Stop 1.2.0.Beta1 appliance - Unzip server-dist 1.2.0.CR1 - Copy the database through command similar to: cp $KEYCLOAK_APPLIANCE_HOME_120BETA1/standalone/data/keycloak.*.db $KEYCLOAK_SERVER_DIST_HOME_120CR1/standalone/data/ - Start server-dist of 1.2.0.CR1. Upgrade was fine and I can see all data in keycloak admin console. I wonder what's the difference comparing to your steps and why your DB upgrade doesn't work. The column "DIRECT_GRANTS_ONLY" should be non-null in CLIENT table even in older versions, so not sure why it's null for you... Maybe you can try to manually connect to your H2 database and set the fields "DIRECT_GRANTS_ONLY" on CLIENT table to non-null value manually through SQL. Marek On 6.5.2015 10:18, Marek Posolda wrote: > I tested upgrade with MySQL but not seeing any issues. Going to try > with H2 as well. > > By the way, are you using H2 in production? > > Marek > > On 6.5.2015 00:59, Matthew Casperson wrote: >> I received this error after copying the h2 database from my existing 1.2.0.Beta1 deployment into a fresh copy of CR1. >> Maybe a bug with the upgrade process? >> jboss.undertow.deployment.default-server.default-host./auth: Failed to start service >> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] >> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_65] >> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_65] >> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] >> Caused by: java.lang.RuntimeException: Failed to construct public org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) >> at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:160) >> at org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211) >> at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295) >> at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236) >> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112) >> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) >> at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) >> at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:79) >> at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) >> at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:220) >> at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:125) >> at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:508) >> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:88) >> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72) >> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] >> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final] >> ... 3 more >> Caused by: org.keycloak.models.ModelException: javax.persistence.PersistenceException: org.hibernate.PropertyAccessException: Null value was assigned to a property of primitive type setter of org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly >> at org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:44) >> at org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:34) >> at com.sun.proxy.$Proxy57.find(Unknown Source)admin >> at org.keycloak.models.jpa.JpaRealmProvider.getRealm(JpaRealmProvider.java:63) >> at org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:163) >> at org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:40) >> at org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:31) >> at org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:160) >> at org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:85) >> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_65] >> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_65] >> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_65] >> at java.lang.reflect.Constructor.newInstance(Constructor.java:526) [rt.jar:1.7.0_65] >> at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148) >> ... 18 more >> Caused by: javax.persistence.PersistenceException: org.hibernate.PropertyAccessException: Null value was assigned to a property of primitive type setter of org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly >> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763) >> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1694) >> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1141) >> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1068) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_65] >> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_65] >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_65] >> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65] >> at org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:32) >> ... 30 more >> Caused by: org.hibernate.PropertyAccessException: Null value was assigned to a property of primitive type setter of org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly >> at org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:126) >> at org.hibernate.tuple.entity.AbstractEntityTuplizer.setPropertyValues(AbstractEntityTuplizer.java:713) >> at org.hibernate.tuple.entity.PojoEntityTuplizer.setPropertyValues(PojoEntityTuplizer.java:362) >> at org.hibernate.persister.entity.AbstractEntityPersister.setPropertyValues(AbstractEntityPersister.java:4718) >> at org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:188) >> at org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:144) >> at org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.performTwoPhaseLoad(AbstractRowReader.java:244) >> at org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.finishUp(AbstractRowReader.java:215) >> at org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:140) >> at org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:138) >> at org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:102) >> at org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:186) >> at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:4126) >> at org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:503) >> at org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:468) >> at org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:213) >> at org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:275) >> at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:151) >> at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1070) >> at org.hibernate.internal.SessionImpl.access$2000(SessionImpl.java:176) >> at org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2551) >> at org.hibernate.internal.SessionImpl.get(SessionImpl.java:955) >> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1110) >> ... 36 more >> Caused by: java.lang.IllegalArgumentException: Can not set boolean field org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly to null value >> at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164) [rt.jar:1.7.0_65] >> at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168) [rt.jar:1.7.0_65] >> at sun.reflect.UnsafeBooleanFieldAccessorImpl.set(UnsafeBooleanFieldAccessorImpl.java:80) [rt.jar:1.7.0_65] >> at java.lang.reflect.Field.set(Field.java:741) [rt.jar:1.7.0_65] >> at org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:122) >> ... 58 more >> >> -- >> *Matthew Casperson* >> *Senior Front End Developer* >> Technology, Space & Distribution >> Auto & General Holdings Pty Ltd >> P: 07) 3377 8751 (Direct: 3377 8751) >> F: 07) 3377 8833 >> >> >> >> This email is sent by Auto & General Insurance Company Ltd, Auto & General Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body corporate (Auto & General) and is for the intended addressee. >> The views expressed in this email and attachments (email) reflect the views of the stated author but may not reflect views of Auto & General. This email is confidential and subject to copyright. >> It may be privileged. If you are not the intended addressee, confidentiality and privilege have not been waived and any use, interference with, or disclosure of this email is unauthorised. >> If you are not the intended addressee please immediately notify the sender and then delete the email. Auto & General does not warrant that this email is error or virus free. >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150506/5785da26/attachment-0001.html From stian at redhat.com Wed May 6 07:14:01 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 6 May 2015 07:14:01 -0400 (EDT) Subject: [keycloak-dev] branching plan? In-Reply-To: <21DB08A7-D760-43E9-9E13-FFE5F44E8B8C@smartling.com> References: <5548C80B.1060004@redhat.com> <233740155.13222641.1430834247914.JavaMail.zimbra@redhat.com> <974639560.13279907.1430834597089.JavaMail.zimbra@redhat.com> <21DB08A7-D760-43E9-9E13-FFE5F44E8B8C@smartling.com> Message-ID: <1383477096.13795078.1430910841576.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Scott Rossillo" > To: "Stian Thorgersen" , "Bill Burke" > Cc: "keycloak-dev" > Sent: Tuesday, May 5, 2015 5:12:26 PM > Subject: Re: [keycloak-dev] branching plan? > > I try to get a few more PRs your way this week to polish up the Spring > Security adapter and add documentation. Great, thanks :) > > ~ Scott > > > On May 5, 2015, at 10:03 AM, Stian Thorgersen wrote: > > > > Added 1.2.0 branch > > > > ----- Original Message ----- > >> From: "Stian Thorgersen" > >> To: "Bill Burke" > >> Cc: keycloak-dev at lists.jboss.org > >> Sent: Tuesday, May 5, 2015 3:57:27 PM > >> Subject: Re: [keycloak-dev] branching plan? > >> > >> Let's do a branch so master is free for dev. I want to merge admin audit > >> events soon. > >> > >> ----- Original Message ----- > >>> From: "Bill Burke" > >>> To: keycloak-dev at lists.jboss.org > >>> Sent: Tuesday, May 5, 2015 3:39:23 PM > >>> Subject: [keycloak-dev] branching plan? > >>> > >>> Is 1.2 being branched? What is the plan? I don't think any of us are > >>> doing anything major prior to May 11th. Just do 1.2.Final in master? > >>> -- > >>> Bill Burke > >>> JBoss, a division of Red Hat > >>> http://bill.burkecentral.com > >>> _______________________________________________ > >>> keycloak-dev mailing list > >>> keycloak-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > From stian at redhat.com Wed May 6 07:15:51 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 6 May 2015 07:15:51 -0400 (EDT) Subject: [keycloak-dev] Problem upgrading from 1.2.0.Beta1 to CR1 In-Reply-To: References: Message-ID: <1635854945.13795538.1430910951426.JavaMail.zimbra@redhat.com> What version did you upgrade from? ----- Original Message ----- > From: "Matthew Casperson" > To: keycloak-dev at lists.jboss.org > Sent: Wednesday, May 6, 2015 12:59:03 AM > Subject: [keycloak-dev] Problem upgrading from 1.2.0.Beta1 to CR1 > > I received this error after copying the h2 database from my existing > 1.2.0.Beta1 deployment into a fresh copy of CR1. > Maybe a bug with the upgrade process? > jboss.undertow.deployment.default-server.default-host./auth: Failed to start > service > at > org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > [rt.jar:1.7.0_65] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > [rt.jar:1.7.0_65] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] > Caused by: java.lang.RuntimeException: Failed to construct public > org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) > at > org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:160) > at > org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211) > at > org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295) > at > org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236) > at > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112) > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) > at > io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) > at > org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:79) > at > io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) > at > io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:220) > at > io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:125) > at > io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:508) > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:88) > at > org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72) > at > org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > at > org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > ... 3 more > Caused by: org.keycloak.models.ModelException: > javax.persistence.PersistenceException: > org.hibernate.PropertyAccessException: Null value was assigned to a property > of primitive type setter of > org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly > at > org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:44) > at > org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:34) > at com.sun.proxy.$Proxy57.find(Unknown Source) > at > org.keycloak.models.jpa.JpaRealmProvider.getRealm(JpaRealmProvider.java:63) > at > org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:163) > at > org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:40) > at > org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:31) > at > org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:160) > at > org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:85) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > [rt.jar:1.7.0_65] > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > [rt.jar:1.7.0_65] > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > [rt.jar:1.7.0_65] > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > [rt.jar:1.7.0_65] > at > org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148) > ... 18 more > Caused by: javax.persistence.PersistenceException: > org.hibernate.PropertyAccessException: Null value was assigned to a property > of primitive type setter of > org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly > at > org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763) > at > org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1694) > at > org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1141) > at > org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1068) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [rt.jar:1.7.0_65] > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > [rt.jar:1.7.0_65] > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [rt.jar:1.7.0_65] > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65] > at > org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:32) > ... 30 more > Caused by: org.hibernate.PropertyAccessException: Null value was assigned to > a property of primitive type setter of > org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly > at > org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:126) > at > org.hibernate.tuple.entity.AbstractEntityTuplizer.setPropertyValues(AbstractEntityTuplizer.java:713) > at > org.hibernate.tuple.entity.PojoEntityTuplizer.setPropertyValues(PojoEntityTuplizer.java:362) > at > org.hibernate.persister.entity.AbstractEntityPersister.setPropertyValues(AbstractEntityPersister.java:4718) > at > org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:188) > at > org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:144) > at > org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.performTwoPhaseLoad(AbstractRowReader.java:244) > at > org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.finishUp(AbstractRowReader.java:215) > at > org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:140) > at > org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:138) > at > org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:102) > at > org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:186) > at > org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:4126) > at > org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:503) > at > org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:468) > at > org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:213) > at > org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:275) > at > org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:151) > at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1070) > at org.hibernate.internal.SessionImpl.access$2000(SessionImpl.java:176) > at > org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2551) > at org.hibernate.internal.SessionImpl.get(SessionImpl.java:955) > at > org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1110) > ... 36 more > Caused by: java.lang.IllegalArgumentException: Can not set boolean field > org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly to null value > at > sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164) > [rt.jar:1.7.0_65] > at > sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168) > [rt.jar:1.7.0_65] > at > sun.reflect.UnsafeBooleanFieldAccessorImpl.set(UnsafeBooleanFieldAccessorImpl.java:80) > [rt.jar:1.7.0_65] > at java.lang.reflect.Field.set(Field.java:741) [rt.jar:1.7.0_65] > at > org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:122) > ... 58 more > > -- > Matthew Casperson > Senior Front End Developer > Technology, Space & Distribution > Auto & General Holdings Pty Ltd > P: 07) 3377 8751 (Direct: 3377 8751 ) > F: 07) 3377 8833 > > > > This email is sent by Auto & General Insurance Company Ltd, Auto & General > Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body > corporate (Auto & General) and is for the intended addressee. > The views expressed in this email and attachments (email) reflect the views > of the stated author but may not reflect views of Auto & General. This email > is confidential and subject to copyright. > It may be privileged. If you are not the intended addressee, confidentiality > and privilege have not been waived and any use, interference with, or > disclosure of this email is unauthorised. > If you are not the intended addressee please immediately notify the sender > and then delete the email. Auto & General does not warrant that this email > is error or virus free. > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From lkrzyzan at redhat.com Wed May 6 10:12:06 2015 From: lkrzyzan at redhat.com (=?utf-8?Q?Libor_Krzy=C5=BEanek?=) Date: Wed, 6 May 2015 16:12:06 +0200 Subject: [keycloak-dev] Docs - missing auth-server into standalone.xml Message-ID: <094E4681-95CE-46AC-B3F3-E7AA89370D76@redhat.com> Hi, it seems docs in http://docs.jboss.org/keycloak/docs/1.2.0.CR1/userguide/html/server-installation.html#d4e115 should note about adding 4th element: true auth Thanks, Libor Krzy?anek jboss.org Development Team -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150506/5a67f223/attachment.html From matthew.casperson at autogeneral.com.au Wed May 6 16:51:50 2015 From: matthew.casperson at autogeneral.com.au (Matthew Casperson) Date: Thu, 7 May 2015 06:51:50 +1000 Subject: [keycloak-dev] Problem upgrading from 1.2.0.Beta1 to CR1 In-Reply-To: <1635854945.13795538.1430910951426.JavaMail.zimbra@redhat.com> References: <1635854945.13795538.1430910951426.JavaMail.zimbra@redhat.com> Message-ID: > By the way, are you using H2 in production? We are still developing the platforms that rely on Keycloak. H2 has worked well (we have low traffic with internal users only), but moving to MySQL is something we'll be doing. > What version did you upgrade from? The table was upgraded from 1.0.4 to 1.2.0.Beta1, then the error appeared attempting to upgrade to CR1. >Maybe you can try to manually connect to your H2 database and set the fields "DIRECT_GRANTS_ONLY" on CLIENT table to non-null value manually through SQL. I'll spend some time this week looking at the tables and the offending column to see if I can manually update it and get the upgrade working. On Wed, May 6, 2015 at 9:15 PM, Stian Thorgersen wrote: > What version did you upgrade from? > > ----- Original Message ----- > > From: "Matthew Casperson" > > To: keycloak-dev at lists.jboss.org > > Sent: Wednesday, May 6, 2015 12:59:03 AM > > Subject: [keycloak-dev] Problem upgrading from 1.2.0.Beta1 to CR1 > > > > I received this error after copying the h2 database from my existing > > 1.2.0.Beta1 deployment into a fresh copy of CR1. > > Maybe a bug with the upgrade process? > > jboss.undertow.deployment.default-server.default-host./auth: Failed to > start > > service > > at > > > org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > > [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > > at > > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > > [rt.jar:1.7.0_65] > > at > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > > [rt.jar:1.7.0_65] > > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] > > Caused by: java.lang.RuntimeException: Failed to construct public > > > org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) > > at > > > org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:160) > > at > > > org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211) > > at > > > org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295) > > at > > > org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236) > > at > > > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112) > > at > > > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) > > at > > > io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) > > at > > > org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:79) > > at > > > io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) > > at > > > io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:220) > > at > > > io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:125) > > at > > > io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:508) > > at > > > org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:88) > > at > > > org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72) > > at > > > org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > > [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > > at > > > org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > > [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > > ... 3 more > > Caused by: org.keycloak.models.ModelException: > > javax.persistence.PersistenceException: > > org.hibernate.PropertyAccessException: Null value was assigned to a > property > > of primitive type setter of > > org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly > > at > > > org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:44) > > at > > > org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:34) > > at com.sun.proxy.$Proxy57.find(Unknown Source) > > at > > > org.keycloak.models.jpa.JpaRealmProvider.getRealm(JpaRealmProvider.java:63) > > at > > > org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:163) > > at > > > org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:40) > > at > > > org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:31) > > at > > > org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:160) > > at > > > org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:85) > > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > > [rt.jar:1.7.0_65] > > at > > > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > > [rt.jar:1.7.0_65] > > at > > > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > > [rt.jar:1.7.0_65] > > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > > [rt.jar:1.7.0_65] > > at > > > org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148) > > ... 18 more > > Caused by: javax.persistence.PersistenceException: > > org.hibernate.PropertyAccessException: Null value was assigned to a > property > > of primitive type setter of > > org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly > > at > > > org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763) > > at > > > org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1694) > > at > > > org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1141) > > at > > > org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1068) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > [rt.jar:1.7.0_65] > > at > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > [rt.jar:1.7.0_65] > > at > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > [rt.jar:1.7.0_65] > > at java.lang.reflect.Method.invoke(Method.java:606) > [rt.jar:1.7.0_65] > > at > > > org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:32) > > ... 30 more > > Caused by: org.hibernate.PropertyAccessException: Null value was > assigned to > > a property of primitive type setter of > > org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly > > at > > > org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:126) > > at > > > org.hibernate.tuple.entity.AbstractEntityTuplizer.setPropertyValues(AbstractEntityTuplizer.java:713) > > at > > > org.hibernate.tuple.entity.PojoEntityTuplizer.setPropertyValues(PojoEntityTuplizer.java:362) > > at > > > org.hibernate.persister.entity.AbstractEntityPersister.setPropertyValues(AbstractEntityPersister.java:4718) > > at > > > org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:188) > > at > > > org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:144) > > at > > > org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.performTwoPhaseLoad(AbstractRowReader.java:244) > > at > > > org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.finishUp(AbstractRowReader.java:215) > > at > > > org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:140) > > at > > > org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:138) > > at > > > org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:102) > > at > > > org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:186) > > at > > > org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:4126) > > at > > > org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:503) > > at > > > org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:468) > > at > > > org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:213) > > at > > > org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:275) > > at > > > org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:151) > > at > org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1070) > > at > org.hibernate.internal.SessionImpl.access$2000(SessionImpl.java:176) > > at > > > org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2551) > > at org.hibernate.internal.SessionImpl.get(SessionImpl.java:955) > > at > > > org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1110) > > ... 36 more > > Caused by: java.lang.IllegalArgumentException: Can not set boolean field > > org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly to null > value > > at > > > sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164) > > [rt.jar:1.7.0_65] > > at > > > sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168) > > [rt.jar:1.7.0_65] > > at > > > sun.reflect.UnsafeBooleanFieldAccessorImpl.set(UnsafeBooleanFieldAccessorImpl.java:80) > > [rt.jar:1.7.0_65] > > at java.lang.reflect.Field.set(Field.java:741) [rt.jar:1.7.0_65] > > at > > > org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:122) > > ... 58 more > > > > -- > > Matthew Casperson > > Senior Front End Developer > > Technology, Space & Distribution > > Auto & General Holdings Pty Ltd > > P: 07) 3377 8751 (Direct: 3377 8751 ) > > F: 07) 3377 8833 > > > > > > > > This email is sent by Auto & General Insurance Company Ltd, Auto & > General > > Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body > > corporate (Auto & General) and is for the intended addressee. > > The views expressed in this email and attachments (email) reflect the > views > > of the stated author but may not reflect views of Auto & General. This > email > > is confidential and subject to copyright. > > It may be privileged. If you are not the intended addressee, > confidentiality > > and privilege have not been waived and any use, interference with, or > > disclosure of this email is unauthorised. > > If you are not the intended addressee please immediately notify the > sender > > and then delete the email. Auto & General does not warrant that this > email > > is error or virus free. > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- *Matthew Casperson* *Senior Front End Developer* Technology, Space & Distribution Auto & General Holdings Pty Ltd P: 07) 3377 8751 (Direct: 3377 8751) F: 07) 3377 8833 -- This email is sent by Auto & General Insurance Company Ltd, Auto & General Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body corporate (Auto & General) and is for the intended addressee. The views expressed in this email and attachments (email) reflect the views of the stated author but may not reflect views of Auto & General. This email is confidential and subject to copyright. It may be privileged. If you are not the intended addressee, confidentiality and privilege have not been waived and any use, interference with, or disclosure of this email is unauthorised. If you are not the intended addressee please immediately notify the sender and then delete the email. Auto & General does not warrant that this email is error or virus free. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150507/5eeeb785/attachment-0001.html From srossillo at smartling.com Wed May 6 17:18:55 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Wed, 6 May 2015 17:18:55 -0400 Subject: [keycloak-dev] Spring Boot Starter for Spring Security Adapter Message-ID: <6DFE98FA-4D5D-4F1D-994F-8ABA9468FC59@smartling.com> Hey all, I need to add one more module to automatically configure Spring Security for Spring Boot applications. This is a convenience but it?s also important to stop Spring Boot from registering the security filters twice. This would be post 1.2.0 but I want to bring it up for two reasons. First, documentation. For 1.2.0, I?ll add a note on the extra Spring Bean that has to be added to stop Spring from registering the Keycloak security filters twice. Secondly, we need a decent module name. spring-boot-starter-keycloak would be inline with Spring?s boot starter naming conventions but I wanted to get your opinions first. There?s already a spring-boot adapter in Keycloak that uses the Tomcat adapter. I don?t want to confuse things. There?s also the option of maintaining this boot starter separately or trying to contribute it to Spring Boot if that?s a better place for it to live. Best, Scott From bburke at redhat.com Wed May 6 20:58:05 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 06 May 2015 20:58:05 -0400 Subject: [keycloak-dev] Spring Boot Starter for Spring Security Adapter In-Reply-To: <6DFE98FA-4D5D-4F1D-994F-8ABA9468FC59@smartling.com> References: <6DFE98FA-4D5D-4F1D-994F-8ABA9468FC59@smartling.com> Message-ID: <554AB89D.7070705@redhat.com> Also remember if it is undocumented nobody but you will be using it :) On 5/6/2015 5:18 PM, Scott Rossillo wrote: > Hey all, > > I need to add one more module to automatically configure Spring Security for Spring Boot applications. This is a convenience but it?s also important to stop Spring Boot from registering the security filters twice. > > This would be post 1.2.0 but I want to bring it up for two reasons. > > First, documentation. For 1.2.0, I?ll add a note on the extra Spring Bean that has to be added to stop Spring from registering the Keycloak security filters twice. > > Secondly, we need a decent module name. spring-boot-starter-keycloak would be inline with Spring?s boot starter naming conventions but I wanted to get your opinions first. There?s already a spring-boot adapter in Keycloak that uses the Tomcat adapter. I don?t want to confuse things. There?s also the option of maintaining this boot starter separately or trying to contribute it to Spring Boot if that?s a better place for it to live. > > Best, > Scott > > > _______________________________________________ > 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 May 7 00:08:25 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 7 May 2015 00:08:25 -0400 (EDT) Subject: [keycloak-dev] Problem upgrading from 1.2.0.Beta1 to CR1 In-Reply-To: References: <1635854945.13795538.1430910951426.JavaMail.zimbra@redhat.com> Message-ID: <1964450824.14310906.1430971705753.JavaMail.zimbra@redhat.com> Just tried upgrading to 1.2.0.Beta1 from 1.0.4 and can confirm there's a problem. If we get a fix in master can you try it out before we release 1.2.0.Final next week? ----- Original Message ----- > From: "Matthew Casperson" > To: "Stian Thorgersen" , mposolda at redhat.com > Cc: keycloak-dev at lists.jboss.org > Sent: Wednesday, May 6, 2015 10:51:50 PM > Subject: Re: [keycloak-dev] Problem upgrading from 1.2.0.Beta1 to CR1 > > > By the way, are you using H2 in production? > We are still developing the platforms that rely on Keycloak. H2 has worked > well (we have low traffic with internal users only), but moving to MySQL is > something we'll be doing. > > > What version did you upgrade from? > The table was upgraded from 1.0.4 to 1.2.0.Beta1, then the error appeared > attempting to upgrade to CR1. > > >Maybe you can try to manually connect to your H2 database and set the > fields "DIRECT_GRANTS_ONLY" on CLIENT table to non-null value manually > through SQL. > I'll spend some time this week looking at the tables and the offending > column to see if I can manually update it and get the upgrade working. > > On Wed, May 6, 2015 at 9:15 PM, Stian Thorgersen wrote: > > > What version did you upgrade from? > > > > ----- Original Message ----- > > > From: "Matthew Casperson" > > > To: keycloak-dev at lists.jboss.org > > > Sent: Wednesday, May 6, 2015 12:59:03 AM > > > Subject: [keycloak-dev] Problem upgrading from 1.2.0.Beta1 to CR1 > > > > > > I received this error after copying the h2 database from my existing > > > 1.2.0.Beta1 deployment into a fresh copy of CR1. > > > Maybe a bug with the upgrade process? > > > jboss.undertow.deployment.default-server.default-host./auth: Failed to > > start > > > service > > > at > > > > > org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > > > [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > > > at > > > > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > > > [rt.jar:1.7.0_65] > > > at > > > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > > > [rt.jar:1.7.0_65] > > > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] > > > Caused by: java.lang.RuntimeException: Failed to construct public > > > > > org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) > > > at > > > > > org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:160) > > > at > > > > > org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211) > > > at > > > > > org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295) > > > at > > > > > org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236) > > > at > > > > > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112) > > > at > > > > > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) > > > at > > > > > io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) > > > at > > > > > org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:79) > > > at > > > > > io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) > > > at > > > > > io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:220) > > > at > > > > > io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:125) > > > at > > > > > io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:508) > > > at > > > > > org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:88) > > > at > > > > > org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72) > > > at > > > > > org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > > > [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > > > at > > > > > org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > > > [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > > > ... 3 more > > > Caused by: org.keycloak.models.ModelException: > > > javax.persistence.PersistenceException: > > > org.hibernate.PropertyAccessException: Null value was assigned to a > > property > > > of primitive type setter of > > > org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly > > > at > > > > > org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:44) > > > at > > > > > org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:34) > > > at com.sun.proxy.$Proxy57.find(Unknown Source) > > > at > > > > > org.keycloak.models.jpa.JpaRealmProvider.getRealm(JpaRealmProvider.java:63) > > > at > > > > > org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:163) > > > at > > > > > org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:40) > > > at > > > > > org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:31) > > > at > > > > > org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:160) > > > at > > > > > org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:85) > > > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > > Method) > > > [rt.jar:1.7.0_65] > > > at > > > > > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > > > [rt.jar:1.7.0_65] > > > at > > > > > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > > > [rt.jar:1.7.0_65] > > > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > > > [rt.jar:1.7.0_65] > > > at > > > > > org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148) > > > ... 18 more > > > Caused by: javax.persistence.PersistenceException: > > > org.hibernate.PropertyAccessException: Null value was assigned to a > > property > > > of primitive type setter of > > > org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly > > > at > > > > > org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763) > > > at > > > > > org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1694) > > > at > > > > > org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1141) > > > at > > > > > org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1068) > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > > [rt.jar:1.7.0_65] > > > at > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > > [rt.jar:1.7.0_65] > > > at > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > > [rt.jar:1.7.0_65] > > > at java.lang.reflect.Method.invoke(Method.java:606) > > [rt.jar:1.7.0_65] > > > at > > > > > org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:32) > > > ... 30 more > > > Caused by: org.hibernate.PropertyAccessException: Null value was > > assigned to > > > a property of primitive type setter of > > > org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly > > > at > > > > > org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:126) > > > at > > > > > org.hibernate.tuple.entity.AbstractEntityTuplizer.setPropertyValues(AbstractEntityTuplizer.java:713) > > > at > > > > > org.hibernate.tuple.entity.PojoEntityTuplizer.setPropertyValues(PojoEntityTuplizer.java:362) > > > at > > > > > org.hibernate.persister.entity.AbstractEntityPersister.setPropertyValues(AbstractEntityPersister.java:4718) > > > at > > > > > org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:188) > > > at > > > > > org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:144) > > > at > > > > > org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.performTwoPhaseLoad(AbstractRowReader.java:244) > > > at > > > > > org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.finishUp(AbstractRowReader.java:215) > > > at > > > > > org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:140) > > > at > > > > > org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:138) > > > at > > > > > org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:102) > > > at > > > > > org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:186) > > > at > > > > > org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:4126) > > > at > > > > > org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:503) > > > at > > > > > org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:468) > > > at > > > > > org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:213) > > > at > > > > > org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:275) > > > at > > > > > org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:151) > > > at > > org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1070) > > > at > > org.hibernate.internal.SessionImpl.access$2000(SessionImpl.java:176) > > > at > > > > > org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2551) > > > at org.hibernate.internal.SessionImpl.get(SessionImpl.java:955) > > > at > > > > > org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1110) > > > ... 36 more > > > Caused by: java.lang.IllegalArgumentException: Can not set boolean field > > > org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly to null > > value > > > at > > > > > sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164) > > > [rt.jar:1.7.0_65] > > > at > > > > > sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168) > > > [rt.jar:1.7.0_65] > > > at > > > > > sun.reflect.UnsafeBooleanFieldAccessorImpl.set(UnsafeBooleanFieldAccessorImpl.java:80) > > > [rt.jar:1.7.0_65] > > > at java.lang.reflect.Field.set(Field.java:741) [rt.jar:1.7.0_65] > > > at > > > > > org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:122) > > > ... 58 more > > > > > > -- > > > Matthew Casperson > > > Senior Front End Developer > > > Technology, Space & Distribution > > > Auto & General Holdings Pty Ltd > > > P: 07) 3377 8751 (Direct: 3377 8751 ) > > > F: 07) 3377 8833 > > > > > > > > > > > > This email is sent by Auto & General Insurance Company Ltd, Auto & > > General > > > Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body > > > corporate (Auto & General) and is for the intended addressee. > > > The views expressed in this email and attachments (email) reflect the > > views > > > of the stated author but may not reflect views of Auto & General. This > > email > > > is confidential and subject to copyright. > > > It may be privileged. If you are not the intended addressee, > > confidentiality > > > and privilege have not been waived and any use, interference with, or > > > disclosure of this email is unauthorised. > > > If you are not the intended addressee please immediately notify the > > sender > > > and then delete the email. Auto & General does not warrant that this > > email > > > is error or virus free. > > > > > > _______________________________________________ > > > keycloak-dev mailing list > > > keycloak-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > -- > *Matthew Casperson* > *Senior Front End Developer* > Technology, Space & Distribution > Auto & General Holdings Pty Ltd > P: 07) 3377 8751 (Direct: 3377 8751) > F: 07) 3377 8833 > > -- > > > This email is sent by Auto & General Insurance Company Ltd, Auto & General > Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body > corporate (Auto & General) and is for the intended addressee. > The views expressed in this email and attachments (email) reflect the views > of the stated author but may not reflect views of Auto & General. This email > is confidential and subject to copyright. > It may be privileged. If you are not the intended addressee, confidentiality > and privilege have not been waived and any use, interference with, or > disclosure of this email is unauthorised. > If you are not the intended addressee please immediately notify the sender > and then delete the email. Auto & General does not warrant that this email > is error or virus free. > > From stian at redhat.com Thu May 7 00:30:48 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 7 May 2015 00:30:48 -0400 (EDT) Subject: [keycloak-dev] Docs - missing auth-server into standalone.xml In-Reply-To: <094E4681-95CE-46AC-B3F3-E7AA89370D76@redhat.com> References: <094E4681-95CE-46AC-B3F3-E7AA89370D76@redhat.com> Message-ID: <752264260.14313549.1430973048238.JavaMail.zimbra@redhat.com> Seems I did a copy/paste error here, fixed now ;) ----- Original Message ----- > From: "Libor Krzy?anek" > To: keycloak-dev at lists.jboss.org > Sent: Wednesday, May 6, 2015 4:12:06 PM > Subject: [keycloak-dev] Docs - missing auth-server into standalone.xml > > Hi, > it seems docs in > http://docs.jboss.org/keycloak/docs/1.2.0.CR1/userguide/html/server-installation.html#d4e115 > should note about adding 4th element: > > > > true > auth > > > > Thanks, > > Libor Krzy?anek > jboss.org Development Team > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Thu May 7 06:27:43 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 7 May 2015 06:27:43 -0400 (EDT) Subject: [keycloak-dev] Keycloak 1.2.0.CR1 Docker image Message-ID: <1511910813.14749155.1430994463892.JavaMail.zimbra@redhat.com> Keycloak 1.2.0.CR1 Docker image is available on Docker Hub (https://registry.hub.docker.com/u/jboss/keycloak/) From hermann.hill at optile.net Thu May 7 10:41:49 2015 From: hermann.hill at optile.net (Hermann Hill) Date: Thu, 7 May 2015 14:41:49 +0000 Subject: [keycloak-dev] Keycloak with mongoDB replica set? Message-ID: Hi, I'd like to use Keycloak with a mongoDB replica set as its backing store, but I didn't find any configuration option to make Keycloak connect to more than one mongo server. Are there plans to support this in the future? Thanks for your time and best regards, Hermann Josef Hill Software Architect optile GmbH Ganghoferstra?e 39 | 80339 M?nchen Mobil +49 (151) 5385 0784 hermann.hill at optile.net | www.optile.net USt.Id.-Nr. DE268847980 Gesch?ftsf?hrer: Daniel Smeds, Stefan Reinhardt Handelsregister M?nchen HRB 183178 +++ creating an open payment world +++ From mposolda at redhat.com Thu May 7 14:56:25 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 07 May 2015 20:56:25 +0200 Subject: [keycloak-dev] Keycloak with mongoDB replica set? In-Reply-To: References: Message-ID: <554BB559.8020608@redhat.com> Hi, I've created JIRA https://issues.jboss.org/browse/KEYCLOAK-1285 for support replica set. For the version 1.2.0.Final, which will be released quite soon, I've added small enhancement in class DefaultMongoConnectionFactoryProvider where is our MongoClient bootstrapped. With it, you will be able to override method DefaultMongoConnectionFactoryProvider.createMongoClient and easily add and configure MongoClient however you need. See docs for more info about how to use and override our SPI: http://docs.jboss.org/keycloak/docs/1.2.0.CR1/userguide/html/providers.html Marek On 7.5.2015 16:41, Hermann Hill wrote: > Hi, > > I'd like to use Keycloak with a mongoDB replica set as its backing store, but I didn't find any configuration option to make Keycloak connect to more than one mongo server. > Are there plans to support this in the future? > > Thanks for your time and best regards, > > Hermann Josef Hill > Software Architect > > optile GmbH > Ganghoferstra?e 39 | 80339 M?nchen > Mobil +49 (151) 5385 0784 > > hermann.hill at optile.net | www.optile.net > > USt.Id.-Nr. DE268847980 > Gesch?ftsf?hrer: Daniel Smeds, Stefan Reinhardt > Handelsregister M?nchen HRB 183178 > > +++ creating an open payment world +++ > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From matthew.casperson at autogeneral.com.au Thu May 7 16:55:14 2015 From: matthew.casperson at autogeneral.com.au (Matthew Casperson) Date: Fri, 8 May 2015 06:55:14 +1000 Subject: [keycloak-dev] Problem upgrading from 1.2.0.Beta1 to CR1 In-Reply-To: <1964450824.14310906.1430971705753.JavaMail.zimbra@redhat.com> References: <1635854945.13795538.1430910951426.JavaMail.zimbra@redhat.com> <1964450824.14310906.1430971705753.JavaMail.zimbra@redhat.com> Message-ID: I can't make any promises, but I will certainly try :) - Matt On Thu, May 7, 2015 at 2:08 PM, Stian Thorgersen wrote: > Just tried upgrading to 1.2.0.Beta1 from 1.0.4 and can confirm there's a > problem. > > If we get a fix in master can you try it out before we release 1.2.0.Final > next week? > > ----- Original Message ----- > > From: "Matthew Casperson" > > To: "Stian Thorgersen" , mposolda at redhat.com > > Cc: keycloak-dev at lists.jboss.org > > Sent: Wednesday, May 6, 2015 10:51:50 PM > > Subject: Re: [keycloak-dev] Problem upgrading from 1.2.0.Beta1 to CR1 > > > > > By the way, are you using H2 in production? > > We are still developing the platforms that rely on Keycloak. H2 has > worked > > well (we have low traffic with internal users only), but moving to MySQL > is > > something we'll be doing. > > > > > What version did you upgrade from? > > The table was upgraded from 1.0.4 to 1.2.0.Beta1, then the error appeared > > attempting to upgrade to CR1. > > > > >Maybe you can try to manually connect to your H2 database and set the > > fields "DIRECT_GRANTS_ONLY" on CLIENT table to non-null value manually > > through SQL. > > I'll spend some time this week looking at the tables and the offending > > column to see if I can manually update it and get the upgrade working. > > > > On Wed, May 6, 2015 at 9:15 PM, Stian Thorgersen > wrote: > > > > > What version did you upgrade from? > > > > > > ----- Original Message ----- > > > > From: "Matthew Casperson" > > > > To: keycloak-dev at lists.jboss.org > > > > Sent: Wednesday, May 6, 2015 12:59:03 AM > > > > Subject: [keycloak-dev] Problem upgrading from 1.2.0.Beta1 to CR1 > > > > > > > > I received this error after copying the h2 database from my existing > > > > 1.2.0.Beta1 deployment into a fresh copy of CR1. > > > > Maybe a bug with the upgrade process? > > > > jboss.undertow.deployment.default-server.default-host./auth: Failed > to > > > start > > > > service > > > > at > > > > > > > > org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > > > > [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > > > > at > > > > > > > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > > > > [rt.jar:1.7.0_65] > > > > at > > > > > > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > > > > [rt.jar:1.7.0_65] > > > > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] > > > > Caused by: java.lang.RuntimeException: Failed to construct public > > > > > > > > org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) > > > > at > > > > > > > > org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:160) > > > > at > > > > > > > > org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211) > > > > at > > > > > > > > org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295) > > > > at > > > > > > > > org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236) > > > > at > > > > > > > > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112) > > > > at > > > > > > > > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) > > > > at > > > > > > > > io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) > > > > at > > > > > > > > org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:79) > > > > at > > > > > > > > io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) > > > > at > > > > > > > > io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:220) > > > > at > > > > > > > > io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:125) > > > > at > > > > > > > > io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:508) > > > > at > > > > > > > > org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:88) > > > > at > > > > > > > > org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72) > > > > at > > > > > > > > org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > > > > [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > > > > at > > > > > > > > org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > > > > [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > > > > ... 3 more > > > > Caused by: org.keycloak.models.ModelException: > > > > javax.persistence.PersistenceException: > > > > org.hibernate.PropertyAccessException: Null value was assigned to a > > > property > > > > of primitive type setter of > > > > org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly > > > > at > > > > > > > > org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:44) > > > > at > > > > > > > > org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:34) > > > > at com.sun.proxy.$Proxy57.find(Unknown Source) > > > > at > > > > > > > > org.keycloak.models.jpa.JpaRealmProvider.getRealm(JpaRealmProvider.java:63) > > > > at > > > > > > > > org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:163) > > > > at > > > > > > > > org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:40) > > > > at > > > > > > > > org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:31) > > > > at > > > > > > > > org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:160) > > > > at > > > > > > > > org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:85) > > > > at > sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > > > Method) > > > > [rt.jar:1.7.0_65] > > > > at > > > > > > > > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > > > > [rt.jar:1.7.0_65] > > > > at > > > > > > > > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > > > > [rt.jar:1.7.0_65] > > > > at > java.lang.reflect.Constructor.newInstance(Constructor.java:526) > > > > [rt.jar:1.7.0_65] > > > > at > > > > > > > > org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148) > > > > ... 18 more > > > > Caused by: javax.persistence.PersistenceException: > > > > org.hibernate.PropertyAccessException: Null value was assigned to a > > > property > > > > of primitive type setter of > > > > org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly > > > > at > > > > > > > > org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763) > > > > at > > > > > > > > org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1694) > > > > at > > > > > > > > org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1141) > > > > at > > > > > > > > org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1068) > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > > > [rt.jar:1.7.0_65] > > > > at > > > > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > > > [rt.jar:1.7.0_65] > > > > at > > > > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > > > [rt.jar:1.7.0_65] > > > > at java.lang.reflect.Method.invoke(Method.java:606) > > > [rt.jar:1.7.0_65] > > > > at > > > > > > > > org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:32) > > > > ... 30 more > > > > Caused by: org.hibernate.PropertyAccessException: Null value was > > > assigned to > > > > a property of primitive type setter of > > > > org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly > > > > at > > > > > > > > org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:126) > > > > at > > > > > > > > org.hibernate.tuple.entity.AbstractEntityTuplizer.setPropertyValues(AbstractEntityTuplizer.java:713) > > > > at > > > > > > > > org.hibernate.tuple.entity.PojoEntityTuplizer.setPropertyValues(PojoEntityTuplizer.java:362) > > > > at > > > > > > > > org.hibernate.persister.entity.AbstractEntityPersister.setPropertyValues(AbstractEntityPersister.java:4718) > > > > at > > > > > > > > org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:188) > > > > at > > > > > > > > org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:144) > > > > at > > > > > > > > org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.performTwoPhaseLoad(AbstractRowReader.java:244) > > > > at > > > > > > > > org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.finishUp(AbstractRowReader.java:215) > > > > at > > > > > > > > org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:140) > > > > at > > > > > > > > org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:138) > > > > at > > > > > > > > org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:102) > > > > at > > > > > > > > org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:186) > > > > at > > > > > > > > org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:4126) > > > > at > > > > > > > > org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:503) > > > > at > > > > > > > > org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:468) > > > > at > > > > > > > > org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:213) > > > > at > > > > > > > > org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:275) > > > > at > > > > > > > > org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:151) > > > > at > > > org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1070) > > > > at > > > org.hibernate.internal.SessionImpl.access$2000(SessionImpl.java:176) > > > > at > > > > > > > > org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2551) > > > > at org.hibernate.internal.SessionImpl.get(SessionImpl.java:955) > > > > at > > > > > > > > org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1110) > > > > ... 36 more > > > > Caused by: java.lang.IllegalArgumentException: Can not set boolean > field > > > > org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly to > null > > > value > > > > at > > > > > > > > sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164) > > > > [rt.jar:1.7.0_65] > > > > at > > > > > > > > sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168) > > > > [rt.jar:1.7.0_65] > > > > at > > > > > > > > sun.reflect.UnsafeBooleanFieldAccessorImpl.set(UnsafeBooleanFieldAccessorImpl.java:80) > > > > [rt.jar:1.7.0_65] > > > > at java.lang.reflect.Field.set(Field.java:741) > [rt.jar:1.7.0_65] > > > > at > > > > > > > > org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:122) > > > > ... 58 more > > > > > > > > -- > > > > Matthew Casperson > > > > Senior Front End Developer > > > > Technology, Space & Distribution > > > > Auto & General Holdings Pty Ltd > > > > P: 07) 3377 8751 (Direct: 3377 8751 ) > > > > F: 07) 3377 8833 > > > > > > > > > > > > > > > > This email is sent by Auto & General Insurance Company Ltd, Auto & > > > General > > > > Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body > > > > corporate (Auto & General) and is for the intended addressee. > > > > The views expressed in this email and attachments (email) reflect the > > > views > > > > of the stated author but may not reflect views of Auto & General. > This > > > email > > > > is confidential and subject to copyright. > > > > It may be privileged. If you are not the intended addressee, > > > confidentiality > > > > and privilege have not been waived and any use, interference with, or > > > > disclosure of this email is unauthorised. > > > > If you are not the intended addressee please immediately notify the > > > sender > > > > and then delete the email. Auto & General does not warrant that this > > > email > > > > is error or virus free. > > > > > > > > _______________________________________________ > > > > keycloak-dev mailing list > > > > keycloak-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > -- > > *Matthew Casperson* > > *Senior Front End Developer* > > Technology, Space & Distribution > > Auto & General Holdings Pty Ltd > > P: 07) 3377 8751 (Direct: 3377 8751) > > F: 07) 3377 8833 > > > > -- > > > > > > This email is sent by Auto & General Insurance Company Ltd, Auto & > General > > Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body > > corporate (Auto & General) and is for the intended addressee. > > The views expressed in this email and attachments (email) reflect the > views > > of the stated author but may not reflect views of Auto & General. This > email > > is confidential and subject to copyright. > > It may be privileged. If you are not the intended addressee, > confidentiality > > and privilege have not been waived and any use, interference with, or > > disclosure of this email is unauthorised. > > If you are not the intended addressee please immediately notify the > sender > > and then delete the email. Auto & General does not warrant that this > email > > is error or virus free. > > > > > -- *Matthew Casperson* *Senior Front End Developer* Technology, Space & Distribution Auto & General Holdings Pty Ltd P: 07) 3377 8751 (Direct: 3377 8751) F: 07) 3377 8833 -- This email is sent by Auto & General Insurance Company Ltd, Auto & General Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body corporate (Auto & General) and is for the intended addressee. The views expressed in this email and attachments (email) reflect the views of the stated author but may not reflect views of Auto & General. This email is confidential and subject to copyright. It may be privileged. If you are not the intended addressee, confidentiality and privilege have not been waived and any use, interference with, or disclosure of this email is unauthorised. If you are not the intended addressee please immediately notify the sender and then delete the email. Auto & General does not warrant that this email is error or virus free. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150508/f6c8c6b6/attachment-0001.html From marcioferlan at gmail.com Thu May 7 17:30:46 2015 From: marcioferlan at gmail.com (Marcio Lima) Date: Thu, 07 May 2015 18:30:46 -0300 Subject: [keycloak-dev] Themes per application Message-ID: <554BD986.8010406@gmail.com> Hello guys! I'm trying to implement Keycloak in my solution, but it turns out that I need to have a completely different login page per application in the same Realm. Keycloak allows me to create themes, but only at Realm level, not at Application level. How would you guys suggest me approaching this? Any plans to develop such a feature or ways to work around it? Thanks in advance! -- Atenciosamente, Marcio Fernandes de Lima http://linkedin.com/in/marcioferlan SCJP, SCWCD, MySQL Core Certified From srossillo at smartling.com Thu May 7 17:41:55 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Thu, 7 May 2015 17:41:55 -0400 Subject: [keycloak-dev] Node Registration Message-ID: org.keycloak.adapters.NodesRegistrationManagement doesn?t sent a port when it registers a node. Additionally, the KC server assumes the cluster node is using port 8080. So even if you manually register a node, as say localhost:9092, when you press ?Test Cluster Availability? the KC server appends port 8080 to the request: http://localhost:9092:8080/customer-portal/ I think there are two bugs, I can open JIRAs if you like: 1. org.keycloak.adapters.NodesRegistrationManagement should send the port the server is on 2. KC server should not assume port 8080 Best, Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150507/731613f1/attachment.html From srossillo at smartling.com Thu May 7 20:20:00 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Thu, 7 May 2015 20:20:00 -0400 Subject: [keycloak-dev] Spring Security Adapter Message-ID: <2392FFB7-1AAE-45C1-8501-77B3B00E1A06@smartling.com> Hi, I sent 3 pull requests that get the Spring Security adapter into shape for production usage. I started writing the documentation today and will be sending a PR tomorrow. I have one more code related PR tomorrow to set up the default Spring Security configuration fully so there?s less to document. :) Best, Scott From stian at redhat.com Fri May 8 01:11:42 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 8 May 2015 01:11:42 -0400 (EDT) Subject: [keycloak-dev] Spring Security Adapter In-Reply-To: <2392FFB7-1AAE-45C1-8501-77B3B00E1A06@smartling.com> References: <2392FFB7-1AAE-45C1-8501-77B3B00E1A06@smartling.com> Message-ID: <21801512.15438768.1431061902785.JavaMail.zimbra@redhat.com> Great, thanks for contributing this. Would also be good to have an example and tests (see testsuite which has adapters tests for tomcat, jetty, etc.). ----- Original Message ----- > From: "Scott Rossillo" > To: "keycloak-dev" > Sent: Friday, 8 May, 2015 2:20:00 AM > Subject: [keycloak-dev] Spring Security Adapter > > Hi, > > I sent 3 pull requests that get the Spring Security adapter into shape for > production usage. I started writing the documentation today and will be > sending a PR tomorrow. > > I have one more code related PR tomorrow to set up the default Spring > Security configuration fully so there?s less to document. :) > > Best, > Scott > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Fri May 8 01:14:46 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 8 May 2015 01:14:46 -0400 (EDT) Subject: [keycloak-dev] Themes per application In-Reply-To: <554BD986.8010406@gmail.com> References: <554BD986.8010406@gmail.com> Message-ID: <1846112137.15439002.1431062086005.JavaMail.zimbra@redhat.com> When a user logs in the user logs in to the realm, not the application. So it doesn't make sense to have different login pages per application. ----- Original Message ----- > From: "Marcio Lima" > To: keycloak-dev at lists.jboss.org > Sent: Thursday, 7 May, 2015 11:30:46 PM > Subject: [keycloak-dev] Themes per application > > Hello guys! > > I'm trying to implement Keycloak in my solution, but it turns out that I > need to have a completely different login page per application in the > same Realm. Keycloak allows me to create themes, but only at Realm > level, not at Application level. > > How would you guys suggest me approaching this? Any plans to develop > such a feature or ways to work around it? > > Thanks in advance! > -- > > Atenciosamente, > > Marcio Fernandes de Lima > http://linkedin.com/in/marcioferlan > SCJP, SCWCD, MySQL Core Certified > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From srossillo at smartling.com Fri May 8 01:24:42 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Fri, 8 May 2015 01:24:42 -0400 Subject: [keycloak-dev] Spring Security Adapter In-Reply-To: <21801512.15438768.1431061902785.JavaMail.zimbra@redhat.com> References: <2392FFB7-1AAE-45C1-8501-77B3B00E1A06@smartling.com> <21801512.15438768.1431061902785.JavaMail.zimbra@redhat.com> Message-ID: <10EC04FB-4412-42CF-8745-DB0722D35EF9@smartling.com> Hi Stian, There?s an example here: https://github.com/foo4u/keycloak-spring-demo I will look into making them run on Wildfly and contributing them to the Keycloak project but it may not make the 1.2.0.Final if that?s going out Monday. Also, I need to push an update to them once you merge my PRs. As for tests, there?s pretty solid unit test coverage in the module?s test folder. However, I?ll look into creating a test suite. These definitely look more like integration tests, which are also quite important. Also post 1.2.0.Final but definitely something I?ll add. ~ Scott PS - I sent another PR about an hour ago adding a docbook section on using the Spring Security adapter. > On May 8, 2015, at 1:11 AM, Stian Thorgersen wrote: > > Great, thanks for contributing this. Would also be good to have an example and tests (see testsuite which has adapters tests for tomcat, jetty, etc.). > > ----- Original Message ----- >> From: "Scott Rossillo" >> To: "keycloak-dev" >> Sent: Friday, 8 May, 2015 2:20:00 AM >> Subject: [keycloak-dev] Spring Security Adapter >> >> Hi, >> >> I sent 3 pull requests that get the Spring Security adapter into shape for >> production usage. I started writing the documentation today and will be >> sending a PR tomorrow. >> >> I have one more code related PR tomorrow to set up the default Spring >> Security configuration fully so there?s less to document. :) >> >> Best, >> Scott >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Fri May 8 01:28:15 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 8 May 2015 01:28:15 -0400 (EDT) Subject: [keycloak-dev] Spring Security Adapter In-Reply-To: <10EC04FB-4412-42CF-8745-DB0722D35EF9@smartling.com> References: <2392FFB7-1AAE-45C1-8501-77B3B00E1A06@smartling.com> <21801512.15438768.1431061902785.JavaMail.zimbra@redhat.com> <10EC04FB-4412-42CF-8745-DB0722D35EF9@smartling.com> Message-ID: <668363196.15440222.1431062895569.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Scott Rossillo" > To: "Stian Thorgersen" > Cc: "keycloak-dev" > Sent: Friday, 8 May, 2015 7:24:42 AM > Subject: Re: [keycloak-dev] Spring Security Adapter > > Hi Stian, > > There?s an example here: https://github.com/foo4u/keycloak-spring-demo > > I will look into making them run on Wildfly and contributing them to the > Keycloak project but it may not make the 1.2.0.Final if that?s going out > Monday. Also, I need to push an update to them once you merge my PRs. Merged and after 1.2.0.Final is no prob. > > As for tests, there?s pretty solid unit test coverage in the module?s test > folder. However, I?ll look into creating a test suite. These definitely look > more like integration tests, which are also quite important. Also post > 1.2.0.Final but definitely something I?ll add. We barely have unit tests and try to aim for integration/end-to-end or whatever you'd call it ;) > > ~ Scott > > PS - I sent another PR about an hour ago adding a docbook section on using > the Spring Security adapter. > > > > On May 8, 2015, at 1:11 AM, Stian Thorgersen wrote: > > > > Great, thanks for contributing this. Would also be good to have an example > > and tests (see testsuite which has adapters tests for tomcat, jetty, > > etc.). > > > > ----- Original Message ----- > >> From: "Scott Rossillo" > >> To: "keycloak-dev" > >> Sent: Friday, 8 May, 2015 2:20:00 AM > >> Subject: [keycloak-dev] Spring Security Adapter > >> > >> Hi, > >> > >> I sent 3 pull requests that get the Spring Security adapter into shape for > >> production usage. I started writing the documentation today and will be > >> sending a PR tomorrow. > >> > >> I have one more code related PR tomorrow to set up the default Spring > >> Security configuration fully so there?s less to document. :) > >> > >> Best, > >> Scott > >> > >> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > From stian at redhat.com Fri May 8 01:58:18 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 8 May 2015 01:58:18 -0400 (EDT) Subject: [keycloak-dev] Keycloak 1.2.0.CR1 OpenShift Cartridge released Message-ID: <54921065.15445315.1431064698977.JavaMail.zimbra@redhat.com> OpenShift Cartridge has been updated to 1.2.0.CR1 From stefano.travelli at entaksi.eu Fri May 8 03:57:50 2015 From: stefano.travelli at entaksi.eu (Stefano Travelli) Date: Fri, 08 May 2015 09:57:50 +0200 Subject: [keycloak-dev] Themes per application In-Reply-To: <1846112137.15439002.1431062086005.JavaMail.zimbra@redhat.com> References: <554BD986.8010406@gmail.com> <1846112137.15439002.1431062086005.JavaMail.zimbra@redhat.com> Message-ID: <554C6C7E.3080706@entaksi.eu> I have a similar use case which I addressed overriding the ftl file and selecting different template based on clientid: <#if client?? && client.clientId?contains('client_x')> <#import "client_x/template.ftl" as layout> <#else> <#import "template.ftl" as layout> It works pretty well with login and register template. You won't be able to customize per application the reset password and error template, though. My use case is that I manage a service and there are several resellers for this service. Each reseller has its own branded application and want some branding on the login and register page as well. Hope this helps. stefano Il 08/05/2015 07:14, Stian Thorgersen ha scritto: > When a user logs in the user logs in to the realm, not the application. So it doesn't make sense to have different login pages per application. > > ----- Original Message ----- >> From: "Marcio Lima" >> To: keycloak-dev at lists.jboss.org >> Sent: Thursday, 7 May, 2015 11:30:46 PM >> Subject: [keycloak-dev] Themes per application >> >> Hello guys! >> >> I'm trying to implement Keycloak in my solution, but it turns out that I >> need to have a completely different login page per application in the >> same Realm. Keycloak allows me to create themes, but only at Realm >> level, not at Application level. >> >> How would you guys suggest me approaching this? Any plans to develop >> such a feature or ways to work around it? >> >> Thanks in advance! >> -- >> >> Atenciosamente, >> >> Marcio Fernandes de Lima >> http://linkedin.com/in/marcioferlan >> SCJP, SCWCD, MySQL Core Certified >> >> _______________________________________________ >> 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 -- *Stefano Travelli* *Entaksi Solutions srl* Via la Piana 76 - fraz. Pontepetri - 51028 San Marcello Pistoiese (PT) P.IVA 01621900479 http://www.entaksi.eu *AZIENDA CON SISTEMA INTEGRATO **DI GESTIONE* *QUALIT?**, SICUREZZA DELLE INFORMAZIONI, SERVIZI IT* *CERTIFICATO DA DNV**?**GL*** *=**ISO 9001 **= **ISO **27**001 **=**ISO **2**0**00**0 **=* La presente comunicazione ha natura non personale e le risposte potrebbero essere conosciute nell'organizzazione di appartenenza da pi? soggetti anche diversi dal mittente. Il messaggio e ogni documento o file allegato ? strettamente riservato ed ? rivolto unicamente alla/e persona/e o Enti cui ? indirizzata, ed alle altre/i da questi ultimi autorizzate a riceverlo. Sono vietate la diffusione, la distribuzione e la copia delle informazioni qui contenute da parte di soggetti non espressamente autorizzati.Se avete ricevuto questa e-mail per errore Vi preghiamo di eliminarla dai Vostri archivi e darne comunicazione al mittente. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150508/4d58def4/attachment-0001.html From stian at redhat.com Fri May 8 04:11:46 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 8 May 2015 04:11:46 -0400 (EDT) Subject: [keycloak-dev] Themes per application In-Reply-To: <554C6C7E.3080706@entaksi.eu> References: <554BD986.8010406@gmail.com> <1846112137.15439002.1431062086005.JavaMail.zimbra@redhat.com> <554C6C7E.3080706@entaksi.eu> Message-ID: <428895104.15480761.1431072706703.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Stefano Travelli" > To: keycloak-dev at lists.jboss.org > Sent: Friday, 8 May, 2015 9:57:50 AM > Subject: Re: [keycloak-dev] Themes per application > > I have a similar use case which I addressed overriding the ftl file and > selecting different template based on clientid: > > <#if client?? && client.clientId?contains('client_x')> > <#import "client_x/template.ftl" as layout> > <#else> > <#import "template.ftl" as layout> > > > It works pretty well with login and register template. You won't be able to > customize per application the reset password and error template, though. > > My use case is that I manage a service and there are several resellers for > this service. Each reseller has its own branded application and want some > branding on the login and register page as well. In that case how does it make sense that users log in to one reseller, but then later when visit another reseller are automatically logged in due to SSO. > > Hope this helps. > stefano > > Il 08/05/2015 07:14, Stian Thorgersen ha scritto: > > > > When a user logs in the user logs in to the realm, not the application. So it > doesn't make sense to have different login pages per application. > > ----- Original Message ----- > > > > From: "Marcio Lima" To: keycloak-dev at lists.jboss.org > Sent: Thursday, 7 May, 2015 11:30:46 PM > Subject: [keycloak-dev] Themes per application > > Hello guys! > > I'm trying to implement Keycloak in my solution, but it turns out that I > need to have a completely different login page per application in the > same Realm. Keycloak allows me to create themes, but only at Realm > level, not at Application level. > > How would you guys suggest me approaching this? Any plans to develop > such a feature or ways to work around it? > > Thanks in advance! > -- > > Atenciosamente, > > Marcio Fernandes de Lima http://linkedin.com/in/marcioferlan SCJP, SCWCD, > MySQL Core Certified > > _______________________________________________ > 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 > > -- > Stefano Travelli > Entaksi Solutions srl > Via la Piana 76 - fraz. Pontepetri - > 51028 San Marcello Pistoiese (PT) > P.IVA 01621900479 > http://www.entaksi.eu > > AZIENDA CON SISTEMA INTEGRATO DI GESTIONE > QUALIT? , SICUREZZA DELLE INFORMAZIONI, SERVIZI IT > CERTIFICATO DA DNV ? GL > = ISO 9001 = ISO 27 001 = ISO 2 0 00 0 = > > La presente comunicazione ha natura non personale e le risposte potrebbero > essere conosciute nell'organizzazione di appartenenza da pi? soggetti anche > diversi dal mittente. Il messaggio e ogni documento o file allegato ? > strettamente riservato ed ? rivolto unicamente alla/e persona/e o Enti cui ? > indirizzata, ed alle altre/i da questi ultimi autorizzate a riceverlo. S ono > vietate l a diffusione, la distribuzione e la copia delle informazioni qui > contenute da parte di soggetti non espressamente autorizzati. Se avete > ricevuto questa e-mail per errore Vi preghiamo di eliminarla dai Vostri > archivi e darne comunicazione al mittent e. > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stefano.travelli at entaksi.eu Fri May 8 04:49:37 2015 From: stefano.travelli at entaksi.eu (Stefano Travelli) Date: Fri, 08 May 2015 10:49:37 +0200 Subject: [keycloak-dev] Themes per application In-Reply-To: <428895104.15480761.1431072706703.JavaMail.zimbra@redhat.com> References: <554BD986.8010406@gmail.com> <1846112137.15439002.1431062086005.JavaMail.zimbra@redhat.com> <554C6C7E.3080706@entaksi.eu> <428895104.15480761.1431072706703.JavaMail.zimbra@redhat.com> Message-ID: <554C78A1.6070308@entaksi.eu> Il 08/05/2015 10:11, Stian Thorgersen ha scritto: > > ----- Original Message ----- >> From: "Stefano Travelli" >> To: keycloak-dev at lists.jboss.org >> Sent: Friday, 8 May, 2015 9:57:50 AM >> Subject: Re: [keycloak-dev] Themes per application >> >> I have a similar use case which I addressed overriding the ftl file and >> selecting different template based on clientid: >> >> <#if client?? && client.clientId?contains('client_x')> >> <#import "client_x/template.ftl" as layout> >> <#else> >> <#import "template.ftl" as layout> >> >> >> It works pretty well with login and register template. You won't be able to >> customize per application the reset password and error template, though. >> >> My use case is that I manage a service and there are several resellers for >> this service. Each reseller has its own branded application and want some >> branding on the login and register page as well. > In that case how does it make sense that users log in to one reseller, but then later when visit another reseller are automatically logged in due to SSO. It doesn't, and I'm not asking for a specific handling of themes per application in keycloak. My users are aware that they are logging in to my service, but since they pay the reseller in order to access it, the reseller likes to have its logo in the login and register page. Having the clientId in the template is nice enough for me. Unfortunately it is not available in the reset password and error page, maybe for good reasons. I will try to dig into the code. stefano > > >> Hope this helps. >> stefano >> >> Il 08/05/2015 07:14, Stian Thorgersen ha scritto: >> >> >> >> When a user logs in the user logs in to the realm, not the application. So it >> doesn't make sense to have different login pages per application. >> >> ----- Original Message ----- >> >> >> >> From: "Marcio Lima" To: keycloak-dev at lists.jboss.org >> Sent: Thursday, 7 May, 2015 11:30:46 PM >> Subject: [keycloak-dev] Themes per application >> >> Hello guys! >> >> I'm trying to implement Keycloak in my solution, but it turns out that I >> need to have a completely different login page per application in the >> same Realm. Keycloak allows me to create themes, but only at Realm >> level, not at Application level. >> >> How would you guys suggest me approaching this? Any plans to develop >> such a feature or ways to work around it? >> >> Thanks in advance! >> -- >> >> Atenciosamente, >> >> Marcio Fernandes de Lima http://linkedin.com/in/marcioferlan SCJP, SCWCD, >> MySQL Core Certified >> >> _______________________________________________ >> 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 marcioferlan at gmail.com Fri May 8 08:15:32 2015 From: marcioferlan at gmail.com (Marcio Lima) Date: Fri, 08 May 2015 09:15:32 -0300 Subject: [keycloak-dev] Themes per application In-Reply-To: <1846112137.15439002.1431062086005.JavaMail.zimbra@redhat.com> References: <554BD986.8010406@gmail.com> <1846112137.15439002.1431062086005.JavaMail.zimbra@redhat.com> Message-ID: <554CA8E4.4070508@gmail.com> Hi Stian, thanks for the quick response! I do agree the login happens at Realm level and that shouldn't and won't change. However, in my case, the applications in that Realm are different. I basically see the following options to workaround it: 1. *Create one theme with **<#if>**blocks for each application* In this case I would need to change this template if a new application comes in or when something changes in any of the login pages (blocks). 2. *Dinamically load login pages from the theme page** *I ran this test and it worked just fine, but, I felt like I shouldn't be doing it this way... bad smell, you know? (:P) The theme login page loads a static login page of each application using the *client_id* variable. Then, places the contents on the current page and sets the necessary elements to Keycloak expected values (like form action, forgot password and register user links URLs, error messages, etc). For each new application, all I have to do is create the static resources in a */themes/${client_id}* folder, with the correct element IDs and it does the trick. Of course there are some drawbacks, but it turns out that I have now 3 applications using this approach. I wish I could have per-application themes, rather. 3. *Convince my client to use the same login page for all applications** *This would be the standard approach, but, unfortunatelly, isn't an option for me. Any thoughts on that? Thanks in advance. Regards, Marcio Fernandes de Lima http://linkedin.com/in/marcioferlan SCJP, SCWCD, MySQL Core Certified On 08/05/2015 02:14, Stian Thorgersen wrote: > When a user logs in the user logs in to the realm, not the application. So it doesn't make sense to have different login pages per application. > > ----- Original Message ----- >> From: "Marcio Lima" >> To: keycloak-dev at lists.jboss.org >> Sent: Thursday, 7 May, 2015 11:30:46 PM >> Subject: [keycloak-dev] Themes per application >> >> Hello guys! >> >> I'm trying to implement Keycloak in my solution, but it turns out that I >> need to have a completely different login page per application in the >> same Realm. Keycloak allows me to create themes, but only at Realm >> level, not at Application level. >> >> How would you guys suggest me approaching this? Any plans to develop >> such a feature or ways to work around it? >> >> Thanks in advance! >> -- >> >> Atenciosamente, >> >> Marcio Fernandes de Lima >> http://linkedin.com/in/marcioferlan >> SCJP, SCWCD, MySQL Core Certified >> >> _______________________________________________ >> 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/20150508/ac17255e/attachment.html From srossillo at smartling.com Fri May 8 10:20:36 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Fri, 8 May 2015 10:20:36 -0400 Subject: [keycloak-dev] Spring Security Adapter In-Reply-To: <668363196.15440222.1431062895569.JavaMail.zimbra@redhat.com> References: <2392FFB7-1AAE-45C1-8501-77B3B00E1A06@smartling.com> <21801512.15438768.1431061902785.JavaMail.zimbra@redhat.com> <10EC04FB-4412-42CF-8745-DB0722D35EF9@smartling.com> <668363196.15440222.1431062895569.JavaMail.zimbra@redhat.com> Message-ID: Thanks for merging everything. Will you merge them into the 1.2.0 branch as well? > On May 8, 2015, at 1:28 AM, Stian Thorgersen wrote: > > > > ----- Original Message ----- >> From: "Scott Rossillo" >> To: "Stian Thorgersen" >> Cc: "keycloak-dev" >> Sent: Friday, 8 May, 2015 7:24:42 AM >> Subject: Re: [keycloak-dev] Spring Security Adapter >> >> Hi Stian, >> >> There?s an example here: https://github.com/foo4u/keycloak-spring-demo >> >> I will look into making them run on Wildfly and contributing them to the >> Keycloak project but it may not make the 1.2.0.Final if that?s going out >> Monday. Also, I need to push an update to them once you merge my PRs. > > Merged and after 1.2.0.Final is no prob. > >> >> As for tests, there?s pretty solid unit test coverage in the module?s test >> folder. However, I?ll look into creating a test suite. These definitely look >> more like integration tests, which are also quite important. Also post >> 1.2.0.Final but definitely something I?ll add. > > We barely have unit tests and try to aim for integration/end-to-end or whatever you'd call it ;) > >> >> ~ Scott >> >> PS - I sent another PR about an hour ago adding a docbook section on using >> the Spring Security adapter. >> >> >>> On May 8, 2015, at 1:11 AM, Stian Thorgersen wrote: >>> >>> Great, thanks for contributing this. Would also be good to have an example >>> and tests (see testsuite which has adapters tests for tomcat, jetty, >>> etc.). >>> >>> ----- Original Message ----- >>>> From: "Scott Rossillo" >>>> To: "keycloak-dev" >>>> Sent: Friday, 8 May, 2015 2:20:00 AM >>>> Subject: [keycloak-dev] Spring Security Adapter >>>> >>>> Hi, >>>> >>>> I sent 3 pull requests that get the Spring Security adapter into shape for >>>> production usage. I started writing the documentation today and will be >>>> sending a PR tomorrow. >>>> >>>> I have one more code related PR tomorrow to set up the default Spring >>>> Security configuration fully so there?s less to document. :) >>>> >>>> Best, >>>> Scott >>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> From srossillo at smartling.com Fri May 8 14:31:09 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Fri, 8 May 2015 14:31:09 -0400 Subject: [keycloak-dev] Back channel logout vs. browser redirect Message-ID: Hi, When developing adapters, is there any benefit to using a browser redirect for logout vs calling: KeycloakDeployment deployment = // get deployment RefreshableKeycloakSecurityContext session = // get session session.logout(deployment); The main reason I ask is that both accomplish the same goal but the back channel method is actually better for integration with Spring Security. Am I losing anything by using the back channel logout method? Best, Scott From stian at redhat.com Mon May 11 01:21:24 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 11 May 2015 01:21:24 -0400 (EDT) Subject: [keycloak-dev] Themes per application In-Reply-To: <554CA8E4.4070508@gmail.com> References: <554BD986.8010406@gmail.com> <1846112137.15439002.1431062086005.JavaMail.zimbra@redhat.com> <554CA8E4.4070508@gmail.com> Message-ID: <864773522.16416947.1431321684171.JavaMail.zimbra@redhat.com> 1 is the best option (well 3 obviously ;)) Beyond making client_id available we're not going to add any specific support for a theme per-client as it just doesn't make sense. Give me a good use-case for it and we can re-consider though. ----- Original Message ----- > From: "Marcio Lima" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Friday, 8 May, 2015 2:15:32 PM > Subject: Re: [keycloak-dev] Themes per application > > Hi Stian, thanks for the quick response! > > I do agree the login happens at Realm level and that shouldn't and won't > change. > However, in my case, the applications in that Realm are different. > > I basically see the following options to workaround it: > > 1. *Create one theme with **<#if>**blocks for each application* > In this case I would need to change this template if a new > application comes in or when something changes in any of the login > pages (blocks). > > 2. *Dinamically load login pages from the theme page** > *I ran this test and it worked just fine, but, I felt like I > shouldn't be doing it this way... bad smell, you know? (:P) > The theme login page loads a static login page of each application > using the *client_id* variable. Then, places the contents on the > current page and sets the necessary elements to Keycloak expected > values (like form action, forgot password and register user links > URLs, error messages, etc). > For each new application, all I have to do is create the static > resources in a */themes/${client_id}* folder, with the correct > element IDs and it does the trick. > Of course there are some drawbacks, but it turns out that I have now > 3 applications using this approach. I wish I could have > per-application themes, rather. > > 3. *Convince my client to use the same login page for all applications** > *This would be the standard approach, but, unfortunatelly, isn't an > option for me. > > Any thoughts on that? > > Thanks in advance. > > Regards, > > Marcio Fernandes de Lima > http://linkedin.com/in/marcioferlan > SCJP, SCWCD, MySQL Core Certified > > On 08/05/2015 02:14, Stian Thorgersen wrote: > > When a user logs in the user logs in to the realm, not the application. So > > it doesn't make sense to have different login pages per application. > > > > ----- Original Message ----- > >> From: "Marcio Lima" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Thursday, 7 May, 2015 11:30:46 PM > >> Subject: [keycloak-dev] Themes per application > >> > >> Hello guys! > >> > >> I'm trying to implement Keycloak in my solution, but it turns out that I > >> need to have a completely different login page per application in the > >> same Realm. Keycloak allows me to create themes, but only at Realm > >> level, not at Application level. > >> > >> How would you guys suggest me approaching this? Any plans to develop > >> such a feature or ways to work around it? > >> > >> Thanks in advance! > >> -- > >> > >> Atenciosamente, > >> > >> Marcio Fernandes de Lima > >> http://linkedin.com/in/marcioferlan > >> SCJP, SCWCD, MySQL Core Certified > >> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > From stian at redhat.com Mon May 11 01:24:41 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 11 May 2015 01:24:41 -0400 (EDT) Subject: [keycloak-dev] Spring Security Adapter In-Reply-To: References: <2392FFB7-1AAE-45C1-8501-77B3B00E1A06@smartling.com> <21801512.15438768.1431061902785.JavaMail.zimbra@redhat.com> <10EC04FB-4412-42CF-8745-DB0722D35EF9@smartling.com> <668363196.15440222.1431062895569.JavaMail.zimbra@redhat.com> Message-ID: <1824083294.16417420.1431321881086.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Scott Rossillo" > To: "Stian Thorgersen" > Cc: "keycloak-dev" > Sent: Friday, 8 May, 2015 4:20:36 PM > Subject: Re: [keycloak-dev] Spring Security Adapter > > Thanks for merging everything. Will you merge them into the 1.2.0 branch as > well? No, bug fixes only in 1.2 branch. > > > > On May 8, 2015, at 1:28 AM, Stian Thorgersen wrote: > > > > > > > > ----- Original Message ----- > >> From: "Scott Rossillo" > >> To: "Stian Thorgersen" > >> Cc: "keycloak-dev" > >> Sent: Friday, 8 May, 2015 7:24:42 AM > >> Subject: Re: [keycloak-dev] Spring Security Adapter > >> > >> Hi Stian, > >> > >> There?s an example here: https://github.com/foo4u/keycloak-spring-demo > >> > >> I will look into making them run on Wildfly and contributing them to the > >> Keycloak project but it may not make the 1.2.0.Final if that?s going out > >> Monday. Also, I need to push an update to them once you merge my PRs. > > > > Merged and after 1.2.0.Final is no prob. > > > >> > >> As for tests, there?s pretty solid unit test coverage in the module?s test > >> folder. However, I?ll look into creating a test suite. These definitely > >> look > >> more like integration tests, which are also quite important. Also post > >> 1.2.0.Final but definitely something I?ll add. > > > > We barely have unit tests and try to aim for integration/end-to-end or > > whatever you'd call it ;) > > > >> > >> ~ Scott > >> > >> PS - I sent another PR about an hour ago adding a docbook section on using > >> the Spring Security adapter. > >> > >> > >>> On May 8, 2015, at 1:11 AM, Stian Thorgersen wrote: > >>> > >>> Great, thanks for contributing this. Would also be good to have an > >>> example > >>> and tests (see testsuite which has adapters tests for tomcat, jetty, > >>> etc.). > >>> > >>> ----- Original Message ----- > >>>> From: "Scott Rossillo" > >>>> To: "keycloak-dev" > >>>> Sent: Friday, 8 May, 2015 2:20:00 AM > >>>> Subject: [keycloak-dev] Spring Security Adapter > >>>> > >>>> Hi, > >>>> > >>>> I sent 3 pull requests that get the Spring Security adapter into shape > >>>> for > >>>> production usage. I started writing the documentation today and will be > >>>> sending a PR tomorrow. > >>>> > >>>> I have one more code related PR tomorrow to set up the default Spring > >>>> Security configuration fully so there?s less to document. :) > >>>> > >>>> Best, > >>>> Scott > >>>> > >>>> > >>>> _______________________________________________ > >>>> keycloak-dev mailing list > >>>> keycloak-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >> > > From stian at redhat.com Mon May 11 01:44:49 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 11 May 2015 01:44:49 -0400 (EDT) Subject: [keycloak-dev] Back channel logout vs. browser redirect In-Reply-To: References: Message-ID: <1682693408.16423942.1431323089597.JavaMail.zimbra@redhat.com> Back channel is better, but for some apps it's not possible (for example client-side/JavaScript). ----- Original Message ----- > From: "Scott Rossillo" > To: "keycloak-dev" > Sent: Friday, 8 May, 2015 8:31:09 PM > Subject: [keycloak-dev] Back channel logout vs. browser redirect > > Hi, > > When developing adapters, is there any benefit to using a browser redirect > for logout vs calling: > > KeycloakDeployment deployment = // get deployment > RefreshableKeycloakSecurityContext session = // get session > session.logout(deployment); > > The main reason I ask is that both accomplish the same goal but the back > channel method is actually better for integration with Spring Security. > > Am I losing anything by using the back channel logout method? > > Best, > Scott > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From thomas.raehalme at codecenter.fi Mon May 11 02:19:15 2015 From: thomas.raehalme at codecenter.fi (Thomas Raehalme) Date: Mon, 11 May 2015 09:19:15 +0300 Subject: [keycloak-dev] Spring Security Adapter In-Reply-To: <1824083294.16417420.1431321881086.JavaMail.zimbra@redhat.com> References: <2392FFB7-1AAE-45C1-8501-77B3B00E1A06@smartling.com> <21801512.15438768.1431061902785.JavaMail.zimbra@redhat.com> <10EC04FB-4412-42CF-8745-DB0722D35EF9@smartling.com> <668363196.15440222.1431062895569.JavaMail.zimbra@redhat.com> <1824083294.16417420.1431321881086.JavaMail.zimbra@redhat.com> Message-ID: Hi! On Mon, May 11, 2015 at 8:24 AM, Stian Thorgersen wrote: > > Thanks for merging everything. Will you merge them into the 1.2.0 branch > as > > well? > > No, bug fixes only in 1.2 branch. > I'd like to thank you guys for the Spring Security adapter, it's looking really good! Since the adapter will not make into the 1.2 release, can you see any problems using the adapter in 1.3 with an earlier Keycloak version? Perhaps separating the adapter releases from the Keycloak application would be something worth considering at some point? Their release cycle is not always related to Keycloak and new adapters could be spawn between Keycloak releases as well. Best regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150511/04410cba/attachment.html From stian at redhat.com Mon May 11 02:39:00 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 11 May 2015 02:39:00 -0400 (EDT) Subject: [keycloak-dev] Spring Security Adapter In-Reply-To: References: <2392FFB7-1AAE-45C1-8501-77B3B00E1A06@smartling.com> <21801512.15438768.1431061902785.JavaMail.zimbra@redhat.com> <10EC04FB-4412-42CF-8745-DB0722D35EF9@smartling.com> <668363196.15440222.1431062895569.JavaMail.zimbra@redhat.com> <1824083294.16417420.1431321881086.JavaMail.zimbra@redhat.com> Message-ID: <1225385070.16479742.1431326340547.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Thomas Raehalme" > To: "keycloak-dev" > Sent: Monday, 11 May, 2015 8:19:15 AM > Subject: Re: [keycloak-dev] Spring Security Adapter > > Hi! > > On Mon, May 11, 2015 at 8:24 AM, Stian Thorgersen < stian at redhat.com > wrote: > > > > Thanks for merging everything. Will you merge them into the 1.2.0 branch as > > well? > > No, bug fixes only in 1.2 branch. > > I'd like to thank you guys for the Spring Security adapter, it's looking > really good! > > Since the adapter will not make into the 1.2 release, can you see any > problems using the adapter in 1.3 with an earlier Keycloak version? Would probably work just fine. We're considering some way to document what adapter versions work with what server version. For now though, only way to make sure is to use same version of server and adapters. > > Perhaps separating the adapter releases from the Keycloak application would > be something worth considering at some point? Their release cycle is not > always related to Keycloak and new adapters could be spawn between Keycloak > releases as well. We're considering doing that > > Best regards, > Thomas > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Mon May 11 06:12:05 2015 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 11 May 2015 12:12:05 +0200 Subject: [keycloak-dev] Node Registration In-Reply-To: References: Message-ID: <55508075.1090109@redhat.com> On 7.5.2015 23:41, Scott Rossillo wrote: > > org.keycloak.adapters.NodesRegistrationManagement doesn?t sent a port > when it registers a node. Additionally, the KC server assumes the > cluster node is using port 8080. So even if you manually register a > node, as say localhost:9092, when you press ?Test Cluster > Availability? the KC server appends port 8080 to the request: > > http://localhost:9092:8080/customer-portal/ > > I think there are two bugs, I can open JIRAs if you like: > > 1. org.keycloak.adapters.NodesRegistrationManagement should send the > port the server is on The JIRA already exists https://issues.jboss.org/browse/KEYCLOAK-888 . However it's quite tricky to add port as requests to cluster are often send via loadbalancer and hence they are on AJP port (like 8009 for example) but for backchannel requests (logout, push not before or test cluster availability etc.) Keycloak needs to send requests to them directly with apache http client (so using port 8080 or 8443). So for now JIRA is postponed until we have important use-case for it. > 2. KC server should not assume port 8080 It doesn't assume 8080 but it just uses the port used in admin URL. It uses admin URL as template, but just replaces the host with the actual registered cluster host. The only limitation is that all cluster hosts need to use same port (Limitation caused by KEYCLOAK-888 ) Marek > > Best, > Scott > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150511/854aa359/attachment.html From bburke at redhat.com Mon May 11 09:29:13 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 11 May 2015 09:29:13 -0400 Subject: [keycloak-dev] auth spi design requirements and initial steps Message-ID: <5550AEA9.1070109@redhat.com> Some generic requirements that will effect the design. 1. Authenticator should be able to be optional per user. i.e. OTP can be optionally set up by the user 2. Multiple authenticators should be resolvable per form. i.e. password, terms and conditions, captcha, and otp could be entered in on one page. 3. Non form based authenticators should be able to bypass any screens if they are the only authenticators. i.e. CLIENT_CERT and KERBEROS. 4. Autheticators need to be able to send challenges after initial request, i.e. Kerberos 5. Clients should be able to specify which Authenticators they require 6. You should be able to attach policies to an Authenticator which allows you to do things like, don't do OTP if you are coming from IP address where you last logged in. 7. Authenticators should be able to plugin in a JAX-RS service that can handle requests for them. 8. Authenticators should be able to specify their display/input page 9. Authenticators can have a "user setup" pages. One for login/registration, one for account service, and one for admin console. Yuck! Design implications: * I think we need to have a AuthenticatorForm as well as an Authenticator interface. * Authenticators would be associated with a AuthenticatorForm. This allows support for multiple Authenticators for one form post. * AuthentictorForms would have an action URL that accepts form input. This form input URL would be referenced by the form name /auth/realms/{realm}/authenticate/forms/{form-name} * AuthenticatorForms would have a name and input/display page. The display page URI can be a relative uri pointing to a theme template, a relative uri that points to an Authenticators JAX-RS service, or an external URI. * A User, per authenticator can be in a SETUP_REQUIRED state. This allows the user to bypass the authenticator and go straight to authenticator setup. * CredentialModel will need generic attributes. Steps? I'm gonna get some abstraction working first with Kerberos, OTP, and Password. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From srossillo at smartling.com Mon May 11 09:42:26 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Mon, 11 May 2015 09:42:26 -0400 Subject: [keycloak-dev] auth spi design requirements and initial steps In-Reply-To: <5550AEA9.1070109@redhat.com> References: <5550AEA9.1070109@redhat.com> Message-ID: <96E58755-24E1-48BA-A821-91202B27D4AB@smartling.com> Is this a reasonable time to consider how impersonation could fit into the auth SPI? > On May 11, 2015, at 9:29 AM, Bill Burke wrote: > > Some generic requirements that will effect the design. > > 1. Authenticator should be able to be optional per user. i.e. OTP can be > optionally set up by the user > 2. Multiple authenticators should be resolvable per form. i.e. password, > terms and conditions, captcha, and otp could be entered in on one page. > 3. Non form based authenticators should be able to bypass any screens if > they are the only authenticators. i.e. CLIENT_CERT and KERBEROS. > 4. Autheticators need to be able to send challenges after initial > request, i.e. Kerberos > 5. Clients should be able to specify which Authenticators they require > 6. You should be able to attach policies to an Authenticator which > allows you to do things like, don't do OTP if you are coming from IP > address where you last logged in. > 7. Authenticators should be able to plugin in a JAX-RS service that can > handle requests for them. > 8. Authenticators should be able to specify their display/input page > 9. Authenticators can have a "user setup" pages. One for > login/registration, one for account service, and one for admin console. > Yuck! > > > > > Design implications: > * I think we need to have a AuthenticatorForm as well as an > Authenticator interface. > * Authenticators would be associated with a AuthenticatorForm. This > allows support for multiple Authenticators for one form post. > * AuthentictorForms would have an action URL that accepts form input. > This form input URL would be referenced by the form name > /auth/realms/{realm}/authenticate/forms/{form-name} > * AuthenticatorForms would have a name and input/display page. The > display page URI can be a relative uri pointing to a theme template, a > relative uri that points to an Authenticators JAX-RS service, or an > external URI. > * A User, per authenticator can be in a SETUP_REQUIRED state. This > allows the user to bypass the authenticator and go straight to > authenticator setup. > * CredentialModel will need generic attributes. > > Steps? > > I'm gonna get some abstraction working first with Kerberos, OTP, and > Password. > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Mon May 11 09:44:55 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 11 May 2015 09:44:55 -0400 (EDT) Subject: [keycloak-dev] auth spi design requirements and initial steps In-Reply-To: <5550AEA9.1070109@redhat.com> References: <5550AEA9.1070109@redhat.com> Message-ID: <1393417933.16793582.1431351895944.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Monday, 11 May, 2015 3:29:13 PM > Subject: [keycloak-dev] auth spi design requirements and initial steps > > Some generic requirements that will effect the design. > > 1. Authenticator should be able to be optional per user. i.e. OTP can be > optionally set up by the user > 2. Multiple authenticators should be resolvable per form. i.e. password, > terms and conditions, captcha, and otp could be entered in on one page. > 3. Non form based authenticators should be able to bypass any screens if > they are the only authenticators. i.e. CLIENT_CERT and KERBEROS. > 4. Autheticators need to be able to send challenges after initial > request, i.e. Kerberos > 5. Clients should be able to specify which Authenticators they require > 6. You should be able to attach policies to an Authenticator which > allows you to do things like, don't do OTP if you are coming from IP > address where you last logged in. Bypassing OTP shouldn't be based on IP. Instead when you do OTP there should be an option to not ask for OTP next time, which sets a cookie. Reasoning behind this is: 1. It's how Google does it ;) 2. IP address for most users are dynamic, and also often shared 3. User should choose not to use OTP next time. This is important as user could be login from a public machine, a friends machine, etc. > 7. Authenticators should be able to plugin in a JAX-RS service that can > handle requests for them. > 8. Authenticators should be able to specify their display/input page > 9. Authenticators can have a "user setup" pages. One for > login/registration, one for account service, and one for admin console. > Yuck! Other things: * Password-less authentication mechanisms (finger scanners, etc.) * Other multi-factor mechanisms (FIDO, SMS, email) * Multiple multi-factor mechanisms for one account (for Red Hat I've got both Google Authenticator and dongle, I use both day to day, but it's also nice to have a backup) * "Detached" flows - for example verify email sends an email with a link, login with email would send a login link, etc.. > > > > > Design implications: > * I think we need to have a AuthenticatorForm as well as an > Authenticator interface. > * Authenticators would be associated with a AuthenticatorForm. This > allows support for multiple Authenticators for one form post. > * AuthentictorForms would have an action URL that accepts form input. > This form input URL would be referenced by the form name > /auth/realms/{realm}/authenticate/forms/{form-name} > * AuthenticatorForms would have a name and input/display page. The > display page URI can be a relative uri pointing to a theme template, a > relative uri that points to an Authenticators JAX-RS service, or an > external URI. > * A User, per authenticator can be in a SETUP_REQUIRED state. This > allows the user to bypass the authenticator and go straight to > authenticator setup. > * CredentialModel will need generic attributes. > > Steps? > > I'm gonna get some abstraction working first with Kerberos, OTP, and > Password. > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bburke at redhat.com Mon May 11 10:09:26 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 11 May 2015 10:09:26 -0400 Subject: [keycloak-dev] auth spi design requirements and initial steps In-Reply-To: <1393417933.16793582.1431351895944.JavaMail.zimbra@redhat.com> References: <5550AEA9.1070109@redhat.com> <1393417933.16793582.1431351895944.JavaMail.zimbra@redhat.com> Message-ID: <5550B816.5070406@redhat.com> On 5/11/2015 9:44 AM, Stian Thorgersen wrote: > > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Monday, 11 May, 2015 3:29:13 PM >> Subject: [keycloak-dev] auth spi design requirements and initial steps >> >> Some generic requirements that will effect the design. >> >> 1. Authenticator should be able to be optional per user. i.e. OTP can be >> optionally set up by the user >> 2. Multiple authenticators should be resolvable per form. i.e. password, >> terms and conditions, captcha, and otp could be entered in on one page. >> 3. Non form based authenticators should be able to bypass any screens if >> they are the only authenticators. i.e. CLIENT_CERT and KERBEROS. >> 4. Autheticators need to be able to send challenges after initial >> request, i.e. Kerberos >> 5. Clients should be able to specify which Authenticators they require >> 6. You should be able to attach policies to an Authenticator which >> allows you to do things like, don't do OTP if you are coming from IP >> address where you last logged in. > > Bypassing OTP shouldn't be based on IP. Instead when you do OTP there should be an option to not ask for OTP next time, which sets a cookie. Reasoning behind this is: > > 1. It's how Google does it ;) > 2. IP address for most users are dynamic, and also often shared > 3. User should choose not to use OTP next time. This is important as user could be login from a public machine, a friends machine, etc. > IP Address can be used to find the user's location. I noticed that World of Warcraft does this. i.e. I didn't have to enter OTP at home, but I did when I traveled (same laptop used). I forgot another one: - Authenticators should be able to add headers to responses i.e. to set a cookie -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From prabhalar at yahoo.com Mon May 11 10:24:47 2015 From: prabhalar at yahoo.com (Raghu Prabhala) Date: Mon, 11 May 2015 10:24:47 -0400 Subject: [keycloak-dev] auth spi design requirements and initial steps In-Reply-To: <5550B816.5070406@redhat.com> References: <5550AEA9.1070109@redhat.com> <1393417933.16793582.1431351895944.JavaMail.zimbra@redhat.com> <5550B816.5070406@redhat.com> Message-ID: Sorry to jump in but Bill just mentioned a real use case within organizations that utilize a risk engine. If I typically login from say USA and one day I login from different country, the risk engine will kick in and based on a policy defined, it may require me to do additional authentication (otp). Similarly there could be a set of black listed IP addresses which may necessitate no access at all or in some cases require multiple authentication steps. Bottom line is a risk engine will determine the authentication steps based on a number of factors including a policy defined for each client app on what is acceptable under what conditions. Sent from my iPhone > On May 11, 2015, at 10:09 AM, Bill Burke wrote: > > > >> On 5/11/2015 9:44 AM, Stian Thorgersen wrote: >> >> >> ----- Original Message ----- >>> From: "Bill Burke" >>> To: keycloak-dev at lists.jboss.org >>> Sent: Monday, 11 May, 2015 3:29:13 PM >>> Subject: [keycloak-dev] auth spi design requirements and initial steps >>> >>> Some generic requirements that will effect the design. >>> >>> 1. Authenticator should be able to be optional per user. i.e. OTP can be >>> optionally set up by the user >>> 2. Multiple authenticators should be resolvable per form. i.e. password, >>> terms and conditions, captcha, and otp could be entered in on one page. >>> 3. Non form based authenticators should be able to bypass any screens if >>> they are the only authenticators. i.e. CLIENT_CERT and KERBEROS. >>> 4. Autheticators need to be able to send challenges after initial >>> request, i.e. Kerberos >>> 5. Clients should be able to specify which Authenticators they require >>> 6. You should be able to attach policies to an Authenticator which >>> allows you to do things like, don't do OTP if you are coming from IP >>> address where you last logged in. >> >> Bypassing OTP shouldn't be based on IP. Instead when you do OTP there should be an option to not ask for OTP next time, which sets a cookie. Reasoning behind this is: >> >> 1. It's how Google does it ;) >> 2. IP address for most users are dynamic, and also often shared >> 3. User should choose not to use OTP next time. This is important as user could be login from a public machine, a friends machine, etc. > > IP Address can be used to find the user's location. I noticed that > World of Warcraft does this. i.e. I didn't have to enter OTP at home, > but I did when I traveled (same laptop used). > > I forgot another one: > > - Authenticators should be able to add headers to responses i.e. to set > a cookie > > > > -- > 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 Tue May 12 02:24:21 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 12 May 2015 02:24:21 -0400 (EDT) Subject: [keycloak-dev] Private/public SPIs In-Reply-To: <2102644065.17431954.1431411705702.JavaMail.zimbra@redhat.com> Message-ID: <1479011433.17432505.1431411861346.JavaMail.zimbra@redhat.com> To make it easy to identify which SPIs are public I've added isPrivate method to SPI. The list below is all the SPIs we currently have, any objections to which are marked as private? SPI Private ------------------------------------- account true client-import true connectionsFile true connectionsHttpClient true connectionsInfinispan true connectionsJpa true connectionsJpaUpdater true connectionsMongo true connectionsMongoUpdater true email true eventsListener false eventsStore true export true identity-provider-mapper false identity_provider false import true login true login-protocol true migration true protocol-mapper false realm true realmCache true social false theme true timer true user true userCache true userFederation false userSessions true well-known true From mposolda at redhat.com Tue May 12 04:47:54 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 12 May 2015 10:47:54 +0200 Subject: [keycloak-dev] Private/public SPIs In-Reply-To: <1479011433.17432505.1431411861346.JavaMail.zimbra@redhat.com> References: <1479011433.17432505.1431411861346.JavaMail.zimbra@redhat.com> Message-ID: <5551BE3A.5010506@redhat.com> No objection. Does private have any limitation from the implementation perspective or is it just a marker? Will user be still able to implement some private SPI and put it into 'providers' folder? Marek On 12.5.2015 08:24, Stian Thorgersen wrote: > To make it easy to identify which SPIs are public I've added isPrivate method to SPI. > > The list below is all the SPIs we currently have, any objections to which are marked as private? > > > SPI Private > ------------------------------------- > account true > client-import true > connectionsFile true > connectionsHttpClient true > connectionsInfinispan true > connectionsJpa true > connectionsJpaUpdater true > connectionsMongo true > connectionsMongoUpdater true > email true > eventsListener false > eventsStore true > export true > identity-provider-mapper false > identity_provider false > import true > login true > login-protocol true > migration true > protocol-mapper false > realm true > realmCache true > social false > theme true > timer true > user true > userCache true > userFederation false > userSessions true > well-known true > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Tue May 12 08:27:57 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 12 May 2015 08:27:57 -0400 (EDT) Subject: [keycloak-dev] Private/public SPIs In-Reply-To: <5551BE3A.5010506@redhat.com> References: <1479011433.17432505.1431411861346.JavaMail.zimbra@redhat.com> <5551BE3A.5010506@redhat.com> Message-ID: <931908081.17733054.1431433677120.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Marek Posolda" > To: "Stian Thorgersen" , "keycloak-dev" > Sent: Tuesday, 12 May, 2015 10:47:54 AM > Subject: Re: [keycloak-dev] Private/public SPIs > > No objection. Does private have any limitation from the implementation > perspective or is it just a marker? Will user be still able to implement > some private SPI and put it into 'providers' folder? Just a marker - maybe we'll add a log warn if someone registers their own provider for a private SPI, but nothing beyond that > > Marek > > On 12.5.2015 08:24, Stian Thorgersen wrote: > > To make it easy to identify which SPIs are public I've added isPrivate > > method to SPI. > > > > The list below is all the SPIs we currently have, any objections to which > > are marked as private? > > > > > > SPI Private > > ------------------------------------- > > account true > > client-import true > > connectionsFile true > > connectionsHttpClient true > > connectionsInfinispan true > > connectionsJpa true > > connectionsJpaUpdater true > > connectionsMongo true > > connectionsMongoUpdater true > > email true > > eventsListener false > > eventsStore true > > export true > > identity-provider-mapper false > > identity_provider false > > import true > > login true > > login-protocol true > > migration true > > protocol-mapper false > > realm true > > realmCache true > > social false > > theme true > > timer true > > user true > > userCache true > > userFederation false > > userSessions true > > well-known true > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > From ssilvert at redhat.com Tue May 12 11:55:43 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 12 May 2015 11:55:43 -0400 Subject: [keycloak-dev] New Keycloak repo in GitHub Message-ID: <5552227F.6040407@redhat.com> Can someone please create a new "elytron" repo under keycloak and give me full rights? This project will contain the new Keycloak/Elytron subsystem, along with Keycloak implementations of Elytron API's, and associated feature packs. Thanks, Stan From bburke at redhat.com Tue May 12 13:33:56 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 12 May 2015 13:33:56 -0400 Subject: [keycloak-dev] New Keycloak repo in GitHub In-Reply-To: <5552227F.6040407@redhat.com> References: <5552227F.6040407@redhat.com> Message-ID: <55523984.1030101@redhat.com> What's the reasoning for a separate repo? On 5/12/2015 11:55 AM, Stan Silvert wrote: > Can someone please create a new "elytron" repo under keycloak and give > me full rights? > > This project will contain the new Keycloak/Elytron subsystem, along with > Keycloak implementations of Elytron API's, and associated feature packs. > > Thanks, > > 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 ssilvert at redhat.com Tue May 12 14:03:39 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 12 May 2015 14:03:39 -0400 Subject: [keycloak-dev] New Keycloak repo in GitHub In-Reply-To: <55523984.1030101@redhat.com> References: <5552227F.6040407@redhat.com> <55523984.1030101@redhat.com> Message-ID: <5552407B.9030400@redhat.com> On 5/12/2015 1:33 PM, Bill Burke wrote: > What's the reasoning for a separate repo? I thought we just discussed this in the meeting, but given the poor audio/video from my internet connection, I'm not surprised you would ask. :-) (I think I have it fixed now, btw) It started with the discussion below. This stuff could go in either WildFly or Keycloak. But WildFly is getting away from having these things in one uber repo. Even Elytron itself is in its own repo. We could put it in Keycloak's repo, but I don't see any advantage. This stuff requires WildFly 10 and Java 8. I'm not sure if we're ready to deal with that in the Keycloak repo yet. But I think the main question is, do we want Keycloak/Elytron integration to be tied to Keycloak releases? If a WildFly release needs something from keycloak-eleytron integration then it's much easier to just do a release of the small repo than to do a full release of the entire Keycloak product. ----- Original Message ----- > From: "Stan Silvert" > To: "Stian Thorgersen" > Cc:mw-security-core at redhat.com > Sent: Tuesday, 12 May, 2015 1:25:15 PM > Subject: Re: Status Report - Week 19 2015 > > On 5/12/2015 7:15 AM, Stian Thorgersen wrote: >> ----- Original Message ----- >>> From: "Stan Silvert" >>> To:mw-security-core at redhat.com >>> Sent: Tuesday, 12 May, 2015 1:11:40 PM >>> Subject: Status Report - Week 19 2015 >>> >>> Accomplishments last week: >>> * Created presentation about feature packs for this week's team meeting >>> * Continue working on new subsystem that only exposes the >>> Keycloak/Elytron realm implementation. >>> * Created feature pack for the new subsystem >> Are these subsystems and feature packs going into Keycloak repo or WF repo? > Keycloak. We're getting away from putting lots of stuff into the WF > repo. Things get developed as independent pieces and then pulled into > the WF build as needed. > > Another alternative might be to put this into its own repo. Sounds like it might be best in a separate repo then. Can you make sure you use keycloak-dev to sync with others around this stuff? We've been missing you on the mailing list > > On 5/12/2015 11:55 AM, Stan Silvert wrote: >> Can someone please create a new "elytron" repo under keycloak and give >> me full rights? >> >> This project will contain the new Keycloak/Elytron subsystem, along with >> Keycloak implementations of Elytron API's, and associated feature packs. >> >> Thanks, >> >> Stan >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From ssilvert at redhat.com Wed May 13 10:06:17 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Wed, 13 May 2015 10:06:17 -0400 Subject: [keycloak-dev] New Keycloak repo in GitHub In-Reply-To: <5552407B.9030400@redhat.com> References: <5552227F.6040407@redhat.com> <55523984.1030101@redhat.com> <5552407B.9030400@redhat.com> Message-ID: <55535A59.4000502@redhat.com> Can we go ahead and make a final decision on this? My code needs a home. :-) On 5/12/2015 2:03 PM, Stan Silvert wrote: > On 5/12/2015 1:33 PM, Bill Burke wrote: >> What's the reasoning for a separate repo? > I thought we just discussed this in the meeting, but given the poor > audio/video from my internet connection, I'm not surprised you would > ask. :-) (I think I have it fixed now, btw) > > It started with the discussion below. This stuff could go in either > WildFly or Keycloak. But WildFly is getting away from having these > things in one uber repo. Even Elytron itself is in its own repo. > > We could put it in Keycloak's repo, but I don't see any advantage. This > stuff requires WildFly 10 and Java 8. I'm not sure if we're ready to > deal with that in the Keycloak repo yet. > > But I think the main question is, do we want Keycloak/Elytron > integration to be tied to Keycloak releases? If a WildFly release needs > something from keycloak-eleytron integration then it's much easier to > just do a release of the small repo than to do a full release of the > entire Keycloak product. > > ----- Original Message ----- > >> From: "Stan Silvert" >> To: "Stian Thorgersen" >> Cc:mw-security-core at redhat.com >> Sent: Tuesday, 12 May, 2015 1:25:15 PM >> Subject: Re: Status Report - Week 19 2015 >> >> On 5/12/2015 7:15 AM, Stian Thorgersen wrote: >>> ----- Original Message ----- >>>> From: "Stan Silvert" >>>> To:mw-security-core at redhat.com >>>> Sent: Tuesday, 12 May, 2015 1:11:40 PM >>>> Subject: Status Report - Week 19 2015 >>>> >>>> Accomplishments last week: >>>> * Created presentation about feature packs for this week's team meeting >>>> * Continue working on new subsystem that only exposes the >>>> Keycloak/Elytron realm implementation. >>>> * Created feature pack for the new subsystem >>> Are these subsystems and feature packs going into Keycloak repo or WF repo? >> Keycloak. We're getting away from putting lots of stuff into the WF >> repo. Things get developed as independent pieces and then pulled into >> the WF build as needed. >> >> Another alternative might be to put this into its own repo. > Sounds like it might be best in a separate repo then. Can you make sure you use keycloak-dev to sync with others around this stuff? We've been missing you on the mailing list > > > >> On 5/12/2015 11:55 AM, Stan Silvert wrote: >>> Can someone please create a new "elytron" repo under keycloak and give >>> me full rights? >>> >>> This project will contain the new Keycloak/Elytron subsystem, along with >>> Keycloak implementations of Elytron API's, and associated feature packs. >>> >>> Thanks, >>> >>> Stan >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Wed May 13 11:38:29 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 13 May 2015 11:38:29 -0400 Subject: [keycloak-dev] New Keycloak repo in GitHub In-Reply-To: <55535A59.4000502@redhat.com> References: <5552227F.6040407@redhat.com> <55523984.1030101@redhat.com> <5552407B.9030400@redhat.com> <55535A59.4000502@redhat.com> Message-ID: <55536FF5.7010402@redhat.com> On 5/13/2015 10:06 AM, Stan Silvert wrote: > Can we go ahead and make a final decision on this? My code needs a > home. :-) > > On 5/12/2015 2:03 PM, Stan Silvert wrote: >> On 5/12/2015 1:33 PM, Bill Burke wrote: >>> What's the reasoning for a separate repo? >> I thought we just discussed this in the meeting, but given the poor >> audio/video from my internet connection, I'm not surprised you would >> ask. :-) (I think I have it fixed now, btw) >> >> It started with the discussion below. This stuff could go in either >> WildFly or Keycloak. But WildFly is getting away from having these >> things in one uber repo. Even Elytron itself is in its own repo. >> >> We could put it in Keycloak's repo, but I don't see any advantage. This >> stuff requires WildFly 10 and Java 8. I'm not sure if we're ready to >> deal with that in the Keycloak repo yet. >> Why keep it in the same repo? * Its easier for development. You import one pom.xml and then everything is loaded. You make a refactor in a core class, and you see the effects everywhere. * We know pull requests don't undermine any keycloak modules. With separate repos, a PR to keycloak/keycloak could pass the CI build and be merged, but break keycloak/elytron. >> But I think the main question is, do we want Keycloak/Elytron >> integration to be tied to Keycloak releases? If a WildFly release needs >> something from keycloak-eleytron integration then it's much easier to >> just do a release of the small repo than to do a full release of the >> entire Keycloak product. >> THere is nothing stopping us from doing an adapter only release if there is only one repo. You can branch from a tag, do the changes, do the adapter-only release, merge branch into main. Wildfly is composed of projects from a variety of teams. Keycloak is a one project one team. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From ssilvert at redhat.com Thu May 14 12:31:38 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Thu, 14 May 2015 12:31:38 -0400 Subject: [keycloak-dev] Am I doing this right? Message-ID: <5554CDEA.10801@redhat.com> Temporary home for Keycloak/Elytron integration is here: https://github.com/ssilvert/keycloak-elytron-temp In looking back over it, I realize I need to ask some general questions. The way the initial realm implementation works is that I implement the Elytron realm interface. Whenever Elytron asks for a user authentication, it calls out to a Keycloak server to validate credentials. The way I'm doing that right now is to use a Direct Access Grant. I adapted some of Bill's code for this purpose: https://github.com/ssilvert/keycloak-elytron-temp/blob/master/realm-impl/src/main/java/org/keycloak/elytron/realm/DirectGrantLogin.java On the Keycloak side, this requires allowing direct access grants on the realm and defining a direct access client. Is there any reason why someone would not want to do this? If so, should I provide some alternate means of authentication? Stan From srossillo at smartling.com Thu May 14 21:59:11 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Thu, 14 May 2015 21:59:11 -0400 Subject: [keycloak-dev] Import Realm when running Keycloak server from Maven Message-ID: Hi, We?re trying to run Keycloak from Maven using: mvn -f testsuite/integration/pom.xml exec:java -Pkeycloak-server -Dkeycloak.port=8080 For development purposes. We saw in the code that you can specify a realm to import. It seems either: mvn -f testsuite/integration/pom.xml exec:java -Pkeycloak-server -Dkeycloak.port=8080 -Dimport=/path/to/realm.json should work. However, we get an exception: 21:58:22,028 DEBUG [org.keycloak.models.utils.RepresentationToModel] Create client: {0}security-admin-console [WARNING] java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:293) at java.lang.Thread.run(Thread.java:745) Caused by: org.keycloak.models.ModelDuplicateException: javax.persistence.PersistenceException: org.hibernate.exception.ConstraintViolationException: Unique index or primary key violation: "UK_B71CJLBENV945RB6GCON438AT_INDEX_4 ON PUBLIC.CLIENT(REALM_ID, CLIENT_ID)"; SQL statement: insert into CLIENT (BASE_URL, BEARER_ONLY, CLIENT_ID, CONSENT_REQUIRED, DIRECT_GRANTS_ONLY, ENABLED, FRONTCHANNEL_LOGOUT, FULL_SCOPE_ALLOWED, MANAGEMENT_URL, NAME, NODE_REREG_TIMEOUT, NOT_BEFORE, PROTOCOL, PUBLIC_CLIENT, REALM_ID, SECRET, SURROGATE_AUTH_REQUIRED, ID) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) [23505-168] at org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:40) at org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:34) at com.sun.proxy.$Proxy61.flush(Unknown Source) at org.keycloak.models.jpa.RealmAdapter.addClient(RealmAdapter.java:643) at org.keycloak.models.utils.RepresentationToModel.createClient(RepresentationToModel.java:525) at org.keycloak.models.utils.RepresentationToModel.createClients(RepresentationToModel.java:509) at org.keycloak.models.utils.RepresentationToModel.importRealm(RepresentationToModel.java:136) at org.keycloak.services.managers.RealmManager.importRealm(RealmManager.java:252) at org.keycloak.testsuite.KeycloakServer.importRealm(KeycloakServer.java:250) at org.keycloak.testsuite.KeycloakServer.importRealm(KeycloakServer.java:230) at org.keycloak.testsuite.KeycloakServer.bootstrapKeycloakServer(KeycloakServer.java:189) at org.keycloak.testsuite.KeycloakServer.main(KeycloakServer.java:108) ... 6 more Caused by: javax.persistence.PersistenceException: org.hibernate.exception.ConstraintViolationException: Unique index or primary key violation: "UK_B71CJLBENV945RB6GCON438AT_INDEX_4 ON PUBLIC.CLIENT(REALM_ID, CLIENT_ID)"; SQL statement: insert into CLIENT (BASE_URL, BEARER_ONLY, CLIENT_ID, CONSENT_REQUIRED, DIRECT_GRANTS_ONLY, ENABLED, FRONTCHANNEL_LOGOUT, FULL_SCOPE_ALLOWED, MANAGEMENT_URL, NAME, NODE_REREG_TIMEOUT, NOT_BEFORE, PROTOCOL, PUBLIC_CLIENT, REALM_ID, SECRET, SURROGATE_AUTH_REQUIRED, ID) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) [23505-168] at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1361) at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1289) at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1295) at org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:976) at sun.reflect.GeneratedMethodAccessor273.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:32) ... 16 more Caused by: org.hibernate.exception.ConstraintViolationException: Unique index or primary key violation: "UK_B71CJLBENV945RB6GCON438AT_INDEX_4 ON PUBLIC.CLIENT(REALM_ID, CLIENT_ID)"; SQL statement: insert into CLIENT (BASE_URL, BEARER_ONLY, CLIENT_ID, CONSENT_REQUIRED, DIRECT_GRANTS_ONLY, ENABLED, FRONTCHANNEL_LOGOUT, FULL_SCOPE_ALLOWED, MANAGEMENT_URL, NAME, NODE_REREG_TIMEOUT, NOT_BEFORE, PROTOCOL, PUBLIC_CLIENT, REALM_ID, SECRET, SURROGATE_AUTH_REQUIRED, ID) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) [23505-168] at org.hibernate.exception.internal.SQLStateConversionDelegate.convert(SQLStateConversionDelegate.java:128) at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:47) at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:125) at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:110) at org.hibernate.engine.jdbc.internal.proxy.AbstractStatementProxyHandler.continueInvocation(AbstractStatementProxyHandler.java:129) at org.hibernate.engine.jdbc.internal.proxy.AbstractProxyHandler.invoke(AbstractProxyHandler.java:81) at com.sun.proxy.$Proxy63.executeUpdate(Unknown Source) at org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:56) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2849) at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3290) at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:80) at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:272) at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:264) at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:186) at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:326) at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1081) at org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:973) ... 20 more Caused by: org.h2.jdbc.JdbcSQLException: Unique index or primary key violation: "UK_B71CJLBENV945RB6GCON438AT_INDEX_4 ON PUBLIC.CLIENT(REALM_ID, CLIENT_ID)"; SQL statement: insert into CLIENT (BASE_URL, BEARER_ONLY, CLIENT_ID, CONSENT_REQUIRED, DIRECT_GRANTS_ONLY, ENABLED, FRONTCHANNEL_LOGOUT, FULL_SCOPE_ALLOWED, MANAGEMENT_URL, NAME, NODE_REREG_TIMEOUT, NOT_BEFORE, PROTOCOL, PUBLIC_CLIENT, REALM_ID, SECRET, SURROGATE_AUTH_REQUIRED, ID) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) [23505-168] at org.h2.message.DbException.getJdbcSQLException(DbException.java:329) at org.h2.message.DbException.get(DbException.java:169) at org.h2.message.DbException.get(DbException.java:146) at org.h2.index.BaseIndex.getDuplicateKeyException(BaseIndex.java:81) at org.h2.index.TreeIndex.add(TreeIndex.java:62) at org.h2.table.RegularTable.addRow(RegularTable.java:121) at org.h2.command.dml.Insert.insertRows(Insert.java:124) at org.h2.command.dml.Insert.update(Insert.java:84) at org.h2.command.CommandContainer.update(CommandContainer.java:75) at org.h2.command.Command.executeUpdate(Command.java:230) at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:156) at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:142) at sun.reflect.GeneratedMethodAccessor271.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.hibernate.engine.jdbc.internal.proxy.AbstractStatementProxyHandler.continueInvocation(AbstractStatementProxyHandler.java:122) ... 33 more -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150514/72a0aa8a/attachment-0001.html From srossillo at smartling.com Thu May 14 22:13:21 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Thu, 14 May 2015 22:13:21 -0400 Subject: [keycloak-dev] Import Realm when running Keycloak server from Maven In-Reply-To: References: Message-ID: Never mind, a colleague of mine figured it out. Just an FYI for anyone who hits the same problem: the realm to import had to be exported from 1.2.0.CR1. We were trying to import a realm file created by an older Keycloak version. :) Thanks, Scott > On May 14, 2015, at 9:59 PM, Scott Rossillo wrote: > > Hi, > > We?re trying to run Keycloak from Maven using: > > mvn -f testsuite/integration/pom.xml exec:java -Pkeycloak-server -Dkeycloak.port=8080 > > For development purposes. We saw in the code that you can specify a realm to import. It seems either: > > mvn -f testsuite/integration/pom.xml exec:java -Pkeycloak-server -Dkeycloak.port=8080 -Dimport=/path/to/realm.json > > should work. However, we get an exception: > > 21:58:22,028 DEBUG [org.keycloak.models.utils.RepresentationToModel] Create client: {0}security-admin-console > [WARNING] > java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:293) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.keycloak.models.ModelDuplicateException: javax.persistence.PersistenceException: org.hibernate.exception.ConstraintViolationException: Unique index or primary key violation: "UK_B71CJLBENV945RB6GCON438AT_INDEX_4 ON PUBLIC.CLIENT(REALM_ID, CLIENT_ID)"; SQL statement: > insert into CLIENT (BASE_URL, BEARER_ONLY, CLIENT_ID, CONSENT_REQUIRED, DIRECT_GRANTS_ONLY, ENABLED, FRONTCHANNEL_LOGOUT, FULL_SCOPE_ALLOWED, MANAGEMENT_URL, NAME, NODE_REREG_TIMEOUT, NOT_BEFORE, PROTOCOL, PUBLIC_CLIENT, REALM_ID, SECRET, SURROGATE_AUTH_REQUIRED, ID) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) [23505-168] > at org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:40) > at org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:34) > at com.sun.proxy.$Proxy61.flush(Unknown Source) > at org.keycloak.models.jpa.RealmAdapter.addClient(RealmAdapter.java:643) > at org.keycloak.models.utils.RepresentationToModel.createClient(RepresentationToModel.java:525) > at org.keycloak.models.utils.RepresentationToModel.createClients(RepresentationToModel.java:509) > at org.keycloak.models.utils.RepresentationToModel.importRealm(RepresentationToModel.java:136) > at org.keycloak.services.managers.RealmManager.importRealm(RealmManager.java:252) > at org.keycloak.testsuite.KeycloakServer.importRealm(KeycloakServer.java:250) > at org.keycloak.testsuite.KeycloakServer.importRealm(KeycloakServer.java:230) > at org.keycloak.testsuite.KeycloakServer.bootstrapKeycloakServer(KeycloakServer.java:189) > at org.keycloak.testsuite.KeycloakServer.main(KeycloakServer.java:108) > ... 6 more > Caused by: javax.persistence.PersistenceException: org.hibernate.exception.ConstraintViolationException: Unique index or primary key violation: "UK_B71CJLBENV945RB6GCON438AT_INDEX_4 ON PUBLIC.CLIENT(REALM_ID, CLIENT_ID)"; SQL statement: > insert into CLIENT (BASE_URL, BEARER_ONLY, CLIENT_ID, CONSENT_REQUIRED, DIRECT_GRANTS_ONLY, ENABLED, FRONTCHANNEL_LOGOUT, FULL_SCOPE_ALLOWED, MANAGEMENT_URL, NAME, NODE_REREG_TIMEOUT, NOT_BEFORE, PROTOCOL, PUBLIC_CLIENT, REALM_ID, SECRET, SURROGATE_AUTH_REQUIRED, ID) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) [23505-168] > at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1361) > at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1289) > at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1295) > at org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:976) > at sun.reflect.GeneratedMethodAccessor273.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:32) > ... 16 more > Caused by: org.hibernate.exception.ConstraintViolationException: Unique index or primary key violation: "UK_B71CJLBENV945RB6GCON438AT_INDEX_4 ON PUBLIC.CLIENT(REALM_ID, CLIENT_ID)"; SQL statement: > insert into CLIENT (BASE_URL, BEARER_ONLY, CLIENT_ID, CONSENT_REQUIRED, DIRECT_GRANTS_ONLY, ENABLED, FRONTCHANNEL_LOGOUT, FULL_SCOPE_ALLOWED, MANAGEMENT_URL, NAME, NODE_REREG_TIMEOUT, NOT_BEFORE, PROTOCOL, PUBLIC_CLIENT, REALM_ID, SECRET, SURROGATE_AUTH_REQUIRED, ID) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) [23505-168] > at org.hibernate.exception.internal.SQLStateConversionDelegate.convert(SQLStateConversionDelegate.java:128) > at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:47) > at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:125) > at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:110) > at org.hibernate.engine.jdbc.internal.proxy.AbstractStatementProxyHandler.continueInvocation(AbstractStatementProxyHandler.java:129) > at org.hibernate.engine.jdbc.internal.proxy.AbstractProxyHandler.invoke(AbstractProxyHandler.java:81) > at com.sun.proxy.$Proxy63.executeUpdate(Unknown Source) > at org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:56) > at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2849) > at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3290) > at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:80) > at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:272) > at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:264) > at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:186) > at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:326) > at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) > at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1081) > at org.hibernate.ejb.AbstractEntityManagerImpl.flush(AbstractEntityManagerImpl.java:973) > ... 20 more > Caused by: org.h2.jdbc.JdbcSQLException: Unique index or primary key violation: "UK_B71CJLBENV945RB6GCON438AT_INDEX_4 ON PUBLIC.CLIENT(REALM_ID, CLIENT_ID)"; SQL statement: > insert into CLIENT (BASE_URL, BEARER_ONLY, CLIENT_ID, CONSENT_REQUIRED, DIRECT_GRANTS_ONLY, ENABLED, FRONTCHANNEL_LOGOUT, FULL_SCOPE_ALLOWED, MANAGEMENT_URL, NAME, NODE_REREG_TIMEOUT, NOT_BEFORE, PROTOCOL, PUBLIC_CLIENT, REALM_ID, SECRET, SURROGATE_AUTH_REQUIRED, ID) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) [23505-168] > at org.h2.message.DbException.getJdbcSQLException(DbException.java:329) > at org.h2.message.DbException.get(DbException.java:169) > at org.h2.message.DbException.get(DbException.java:146) > at org.h2.index.BaseIndex.getDuplicateKeyException(BaseIndex.java:81) > at org.h2.index.TreeIndex.add(TreeIndex.java:62) > at org.h2.table.RegularTable.addRow(RegularTable.java:121) > at org.h2.command.dml.Insert.insertRows(Insert.java:124) > at org.h2.command.dml.Insert.update(Insert.java:84) > at org.h2.command.CommandContainer.update(CommandContainer.java:75) > at org.h2.command.Command.executeUpdate(Command.java:230) > at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:156) > at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:142) > at sun.reflect.GeneratedMethodAccessor271.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.hibernate.engine.jdbc.internal.proxy.AbstractStatementProxyHandler.continueInvocation(AbstractStatementProxyHandler.java:122) > ... 33 more > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150514/cd92ac47/attachment-0001.html From mposolda at redhat.com Fri May 15 01:35:44 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 15 May 2015 07:35:44 +0200 Subject: [keycloak-dev] [keycloak-user] Keycloak documentation In-Reply-To: References: Message-ID: <555585B0.9040701@redhat.com> Hi, Keycloak implements OpenID Connect and SAML specifications from both client and server perspective. You can find some diagrams related to those specs on the web. Client (adapters) code is inside "integration" module and it's submodules. Then in "core" module is some shared code for both adapters and server. The rest of the code are mainly server parts. For the server, you can start to look at KeycloakApplication class, which is entry point where are registered REST resources and KeycloakSessionFactory, which registers SPIs. That's for the start. For the rest, I would suggest to dig into code, debug and see how it works :-) ah, and some startup docs for developers is also in readme files under "misc" directory (you can take a look at least to HackingOnKeycloak.md and Testsuite.md ). Good luck:-) Marek On 15.5.2015 06:41, Carlos Feria wrote: > > Hello. I'm using keycloak in my projects, it is a great solution. > > I'd would like to find some documentation of the structure or > architecture of keycloak, something like uml diagrams or any > documentation for developers not only for users... > > i'm trying to review the code for learn how keycloak works internally. > Please, anybody could tell me if exists anything like. > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150515/93e5310a/attachment.html From ssilvert at redhat.com Fri May 15 08:36:55 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 15 May 2015 08:36:55 -0400 Subject: [keycloak-dev] Thoughts on Keycloak CLI Message-ID: <5555E867.4020703@redhat.com> I've been giving some thought to the Keycloak integration with WildFly CLI. There are two designs. Both involve a subsystem called "kcrest" with a resource called "server". You can define a server to talk to using these three attributes: base-url ( value is something like http://localhost:8080/auth/admin/realms) username password username and password are optional. If you don't mind having these values stored in standalone.xml/domain.xml you can specify them. That way, you don't have to include them with each request. *Design #1: Implement all of the Keycloak REST API in CLI *We build out resources for each REST path and put them in the management model. Then build out operations for everything. So a CLI session to create a client called "myclient" might look like this: cd /subsystem=kcrest/server=foo cd realm=myrealm clients=myclient:add(enabled=true) *Design #2: Create a single generic operation that closely mimics the REST API* cd /subsystem=kcrest/server=foo :submit(method=POST, path=/myrealm/clients,params={"clientId"=>"myclient","enabled"=>"true"}) * **Advantages of Design #1* * Looks and behaves just like other CLI resources * Uses standard CLI operations * Each resource and operation can contain help text * Everything can be navigated from CLI command line or CLI GUI tree, making it easy to browse the model *Disadvantages of Design #1** * * It might take a very long time to implement (2-3 months?) * Ongoing maintenance. Every time REST API changes, you have to update subsystem code *Advantages of Design #2 * * Quick to implement (2-3 weeks) * Always works despite REST API changes *Disadvantages of Design #2 * * :submit operations get long and ugly * Can't specify help text for each resource * Hard to browse the model. Need to submit "list" style REST invocations. Note that it might be possible to auto-generate Design #1. If so, it would be the best of both worlds. Whoever implements this should probably start with Design #2 and then spend some time researching auto-generation of Design #1. Other thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150515/445e68d7/attachment.html From mstrukel at redhat.com Mon May 18 09:46:50 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Mon, 18 May 2015 09:46:50 -0400 (EDT) Subject: [keycloak-dev] Do we really want to keep support for Wildfly 8.2.0.Final In-Reply-To: <685212610.451225.1431955153082.JavaMail.zimbra@redhat.com> Message-ID: <431362903.475583.1431956810728.JavaMail.zimbra@redhat.com> In recent weeks I upgraded Wildfly version we use for server distro to 9.0.0.CR1 in order to be up to date with latest subsystem APIs. That was accompanied by server / adapter subsystem split, and code cleanup that fixed deprecated uses of Wildfly subsystems APIs. It also resulted in dropped support for EAP6 within keycloak-wildfly-adapter-susbsystem. I've been working on putting EAP6 support into keycloak-as7-subsystem, and that seems to work fine. We thus have adapter support for WF9, and EAP7 via wildfly-adapter-subsystem, and adapter support for AS7, and EAP6 via as7-subsystem. That leaves out WF8. Since it uses undertow, it makes no sense to try put it into as7-subsystem, and since it uses APIs deprecated in WF9 it makes no sense to put it into wildfly-adapter-subsystem as that would require again messing up the just-cleaned-up subsystems code. There's another issue that's specific to WF8 - org.apache.httpcomponents slot=4.3. That complicates the modules build, and the examples build. Manually testing AS7, EAP6, WF9 using unconfigured-demo I was constantly bumping into mismatches between jboss-deployment-structure.xml in demos and the modules in the server. It makes no sense to bundle org.apache.httpcomponents slot=4.3 with WF9, but we have to bundle them with WF8. Current build does not solve this issue yet. I have a solution in the works, but maybe we want to decide not to support WF 8 at all. For all practical purposes WF 9.0.0.CR1 is equivalent and better than 8.2.0.Final so I see no reason why people couldn't upgrade other then maybe emotional attachment to .Final in the version. What do the rest of you think? Am I missing something? From bburke at redhat.com Mon May 18 13:27:27 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 18 May 2015 13:27:27 -0400 Subject: [keycloak-dev] Do we really want to keep support for Wildfly 8.2.0.Final In-Reply-To: <431362903.475583.1431956810728.JavaMail.zimbra@redhat.com> References: <431362903.475583.1431956810728.JavaMail.zimbra@redhat.com> Message-ID: <555A20FF.1080904@redhat.com> We will retain AS7, EAP6, Wildfly 8.x, and Wildfly 9 adapters. On 5/18/2015 9:46 AM, Marko Strukelj wrote: > > In recent weeks I upgraded Wildfly version we use for server distro to 9.0.0.CR1 in order to be up to date with latest subsystem APIs. That was accompanied by server / adapter subsystem split, and code cleanup that fixed deprecated uses of Wildfly subsystems APIs. It also resulted in dropped support for EAP6 within keycloak-wildfly-adapter-susbsystem. > > I've been working on putting EAP6 support into keycloak-as7-subsystem, and that seems to work fine. > > We thus have adapter support for WF9, and EAP7 via wildfly-adapter-subsystem, and adapter support for AS7, and EAP6 via as7-subsystem. > > That leaves out WF8. Since it uses undertow, it makes no sense to try put it into as7-subsystem, and since it uses APIs deprecated in WF9 it makes no sense to put it into wildfly-adapter-subsystem as that would require again messing up the just-cleaned-up subsystems code. > > There's another issue that's specific to WF8 - org.apache.httpcomponents slot=4.3. That complicates the modules build, and the examples build. Manually testing AS7, EAP6, WF9 using unconfigured-demo I was constantly bumping into mismatches between jboss-deployment-structure.xml in demos and the modules in the server. > > It makes no sense to bundle org.apache.httpcomponents slot=4.3 with WF9, but we have to bundle them with WF8. Current build does not solve this issue yet. I have a solution in the works, but maybe we want to decide not to support WF 8 at all. For all practical purposes WF 9.0.0.CR1 is equivalent and better than 8.2.0.Final so I see no reason why people couldn't upgrade other then maybe emotional attachment to .Final in the version. > > What do the rest of you think? Am I missing something? > _______________________________________________ > 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 May 18 14:38:40 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Mon, 18 May 2015 14:38:40 -0400 Subject: [keycloak-dev] Thoughts on Keycloak CLI In-Reply-To: <5555E867.4020703@redhat.com> References: <5555E867.4020703@redhat.com> Message-ID: <555A31B0.907@redhat.com> BTW, I've got some down time waiting on Elytron, so I've decided to do a quickie implementation of #2 to see how it goes. On 5/15/2015 8:36 AM, Stan Silvert wrote: > I've been giving some thought to the Keycloak integration with WildFly > CLI. There are two designs. Both involve a subsystem called "kcrest" > with a resource called "server". You can define a server to talk to > using these three attributes: > base-url ( value is something like > http://localhost:8080/auth/admin/realms) > username > password > > username and password are optional. If you don't mind having these > values stored in standalone.xml/domain.xml you can specify them. That > way, you don't have to include them with each request. > > *Design #1: Implement all of the Keycloak REST API in CLI > *We build out resources for each REST path and put them in the > management model. Then build out operations for everything. So a CLI > session to create a client called "myclient" might look like this: > cd /subsystem=kcrest/server=foo > cd realm=myrealm > clients=myclient:add(enabled=true) > > *Design #2: Create a single generic operation that closely mimics the > REST API* > cd /subsystem=kcrest/server=foo > :submit(method=POST, > path=/myrealm/clients,params={"clientId"=>"myclient","enabled"=>"true"}) > * > **Advantages of Design #1* > > * Looks and behaves just like other CLI resources > * Uses standard CLI operations > * Each resource and operation can contain help text > * Everything can be navigated from CLI command line or CLI GUI tree, > making it easy to browse the model > > *Disadvantages of Design #1** > * > > * It might take a very long time to implement (2-3 months?) > * Ongoing maintenance. Every time REST API changes, you have to > update subsystem code > > *Advantages of Design #2 > * > > * Quick to implement (2-3 weeks) > * Always works despite REST API changes > > *Disadvantages of Design #2 > * > > * :submit operations get long and ugly > * Can't specify help text for each resource > * Hard to browse the model. Need to submit "list" style REST > invocations. > > Note that it might be possible to auto-generate Design #1. If so, it > would be the best of both worlds. > > Whoever implements this should probably start with Design #2 and then > spend some time researching auto-generation of Design #1. > > Other thoughts? > > > > _______________________________________________ > 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/20150518/1dd75449/attachment.html From stian at redhat.com Tue May 19 02:22:53 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 19 May 2015 02:22:53 -0400 (EDT) Subject: [keycloak-dev] Thoughts on Keycloak CLI In-Reply-To: <555A31B0.907@redhat.com> References: <5555E867.4020703@redhat.com> <555A31B0.907@redhat.com> Message-ID: <1696523919.1386139.1432016573984.JavaMail.zimbra@redhat.com> I'm not a big fan of Design #2, sounds like it's going to be pretty much useless. We should do it properly if we/when we do it. DMR/CLI is hard enough to use as it is! The first priority for CLI is to have support to reset admin password and to do import/export, not the admin endpoints. We also need to make sure we can authenticate properly using Keycloak. ----- Original Message ----- > From: "Stan Silvert" > To: keycloak-dev at lists.jboss.org > Sent: Monday, 18 May, 2015 8:38:40 PM > Subject: Re: [keycloak-dev] Thoughts on Keycloak CLI > > BTW, I've got some down time waiting on Elytron, so I've decided to do a > quickie implementation of #2 to see how it goes. > > On 5/15/2015 8:36 AM, Stan Silvert wrote: > > > I've been giving some thought to the Keycloak integration with WildFly CLI. > There are two designs. Both involve a subsystem called "kcrest" with a > resource called "server". You can define a server to talk to using these > three attributes: > base-url ( value is something like http://localhost:8080/auth/admin/realms ) > username > password > > username and password are optional. If you don't mind having these values > stored in standalone.xml/domain.xml you can specify them. That way, you > don't have to include them with each request. > > Design #1: Implement all of the Keycloak REST API in CLI > We build out resources for each REST path and put them in the management > model. Then build out operations for everything. So a CLI session to create > a client called "myclient" might look like this: > cd /subsystem=kcrest/server=foo > cd realm=myrealm > clients=myclient:add(enabled=true) > > Design #2: Create a single generic operation that closely mimics the REST API > cd /subsystem=kcrest/server=foo > :submit(method=POST, > path=/myrealm/clients,params={"clientId"=>"myclient","enabled"=>"true"}) > > Advantages of Design #1 > > > * Looks and behaves just like other CLI resources > * Uses standard CLI operations > * Each resource and operation can contain help text > * Everything can be navigated from CLI command line or CLI GUI tree, > making it easy to browse the model > > > Disadvantages of Design #1 > > > * It might take a very long time to implement (2-3 months?) > * Ongoing maintenance. Every time REST API changes, you have to update > subsystem code > > > Advantages of Design #2 > > > * Quick to implement (2-3 weeks) > * Always works despite REST API changes > > > Disadvantages of Design #2 > > > * :submit operations get long and ugly > * Can't specify help text for each resource > * Hard to browse the model. Need to submit "list" style REST invocations. > > > Note that it might be possible to auto-generate Design #1. If so, it would be > the best of both worlds. > > > Whoever implements this should probably start with Design #2 and then spend > some time researching auto-generation of Design #1. > > > Other thoughts? > > > _______________________________________________ > keycloak-dev mailing list keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Tue May 19 05:44:20 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 19 May 2015 05:44:20 -0400 (EDT) Subject: [keycloak-dev] Update admin rest api to always use ids in paths In-Reply-To: <692831146.1520171.1432028562292.JavaMail.zimbra@redhat.com> Message-ID: <1669528382.1520815.1432028660423.JavaMail.zimbra@redhat.com> Currently we use a mix between name and ids in paths for admin rest api. For consistency we should always use ids in paths. This is required by admin events (otherwise we require a lot of work-around to set the resource path). From mposolda at redhat.com Tue May 19 07:57:07 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 19 May 2015 13:57:07 +0200 Subject: [keycloak-dev] Update admin rest api to always use ids in paths In-Reply-To: <1669528382.1520815.1432028660423.JavaMail.zimbra@redhat.com> References: <1669528382.1520815.1432028660423.JavaMail.zimbra@redhat.com> Message-ID: <555B2513.1090600@redhat.com> +1 There is just one small issue that URLs are not so nice like with names. But we already use ids on some places and it's good to be consistent. Marek On 19.5.2015 11:44, Stian Thorgersen wrote: > Currently we use a mix between name and ids in paths for admin rest api. For consistency we should always use ids in paths. > > This is required by admin events (otherwise we require a lot of work-around to set the resource path). > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Tue May 19 08:02:20 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 19 May 2015 08:02:20 -0400 (EDT) Subject: [keycloak-dev] Keycloak 1.2.0.Final released In-Reply-To: <835789693.1573810.1432036881644.JavaMail.zimbra@redhat.com> Message-ID: <815638486.1574215.1432036940104.JavaMail.zimbra@redhat.com> No major changes since 1.2.0.CR1 only some minor bug fixes. For full details see https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12313920&version=12327255 and to download go to https://sourceforge.net/projects/keycloak/files/1.2.0.Final/. From ssilvert at redhat.com Tue May 19 08:11:48 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 19 May 2015 08:11:48 -0400 Subject: [keycloak-dev] Thoughts on Keycloak CLI In-Reply-To: <1696523919.1386139.1432016573984.JavaMail.zimbra@redhat.com> References: <5555E867.4020703@redhat.com> <555A31B0.907@redhat.com> <1696523919.1386139.1432016573984.JavaMail.zimbra@redhat.com> Message-ID: <555B2884.9060900@redhat.com> On 5/19/2015 2:22 AM, Stian Thorgersen wrote: > I'm not a big fan of Design #2, sounds like it's going to be pretty much useless. #2 gives you an easy way to execute the REST API from the command line or via a CLI script. Surely, that's a useful feature to have. > We should do it properly if we/when we do it. DMR/CLI is hard enough to use as it is! #1 is prettier. #2 is more raw. I don't see why we wouldn't have both eventually. I'm halfway done with #2. It's easy to implement and having it is better than not having it. Plus, having #2 will make it easier to implement #1. Are you still thinking we should have our own proprietary CLI instead? > > The first priority for CLI is to have support to reset admin password and to do import/export, not the admin endpoints. Is reset admin password not allowed from the REST API? > We also need to make sure we can authenticate properly using Keycloak. I'm not sure what you mean by this. Can you elaborate? > > ----- Original Message ----- >> From: "Stan Silvert" >> To: keycloak-dev at lists.jboss.org >> Sent: Monday, 18 May, 2015 8:38:40 PM >> Subject: Re: [keycloak-dev] Thoughts on Keycloak CLI >> >> BTW, I've got some down time waiting on Elytron, so I've decided to do a >> quickie implementation of #2 to see how it goes. >> >> On 5/15/2015 8:36 AM, Stan Silvert wrote: >> >> >> I've been giving some thought to the Keycloak integration with WildFly CLI. >> There are two designs. Both involve a subsystem called "kcrest" with a >> resource called "server". You can define a server to talk to using these >> three attributes: >> base-url ( value is something like http://localhost:8080/auth/admin/realms ) >> username >> password >> >> username and password are optional. If you don't mind having these values >> stored in standalone.xml/domain.xml you can specify them. That way, you >> don't have to include them with each request. >> >> Design #1: Implement all of the Keycloak REST API in CLI >> We build out resources for each REST path and put them in the management >> model. Then build out operations for everything. So a CLI session to create >> a client called "myclient" might look like this: >> cd /subsystem=kcrest/server=foo >> cd realm=myrealm >> clients=myclient:add(enabled=true) >> >> Design #2: Create a single generic operation that closely mimics the REST API >> cd /subsystem=kcrest/server=foo >> :submit(method=POST, >> path=/myrealm/clients,params={"clientId"=>"myclient","enabled"=>"true"}) >> >> Advantages of Design #1 >> >> >> * Looks and behaves just like other CLI resources >> * Uses standard CLI operations >> * Each resource and operation can contain help text >> * Everything can be navigated from CLI command line or CLI GUI tree, >> making it easy to browse the model >> >> >> Disadvantages of Design #1 >> >> >> * It might take a very long time to implement (2-3 months?) >> * Ongoing maintenance. Every time REST API changes, you have to update >> subsystem code >> >> >> Advantages of Design #2 >> >> >> * Quick to implement (2-3 weeks) >> * Always works despite REST API changes >> >> >> Disadvantages of Design #2 >> >> >> * :submit operations get long and ugly >> * Can't specify help text for each resource >> * Hard to browse the model. Need to submit "list" style REST invocations. >> >> >> Note that it might be possible to auto-generate Design #1. If so, it would be >> the best of both worlds. >> >> >> Whoever implements this should probably start with Design #2 and then spend >> some time researching auto-generation of Design #1. >> >> >> Other thoughts? >> >> >> _______________________________________________ >> keycloak-dev mailing list keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Tue May 19 08:22:26 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 19 May 2015 08:22:26 -0400 (EDT) Subject: [keycloak-dev] Thoughts on Keycloak CLI In-Reply-To: <555B2884.9060900@redhat.com> References: <5555E867.4020703@redhat.com> <555A31B0.907@redhat.com> <1696523919.1386139.1432016573984.JavaMail.zimbra@redhat.com> <555B2884.9060900@redhat.com> Message-ID: <1126949749.1584275.1432038146351.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Stan Silvert" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Tuesday, 19 May, 2015 2:11:48 PM > Subject: Re: [keycloak-dev] Thoughts on Keycloak CLI > > On 5/19/2015 2:22 AM, Stian Thorgersen wrote: > > I'm not a big fan of Design #2, sounds like it's going to be pretty much > > useless. > #2 gives you an easy way to execute the REST API from the command line > or via a CLI script. Surely, that's a useful feature to have. So does CURL and I bet it's easier to just use that directly than a DMR wrapped REST API > > We should do it properly if we/when we do it. DMR/CLI is hard enough to use > > as it is! > #1 is prettier. #2 is more raw. I don't see why we wouldn't have both > eventually. I'm halfway done with #2. It's easy to implement and > having it is better than not having it. Plus, having #2 will make it > easier to implement #1. > > Are you still thinking we should have our own proprietary CLI instead? Yes, I'm pretty convinced wrapping the REST endpoint isn't going to produce an usable CLI > > > > The first priority for CLI is to have support to reset admin password and > > to do import/export, not the admin endpoints. > Is reset admin password not allowed from the REST API? > > We also need to make sure we can authenticate properly using Keycloak. > I'm not sure what you mean by this. Can you elaborate? Adding operations from admin endpoints (create/update realm, create/update users, etc.) isn't the highest priority. What we do need is: * Recover admin password - if a user looses the admin password there's no easy way to recover access other than manually editing the database * Make it easier to run import/export and allow running it offline As we're using JBoss CLI, which now has an offline mode, that's the perfect place to add those operations. > > > > ----- Original Message ----- > >> From: "Stan Silvert" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Monday, 18 May, 2015 8:38:40 PM > >> Subject: Re: [keycloak-dev] Thoughts on Keycloak CLI > >> > >> BTW, I've got some down time waiting on Elytron, so I've decided to do a > >> quickie implementation of #2 to see how it goes. > >> > >> On 5/15/2015 8:36 AM, Stan Silvert wrote: > >> > >> > >> I've been giving some thought to the Keycloak integration with WildFly > >> CLI. > >> There are two designs. Both involve a subsystem called "kcrest" with a > >> resource called "server". You can define a server to talk to using these > >> three attributes: > >> base-url ( value is something like http://localhost:8080/auth/admin/realms > >> ) > >> username > >> password > >> > >> username and password are optional. If you don't mind having these values > >> stored in standalone.xml/domain.xml you can specify them. That way, you > >> don't have to include them with each request. > >> > >> Design #1: Implement all of the Keycloak REST API in CLI > >> We build out resources for each REST path and put them in the management > >> model. Then build out operations for everything. So a CLI session to > >> create > >> a client called "myclient" might look like this: > >> cd /subsystem=kcrest/server=foo > >> cd realm=myrealm > >> clients=myclient:add(enabled=true) > >> > >> Design #2: Create a single generic operation that closely mimics the REST > >> API > >> cd /subsystem=kcrest/server=foo > >> :submit(method=POST, > >> path=/myrealm/clients,params={"clientId"=>"myclient","enabled"=>"true"}) > >> > >> Advantages of Design #1 > >> > >> > >> * Looks and behaves just like other CLI resources > >> * Uses standard CLI operations > >> * Each resource and operation can contain help text > >> * Everything can be navigated from CLI command line or CLI GUI tree, > >> making it easy to browse the model > >> > >> > >> Disadvantages of Design #1 > >> > >> > >> * It might take a very long time to implement (2-3 months?) > >> * Ongoing maintenance. Every time REST API changes, you have to > >> update > >> subsystem code > >> > >> > >> Advantages of Design #2 > >> > >> > >> * Quick to implement (2-3 weeks) > >> * Always works despite REST API changes > >> > >> > >> Disadvantages of Design #2 > >> > >> > >> * :submit operations get long and ugly > >> * Can't specify help text for each resource > >> * Hard to browse the model. Need to submit "list" style REST > >> invocations. > >> > >> > >> Note that it might be possible to auto-generate Design #1. If so, it would > >> be > >> the best of both worlds. > >> > >> > >> Whoever implements this should probably start with Design #2 and then > >> spend > >> some time researching auto-generation of Design #1. > >> > >> > >> Other thoughts? > >> > >> > >> _______________________________________________ > >> keycloak-dev mailing list keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > >> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > From stian at redhat.com Tue May 19 08:41:26 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 19 May 2015 08:41:26 -0400 (EDT) Subject: [keycloak-dev] Thoughts on Keycloak CLI In-Reply-To: <1126949749.1584275.1432038146351.JavaMail.zimbra@redhat.com> References: <5555E867.4020703@redhat.com> <555A31B0.907@redhat.com> <1696523919.1386139.1432016573984.JavaMail.zimbra@redhat.com> <555B2884.9060900@redhat.com> <1126949749.1584275.1432038146351.JavaMail.zimbra@redhat.com> Message-ID: <1066579760.1595798.1432039286591.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Stian Thorgersen" > To: "Stan Silvert" > Cc: keycloak-dev at lists.jboss.org > Sent: Tuesday, 19 May, 2015 2:22:26 PM > Subject: Re: [keycloak-dev] Thoughts on Keycloak CLI > > > > ----- Original Message ----- > > From: "Stan Silvert" > > To: "Stian Thorgersen" > > Cc: keycloak-dev at lists.jboss.org > > Sent: Tuesday, 19 May, 2015 2:11:48 PM > > Subject: Re: [keycloak-dev] Thoughts on Keycloak CLI > > > > On 5/19/2015 2:22 AM, Stian Thorgersen wrote: > > > I'm not a big fan of Design #2, sounds like it's going to be pretty much > > > useless. > > #2 gives you an easy way to execute the REST API from the command line > > or via a CLI script. Surely, that's a useful feature to have. > > So does CURL and I bet it's easier to just use that directly than a DMR > wrapped REST API > > > > We should do it properly if we/when we do it. DMR/CLI is hard enough to > > > use > > > as it is! > > #1 is prettier. #2 is more raw. I don't see why we wouldn't have both > > eventually. I'm halfway done with #2. It's easy to implement and > > having it is better than not having it. Plus, having #2 will make it > > easier to implement #1. Why would we have two alternatives to do the same thing? > > > > Are you still thinking we should have our own proprietary CLI instead? > > Yes, I'm pretty convinced wrapping the REST endpoint isn't going to produce > an usable CLI Can you give some examples on how this would actually look like? Also, how is authentication done? > > > > > > > The first priority for CLI is to have support to reset admin password and > > > to do import/export, not the admin endpoints. > > Is reset admin password not allowed from the REST API? > > > We also need to make sure we can authenticate properly using Keycloak. > > I'm not sure what you mean by this. Can you elaborate? > > Adding operations from admin endpoints (create/update realm, create/update > users, etc.) isn't the highest priority. What we do need is: > > * Recover admin password - if a user looses the admin password there's no > easy way to recover access other than manually editing the database > * Make it easier to run import/export and allow running it offline > > As we're using JBoss CLI, which now has an offline mode, that's the perfect > place to add those operations. > > > > > > > ----- Original Message ----- > > >> From: "Stan Silvert" > > >> To: keycloak-dev at lists.jboss.org > > >> Sent: Monday, 18 May, 2015 8:38:40 PM > > >> Subject: Re: [keycloak-dev] Thoughts on Keycloak CLI > > >> > > >> BTW, I've got some down time waiting on Elytron, so I've decided to do a > > >> quickie implementation of #2 to see how it goes. > > >> > > >> On 5/15/2015 8:36 AM, Stan Silvert wrote: > > >> > > >> > > >> I've been giving some thought to the Keycloak integration with WildFly > > >> CLI. > > >> There are two designs. Both involve a subsystem called "kcrest" with a > > >> resource called "server". You can define a server to talk to using these > > >> three attributes: > > >> base-url ( value is something like > > >> http://localhost:8080/auth/admin/realms > > >> ) > > >> username > > >> password > > >> > > >> username and password are optional. If you don't mind having these > > >> values > > >> stored in standalone.xml/domain.xml you can specify them. That way, you > > >> don't have to include them with each request. > > >> > > >> Design #1: Implement all of the Keycloak REST API in CLI > > >> We build out resources for each REST path and put them in the management > > >> model. Then build out operations for everything. So a CLI session to > > >> create > > >> a client called "myclient" might look like this: > > >> cd /subsystem=kcrest/server=foo > > >> cd realm=myrealm > > >> clients=myclient:add(enabled=true) > > >> > > >> Design #2: Create a single generic operation that closely mimics the > > >> REST > > >> API > > >> cd /subsystem=kcrest/server=foo > > >> :submit(method=POST, > > >> path=/myrealm/clients,params={"clientId"=>"myclient","enabled"=>"true"}) > > >> > > >> Advantages of Design #1 > > >> > > >> > > >> * Looks and behaves just like other CLI resources > > >> * Uses standard CLI operations > > >> * Each resource and operation can contain help text > > >> * Everything can be navigated from CLI command line or CLI GUI > > >> tree, > > >> making it easy to browse the model > > >> > > >> > > >> Disadvantages of Design #1 > > >> > > >> > > >> * It might take a very long time to implement (2-3 months?) > > >> * Ongoing maintenance. Every time REST API changes, you have to > > >> update > > >> subsystem code > > >> > > >> > > >> Advantages of Design #2 > > >> > > >> > > >> * Quick to implement (2-3 weeks) > > >> * Always works despite REST API changes > > >> > > >> > > >> Disadvantages of Design #2 > > >> > > >> > > >> * :submit operations get long and ugly > > >> * Can't specify help text for each resource > > >> * Hard to browse the model. Need to submit "list" style REST > > >> invocations. > > >> > > >> > > >> Note that it might be possible to auto-generate Design #1. If so, it > > >> would > > >> be > > >> the best of both worlds. > > >> > > >> > > >> Whoever implements this should probably start with Design #2 and then > > >> spend > > >> some time researching auto-generation of Design #1. > > >> > > >> > > >> Other thoughts? > > >> > > >> > > >> _______________________________________________ > > >> keycloak-dev mailing list keycloak-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > >> > > >> > > >> _______________________________________________ > > >> keycloak-dev mailing list > > >> keycloak-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From ssilvert at redhat.com Tue May 19 09:02:07 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 19 May 2015 09:02:07 -0400 Subject: [keycloak-dev] Thoughts on Keycloak CLI In-Reply-To: <1066579760.1595798.1432039286591.JavaMail.zimbra@redhat.com> References: <5555E867.4020703@redhat.com> <555A31B0.907@redhat.com> <1696523919.1386139.1432016573984.JavaMail.zimbra@redhat.com> <555B2884.9060900@redhat.com> <1126949749.1584275.1432038146351.JavaMail.zimbra@redhat.com> <1066579760.1595798.1432039286591.JavaMail.zimbra@redhat.com> Message-ID: <555B344F.80507@redhat.com> On 5/19/2015 8:41 AM, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Stian Thorgersen" >> To: "Stan Silvert" >> Cc: keycloak-dev at lists.jboss.org >> Sent: Tuesday, 19 May, 2015 2:22:26 PM >> Subject: Re: [keycloak-dev] Thoughts on Keycloak CLI >> >> >> >> ----- Original Message ----- >>> From: "Stan Silvert" >>> To: "Stian Thorgersen" >>> Cc: keycloak-dev at lists.jboss.org >>> Sent: Tuesday, 19 May, 2015 2:11:48 PM >>> Subject: Re: [keycloak-dev] Thoughts on Keycloak CLI >>> >>> On 5/19/2015 2:22 AM, Stian Thorgersen wrote: >>>> I'm not a big fan of Design #2, sounds like it's going to be pretty much >>>> useless. >>> #2 gives you an easy way to execute the REST API from the command line >>> or via a CLI script. Surely, that's a useful feature to have. >> So does CURL and I bet it's easier to just use that directly than a DMR >> wrapped REST API Windows doesn't have curl by default. We need something platform independent that integrates with the the rest of WildFly. (Also, I tried doing this with curl. It's not very easy IMO.) >> >>>> We should do it properly if we/when we do it. DMR/CLI is hard enough to >>>> use >>>> as it is! >>> #1 is prettier. #2 is more raw. I don't see why we wouldn't have both >>> eventually. I'm halfway done with #2. It's easy to implement and >>> having it is better than not having it. Plus, having #2 will make it >>> easier to implement #1. > Why would we have two alternatives to do the same thing? It's possible we would get to the point where we would deprecate #2. But that would depend on whether or not we could auto-generate #1. #2 is something that would always work no matter what. Think of #1 as something that puts a nicer UI on top of #2. > >>> Are you still thinking we should have our own proprietary CLI instead? >> Yes, I'm pretty convinced wrapping the REST endpoint isn't going to produce >> an usable CLI > Can you give some examples on how this would actually look like? I have GET requests already working: /subsystem=keycloak-cli/:submit(method=GET,path=/demo/client-session-stats) { "outcome" => "success", "result" => {"admin-client" => 1} } /subsystem=keycloak-cli/:submit(method=GET,path=/demo/roles) { "outcome" => "success", "result" => [ { "id" => "9d6cb276-3b60-4a29-bc5c-6ffb573e01d4", "name" => "admin", "description" => "Administrator privileges", "composite" => false, "composites" => undefined }, { "id" => "7606678c-cf44-4a22-8551-549136047a9c", "name" => "user", "description" => "User privileges", "composite" => false, "composites" => undefined } ] } > Also, how is authentication done? Authentication is done the same way as in the AdminClient.java example. Username and password can be stored in standalone.xml or passed along with each request. We could cache the AccessToken so you only have to specify it once. If you are using Keycloak to authenticate CLI then it's also possible to use the AccessToken you got when you logged into CLI. > >>>> The first priority for CLI is to have support to reset admin password and >>>> to do import/export, not the admin endpoints. >>> Is reset admin password not allowed from the REST API? >>>> We also need to make sure we can authenticate properly using Keycloak. >>> I'm not sure what you mean by this. Can you elaborate? >> Adding operations from admin endpoints (create/update realm, create/update >> users, etc.) isn't the highest priority. What we do need is: >> >> * Recover admin password - if a user looses the admin password there's no >> easy way to recover access other than manually editing the database >> * Make it easier to run import/export and allow running it offline >> >> As we're using JBoss CLI, which now has an offline mode, that's the perfect >> place to add those operations. >> >>>> ----- Original Message ----- >>>>> From: "Stan Silvert" >>>>> To: keycloak-dev at lists.jboss.org >>>>> Sent: Monday, 18 May, 2015 8:38:40 PM >>>>> Subject: Re: [keycloak-dev] Thoughts on Keycloak CLI >>>>> >>>>> BTW, I've got some down time waiting on Elytron, so I've decided to do a >>>>> quickie implementation of #2 to see how it goes. >>>>> >>>>> On 5/15/2015 8:36 AM, Stan Silvert wrote: >>>>> >>>>> >>>>> I've been giving some thought to the Keycloak integration with WildFly >>>>> CLI. >>>>> There are two designs. Both involve a subsystem called "kcrest" with a >>>>> resource called "server". You can define a server to talk to using these >>>>> three attributes: >>>>> base-url ( value is something like >>>>> http://localhost:8080/auth/admin/realms >>>>> ) >>>>> username >>>>> password >>>>> >>>>> username and password are optional. If you don't mind having these >>>>> values >>>>> stored in standalone.xml/domain.xml you can specify them. That way, you >>>>> don't have to include them with each request. >>>>> >>>>> Design #1: Implement all of the Keycloak REST API in CLI >>>>> We build out resources for each REST path and put them in the management >>>>> model. Then build out operations for everything. So a CLI session to >>>>> create >>>>> a client called "myclient" might look like this: >>>>> cd /subsystem=kcrest/server=foo >>>>> cd realm=myrealm >>>>> clients=myclient:add(enabled=true) >>>>> >>>>> Design #2: Create a single generic operation that closely mimics the >>>>> REST >>>>> API >>>>> cd /subsystem=kcrest/server=foo >>>>> :submit(method=POST, >>>>> path=/myrealm/clients,params={"clientId"=>"myclient","enabled"=>"true"}) >>>>> >>>>> Advantages of Design #1 >>>>> >>>>> >>>>> * Looks and behaves just like other CLI resources >>>>> * Uses standard CLI operations >>>>> * Each resource and operation can contain help text >>>>> * Everything can be navigated from CLI command line or CLI GUI >>>>> tree, >>>>> making it easy to browse the model >>>>> >>>>> >>>>> Disadvantages of Design #1 >>>>> >>>>> >>>>> * It might take a very long time to implement (2-3 months?) >>>>> * Ongoing maintenance. Every time REST API changes, you have to >>>>> update >>>>> subsystem code >>>>> >>>>> >>>>> Advantages of Design #2 >>>>> >>>>> >>>>> * Quick to implement (2-3 weeks) >>>>> * Always works despite REST API changes >>>>> >>>>> >>>>> Disadvantages of Design #2 >>>>> >>>>> >>>>> * :submit operations get long and ugly >>>>> * Can't specify help text for each resource >>>>> * Hard to browse the model. Need to submit "list" style REST >>>>> invocations. >>>>> >>>>> >>>>> Note that it might be possible to auto-generate Design #1. If so, it >>>>> would >>>>> be >>>>> the best of both worlds. >>>>> >>>>> >>>>> Whoever implements this should probably start with Design #2 and then >>>>> spend >>>>> some time researching auto-generation of Design #1. >>>>> >>>>> >>>>> Other thoughts? >>>>> >>>>> >>>>> _______________________________________________ >>>>> keycloak-dev mailing list keycloak-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From ssilvert at redhat.com Tue May 19 09:05:45 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 19 May 2015 09:05:45 -0400 Subject: [keycloak-dev] Thoughts on Keycloak CLI In-Reply-To: <1066579760.1595798.1432039286591.JavaMail.zimbra@redhat.com> References: <5555E867.4020703@redhat.com> <555A31B0.907@redhat.com> <1696523919.1386139.1432016573984.JavaMail.zimbra@redhat.com> <555B2884.9060900@redhat.com> <1126949749.1584275.1432038146351.JavaMail.zimbra@redhat.com> <1066579760.1595798.1432039286591.JavaMail.zimbra@redhat.com> Message-ID: <555B3529.9000005@redhat.com> On 5/19/2015 8:41 AM, Stian Thorgersen wrote: >>>> The first priority for CLI is to have support to reset admin password and >>>> to do import/export, not the admin endpoints. >>> Is reset admin password not allowed from the REST API? >>>> We also need to make sure we can authenticate properly using Keycloak. >>> I'm not sure what you mean by this. Can you elaborate? >> Adding operations from admin endpoints (create/update realm, create/update >> users, etc.) isn't the highest priority. What we do need is: >> >> * Recover admin password - if a user looses the admin password there's no >> easy way to recover access other than manually editing the database Indeed. That does sound like a high priority. I take it there is no existing API for that? >> * Make it easier to run import/export and allow running it offline Sounds doable. >> >> As we're using JBoss CLI, which now has an offline mode, that's the perfect >> place to add those operations. >> >>>> ----- Original Message ----- >>>>> From: "Stan Silvert" >>>>> To: keycloak-dev at lists.jboss.org >>>>> Sent: Monday, 18 May, 2015 8:38:40 PM >>>>> Subject: Re: [keycloak-dev] Thoughts on Keycloak CLI >>>>> >>>>> BTW, I've got some down time waiting on Elytron, so I've decided to do a >>>>> quickie implementation of #2 to see how it goes. >>>>> >>>>> On 5/15/2015 8:36 AM, Stan Silvert wrote: >>>>> >>>>> >>>>> I've been giving some thought to the Keycloak integration with WildFly >>>>> CLI. >>>>> There are two designs. Both involve a subsystem called "kcrest" with a >>>>> resource called "server". You can define a server to talk to using these >>>>> three attributes: >>>>> base-url ( value is something like >>>>> http://localhost:8080/auth/admin/realms >>>>> ) >>>>> username >>>>> password >>>>> >>>>> username and password are optional. If you don't mind having these >>>>> values >>>>> stored in standalone.xml/domain.xml you can specify them. That way, you >>>>> don't have to include them with each request. >>>>> >>>>> Design #1: Implement all of the Keycloak REST API in CLI >>>>> We build out resources for each REST path and put them in the management >>>>> model. Then build out operations for everything. So a CLI session to >>>>> create >>>>> a client called "myclient" might look like this: >>>>> cd /subsystem=kcrest/server=foo >>>>> cd realm=myrealm >>>>> clients=myclient:add(enabled=true) >>>>> >>>>> Design #2: Create a single generic operation that closely mimics the >>>>> REST >>>>> API >>>>> cd /subsystem=kcrest/server=foo >>>>> :submit(method=POST, >>>>> path=/myrealm/clients,params={"clientId"=>"myclient","enabled"=>"true"}) >>>>> >>>>> Advantages of Design #1 >>>>> >>>>> >>>>> * Looks and behaves just like other CLI resources >>>>> * Uses standard CLI operations >>>>> * Each resource and operation can contain help text >>>>> * Everything can be navigated from CLI command line or CLI GUI >>>>> tree, >>>>> making it easy to browse the model >>>>> >>>>> >>>>> Disadvantages of Design #1 >>>>> >>>>> >>>>> * It might take a very long time to implement (2-3 months?) >>>>> * Ongoing maintenance. Every time REST API changes, you have to >>>>> update >>>>> subsystem code >>>>> >>>>> >>>>> Advantages of Design #2 >>>>> >>>>> >>>>> * Quick to implement (2-3 weeks) >>>>> * Always works despite REST API changes >>>>> >>>>> >>>>> Disadvantages of Design #2 >>>>> >>>>> >>>>> * :submit operations get long and ugly >>>>> * Can't specify help text for each resource >>>>> * Hard to browse the model. Need to submit "list" style REST >>>>> invocations. >>>>> >>>>> >>>>> Note that it might be possible to auto-generate Design #1. If so, it >>>>> would >>>>> be >>>>> the best of both worlds. >>>>> >>>>> >>>>> Whoever implements this should probably start with Design #2 and then >>>>> spend >>>>> some time researching auto-generation of Design #1. >>>>> >>>>> >>>>> Other thoughts? >>>>> >>>>> >>>>> _______________________________________________ >>>>> keycloak-dev mailing list keycloak-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From bburke at redhat.com Tue May 19 09:27:39 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 19 May 2015 09:27:39 -0400 Subject: [keycloak-dev] Thoughts on Keycloak CLI In-Reply-To: <555B3529.9000005@redhat.com> References: <5555E867.4020703@redhat.com> <555A31B0.907@redhat.com> <1696523919.1386139.1432016573984.JavaMail.zimbra@redhat.com> <555B2884.9060900@redhat.com> <1126949749.1584275.1432038146351.JavaMail.zimbra@redhat.com> <1066579760.1595798.1432039286591.JavaMail.zimbra@redhat.com> <555B3529.9000005@redhat.com> Message-ID: <555B3A4B.8050409@redhat.com> FWIW, I agree with Stian on #2. Why wouldn't you just use the REST interface in that case? IMO, JBoss CLI suffers from serious usability issues. Kinda sucks we have to build on top of it. BTW, doesn't an admin password recovery scare you a little bit? Shouldn't this be an operation that can only run in offline mode directly on the machine keycloak is installed? Import/export falls into this catagory too. On 5/19/2015 9:05 AM, Stan Silvert wrote: > On 5/19/2015 8:41 AM, Stian Thorgersen wrote: >>>>> The first priority for CLI is to have support to reset admin password and >>>>> to do import/export, not the admin endpoints. >>>> Is reset admin password not allowed from the REST API? >>>>> We also need to make sure we can authenticate properly using Keycloak. >>>> I'm not sure what you mean by this. Can you elaborate? >>> Adding operations from admin endpoints (create/update realm, create/update >>> users, etc.) isn't the highest priority. What we do need is: >>> >>> * Recover admin password - if a user looses the admin password there's no >>> easy way to recover access other than manually editing the database > Indeed. That does sound like a high priority. I take it there is no > existing API for that? >>> * Make it easier to run import/export and allow running it offline > Sounds doable. >>> >>> As we're using JBoss CLI, which now has an offline mode, that's the perfect >>> place to add those operations. > >>> >>>>> ----- Original Message ----- >>>>>> From: "Stan Silvert" >>>>>> To: keycloak-dev at lists.jboss.org >>>>>> Sent: Monday, 18 May, 2015 8:38:40 PM >>>>>> Subject: Re: [keycloak-dev] Thoughts on Keycloak CLI >>>>>> >>>>>> BTW, I've got some down time waiting on Elytron, so I've decided to do a >>>>>> quickie implementation of #2 to see how it goes. >>>>>> >>>>>> On 5/15/2015 8:36 AM, Stan Silvert wrote: >>>>>> >>>>>> >>>>>> I've been giving some thought to the Keycloak integration with WildFly >>>>>> CLI. >>>>>> There are two designs. Both involve a subsystem called "kcrest" with a >>>>>> resource called "server". You can define a server to talk to using these >>>>>> three attributes: >>>>>> base-url ( value is something like >>>>>> http://localhost:8080/auth/admin/realms >>>>>> ) >>>>>> username >>>>>> password >>>>>> >>>>>> username and password are optional. If you don't mind having these >>>>>> values >>>>>> stored in standalone.xml/domain.xml you can specify them. That way, you >>>>>> don't have to include them with each request. >>>>>> >>>>>> Design #1: Implement all of the Keycloak REST API in CLI >>>>>> We build out resources for each REST path and put them in the management >>>>>> model. Then build out operations for everything. So a CLI session to >>>>>> create >>>>>> a client called "myclient" might look like this: >>>>>> cd /subsystem=kcrest/server=foo >>>>>> cd realm=myrealm >>>>>> clients=myclient:add(enabled=true) >>>>>> >>>>>> Design #2: Create a single generic operation that closely mimics the >>>>>> REST >>>>>> API >>>>>> cd /subsystem=kcrest/server=foo >>>>>> :submit(method=POST, >>>>>> path=/myrealm/clients,params={"clientId"=>"myclient","enabled"=>"true"}) >>>>>> >>>>>> Advantages of Design #1 >>>>>> >>>>>> >>>>>> * Looks and behaves just like other CLI resources >>>>>> * Uses standard CLI operations >>>>>> * Each resource and operation can contain help text >>>>>> * Everything can be navigated from CLI command line or CLI GUI >>>>>> tree, >>>>>> making it easy to browse the model >>>>>> >>>>>> >>>>>> Disadvantages of Design #1 >>>>>> >>>>>> >>>>>> * It might take a very long time to implement (2-3 months?) >>>>>> * Ongoing maintenance. Every time REST API changes, you have to >>>>>> update >>>>>> subsystem code >>>>>> >>>>>> >>>>>> Advantages of Design #2 >>>>>> >>>>>> >>>>>> * Quick to implement (2-3 weeks) >>>>>> * Always works despite REST API changes >>>>>> >>>>>> >>>>>> Disadvantages of Design #2 >>>>>> >>>>>> >>>>>> * :submit operations get long and ugly >>>>>> * Can't specify help text for each resource >>>>>> * Hard to browse the model. Need to submit "list" style REST >>>>>> invocations. >>>>>> >>>>>> >>>>>> Note that it might be possible to auto-generate Design #1. If so, it >>>>>> would >>>>>> be >>>>>> the best of both worlds. >>>>>> >>>>>> >>>>>> Whoever implements this should probably start with Design #2 and then >>>>>> spend >>>>>> some time researching auto-generation of Design #1. >>>>>> >>>>>> >>>>>> Other thoughts? >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> keycloak-dev mailing list keycloak-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> keycloak-dev mailing list >>>>>> keycloak-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From ssilvert at redhat.com Tue May 19 09:39:38 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 19 May 2015 09:39:38 -0400 Subject: [keycloak-dev] Thoughts on Keycloak CLI In-Reply-To: <555B3A4B.8050409@redhat.com> References: <5555E867.4020703@redhat.com> <555A31B0.907@redhat.com> <1696523919.1386139.1432016573984.JavaMail.zimbra@redhat.com> <555B2884.9060900@redhat.com> <1126949749.1584275.1432038146351.JavaMail.zimbra@redhat.com> <1066579760.1595798.1432039286591.JavaMail.zimbra@redhat.com> <555B3529.9000005@redhat.com> <555B3A4B.8050409@redhat.com> Message-ID: <555B3D1A.6030902@redhat.com> On 5/19/2015 9:27 AM, Bill Burke wrote: > FWIW, I agree with Stian on #2. Why wouldn't you just use the REST > interface in that case? IMO, JBoss CLI suffers from serious usability > issues. Kinda sucks we have to build on top of it. I agree too. #1 is better. But #2 makes it easier to "just use the REST interface". > > BTW, doesn't an admin password recovery scare you a little bit? You mean not having it is scary? > Shouldn't this be an operation that can only run in offline mode > directly on the machine keycloak is installed? Import/export falls into > this catagory too. Yes. I think we all agree on that. > > On 5/19/2015 9:05 AM, Stan Silvert wrote: >> On 5/19/2015 8:41 AM, Stian Thorgersen wrote: >>>>>> The first priority for CLI is to have support to reset admin password and >>>>>> to do import/export, not the admin endpoints. >>>>> Is reset admin password not allowed from the REST API? >>>>>> We also need to make sure we can authenticate properly using Keycloak. >>>>> I'm not sure what you mean by this. Can you elaborate? >>>> Adding operations from admin endpoints (create/update realm, create/update >>>> users, etc.) isn't the highest priority. What we do need is: >>>> >>>> * Recover admin password - if a user looses the admin password there's no >>>> easy way to recover access other than manually editing the database >> Indeed. That does sound like a high priority. I take it there is no >> existing API for that? >>>> * Make it easier to run import/export and allow running it offline >> Sounds doable. >>>> As we're using JBoss CLI, which now has an offline mode, that's the perfect >>>> place to add those operations. >>>>>> ----- Original Message ----- >>>>>>> From: "Stan Silvert" >>>>>>> To: keycloak-dev at lists.jboss.org >>>>>>> Sent: Monday, 18 May, 2015 8:38:40 PM >>>>>>> Subject: Re: [keycloak-dev] Thoughts on Keycloak CLI >>>>>>> >>>>>>> BTW, I've got some down time waiting on Elytron, so I've decided to do a >>>>>>> quickie implementation of #2 to see how it goes. >>>>>>> >>>>>>> On 5/15/2015 8:36 AM, Stan Silvert wrote: >>>>>>> >>>>>>> >>>>>>> I've been giving some thought to the Keycloak integration with WildFly >>>>>>> CLI. >>>>>>> There are two designs. Both involve a subsystem called "kcrest" with a >>>>>>> resource called "server". You can define a server to talk to using these >>>>>>> three attributes: >>>>>>> base-url ( value is something like >>>>>>> http://localhost:8080/auth/admin/realms >>>>>>> ) >>>>>>> username >>>>>>> password >>>>>>> >>>>>>> username and password are optional. If you don't mind having these >>>>>>> values >>>>>>> stored in standalone.xml/domain.xml you can specify them. That way, you >>>>>>> don't have to include them with each request. >>>>>>> >>>>>>> Design #1: Implement all of the Keycloak REST API in CLI >>>>>>> We build out resources for each REST path and put them in the management >>>>>>> model. Then build out operations for everything. So a CLI session to >>>>>>> create >>>>>>> a client called "myclient" might look like this: >>>>>>> cd /subsystem=kcrest/server=foo >>>>>>> cd realm=myrealm >>>>>>> clients=myclient:add(enabled=true) >>>>>>> >>>>>>> Design #2: Create a single generic operation that closely mimics the >>>>>>> REST >>>>>>> API >>>>>>> cd /subsystem=kcrest/server=foo >>>>>>> :submit(method=POST, >>>>>>> path=/myrealm/clients,params={"clientId"=>"myclient","enabled"=>"true"}) >>>>>>> >>>>>>> Advantages of Design #1 >>>>>>> >>>>>>> >>>>>>> * Looks and behaves just like other CLI resources >>>>>>> * Uses standard CLI operations >>>>>>> * Each resource and operation can contain help text >>>>>>> * Everything can be navigated from CLI command line or CLI GUI >>>>>>> tree, >>>>>>> making it easy to browse the model >>>>>>> >>>>>>> >>>>>>> Disadvantages of Design #1 >>>>>>> >>>>>>> >>>>>>> * It might take a very long time to implement (2-3 months?) >>>>>>> * Ongoing maintenance. Every time REST API changes, you have to >>>>>>> update >>>>>>> subsystem code >>>>>>> >>>>>>> >>>>>>> Advantages of Design #2 >>>>>>> >>>>>>> >>>>>>> * Quick to implement (2-3 weeks) >>>>>>> * Always works despite REST API changes >>>>>>> >>>>>>> >>>>>>> Disadvantages of Design #2 >>>>>>> >>>>>>> >>>>>>> * :submit operations get long and ugly >>>>>>> * Can't specify help text for each resource >>>>>>> * Hard to browse the model. Need to submit "list" style REST >>>>>>> invocations. >>>>>>> >>>>>>> >>>>>>> Note that it might be possible to auto-generate Design #1. If so, it >>>>>>> would >>>>>>> be >>>>>>> the best of both worlds. >>>>>>> >>>>>>> >>>>>>> Whoever implements this should probably start with Design #2 and then >>>>>>> spend >>>>>>> some time researching auto-generation of Design #1. >>>>>>> >>>>>>> >>>>>>> Other thoughts? >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> keycloak-dev mailing list keycloak-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> keycloak-dev mailing list >>>>>>> keycloak-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From ssilvert at redhat.com Tue May 19 09:42:22 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 19 May 2015 09:42:22 -0400 Subject: [keycloak-dev] Why does WildFly CLI suck? Message-ID: <555B3DBE.6080900@redhat.com> I've probably been too involved with it to be objective. What are the usability issues? From bburke at redhat.com Tue May 19 10:04:17 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 19 May 2015 10:04:17 -0400 Subject: [keycloak-dev] Why does WildFly CLI suck? In-Reply-To: <555B3DBE.6080900@redhat.com> References: <555B3DBE.6080900@redhat.com> Message-ID: <555B42E1.9000505@redhat.com> CLI is a UI. Generically rendered UIs generally suck. For example, did not managing JBoss 4.x and earlier suck using some generic JMX UI renderer? CLI falls into this category IMO. On 5/19/2015 9:42 AM, Stan Silvert wrote: > I've probably been too involved with it to be objective. What are the > usability issues? > _______________________________________________ > 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 leonardo.zanivan at gmail.com Tue May 19 10:23:03 2015 From: leonardo.zanivan at gmail.com (Leonardo Loch Zanivan) Date: Tue, 19 May 2015 14:23:03 +0000 Subject: [keycloak-dev] Why does WildFly CLI suck? In-Reply-To: <555B42E1.9000505@redhat.com> References: <555B3DBE.6080900@redhat.com> <555B42E1.9000505@redhat.com> Message-ID: IMHO, CLI is only for automation. However, JBoss CLI is hard to understand. On Tue, May 19, 2015 at 11:04 AM Bill Burke wrote: > CLI is a UI. Generically rendered UIs generally suck. For example, did > not managing JBoss 4.x and earlier suck using some generic JMX UI > renderer? CLI falls into this category IMO. > > On 5/19/2015 9:42 AM, Stan Silvert wrote: > > I've probably been too involved with it to be objective. What are the > > usability issues? > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150519/b8508e9b/attachment-0001.html From stian at redhat.com Tue May 19 10:31:36 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 19 May 2015 10:31:36 -0400 (EDT) Subject: [keycloak-dev] New Keycloak repo in GitHub In-Reply-To: <55536FF5.7010402@redhat.com> References: <5552227F.6040407@redhat.com> <55523984.1030101@redhat.com> <5552407B.9030400@redhat.com> <55535A59.4000502@redhat.com> <55536FF5.7010402@redhat.com> Message-ID: <1279952648.1694058.1432045896306.JavaMail.zimbra@redhat.com> Let's put it in main repo in integration/elytron. That's where all other adapters live, so makes sense to put the elytron adapter there as well. ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Wednesday, 13 May, 2015 5:38:29 PM > Subject: Re: [keycloak-dev] New Keycloak repo in GitHub > > > > On 5/13/2015 10:06 AM, Stan Silvert wrote: > > Can we go ahead and make a final decision on this? My code needs a > > home. :-) > > > > On 5/12/2015 2:03 PM, Stan Silvert wrote: > >> On 5/12/2015 1:33 PM, Bill Burke wrote: > >>> What's the reasoning for a separate repo? > >> I thought we just discussed this in the meeting, but given the poor > >> audio/video from my internet connection, I'm not surprised you would > >> ask. :-) (I think I have it fixed now, btw) > >> > >> It started with the discussion below. This stuff could go in either > >> WildFly or Keycloak. But WildFly is getting away from having these > >> things in one uber repo. Even Elytron itself is in its own repo. > >> > >> We could put it in Keycloak's repo, but I don't see any advantage. This > >> stuff requires WildFly 10 and Java 8. I'm not sure if we're ready to > >> deal with that in the Keycloak repo yet. > >> > > Why keep it in the same repo? > > * Its easier for development. You import one pom.xml and then everything > is loaded. You make a refactor in a core class, and you see the effects > everywhere. > > * We know pull requests don't undermine any keycloak modules. With > separate repos, a PR to keycloak/keycloak could pass the CI build and be > merged, but break keycloak/elytron. > > >> But I think the main question is, do we want Keycloak/Elytron > >> integration to be tied to Keycloak releases? If a WildFly release needs > >> something from keycloak-eleytron integration then it's much easier to > >> just do a release of the small repo than to do a full release of the > >> entire Keycloak product. > >> > > THere is nothing stopping us from doing an adapter only release if there > is only one repo. You can branch from a tag, do the changes, do the > adapter-only release, merge branch into main. > > Wildfly is composed of projects from a variety of teams. Keycloak is a > one project one team. > > -- > 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 Tue May 19 10:35:52 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 19 May 2015 10:35:52 -0400 (EDT) Subject: [keycloak-dev] Am I doing this right? In-Reply-To: <5554CDEA.10801@redhat.com> References: <5554CDEA.10801@redhat.com> Message-ID: <120006136.1703365.1432046152924.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Stan Silvert" > To: keycloak-dev at lists.jboss.org > Sent: Thursday, 14 May, 2015 6:31:38 PM > Subject: [keycloak-dev] Am I doing this right? > > Temporary home for Keycloak/Elytron integration is here: > https://github.com/ssilvert/keycloak-elytron-temp > > In looking back over it, I realize I need to ask some general questions. > > The way the initial realm implementation works is that I implement the > Elytron realm interface. Whenever Elytron asks for a user > authentication, it calls out to a Keycloak server to validate credentials. > > The way I'm doing that right now is to use a Direct Access Grant. I > adapted some of Bill's code for this purpose: > https://github.com/ssilvert/keycloak-elytron-temp/blob/master/realm-impl/src/main/java/org/keycloak/elytron/realm/DirectGrantLogin.java > > On the Keycloak side, this requires allowing direct access grants on the > realm and defining a direct access client. Is there any reason why > someone would not want to do this? If so, should I provide some > alternate means of authentication? Depends on the use-case. If it's web based it should use redirects, not direct grant. Elytron has to support redirect based authentication as well. If it's not web based (cli, etc) and it's authenticating a user it should be direct grant. Although it needs to make sure the token is used (and not storing username/password). Direct grant is a way to obtain a token with a users credentials, not really a mechanism to verify user credentials. If it's not web based and it's authenticating a client it should not use direct grant. It should use client credentials grant (I think it's called) and authenticate with certificates or signed jwt's. > > Stan > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From stian at redhat.com Tue May 19 10:41:17 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 19 May 2015 10:41:17 -0400 (EDT) Subject: [keycloak-dev] Thoughts on Keycloak CLI In-Reply-To: <555B3D1A.6030902@redhat.com> References: <5555E867.4020703@redhat.com> <1696523919.1386139.1432016573984.JavaMail.zimbra@redhat.com> <555B2884.9060900@redhat.com> <1126949749.1584275.1432038146351.JavaMail.zimbra@redhat.com> <1066579760.1595798.1432039286591.JavaMail.zimbra@redhat.com> <555B3529.9000005@redhat.com> <555B3A4B.8050409@redhat.com> <555B3D1A.6030902@redhat.com> Message-ID: <1298294552.1710690.1432046477287.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Stan Silvert" > To: keycloak-dev at lists.jboss.org > Sent: Tuesday, 19 May, 2015 3:39:38 PM > Subject: Re: [keycloak-dev] Thoughts on Keycloak CLI > > On 5/19/2015 9:27 AM, Bill Burke wrote: > > FWIW, I agree with Stian on #2. Why wouldn't you just use the REST > > interface in that case? IMO, JBoss CLI suffers from serious usability > > issues. Kinda sucks we have to build on top of it. > I agree too. #1 is better. But #2 makes it easier to "just use the > REST interface". Let's drop option #2 - wrapping a REST API in DMR isn't anything but a hack/work-around. Instead let's go with option #1, but with a subset for now. > > > > BTW, doesn't an admin password recovery scare you a little bit? > You mean not having it is scary? Both ;) > > Shouldn't this be an operation that can only run in offline mode > > directly on the machine keycloak is installed? Import/export falls into > > this catagory too. > Yes. I think we all agree on that. Can we for now go for import/export + reset admin password? That get's us started on CLI support. Next step might be importing/updating clients, then managing users. Is there a way to only allow certain operations in DMR "locally"? Storing username/password in standalone.xml is a really horrible idea! Instead it should authenticate with username/password and store the refresh token. > > > > On 5/19/2015 9:05 AM, Stan Silvert wrote: > >> On 5/19/2015 8:41 AM, Stian Thorgersen wrote: > >>>>>> The first priority for CLI is to have support to reset admin password > >>>>>> and > >>>>>> to do import/export, not the admin endpoints. > >>>>> Is reset admin password not allowed from the REST API? > >>>>>> We also need to make sure we can authenticate properly using Keycloak. > >>>>> I'm not sure what you mean by this. Can you elaborate? > >>>> Adding operations from admin endpoints (create/update realm, > >>>> create/update > >>>> users, etc.) isn't the highest priority. What we do need is: > >>>> > >>>> * Recover admin password - if a user looses the admin password there's > >>>> no > >>>> easy way to recover access other than manually editing the database > >> Indeed. That does sound like a high priority. I take it there is no > >> existing API for that? > >>>> * Make it easier to run import/export and allow running it offline > >> Sounds doable. > >>>> As we're using JBoss CLI, which now has an offline mode, that's the > >>>> perfect > >>>> place to add those operations. > >>>>>> ----- Original Message ----- > >>>>>>> From: "Stan Silvert" > >>>>>>> To: keycloak-dev at lists.jboss.org > >>>>>>> Sent: Monday, 18 May, 2015 8:38:40 PM > >>>>>>> Subject: Re: [keycloak-dev] Thoughts on Keycloak CLI > >>>>>>> > >>>>>>> BTW, I've got some down time waiting on Elytron, so I've decided to > >>>>>>> do a > >>>>>>> quickie implementation of #2 to see how it goes. > >>>>>>> > >>>>>>> On 5/15/2015 8:36 AM, Stan Silvert wrote: > >>>>>>> > >>>>>>> > >>>>>>> I've been giving some thought to the Keycloak integration with > >>>>>>> WildFly > >>>>>>> CLI. > >>>>>>> There are two designs. Both involve a subsystem called "kcrest" with > >>>>>>> a > >>>>>>> resource called "server". You can define a server to talk to using > >>>>>>> these > >>>>>>> three attributes: > >>>>>>> base-url ( value is something like > >>>>>>> http://localhost:8080/auth/admin/realms > >>>>>>> ) > >>>>>>> username > >>>>>>> password > >>>>>>> > >>>>>>> username and password are optional. If you don't mind having these > >>>>>>> values > >>>>>>> stored in standalone.xml/domain.xml you can specify them. That way, > >>>>>>> you > >>>>>>> don't have to include them with each request. > >>>>>>> > >>>>>>> Design #1: Implement all of the Keycloak REST API in CLI > >>>>>>> We build out resources for each REST path and put them in the > >>>>>>> management > >>>>>>> model. Then build out operations for everything. So a CLI session to > >>>>>>> create > >>>>>>> a client called "myclient" might look like this: > >>>>>>> cd /subsystem=kcrest/server=foo > >>>>>>> cd realm=myrealm > >>>>>>> clients=myclient:add(enabled=true) > >>>>>>> > >>>>>>> Design #2: Create a single generic operation that closely mimics the > >>>>>>> REST > >>>>>>> API > >>>>>>> cd /subsystem=kcrest/server=foo > >>>>>>> :submit(method=POST, > >>>>>>> path=/myrealm/clients,params={"clientId"=>"myclient","enabled"=>"true"}) > >>>>>>> > >>>>>>> Advantages of Design #1 > >>>>>>> > >>>>>>> > >>>>>>> * Looks and behaves just like other CLI resources > >>>>>>> * Uses standard CLI operations > >>>>>>> * Each resource and operation can contain help text > >>>>>>> * Everything can be navigated from CLI command line or CLI > >>>>>>> GUI > >>>>>>> tree, > >>>>>>> making it easy to browse the model > >>>>>>> > >>>>>>> > >>>>>>> Disadvantages of Design #1 > >>>>>>> > >>>>>>> > >>>>>>> * It might take a very long time to implement (2-3 months?) > >>>>>>> * Ongoing maintenance. Every time REST API changes, you have > >>>>>>> to > >>>>>>> update > >>>>>>> subsystem code > >>>>>>> > >>>>>>> > >>>>>>> Advantages of Design #2 > >>>>>>> > >>>>>>> > >>>>>>> * Quick to implement (2-3 weeks) > >>>>>>> * Always works despite REST API changes > >>>>>>> > >>>>>>> > >>>>>>> Disadvantages of Design #2 > >>>>>>> > >>>>>>> > >>>>>>> * :submit operations get long and ugly > >>>>>>> * Can't specify help text for each resource > >>>>>>> * Hard to browse the model. Need to submit "list" style REST > >>>>>>> invocations. > >>>>>>> > >>>>>>> > >>>>>>> Note that it might be possible to auto-generate Design #1. If so, it > >>>>>>> would > >>>>>>> be > >>>>>>> the best of both worlds. > >>>>>>> > >>>>>>> > >>>>>>> Whoever implements this should probably start with Design #2 and then > >>>>>>> spend > >>>>>>> some time researching auto-generation of Design #1. > >>>>>>> > >>>>>>> > >>>>>>> Other thoughts? > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> keycloak-dev mailing list keycloak-dev at lists.jboss.org > >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> keycloak-dev mailing list > >>>>>>> keycloak-dev at lists.jboss.org > >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>> _______________________________________________ > >>>> keycloak-dev mailing list > >>>> keycloak-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From matthew.casperson at autogeneral.com.au Tue May 19 16:44:25 2015 From: matthew.casperson at autogeneral.com.au (Matthew Casperson) Date: Wed, 20 May 2015 06:44:25 +1000 Subject: [keycloak-dev] Problem upgrading from 1.2.0.Beta1 to CR1 In-Reply-To: References: <1635854945.13795538.1430910951426.JavaMail.zimbra@redhat.com> <1964450824.14310906.1430971705753.JavaMail.zimbra@redhat.com> Message-ID: Apologies for not testing this sooner, but I can confirm that 1.2.0-Final fixes this issue. - Matt On Fri, May 8, 2015 at 6:55 AM, Matthew Casperson < matthew.casperson at autogeneral.com.au> wrote: > I can't make any promises, but I will certainly try :) > > - Matt > > On Thu, May 7, 2015 at 2:08 PM, Stian Thorgersen wrote: > >> Just tried upgrading to 1.2.0.Beta1 from 1.0.4 and can confirm there's a >> problem. >> >> If we get a fix in master can you try it out before we release >> 1.2.0.Final next week? >> >> ----- Original Message ----- >> > From: "Matthew Casperson" >> > To: "Stian Thorgersen" , mposolda at redhat.com >> > Cc: keycloak-dev at lists.jboss.org >> > Sent: Wednesday, May 6, 2015 10:51:50 PM >> > Subject: Re: [keycloak-dev] Problem upgrading from 1.2.0.Beta1 to CR1 >> > >> > > By the way, are you using H2 in production? >> > We are still developing the platforms that rely on Keycloak. H2 has >> worked >> > well (we have low traffic with internal users only), but moving to >> MySQL is >> > something we'll be doing. >> > >> > > What version did you upgrade from? >> > The table was upgraded from 1.0.4 to 1.2.0.Beta1, then the error >> appeared >> > attempting to upgrade to CR1. >> > >> > >Maybe you can try to manually connect to your H2 database and set the >> > fields "DIRECT_GRANTS_ONLY" on CLIENT table to non-null value manually >> > through SQL. >> > I'll spend some time this week looking at the tables and the offending >> > column to see if I can manually update it and get the upgrade working. >> > >> > On Wed, May 6, 2015 at 9:15 PM, Stian Thorgersen >> wrote: >> > >> > > What version did you upgrade from? >> > > >> > > ----- Original Message ----- >> > > > From: "Matthew Casperson" >> > > > To: keycloak-dev at lists.jboss.org >> > > > Sent: Wednesday, May 6, 2015 12:59:03 AM >> > > > Subject: [keycloak-dev] Problem upgrading from 1.2.0.Beta1 to CR1 >> > > > >> > > > I received this error after copying the h2 database from my existing >> > > > 1.2.0.Beta1 deployment into a fresh copy of CR1. >> > > > Maybe a bug with the upgrade process? >> > > > jboss.undertow.deployment.default-server.default-host./auth: Failed >> to >> > > start >> > > > service >> > > > at >> > > > >> > > >> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) >> > > > [jboss-msc-1.2.2.Final.jar:1.2.2.Final] >> > > > at >> > > > >> > > >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >> > > > [rt.jar:1.7.0_65] >> > > > at >> > > > >> > > >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >> > > > [rt.jar:1.7.0_65] >> > > > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] >> > > > Caused by: java.lang.RuntimeException: Failed to construct public >> > > > >> > > >> org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) >> > > > at >> > > > >> > > >> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:160) >> > > > at >> > > > >> > > >> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211) >> > > > at >> > > > >> > > >> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295) >> > > > at >> > > > >> > > >> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236) >> > > > at >> > > > >> > > >> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112) >> > > > at >> > > > >> > > >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) >> > > > at >> > > > >> > > >> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) >> > > > at >> > > > >> > > >> org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:79) >> > > > at >> > > > >> > > >> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) >> > > > at >> > > > >> > > >> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:220) >> > > > at >> > > > >> > > >> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:125) >> > > > at >> > > > >> > > >> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:508) >> > > > at >> > > > >> > > >> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:88) >> > > > at >> > > > >> > > >> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72) >> > > > at >> > > > >> > > >> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) >> > > > [jboss-msc-1.2.2.Final.jar:1.2.2.Final] >> > > > at >> > > > >> > > >> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) >> > > > [jboss-msc-1.2.2.Final.jar:1.2.2.Final] >> > > > ... 3 more >> > > > Caused by: org.keycloak.models.ModelException: >> > > > javax.persistence.PersistenceException: >> > > > org.hibernate.PropertyAccessException: Null value was assigned to a >> > > property >> > > > of primitive type setter of >> > > > org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly >> > > > at >> > > > >> > > >> org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:44) >> > > > at >> > > > >> > > >> org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:34) >> > > > at com.sun.proxy.$Proxy57.find(Unknown Source) >> > > > at >> > > > >> > > >> org.keycloak.models.jpa.JpaRealmProvider.getRealm(JpaRealmProvider.java:63) >> > > > at >> > > > >> > > >> org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:163) >> > > > at >> > > > >> > > >> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:40) >> > > > at >> > > > >> > > >> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:31) >> > > > at >> > > > >> > > >> org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:160) >> > > > at >> > > > >> > > >> org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:85) >> > > > at >> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >> > > Method) >> > > > [rt.jar:1.7.0_65] >> > > > at >> > > > >> > > >> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) >> > > > [rt.jar:1.7.0_65] >> > > > at >> > > > >> > > >> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >> > > > [rt.jar:1.7.0_65] >> > > > at >> java.lang.reflect.Constructor.newInstance(Constructor.java:526) >> > > > [rt.jar:1.7.0_65] >> > > > at >> > > > >> > > >> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148) >> > > > ... 18 more >> > > > Caused by: javax.persistence.PersistenceException: >> > > > org.hibernate.PropertyAccessException: Null value was assigned to a >> > > property >> > > > of primitive type setter of >> > > > org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly >> > > > at >> > > > >> > > >> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763) >> > > > at >> > > > >> > > >> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1694) >> > > > at >> > > > >> > > >> org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1141) >> > > > at >> > > > >> > > >> org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1068) >> > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> > > > [rt.jar:1.7.0_65] >> > > > at >> > > > >> > > >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >> > > > [rt.jar:1.7.0_65] >> > > > at >> > > > >> > > >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> > > > [rt.jar:1.7.0_65] >> > > > at java.lang.reflect.Method.invoke(Method.java:606) >> > > [rt.jar:1.7.0_65] >> > > > at >> > > > >> > > >> org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:32) >> > > > ... 30 more >> > > > Caused by: org.hibernate.PropertyAccessException: Null value was >> > > assigned to >> > > > a property of primitive type setter of >> > > > org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly >> > > > at >> > > > >> > > >> org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:126) >> > > > at >> > > > >> > > >> org.hibernate.tuple.entity.AbstractEntityTuplizer.setPropertyValues(AbstractEntityTuplizer.java:713) >> > > > at >> > > > >> > > >> org.hibernate.tuple.entity.PojoEntityTuplizer.setPropertyValues(PojoEntityTuplizer.java:362) >> > > > at >> > > > >> > > >> org.hibernate.persister.entity.AbstractEntityPersister.setPropertyValues(AbstractEntityPersister.java:4718) >> > > > at >> > > > >> > > >> org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:188) >> > > > at >> > > > >> > > >> org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:144) >> > > > at >> > > > >> > > >> org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.performTwoPhaseLoad(AbstractRowReader.java:244) >> > > > at >> > > > >> > > >> org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.finishUp(AbstractRowReader.java:215) >> > > > at >> > > > >> > > >> org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:140) >> > > > at >> > > > >> > > >> org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:138) >> > > > at >> > > > >> > > >> org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:102) >> > > > at >> > > > >> > > >> org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:186) >> > > > at >> > > > >> > > >> org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:4126) >> > > > at >> > > > >> > > >> org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:503) >> > > > at >> > > > >> > > >> org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:468) >> > > > at >> > > > >> > > >> org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:213) >> > > > at >> > > > >> > > >> org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:275) >> > > > at >> > > > >> > > >> org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:151) >> > > > at >> > > org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1070) >> > > > at >> > > org.hibernate.internal.SessionImpl.access$2000(SessionImpl.java:176) >> > > > at >> > > > >> > > >> org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2551) >> > > > at >> org.hibernate.internal.SessionImpl.get(SessionImpl.java:955) >> > > > at >> > > > >> > > >> org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1110) >> > > > ... 36 more >> > > > Caused by: java.lang.IllegalArgumentException: Can not set boolean >> field >> > > > org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly to >> null >> > > value >> > > > at >> > > > >> > > >> sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164) >> > > > [rt.jar:1.7.0_65] >> > > > at >> > > > >> > > >> sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168) >> > > > [rt.jar:1.7.0_65] >> > > > at >> > > > >> > > >> sun.reflect.UnsafeBooleanFieldAccessorImpl.set(UnsafeBooleanFieldAccessorImpl.java:80) >> > > > [rt.jar:1.7.0_65] >> > > > at java.lang.reflect.Field.set(Field.java:741) >> [rt.jar:1.7.0_65] >> > > > at >> > > > >> > > >> org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:122) >> > > > ... 58 more >> > > > >> > > > -- >> > > > Matthew Casperson >> > > > Senior Front End Developer >> > > > Technology, Space & Distribution >> > > > Auto & General Holdings Pty Ltd >> > > > P: 07) 3377 8751 (Direct: 3377 8751 ) >> > > > F: 07) 3377 8833 >> > > > >> > > > >> > > > >> > > > This email is sent by Auto & General Insurance Company Ltd, Auto & >> > > General >> > > > Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body >> > > > corporate (Auto & General) and is for the intended addressee. >> > > > The views expressed in this email and attachments (email) reflect >> the >> > > views >> > > > of the stated author but may not reflect views of Auto & General. >> This >> > > email >> > > > is confidential and subject to copyright. >> > > > It may be privileged. If you are not the intended addressee, >> > > confidentiality >> > > > and privilege have not been waived and any use, interference with, >> or >> > > > disclosure of this email is unauthorised. >> > > > If you are not the intended addressee please immediately notify the >> > > sender >> > > > and then delete the email. Auto & General does not warrant that this >> > > email >> > > > is error or virus free. >> > > > >> > > > _______________________________________________ >> > > > keycloak-dev mailing list >> > > > keycloak-dev at lists.jboss.org >> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > >> > >> > >> > >> > -- >> > *Matthew Casperson* >> > *Senior Front End Developer* >> > Technology, Space & Distribution >> > Auto & General Holdings Pty Ltd >> > P: 07) 3377 8751 (Direct: 3377 8751) >> > F: 07) 3377 8833 >> > >> > -- >> > >> > >> > This email is sent by Auto & General Insurance Company Ltd, Auto & >> General >> > Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body >> > corporate (Auto & General) and is for the intended addressee. >> > The views expressed in this email and attachments (email) reflect the >> views >> > of the stated author but may not reflect views of Auto & General. This >> email >> > is confidential and subject to copyright. >> > It may be privileged. If you are not the intended addressee, >> confidentiality >> > and privilege have not been waived and any use, interference with, or >> > disclosure of this email is unauthorised. >> > If you are not the intended addressee please immediately notify the >> sender >> > and then delete the email. Auto & General does not warrant that this >> email >> > is error or virus free. >> > >> > >> > > > > -- > *Matthew Casperson* > *Senior Front End Developer* > Technology, Space & Distribution > Auto & General Holdings Pty Ltd > P: 07) 3377 8751 (Direct: 3377 8751) > F: 07) 3377 8833 > > > -- *Matthew Casperson* *Senior Front End Developer* Technology, Space & Distribution Auto & General Holdings Pty Ltd P: 07) 3377 8751 (Direct: 3377 8751) F: 07) 3377 8833 -- This email is sent by Auto & General Insurance Company Ltd, Auto & General Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body corporate (Auto & General) and is for the intended addressee. The views expressed in this email and attachments (email) reflect the views of the stated author but may not reflect views of Auto & General. This email is confidential and subject to copyright. It may be privileged. If you are not the intended addressee, confidentiality and privilege have not been waived and any use, interference with, or disclosure of this email is unauthorised. If you are not the intended addressee please immediately notify the sender and then delete the email. Auto & General does not warrant that this email is error or virus free. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150520/33f99912/attachment-0001.html From stian at redhat.com Wed May 20 00:42:01 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 20 May 2015 00:42:01 -0400 (EDT) Subject: [keycloak-dev] Problem upgrading from 1.2.0.Beta1 to CR1 In-Reply-To: References: <1635854945.13795538.1430910951426.JavaMail.zimbra@redhat.com> <1964450824.14310906.1430971705753.JavaMail.zimbra@redhat.com> Message-ID: <815667346.2080896.1432096921886.JavaMail.zimbra@redhat.com> Great, thanks for letting us know ----- Original Message ----- > From: "Matthew Casperson" > To: "Stian Thorgersen" > Cc: mposolda at redhat.com, keycloak-dev at lists.jboss.org > Sent: Tuesday, 19 May, 2015 10:44:25 PM > Subject: Re: [keycloak-dev] Problem upgrading from 1.2.0.Beta1 to CR1 > > Apologies for not testing this sooner, but I can confirm that 1.2.0-Final > fixes this issue. > > - Matt > > On Fri, May 8, 2015 at 6:55 AM, Matthew Casperson < > matthew.casperson at autogeneral.com.au> wrote: > > > I can't make any promises, but I will certainly try :) > > > > - Matt > > > > On Thu, May 7, 2015 at 2:08 PM, Stian Thorgersen wrote: > > > >> Just tried upgrading to 1.2.0.Beta1 from 1.0.4 and can confirm there's a > >> problem. > >> > >> If we get a fix in master can you try it out before we release > >> 1.2.0.Final next week? > >> > >> ----- Original Message ----- > >> > From: "Matthew Casperson" > >> > To: "Stian Thorgersen" , mposolda at redhat.com > >> > Cc: keycloak-dev at lists.jboss.org > >> > Sent: Wednesday, May 6, 2015 10:51:50 PM > >> > Subject: Re: [keycloak-dev] Problem upgrading from 1.2.0.Beta1 to CR1 > >> > > >> > > By the way, are you using H2 in production? > >> > We are still developing the platforms that rely on Keycloak. H2 has > >> worked > >> > well (we have low traffic with internal users only), but moving to > >> MySQL is > >> > something we'll be doing. > >> > > >> > > What version did you upgrade from? > >> > The table was upgraded from 1.0.4 to 1.2.0.Beta1, then the error > >> appeared > >> > attempting to upgrade to CR1. > >> > > >> > >Maybe you can try to manually connect to your H2 database and set the > >> > fields "DIRECT_GRANTS_ONLY" on CLIENT table to non-null value manually > >> > through SQL. > >> > I'll spend some time this week looking at the tables and the offending > >> > column to see if I can manually update it and get the upgrade working. > >> > > >> > On Wed, May 6, 2015 at 9:15 PM, Stian Thorgersen > >> wrote: > >> > > >> > > What version did you upgrade from? > >> > > > >> > > ----- Original Message ----- > >> > > > From: "Matthew Casperson" > >> > > > To: keycloak-dev at lists.jboss.org > >> > > > Sent: Wednesday, May 6, 2015 12:59:03 AM > >> > > > Subject: [keycloak-dev] Problem upgrading from 1.2.0.Beta1 to CR1 > >> > > > > >> > > > I received this error after copying the h2 database from my existing > >> > > > 1.2.0.Beta1 deployment into a fresh copy of CR1. > >> > > > Maybe a bug with the upgrade process? > >> > > > jboss.undertow.deployment.default-server.default-host./auth: Failed > >> to > >> > > start > >> > > > service > >> > > > at > >> > > > > >> > > > >> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > >> > > > [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > >> > > > at > >> > > > > >> > > > >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > >> > > > [rt.jar:1.7.0_65] > >> > > > at > >> > > > > >> > > > >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > >> > > > [rt.jar:1.7.0_65] > >> > > > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] > >> > > > Caused by: java.lang.RuntimeException: Failed to construct public > >> > > > > >> > > > >> org.keycloak.services.resources.KeycloakApplication(javax.servlet.ServletContext,org.jboss.resteasy.core.Dispatcher) > >> > > > at > >> > > > > >> > > > >> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:160) > >> > > > at > >> > > > > >> > > > >> org.jboss.resteasy.spi.ResteasyProviderFactory.createProviderInstance(ResteasyProviderFactory.java:2211) > >> > > > at > >> > > > > >> > > > >> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:295) > >> > > > at > >> > > > > >> > > > >> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:236) > >> > > > at > >> > > > > >> > > > >> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112) > >> > > > at > >> > > > > >> > > > >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) > >> > > > at > >> > > > > >> > > > >> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117) > >> > > > at > >> > > > > >> > > > >> org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:79) > >> > > > at > >> > > > > >> > > > >> io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103) > >> > > > at > >> > > > > >> > > > >> io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:220) > >> > > > at > >> > > > > >> > > > >> io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:125) > >> > > > at > >> > > > > >> > > > >> io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:508) > >> > > > at > >> > > > > >> > > > >> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:88) > >> > > > at > >> > > > > >> > > > >> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:72) > >> > > > at > >> > > > > >> > > > >> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > >> > > > [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > >> > > > at > >> > > > > >> > > > >> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > >> > > > [jboss-msc-1.2.2.Final.jar:1.2.2.Final] > >> > > > ... 3 more > >> > > > Caused by: org.keycloak.models.ModelException: > >> > > > javax.persistence.PersistenceException: > >> > > > org.hibernate.PropertyAccessException: Null value was assigned to a > >> > > property > >> > > > of primitive type setter of > >> > > > org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly > >> > > > at > >> > > > > >> > > > >> org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:44) > >> > > > at > >> > > > > >> > > > >> org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:34) > >> > > > at com.sun.proxy.$Proxy57.find(Unknown Source) > >> > > > at > >> > > > > >> > > > >> org.keycloak.models.jpa.JpaRealmProvider.getRealm(JpaRealmProvider.java:63) > >> > > > at > >> > > > > >> > > > >> org.keycloak.models.cache.DefaultCacheRealmProvider.getRealm(DefaultCacheRealmProvider.java:163) > >> > > > at > >> > > > > >> > > > >> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:40) > >> > > > at > >> > > > > >> > > > >> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:31) > >> > > > at > >> > > > > >> > > > >> org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:160) > >> > > > at > >> > > > > >> > > > >> org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:85) > >> > > > at > >> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > >> > > Method) > >> > > > [rt.jar:1.7.0_65] > >> > > > at > >> > > > > >> > > > >> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > >> > > > [rt.jar:1.7.0_65] > >> > > > at > >> > > > > >> > > > >> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > >> > > > [rt.jar:1.7.0_65] > >> > > > at > >> java.lang.reflect.Constructor.newInstance(Constructor.java:526) > >> > > > [rt.jar:1.7.0_65] > >> > > > at > >> > > > > >> > > > >> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:148) > >> > > > ... 18 more > >> > > > Caused by: javax.persistence.PersistenceException: > >> > > > org.hibernate.PropertyAccessException: Null value was assigned to a > >> > > property > >> > > > of primitive type setter of > >> > > > org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly > >> > > > at > >> > > > > >> > > > >> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763) > >> > > > at > >> > > > > >> > > > >> org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1694) > >> > > > at > >> > > > > >> > > > >> org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1141) > >> > > > at > >> > > > > >> > > > >> org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1068) > >> > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > >> > > > [rt.jar:1.7.0_65] > >> > > > at > >> > > > > >> > > > >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > >> > > > [rt.jar:1.7.0_65] > >> > > > at > >> > > > > >> > > > >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > >> > > > [rt.jar:1.7.0_65] > >> > > > at java.lang.reflect.Method.invoke(Method.java:606) > >> > > [rt.jar:1.7.0_65] > >> > > > at > >> > > > > >> > > > >> org.keycloak.connections.jpa.PersistenceExceptionConverter.invoke(PersistenceExceptionConverter.java:32) > >> > > > ... 30 more > >> > > > Caused by: org.hibernate.PropertyAccessException: Null value was > >> > > assigned to > >> > > > a property of primitive type setter of > >> > > > org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly > >> > > > at > >> > > > > >> > > > >> org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:126) > >> > > > at > >> > > > > >> > > > >> org.hibernate.tuple.entity.AbstractEntityTuplizer.setPropertyValues(AbstractEntityTuplizer.java:713) > >> > > > at > >> > > > > >> > > > >> org.hibernate.tuple.entity.PojoEntityTuplizer.setPropertyValues(PojoEntityTuplizer.java:362) > >> > > > at > >> > > > > >> > > > >> org.hibernate.persister.entity.AbstractEntityPersister.setPropertyValues(AbstractEntityPersister.java:4718) > >> > > > at > >> > > > > >> > > > >> org.hibernate.engine.internal.TwoPhaseLoad.doInitializeEntity(TwoPhaseLoad.java:188) > >> > > > at > >> > > > > >> > > > >> org.hibernate.engine.internal.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:144) > >> > > > at > >> > > > > >> > > > >> org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.performTwoPhaseLoad(AbstractRowReader.java:244) > >> > > > at > >> > > > > >> > > > >> org.hibernate.loader.plan.exec.process.internal.AbstractRowReader.finishUp(AbstractRowReader.java:215) > >> > > > at > >> > > > > >> > > > >> org.hibernate.loader.plan.exec.process.internal.ResultSetProcessorImpl.extractResults(ResultSetProcessorImpl.java:140) > >> > > > at > >> > > > > >> > > > >> org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:138) > >> > > > at > >> > > > > >> > > > >> org.hibernate.loader.plan.exec.internal.AbstractLoadPlanBasedLoader.executeLoad(AbstractLoadPlanBasedLoader.java:102) > >> > > > at > >> > > > > >> > > > >> org.hibernate.loader.entity.plan.AbstractLoadPlanBasedEntityLoader.load(AbstractLoadPlanBasedEntityLoader.java:186) > >> > > > at > >> > > > > >> > > > >> org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:4126) > >> > > > at > >> > > > > >> > > > >> org.hibernate.event.internal.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:503) > >> > > > at > >> > > > > >> > > > >> org.hibernate.event.internal.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:468) > >> > > > at > >> > > > > >> > > > >> org.hibernate.event.internal.DefaultLoadEventListener.load(DefaultLoadEventListener.java:213) > >> > > > at > >> > > > > >> > > > >> org.hibernate.event.internal.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:275) > >> > > > at > >> > > > > >> > > > >> org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:151) > >> > > > at > >> > > org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1070) > >> > > > at > >> > > org.hibernate.internal.SessionImpl.access$2000(SessionImpl.java:176) > >> > > > at > >> > > > > >> > > > >> org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2551) > >> > > > at > >> org.hibernate.internal.SessionImpl.get(SessionImpl.java:955) > >> > > > at > >> > > > > >> > > > >> org.hibernate.jpa.spi.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:1110) > >> > > > ... 36 more > >> > > > Caused by: java.lang.IllegalArgumentException: Can not set boolean > >> field > >> > > > org.keycloak.models.jpa.entities.ClientEntity.directGrantsOnly to > >> null > >> > > value > >> > > > at > >> > > > > >> > > > >> sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164) > >> > > > [rt.jar:1.7.0_65] > >> > > > at > >> > > > > >> > > > >> sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168) > >> > > > [rt.jar:1.7.0_65] > >> > > > at > >> > > > > >> > > > >> sun.reflect.UnsafeBooleanFieldAccessorImpl.set(UnsafeBooleanFieldAccessorImpl.java:80) > >> > > > [rt.jar:1.7.0_65] > >> > > > at java.lang.reflect.Field.set(Field.java:741) > >> [rt.jar:1.7.0_65] > >> > > > at > >> > > > > >> > > > >> org.hibernate.property.DirectPropertyAccessor$DirectSetter.set(DirectPropertyAccessor.java:122) > >> > > > ... 58 more > >> > > > > >> > > > -- > >> > > > Matthew Casperson > >> > > > Senior Front End Developer > >> > > > Technology, Space & Distribution > >> > > > Auto & General Holdings Pty Ltd > >> > > > P: 07) 3377 8751 (Direct: 3377 8751 ) > >> > > > F: 07) 3377 8833 > >> > > > > >> > > > > >> > > > > >> > > > This email is sent by Auto & General Insurance Company Ltd, Auto & > >> > > General > >> > > > Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body > >> > > > corporate (Auto & General) and is for the intended addressee. > >> > > > The views expressed in this email and attachments (email) reflect > >> the > >> > > views > >> > > > of the stated author but may not reflect views of Auto & General. > >> This > >> > > email > >> > > > is confidential and subject to copyright. > >> > > > It may be privileged. If you are not the intended addressee, > >> > > confidentiality > >> > > > and privilege have not been waived and any use, interference with, > >> or > >> > > > disclosure of this email is unauthorised. > >> > > > If you are not the intended addressee please immediately notify the > >> > > sender > >> > > > and then delete the email. Auto & General does not warrant that this > >> > > email > >> > > > is error or virus free. > >> > > > > >> > > > _______________________________________________ > >> > > > keycloak-dev mailing list > >> > > > keycloak-dev at lists.jboss.org > >> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > > >> > > >> > > >> > > >> > -- > >> > *Matthew Casperson* > >> > *Senior Front End Developer* > >> > Technology, Space & Distribution > >> > Auto & General Holdings Pty Ltd > >> > P: 07) 3377 8751 (Direct: 3377 8751) > >> > F: 07) 3377 8833 > >> > > >> > -- > >> > > >> > > >> > This email is sent by Auto & General Insurance Company Ltd, Auto & > >> General > >> > Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body > >> > corporate (Auto & General) and is for the intended addressee. > >> > The views expressed in this email and attachments (email) reflect the > >> views > >> > of the stated author but may not reflect views of Auto & General. This > >> email > >> > is confidential and subject to copyright. > >> > It may be privileged. If you are not the intended addressee, > >> confidentiality > >> > and privilege have not been waived and any use, interference with, or > >> > disclosure of this email is unauthorised. > >> > If you are not the intended addressee please immediately notify the > >> sender > >> > and then delete the email. Auto & General does not warrant that this > >> email > >> > is error or virus free. > >> > > >> > > >> > > > > > > > > -- > > *Matthew Casperson* > > *Senior Front End Developer* > > Technology, Space & Distribution > > Auto & General Holdings Pty Ltd > > P: 07) 3377 8751 (Direct: 3377 8751) > > F: 07) 3377 8833 > > > > > > > > > -- > *Matthew Casperson* > *Senior Front End Developer* > Technology, Space & Distribution > Auto & General Holdings Pty Ltd > P: 07) 3377 8751 (Direct: 3377 8751) > F: 07) 3377 8833 > > -- > > > This email is sent by Auto & General Insurance Company Ltd, Auto & General > Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body > corporate (Auto & General) and is for the intended addressee. > The views expressed in this email and attachments (email) reflect the views > of the stated author but may not reflect views of Auto & General. This email > is confidential and subject to copyright. > It may be privileged. If you are not the intended addressee, confidentiality > and privilege have not been waived and any use, interference with, or > disclosure of this email is unauthorised. > If you are not the intended addressee please immediately notify the sender > and then delete the email. Auto & General does not warrant that this email > is error or virus free. > > From stian at redhat.com Wed May 20 00:58:57 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 20 May 2015 00:58:57 -0400 (EDT) Subject: [keycloak-dev] Docs moved to github.io In-Reply-To: <1395238099.2082838.1432097902720.JavaMail.zimbra@redhat.com> Message-ID: <1830426098.2082851.1432097937468.JavaMail.zimbra@redhat.com> The docs on keycloak.org/docs has moved to github.io. This makes them faster to load, but also simpler to upload. From stian at redhat.com Wed May 20 03:44:15 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 20 May 2015 03:44:15 -0400 (EDT) Subject: [keycloak-dev] Why does WildFly CLI suck? In-Reply-To: <555B42E1.9000505@redhat.com> References: <555B3DBE.6080900@redhat.com> <555B42E1.9000505@redhat.com> Message-ID: <1100648239.2139559.1432107855894.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Tuesday, 19 May, 2015 4:04:17 PM > Subject: Re: [keycloak-dev] Why does WildFly CLI suck? > > CLI is a UI. Generically rendered UIs generally suck. For example, did > not managing JBoss 4.x and earlier suck using some generic JMX UI > renderer? CLI falls into this category IMO. +1 I've never been able to achieve anything without googling for a recipe The fact that there's alternative commands for doing common tasks suggests that I'm not the only one. For example adding a data-source can be done with: /subsystem=datasources/data-source=MigrateDS:add(jndi-name=java:jboss/datasources/MigrateDS, pool-name=MigrateDS, driver-name=h2, connection-url=jdbc:h2:mem:test;DB_CLOSE_DELAY=-1) or data-source add ... The first auto-generated one is very hard to use, the whole syntax of the cli is weird in the first place and figuring how to puzzle that together is hopeless. The last one is much better, but there's very few of those easy to use commands available. > > On 5/19/2015 9:42 AM, Stan Silvert wrote: > > I've probably been too involved with it to be objective. What are the > > usability issues? > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From ssilvert at redhat.com Wed May 20 07:47:58 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Wed, 20 May 2015 07:47:58 -0400 Subject: [keycloak-dev] Why does WildFly CLI suck? In-Reply-To: <1100648239.2139559.1432107855894.JavaMail.zimbra@redhat.com> References: <555B3DBE.6080900@redhat.com> <555B42E1.9000505@redhat.com> <1100648239.2139559.1432107855894.JavaMail.zimbra@redhat.com> Message-ID: <555C746E.80508@redhat.com> On 5/20/2015 3:44 AM, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Tuesday, 19 May, 2015 4:04:17 PM >> Subject: Re: [keycloak-dev] Why does WildFly CLI suck? >> >> CLI is a UI. Generically rendered UIs generally suck. For example, did >> not managing JBoss 4.x and earlier suck using some generic JMX UI >> renderer? CLI falls into this category IMO. > +1 I've never been able to achieve anything without googling for a recipe > > The fact that there's alternative commands for doing common tasks suggests that I'm not the only one. For example adding a data-source can be done with: > > /subsystem=datasources/data-source=MigrateDS:add(jndi-name=java:jboss/datasources/MigrateDS, pool-name=MigrateDS, driver-name=h2, connection-url=jdbc:h2:mem:test;DB_CLOSE_DELAY=-1) > > or > > data-source add ... > > The first auto-generated one is very hard to use, the whole syntax of the cli is weird in the first place and figuring how to puzzle that together is hopeless. That's what CLI GUI is for. It provides a form (with help text) for each operation and then constructs the syntax for you. (And I agree that the syntax is a little weird. I need to ask why they didn't stick with plain JSON.) > The last one is much better, but there's very few of those easy to use commands available. True. So both of you seem to be making the point that auto-generated UI's tend to suck. Humans can create a better UI to be consumed by humans. (Of course, sometimes humans create terrible UI's as well) I think the problem here is one of size. There are thousands of operations in WildFly CLI. Who is going to create all those user-friendly operations? So my point here is the same as in the earlier discussion about what should be in the Keycloak CLI. Having something is better than having nothing. Customers love the WildFly CLI compared to what was there before because before there was no CLI at all. (Incidentally, a lot of customers apparently liked the old JMX console. We got a lot of flak about removing it in WildFly.) > >> On 5/19/2015 9:42 AM, Stan Silvert wrote: >>> I've probably been too involved with it to be objective. What are the >>> usability issues? >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Wed May 20 08:25:12 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 20 May 2015 08:25:12 -0400 Subject: [keycloak-dev] Why does WildFly CLI suck? In-Reply-To: <555C746E.80508@redhat.com> References: <555B3DBE.6080900@redhat.com> <555B42E1.9000505@redhat.com> <1100648239.2139559.1432107855894.JavaMail.zimbra@redhat.com> <555C746E.80508@redhat.com> Message-ID: <555C7D28.40605@redhat.com> On 5/20/2015 7:47 AM, Stan Silvert wrote: > > On 5/20/2015 3:44 AM, Stian Thorgersen wrote: >> >> ----- Original Message ----- >>> From: "Bill Burke" >>> To: keycloak-dev at lists.jboss.org >>> Sent: Tuesday, 19 May, 2015 4:04:17 PM >>> Subject: Re: [keycloak-dev] Why does WildFly CLI suck? >>> >>> CLI is a UI. Generically rendered UIs generally suck. For example, did >>> not managing JBoss 4.x and earlier suck using some generic JMX UI >>> renderer? CLI falls into this category IMO. >> +1 I've never been able to achieve anything without googling for a recipe >> >> The fact that there's alternative commands for doing common tasks suggests that I'm not the only one. For example adding a data-source can be done with: >> >> /subsystem=datasources/data-source=MigrateDS:add(jndi-name=java:jboss/datasources/MigrateDS, pool-name=MigrateDS, driver-name=h2, connection-url=jdbc:h2:mem:test;DB_CLOSE_DELAY=-1) >> >> or >> >> data-source add ... >> >> The first auto-generated one is very hard to use, the whole syntax of the cli is weird in the first place and figuring how to puzzle that together is hopeless. > That's what CLI GUI is for. Why would somebody use CLI GUI over keycloak admin console? -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From srossillo at smartling.com Wed May 20 09:52:34 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Wed, 20 May 2015 09:52:34 -0400 Subject: [keycloak-dev] Docs moved to github.io In-Reply-To: <1830426098.2082851.1432097937468.JavaMail.zimbra@redhat.com> References: <1830426098.2082851.1432097937468.JavaMail.zimbra@redhat.com> Message-ID: <23C1EFE9-8302-4F5D-AE97-5EB572F5FF10@smartling.com> It would be nice if we could get snapshot build documentation and legacy documentation there as well. :) Similar to http://docs.spring.io/spring/docs/ has a per release documentation folder and snapshot docs are deployed as well. > On May 20, 2015, at 12:58 AM, Stian Thorgersen wrote: > > The docs on keycloak.org/docs has moved to github.io. This makes them faster to load, but also simpler to upload. > _______________________________________________ > 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/20150520/25b25d28/attachment.html From mposolda at redhat.com Wed May 20 17:33:16 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 20 May 2015 23:33:16 +0200 Subject: [keycloak-dev] Progress on LDAP enhancements Message-ID: <555CFD9C.3020002@redhat.com> I think I am finished with step 1 prototype on LDAP enhancements. Right now it's just in my local fork https://github.com/mposolda/keycloak/tree/ldap , I can't send PR as model and admin console are kind of broken in my fork (ATM I am testing with some hardcoded configs). What I did so far: - Refactoring and simplifying of forked picketlink LDAP code and removed some abstractions to make it easier to use - Added UserFederationMapper SPI. The plan is to be in line with already existing ProtocolMappers and IdentityProviderMappers. - Added LDAPFederationMapper. This mapper is invoked from LDAPFederationProvider and provides some callbacks and extension points. For more details, see methods and javadoc: https://github.com/mposolda/keycloak/blob/ldap/federation/ldap/src/main/java/org/keycloak/federation/ldap/mappers/LDAPFederationMapper.java . I have 3 implementations right now: -- UserAttributeLDAPFederationMapper - This is used to map LDAP attributes to UserModel attributes/properties . -- FullNameLDAPFederationMapper - Many LDAP deployments store fullName of user in single LDAP attribute (usually "cn" attribute). So this allows to map fullName from LDAP to firstName and lastName on UserModel -- RoleLDAPFederationMapper - allows to map LDAP roles and user role mappings from some DN in LDAP tree to either realm roles or client roles of some client. Of course it's not a problem to plug more mappers, so it's not an issue to map for example LDAP roles from tree "ou=finance,dc=myorg,dc=org" to client roles of client "finance" and roles from tree "ou=development,dc=myorg,dc=org" to client roles of client "development" etc. - Minor refactoring of some methods on UserFederationProvider interface. I needed to add RealmModel as parameter to some methods (it was already in most of them) because RealmModel will be used to retrieve list of configured UserFederationMapperModels . Next planned steps: - Model - I plan to add CRUD for UserFederationMapperModel to RealmModel (similarly like IdentityProviderMapperModel) - Admin console - I've been thinking about new tab "Mappers" under "User Federation". The tab will be active when you have some Federation provider chosen and it will allow to add/update/remove mappers for particular provider. Again something very similar to already existing broker mappers. WDYT? - Address remaining subtasks of https://issues.jboss.org/browse/KEYCLOAK-886 . Not everything will be addressed by mappers. For example there is performance issue https://issues.jboss.org/browse/KEYCLOAK-838 . I am thinking about adding some caching at LDAPIdentityStore level, but also I am thinking about some simple per-request caching at UserFederationManager level, which might help with federation performance in general (not just specific to LDAP). Maybe combination of both? But I am not sure atm... - DB migration Question: I wonder if we can put RealmModel accessible from UserFederationProviderModel? It shouldn't be a problem from implementation perspective as UserFederationProviderModel CRUD methods are on RealmModel, so realm can just inject itself before return UserFederationProviderModel. Since UserFederationProvider instances are created by method "getInstance" on UserFederationProviderFactory, which has UserFederationProviderModel as one of parameters, it will make RealmModel accessible in UserFederationProvider and hence it won't be needed to have RealmModel in signature of methods on UserFederationProvider. WDYT? Marek From ssilvert at redhat.com Thu May 21 08:56:15 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Thu, 21 May 2015 08:56:15 -0400 Subject: [keycloak-dev] Why does WildFly CLI suck? In-Reply-To: <555C7D28.40605@redhat.com> References: <555B3DBE.6080900@redhat.com> <555B42E1.9000505@redhat.com> <1100648239.2139559.1432107855894.JavaMail.zimbra@redhat.com> <555C746E.80508@redhat.com> <555C7D28.40605@redhat.com> Message-ID: <555DD5EF.6040002@redhat.com> On 5/20/2015 8:25 AM, Bill Burke wrote: > > On 5/20/2015 7:47 AM, Stan Silvert wrote: >> On 5/20/2015 3:44 AM, Stian Thorgersen wrote: >>> ----- Original Message ----- >>>> From: "Bill Burke" >>>> To: keycloak-dev at lists.jboss.org >>>> Sent: Tuesday, 19 May, 2015 4:04:17 PM >>>> Subject: Re: [keycloak-dev] Why does WildFly CLI suck? >>>> >>>> CLI is a UI. Generically rendered UIs generally suck. For example, did >>>> not managing JBoss 4.x and earlier suck using some generic JMX UI >>>> renderer? CLI falls into this category IMO. >>> +1 I've never been able to achieve anything without googling for a recipe >>> >>> The fact that there's alternative commands for doing common tasks suggests that I'm not the only one. For example adding a data-source can be done with: >>> >>> /subsystem=datasources/data-source=MigrateDS:add(jndi-name=java:jboss/datasources/MigrateDS, pool-name=MigrateDS, driver-name=h2, connection-url=jdbc:h2:mem:test;DB_CLOSE_DELAY=-1) >>> >>> or >>> >>> data-source add ... >>> >>> The first auto-generated one is very hard to use, the whole syntax of the cli is weird in the first place and figuring how to puzzle that together is hopeless. >> That's what CLI GUI is for. > Why would somebody use CLI GUI over keycloak admin console? > I assume you mean "Why use CLI GUI over WildFly admin console.?" :-) Here's a top 11 list: 1) WildFly admin console is not complete. It doesn't come close to covering all the operations. CLI GUI gives you everything, with help text included. 2) New subsystems don't show up in admin console. You have to write a GWT UI for it by hand and give it to the admin console team. Then you have to wait for them to release it. CLI GUI gives you a UI for everything automatically. 3) If you are creating a script, CLI GUI helps you formulate the syntax of the operations. 4) You can run scripts from CLI GUI. Can't do that from admin console. Also, CLI GUI remembers your recently run scripts so you can find and execute them quickly. 5) CLI GUI lets you browse the entire management tree and learn about what is available. It's a great teaching tool. 6) If run locally, you don't need to log in to CLI GUI. 7) If run locally, CLI GUI survives a server restart. You don't need to reconnect. Great for development where you restart often. 8) CLI GUI is very small. Admin console is huge. In fact, about half of the WildFly download comes from the admin console. 9) CLI GUI runs inside jconsole. So you can monitor the server and execute commands in the same UI. Admin console's monitoring capability is very limited. 10) CLI GUI's "verbose" mode shows you the full request and response. That's very handy when writing DMR code and you need to learn exactly how the request and response are structured. 11) CLI GUI lets you download server logs. Admin console still doesn't have this important feature. And all that comes from a tool that I've probably spent a total of six weeks working on. How much did admin console cost to develop? So far, two full time developers have worked on it for the last 3 to 4 years. Stan From leonardo.zanivan at gmail.com Thu May 21 11:39:12 2015 From: leonardo.zanivan at gmail.com (Leonardo Loch Zanivan) Date: Thu, 21 May 2015 15:39:12 +0000 Subject: [keycloak-dev] [keycloak-user] Securing one .war with two .json In-Reply-To: References: Message-ID: Look at multi-tenant example https://github.com/keycloak/keycloak/tree/master/examples/multi-tenant On Thu, May 21, 2015 at 12:31 PM Carlos Feria wrote: > Good morning. How can i configure one .war with two .json? > > I have two realms, these access the same .war (restfull bearer only), but > my problem is that a .war can just one realm dependencie. > > I see that *keycloak* have a application with *realm-management* name and > this application is registered in more than one realms but all realms can > access to *realm-management* without problems. > > How can i do the same with my .war like *realm-management.* > > I need registrer my .war in two realms. Please help me. > > -- > Carlos E. Feria Vila > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150521/f471a469/attachment.html From mstrukel at redhat.com Thu May 21 16:56:40 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Thu, 21 May 2015 16:56:40 -0400 (EDT) Subject: [keycloak-dev] User apps and HttpClient In-Reply-To: <985152942.2784763.1432240539712.JavaMail.zimbra@redhat.com> Message-ID: <60533052.2790794.1432241800924.JavaMail.zimbra@redhat.com> We package examples with jboss-deployment-structure.xml that looks like this: If we drop a .war containing this into Wildfly 9 (distribution/server-dist - ATM distribution/demo-dist, and distribution/adapters/wildfly-adapter-zip look buggy as they still use slot=4.3), things are fine. However, if we dropped this into Wildfly 8 with keycloak adapter modules using org.apache.httpcomponents slot=4.3, we get a java.lang.LinkageError as soon as some Keycloak logic is triggered by user app. The question: how come jboss modules isolation doesn?t kick in and allow keycloak adapter modules to use slot=4.3 while at the same time user app (our examples) uses slot=main? The answer is that org.keycloak.adapters.HttpClientBuilder which seems to be our helper class for org.apache.httpcomponents inevitably leaks the version of HttpClient its module refers to - can?t be any other way (unless we change the code to use client app?s classloader - opening a can of worms). Any user app using HttpClientBuilder.build() method receives an instance of HttpClient loaded through org.keycloak.keycloak-adapter-core module, and transitively through org.apache.httpcomponents referred to therein. Any attempt of an application (.war) to package its own httpcomponents jars, or to refer to a different jboss module than the exact one referred to by org.keycloak.keycloak-adapter-core will result in ?catastrophic failure?. Example: HttpClient client = new HttpClientBuilder().disableTrustManager().build(); HttpClient on the left is loaded by app?s classloader. The one returned by build() on the right is loaded by org.keycloak.keycloak-adapter-core module?s version of httpcomponents. If it?s not the same classloader (jboss module) on both sides loading HttpClient you get a LinkageError. In light of this I wonder if it wasn?t the best solution to reexport org.apache.httpcomponents to .wars by default, thereby removing the necessity to package jboss-deployment-structure.xml at all, and ensuring that user application always uses the proper module. Currently jboss-deployment-structure.xml is required for wildfly / as7, and is a nuisance, especially as it has to be different (refer to slot=4.3) for Wildfly 8. If using HttpClientBuilder is supposed to be completely optional, we could maybe add configuration to keycloak subsystem to control exposing it to all or specific secure deployments. We could simply add another common attribute that can be used in and . We could expose it by default and have something like: false to inhibit exposing it if a situation calls for it. WDYT? From ssilvert at redhat.com Thu May 21 19:58:01 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Thu, 21 May 2015 19:58:01 -0400 Subject: [keycloak-dev] User apps and HttpClient In-Reply-To: <60533052.2790794.1432241800924.JavaMail.zimbra@redhat.com> References: <60533052.2790794.1432241800924.JavaMail.zimbra@redhat.com> Message-ID: <555E7109.10608@redhat.com> On 5/21/2015 4:56 PM, Marko Strukelj wrote: > We package examples with jboss-deployment-structure.xml that looks like this: > > > > > > > > > > > > If we drop a .war containing this into Wildfly 9 (distribution/server-dist - ATM distribution/demo-dist, and distribution/adapters/wildfly-adapter-zip look buggy as they still use slot=4.3), things are fine. > > However, if we dropped this into Wildfly 8 with keycloak adapter modules using org.apache.httpcomponents slot=4.3, we get a java.lang.LinkageError as soon as some Keycloak logic is triggered by user app. > > The question: how come jboss modules isolation doesn?t kick in and allow keycloak adapter modules to use slot=4.3 while at the same time user app (our examples) uses slot=main? > > The answer is that org.keycloak.adapters.HttpClientBuilder which seems to be our helper class for org.apache.httpcomponents inevitably leaks the version of HttpClient its module refers to - can?t be any other way (unless we change the code to use client app?s classloader - opening a can of worms). Any user app using HttpClientBuilder.build() method receives an instance of HttpClient loaded through org.keycloak.keycloak-adapter-core module, and transitively through org.apache.httpcomponents referred to therein. > > Any attempt of an application (.war) to package its own httpcomponents jars, or to refer to a different jboss module than the exact one referred to by org.keycloak.keycloak-adapter-core will result in ?catastrophic failure?. Example: > > > HttpClient client = new HttpClientBuilder().disableTrustManager().build(); > > > HttpClient on the left is loaded by app?s classloader. The one returned by build() on the right is loaded by org.keycloak.keycloak-adapter-core module?s version of httpcomponents. If it?s not the same classloader (jboss module) on both sides loading HttpClient you get a LinkageError. > > > In light of this I wonder if it wasn?t the best solution to reexport org.apache.httpcomponents to .wars by default, thereby removing the necessity to package jboss-deployment-structure.xml at all, and ensuring that user application always uses the proper module. > > Currently jboss-deployment-structure.xml is required for wildfly / as7, and is a nuisance, especially as it has to be different (refer to slot=4.3) for Wildfly 8. > > If using HttpClientBuilder is supposed to be completely optional, we could maybe add configuration to keycloak subsystem to control exposing it to all or specific secure deployments. > > We could simply add another common attribute that can be used in and . We could expose it by default and have something like: > > false > > to inhibit exposing it if a situation calls for it. > > > WDYT? What do I think? I think that classloading questions always make my head hurt! The best solution would be to find a way to detect the problem and fix it at deploy time. Using a DependencyProcessor, it should be possible to detect that the deployment contains the same module from two different slots. Then pick the best slot and spit out a warning message that you are removing the undesirable module. It should be possible, but I don't know if it actually _IS_ possible. A version mismatch between modules is like a cancer. I think you should speak to an oncologist or David Lloyd. Since Red Hat doesn't employ any oncologists, go with David. :-) > > > > _______________________________________________ > 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/20150521/a8d43276/attachment-0001.html From stian at redhat.com Fri May 22 03:00:31 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 22 May 2015 03:00:31 -0400 (EDT) Subject: [keycloak-dev] User apps and HttpClient In-Reply-To: <60533052.2790794.1432241800924.JavaMail.zimbra@redhat.com> References: <60533052.2790794.1432241800924.JavaMail.zimbra@redhat.com> Message-ID: <98911381.3786626.1432278031515.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Marko Strukelj" > To: "keycloak dev" > Sent: Thursday, 21 May, 2015 10:56:40 PM > Subject: [keycloak-dev] User apps and HttpClient > > We package examples with jboss-deployment-structure.xml that looks like this: > > > > > > > > > > > > If we drop a .war containing this into Wildfly 9 (distribution/server-dist - > ATM distribution/demo-dist, and distribution/adapters/wildfly-adapter-zip > look buggy as they still use slot=4.3), things are fine. > > However, if we dropped this into Wildfly 8 with keycloak adapter modules > using org.apache.httpcomponents slot=4.3, we get a java.lang.LinkageError as > soon as some Keycloak logic is triggered by user app. > > The question: how come jboss modules isolation doesn?t kick in and allow > keycloak adapter modules to use slot=4.3 while at the same time user app > (our examples) uses slot=main? > > The answer is that org.keycloak.adapters.HttpClientBuilder which seems to be > our helper class for org.apache.httpcomponents inevitably leaks the version > of HttpClient its module refers to - can?t be any other way (unless we > change the code to use client app?s classloader - opening a can of worms). > Any user app using HttpClientBuilder.build() method receives an instance of > HttpClient loaded through org.keycloak.keycloak-adapter-core module, and > transitively through org.apache.httpcomponents referred to therein. > > Any attempt of an application (.war) to package its own httpcomponents jars, > or to refer to a different jboss module than the exact one referred to by > org.keycloak.keycloak-adapter-core will result in ?catastrophic failure?. > Example: > > > HttpClient client = new > HttpClientBuilder().disableTrustManager().build(); > > > HttpClient on the left is loaded by app?s classloader. The one returned by > build() on the right is loaded by org.keycloak.keycloak-adapter-core > module?s version of httpcomponents. If it?s not the same classloader (jboss > module) on both sides loading HttpClient you get a LinkageError. HttpClientBuilder is an internal helper class and shouldn't be used directly by applications. We just need to rewrite the examples to not use it and Bob's your uncle the problem is no longer ;) > > > In light of this I wonder if it wasn?t the best solution to reexport > org.apache.httpcomponents to .wars by default, thereby removing the > necessity to package jboss-deployment-structure.xml at all, and ensuring > that user application always uses the proper module. > > Currently jboss-deployment-structure.xml is required for wildfly / as7, and > is a nuisance, especially as it has to be different (refer to slot=4.3) for > Wildfly 8. > > If using HttpClientBuilder is supposed to be completely optional, we could > maybe add configuration to keycloak subsystem to control exposing it to all > or specific secure deployments. > > We could simply add another common attribute that can be used in and > . We could expose it by default and have something like: > > false > > to inhibit exposing it if a situation calls for it. > > > WDYT? > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Fri May 22 03:35:30 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 22 May 2015 09:35:30 +0200 Subject: [keycloak-dev] User apps and HttpClient In-Reply-To: <98911381.3786626.1432278031515.JavaMail.zimbra@redhat.com> References: <60533052.2790794.1432241800924.JavaMail.zimbra@redhat.com> <98911381.3786626.1432278031515.JavaMail.zimbra@redhat.com> Message-ID: <555EDC42.3000707@redhat.com> On 22.5.2015 09:00, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Marko Strukelj" >> To: "keycloak dev" >> Sent: Thursday, 21 May, 2015 10:56:40 PM >> Subject: [keycloak-dev] User apps and HttpClient >> >> We package examples with jboss-deployment-structure.xml that looks like this: >> >> >> >> >> >> >> >> >> >> >> >> If we drop a .war containing this into Wildfly 9 (distribution/server-dist - >> ATM distribution/demo-dist, and distribution/adapters/wildfly-adapter-zip >> look buggy as they still use slot=4.3), things are fine. >> >> However, if we dropped this into Wildfly 8 with keycloak adapter modules >> using org.apache.httpcomponents slot=4.3, we get a java.lang.LinkageError as >> soon as some Keycloak logic is triggered by user app. >> >> The question: how come jboss modules isolation doesn?t kick in and allow >> keycloak adapter modules to use slot=4.3 while at the same time user app >> (our examples) uses slot=main? >> >> The answer is that org.keycloak.adapters.HttpClientBuilder which seems to be >> our helper class for org.apache.httpcomponents inevitably leaks the version >> of HttpClient its module refers to - can?t be any other way (unless we >> change the code to use client app?s classloader - opening a can of worms). >> Any user app using HttpClientBuilder.build() method receives an instance of >> HttpClient loaded through org.keycloak.keycloak-adapter-core module, and >> transitively through org.apache.httpcomponents referred to therein. >> >> Any attempt of an application (.war) to package its own httpcomponents jars, >> or to refer to a different jboss module than the exact one referred to by >> org.keycloak.keycloak-adapter-core will result in ?catastrophic failure?. >> Example: >> >> >> HttpClient client = new >> HttpClientBuilder().disableTrustManager().build(); >> >> >> HttpClient on the left is loaded by app?s classloader. The one returned by >> build() on the right is loaded by org.keycloak.keycloak-adapter-core >> module?s version of httpcomponents. If it?s not the same classloader (jboss >> module) on both sides loading HttpClient you get a LinkageError. > HttpClientBuilder is an internal helper class and shouldn't be used directly by applications. We just need to rewrite the examples to not use it and Bob's your uncle the problem is no longer ;) Not directly related, but I wonder if we should do the same for JsonSerialization class? I remember some time ago someone complained on keycloak-user ML that something doesn't work for him as expected and you or Bill answered that it's just internal class. However since our examples are using it, we can't expect people to not use it in their own apps ;-) Marek > >> >> In light of this I wonder if it wasn?t the best solution to reexport >> org.apache.httpcomponents to .wars by default, thereby removing the >> necessity to package jboss-deployment-structure.xml at all, and ensuring >> that user application always uses the proper module. >> >> Currently jboss-deployment-structure.xml is required for wildfly / as7, and >> is a nuisance, especially as it has to be different (refer to slot=4.3) for >> Wildfly 8. >> >> If using HttpClientBuilder is supposed to be completely optional, we could >> maybe add configuration to keycloak subsystem to control exposing it to all >> or specific secure deployments. >> >> We could simply add another common attribute that can be used in and >> . We could expose it by default and have something like: >> >> false >> >> to inhibit exposing it if a situation calls for it. >> >> >> WDYT? >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mstrukel at redhat.com Fri May 22 03:38:49 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Fri, 22 May 2015 03:38:49 -0400 (EDT) Subject: [keycloak-dev] User apps and HttpClient In-Reply-To: <98911381.3786626.1432278031515.JavaMail.zimbra@redhat.com> References: <60533052.2790794.1432241800924.JavaMail.zimbra@redhat.com> <98911381.3786626.1432278031515.JavaMail.zimbra@redhat.com> Message-ID: <1111124532.2952078.1432280329274.JavaMail.zimbra@redhat.com> That's a great solution :) I suppose most / all? of adapter modules should also be marked as internal modules, so that there is a warning in the log if a user pulls them in as dependencies. ----- Original Message ----- > > > ----- Original Message ----- > > From: "Marko Strukelj" > > To: "keycloak dev" > > Sent: Thursday, 21 May, 2015 10:56:40 PM > > Subject: [keycloak-dev] User apps and HttpClient > > > > We package examples with jboss-deployment-structure.xml that looks like > > this: > > > > > > > > > > > > > > > > > > > > > > > > If we drop a .war containing this into Wildfly 9 (distribution/server-dist > > - > > ATM distribution/demo-dist, and distribution/adapters/wildfly-adapter-zip > > look buggy as they still use slot=4.3), things are fine. > > > > However, if we dropped this into Wildfly 8 with keycloak adapter modules > > using org.apache.httpcomponents slot=4.3, we get a java.lang.LinkageError > > as > > soon as some Keycloak logic is triggered by user app. > > > > The question: how come jboss modules isolation doesn?t kick in and allow > > keycloak adapter modules to use slot=4.3 while at the same time user app > > (our examples) uses slot=main? > > > > The answer is that org.keycloak.adapters.HttpClientBuilder which seems to > > be > > our helper class for org.apache.httpcomponents inevitably leaks the version > > of HttpClient its module refers to - can?t be any other way (unless we > > change the code to use client app?s classloader - opening a can of worms). > > Any user app using HttpClientBuilder.build() method receives an instance of > > HttpClient loaded through org.keycloak.keycloak-adapter-core module, and > > transitively through org.apache.httpcomponents referred to therein. > > > > Any attempt of an application (.war) to package its own httpcomponents > > jars, > > or to refer to a different jboss module than the exact one referred to by > > org.keycloak.keycloak-adapter-core will result in ?catastrophic failure?. > > Example: > > > > > > HttpClient client = new > > HttpClientBuilder().disableTrustManager().build(); > > > > > > HttpClient on the left is loaded by app?s classloader. The one returned by > > build() on the right is loaded by org.keycloak.keycloak-adapter-core > > module?s version of httpcomponents. If it?s not the same classloader (jboss > > module) on both sides loading HttpClient you get a LinkageError. > > HttpClientBuilder is an internal helper class and shouldn't be used directly > by applications. We just need to rewrite the examples to not use it and > Bob's your uncle the problem is no longer ;) > > > > > > > In light of this I wonder if it wasn?t the best solution to reexport > > org.apache.httpcomponents to .wars by default, thereby removing the > > necessity to package jboss-deployment-structure.xml at all, and ensuring > > that user application always uses the proper module. > > > > Currently jboss-deployment-structure.xml is required for wildfly / as7, and > > is a nuisance, especially as it has to be different (refer to slot=4.3) for > > Wildfly 8. > > > > If using HttpClientBuilder is supposed to be completely optional, we could > > maybe add configuration to keycloak subsystem to control exposing it to all > > or specific secure deployments. > > > > We could simply add another common attribute that can be used in > > and > > . We could expose it by default and have something like: > > > > false > > > > to inhibit exposing it if a situation calls for it. > > > > > > WDYT? > > > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From matzew at apache.org Fri May 22 03:44:29 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 22 May 2015 09:44:29 +0200 Subject: [keycloak-dev] Error using Keycloak 1.2.0 Message-ID: Hi, yesterday we started to get onto 1.2.0 (on 1.1.0 before), and a few changes were required: https://github.com/matzew/aerogear-unifiedpush-server/commit/c418b96bff2a921b4d47075556c93c5a17078260 But now the deployment on WF 8.2, gives me this: https://gist.github.com/matzew/47805bd3aa1320a3cd51 But I am not sure what's not missing regarding the missing template :-( -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150522/fe80eb31/attachment.html From stian at redhat.com Fri May 22 03:49:33 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 22 May 2015 03:49:33 -0400 (EDT) Subject: [keycloak-dev] User apps and HttpClient In-Reply-To: <1111124532.2952078.1432280329274.JavaMail.zimbra@redhat.com> References: <60533052.2790794.1432241800924.JavaMail.zimbra@redhat.com> <98911381.3786626.1432278031515.JavaMail.zimbra@redhat.com> <1111124532.2952078.1432280329274.JavaMail.zimbra@redhat.com> Message-ID: <488442622.3815540.1432280973255.JavaMail.zimbra@redhat.com> For now let's update the examples to not use internal classes, including JsonSerialization which Marek pointed out. I think the only class examples/demos should use are KeycloakSecurityContext and very few examples even needs that. Marking modules as private needs to be done as part of a bigger task, so don't do anything yet. We need to clearly define what classes/interfaces/modules are internal and which are public. It'll be easier for adapters than for the server, so we should probably start there, but we have other higher priority tasks atm. ----- Original Message ----- > From: "Marko Strukelj" > To: "Stian Thorgersen" > Cc: "keycloak dev" > Sent: Friday, 22 May, 2015 9:38:49 AM > Subject: Re: [keycloak-dev] User apps and HttpClient > > That's a great solution :) > > I suppose most / all? of adapter modules should also be marked as internal > modules, so that there is a warning in the log if a user pulls them in as > dependencies. > > ----- Original Message ----- > > > > > > ----- Original Message ----- > > > From: "Marko Strukelj" > > > To: "keycloak dev" > > > Sent: Thursday, 21 May, 2015 10:56:40 PM > > > Subject: [keycloak-dev] User apps and HttpClient > > > > > > We package examples with jboss-deployment-structure.xml that looks like > > > this: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If we drop a .war containing this into Wildfly 9 > > > (distribution/server-dist > > > - > > > ATM distribution/demo-dist, and distribution/adapters/wildfly-adapter-zip > > > look buggy as they still use slot=4.3), things are fine. > > > > > > However, if we dropped this into Wildfly 8 with keycloak adapter modules > > > using org.apache.httpcomponents slot=4.3, we get a java.lang.LinkageError > > > as > > > soon as some Keycloak logic is triggered by user app. > > > > > > The question: how come jboss modules isolation doesn?t kick in and allow > > > keycloak adapter modules to use slot=4.3 while at the same time user app > > > (our examples) uses slot=main? > > > > > > The answer is that org.keycloak.adapters.HttpClientBuilder which seems to > > > be > > > our helper class for org.apache.httpcomponents inevitably leaks the > > > version > > > of HttpClient its module refers to - can?t be any other way (unless we > > > change the code to use client app?s classloader - opening a can of > > > worms). > > > Any user app using HttpClientBuilder.build() method receives an instance > > > of > > > HttpClient loaded through org.keycloak.keycloak-adapter-core module, and > > > transitively through org.apache.httpcomponents referred to therein. > > > > > > Any attempt of an application (.war) to package its own httpcomponents > > > jars, > > > or to refer to a different jboss module than the exact one referred to by > > > org.keycloak.keycloak-adapter-core will result in ?catastrophic failure?. > > > Example: > > > > > > > > > HttpClient client = new > > > HttpClientBuilder().disableTrustManager().build(); > > > > > > > > > HttpClient on the left is loaded by app?s classloader. The one returned > > > by > > > build() on the right is loaded by org.keycloak.keycloak-adapter-core > > > module?s version of httpcomponents. If it?s not the same classloader > > > (jboss > > > module) on both sides loading HttpClient you get a LinkageError. > > > > HttpClientBuilder is an internal helper class and shouldn't be used > > directly > > by applications. We just need to rewrite the examples to not use it and > > Bob's your uncle the problem is no longer ;) > > > > > > > > > > > In light of this I wonder if it wasn?t the best solution to reexport > > > org.apache.httpcomponents to .wars by default, thereby removing the > > > necessity to package jboss-deployment-structure.xml at all, and ensuring > > > that user application always uses the proper module. > > > > > > Currently jboss-deployment-structure.xml is required for wildfly / as7, > > > and > > > is a nuisance, especially as it has to be different (refer to slot=4.3) > > > for > > > Wildfly 8. > > > > > > If using HttpClientBuilder is supposed to be completely optional, we > > > could > > > maybe add configuration to keycloak subsystem to control exposing it to > > > all > > > or specific secure deployments. > > > > > > We could simply add another common attribute that can be used in > > > and > > > . We could expose it by default and have something > > > like: > > > > > > false > > > > > > to inhibit exposing it if a situation calls for it. > > > > > > > > > WDYT? > > > > > > > > > > > > _______________________________________________ > > > keycloak-dev mailing list > > > keycloak-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > From mstrukel at redhat.com Fri May 22 03:50:27 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Fri, 22 May 2015 03:50:27 -0400 (EDT) Subject: [keycloak-dev] User apps and HttpClient In-Reply-To: <555E7109.10608@redhat.com> References: <60533052.2790794.1432241800924.JavaMail.zimbra@redhat.com> <555E7109.10608@redhat.com> Message-ID: <1329091490.2956540.1432281027019.JavaMail.zimbra@redhat.com> I like Stian's solution much better ... it's much simpler :) @Stian: Is there some docs where I can get a better understanding of what's an API that is exposed to client, and what is implementation details never to be used by client apps ... Ideally that would be easy to establish based on package names - e.g. anything not in org.keycloak.something.impl might be an API, or nothing but what's in org.keycloak.something.api might be an API ... Or maybe we have one single module that's client API? ----- Original Message ----- > On 5/21/2015 4:56 PM, Marko Strukelj wrote: > > We package examples with jboss-deployment-structure.xml that looks like > > this: > > > > > > > > > > > > > > > > > > > > > > > > If we drop a .war containing this into Wildfly 9 (distribution/server-dist > > - > > ATM distribution/demo-dist, and distribution/adapters/wildfly-adapter-zip > > look buggy as they still use slot=4.3), things are fine. > > > However, if we dropped this into Wildfly 8 with keycloak adapter modules > > using org.apache.httpcomponents slot=4.3, we get a java.lang.LinkageError > > as > > soon as some Keycloak logic is triggered by user app. > > > The question: how come jboss modules isolation doesn?t kick in and allow > > keycloak adapter modules to use slot=4.3 while at the same time user app > > (our examples) uses slot=main? > > > The answer is that org.keycloak.adapters.HttpClientBuilder which seems to > > be > > our helper class for org.apache.httpcomponents inevitably leaks the version > > of HttpClient its module refers to - can?t be any other way (unless we > > change the code to use client app?s classloader - opening a can of worms). > > Any user app using HttpClientBuilder.build() method receives an instance of > > HttpClient loaded through org.keycloak.keycloak-adapter-core module, and > > transitively through org.apache.httpcomponents referred to therein. > > > Any attempt of an application (.war) to package its own httpcomponents > > jars, > > or to refer to a different jboss module than the exact one referred to by > > org.keycloak.keycloak-adapter-core will result in ?catastrophic failure?. > > Example: > > > HttpClient client = new HttpClientBuilder().disableTrustManager().build(); > > > HttpClient on the left is loaded by app?s classloader. The one returned by > > build() on the right is loaded by org.keycloak.keycloak-adapter-core > > module?s version of httpcomponents. If it?s not the same classloader (jboss > > module) on both sides loading HttpClient you get a LinkageError. > > > In light of this I wonder if it wasn?t the best solution to reexport > > org.apache.httpcomponents to .wars by default, thereby removing the > > necessity to package jboss-deployment-structure.xml at all, and ensuring > > that user application always uses the proper module. > > > Currently jboss-deployment-structure.xml is required for wildfly / as7, and > > is a nuisance, especially as it has to be different (refer to slot=4.3) for > > Wildfly 8. > > > If using HttpClientBuilder is supposed to be completely optional, we could > > maybe add configuration to keycloak subsystem to control exposing it to all > > or specific secure deployments. > > > We could simply add another common attribute that can be used in > > and > > . We could expose it by default and have something like: > > > false > > > to inhibit exposing it if a situation calls for it. > > > WDYT? > > What do I think? I think that classloading questions always make my head > hurt! > The best solution would be to find a way to detect the problem and fix it at > deploy time. Using a DependencyProcessor, it should be possible to detect > that the deployment contains the same module from two different slots. Then > pick the best slot and spit out a warning message that you are removing the > undesirable module. > It should be possible, but I don't know if it actually IS possible. A version > mismatch between modules is like a cancer. I think you should speak to an > oncologist or David Lloyd. Since Red Hat doesn't employ any oncologists, go > with David. :-) > > _______________________________________________ > > > 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/20150522/5732b8e0/attachment-0001.html From stian at redhat.com Fri May 22 03:59:23 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 22 May 2015 03:59:23 -0400 (EDT) Subject: [keycloak-dev] User apps and HttpClient In-Reply-To: <1329091490.2956540.1432281027019.JavaMail.zimbra@redhat.com> References: <60533052.2790794.1432241800924.JavaMail.zimbra@redhat.com> <555E7109.10608@redhat.com> <1329091490.2956540.1432281027019.JavaMail.zimbra@redhat.com> Message-ID: <1241926539.3818527.1432281563043.JavaMail.zimbra@redhat.com> For now let's just make sure examples don't use HttpClientBuilder. That should be relatively quick to fix and solves you're problem. We can worry about the rest later when we start defining public/private stuff. ----- Original Message ----- > From: "Marko Strukelj" > To: "Stan Silvert" > Cc: keycloak-dev at lists.jboss.org > Sent: Friday, 22 May, 2015 9:50:27 AM > Subject: Re: [keycloak-dev] User apps and HttpClient > > I like Stian's solution much better ... it's much simpler :) > > @Stian: Is there some docs where I can get a better understanding of what's > an API that is exposed to client, and what is implementation details never > to be used by client apps ... > > Ideally that would be easy to establish based on package names - e.g. > anything not in org.keycloak.something.impl might be an API, or nothing but > what's in org.keycloak.something.api might be an API ... > Or maybe we have one single module that's client API? > > > > > > > On 5/21/2015 4:56 PM, Marko Strukelj wrote: > > > > We package examples with jboss-deployment-structure.xml that looks like this: > > > > > > > > > > > > If we drop a .war containing this into Wildfly 9 (distribution/server-dist - > ATM distribution/demo-dist, and distribution/adapters/wildfly-adapter-zip > look buggy as they still use slot=4.3), things are fine. > > However, if we dropped this into Wildfly 8 with keycloak adapter modules > using org.apache.httpcomponents slot=4.3, we get a java.lang.LinkageError as > soon as some Keycloak logic is triggered by user app. > > The question: how come jboss modules isolation doesn?t kick in and allow > keycloak adapter modules to use slot=4.3 while at the same time user app > (our examples) uses slot=main? > > The answer is that org.keycloak.adapters.HttpClientBuilder which seems to be > our helper class for org.apache.httpcomponents inevitably leaks the version > of HttpClient its module refers to - can?t be any other way (unless we > change the code to use client app?s classloader - opening a can of worms). > Any user app using HttpClientBuilder.build() method receives an instance of > HttpClient loaded through org.keycloak.keycloak-adapter-core module, and > transitively through org.apache.httpcomponents referred to therein. > > Any attempt of an application (.war) to package its own httpcomponents jars, > or to refer to a different jboss module than the exact one referred to by > org.keycloak.keycloak-adapter-core will result in ?catastrophic failure?. > Example: > > > HttpClient client = new > HttpClientBuilder().disableTrustManager().build(); > > > HttpClient on the left is loaded by app?s classloader. The one returned by > build() on the right is loaded by org.keycloak.keycloak-adapter-core > module?s version of httpcomponents. If it?s not the same classloader (jboss > module) on both sides loading HttpClient you get a LinkageError. > > > In light of this I wonder if it wasn?t the best solution to reexport > org.apache.httpcomponents to .wars by default, thereby removing the > necessity to package jboss-deployment-structure.xml at all, and ensuring > that user application always uses the proper module. > > Currently jboss-deployment-structure.xml is required for wildfly / as7, and > is a nuisance, especially as it has to be different (refer to slot=4.3) for > Wildfly 8. > > If using HttpClientBuilder is supposed to be completely optional, we could > maybe add configuration to keycloak subsystem to control exposing it to all > or specific secure deployments. > > We could simply add another common attribute that can be used in and > . We could expose it by default and have something like: > > false > > to inhibit exposing it if a situation calls for it. > > > WDYT? > What do I think? I think that classloading questions always make my head > hurt! > > The best solution would be to find a way to detect the problem and fix it at > deploy time. Using a DependencyProcessor, it should be possible to detect > that the deployment contains the same module from two different slots. Then > pick the best slot and spit out a warning message that you are removing the > undesirable module. > > It should be possible, but I don't know if it actually IS possible. A version > mismatch between modules is like a cancer. I think you should speak to an > oncologist or David Lloyd. Since Red Hat doesn't employ any oncologists, go > with David. :-) > > > > _______________________________________________ > keycloak-dev mailing list keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Fri May 22 04:00:21 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 22 May 2015 04:00:21 -0400 (EDT) Subject: [keycloak-dev] User apps and HttpClient In-Reply-To: <1241926539.3818527.1432281563043.JavaMail.zimbra@redhat.com> References: <60533052.2790794.1432241800924.JavaMail.zimbra@redhat.com> <555E7109.10608@redhat.com> <1329091490.2956540.1432281027019.JavaMail.zimbra@redhat.com> <1241926539.3818527.1432281563043.JavaMail.zimbra@redhat.com> Message-ID: <1581365079.3819202.1432281621864.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Stian Thorgersen" > To: "Marko Strukelj" > Cc: "Stan Silvert" , keycloak-dev at lists.jboss.org > Sent: Friday, 22 May, 2015 9:59:23 AM > Subject: Re: [keycloak-dev] User apps and HttpClient > > For now let's just make sure examples don't use HttpClientBuilder. That > should be relatively quick to fix and solves you're problem. We can worry > about the rest later when we start defining public/private stuff. You're not the problem, I obviously meant your problem ;) > > ----- Original Message ----- > > From: "Marko Strukelj" > > To: "Stan Silvert" > > Cc: keycloak-dev at lists.jboss.org > > Sent: Friday, 22 May, 2015 9:50:27 AM > > Subject: Re: [keycloak-dev] User apps and HttpClient > > > > I like Stian's solution much better ... it's much simpler :) > > > > @Stian: Is there some docs where I can get a better understanding of what's > > an API that is exposed to client, and what is implementation details never > > to be used by client apps ... > > > > Ideally that would be easy to establish based on package names - e.g. > > anything not in org.keycloak.something.impl might be an API, or nothing but > > what's in org.keycloak.something.api might be an API ... > > Or maybe we have one single module that's client API? > > > > > > > > > > > > > > On 5/21/2015 4:56 PM, Marko Strukelj wrote: > > > > > > > > We package examples with jboss-deployment-structure.xml that looks like > > this: > > > > > > > > > > > > > > > > > > > > > > > > If we drop a .war containing this into Wildfly 9 (distribution/server-dist > > - > > ATM distribution/demo-dist, and distribution/adapters/wildfly-adapter-zip > > look buggy as they still use slot=4.3), things are fine. > > > > However, if we dropped this into Wildfly 8 with keycloak adapter modules > > using org.apache.httpcomponents slot=4.3, we get a java.lang.LinkageError > > as > > soon as some Keycloak logic is triggered by user app. > > > > The question: how come jboss modules isolation doesn?t kick in and allow > > keycloak adapter modules to use slot=4.3 while at the same time user app > > (our examples) uses slot=main? > > > > The answer is that org.keycloak.adapters.HttpClientBuilder which seems to > > be > > our helper class for org.apache.httpcomponents inevitably leaks the version > > of HttpClient its module refers to - can?t be any other way (unless we > > change the code to use client app?s classloader - opening a can of worms). > > Any user app using HttpClientBuilder.build() method receives an instance of > > HttpClient loaded through org.keycloak.keycloak-adapter-core module, and > > transitively through org.apache.httpcomponents referred to therein. > > > > Any attempt of an application (.war) to package its own httpcomponents > > jars, > > or to refer to a different jboss module than the exact one referred to by > > org.keycloak.keycloak-adapter-core will result in ?catastrophic failure?. > > Example: > > > > > > HttpClient client = new > > HttpClientBuilder().disableTrustManager().build(); > > > > > > HttpClient on the left is loaded by app?s classloader. The one returned by > > build() on the right is loaded by org.keycloak.keycloak-adapter-core > > module?s version of httpcomponents. If it?s not the same classloader (jboss > > module) on both sides loading HttpClient you get a LinkageError. > > > > > > In light of this I wonder if it wasn?t the best solution to reexport > > org.apache.httpcomponents to .wars by default, thereby removing the > > necessity to package jboss-deployment-structure.xml at all, and ensuring > > that user application always uses the proper module. > > > > Currently jboss-deployment-structure.xml is required for wildfly / as7, and > > is a nuisance, especially as it has to be different (refer to slot=4.3) for > > Wildfly 8. > > > > If using HttpClientBuilder is supposed to be completely optional, we could > > maybe add configuration to keycloak subsystem to control exposing it to all > > or specific secure deployments. > > > > We could simply add another common attribute that can be used in > > and > > . We could expose it by default and have something like: > > > > false > > > > to inhibit exposing it if a situation calls for it. > > > > > > WDYT? > > What do I think? I think that classloading questions always make my head > > hurt! > > > > The best solution would be to find a way to detect the problem and fix it > > at > > deploy time. Using a DependencyProcessor, it should be possible to detect > > that the deployment contains the same module from two different slots. Then > > pick the best slot and spit out a warning message that you are removing the > > undesirable module. > > > > It should be possible, but I don't know if it actually IS possible. A > > version > > mismatch between modules is like a cancer. I think you should speak to an > > oncologist or David Lloyd. Since Red Hat doesn't employ any oncologists, go > > with David. :-) > > > > > > > > _______________________________________________ > > 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 Fri May 22 07:00:11 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 22 May 2015 07:00:11 -0400 Subject: [keycloak-dev] User apps and HttpClient In-Reply-To: <1329091490.2956540.1432281027019.JavaMail.zimbra@redhat.com> References: <60533052.2790794.1432241800924.JavaMail.zimbra@redhat.com> <555E7109.10608@redhat.com> <1329091490.2956540.1432281027019.JavaMail.zimbra@redhat.com> Message-ID: <555F0C3B.2080609@redhat.com> On 5/22/2015 3:50 AM, Marko Strukelj wrote: > I like Stian's solution much better ... it's much simpler :) Yea, to extend the medical metaphor, it's like the guy who goes in to see the doctor. He raises his arm in a funny way and says, "Hey doc, it hurts when I do this." Doctor says, "Don't do that." > > @Stian: Is there some docs where I can get a better understanding of > what's an API that is exposed to client, and what is implementation > details never to be used by client apps ... > > Ideally that would be easy to establish based on package names - e.g. > anything not in org.keycloak.something.impl might be an API, or > nothing but what's in org.keycloak.something.api might be an API ... > Or maybe we have one single module that's client API? > > > ------------------------------------------------------------------------ > > On 5/21/2015 4:56 PM, Marko Strukelj wrote: > > We package examples with jboss-deployment-structure.xml that looks like this: > > > > > > > > > > > > If we drop a .war containing this into Wildfly 9 (distribution/server-dist - ATM distribution/demo-dist, and distribution/adapters/wildfly-adapter-zip look buggy as they still use slot=4.3), things are fine. > > However, if we dropped this into Wildfly 8 with keycloak adapter modules using org.apache.httpcomponents slot=4.3, we get a java.lang.LinkageError as soon as some Keycloak logic is triggered by user app. > > The question: how come jboss modules isolation doesn?t kick in and allow keycloak adapter modules to use slot=4.3 while at the same time user app (our examples) uses slot=main? > > The answer is that org.keycloak.adapters.HttpClientBuilder which seems to be our helper class for org.apache.httpcomponents inevitably leaks the version of HttpClient its module refers to - can?t be any other way (unless we change the code to use client app?s classloader - opening a can of worms). Any user app using HttpClientBuilder.build() method receives an instance of HttpClient loaded through org.keycloak.keycloak-adapter-core module, and transitively through org.apache.httpcomponents referred to therein. > > Any attempt of an application (.war) to package its own httpcomponents jars, or to refer to a different jboss module than the exact one referred to by org.keycloak.keycloak-adapter-core will result in ?catastrophic failure?. Example: > > > HttpClient client = new HttpClientBuilder().disableTrustManager().build(); > > > HttpClient on the left is loaded by app?s classloader. The one returned by build() on the right is loaded by org.keycloak.keycloak-adapter-core module?s version of httpcomponents. If it?s not the same classloader (jboss module) on both sides loading HttpClient you get a LinkageError. > > > In light of this I wonder if it wasn?t the best solution to reexport org.apache.httpcomponents to .wars by default, thereby removing the necessity to package jboss-deployment-structure.xml at all, and ensuring that user application always uses the proper module. > > Currently jboss-deployment-structure.xml is required for wildfly / as7, and is a nuisance, especially as it has to be different (refer to slot=4.3) for Wildfly 8. > > If using HttpClientBuilder is supposed to be completely optional, we could maybe add configuration to keycloak subsystem to control exposing it to all or specific secure deployments. > > We could simply add another common attribute that can be used in and . We could expose it by default and have something like: > > false > > to inhibit exposing it if a situation calls for it. > > > WDYT? > > What do I think? I think that classloading questions always make > my head hurt! > > The best solution would be to find a way to detect the problem and > fix it at deploy time. Using a DependencyProcessor, it should be > possible to detect that the deployment contains the same module > from two different slots. Then pick the best slot and spit out a > warning message that you are removing the undesirable module. > > It should be possible, but I don't know if it actually IS > possible. A version mismatch between modules is like a cancer. I > think you should speak to an oncologist or David Lloyd. Since Red > Hat doesn't employ any oncologists, go with David. :-) > > > _______________________________________________ > 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/20150522/37843785/attachment.html From stian at redhat.com Fri May 22 07:25:17 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 22 May 2015 07:25:17 -0400 (EDT) Subject: [keycloak-dev] Progress on LDAP enhancements In-Reply-To: <555CFD9C.3020002@redhat.com> References: <555CFD9C.3020002@redhat.com> Message-ID: <973779062.3964356.1432293917891.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Marek Posolda" > To: keycloak-dev at lists.jboss.org > Sent: Wednesday, 20 May, 2015 11:33:16 PM > Subject: [keycloak-dev] Progress on LDAP enhancements > > I think I am finished with step 1 prototype on LDAP enhancements. Right > now it's just in my local fork > https://github.com/mposolda/keycloak/tree/ldap , I can't send PR as > model and admin console are kind of broken in my fork (ATM I am testing > with some hardcoded configs). > > What I did so far: > > - Refactoring and simplifying of forked picketlink LDAP code and removed > some abstractions to make it easier to use > > - Added UserFederationMapper SPI. The plan is to be in line with already > existing ProtocolMappers and IdentityProviderMappers. > > - Added LDAPFederationMapper. This mapper is invoked from > LDAPFederationProvider and provides some callbacks and extension points. > For more details, see methods and javadoc: > https://github.com/mposolda/keycloak/blob/ldap/federation/ldap/src/main/java/org/keycloak/federation/ldap/mappers/LDAPFederationMapper.java > . I have 3 implementations right now: > -- UserAttributeLDAPFederationMapper - This is used to map LDAP > attributes to UserModel attributes/properties . > -- FullNameLDAPFederationMapper - Many LDAP deployments store fullName > of user in single LDAP attribute (usually "cn" attribute). So this > allows to map fullName from LDAP to firstName and lastName on UserModel > -- RoleLDAPFederationMapper - allows to map LDAP roles and user role > mappings from some DN in LDAP tree to either realm roles or client roles > of some client. Of course it's not a problem to plug more mappers, so > it's not an issue to map for example LDAP roles from tree > "ou=finance,dc=myorg,dc=org" to client roles of client "finance" and > roles from tree "ou=development,dc=myorg,dc=org" to client roles of > client "development" etc. > > - Minor refactoring of some methods on UserFederationProvider interface. > I needed to add RealmModel as parameter to some methods (it was already > in most of them) because RealmModel will be used to retrieve list of > configured UserFederationMapperModels . > > > Next planned steps: > - Model - I plan to add CRUD for UserFederationMapperModel to RealmModel > (similarly like IdentityProviderMapperModel) > > - Admin console - I've been thinking about new tab "Mappers" under "User > Federation". The tab will be active when you have some Federation > provider chosen and it will allow to add/update/remove mappers for > particular provider. Again something very similar to already existing > broker mappers. WDYT? +1 > > - Address remaining subtasks of > https://issues.jboss.org/browse/KEYCLOAK-886 . Not everything will be > addressed by mappers. For example there is performance issue > https://issues.jboss.org/browse/KEYCLOAK-838 . I am thinking about > adding some caching at LDAPIdentityStore level, but also I am thinking > about some simple per-request caching at UserFederationManager level, > which might help with federation performance in general (not just > specific to LDAP). Maybe combination of both? But I am not sure atm... > > - DB migration > > Question: I wonder if we can put RealmModel accessible from > UserFederationProviderModel? It shouldn't be a problem from > implementation perspective as UserFederationProviderModel CRUD methods > are on RealmModel, so realm can just inject itself before return > UserFederationProviderModel. Since UserFederationProvider instances are > created by method "getInstance" on UserFederationProviderFactory, which > has UserFederationProviderModel as one of parameters, it will make > RealmModel accessible in UserFederationProvider and hence it won't be > needed to have RealmModel in signature of methods on UserFederationProvider. > > WDYT? Realm is already available from KeycloakContext / session.getContext().getRealm() > > Marek > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From velias at redhat.com Fri May 22 08:09:53 2015 From: velias at redhat.com (Vlastimil Elias) Date: Fri, 22 May 2015 14:09:53 +0200 Subject: [keycloak-dev] User apps and HttpClient In-Reply-To: <60533052.2790794.1432241800924.JavaMail.zimbra@redhat.com> References: <60533052.2790794.1432241800924.JavaMail.zimbra@redhat.com> Message-ID: <555F1C91.7070908@redhat.com> Hi boys, we just hit same problem with our app running at EAP 6.4 and latest Keycloak adapters 1.2.0.CR1 and Final1. I tried to play with of our app but no any success. Is there any other solution than downgrade of Keycloak EAP adapter to 1.2.0.Beta1 as we need solution ASAP? Is 1.2.0.Beta1 EAP adapter is compatible with Keycloak server 1.2.0.Final? Other solution is rewrite our app not to use httpclient, but it is not ideal solution too. Thanks in advance for some solution proposal. Vlastimil On 21.5.2015 22:56, Marko Strukelj wrote: > We package examples with jboss-deployment-structure.xml that looks like this: > > > > > > > > > > > > If we drop a .war containing this into Wildfly 9 (distribution/server-dist - ATM distribution/demo-dist, and distribution/adapters/wildfly-adapter-zip look buggy as they still use slot=4.3), things are fine. > > However, if we dropped this into Wildfly 8 with keycloak adapter modules using org.apache.httpcomponents slot=4.3, we get a java.lang.LinkageError as soon as some Keycloak logic is triggered by user app. > > The question: how come jboss modules isolation doesn?t kick in and allow keycloak adapter modules to use slot=4.3 while at the same time user app (our examples) uses slot=main? > > The answer is that org.keycloak.adapters.HttpClientBuilder which seems to be our helper class for org.apache.httpcomponents inevitably leaks the version of HttpClient its module refers to - can?t be any other way (unless we change the code to use client app?s classloader - opening a can of worms). Any user app using HttpClientBuilder.build() method receives an instance of HttpClient loaded through org.keycloak.keycloak-adapter-core module, and transitively through org.apache.httpcomponents referred to therein. > > Any attempt of an application (.war) to package its own httpcomponents jars, or to refer to a different jboss module than the exact one referred to by org.keycloak.keycloak-adapter-core will result in ?catastrophic failure?. Example: > > > HttpClient client = new HttpClientBuilder().disableTrustManager().build(); > > > HttpClient on the left is loaded by app?s classloader. The one returned by build() on the right is loaded by org.keycloak.keycloak-adapter-core module?s version of httpcomponents. If it?s not the same classloader (jboss module) on both sides loading HttpClient you get a LinkageError. > > > In light of this I wonder if it wasn?t the best solution to reexport org.apache.httpcomponents to .wars by default, thereby removing the necessity to package jboss-deployment-structure.xml at all, and ensuring that user application always uses the proper module. > > Currently jboss-deployment-structure.xml is required for wildfly / as7, and is a nuisance, especially as it has to be different (refer to slot=4.3) for Wildfly 8. > > If using HttpClientBuilder is supposed to be completely optional, we could maybe add configuration to keycloak subsystem to control exposing it to all or specific secure deployments. > > We could simply add another common attribute that can be used in and . We could expose it by default and have something like: > > false > > to inhibit exposing it if a situation calls for it. > > > WDYT? > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Vlastimil Elias Principal Software Engineer jboss.org Development Team From ssilvert at redhat.com Fri May 22 08:36:33 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 22 May 2015 08:36:33 -0400 Subject: [keycloak-dev] User apps and HttpClient In-Reply-To: <555F1C91.7070908@redhat.com> References: <60533052.2790794.1432241800924.JavaMail.zimbra@redhat.com> <555F1C91.7070908@redhat.com> Message-ID: <555F22D1.708@redhat.com> Can you use slot=4.3 for your app? On 5/22/2015 8:09 AM, Vlastimil Elias wrote: > Hi boys, > > we just hit same problem with our app running at EAP 6.4 and latest > Keycloak adapters 1.2.0.CR1 and Final1. > > I tried to play with of our app but no any > success. > > Is there any other solution than downgrade of Keycloak EAP adapter to > 1.2.0.Beta1 as we need solution ASAP? > Is 1.2.0.Beta1 EAP adapter is compatible with Keycloak server 1.2.0.Final? > > Other solution is rewrite our app not to use httpclient, but it is not > ideal solution too. > > Thanks in advance for some solution proposal. > > Vlastimil > > On 21.5.2015 22:56, Marko Strukelj wrote: >> We package examples with jboss-deployment-structure.xml that looks like this: >> >> >> >> >> >> >> >> >> >> >> >> If we drop a .war containing this into Wildfly 9 (distribution/server-dist - ATM distribution/demo-dist, and distribution/adapters/wildfly-adapter-zip look buggy as they still use slot=4.3), things are fine. >> >> However, if we dropped this into Wildfly 8 with keycloak adapter modules using org.apache.httpcomponents slot=4.3, we get a java.lang.LinkageError as soon as some Keycloak logic is triggered by user app. >> >> The question: how come jboss modules isolation doesn?t kick in and allow keycloak adapter modules to use slot=4.3 while at the same time user app (our examples) uses slot=main? >> >> The answer is that org.keycloak.adapters.HttpClientBuilder which seems to be our helper class for org.apache.httpcomponents inevitably leaks the version of HttpClient its module refers to - can?t be any other way (unless we change the code to use client app?s classloader - opening a can of worms). Any user app using HttpClientBuilder.build() method receives an instance of HttpClient loaded through org.keycloak.keycloak-adapter-core module, and transitively through org.apache.httpcomponents referred to therein. >> >> Any attempt of an application (.war) to package its own httpcomponents jars, or to refer to a different jboss module than the exact one referred to by org.keycloak.keycloak-adapter-core will result in ?catastrophic failure?. Example: >> >> >> HttpClient client = new HttpClientBuilder().disableTrustManager().build(); >> >> >> HttpClient on the left is loaded by app?s classloader. The one returned by build() on the right is loaded by org.keycloak.keycloak-adapter-core module?s version of httpcomponents. If it?s not the same classloader (jboss module) on both sides loading HttpClient you get a LinkageError. >> >> >> In light of this I wonder if it wasn?t the best solution to reexport org.apache.httpcomponents to .wars by default, thereby removing the necessity to package jboss-deployment-structure.xml at all, and ensuring that user application always uses the proper module. >> >> Currently jboss-deployment-structure.xml is required for wildfly / as7, and is a nuisance, especially as it has to be different (refer to slot=4.3) for Wildfly 8. >> >> If using HttpClientBuilder is supposed to be completely optional, we could maybe add configuration to keycloak subsystem to control exposing it to all or specific secure deployments. >> >> We could simply add another common attribute that can be used in and . We could expose it by default and have something like: >> >> false >> >> to inhibit exposing it if a situation calls for it. >> >> >> WDYT? >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev From mstrukel at redhat.com Fri May 22 08:36:41 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Fri, 22 May 2015 08:36:41 -0400 (EDT) Subject: [keycloak-dev] User apps and HttpClient In-Reply-To: <555F1C91.7070908@redhat.com> References: <60533052.2790794.1432241800924.JavaMail.zimbra@redhat.com> <555F1C91.7070908@redhat.com> Message-ID: <1211080921.3086903.1432298201554.JavaMail.zimbra@redhat.com> @Vlastimil - a few questions: Do you use org.keycloak.adapters.HttpClientBuilder in your app? Do you import any other class from org.keycloak.adapters in your app? Do you package httpclient.jar within your .war by any chance? Do you put jboss-deployment-structure.xml to your .war's /WEB-INF Does your jboss-deployment-structure.xml look like this: - m ----- Original Message ----- > Hi boys, > > we just hit same problem with our app running at EAP 6.4 and latest > Keycloak adapters 1.2.0.CR1 and Final1. > > I tried to play with of our app but no any > success. > > Is there any other solution than downgrade of Keycloak EAP adapter to > 1.2.0.Beta1 as we need solution ASAP? > Is 1.2.0.Beta1 EAP adapter is compatible with Keycloak server 1.2.0.Final? > > Other solution is rewrite our app not to use httpclient, but it is not > ideal solution too. > > Thanks in advance for some solution proposal. > > Vlastimil > > On 21.5.2015 22:56, Marko Strukelj wrote: > > We package examples with jboss-deployment-structure.xml that looks like > > this: > > > > > > > > > > > > > > > > > > > > > > > > If we drop a .war containing this into Wildfly 9 (distribution/server-dist > > - ATM distribution/demo-dist, and > > distribution/adapters/wildfly-adapter-zip look buggy as they still use > > slot=4.3), things are fine. > > > > However, if we dropped this into Wildfly 8 with keycloak adapter modules > > using org.apache.httpcomponents slot=4.3, we get a java.lang.LinkageError > > as soon as some Keycloak logic is triggered by user app. > > > > The question: how come jboss modules isolation doesn?t kick in and allow > > keycloak adapter modules to use slot=4.3 while at the same time user app > > (our examples) uses slot=main? > > > > The answer is that org.keycloak.adapters.HttpClientBuilder which seems to > > be our helper class for org.apache.httpcomponents inevitably leaks the > > version of HttpClient its module refers to - can?t be any other way > > (unless we change the code to use client app?s classloader - opening a can > > of worms). Any user app using HttpClientBuilder.build() method receives an > > instance of HttpClient loaded through org.keycloak.keycloak-adapter-core > > module, and transitively through org.apache.httpcomponents referred to > > therein. > > > > Any attempt of an application (.war) to package its own httpcomponents > > jars, or to refer to a different jboss module than the exact one referred > > to by org.keycloak.keycloak-adapter-core will result in ?catastrophic > > failure?. Example: > > > > > > HttpClient client = new > > HttpClientBuilder().disableTrustManager().build(); > > > > > > HttpClient on the left is loaded by app?s classloader. The one returned by > > build() on the right is loaded by org.keycloak.keycloak-adapter-core > > module?s version of httpcomponents. If it?s not the same classloader > > (jboss module) on both sides loading HttpClient you get a LinkageError. > > > > > > In light of this I wonder if it wasn?t the best solution to reexport > > org.apache.httpcomponents to .wars by default, thereby removing the > > necessity to package jboss-deployment-structure.xml at all, and ensuring > > that user application always uses the proper module. > > > > Currently jboss-deployment-structure.xml is required for wildfly / as7, and > > is a nuisance, especially as it has to be different (refer to slot=4.3) > > for Wildfly 8. > > > > If using HttpClientBuilder is supposed to be completely optional, we could > > maybe add configuration to keycloak subsystem to control exposing it to > > all or specific secure deployments. > > > > We could simply add another common attribute that can be used in > > and . We could expose it by default and have something > > like: > > > > false > > > > to inhibit exposing it if a situation calls for it. > > > > > > WDYT? > > > > > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -- > Vlastimil Elias > Principal Software Engineer > jboss.org Development Team > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From ssilvert at redhat.com Fri May 22 08:46:59 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 22 May 2015 08:46:59 -0400 Subject: [keycloak-dev] Reset admin password Message-ID: <555F2543.5070605@redhat.com> We need a way to reset the admin password in case it is lost or hijacked. The proposal is to do that through an operation on the keycloak-server-subsystem that only runs in "offline CLI" mode. First, we currently allow you to delete the admin user. Should we disallow that and make the master admin user permanent? Should the new operation only work on the master admin password or can it be applied to any user in any realm? From velias at redhat.com Fri May 22 08:48:44 2015 From: velias at redhat.com (Vlastimil Elias) Date: Fri, 22 May 2015 14:48:44 +0200 Subject: [keycloak-dev] User apps and HttpClient In-Reply-To: <1211080921.3086903.1432298201554.JavaMail.zimbra@redhat.com> References: <60533052.2790794.1432241800924.JavaMail.zimbra@redhat.com> <555F1C91.7070908@redhat.com> <1211080921.3086903.1432298201554.JavaMail.zimbra@redhat.com> Message-ID: <555F25AC.804@redhat.com> Hi, On 22.5.2015 14:36, Marko Strukelj wrote: > @Vlastimil - a few questions: > > Do you use org.keycloak.adapters.HttpClientBuilder in your app? yes, colleague (in CC) who create the code used some example how to call Keycloak REST API from java code, so he uses this > Do you import any other class from org.keycloak.adapters in your app? no > Do you package httpclient.jar within your .war by any chance? no > Do you put jboss-deployment-structure.xml to your .war's /WEB-INF > Does your jboss-deployment-structure.xml look like this: > > > > > > > > Yes. I tried this both with and without slot="4.3" attribute but error is here in both cases. A bit strange thing is that LinkageError has been thrown in finally block on call of client.getConnectionManager().shutdown(); When I commented this out then LinkageError arrised at line with HttpResponse response = client.execute(get); call, which is still not first occurence of httpclient in the method, but I understand that it is classloading problem which is always strange ;-) Thanks in advance Vl. > - m > > ----- Original Message ----- >> Hi boys, >> >> we just hit same problem with our app running at EAP 6.4 and latest >> Keycloak adapters 1.2.0.CR1 and Final1. >> >> I tried to play with of our app but no any >> success. >> >> Is there any other solution than downgrade of Keycloak EAP adapter to >> 1.2.0.Beta1 as we need solution ASAP? >> Is 1.2.0.Beta1 EAP adapter is compatible with Keycloak server 1.2.0.Final? >> >> Other solution is rewrite our app not to use httpclient, but it is not >> ideal solution too. >> >> Thanks in advance for some solution proposal. >> >> Vlastimil >> >> On 21.5.2015 22:56, Marko Strukelj wrote: >>> We package examples with jboss-deployment-structure.xml that looks like >>> this: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> If we drop a .war containing this into Wildfly 9 (distribution/server-dist >>> - ATM distribution/demo-dist, and >>> distribution/adapters/wildfly-adapter-zip look buggy as they still use >>> slot=4.3), things are fine. >>> >>> However, if we dropped this into Wildfly 8 with keycloak adapter modules >>> using org.apache.httpcomponents slot=4.3, we get a java.lang.LinkageError >>> as soon as some Keycloak logic is triggered by user app. >>> >>> The question: how come jboss modules isolation doesn?t kick in and allow >>> keycloak adapter modules to use slot=4.3 while at the same time user app >>> (our examples) uses slot=main? >>> >>> The answer is that org.keycloak.adapters.HttpClientBuilder which seems to >>> be our helper class for org.apache.httpcomponents inevitably leaks the >>> version of HttpClient its module refers to - can?t be any other way >>> (unless we change the code to use client app?s classloader - opening a can >>> of worms). Any user app using HttpClientBuilder.build() method receives an >>> instance of HttpClient loaded through org.keycloak.keycloak-adapter-core >>> module, and transitively through org.apache.httpcomponents referred to >>> therein. >>> >>> Any attempt of an application (.war) to package its own httpcomponents >>> jars, or to refer to a different jboss module than the exact one referred >>> to by org.keycloak.keycloak-adapter-core will result in ?catastrophic >>> failure?. Example: >>> >>> >>> HttpClient client = new >>> HttpClientBuilder().disableTrustManager().build(); >>> >>> >>> HttpClient on the left is loaded by app?s classloader. The one returned by >>> build() on the right is loaded by org.keycloak.keycloak-adapter-core >>> module?s version of httpcomponents. If it?s not the same classloader >>> (jboss module) on both sides loading HttpClient you get a LinkageError. >>> >>> >>> In light of this I wonder if it wasn?t the best solution to reexport >>> org.apache.httpcomponents to .wars by default, thereby removing the >>> necessity to package jboss-deployment-structure.xml at all, and ensuring >>> that user application always uses the proper module. >>> >>> Currently jboss-deployment-structure.xml is required for wildfly / as7, and >>> is a nuisance, especially as it has to be different (refer to slot=4.3) >>> for Wildfly 8. >>> >>> If using HttpClientBuilder is supposed to be completely optional, we could >>> maybe add configuration to keycloak subsystem to control exposing it to >>> all or specific secure deployments. >>> >>> We could simply add another common attribute that can be used in >>> and . We could expose it by default and have something >>> like: >>> >>> false >>> >>> to inhibit exposing it if a situation calls for it. >>> >>> >>> WDYT? >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> -- >> Vlastimil Elias >> Principal Software Engineer >> jboss.org Development Team >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Vlastimil Elias Principal Software Engineer jboss.org Development Team From stian at redhat.com Fri May 22 08:56:55 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 22 May 2015 08:56:55 -0400 (EDT) Subject: [keycloak-dev] Reset admin password In-Reply-To: <555F2543.5070605@redhat.com> References: <555F2543.5070605@redhat.com> Message-ID: <264491439.4008534.1432299415112.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Stan Silvert" > To: keycloak-dev at lists.jboss.org > Sent: Friday, 22 May, 2015 2:46:59 PM > Subject: [keycloak-dev] Reset admin password > > We need a way to reset the admin password in case it is lost or > hijacked. The proposal is to do that through an operation on the > keycloak-server-subsystem that only runs in "offline CLI" mode. > > First, we currently allow you to delete the admin user. Should we > disallow that and make the master admin user permanent? Interesting question - quick answer, not sure! There are all sorts of things that can be deleted that'll currently screw things up royally! For example deleting admin related roles and clients. Created https://issues.jboss.org/browse/KEYCLOAK-1340 for this. For admin user maybe rather than a reset admin password option, we should have a reset admin account option? > > Should the new operation only work on the master admin password or can > it be applied to any user in any realm? +1 To just admin > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From ssilvert at redhat.com Fri May 22 09:06:13 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 22 May 2015 09:06:13 -0400 Subject: [keycloak-dev] Reset admin password In-Reply-To: <264491439.4008534.1432299415112.JavaMail.zimbra@redhat.com> References: <555F2543.5070605@redhat.com> <264491439.4008534.1432299415112.JavaMail.zimbra@redhat.com> Message-ID: <555F29C5.5010605@redhat.com> On 5/22/2015 8:56 AM, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Stan Silvert" >> To: keycloak-dev at lists.jboss.org >> Sent: Friday, 22 May, 2015 2:46:59 PM >> Subject: [keycloak-dev] Reset admin password >> >> We need a way to reset the admin password in case it is lost or >> hijacked. The proposal is to do that through an operation on the >> keycloak-server-subsystem that only runs in "offline CLI" mode. >> >> First, we currently allow you to delete the admin user. Should we >> disallow that and make the master admin user permanent? > Interesting question - quick answer, not sure! > > There are all sorts of things that can be deleted that'll currently screw things up royally! For example deleting admin related roles and clients. Created https://issues.jboss.org/browse/KEYCLOAK-1340 for this. > > For admin user maybe rather than a reset admin password option, we should have a reset admin account option? Depends on what "reset admin account" actually does. I wouldn't want a "reset admin account" to change things that the user put there on purpose. If you can reset the password and get into the account then you can go into the UI and change anything that doesn't look right. > >> Should the new operation only work on the master admin password or can >> it be applied to any user in any realm? > +1 To just admin > >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From mstrukel at redhat.com Fri May 22 09:15:58 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Fri, 22 May 2015 09:15:58 -0400 (EDT) Subject: [keycloak-dev] User apps and HttpClient In-Reply-To: <555F25AC.804@redhat.com> References: <60533052.2790794.1432241800924.JavaMail.zimbra@redhat.com> <555F1C91.7070908@redhat.com> <1211080921.3086903.1432298201554.JavaMail.zimbra@redhat.com> <555F25AC.804@redhat.com> Message-ID: <923428983.3111623.1432300558434.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hi, > > On 22.5.2015 14:36, Marko Strukelj wrote: > > @Vlastimil - a few questions: > > > > Do you use org.keycloak.adapters.HttpClientBuilder in your app? > yes, colleague (in CC) who create the code used some example how to call > Keycloak REST API from java code, so he uses this Ok, in this case you have to make sure to include jboss-deployment-structure.xml that adds dependency on org.apache.httpcomponents. To make sure you use the right slot, open the modules/org/keycloak/keycloak-adapter-core/main/module.xml (could be in modules/system/layers/base). In that file find dependency on org.apache.httpcomponents and check if it has a slot="4.3". In your jboss-deployment-structure.xml you have to use the same dependency. That's all. Things should then work. Or another option that Stian suggested ... don't use HttpClientBuilder at all. Forget about it. Use HttpClient directly. I think in that case it's up to you how you provide HttpClient to your .war. Haven't yet tried though. That one is on TODOs ... > > Do you import any other class from org.keycloak.adapters in your app? > no > > Do you package httpclient.jar within your .war by any chance? > no > > Do you put jboss-deployment-structure.xml to your .war's /WEB-INF > > Does your jboss-deployment-structure.xml look like this: > > > > > > > > > > > > > > > > > > Yes. I tried this both with and without slot="4.3" attribute but error > is here in both cases. > One of these cases should be a solution to your problem. > A bit strange thing is that LinkageError has been thrown in finally > block on call of > client.getConnectionManager().shutdown(); > > When I commented this out then LinkageError arrised at line with > HttpResponse response = client.execute(get); > call, which is still not first occurence of httpclient in the method, > but I understand that it is classloading problem which is always strange ;-) Sounds like there is more going on here than what I initially described. There might be more ways of erroneous interaction between multiple versions of HttpClient than we currently see. If you could make a reproducer and add it to JIRA that would be great ... as I'm a bit in the dark here now. It could be related to this issue: https://issues.jboss.org/browse/KEYCLOAK-1338 - m From stian at redhat.com Fri May 22 09:56:54 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 22 May 2015 09:56:54 -0400 (EDT) Subject: [keycloak-dev] Reset admin password In-Reply-To: <555F29C5.5010605@redhat.com> References: <555F2543.5070605@redhat.com> <264491439.4008534.1432299415112.JavaMail.zimbra@redhat.com> <555F29C5.5010605@redhat.com> Message-ID: <342738121.4063141.1432303014055.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Stan Silvert" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Friday, 22 May, 2015 3:06:13 PM > Subject: Re: [keycloak-dev] Reset admin password > > On 5/22/2015 8:56 AM, Stian Thorgersen wrote: > > > > ----- Original Message ----- > >> From: "Stan Silvert" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Friday, 22 May, 2015 2:46:59 PM > >> Subject: [keycloak-dev] Reset admin password > >> > >> We need a way to reset the admin password in case it is lost or > >> hijacked. The proposal is to do that through an operation on the > >> keycloak-server-subsystem that only runs in "offline CLI" mode. > >> > >> First, we currently allow you to delete the admin user. Should we > >> disallow that and make the master admin user permanent? > > Interesting question - quick answer, not sure! > > > > There are all sorts of things that can be deleted that'll currently screw > > things up royally! For example deleting admin related roles and clients. > > Created https://issues.jboss.org/browse/KEYCLOAK-1340 for this. > > > > For admin user maybe rather than a reset admin password option, we should > > have a reset admin account option? > Depends on what "reset admin account" actually does. I wouldn't want a > "reset admin account" to change things that the user put there on > purpose. If you can reset the password and get into the account then > you can go into the UI and change anything that doesn't look right. How about "recover admin account" that: 1. If user 'admin' in realm 'master' doesn't exist create it 2. If user 'admin' doesn't have realm role 'admin' add it 3. Set user 'admin' password to either 'admin' or to specified password > > > > >> Should the new operation only work on the master admin password or can > >> it be applied to any user in any realm? > > +1 To just admin > > > >> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > From ssilvert at redhat.com Fri May 22 11:20:22 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 22 May 2015 11:20:22 -0400 Subject: [keycloak-dev] Reset admin password In-Reply-To: <342738121.4063141.1432303014055.JavaMail.zimbra@redhat.com> References: <555F2543.5070605@redhat.com> <264491439.4008534.1432299415112.JavaMail.zimbra@redhat.com> <555F29C5.5010605@redhat.com> <342738121.4063141.1432303014055.JavaMail.zimbra@redhat.com> Message-ID: <555F4936.20201@redhat.com> On 5/22/2015 9:56 AM, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Stan Silvert" >> To: "Stian Thorgersen" >> Cc: keycloak-dev at lists.jboss.org >> Sent: Friday, 22 May, 2015 3:06:13 PM >> Subject: Re: [keycloak-dev] Reset admin password >> >> On 5/22/2015 8:56 AM, Stian Thorgersen wrote: >>> ----- Original Message ----- >>>> From: "Stan Silvert" >>>> To: keycloak-dev at lists.jboss.org >>>> Sent: Friday, 22 May, 2015 2:46:59 PM >>>> Subject: [keycloak-dev] Reset admin password >>>> >>>> We need a way to reset the admin password in case it is lost or >>>> hijacked. The proposal is to do that through an operation on the >>>> keycloak-server-subsystem that only runs in "offline CLI" mode. >>>> >>>> First, we currently allow you to delete the admin user. Should we >>>> disallow that and make the master admin user permanent? >>> Interesting question - quick answer, not sure! >>> >>> There are all sorts of things that can be deleted that'll currently screw >>> things up royally! For example deleting admin related roles and clients. >>> Created https://issues.jboss.org/browse/KEYCLOAK-1340 for this. >>> >>> For admin user maybe rather than a reset admin password option, we should >>> have a reset admin account option? >> Depends on what "reset admin account" actually does. I wouldn't want a >> "reset admin account" to change things that the user put there on >> purpose. If you can reset the password and get into the account then >> you can go into the UI and change anything that doesn't look right. > How about "recover admin account" that: > > 1. If user 'admin' in realm 'master' doesn't exist create it > 2. If user 'admin' doesn't have realm role 'admin' add it > 3. Set user 'admin' password to either 'admin' or to specified password Sounds good. Let's do that. > >>>> Should the new operation only work on the master admin password or can >>>> it be applied to any user in any realm? >>> +1 To just admin >>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >> From mposolda at redhat.com Fri May 22 11:25:20 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 22 May 2015 17:25:20 +0200 Subject: [keycloak-dev] Reset admin password In-Reply-To: <264491439.4008534.1432299415112.JavaMail.zimbra@redhat.com> References: <555F2543.5070605@redhat.com> <264491439.4008534.1432299415112.JavaMail.zimbra@redhat.com> Message-ID: <555F4A60.60908@redhat.com> On 22.5.2015 14:56, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Stan Silvert" >> To: keycloak-dev at lists.jboss.org >> Sent: Friday, 22 May, 2015 2:46:59 PM >> Subject: [keycloak-dev] Reset admin password >> >> We need a way to reset the admin password in case it is lost or >> hijacked. The proposal is to do that through an operation on the >> keycloak-server-subsystem that only runs in "offline CLI" mode. >> >> First, we currently allow you to delete the admin user. Should we >> disallow that and make the master admin user permanent? > Interesting question - quick answer, not sure! > > There are all sorts of things that can be deleted that'll currently screw things up royally! For example deleting admin related roles and clients. Created https://issues.jboss.org/browse/KEYCLOAK-1340 for this. Similar issue pointed some time ago by Petr Mensik from QA team: if you change SSO session max lifespan timeout for example to 1 second, you are immediately logged out from admin console and you're not able to login again (More accurately you are able to login, but you're logged out immediately due to session timeout). There are likely bunch of similar things and not sure if we can handle all of them. Question is if these are not just "theoretic" issues? I can't remember any user complain on ML that he accidentally broke his keycloak DB by delete/configure something strange in admin console. Marek > > For admin user maybe rather than a reset admin password option, we should have a reset admin account option? > >> Should the new operation only work on the master admin password or can >> it be applied to any user in any realm? > +1 To just admin > >> >> _______________________________________________ >> 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 leonardo.zanivan at gmail.com Fri May 22 11:27:06 2015 From: leonardo.zanivan at gmail.com (Leonardo Loch Zanivan) Date: Fri, 22 May 2015 15:27:06 +0000 Subject: [keycloak-dev] Reset admin password In-Reply-To: <555F4A60.60908@redhat.com> References: <555F2543.5070605@redhat.com> <264491439.4008534.1432299415112.JavaMail.zimbra@redhat.com> <555F4A60.60908@redhat.com> Message-ID: I think it's possible to rename/delete master realm... On Fri, May 22, 2015 at 12:25 PM Marek Posolda wrote: > On 22.5.2015 14:56, Stian Thorgersen wrote: > > > > ----- Original Message ----- > >> From: "Stan Silvert" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Friday, 22 May, 2015 2:46:59 PM > >> Subject: [keycloak-dev] Reset admin password > >> > >> We need a way to reset the admin password in case it is lost or > >> hijacked. The proposal is to do that through an operation on the > >> keycloak-server-subsystem that only runs in "offline CLI" mode. > >> > >> First, we currently allow you to delete the admin user. Should we > >> disallow that and make the master admin user permanent? > > Interesting question - quick answer, not sure! > > > > There are all sorts of things that can be deleted that'll currently > screw things up royally! For example deleting admin related roles and > clients. Created https://issues.jboss.org/browse/KEYCLOAK-1340 for this. > Similar issue pointed some time ago by Petr Mensik from QA team: if you > change SSO session max lifespan timeout for example to 1 second, you are > immediately logged out from admin console and you're not able to login > again (More accurately you are able to login, but you're logged out > immediately due to session timeout). > > There are likely bunch of similar things and not sure if we can handle > all of them. Question is if these are not just "theoretic" issues? I > can't remember any user complain on ML that he accidentally broke his > keycloak DB by delete/configure something strange in admin console. > > Marek > > > > For admin user maybe rather than a reset admin password option, we > should have a reset admin account option? > > > >> Should the new operation only work on the master admin password or can > >> it be applied to any user in any realm? > > +1 To just admin > > > >> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150522/9cb73b78/attachment.html From sblanc at redhat.com Fri May 22 11:31:56 2015 From: sblanc at redhat.com (Sebastien Blanc) Date: Fri, 22 May 2015 17:31:56 +0200 Subject: [keycloak-dev] Error using Keycloak 1.2.0 In-Reply-To: References: Message-ID: Matzew, I just saw that the layout of the themes have changed 1.2 ( http://keycloak.github.io/docs/userguide/html/Migration_from_older_versions.html#d4e3133) , I will do a PR against your branch On Fri, May 22, 2015 at 9:44 AM, Matthias Wessendorf wrote: > Hi, > > yesterday we started to get onto 1.2.0 (on 1.1.0 before), and a few > changes were required: > > https://github.com/matzew/aerogear-unifiedpush-server/commit/c418b96bff2a921b4d47075556c93c5a17078260 > > But now the deployment on WF 8.2, gives me this: > https://gist.github.com/matzew/47805bd3aa1320a3cd51 > > But I am not sure what's not missing regarding the missing template :-( > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150522/5cbad55b/attachment-0001.html From ssilvert at redhat.com Fri May 22 11:39:51 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 22 May 2015 11:39:51 -0400 Subject: [keycloak-dev] Reset admin password In-Reply-To: <555F4A60.60908@redhat.com> References: <555F2543.5070605@redhat.com> <264491439.4008534.1432299415112.JavaMail.zimbra@redhat.com> <555F4A60.60908@redhat.com> Message-ID: <555F4DC7.6040908@redhat.com> On 5/22/2015 11:25 AM, Marek Posolda wrote: > On 22.5.2015 14:56, Stian Thorgersen wrote: >> >> ----- Original Message ----- >>> From: "Stan Silvert" >>> To: keycloak-dev at lists.jboss.org >>> Sent: Friday, 22 May, 2015 2:46:59 PM >>> Subject: [keycloak-dev] Reset admin password >>> >>> We need a way to reset the admin password in case it is lost or >>> hijacked. The proposal is to do that through an operation on the >>> keycloak-server-subsystem that only runs in "offline CLI" mode. >>> >>> First, we currently allow you to delete the admin user. Should we >>> disallow that and make the master admin user permanent? >> Interesting question - quick answer, not sure! >> >> There are all sorts of things that can be deleted that'll currently >> screw things up royally! For example deleting admin related roles and >> clients. Created https://issues.jboss.org/browse/KEYCLOAK-1340 for this. > Similar issue pointed some time ago by Petr Mensik from QA team: if > you change SSO session max lifespan timeout for example to 1 second, > you are immediately logged out from admin console and you're not able > to login again (More accurately you are able to login, but you're > logged out immediately due to session timeout). > > There are likely bunch of similar things and not sure if we can handle > all of them. Question is if these are not just "theoretic" issues? I > can't remember any user complain on ML that he accidentally broke his > keycloak DB by delete/configure something strange in admin console. > > Marek I think we need to clean these up. You should never be able to do anything from the UI that renders your system inoperable. It's only a matter of time before some big customer has a disaster because we let him do something really stupid. >> >> For admin user maybe rather than a reset admin password option, we >> should have a reset admin account option? >> >>> Should the new operation only work on the master admin password or can >>> it be applied to any user in any realm? >> +1 To just admin >> >>> >>> _______________________________________________ >>> 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 sblanc at redhat.com Fri May 22 11:44:45 2015 From: sblanc at redhat.com (Sebastien Blanc) Date: Fri, 22 May 2015 17:44:45 +0200 Subject: [keycloak-dev] Error using Keycloak 1.2.0 In-Reply-To: References: Message-ID: Alright I see I'm late to the party :) https://github.com/matzew/aerogear-unifiedpush-server/commit/ab4de307477ee2401e46341882c6a0468fdae7fb thx Stian On Fri, May 22, 2015 at 5:31 PM, Sebastien Blanc wrote: > Matzew, I just saw that the layout of the themes have changed 1.2 ( > http://keycloak.github.io/docs/userguide/html/Migration_from_older_versions.html#d4e3133) > , I will do a PR against your branch > > On Fri, May 22, 2015 at 9:44 AM, Matthias Wessendorf > wrote: > >> Hi, >> >> yesterday we started to get onto 1.2.0 (on 1.1.0 before), and a few >> changes were required: >> >> https://github.com/matzew/aerogear-unifiedpush-server/commit/c418b96bff2a921b4d47075556c93c5a17078260 >> >> But now the deployment on WF 8.2, gives me this: >> https://gist.github.com/matzew/47805bd3aa1320a3cd51 >> >> But I am not sure what's not missing regarding the missing template :-( >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150522/44b9de48/attachment.html From b.hansmann at alphaapps.de Fri May 22 12:12:52 2015 From: b.hansmann at alphaapps.de (Benjamin Hansmann [alphaApps]) Date: Fri, 22 May 2015 18:12:52 +0200 Subject: [keycloak-dev] ErrorResponse and ErrorResponseException Message-ID: <1432311172.7471.30.camel@alphaapps.de> In case of failures org.keycloak.services.admin.UsersResource returns an ErrorResponse or throws an exception (e.g. BadRequestException, NotFoundException...) depending if the return type of the corresponding method is Response or void. This leads to inconsistent error representations on the client side. org.keycloak.services.ErrorResponse wraps an ErrorRepresentation. org.keycloak.services.ErrorResponseExceptions defines another representation for errors org.jboss.resteasy.spi.{BadRequestException|NotFoundException|Inte...} just wraps a string Would anyone mind if I define a new Exception wraps an ErrorRepresentation for those methods that don't return a response? Or does an exception of this kind already exist. It should ideally be named ErrorResponseException but that one already exists... Benjamin From mposolda at redhat.com Fri May 22 12:22:53 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 22 May 2015 18:22:53 +0200 Subject: [keycloak-dev] Reset admin password In-Reply-To: <555F4DC7.6040908@redhat.com> References: <555F2543.5070605@redhat.com> <264491439.4008534.1432299415112.JavaMail.zimbra@redhat.com> <555F4A60.60908@redhat.com> <555F4DC7.6040908@redhat.com> Message-ID: <555F57DD.1010003@redhat.com> On 22.5.2015 17:39, Stan Silvert wrote: > On 5/22/2015 11:25 AM, Marek Posolda wrote: >> On 22.5.2015 14:56, Stian Thorgersen wrote: >>> >>> ----- Original Message ----- >>>> From: "Stan Silvert" >>>> To: keycloak-dev at lists.jboss.org >>>> Sent: Friday, 22 May, 2015 2:46:59 PM >>>> Subject: [keycloak-dev] Reset admin password >>>> >>>> We need a way to reset the admin password in case it is lost or >>>> hijacked. The proposal is to do that through an operation on the >>>> keycloak-server-subsystem that only runs in "offline CLI" mode. >>>> >>>> First, we currently allow you to delete the admin user. Should we >>>> disallow that and make the master admin user permanent? >>> Interesting question - quick answer, not sure! >>> >>> There are all sorts of things that can be deleted that'll currently >>> screw things up royally! For example deleting admin related roles >>> and clients. Created https://issues.jboss.org/browse/KEYCLOAK-1340 >>> for this. >> Similar issue pointed some time ago by Petr Mensik from QA team: if >> you change SSO session max lifespan timeout for example to 1 second, >> you are immediately logged out from admin console and you're not able >> to login again (More accurately you are able to login, but you're >> logged out immediately due to session timeout). >> >> There are likely bunch of similar things and not sure if we can >> handle all of them. Question is if these are not just "theoretic" >> issues? I can't remember any user complain on ML that he accidentally >> broke his keycloak DB by delete/configure something strange in admin >> console. >> >> Marek > I think we need to clean these up. You should never be able to do > anything from the UI that renders your system inoperable. It's only > a matter of time before some big customer has a disaster because we > let him do something really stupid. Probably yes. However people can possibly fix it by edit DB directly or recover their DB (assuming big customer will do DB backup). But I agree, we can always be a bit resistent against those issues. And hopefully CLI could help as well to recover from those. I've created https://issues.jboss.org/browse/KEYCLOAK-1341 for 1-second timeout issue. Marek >>> >>> For admin user maybe rather than a reset admin password option, we >>> should have a reset admin account option? >>> >>>> Should the new operation only work on the master admin password or can >>>> it be applied to any user in any realm? >>> +1 To just admin >>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > From bburke at redhat.com Fri May 22 15:17:42 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 22 May 2015 15:17:42 -0400 Subject: [keycloak-dev] Reset admin password In-Reply-To: <555F57DD.1010003@redhat.com> References: <555F2543.5070605@redhat.com> <264491439.4008534.1432299415112.JavaMail.zimbra@redhat.com> <555F4A60.60908@redhat.com> <555F4DC7.6040908@redhat.com> <555F57DD.1010003@redhat.com> Message-ID: <555F80D6.5010802@redhat.com> On 5/22/2015 12:22 PM, Marek Posolda wrote: > On 22.5.2015 17:39, Stan Silvert wrote: >> On 5/22/2015 11:25 AM, Marek Posolda wrote: >>> On 22.5.2015 14:56, Stian Thorgersen wrote: >>>> >>>> ----- Original Message ----- >>>>> From: "Stan Silvert" >>>>> To: keycloak-dev at lists.jboss.org >>>>> Sent: Friday, 22 May, 2015 2:46:59 PM >>>>> Subject: [keycloak-dev] Reset admin password >>>>> >>>>> We need a way to reset the admin password in case it is lost or >>>>> hijacked. The proposal is to do that through an operation on the >>>>> keycloak-server-subsystem that only runs in "offline CLI" mode. >>>>> >>>>> First, we currently allow you to delete the admin user. Should we >>>>> disallow that and make the master admin user permanent? >>>> Interesting question - quick answer, not sure! >>>> >>>> There are all sorts of things that can be deleted that'll currently >>>> screw things up royally! For example deleting admin related roles >>>> and clients. Created https://issues.jboss.org/browse/KEYCLOAK-1340 >>>> for this. >>> Similar issue pointed some time ago by Petr Mensik from QA team: if >>> you change SSO session max lifespan timeout for example to 1 second, >>> you are immediately logged out from admin console and you're not able >>> to login again (More accurately you are able to login, but you're >>> logged out immediately due to session timeout). >>> >>> There are likely bunch of similar things and not sure if we can >>> handle all of them. Question is if these are not just "theoretic" >>> issues? I can't remember any user complain on ML that he accidentally >>> broke his keycloak DB by delete/configure something strange in admin >>> console. >>> >>> Marek >> I think we need to clean these up. You should never be able to do >> anything from the UI that renders your system inoperable. It's only >> a matter of time before some big customer has a disaster because we >> let him do something really stupid. > Probably yes. However people can possibly fix it by edit DB directly or > recover their DB (assuming big customer will do DB backup). > > But I agree, we can always be a bit resistent against those issues. And > hopefully CLI could help as well to recover from those. I've created > https://issues.jboss.org/browse/KEYCLOAK-1341 for 1-second timeout issue. > There's actually better ways to accomplish this: a) credential reset via email b) credential reset via SMS c) credential reset via "what is your mother's maiden name" d) one or more of the above. As Marek said, worst case workaround is to write the database record directly. This whole talk of adding a reset password to CLI makes me very nervous as then our security is only as good as Wildfly's CLI security. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From mposolda at redhat.com Fri May 22 15:43:51 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 22 May 2015 21:43:51 +0200 Subject: [keycloak-dev] Progress on LDAP enhancements In-Reply-To: <973779062.3964356.1432293917891.JavaMail.zimbra@redhat.com> References: <555CFD9C.3020002@redhat.com> <973779062.3964356.1432293917891.JavaMail.zimbra@redhat.com> Message-ID: <555F86F7.7020301@redhat.com> On 22.5.2015 13:25, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Marek Posolda" >> To: keycloak-dev at lists.jboss.org >> Sent: Wednesday, 20 May, 2015 11:33:16 PM >> Subject: [keycloak-dev] Progress on LDAP enhancements >> >> I think I am finished with step 1 prototype on LDAP enhancements. Right >> now it's just in my local fork >> https://github.com/mposolda/keycloak/tree/ldap , I can't send PR as >> model and admin console are kind of broken in my fork (ATM I am testing >> with some hardcoded configs). >> >> What I did so far: >> >> - Refactoring and simplifying of forked picketlink LDAP code and removed >> some abstractions to make it easier to use >> >> - Added UserFederationMapper SPI. The plan is to be in line with already >> existing ProtocolMappers and IdentityProviderMappers. >> >> - Added LDAPFederationMapper. This mapper is invoked from >> LDAPFederationProvider and provides some callbacks and extension points. >> For more details, see methods and javadoc: >> https://github.com/mposolda/keycloak/blob/ldap/federation/ldap/src/main/java/org/keycloak/federation/ldap/mappers/LDAPFederationMapper.java >> . I have 3 implementations right now: >> -- UserAttributeLDAPFederationMapper - This is used to map LDAP >> attributes to UserModel attributes/properties . >> -- FullNameLDAPFederationMapper - Many LDAP deployments store fullName >> of user in single LDAP attribute (usually "cn" attribute). So this >> allows to map fullName from LDAP to firstName and lastName on UserModel >> -- RoleLDAPFederationMapper - allows to map LDAP roles and user role >> mappings from some DN in LDAP tree to either realm roles or client roles >> of some client. Of course it's not a problem to plug more mappers, so >> it's not an issue to map for example LDAP roles from tree >> "ou=finance,dc=myorg,dc=org" to client roles of client "finance" and >> roles from tree "ou=development,dc=myorg,dc=org" to client roles of >> client "development" etc. >> >> - Minor refactoring of some methods on UserFederationProvider interface. >> I needed to add RealmModel as parameter to some methods (it was already >> in most of them) because RealmModel will be used to retrieve list of >> configured UserFederationMapperModels . >> >> >> Next planned steps: >> - Model - I plan to add CRUD for UserFederationMapperModel to RealmModel >> (similarly like IdentityProviderMapperModel) >> >> - Admin console - I've been thinking about new tab "Mappers" under "User >> Federation". The tab will be active when you have some Federation >> provider chosen and it will allow to add/update/remove mappers for >> particular provider. Again something very similar to already existing >> broker mappers. WDYT? > +1 > >> - Address remaining subtasks of >> https://issues.jboss.org/browse/KEYCLOAK-886 . Not everything will be >> addressed by mappers. For example there is performance issue >> https://issues.jboss.org/browse/KEYCLOAK-838 . I am thinking about >> adding some caching at LDAPIdentityStore level, but also I am thinking >> about some simple per-request caching at UserFederationManager level, >> which might help with federation performance in general (not just >> specific to LDAP). Maybe combination of both? But I am not sure atm... >> >> - DB migration >> >> Question: I wonder if we can put RealmModel accessible from >> UserFederationProviderModel? It shouldn't be a problem from >> implementation perspective as UserFederationProviderModel CRUD methods >> are on RealmModel, so realm can just inject itself before return >> UserFederationProviderModel. Since UserFederationProvider instances are >> created by method "getInstance" on UserFederationProviderFactory, which >> has UserFederationProviderModel as one of parameters, it will make >> RealmModel accessible in UserFederationProvider and hence it won't be >> needed to have RealmModel in signature of methods on UserFederationProvider. >> >> WDYT? > Realm is already available from KeycloakContext / session.getContext().getRealm() Yeah, however this is not available in all cases (for example during tests or admin requests). And you can't be sure that RealmModel from the context is the RealmModel corresponding to your UserFederationProviderModel. I think I will keep it as it is for now, also due to some other possible issues. After thinking more it seems that adding RealmModel as variable to UserFederationProviderModel is not very good idea... Marek > >> Marek >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From mposolda at redhat.com Fri May 22 15:46:43 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 22 May 2015 21:46:43 +0200 Subject: [keycloak-dev] Progress on LDAP enhancements In-Reply-To: <555F86F7.7020301@redhat.com> References: <555CFD9C.3020002@redhat.com> <973779062.3964356.1432293917891.JavaMail.zimbra@redhat.com> <555F86F7.7020301@redhat.com> Message-ID: <555F87A3.8000607@redhat.com> I've commited first version to the master. "Mappers" tab is not yet added to admin console, but model works and all the tests are passing. Still quite a lot of work remaining though... Marek On 22.5.2015 21:43, Marek Posolda wrote: > On 22.5.2015 13:25, Stian Thorgersen wrote: >> >> ----- Original Message ----- >>> From: "Marek Posolda" >>> To: keycloak-dev at lists.jboss.org >>> Sent: Wednesday, 20 May, 2015 11:33:16 PM >>> Subject: [keycloak-dev] Progress on LDAP enhancements >>> >>> I think I am finished with step 1 prototype on LDAP enhancements. Right >>> now it's just in my local fork >>> https://github.com/mposolda/keycloak/tree/ldap , I can't send PR as >>> model and admin console are kind of broken in my fork (ATM I am testing >>> with some hardcoded configs). >>> >>> What I did so far: >>> >>> - Refactoring and simplifying of forked picketlink LDAP code and >>> removed >>> some abstractions to make it easier to use >>> >>> - Added UserFederationMapper SPI. The plan is to be in line with >>> already >>> existing ProtocolMappers and IdentityProviderMappers. >>> >>> - Added LDAPFederationMapper. This mapper is invoked from >>> LDAPFederationProvider and provides some callbacks and extension >>> points. >>> For more details, see methods and javadoc: >>> https://github.com/mposolda/keycloak/blob/ldap/federation/ldap/src/main/java/org/keycloak/federation/ldap/mappers/LDAPFederationMapper.java >>> >>> . I have 3 implementations right now: >>> -- UserAttributeLDAPFederationMapper - This is used to map LDAP >>> attributes to UserModel attributes/properties . >>> -- FullNameLDAPFederationMapper - Many LDAP deployments store fullName >>> of user in single LDAP attribute (usually "cn" attribute). So this >>> allows to map fullName from LDAP to firstName and lastName on UserModel >>> -- RoleLDAPFederationMapper - allows to map LDAP roles and user role >>> mappings from some DN in LDAP tree to either realm roles or client >>> roles >>> of some client. Of course it's not a problem to plug more mappers, so >>> it's not an issue to map for example LDAP roles from tree >>> "ou=finance,dc=myorg,dc=org" to client roles of client "finance" and >>> roles from tree "ou=development,dc=myorg,dc=org" to client roles of >>> client "development" etc. >>> >>> - Minor refactoring of some methods on UserFederationProvider >>> interface. >>> I needed to add RealmModel as parameter to some methods (it was already >>> in most of them) because RealmModel will be used to retrieve list of >>> configured UserFederationMapperModels . >>> >>> >>> Next planned steps: >>> - Model - I plan to add CRUD for UserFederationMapperModel to >>> RealmModel >>> (similarly like IdentityProviderMapperModel) >>> >>> - Admin console - I've been thinking about new tab "Mappers" under >>> "User >>> Federation". The tab will be active when you have some Federation >>> provider chosen and it will allow to add/update/remove mappers for >>> particular provider. Again something very similar to already existing >>> broker mappers. WDYT? >> +1 >> >>> - Address remaining subtasks of >>> https://issues.jboss.org/browse/KEYCLOAK-886 . Not everything will be >>> addressed by mappers. For example there is performance issue >>> https://issues.jboss.org/browse/KEYCLOAK-838 . I am thinking about >>> adding some caching at LDAPIdentityStore level, but also I am thinking >>> about some simple per-request caching at UserFederationManager level, >>> which might help with federation performance in general (not just >>> specific to LDAP). Maybe combination of both? But I am not sure atm... >>> >>> - DB migration >>> >>> Question: I wonder if we can put RealmModel accessible from >>> UserFederationProviderModel? It shouldn't be a problem from >>> implementation perspective as UserFederationProviderModel CRUD methods >>> are on RealmModel, so realm can just inject itself before return >>> UserFederationProviderModel. Since UserFederationProvider instances are >>> created by method "getInstance" on UserFederationProviderFactory, which >>> has UserFederationProviderModel as one of parameters, it will make >>> RealmModel accessible in UserFederationProvider and hence it won't be >>> needed to have RealmModel in signature of methods on >>> UserFederationProvider. >>> >>> WDYT? >> Realm is already available from KeycloakContext / >> session.getContext().getRealm() > Yeah, however this is not available in all cases (for example during > tests or admin requests). And you can't be sure that RealmModel from > the context is the RealmModel corresponding to your > UserFederationProviderModel. > > I think I will keep it as it is for now, also due to some other > possible issues. After thinking more it seems that adding RealmModel > as variable to UserFederationProviderModel is not very good idea... > > Marek >> >>> Marek >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> > From ssilvert at redhat.com Fri May 22 18:20:34 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 22 May 2015 18:20:34 -0400 Subject: [keycloak-dev] Reset admin password In-Reply-To: <555F80D6.5010802@redhat.com> References: <555F2543.5070605@redhat.com> <264491439.4008534.1432299415112.JavaMail.zimbra@redhat.com> <555F4A60.60908@redhat.com> <555F4DC7.6040908@redhat.com> <555F57DD.1010003@redhat.com> <555F80D6.5010802@redhat.com> Message-ID: <555FABB2.1050808@redhat.com> On 5/22/2015 3:17 PM, Bill Burke wrote: > > On 5/22/2015 12:22 PM, Marek Posolda wrote: >> On 22.5.2015 17:39, Stan Silvert wrote: >>> On 5/22/2015 11:25 AM, Marek Posolda wrote: >>>> On 22.5.2015 14:56, Stian Thorgersen wrote: >>>>> ----- Original Message ----- >>>>>> From: "Stan Silvert" >>>>>> To: keycloak-dev at lists.jboss.org >>>>>> Sent: Friday, 22 May, 2015 2:46:59 PM >>>>>> Subject: [keycloak-dev] Reset admin password >>>>>> >>>>>> We need a way to reset the admin password in case it is lost or >>>>>> hijacked. The proposal is to do that through an operation on the >>>>>> keycloak-server-subsystem that only runs in "offline CLI" mode. >>>>>> >>>>>> First, we currently allow you to delete the admin user. Should we >>>>>> disallow that and make the master admin user permanent? >>>>> Interesting question - quick answer, not sure! >>>>> >>>>> There are all sorts of things that can be deleted that'll currently >>>>> screw things up royally! For example deleting admin related roles >>>>> and clients. Created https://issues.jboss.org/browse/KEYCLOAK-1340 >>>>> for this. >>>> Similar issue pointed some time ago by Petr Mensik from QA team: if >>>> you change SSO session max lifespan timeout for example to 1 second, >>>> you are immediately logged out from admin console and you're not able >>>> to login again (More accurately you are able to login, but you're >>>> logged out immediately due to session timeout). >>>> >>>> There are likely bunch of similar things and not sure if we can >>>> handle all of them. Question is if these are not just "theoretic" >>>> issues? I can't remember any user complain on ML that he accidentally >>>> broke his keycloak DB by delete/configure something strange in admin >>>> console. >>>> >>>> Marek >>> I think we need to clean these up. You should never be able to do >>> anything from the UI that renders your system inoperable. It's only >>> a matter of time before some big customer has a disaster because we >>> let him do something really stupid. >> Probably yes. However people can possibly fix it by edit DB directly or >> recover their DB (assuming big customer will do DB backup). >> >> But I agree, we can always be a bit resistent against those issues. And >> hopefully CLI could help as well to recover from those. I've created >> https://issues.jboss.org/browse/KEYCLOAK-1341 for 1-second timeout issue. >> > There's actually better ways to accomplish this: > a) credential reset via email > b) credential reset via SMS > c) credential reset via "what is your mother's maiden name" > d) one or more of the above. > > As Marek said, worst case workaround is to write the database record > directly. This whole talk of adding a reset password to CLI makes me > very nervous as then our security is only as good as Wildfly's CLI security. > This operation only works in CLI offline mode. You need access to the file system. So you are relying on the security of the box itself. I'll leave it to others to decide if password recovery is sufficient. From velias at redhat.com Mon May 25 02:16:52 2015 From: velias at redhat.com (Vlastimil Elias) Date: Mon, 25 May 2015 08:16:52 +0200 Subject: [keycloak-dev] User apps and HttpClient In-Reply-To: <923428983.3111623.1432300558434.JavaMail.zimbra@redhat.com> References: <60533052.2790794.1432241800924.JavaMail.zimbra@redhat.com> <555F1C91.7070908@redhat.com> <1211080921.3086903.1432298201554.JavaMail.zimbra@redhat.com> <555F25AC.804@redhat.com> <923428983.3111623.1432300558434.JavaMail.zimbra@redhat.com> Message-ID: <5562BE54.7030009@redhat.com> Hi Marko, thanks, I'll try to prepare reproducer project and attach it to the issue. But I'm also going to remove use of org.keycloak.adapters.HttpClientBuilder from our apps code to make it more stable for future changes. Hope use of plain HttpClient without the keycloak builder will work OK. Thanks Vlastimil On 22.5.2015 15:15, Marko Strukelj wrote: > ----- Original Message ----- >> Hi, >> >> On 22.5.2015 14:36, Marko Strukelj wrote: >>> @Vlastimil - a few questions: >>> >>> Do you use org.keycloak.adapters.HttpClientBuilder in your app? >> yes, colleague (in CC) who create the code used some example how to call >> Keycloak REST API from java code, so he uses this > Ok, in this case you have to make sure to include jboss-deployment-structure.xml that adds dependency on org.apache.httpcomponents. To make sure you use the right slot, open the modules/org/keycloak/keycloak-adapter-core/main/module.xml (could be in modules/system/layers/base). In that file find dependency on org.apache.httpcomponents and check if it has a slot="4.3". > In your jboss-deployment-structure.xml you have to use the same dependency. That's all. Things should then work. > > Or another option that Stian suggested ... don't use HttpClientBuilder at all. Forget about it. Use HttpClient directly. I think in that case it's up to you how you provide HttpClient to your .war. Haven't yet tried though. That one is on TODOs ... > > >>> Do you import any other class from org.keycloak.adapters in your app? >> no >>> Do you package httpclient.jar within your .war by any chance? >> no >>> Do you put jboss-deployment-structure.xml to your .war's /WEB-INF >>> Does your jboss-deployment-structure.xml look like this: >>> >>> >>> >>> >>> >>> >>> >>> >> Yes. I tried this both with and without slot="4.3" attribute but error >> is here in both cases. >> > One of these cases should be a solution to your problem. > >> A bit strange thing is that LinkageError has been thrown in finally >> block on call of >> client.getConnectionManager().shutdown(); >> >> When I commented this out then LinkageError arrised at line with >> HttpResponse response = client.execute(get); >> call, which is still not first occurence of httpclient in the method, >> but I understand that it is classloading problem which is always strange ;-) > Sounds like there is more going on here than what I initially described. There might be more ways of erroneous interaction between multiple versions of HttpClient than we currently see. > If you could make a reproducer and add it to JIRA that would be great ... as I'm a bit in the dark here now. > > It could be related to this issue: https://issues.jboss.org/browse/KEYCLOAK-1338 > > - m -- Vlastimil Elias Principal Software Engineer jboss.org Development Team From mposolda at redhat.com Mon May 25 05:49:17 2015 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 25 May 2015 11:49:17 +0200 Subject: [keycloak-dev] Failed building latest master - as7-subsystem Message-ID: <5562F01D.4000007@redhat.com> I have some issues building latest master. Namely when building "integration/as7-subsystem" I had: [ERROR] Failed to execute goal on project keycloak-as7-subsystem: Could not resolve dependencies for project org.keycloak:keycloak-as7-subsystem:jar:1.3.0.Final-SNAPSHOT: The following artifacts could not be resolved: org.jboss.as:jboss-as-naming:jar:7.5.0.Final-redhat-15, org.jboss.as:jboss-as-server:jar:7.5.0.Final-redhat-15, org.jboss.as:jboss-as-ee:jar:7.5.0.Final-redhat-15, org.jboss.as:jboss-as-web:jar:7.5.0.Final-redhat-15: Could not find artifact org.jboss.as:jboss-as-naming:jar:7.5.0.Final-redhat-15 in jboss-public-repository-group (https://repository.jboss.org/nexus/content/groups/public-jboss) To workaround this, I downloaded jboss-eap-6.4.0.Alpha.zip and unzip it to my local maven repo. I guess we don't want this step to be required for build Keycloak? Is there any public repository, which contains those artifacts and which should be put into pom.xml ? Or am I just missing something? Marek From mstrukel at redhat.com Mon May 25 05:57:13 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Mon, 25 May 2015 05:57:13 -0400 (EDT) Subject: [keycloak-dev] Failed building latest master - as7-subsystem In-Reply-To: <5562F01D.4000007@redhat.com> References: <5562F01D.4000007@redhat.com> Message-ID: <1391536370.3809224.1432547833355.JavaMail.zimbra@redhat.com> Yeah, it's a bug. It happens if you pass -P to your mvn. When maven profile is activated via true any use specifying of profiles via -P will deactivate such profiles that would otherwise be active. I already made a PR for this ... but it's not in the master yet: https://github.com/keycloak/keycloak/pull/1275 You can work around this by first building without -P to make sure artifacts are downloaded to local repo, then build again with -P and it should work. You may have issues if you have a mirror configured as these artifacts are pulled from JBoss Early Access repo ... ----- Original Message ----- > I have some issues building latest master. Namely when building > "integration/as7-subsystem" I had: > > [ERROR] Failed to execute goal on project keycloak-as7-subsystem: Could > not resolve dependencies for project > org.keycloak:keycloak-as7-subsystem:jar:1.3.0.Final-SNAPSHOT: The > following artifacts could not be resolved: > org.jboss.as:jboss-as-naming:jar:7.5.0.Final-redhat-15, > org.jboss.as:jboss-as-server:jar:7.5.0.Final-redhat-15, > org.jboss.as:jboss-as-ee:jar:7.5.0.Final-redhat-15, > org.jboss.as:jboss-as-web:jar:7.5.0.Final-redhat-15: Could not find > artifact org.jboss.as:jboss-as-naming:jar:7.5.0.Final-redhat-15 in > jboss-public-repository-group > (https://repository.jboss.org/nexus/content/groups/public-jboss) > > > To workaround this, I downloaded jboss-eap-6.4.0.Alpha.zip and unzip it > to my local maven repo. I guess we don't want this step to be required > for build Keycloak? Is there any public repository, which contains those > artifacts and which should be put into pom.xml ? Or am I just missing > something? > > Marek > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From mstrukel at redhat.com Mon May 25 06:17:34 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Mon, 25 May 2015 06:17:34 -0400 (EDT) Subject: [keycloak-dev] User apps and HttpClient In-Reply-To: <5562BE54.7030009@redhat.com> References: <60533052.2790794.1432241800924.JavaMail.zimbra@redhat.com> <555F1C91.7070908@redhat.com> <1211080921.3086903.1432298201554.JavaMail.zimbra@redhat.com> <555F25AC.804@redhat.com> <923428983.3111623.1432300558434.JavaMail.zimbra@redhat.com> <5562BE54.7030009@redhat.com> Message-ID: <1347909780.3813587.1432549054134.JavaMail.zimbra@redhat.com> There's a proposed fix for addressing this in our example demos: https://github.com/keycloak/keycloak/pull/1276 With this patch customer-portal, product-portal and other demos always use whatever httpcomponents version is packaged with AS7 / Wildfly without any collision with Keycloak. ----- Original Message ----- > Hi Marko, > > thanks, I'll try to prepare reproducer project and attach it to the issue. > > But I'm also going to remove use of > org.keycloak.adapters.HttpClientBuilder from our apps code to make it > more stable for future changes. > Hope use of plain HttpClient without the keycloak builder will work OK. > > Thanks > > Vlastimil > > > On 22.5.2015 15:15, Marko Strukelj wrote: > > ----- Original Message ----- > >> Hi, > >> > >> On 22.5.2015 14:36, Marko Strukelj wrote: > >>> @Vlastimil - a few questions: > >>> > >>> Do you use org.keycloak.adapters.HttpClientBuilder in your app? > >> yes, colleague (in CC) who create the code used some example how to call > >> Keycloak REST API from java code, so he uses this > > Ok, in this case you have to make sure to include > > jboss-deployment-structure.xml that adds dependency on > > org.apache.httpcomponents. To make sure you use the right slot, open the > > modules/org/keycloak/keycloak-adapter-core/main/module.xml (could be in > > modules/system/layers/base). In that file find dependency on > > org.apache.httpcomponents and check if it has a slot="4.3". > > In your jboss-deployment-structure.xml you have to use the same dependency. > > That's all. Things should then work. > > > > Or another option that Stian suggested ... don't use HttpClientBuilder at > > all. Forget about it. Use HttpClient directly. I think in that case it's > > up to you how you provide HttpClient to your .war. Haven't yet tried > > though. That one is on TODOs ... > > > > > >>> Do you import any other class from org.keycloak.adapters in your app? > >> no > >>> Do you package httpclient.jar within your .war by any chance? > >> no > >>> Do you put jboss-deployment-structure.xml to your .war's /WEB-INF > >>> Does your jboss-deployment-structure.xml look like this: > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >> Yes. I tried this both with and without slot="4.3" attribute but error > >> is here in both cases. > >> > > One of these cases should be a solution to your problem. > > > >> A bit strange thing is that LinkageError has been thrown in finally > >> block on call of > >> client.getConnectionManager().shutdown(); > >> > >> When I commented this out then LinkageError arrised at line with > >> HttpResponse response = client.execute(get); > >> call, which is still not first occurence of httpclient in the method, > >> but I understand that it is classloading problem which is always strange > >> ;-) > > Sounds like there is more going on here than what I initially described. > > There might be more ways of erroneous interaction between multiple > > versions of HttpClient than we currently see. > > If you could make a reproducer and add it to JIRA that would be great ... > > as I'm a bit in the dark here now. > > > > It could be related to this issue: > > https://issues.jboss.org/browse/KEYCLOAK-1338 > > > > - m > > -- > Vlastimil Elias > Principal Software Engineer > jboss.org Development Team > > From mposolda at redhat.com Mon May 25 09:59:23 2015 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 25 May 2015 15:59:23 +0200 Subject: [keycloak-dev] Failed building latest master - as7-subsystem In-Reply-To: <1391536370.3809224.1432547833355.JavaMail.zimbra@redhat.com> References: <5562F01D.4000007@redhat.com> <1391536370.3809224.1432547833355.JavaMail.zimbra@redhat.com> Message-ID: <55632ABB.1070609@redhat.com> Thanks Marko, good to know that you have fix already :-) Actually I didn't use -P but I used JDK8 to build. Seeing there is profile "doclint-java8-disable" declared in pom.xml and active with JDK8, which is maybe why the profile "jboss-earlyaccess-repository" wasn't used. Marek On 25.5.2015 11:57, Marko Strukelj wrote: > Yeah, it's a bug. It happens if you pass -P to your mvn. > > When maven profile is activated via true any use specifying of profiles via -P will deactivate such profiles that would otherwise be active. > > I already made a PR for this ... but it's not in the master yet: https://github.com/keycloak/keycloak/pull/1275 > > You can work around this by first building without -P to make sure artifacts are downloaded to local repo, then build again with -P and it should work. > > You may have issues if you have a mirror configured as these artifacts are pulled from JBoss Early Access repo ... > > > ----- Original Message ----- >> I have some issues building latest master. Namely when building >> "integration/as7-subsystem" I had: >> >> [ERROR] Failed to execute goal on project keycloak-as7-subsystem: Could >> not resolve dependencies for project >> org.keycloak:keycloak-as7-subsystem:jar:1.3.0.Final-SNAPSHOT: The >> following artifacts could not be resolved: >> org.jboss.as:jboss-as-naming:jar:7.5.0.Final-redhat-15, >> org.jboss.as:jboss-as-server:jar:7.5.0.Final-redhat-15, >> org.jboss.as:jboss-as-ee:jar:7.5.0.Final-redhat-15, >> org.jboss.as:jboss-as-web:jar:7.5.0.Final-redhat-15: Could not find >> artifact org.jboss.as:jboss-as-naming:jar:7.5.0.Final-redhat-15 in >> jboss-public-repository-group >> (https://repository.jboss.org/nexus/content/groups/public-jboss) >> >> >> To workaround this, I downloaded jboss-eap-6.4.0.Alpha.zip and unzip it >> to my local maven repo. I guess we don't want this step to be required >> for build Keycloak? Is there any public repository, which contains those >> artifacts and which should be put into pom.xml ? Or am I just missing >> something? >> >> Marek >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From mstrukel at redhat.com Mon May 25 10:43:52 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Mon, 25 May 2015 10:43:52 -0400 (EDT) Subject: [keycloak-dev] Failed building latest master - as7-subsystem In-Reply-To: <55632ABB.1070609@redhat.com> References: <5562F01D.4000007@redhat.com> <1391536370.3809224.1432547833355.JavaMail.zimbra@redhat.com> <55632ABB.1070609@redhat.com> Message-ID: <1688015865.3882989.1432565032500.JavaMail.zimbra@redhat.com> Sorry I didn't send a heads up about it to this mailing list :) The de/activation mechanism you describe would mean that mechanism is even more useless than I thought, as it would auto turn off even more unpredictably. Hopefully the proposed fix works for everybody. ----- Original Message ----- > Thanks Marko, good to know that you have fix already :-) > > Actually I didn't use -P but I used JDK8 to build. Seeing there is > profile "doclint-java8-disable" declared in pom.xml and active with > JDK8, which is maybe why the profile "jboss-earlyaccess-repository" > wasn't used. > > Marek > > On 25.5.2015 11:57, Marko Strukelj wrote: > > Yeah, it's a bug. It happens if you pass -P to your mvn. > > > > When maven profile is activated via true > > any use specifying of profiles via -P will deactivate such profiles that > > would otherwise be active. > > > > I already made a PR for this ... but it's not in the master yet: > > https://github.com/keycloak/keycloak/pull/1275 > > > > You can work around this by first building without -P to make sure > > artifacts are downloaded to local repo, then build again with -P and it > > should work. > > > > You may have issues if you have a mirror configured as these artifacts are > > pulled from JBoss Early Access repo ... > > > > > > ----- Original Message ----- > >> I have some issues building latest master. Namely when building > >> "integration/as7-subsystem" I had: > >> > >> [ERROR] Failed to execute goal on project keycloak-as7-subsystem: Could > >> not resolve dependencies for project > >> org.keycloak:keycloak-as7-subsystem:jar:1.3.0.Final-SNAPSHOT: The > >> following artifacts could not be resolved: > >> org.jboss.as:jboss-as-naming:jar:7.5.0.Final-redhat-15, > >> org.jboss.as:jboss-as-server:jar:7.5.0.Final-redhat-15, > >> org.jboss.as:jboss-as-ee:jar:7.5.0.Final-redhat-15, > >> org.jboss.as:jboss-as-web:jar:7.5.0.Final-redhat-15: Could not find > >> artifact org.jboss.as:jboss-as-naming:jar:7.5.0.Final-redhat-15 in > >> jboss-public-repository-group > >> (https://repository.jboss.org/nexus/content/groups/public-jboss) > >> > >> > >> To workaround this, I downloaded jboss-eap-6.4.0.Alpha.zip and unzip it > >> to my local maven repo. I guess we don't want this step to be required > >> for build Keycloak? Is there any public repository, which contains those > >> artifacts and which should be put into pom.xml ? Or am I just missing > >> something? > >> > >> Marek > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > From stian at redhat.com Tue May 26 02:46:43 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 26 May 2015 02:46:43 -0400 (EDT) Subject: [keycloak-dev] Progress on LDAP enhancements In-Reply-To: <555F86F7.7020301@redhat.com> References: <555CFD9C.3020002@redhat.com> <973779062.3964356.1432293917891.JavaMail.zimbra@redhat.com> <555F86F7.7020301@redhat.com> Message-ID: <1240980435.5334139.1432622803403.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Marek Posolda" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Friday, 22 May, 2015 9:43:51 PM > Subject: Re: [keycloak-dev] Progress on LDAP enhancements > > On 22.5.2015 13:25, Stian Thorgersen wrote: > > > > ----- Original Message ----- > >> From: "Marek Posolda" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Wednesday, 20 May, 2015 11:33:16 PM > >> Subject: [keycloak-dev] Progress on LDAP enhancements > >> > >> I think I am finished with step 1 prototype on LDAP enhancements. Right > >> now it's just in my local fork > >> https://github.com/mposolda/keycloak/tree/ldap , I can't send PR as > >> model and admin console are kind of broken in my fork (ATM I am testing > >> with some hardcoded configs). > >> > >> What I did so far: > >> > >> - Refactoring and simplifying of forked picketlink LDAP code and removed > >> some abstractions to make it easier to use > >> > >> - Added UserFederationMapper SPI. The plan is to be in line with already > >> existing ProtocolMappers and IdentityProviderMappers. > >> > >> - Added LDAPFederationMapper. This mapper is invoked from > >> LDAPFederationProvider and provides some callbacks and extension points. > >> For more details, see methods and javadoc: > >> https://github.com/mposolda/keycloak/blob/ldap/federation/ldap/src/main/java/org/keycloak/federation/ldap/mappers/LDAPFederationMapper.java > >> . I have 3 implementations right now: > >> -- UserAttributeLDAPFederationMapper - This is used to map LDAP > >> attributes to UserModel attributes/properties . > >> -- FullNameLDAPFederationMapper - Many LDAP deployments store fullName > >> of user in single LDAP attribute (usually "cn" attribute). So this > >> allows to map fullName from LDAP to firstName and lastName on UserModel > >> -- RoleLDAPFederationMapper - allows to map LDAP roles and user role > >> mappings from some DN in LDAP tree to either realm roles or client roles > >> of some client. Of course it's not a problem to plug more mappers, so > >> it's not an issue to map for example LDAP roles from tree > >> "ou=finance,dc=myorg,dc=org" to client roles of client "finance" and > >> roles from tree "ou=development,dc=myorg,dc=org" to client roles of > >> client "development" etc. > >> > >> - Minor refactoring of some methods on UserFederationProvider interface. > >> I needed to add RealmModel as parameter to some methods (it was already > >> in most of them) because RealmModel will be used to retrieve list of > >> configured UserFederationMapperModels . > >> > >> > >> Next planned steps: > >> - Model - I plan to add CRUD for UserFederationMapperModel to RealmModel > >> (similarly like IdentityProviderMapperModel) > >> > >> - Admin console - I've been thinking about new tab "Mappers" under "User > >> Federation". The tab will be active when you have some Federation > >> provider chosen and it will allow to add/update/remove mappers for > >> particular provider. Again something very similar to already existing > >> broker mappers. WDYT? > > +1 > > > >> - Address remaining subtasks of > >> https://issues.jboss.org/browse/KEYCLOAK-886 . Not everything will be > >> addressed by mappers. For example there is performance issue > >> https://issues.jboss.org/browse/KEYCLOAK-838 . I am thinking about > >> adding some caching at LDAPIdentityStore level, but also I am thinking > >> about some simple per-request caching at UserFederationManager level, > >> which might help with federation performance in general (not just > >> specific to LDAP). Maybe combination of both? But I am not sure atm... > >> > >> - DB migration > >> > >> Question: I wonder if we can put RealmModel accessible from > >> UserFederationProviderModel? It shouldn't be a problem from > >> implementation perspective as UserFederationProviderModel CRUD methods > >> are on RealmModel, so realm can just inject itself before return > >> UserFederationProviderModel. Since UserFederationProvider instances are > >> created by method "getInstance" on UserFederationProviderFactory, which > >> has UserFederationProviderModel as one of parameters, it will make > >> RealmModel accessible in UserFederationProvider and hence it won't be > >> needed to have RealmModel in signature of methods on > >> UserFederationProvider. > >> > >> WDYT? > > Realm is already available from KeycloakContext / > > session.getContext().getRealm() > Yeah, however this is not available in all cases (for example during > tests or admin requests). And you can't be sure that RealmModel from the > context is the RealmModel corresponding to your > UserFederationProviderModel. For tests it can be fixed. Why can't you be sure it's the same realm? > > I think I will keep it as it is for now, also due to some other possible > issues. After thinking more it seems that adding RealmModel as variable > to UserFederationProviderModel is not very good idea... > > Marek > > > >> Marek > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > From stian at redhat.com Tue May 26 02:53:14 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 26 May 2015 02:53:14 -0400 (EDT) Subject: [keycloak-dev] Reset admin password In-Reply-To: <555F80D6.5010802@redhat.com> References: <555F2543.5070605@redhat.com> <264491439.4008534.1432299415112.JavaMail.zimbra@redhat.com> <555F4A60.60908@redhat.com> <555F4DC7.6040908@redhat.com> <555F57DD.1010003@redhat.com> <555F80D6.5010802@redhat.com> Message-ID: <1223430140.5338205.1432623194100.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Friday, 22 May, 2015 9:17:42 PM > Subject: Re: [keycloak-dev] Reset admin password > > > > On 5/22/2015 12:22 PM, Marek Posolda wrote: > > On 22.5.2015 17:39, Stan Silvert wrote: > >> On 5/22/2015 11:25 AM, Marek Posolda wrote: > >>> On 22.5.2015 14:56, Stian Thorgersen wrote: > >>>> > >>>> ----- Original Message ----- > >>>>> From: "Stan Silvert" > >>>>> To: keycloak-dev at lists.jboss.org > >>>>> Sent: Friday, 22 May, 2015 2:46:59 PM > >>>>> Subject: [keycloak-dev] Reset admin password > >>>>> > >>>>> We need a way to reset the admin password in case it is lost or > >>>>> hijacked. The proposal is to do that through an operation on the > >>>>> keycloak-server-subsystem that only runs in "offline CLI" mode. > >>>>> > >>>>> First, we currently allow you to delete the admin user. Should we > >>>>> disallow that and make the master admin user permanent? > >>>> Interesting question - quick answer, not sure! > >>>> > >>>> There are all sorts of things that can be deleted that'll currently > >>>> screw things up royally! For example deleting admin related roles > >>>> and clients. Created https://issues.jboss.org/browse/KEYCLOAK-1340 > >>>> for this. > >>> Similar issue pointed some time ago by Petr Mensik from QA team: if > >>> you change SSO session max lifespan timeout for example to 1 second, > >>> you are immediately logged out from admin console and you're not able > >>> to login again (More accurately you are able to login, but you're > >>> logged out immediately due to session timeout). > >>> > >>> There are likely bunch of similar things and not sure if we can > >>> handle all of them. Question is if these are not just "theoretic" > >>> issues? I can't remember any user complain on ML that he accidentally > >>> broke his keycloak DB by delete/configure something strange in admin > >>> console. > >>> > >>> Marek > >> I think we need to clean these up. You should never be able to do > >> anything from the UI that renders your system inoperable. It's only > >> a matter of time before some big customer has a disaster because we > >> let him do something really stupid. > > Probably yes. However people can possibly fix it by edit DB directly or > > recover their DB (assuming big customer will do DB backup). > > > > But I agree, we can always be a bit resistent against those issues. And > > hopefully CLI could help as well to recover from those. I've created > > https://issues.jboss.org/browse/KEYCLOAK-1341 for 1-second timeout issue. > > > > There's actually better ways to accomplish this: > a) credential reset via email > b) credential reset via SMS > c) credential reset via "what is your mother's maiden name" > d) one or more of the above. We already have a and b, but those require email and sms to be configured. By the way have you seen http://googleonlinesecurity.blogspot.no/2015/05/new-research-some-tough-questions-for.html - apparently security questions are rubbish ;) > > As Marek said, worst case workaround is to write the database record > directly. This whole talk of adding a reset password to CLI makes me > very nervous as then our security is only as good as Wildfly's CLI security. It's a pretty tough job to reset a password by writing directly to the db, especially as the password needs to be hashed. IMO we just need to make sure the user is local to the box for these operations. Only accessible in offline + locale use of cli. > > > > -- > 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 Tue May 26 02:57:30 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 26 May 2015 02:57:30 -0400 (EDT) Subject: [keycloak-dev] Secret security questions deemed insecure In-Reply-To: <1217673848.5340424.1432623443928.JavaMail.zimbra@redhat.com> Message-ID: <993033584.5340444.1432623450128.JavaMail.zimbra@redhat.com> http://googleonlinesecurity.blogspot.no/2015/05/new-research-some-tough-questions-for.html From stian at redhat.com Tue May 26 03:20:37 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 26 May 2015 03:20:37 -0400 (EDT) Subject: [keycloak-dev] [keycloak-user] Keycloak-1.2.0.Final /$keycloak_home/standalone/deployments folder In-Reply-To: References: Message-ID: <1750170089.5370017.1432624837771.JavaMail.zimbra@redhat.com> http://keycloak.github.io/docs/userguide/html/Migration_from_older_versions.html#d4e3120 http://blog.keycloak.org/2015/05/distribution-changes.html ----- Original Message ----- > From: "Carlos Feria" > To: keycloak-user at lists.jboss.org, keycloak-dev at lists.jboss.org > Sent: Monday, 25 May, 2015 11:42:33 PM > Subject: [keycloak-user] Keycloak-1.2.0.Final /$keycloak_home/standalone/deployments folder > > Hello i'm using keycloak-1.2.0.Final and i can't see the > /$keycloak_home/standalone /deployments folder, so i can't deploy other .war > of my projects...wich is the folder where i can put my .war deployments? > > -- > Carlos E. Feria Vila > > _______________________________________________ > keycloak-user mailing list > keycloak-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user From giriraj.sharma27 at gmail.com Tue May 26 03:23:29 2015 From: giriraj.sharma27 at gmail.com (Giriraj Sharma) Date: Tue, 26 May 2015 12:53:29 +0530 Subject: [keycloak-dev] Keycloak PKI/Certificate Service Implementation Message-ID: We're looking to provide a API to easily enable Key and Certificate Management to Keycloak-based applications. We may have a comprehensive PKI/Certificate service for KC so as to fulfill all key/certificate/JOSE requirements in future roadmap. This is a future consideration/idea and is not meant as a feature to be merged soon. It will be likely to hit KC master as and when the roadmap will require. The idea is turn a realm into a Certification Authority, responsible for issue, validate, revoke and renew certificates for the identity types (eg.: realms, users, applications etc) associated with it. Thus, realm will act as the root CA or realm's certificate(X509 v1) will be self signed and certificates(X509 v3) of identity types will be signed with realm's certificate. So, there will be a pki module with key and certificate authority which will be able to perform all key and certificate related functions and hence will be used as per requirements by identity types(eg.: realms, users, applications etc). In the future, we also want to provide: - RESTful Endpoints to perform not only certificate operations, but also manage keys. Specially public keys. Probably using JSON Web Keys (JWK). - Better support for HTML5 and mobile applications that require some kind of support for certificates, asymmetric keys, signature and encryption. Specially when using JWT and JOSE. - Support Java KeyStores to load and store keys. -Implementation of lets encrypt ACME Specification. -Support for JWS and JWE, if required. After some initial work, I think we have an initial design. Still have to think about, specially regarding the configuration and storage. Basically, what we have so far are two main components: CertificateAuthority and KeyAuthority. The first is about managing keys (eg.: RSA keys) for realm and identity types. The second one is about managing certificates using the keys for a particular type. We have Key and Certificate Authority which can be injected anywhere and be used accordingly. If CDI doesn't appears to be a good choice, then, we can probably directly use these services via method invocations : @Inject private KeyAuthority keyAuthority; @Inject private CertificateAuthority certificateAuthority; More information here : https://gist.github.com/girirajsharma/8d59a674a28560ca0a91 First cut on my local keycloak pki branch : https://github.com/girirajsharma/keycloak/commit/89f20380ece48cbdbc6426ec98d32e4d0751bd29 Cheers, -- Giriraj Sharma about.me/girirajsharma Giriraj Sharma, Department of Computer Science National Institute of Technology Hamirpur Himachal Pradesh, India 177005 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150526/164d6fb1/attachment.html From bburke at redhat.com Tue May 26 08:43:55 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 26 May 2015 08:43:55 -0400 Subject: [keycloak-dev] Keycloak PKI/Certificate Service Implementation In-Reply-To: References: Message-ID: <55646A8B.4090207@redhat.com> I want a facility in the admin console that can create and name one or more keypairs/certificates. Then, we can assign these keypair/certs to various aspects. i.e., Most protocols recommend different keypairs for encryption and signatures. Some clients may want to use HMAC over RSA, etc. On 5/26/2015 3:23 AM, Giriraj Sharma wrote: > We're looking to provide a API to easily enable Key and Certificate > Management to > Keycloak-based applications. We may have a comprehensive PKI/Certificate > service > for KC so as to fulfill all key/certificate/JOSE requirements in future > roadmap. This is a future > consideration/idea and is not meant as a feature to be merged soon. It > will be likely to hit KC master > as and when the roadmap will require. > > The idea is turn a realm into a Certification Authority, > responsible for issue, validate, revoke and renew certificates for the > identity types > (eg.: realms, users, applications etc) associated with it. Thus, realm > will act > as the root CA or realm's certificate(X509 v1) will be self signed and > certificates(X509 v3) of > identity types will be signed with realm's certificate. > > So, there will be a pki module with key and certificate authority which > will be able to > perform all key and certificate related functions and hence will be used > as per requirements > by identity types(eg.: realms, users, applications etc). > > In the future, we also want to provide: > - RESTful Endpoints to perform not only certificate operations, but also > manage keys. > Specially public keys. Probably using JSON Web Keys (JWK). > - Better support for HTML5 and mobile applications that require some > kind of support for certificates, > asymmetric keys, signature and encryption. Specially when using JWT and > JOSE. > - Support Java KeyStores to load and store keys. > > -Implementation of lets encrypt ACME Specification. > -Support for JWS and JWE, if required. > > After some initial work, I think we have an initial design. Still have > to think about, > specially regarding the configuration and storage. > > Basically, what we have so far are two main components: > CertificateAuthority and KeyAuthority. > The first is about managing keys (eg.: RSA keys) for realm and identity > types. > The second one is about managing certificates using the keys for a > particular type. > > We have Key and Certificate Authority which can be injected anywhere and > be used accordingly. > If CDI doesn't appears to be a good choice, then, we can probably > directly use these services via method > invocations : > > @Inject > private KeyAuthority keyAuthority; > > @Inject > private CertificateAuthority certificateAuthority; > > More information here : > https://gist.github.com/girirajsharma/8d59a674a28560ca0a91 > First cut on my local keycloak pki branch : > https://github.com/girirajsharma/keycloak/commit/89f20380ece48cbdbc6426ec98d32e4d0751bd29 > > Cheers, > > -- > Giriraj Sharma > about.me/girirajsharma > > > > Giriraj Sharma, > Department of Computer Science > National Institute of Technology Hamirpur > Himachal Pradesh, India 177005 > > > _______________________________________________ > 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 giriraj.sharma27 at gmail.com Tue May 26 08:57:29 2015 From: giriraj.sharma27 at gmail.com (Giriraj Sharma) Date: Tue, 26 May 2015 18:27:29 +0530 Subject: [keycloak-dev] Keycloak PKI/Certificate Service Implementation In-Reply-To: <55646A8B.4090207@redhat.com> References: <55646A8B.4090207@redhat.com> Message-ID: Acknowledged. Certificate/Key Configuration Authority will facilitate setting configuration for almost all config parameters( eg. key/cert signature algorithm, encryption algorithm, signature/secure random algorithm provider, bit length, validity etc.). On Tue, May 26, 2015 at 6:13 PM, Bill Burke wrote: > I want a facility in the admin console that can create and name one or > more keypairs/certificates. Then, we can assign these keypair/certs to > various aspects. i.e., Most protocols recommend different keypairs for > encryption and signatures. Some clients may want to use HMAC over RSA, > etc. > > On 5/26/2015 3:23 AM, Giriraj Sharma wrote: > > We're looking to provide a API to easily enable Key and Certificate > > Management to > > Keycloak-based applications. We may have a comprehensive PKI/Certificate > > service > > for KC so as to fulfill all key/certificate/JOSE requirements in future > > roadmap. This is a future > > consideration/idea and is not meant as a feature to be merged soon. It > > will be likely to hit KC master > > as and when the roadmap will require. > > > > The idea is turn a realm into a Certification Authority, > > responsible for issue, validate, revoke and renew certificates for the > > identity types > > (eg.: realms, users, applications etc) associated with it. Thus, realm > > will act > > as the root CA or realm's certificate(X509 v1) will be self signed and > > certificates(X509 v3) of > > identity types will be signed with realm's certificate. > > > > So, there will be a pki module with key and certificate authority which > > will be able to > > perform all key and certificate related functions and hence will be used > > as per requirements > > by identity types(eg.: realms, users, applications etc). > > > > In the future, we also want to provide: > > - RESTful Endpoints to perform not only certificate operations, but also > > manage keys. > > Specially public keys. Probably using JSON Web Keys (JWK). > > - Better support for HTML5 and mobile applications that require some > > kind of support for certificates, > > asymmetric keys, signature and encryption. Specially when using JWT and > > JOSE. > > - Support Java KeyStores to load and store keys. > > > > -Implementation of lets encrypt ACME Specification. > > -Support for JWS and JWE, if required. > > > > After some initial work, I think we have an initial design. Still have > > to think about, > > specially regarding the configuration and storage. > > > > Basically, what we have so far are two main components: > > CertificateAuthority and KeyAuthority. > > The first is about managing keys (eg.: RSA keys) for realm and identity > > types. > > The second one is about managing certificates using the keys for a > > particular type. > > > > We have Key and Certificate Authority which can be injected anywhere and > > be used accordingly. > > If CDI doesn't appears to be a good choice, then, we can probably > > directly use these services via method > > invocations : > > > > @Inject > > private KeyAuthority keyAuthority; > > > > @Inject > > private CertificateAuthority certificateAuthority; > > > > More information here : > > https://gist.github.com/girirajsharma/8d59a674a28560ca0a91 > > First cut on my local keycloak pki branch : > > > https://github.com/girirajsharma/keycloak/commit/89f20380ece48cbdbc6426ec98d32e4d0751bd29 > > > > Cheers, > > > > -- > > Giriraj Sharma > > about.me/girirajsharma > > > > > > > > Giriraj Sharma, > > Department of Computer Science > > National Institute of Technology Hamirpur > > Himachal Pradesh, India 177005 > > > > > > _______________________________________________ > > 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 > -- Giriraj Sharma about.me/girirajsharma Giriraj Sharma, Department of Computer Science National Institute of Technology Hamirpur Himachal Pradesh, India 177005 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150526/e3ddfa33/attachment.html From mstrukel at redhat.com Tue May 26 11:03:01 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Tue, 26 May 2015 11:03:01 -0400 (EDT) Subject: [keycloak-dev] Generating logout / account links in secured web app In-Reply-To: <1451481324.4366887.1432650998651.JavaMail.zimbra@redhat.com> Message-ID: <1620984937.4403355.1432652581307.JavaMail.zimbra@redhat.com> I've been trying to make sure that logout functionality works properly within demos deployed on AS7/Wildfly, with Keycloak server in another WF instance on a different port. Debug stepping through code I can see that there is properly configured org.keycloak.adapters.KeycloakDeployment instance available which contains all the proper info, yet is not used in demo apps. Rather, the demo apps manually compose relative urls which then point to the local instance rather than remote instance where Keycloak server resides. For example, customer-app.war/customers/view.jsp contains: String logoutUri = KeycloakUriBuilder.fromUri("/auth").path(ServiceUrlConstants.TOKEN_SERVICE_LOGOUT_PATH) .queryParam("redirect_uri", "/customer-portal").build("demo").toString(); String acctUri = KeycloakUriBuilder.fromUri("/auth").path(ServiceUrlConstants.ACCOUNT_SERVICE_PATH) .queryParam("referrer", "customer-portal").build("demo").toString(); These both produce relative urls ... org.keycloak.util.KeycloakUriBuilder looks like it could be part of public API, org.keycloak.constants.ServiceUrlConstants could be problematic as public API since final string fields are copied over to classes using them at compile time. But anyway ... I would like a way in my webapp to get to information that's in KeycloakDeployment, specifically #getLogoutUrl(), and #getAccountUrl(). By itself KeycloakDeployment doesn't look API ready, also there's ?redirect_uri= or ?referer= to be specified so there must be some other utility or API classes that can return the proper urls using already available info. Makes no sense to manually compose them in round-about and error prone ways from my app ... Is there a known way to achieve this or is this something we can add - maybe to org.keycloak.adapters.AdapterUtils. Also, I'm not sure that AdapterUtils.getOriginForRestCalls() works properly by returning a relative url on NEVER in the case when server is on a different host / port than secured web app. From mposolda at redhat.com Tue May 26 13:03:18 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 26 May 2015 19:03:18 +0200 Subject: [keycloak-dev] Progress on LDAP enhancements In-Reply-To: <1240980435.5334139.1432622803403.JavaMail.zimbra@redhat.com> References: <555CFD9C.3020002@redhat.com> <973779062.3964356.1432293917891.JavaMail.zimbra@redhat.com> <555F86F7.7020301@redhat.com> <1240980435.5334139.1432622803403.JavaMail.zimbra@redhat.com> Message-ID: <5564A756.8010202@redhat.com> On 26.5.2015 08:46, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Marek Posolda" >> To: "Stian Thorgersen" >> Cc: keycloak-dev at lists.jboss.org >> Sent: Friday, 22 May, 2015 9:43:51 PM >> Subject: Re: [keycloak-dev] Progress on LDAP enhancements >> >> On 22.5.2015 13:25, Stian Thorgersen wrote: >>> ----- Original Message ----- >>>> From: "Marek Posolda" >>>> To: keycloak-dev at lists.jboss.org >>>> Sent: Wednesday, 20 May, 2015 11:33:16 PM >>>> Subject: [keycloak-dev] Progress on LDAP enhancements >>>> >>>> I think I am finished with step 1 prototype on LDAP enhancements. Right >>>> now it's just in my local fork >>>> https://github.com/mposolda/keycloak/tree/ldap , I can't send PR as >>>> model and admin console are kind of broken in my fork (ATM I am testing >>>> with some hardcoded configs). >>>> >>>> What I did so far: >>>> >>>> - Refactoring and simplifying of forked picketlink LDAP code and removed >>>> some abstractions to make it easier to use >>>> >>>> - Added UserFederationMapper SPI. The plan is to be in line with already >>>> existing ProtocolMappers and IdentityProviderMappers. >>>> >>>> - Added LDAPFederationMapper. This mapper is invoked from >>>> LDAPFederationProvider and provides some callbacks and extension points. >>>> For more details, see methods and javadoc: >>>> https://github.com/mposolda/keycloak/blob/ldap/federation/ldap/src/main/java/org/keycloak/federation/ldap/mappers/LDAPFederationMapper.java >>>> . I have 3 implementations right now: >>>> -- UserAttributeLDAPFederationMapper - This is used to map LDAP >>>> attributes to UserModel attributes/properties . >>>> -- FullNameLDAPFederationMapper - Many LDAP deployments store fullName >>>> of user in single LDAP attribute (usually "cn" attribute). So this >>>> allows to map fullName from LDAP to firstName and lastName on UserModel >>>> -- RoleLDAPFederationMapper - allows to map LDAP roles and user role >>>> mappings from some DN in LDAP tree to either realm roles or client roles >>>> of some client. Of course it's not a problem to plug more mappers, so >>>> it's not an issue to map for example LDAP roles from tree >>>> "ou=finance,dc=myorg,dc=org" to client roles of client "finance" and >>>> roles from tree "ou=development,dc=myorg,dc=org" to client roles of >>>> client "development" etc. >>>> >>>> - Minor refactoring of some methods on UserFederationProvider interface. >>>> I needed to add RealmModel as parameter to some methods (it was already >>>> in most of them) because RealmModel will be used to retrieve list of >>>> configured UserFederationMapperModels . >>>> >>>> >>>> Next planned steps: >>>> - Model - I plan to add CRUD for UserFederationMapperModel to RealmModel >>>> (similarly like IdentityProviderMapperModel) >>>> >>>> - Admin console - I've been thinking about new tab "Mappers" under "User >>>> Federation". The tab will be active when you have some Federation >>>> provider chosen and it will allow to add/update/remove mappers for >>>> particular provider. Again something very similar to already existing >>>> broker mappers. WDYT? >>> +1 >>> >>>> - Address remaining subtasks of >>>> https://issues.jboss.org/browse/KEYCLOAK-886 . Not everything will be >>>> addressed by mappers. For example there is performance issue >>>> https://issues.jboss.org/browse/KEYCLOAK-838 . I am thinking about >>>> adding some caching at LDAPIdentityStore level, but also I am thinking >>>> about some simple per-request caching at UserFederationManager level, >>>> which might help with federation performance in general (not just >>>> specific to LDAP). Maybe combination of both? But I am not sure atm... >>>> >>>> - DB migration >>>> >>>> Question: I wonder if we can put RealmModel accessible from >>>> UserFederationProviderModel? It shouldn't be a problem from >>>> implementation perspective as UserFederationProviderModel CRUD methods >>>> are on RealmModel, so realm can just inject itself before return >>>> UserFederationProviderModel. Since UserFederationProvider instances are >>>> created by method "getInstance" on UserFederationProviderFactory, which >>>> has UserFederationProviderModel as one of parameters, it will make >>>> RealmModel accessible in UserFederationProvider and hence it won't be >>>> needed to have RealmModel in signature of methods on >>>> UserFederationProvider. >>>> >>>> WDYT? >>> Realm is already available from KeycloakContext / >>> session.getContext().getRealm() >> Yeah, however this is not available in all cases (for example during >> tests or admin requests). And you can't be sure that RealmModel from the >> context is the RealmModel corresponding to your >> UserFederationProviderModel. > For tests it can be fixed. How about admin requests? Currently both "realm" and "client" are null in session.getContext() . Should we set realm to context in RealmsAdminResource.getRealmAdmin ? And similarly client before ClientResource is invoked? It's a bit tricky as admin can be authenticated to realm "master" but he is administrating realm "foo", but it seems to me that it's fine to set the realm, which he is administrating (sending admin requests too) rather than the realm where he is authenticated. > Why can't you be sure it's the same realm? I mean for example if you have code like this: RealmModel masterRealm = session.realms().getRealmByName("master"); UserModel admin = session.users().getUserByUsername("admin", masterRealm); RealmModel fooRealm = session.realms().getRealmByName("foo"); UserModel foo = session.users().getUserByUsername("foo", fooRealm); and both realms are configured to use federation and realm "foo" is set in the context. Then when calling the second line: session.users().getUserByUsername("admin", masterRealm) the UserFederationProvider will use incorrect realm "foo" from the context when it should use realm "master" . It seems the proper behaviour is, that UserFederationManager will just use the realm send to the "getUserByUsername" (or any other method) as argument and pass same realm instance to the UserFederationProvider as argument. Is it clearer what I mean? Marek >> I think I will keep it as it is for now, also due to some other possible >> issues. After thinking more it seems that adding RealmModel as variable >> to UserFederationProviderModel is not very good idea... >> >> Marek >>>> Marek >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >> From jpkroehling at redhat.com Tue May 26 13:08:08 2015 From: jpkroehling at redhat.com (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=) Date: Tue, 26 May 2015 19:08:08 +0200 Subject: [keycloak-dev] Persistent token Message-ID: <5564A878.7060508@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 All, For Hawkular, we have an agent that runs on behalf of an user on a separate machine (a server), sending metrics to our backend, secured by Keycloak. While we could perform all the OAuth steps in our agent code, a goal for us is to make it as easy as possible for third-parties to write "agents". So, having a basic-auth-like scenario is the ideal scenario for us. I think I have discussed this scenario earlier with Marek and/or Stian via IRC but I don't think a conclusion was made back then. Basically, what we would need is either a "persistent token" or a key/secret mechanism. For now, we are making the agent use the basic-auth, but that implies in the agent knowing the user's password (which is not ideal). As I understand that there were some talks about this before, I would like to understand what's the current (planned) solution for this scenario. Depending on how it goes, I can start with a PoC and send it as a PR for Keycloak. - - Juca. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVZKh4AAoJECKM1e+fkPrXdoUH/3DJty468AQ0MQgo5SokCrfu GvfGkDi0yMvOutsPdAYVGLxwUAFNFXICG1x/iP3UZYHcZgqzuclwMJQOV3/RKNAb uGn5VlllV5rhUnJiF49QeGVrYwB/O9llkRty5jzIzo0vej8eZl8LIQroxjIwpCEQ gy9OwBnj60mBcTvE33EgKKhAsBQ+aVKCFsc/LLDPxBljWvwk5o4OOwJ7HoqFoOI6 Jh78ehOJam1cJug8U3wBWvf9VI2cZzxTAw5fUlM7YBwqR1ewiYsk2XrxQP7DTu76 F0fYsi/fK2y8LA84K+QAztxXvOb5GiS/t6ZZAUER/ZkyzFUJ6qf908gwgqZKWA8= =dcGk -----END PGP SIGNATURE----- From stian at redhat.com Wed May 27 02:42:55 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 27 May 2015 02:42:55 -0400 (EDT) Subject: [keycloak-dev] Progress on LDAP enhancements In-Reply-To: <5564A756.8010202@redhat.com> References: <555CFD9C.3020002@redhat.com> <973779062.3964356.1432293917891.JavaMail.zimbra@redhat.com> <555F86F7.7020301@redhat.com> <1240980435.5334139.1432622803403.JavaMail.zimbra@redhat.com> <5564A756.8010202@redhat.com> Message-ID: <1815867709.6260251.1432708975187.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Marek Posolda" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Tuesday, 26 May, 2015 7:03:18 PM > Subject: Re: [keycloak-dev] Progress on LDAP enhancements > > On 26.5.2015 08:46, Stian Thorgersen wrote: > > > > ----- Original Message ----- > >> From: "Marek Posolda" > >> To: "Stian Thorgersen" > >> Cc: keycloak-dev at lists.jboss.org > >> Sent: Friday, 22 May, 2015 9:43:51 PM > >> Subject: Re: [keycloak-dev] Progress on LDAP enhancements > >> > >> On 22.5.2015 13:25, Stian Thorgersen wrote: > >>> ----- Original Message ----- > >>>> From: "Marek Posolda" > >>>> To: keycloak-dev at lists.jboss.org > >>>> Sent: Wednesday, 20 May, 2015 11:33:16 PM > >>>> Subject: [keycloak-dev] Progress on LDAP enhancements > >>>> > >>>> I think I am finished with step 1 prototype on LDAP enhancements. Right > >>>> now it's just in my local fork > >>>> https://github.com/mposolda/keycloak/tree/ldap , I can't send PR as > >>>> model and admin console are kind of broken in my fork (ATM I am testing > >>>> with some hardcoded configs). > >>>> > >>>> What I did so far: > >>>> > >>>> - Refactoring and simplifying of forked picketlink LDAP code and removed > >>>> some abstractions to make it easier to use > >>>> > >>>> - Added UserFederationMapper SPI. The plan is to be in line with already > >>>> existing ProtocolMappers and IdentityProviderMappers. > >>>> > >>>> - Added LDAPFederationMapper. This mapper is invoked from > >>>> LDAPFederationProvider and provides some callbacks and extension points. > >>>> For more details, see methods and javadoc: > >>>> https://github.com/mposolda/keycloak/blob/ldap/federation/ldap/src/main/java/org/keycloak/federation/ldap/mappers/LDAPFederationMapper.java > >>>> . I have 3 implementations right now: > >>>> -- UserAttributeLDAPFederationMapper - This is used to map LDAP > >>>> attributes to UserModel attributes/properties . > >>>> -- FullNameLDAPFederationMapper - Many LDAP deployments store fullName > >>>> of user in single LDAP attribute (usually "cn" attribute). So this > >>>> allows to map fullName from LDAP to firstName and lastName on UserModel > >>>> -- RoleLDAPFederationMapper - allows to map LDAP roles and user role > >>>> mappings from some DN in LDAP tree to either realm roles or client roles > >>>> of some client. Of course it's not a problem to plug more mappers, so > >>>> it's not an issue to map for example LDAP roles from tree > >>>> "ou=finance,dc=myorg,dc=org" to client roles of client "finance" and > >>>> roles from tree "ou=development,dc=myorg,dc=org" to client roles of > >>>> client "development" etc. > >>>> > >>>> - Minor refactoring of some methods on UserFederationProvider interface. > >>>> I needed to add RealmModel as parameter to some methods (it was already > >>>> in most of them) because RealmModel will be used to retrieve list of > >>>> configured UserFederationMapperModels . > >>>> > >>>> > >>>> Next planned steps: > >>>> - Model - I plan to add CRUD for UserFederationMapperModel to RealmModel > >>>> (similarly like IdentityProviderMapperModel) > >>>> > >>>> - Admin console - I've been thinking about new tab "Mappers" under "User > >>>> Federation". The tab will be active when you have some Federation > >>>> provider chosen and it will allow to add/update/remove mappers for > >>>> particular provider. Again something very similar to already existing > >>>> broker mappers. WDYT? > >>> +1 > >>> > >>>> - Address remaining subtasks of > >>>> https://issues.jboss.org/browse/KEYCLOAK-886 . Not everything will be > >>>> addressed by mappers. For example there is performance issue > >>>> https://issues.jboss.org/browse/KEYCLOAK-838 . I am thinking about > >>>> adding some caching at LDAPIdentityStore level, but also I am thinking > >>>> about some simple per-request caching at UserFederationManager level, > >>>> which might help with federation performance in general (not just > >>>> specific to LDAP). Maybe combination of both? But I am not sure atm... > >>>> > >>>> - DB migration > >>>> > >>>> Question: I wonder if we can put RealmModel accessible from > >>>> UserFederationProviderModel? It shouldn't be a problem from > >>>> implementation perspective as UserFederationProviderModel CRUD methods > >>>> are on RealmModel, so realm can just inject itself before return > >>>> UserFederationProviderModel. Since UserFederationProvider instances are > >>>> created by method "getInstance" on UserFederationProviderFactory, which > >>>> has UserFederationProviderModel as one of parameters, it will make > >>>> RealmModel accessible in UserFederationProvider and hence it won't be > >>>> needed to have RealmModel in signature of methods on > >>>> UserFederationProvider. > >>>> > >>>> WDYT? > >>> Realm is already available from KeycloakContext / > >>> session.getContext().getRealm() > >> Yeah, however this is not available in all cases (for example during > >> tests or admin requests). And you can't be sure that RealmModel from the > >> context is the RealmModel corresponding to your > >> UserFederationProviderModel. > > For tests it can be fixed. > How about admin requests? Currently both "realm" and "client" are null > in session.getContext() . Should we set realm to context in > RealmsAdminResource.getRealmAdmin ? And similarly client before > ClientResource is invoked? > > It's a bit tricky as admin can be authenticated to realm "master" but he > is administrating realm "foo", but it seems to me that it's fine to set > the realm, which he is administrating (sending admin requests too) > rather than the realm where he is authenticated. > > Why can't you be sure it's the same realm? > I mean for example if you have code like this: > > RealmModel masterRealm = session.realms().getRealmByName("master"); > UserModel admin = session.users().getUserByUsername("admin", masterRealm); > > RealmModel fooRealm = session.realms().getRealmByName("foo"); > UserModel foo = session.users().getUserByUsername("foo", fooRealm); > > and both realms are configured to use federation and realm "foo" is set > in the context. Then when calling the second line: > > session.users().getUserByUsername("admin", masterRealm) > > the UserFederationProvider will use incorrect realm "foo" from the > context when it should use realm "master" . > > It seems the proper behaviour is, that UserFederationManager will just > use the realm send to the "getUserByUsername" (or any other method) as > argument and pass same realm instance to the UserFederationProvider as > argument. Is it clearer what I mean? Yep, I think passing the realm is what works for now, but I wonder if a session should always be linked to a specific realm, rather than having to pass the realm around all the time. > > Marek > >> I think I will keep it as it is for now, also due to some other possible > >> issues. After thinking more it seems that adding RealmModel as variable > >> to UserFederationProviderModel is not very good idea... > >> > >> Marek > >>>> Marek > >>>> _______________________________________________ > >>>> keycloak-dev mailing list > >>>> keycloak-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>> > >> > > From stian at redhat.com Wed May 27 03:12:34 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 27 May 2015 03:12:34 -0400 (EDT) Subject: [keycloak-dev] Persistent token In-Reply-To: <5564A878.7060508@redhat.com> References: <5564A878.7060508@redhat.com> Message-ID: <1529163647.6273939.1432710754110.JavaMail.zimbra@redhat.com> To support "agents" or other non-humans we intend to add two things to Keycloak: * Client accounts - these are basically a account that's linked to a specific client * Client auth mechanisms - cert and/or jwt/jws auth mechanisms for clients There's is standard flows in OpenID Connect for clients to authenticate as themselves to retrieve tokens. We don't have this yet though. Do you want an agent to authenticate as itself, or on behalf of a user? In either case for the time being you should use direct grant to obtain a refresh token and store that. I would recommend you create a small lib that makes it very easy for an agent to do that. Something like (pseudo code, with no thoughts about usability): Auth auth = Auth.init("client-id", "client-secret", "username", "password"); String token = auth.getToken(); Under the covers this would invoke Keycloak's direct grant api to obtain a token. In the future when we add support for client account and client auth mechanisms it could be simplified to: Auth auth = Auth.init("client-id", "client-secret"); or X509Certificate cert = loadCert(); Auth auth = Auth.init("client-id", cert); ----- Original Message ----- > From: "Juraci Paix?o Kr?hling" > To: keycloak-dev at lists.jboss.org > Sent: Tuesday, 26 May, 2015 7:08:08 PM > Subject: [keycloak-dev] Persistent token > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > All, > > For Hawkular, we have an agent that runs on behalf of an user on a > separate machine (a server), sending metrics to our backend, secured > by Keycloak. > > While we could perform all the OAuth steps in our agent code, a goal > for us is to make it as easy as possible for third-parties to write > "agents". So, having a basic-auth-like scenario is the ideal scenario > for us. > > I think I have discussed this scenario earlier with Marek and/or Stian > via IRC but I don't think a conclusion was made back then. > > Basically, what we would need is either a "persistent token" or a > key/secret mechanism. For now, we are making the agent use the > basic-auth, but that implies in the agent knowing the user's password > (which is not ideal). > > As I understand that there were some talks about this before, I would > like to understand what's the current (planned) solution for this > scenario. Depending on how it goes, I can start with a PoC and send it > as a PR for Keycloak. > > - - Juca. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJVZKh4AAoJECKM1e+fkPrXdoUH/3DJty468AQ0MQgo5SokCrfu > GvfGkDi0yMvOutsPdAYVGLxwUAFNFXICG1x/iP3UZYHcZgqzuclwMJQOV3/RKNAb > uGn5VlllV5rhUnJiF49QeGVrYwB/O9llkRty5jzIzo0vej8eZl8LIQroxjIwpCEQ > gy9OwBnj60mBcTvE33EgKKhAsBQ+aVKCFsc/LLDPxBljWvwk5o4OOwJ7HoqFoOI6 > Jh78ehOJam1cJug8U3wBWvf9VI2cZzxTAw5fUlM7YBwqR1ewiYsk2XrxQP7DTu76 > F0fYsi/fK2y8LA84K+QAztxXvOb5GiS/t6ZZAUER/ZkyzFUJ6qf908gwgqZKWA8= > =dcGk > -----END PGP SIGNATURE----- > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From juraci at kroehling.de Wed May 27 04:40:19 2015 From: juraci at kroehling.de (=?UTF-8?B?SnVyYWNpIFBhaXjDo28gS3LDtmhsaW5n?=) Date: Wed, 27 May 2015 10:40:19 +0200 Subject: [keycloak-dev] Persistent token In-Reply-To: <1529163647.6273939.1432710754110.JavaMail.zimbra@redhat.com> References: <5564A878.7060508@redhat.com> <1529163647.6273939.1432710754110.JavaMail.zimbra@redhat.com> Message-ID: <556582F3.7010708@kroehling.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05/27/2015 09:12 AM, Stian Thorgersen wrote: > To support "agents" or other non-humans we intend to add two things > to Keycloak: > > * Client accounts - these are basically a account that's linked to > a specific client * Client auth mechanisms - cert and/or jwt/jws > auth mechanisms for clients > > There's is standard flows in OpenID Connect for clients to > authenticate as themselves to retrieve tokens. We don't have this > yet though. If there are plans on how to achieve that, I can help on this, as that's something we'd need on Hawkular. > Do you want an agent to authenticate as itself, or on behalf of a > user? In either case for the time being you should use direct grant > to obtain a refresh token and store that. I would recommend you > create a small lib that makes it very easy for an agent to do that. > Something like (pseudo code, with no thoughts about usability): On behalf of an user, so that we know under which account the data should be stored. For the direct grant/token retrieval: let's split the issue in three parts. We have our own agent, then we might have third-party tools and finally we have custom collectors, written by sysadmins. For our own agent, we can spend some time in "doing the right thing", including optimization of HTTP calls, secure storage of tokens and so on. So, even though it would be more complex than ideal, our agent is still under our control. For third-party tools, we could provide libraries that would handle this part. We'd prefer not to, as this is maintenance cost that we might not be able to afford right now, specially we have to provide APIs for "all" major languages. But for the sysadmins, we'd really need the simplest possible solution that works from the command line. The target here is to tell sysadmins: "here's a sample curl call that you could make", and let them do it. Having them worry about getting a token, parsing JSON and so on is something we are trying to avoid. - - Juca. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVZYLzAAoJEDnJtskdmzLM23UH/0sK/o+1RdIx7JDEgxQmMcE6 KmsxE72nkrbVbju3jjTn62h87L7TMpRH7w4qjVo3ekCdfN/Qd2D6FMpzAcIPaigM 7J9w5DH66Ibyj39sGynREjWvVWMDv5PV+79m3m22o1TNtkR5v9bzIhxsr749kpit p9GNJSLlorqRx8E0YtpGjEuoCo36NjdoW5kV3LnvO1iMiYJ3LxosnizrkWpBS0Sb RgSyxihB6vc2IL7+7DuxAOPSnb2tVmYyVYDB/WembpDExveVEDxJWv6yjR5mTGtd 7QPNUWTUGcnozjEeoiFXOP988+9RWfv1afCRhMjq7RFfbp8G9judjAY1kt+ly1U= =R815 -----END PGP SIGNATURE----- From stian at redhat.com Wed May 27 05:50:27 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 27 May 2015 05:50:27 -0400 (EDT) Subject: [keycloak-dev] Persistent token In-Reply-To: <556582F3.7010708@kroehling.de> References: <5564A878.7060508@redhat.com> <1529163647.6273939.1432710754110.JavaMail.zimbra@redhat.com> <556582F3.7010708@kroehling.de> Message-ID: <688890843.6368243.1432720227378.JavaMail.zimbra@redhat.com> Just discussed this idea with Juraci on IRC: 1. Hawkular console provides a mechanism to link an agent - Hawkular creates a client on behalf of the agent - Hawkular creates a refresh token using the direct grant api and stores this in a db - Hawkular console displays a reference to the token to the admin - Admin copy/paste the reference into the agent 2. When agent invokes Hawkular it includes the token reference in the Authorization header 3. A proxy/filter in front of Hawkular services swaps the token reference with an access token - It should keep access tokens in memory, if one exists for the ref, it should check expiration. If still valid just swap reference in header with access token - If access token doesn't exist in memory or is expired, it should retrieve refresh token from persistent store and use it to obtain an access token from Keycloak. We need to add support for offline tokens in Keycloak to support this idea. Otherwise admins have to re-link agents when the refresh token expires. The benefits of this approach are: * Very simple code in agents - just need to add a hard-coded string (token reference) to a header before invoking Hawkular * No need to store username/password in agents (which would be the case if http basic was used) * Users can revoke access to specific agents through account management ----- Original Message ----- > From: "Juraci Paix?o Kr?hling" > To: keycloak-dev at lists.jboss.org > Sent: Wednesday, 27 May, 2015 10:40:19 AM > Subject: Re: [keycloak-dev] Persistent token > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 05/27/2015 09:12 AM, Stian Thorgersen wrote: > > To support "agents" or other non-humans we intend to add two things > > to Keycloak: > > > > * Client accounts - these are basically a account that's linked to > > a specific client * Client auth mechanisms - cert and/or jwt/jws > > auth mechanisms for clients > > > > There's is standard flows in OpenID Connect for clients to > > authenticate as themselves to retrieve tokens. We don't have this > > yet though. > > If there are plans on how to achieve that, I can help on this, as > that's something we'd need on Hawkular. > > > Do you want an agent to authenticate as itself, or on behalf of a > > user? In either case for the time being you should use direct grant > > to obtain a refresh token and store that. I would recommend you > > create a small lib that makes it very easy for an agent to do that. > > Something like (pseudo code, with no thoughts about usability): > > On behalf of an user, so that we know under which account the data > should be stored. > > For the direct grant/token retrieval: let's split the issue in three > parts. We have our own agent, then we might have third-party tools and > finally we have custom collectors, written by sysadmins. > > For our own agent, we can spend some time in "doing the right thing", > including optimization of HTTP calls, secure storage of tokens and so > on. So, even though it would be more complex than ideal, our agent is > still under our control. > > For third-party tools, we could provide libraries that would handle > this part. We'd prefer not to, as this is maintenance cost that we > might not be able to afford right now, specially we have to provide > APIs for "all" major languages. > > But for the sysadmins, we'd really need the simplest possible solution > that works from the command line. The target here is to tell > sysadmins: "here's a sample curl call that you could make", and let > them do it. Having them worry about getting a token, parsing JSON and > so on is something we are trying to avoid. > > - - Juca. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJVZYLzAAoJEDnJtskdmzLM23UH/0sK/o+1RdIx7JDEgxQmMcE6 > KmsxE72nkrbVbju3jjTn62h87L7TMpRH7w4qjVo3ekCdfN/Qd2D6FMpzAcIPaigM > 7J9w5DH66Ibyj39sGynREjWvVWMDv5PV+79m3m22o1TNtkR5v9bzIhxsr749kpit > p9GNJSLlorqRx8E0YtpGjEuoCo36NjdoW5kV3LnvO1iMiYJ3LxosnizrkWpBS0Sb > RgSyxihB6vc2IL7+7DuxAOPSnb2tVmYyVYDB/WembpDExveVEDxJWv6yjR5mTGtd > 7QPNUWTUGcnozjEeoiFXOP988+9RWfv1afCRhMjq7RFfbp8G9judjAY1kt+ly1U= > =R815 > -----END PGP SIGNATURE----- > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From mposolda at redhat.com Wed May 27 07:07:31 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 27 May 2015 13:07:31 +0200 Subject: [keycloak-dev] Dynamically compute LIST values in ProviderConfigProperty Message-ID: <5565A573.3000702@redhat.com> UserFederationMapper is using ConfiguredProvider like other mappers. In Role LDAP Mapper, I want to display combobox with the list of all the realm clients, so user can choose, which client roles will be mapped to LDAP roles. I need RealmModel instance for this. Currently I can see those possible solutions: 1) Make admin requests to have RealmModel (and possibly ClientModel) available in KeycloakContext (currently is null). As I mentioned in other mail yesterday, we can possibly set RealmModel in RealmsAdminResource.getRealmAdmin . Similarly ClientModel can be set later before ClientResource is instantiated. 2) Add RealmModel as argument on "ConfiguredProvider.getConfigProperties" method 3) Use method "getConfigProperties(RealmModel realm)" just in my provider and ignore the "getConfigProperties()" from ConfiguredProvider. Currently I have it already working with (3), but I don't like it very much... It seems to me that (1) is best. Solution (2) is also not very good IMO (also because protocolMappers are tight to the client and not to the realm) It looks to me that IdentityProviderMapper may also need realm to retrieve the roles dynamically. The current solution where user manually needs to fill "clientName.roleName" is likely not very good (not user friendly and it won't work for realm role with dot in the name like "my.cool.realm.role" ). Also I wonder if ProviderConfigProperty should support MAP type in addition to the list? Then we can use key/value pairs instead of just flat values. That will allow that users will see client/role names in the combobox in the UI, but chosen value will be client/role ID. WDYT? Marek From mposolda at redhat.com Wed May 27 07:18:11 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 27 May 2015 13:18:11 +0200 Subject: [keycloak-dev] Dynamically compute LIST values in ProviderConfigProperty In-Reply-To: <5565A573.3000702@redhat.com> References: <5565A573.3000702@redhat.com> Message-ID: <5565A7F3.1070506@redhat.com> On 27.5.2015 13:07, Marek Posolda wrote: > UserFederationMapper is using ConfiguredProvider like other mappers. > In Role LDAP Mapper, I want to display combobox with the list of all > the realm clients, so user can choose, which client roles will be > mapped to LDAP roles. I need RealmModel instance for this. Currently I > can see those possible solutions: > > 1) Make admin requests to have RealmModel (and possibly ClientModel) > available in KeycloakContext (currently is null). As I mentioned in > other mail yesterday, we can possibly set RealmModel in > RealmsAdminResource.getRealmAdmin . Similarly ClientModel can be set > later before ClientResource is instantiated. > > 2) Add RealmModel as argument on > "ConfiguredProvider.getConfigProperties" method > > 3) Use method "getConfigProperties(RealmModel realm)" just in my > provider and ignore the "getConfigProperties()" from ConfiguredProvider. > > Currently I have it already working with (3), but I don't like it very > much... It seems to me that (1) is best. Solution (2) is also not very > good IMO (also because protocolMappers are tight to the client and not > to the realm) > > It looks to me that IdentityProviderMapper may also need realm to > retrieve the roles dynamically. The current solution where user > manually needs to fill "clientName.roleName" is likely not very good > (not user friendly and it won't work for realm role with dot in the > name like "my.cool.realm.role" ). > > Also I wonder if ProviderConfigProperty should support MAP type in > addition to the list? Then we can use key/value pairs instead of just > flat values. That will allow that users will see client/role names in > the combobox in the UI, but chosen value will be client/role ID. I meant "chosen key", which will be used as the configuration value in the backend will be client/role ID. > WDYT? > Marek From stian at redhat.com Wed May 27 09:17:44 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 27 May 2015 09:17:44 -0400 (EDT) Subject: [keycloak-dev] Dynamically compute LIST values in ProviderConfigProperty In-Reply-To: <5565A7F3.1070506@redhat.com> References: <5565A573.3000702@redhat.com> <5565A7F3.1070506@redhat.com> Message-ID: <685616349.6565901.1432732664816.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Marek Posolda" > To: keycloak-dev at lists.jboss.org > Sent: Wednesday, 27 May, 2015 1:18:11 PM > Subject: Re: [keycloak-dev] Dynamically compute LIST values in ProviderConfigProperty > > On 27.5.2015 13:07, Marek Posolda wrote: > > UserFederationMapper is using ConfiguredProvider like other mappers. > > In Role LDAP Mapper, I want to display combobox with the list of all > > the realm clients, so user can choose, which client roles will be > > mapped to LDAP roles. I need RealmModel instance for this. Currently I > > can see those possible solutions: > > > > 1) Make admin requests to have RealmModel (and possibly ClientModel) > > available in KeycloakContext (currently is null). As I mentioned in > > other mail yesterday, we can possibly set RealmModel in > > RealmsAdminResource.getRealmAdmin . Similarly ClientModel can be set > > later before ClientResource is instantiated. > > > > 2) Add RealmModel as argument on > > "ConfiguredProvider.getConfigProperties" method > > > > 3) Use method "getConfigProperties(RealmModel realm)" just in my > > provider and ignore the "getConfigProperties()" from ConfiguredProvider. > > > > Currently I have it already working with (3), but I don't like it very > > much... It seems to me that (1) is best. Solution (2) is also not very > > good IMO (also because protocolMappers are tight to the client and not > > to the realm) +1 To option 1 - we should get rid of passing the realm around and instead rely on KeycloakContext > > > > It looks to me that IdentityProviderMapper may also need realm to > > retrieve the roles dynamically. The current solution where user > > manually needs to fill "clientName.roleName" is likely not very good > > (not user friendly and it won't work for realm role with dot in the > > name like "my.cool.realm.role" ). +1000 > > > > Also I wonder if ProviderConfigProperty should support MAP type in > > addition to the list? Then we can use key/value pairs instead of just > > flat values. That will allow that users will see client/role names in > > the combobox in the UI, but chosen value will be client/role ID. > I meant "chosen key", which will be used as the configuration value in > the backend will be client/role ID. > > > 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 May 27 10:23:38 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 27 May 2015 10:23:38 -0400 Subject: [keycloak-dev] Dynamically compute LIST values in ProviderConfigProperty In-Reply-To: <685616349.6565901.1432732664816.JavaMail.zimbra@redhat.com> References: <5565A573.3000702@redhat.com> <5565A7F3.1070506@redhat.com> <685616349.6565901.1432732664816.JavaMail.zimbra@redhat.com> Message-ID: <5565D36A.90706@redhat.com> I was thinking that we'd just add new types beyond STRING, BOOLEAN, LIST etc. Just add a ROLE_LIST and CLIENT_LIST ProviderConfigProperty type, the admin console would see that type, and just display an appropriate UI for selecting that type. Down the line we couldadd types like CERTIFICATE_LIST, USER_SEARCH, etc... I don't think a getConfigProperties(RealmModel) is needed. The admin console already knows the current realm and it can itself query for the ROLE/Client list to display to choose from. Following me? Another approach would be to allow the Provider to specify a partial html page and javascript to import. On 5/27/2015 9:17 AM, Stian Thorgersen wrote: > > > ----- Original Message ----- >> From: "Marek Posolda" >> To: keycloak-dev at lists.jboss.org >> Sent: Wednesday, 27 May, 2015 1:18:11 PM >> Subject: Re: [keycloak-dev] Dynamically compute LIST values in ProviderConfigProperty >> >> On 27.5.2015 13:07, Marek Posolda wrote: >>> UserFederationMapper is using ConfiguredProvider like other mappers. >>> In Role LDAP Mapper, I want to display combobox with the list of all >>> the realm clients, so user can choose, which client roles will be >>> mapped to LDAP roles. I need RealmModel instance for this. Currently I >>> can see those possible solutions: >>> >>> 1) Make admin requests to have RealmModel (and possibly ClientModel) >>> available in KeycloakContext (currently is null). As I mentioned in >>> other mail yesterday, we can possibly set RealmModel in >>> RealmsAdminResource.getRealmAdmin . Similarly ClientModel can be set >>> later before ClientResource is instantiated. >>> >>> 2) Add RealmModel as argument on >>> "ConfiguredProvider.getConfigProperties" method >>> >>> 3) Use method "getConfigProperties(RealmModel realm)" just in my >>> provider and ignore the "getConfigProperties()" from ConfiguredProvider. >>> >>> Currently I have it already working with (3), but I don't like it very >>> much... It seems to me that (1) is best. Solution (2) is also not very >>> good IMO (also because protocolMappers are tight to the client and not >>> to the realm) > > +1 To option 1 - we should get rid of passing the realm around and instead rely on KeycloakContext > >>> >>> It looks to me that IdentityProviderMapper may also need realm to >>> retrieve the roles dynamically. The current solution where user >>> manually needs to fill "clientName.roleName" is likely not very good >>> (not user friendly and it won't work for realm role with dot in the >>> name like "my.cool.realm.role" ). > > +1000 > >>> >>> Also I wonder if ProviderConfigProperty should support MAP type in >>> addition to the list? Then we can use key/value pairs instead of just >>> flat values. That will allow that users will see client/role names in >>> the combobox in the UI, but chosen value will be client/role ID. >> I meant "chosen key", which will be used as the configuration value in >> the backend will be client/role ID. >> >>> WDYT? >>> Marek >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From matzew at apache.org Wed May 27 11:26:08 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 27 May 2015 17:26:08 +0200 Subject: [keycloak-dev] Keycloak 1.2.0 - more template issues/changes? Message-ID: Hi, for UPS 1.0.3 we used the 1.0.5.Final version Keycloak. We are using a custom WAR file that we feed w/ some configuration: * https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/servers/auth-server/src/main/webapp/WEB-INF/ups-realm.json * https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/servers/auth-server/src/main/resources/META-INF/keycloak-server.json Now, after logging in to UPS (w/ our admin), I am also able to access the "Admin UI Console" of Keycloak http(s)://SERVER:PORT/auth/admin/aerogear/console/index.html That works fine w/ 1.1.0 of Keycloak as well. However, when trying to access the "auth/admin/aerogear/console/index.html" URL w/ 1.2.0.Final, I am getting a 500 error and some stack (see below). Looks like a bit more changes on the template are required? See also Stian's commit from last week https://github.com/matzew/aerogear-unifiedpush-server/commit/6d1142cb70bf8f37eb336fa9f6a0df41a292ee55 Oh, and the login to UPS itself is all fine and is great, it is just the access to "Admin UI Console" of Keycloak seems broken: 17:20:53,621 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth].[Keycloak REST Interface]] (http-/0.0.0.0:8080-4) JBWEB000236: Servlet.service() for servlet Keycloak REST Interface threw exception: java.lang.RuntimeException: request path: /auth/admin/aerogear/console/ at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:54) [keycloak-services-1.2.0.Final.jar:1.2.0.Final] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] Caused by: org.jboss.resteasy.spi.UnhandledException: org.keycloak.freemarker.FreeMarkerException: Failed to process template index.ftl at org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:364) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:232) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:208) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:556) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:523) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41) [keycloak-services-1.2.0.Final.jar:1.2.0.Final] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:40) [keycloak-services-1.2.0.Final.jar:1.2.0.Final] ... 15 more Caused by: org.keycloak.freemarker.FreeMarkerException: Failed to process template index.ftl at org.keycloak.freemarker.FreeMarkerUtil.processTemplate(FreeMarkerUtil.java:47) [keycloak-forms-common-freemarker-1.2.0.Final.jar:1.2.0.Final] at org.keycloak.services.resources.admin.AdminConsole.getMainPage(AdminConsole.java:292) [keycloak-services-1.2.0.Final.jar:1.2.0.Final] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_65] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_65] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_65] at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65] at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:168) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:158) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:91) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:541) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] ... 27 more Caused by: java.io.FileNotFoundException: Template "index.ftl" not found. at freemarker.template.Configuration.getTemplate(Configuration.java:742) [freemarker-2.3.20.jar:2.3.20] at freemarker.template.Configuration.getTemplate(Configuration.java:665) [freemarker-2.3.20.jar:2.3.20] at org.keycloak.freemarker.FreeMarkerUtil.getTemplate(FreeMarkerUtil.java:54) [keycloak-forms-common-freemarker-1.2.0.Final.jar:1.2.0.Final] at org.keycloak.freemarker.FreeMarkerUtil.processTemplate(FreeMarkerUtil.java:34) [keycloak-forms-common-freemarker-1.2.0.Final.jar:1.2.0.Final] ... 38 more Any thoughts? -Matthias PS: I think it's unrelated, but I am running on EAP 6.4 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150527/121b0be0/attachment-0001.html From sblanc at redhat.com Wed May 27 12:58:52 2015 From: sblanc at redhat.com (Sebastien Blanc) Date: Wed, 27 May 2015 18:58:52 +0200 Subject: [keycloak-dev] Keycloak 1.2.0 - more template issues/changes? In-Reply-To: References: Message-ID: Could this be related to that http://lists.jboss.org/pipermail/keycloak-dev/2015-February/003864.html ? On Wed, May 27, 2015 at 5:26 PM, Matthias Wessendorf wrote: > Hi, > > for UPS 1.0.3 we used the 1.0.5.Final version Keycloak. > > We are using a custom WAR file that we feed w/ some configuration: > * > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/servers/auth-server/src/main/webapp/WEB-INF/ups-realm.json > * > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/servers/auth-server/src/main/resources/META-INF/keycloak-server.json > > Now, after logging in to UPS (w/ our admin), I am also able to access the > "Admin UI Console" of Keycloak > http(s)://SERVER:PORT/auth/admin/aerogear/console/index.html > > > That works fine w/ 1.1.0 of Keycloak as well. > > However, when trying to access the > "auth/admin/aerogear/console/index.html" URL w/ 1.2.0.Final, I am getting a > 500 error and some stack (see below). > > Looks like a bit more changes on the template are required? > See also Stian's commit from last week > https://github.com/matzew/aerogear-unifiedpush-server/commit/6d1142cb70bf8f37eb336fa9f6a0df41a292ee55 > > > Oh, and the login to UPS itself is all fine and is great, it is just the > access to "Admin UI Console" of Keycloak seems broken: > > > 17:20:53,621 ERROR > [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth].[Keycloak > REST Interface]] (http-/0.0.0.0:8080-4) JBWEB000236: Servlet.service() > for servlet Keycloak REST Interface threw exception: > java.lang.RuntimeException: request path: /auth/admin/aerogear/console/ > at > org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:54) > [keycloak-services-1.2.0.Final.jar:1.2.0.Final] > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at > org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) > [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at > org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) > [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at > org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) > [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] > Caused by: org.jboss.resteasy.spi.UnhandledException: > org.keycloak.freemarker.FreeMarkerException: Failed to process template > index.ftl > at > org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:364) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at > org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:232) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at > org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:208) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at > org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:556) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:523) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) > [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2] > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at > org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41) > [keycloak-services-1.2.0.Final.jar:1.2.0.Final] > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at > org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:40) > [keycloak-services-1.2.0.Final.jar:1.2.0.Final] > ... 15 more > Caused by: org.keycloak.freemarker.FreeMarkerException: Failed to process > template index.ftl > at > org.keycloak.freemarker.FreeMarkerUtil.processTemplate(FreeMarkerUtil.java:47) > [keycloak-forms-common-freemarker-1.2.0.Final.jar:1.2.0.Final] > at > org.keycloak.services.resources.admin.AdminConsole.getMainPage(AdminConsole.java:292) > [keycloak-services-1.2.0.Final.jar:1.2.0.Final] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [rt.jar:1.7.0_65] > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > [rt.jar:1.7.0_65] > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [rt.jar:1.7.0_65] > at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65] > at > org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:168) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at > org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at > org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:158) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:91) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at > org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:541) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > ... 27 more > Caused by: java.io.FileNotFoundException: Template "index.ftl" not found. > at freemarker.template.Configuration.getTemplate(Configuration.java:742) > [freemarker-2.3.20.jar:2.3.20] > at freemarker.template.Configuration.getTemplate(Configuration.java:665) > [freemarker-2.3.20.jar:2.3.20] > at > org.keycloak.freemarker.FreeMarkerUtil.getTemplate(FreeMarkerUtil.java:54) > [keycloak-forms-common-freemarker-1.2.0.Final.jar:1.2.0.Final] > at > org.keycloak.freemarker.FreeMarkerUtil.processTemplate(FreeMarkerUtil.java:34) > [keycloak-forms-common-freemarker-1.2.0.Final.jar:1.2.0.Final] > ... 38 more > > > Any thoughts? > > -Matthias > > PS: I think it's unrelated, but I am running on EAP 6.4 > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150527/0fb16d53/attachment.html From sblanc at redhat.com Wed May 27 13:15:11 2015 From: sblanc at redhat.com (Sebastien Blanc) Date: Wed, 27 May 2015 19:15:11 +0200 Subject: [keycloak-dev] Keycloak 1.2.0 - more template issues/changes? In-Reply-To: References: Message-ID: Nevermind it's unrelated but I found the issue, Matzew you can cherry-pick this : https://github.com/sebastienblanc/aerogear-unified-push-server/commit/af01e241691879b20702e0b98d4d5a8defdcb3b7 On Wed, May 27, 2015 at 6:58 PM, Sebastien Blanc wrote: > Could this be related to that > http://lists.jboss.org/pipermail/keycloak-dev/2015-February/003864.html ? > > On Wed, May 27, 2015 at 5:26 PM, Matthias Wessendorf > wrote: > >> Hi, >> >> for UPS 1.0.3 we used the 1.0.5.Final version Keycloak. >> >> We are using a custom WAR file that we feed w/ some configuration: >> * >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/servers/auth-server/src/main/webapp/WEB-INF/ups-realm.json >> * >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/servers/auth-server/src/main/resources/META-INF/keycloak-server.json >> >> Now, after logging in to UPS (w/ our admin), I am also able to access the >> "Admin UI Console" of Keycloak >> http(s)://SERVER:PORT/auth/admin/aerogear/console/index.html >> >> >> That works fine w/ 1.1.0 of Keycloak as well. >> >> However, when trying to access the >> "auth/admin/aerogear/console/index.html" URL w/ 1.2.0.Final, I am getting a >> 500 error and some stack (see below). >> >> Looks like a bit more changes on the template are required? >> See also Stian's commit from last week >> https://github.com/matzew/aerogear-unifiedpush-server/commit/6d1142cb70bf8f37eb336fa9f6a0df41a292ee55 >> >> >> Oh, and the login to UPS itself is all fine and is great, it is just the >> access to "Admin UI Console" of Keycloak seems broken: >> >> >> 17:20:53,621 ERROR >> [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth].[Keycloak >> REST Interface]] (http-/0.0.0.0:8080-4) JBWEB000236: Servlet.service() >> for servlet Keycloak REST Interface threw exception: >> java.lang.RuntimeException: request path: /auth/admin/aerogear/console/ >> at >> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:54) >> [keycloak-services-1.2.0.Final.jar:1.2.0.Final] >> at >> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) >> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >> at >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) >> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >> at >> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) >> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >> at >> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) >> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >> at >> org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) >> [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] >> at >> org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) >> [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] >> at >> org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) >> [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] >> at >> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) >> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >> at >> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) >> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >> at >> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) >> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >> at >> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) >> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >> at >> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) >> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >> at >> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) >> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >> at >> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) >> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] >> Caused by: org.jboss.resteasy.spi.UnhandledException: >> org.keycloak.freemarker.FreeMarkerException: Failed to process template >> index.ftl >> at >> org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:364) >> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >> at >> org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:232) >> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >> at >> org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:208) >> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >> at >> org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:556) >> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >> at >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:523) >> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >> at >> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) >> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >> at >> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) >> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >> at >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) >> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >> at >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) >> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) >> [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2] >> at >> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) >> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >> at >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) >> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >> at >> org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41) >> [keycloak-services-1.2.0.Final.jar:1.2.0.Final] >> at >> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) >> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >> at >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) >> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >> at >> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:40) >> [keycloak-services-1.2.0.Final.jar:1.2.0.Final] >> ... 15 more >> Caused by: org.keycloak.freemarker.FreeMarkerException: Failed to process >> template index.ftl >> at >> org.keycloak.freemarker.FreeMarkerUtil.processTemplate(FreeMarkerUtil.java:47) >> [keycloak-forms-common-freemarker-1.2.0.Final.jar:1.2.0.Final] >> at >> org.keycloak.services.resources.admin.AdminConsole.getMainPage(AdminConsole.java:292) >> [keycloak-services-1.2.0.Final.jar:1.2.0.Final] >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> [rt.jar:1.7.0_65] >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >> [rt.jar:1.7.0_65] >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> [rt.jar:1.7.0_65] >> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65] >> at >> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:168) >> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >> at >> org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269) >> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227) >> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >> at >> org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:158) >> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >> at >> org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:91) >> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >> at >> org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:541) >> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >> ... 27 more >> Caused by: java.io.FileNotFoundException: Template "index.ftl" not found. >> at freemarker.template.Configuration.getTemplate(Configuration.java:742) >> [freemarker-2.3.20.jar:2.3.20] >> at freemarker.template.Configuration.getTemplate(Configuration.java:665) >> [freemarker-2.3.20.jar:2.3.20] >> at >> org.keycloak.freemarker.FreeMarkerUtil.getTemplate(FreeMarkerUtil.java:54) >> [keycloak-forms-common-freemarker-1.2.0.Final.jar:1.2.0.Final] >> at >> org.keycloak.freemarker.FreeMarkerUtil.processTemplate(FreeMarkerUtil.java:34) >> [keycloak-forms-common-freemarker-1.2.0.Final.jar:1.2.0.Final] >> ... 38 more >> >> >> Any thoughts? >> >> -Matthias >> >> PS: I think it's unrelated, but I am running on EAP 6.4 >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150527/cb93c645/attachment-0001.html From matzew at apache.org Wed May 27 13:27:19 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 27 May 2015 19:27:19 +0200 Subject: [keycloak-dev] Keycloak 1.2.0 - more template issues/changes? In-Reply-To: References: Message-ID: ah, great; will do On Wednesday, May 27, 2015, Sebastien Blanc wrote: > Nevermind it's unrelated but I found the issue, Matzew you can cherry-pick > this : > > https://github.com/sebastienblanc/aerogear-unified-push-server/commit/af01e241691879b20702e0b98d4d5a8defdcb3b7 > > > On Wed, May 27, 2015 at 6:58 PM, Sebastien Blanc > wrote: > >> Could this be related to that >> http://lists.jboss.org/pipermail/keycloak-dev/2015-February/003864.html >> ? >> >> On Wed, May 27, 2015 at 5:26 PM, Matthias Wessendorf > > wrote: >> >>> Hi, >>> >>> for UPS 1.0.3 we used the 1.0.5.Final version Keycloak. >>> >>> We are using a custom WAR file that we feed w/ some configuration: >>> * >>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/servers/auth-server/src/main/webapp/WEB-INF/ups-realm.json >>> * >>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/servers/auth-server/src/main/resources/META-INF/keycloak-server.json >>> >>> Now, after logging in to UPS (w/ our admin), I am also able to access >>> the "Admin UI Console" of Keycloak >>> http(s)://SERVER:PORT/auth/admin/aerogear/console/index.html >>> >>> >>> That works fine w/ 1.1.0 of Keycloak as well. >>> >>> However, when trying to access the >>> "auth/admin/aerogear/console/index.html" URL w/ 1.2.0.Final, I am getting a >>> 500 error and some stack (see below). >>> >>> Looks like a bit more changes on the template are required? >>> See also Stian's commit from last week >>> https://github.com/matzew/aerogear-unifiedpush-server/commit/6d1142cb70bf8f37eb336fa9f6a0df41a292ee55 >>> >>> >>> Oh, and the login to UPS itself is all fine and is great, it is just the >>> access to "Admin UI Console" of Keycloak seems broken: >>> >>> >>> 17:20:53,621 ERROR >>> [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth].[Keycloak >>> REST Interface]] (http-/0.0.0.0:8080-4) JBWEB000236: Servlet.service() >>> for servlet Keycloak REST Interface threw exception: >>> java.lang.RuntimeException: request path: /auth/admin/aerogear/console/ >>> at >>> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:54) >>> [keycloak-services-1.2.0.Final.jar:1.2.0.Final] >>> at >>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) >>> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >>> at >>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) >>> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >>> at >>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) >>> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >>> at >>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) >>> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >>> at >>> org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) >>> [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] >>> at >>> org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) >>> [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] >>> at >>> org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) >>> [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] >>> at >>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) >>> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >>> at >>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) >>> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >>> at >>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) >>> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >>> at >>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) >>> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >>> at >>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) >>> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >>> at >>> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) >>> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >>> at >>> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) >>> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >>> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] >>> Caused by: org.jboss.resteasy.spi.UnhandledException: >>> org.keycloak.freemarker.FreeMarkerException: Failed to process template >>> index.ftl >>> at >>> org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:364) >>> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >>> at >>> org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:232) >>> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >>> at >>> org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:208) >>> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >>> at >>> org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:556) >>> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >>> at >>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:523) >>> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >>> at >>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) >>> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >>> at >>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) >>> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >>> at >>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) >>> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >>> at >>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) >>> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) >>> [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2] >>> at >>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) >>> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >>> at >>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) >>> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >>> at >>> org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41) >>> [keycloak-services-1.2.0.Final.jar:1.2.0.Final] >>> at >>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) >>> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >>> at >>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) >>> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >>> at >>> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:40) >>> [keycloak-services-1.2.0.Final.jar:1.2.0.Final] >>> ... 15 more >>> Caused by: org.keycloak.freemarker.FreeMarkerException: Failed to >>> process template index.ftl >>> at >>> org.keycloak.freemarker.FreeMarkerUtil.processTemplate(FreeMarkerUtil.java:47) >>> [keycloak-forms-common-freemarker-1.2.0.Final.jar:1.2.0.Final] >>> at >>> org.keycloak.services.resources.admin.AdminConsole.getMainPage(AdminConsole.java:292) >>> [keycloak-services-1.2.0.Final.jar:1.2.0.Final] >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> [rt.jar:1.7.0_65] >>> at >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >>> [rt.jar:1.7.0_65] >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> [rt.jar:1.7.0_65] >>> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65] >>> at >>> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:168) >>> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >>> at >>> org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269) >>> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >>> at >>> org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227) >>> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >>> at >>> org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:158) >>> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >>> at >>> org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:91) >>> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >>> at >>> org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:541) >>> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >>> ... 27 more >>> Caused by: java.io.FileNotFoundException: Template "index.ftl" not found. >>> at freemarker.template.Configuration.getTemplate(Configuration.java:742) >>> [freemarker-2.3.20.jar:2.3.20] >>> at freemarker.template.Configuration.getTemplate(Configuration.java:665) >>> [freemarker-2.3.20.jar:2.3.20] >>> at >>> org.keycloak.freemarker.FreeMarkerUtil.getTemplate(FreeMarkerUtil.java:54) >>> [keycloak-forms-common-freemarker-1.2.0.Final.jar:1.2.0.Final] >>> at >>> org.keycloak.freemarker.FreeMarkerUtil.processTemplate(FreeMarkerUtil.java:34) >>> [keycloak-forms-common-freemarker-1.2.0.Final.jar:1.2.0.Final] >>> ... 38 more >>> >>> >>> Any thoughts? >>> >>> -Matthias >>> >>> PS: I think it's unrelated, but I am running on EAP 6.4 >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150527/ecd52914/attachment.html From matzew at apache.org Wed May 27 13:41:51 2015 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 27 May 2015 19:41:51 +0200 Subject: [keycloak-dev] Keycloak 1.2.0 - more template issues/changes? In-Reply-To: References: Message-ID: great, that did it On Wed, May 27, 2015 at 7:27 PM, Matthias Wessendorf wrote: > ah, great; will do > > > On Wednesday, May 27, 2015, Sebastien Blanc wrote: > >> Nevermind it's unrelated but I found the issue, Matzew you can >> cherry-pick this : >> >> https://github.com/sebastienblanc/aerogear-unified-push-server/commit/af01e241691879b20702e0b98d4d5a8defdcb3b7 >> >> >> On Wed, May 27, 2015 at 6:58 PM, Sebastien Blanc >> wrote: >> >>> Could this be related to that >>> http://lists.jboss.org/pipermail/keycloak-dev/2015-February/003864.html >>> ? >>> >>> On Wed, May 27, 2015 at 5:26 PM, Matthias Wessendorf >>> wrote: >>> >>>> Hi, >>>> >>>> for UPS 1.0.3 we used the 1.0.5.Final version Keycloak. >>>> >>>> We are using a custom WAR file that we feed w/ some configuration: >>>> * >>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/servers/auth-server/src/main/webapp/WEB-INF/ups-realm.json >>>> * >>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/servers/auth-server/src/main/resources/META-INF/keycloak-server.json >>>> >>>> Now, after logging in to UPS (w/ our admin), I am also able to access >>>> the "Admin UI Console" of Keycloak >>>> http(s)://SERVER:PORT/auth/admin/aerogear/console/index.html >>>> >>>> >>>> That works fine w/ 1.1.0 of Keycloak as well. >>>> >>>> However, when trying to access the >>>> "auth/admin/aerogear/console/index.html" URL w/ 1.2.0.Final, I am getting a >>>> 500 error and some stack (see below). >>>> >>>> Looks like a bit more changes on the template are required? >>>> See also Stian's commit from last week >>>> https://github.com/matzew/aerogear-unifiedpush-server/commit/6d1142cb70bf8f37eb336fa9f6a0df41a292ee55 >>>> >>>> >>>> Oh, and the login to UPS itself is all fine and is great, it is just >>>> the access to "Admin UI Console" of Keycloak seems broken: >>>> >>>> >>>> 17:20:53,621 ERROR >>>> [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth].[Keycloak >>>> REST Interface]] (http-/0.0.0.0:8080-4) JBWEB000236: Servlet.service() >>>> for servlet Keycloak REST Interface threw exception: >>>> java.lang.RuntimeException: request path: /auth/admin/aerogear/console/ >>>> at >>>> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:54) >>>> [keycloak-services-1.2.0.Final.jar:1.2.0.Final] >>>> at >>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) >>>> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >>>> at >>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) >>>> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >>>> at >>>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) >>>> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >>>> at >>>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) >>>> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >>>> at >>>> org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) >>>> [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] >>>> at >>>> org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) >>>> [jboss-as-jpa-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] >>>> at >>>> org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) >>>> [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21] >>>> at >>>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) >>>> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >>>> at >>>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) >>>> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >>>> at >>>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) >>>> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >>>> at >>>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) >>>> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >>>> at >>>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) >>>> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >>>> at >>>> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) >>>> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >>>> at >>>> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) >>>> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >>>> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65] >>>> Caused by: org.jboss.resteasy.spi.UnhandledException: >>>> org.keycloak.freemarker.FreeMarkerException: Failed to process template >>>> index.ftl >>>> at >>>> org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:364) >>>> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >>>> at >>>> org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:232) >>>> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >>>> at >>>> org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:208) >>>> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >>>> at >>>> org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:556) >>>> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >>>> at >>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:523) >>>> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >>>> at >>>> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) >>>> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >>>> at >>>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) >>>> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >>>> at >>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) >>>> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >>>> at >>>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) >>>> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) >>>> [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2] >>>> at >>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) >>>> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >>>> at >>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) >>>> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >>>> at >>>> org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41) >>>> [keycloak-services-1.2.0.Final.jar:1.2.0.Final] >>>> at >>>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) >>>> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >>>> at >>>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) >>>> [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] >>>> at >>>> org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:40) >>>> [keycloak-services-1.2.0.Final.jar:1.2.0.Final] >>>> ... 15 more >>>> Caused by: org.keycloak.freemarker.FreeMarkerException: Failed to >>>> process template index.ftl >>>> at >>>> org.keycloak.freemarker.FreeMarkerUtil.processTemplate(FreeMarkerUtil.java:47) >>>> [keycloak-forms-common-freemarker-1.2.0.Final.jar:1.2.0.Final] >>>> at >>>> org.keycloak.services.resources.admin.AdminConsole.getMainPage(AdminConsole.java:292) >>>> [keycloak-services-1.2.0.Final.jar:1.2.0.Final] >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>> [rt.jar:1.7.0_65] >>>> at >>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >>>> [rt.jar:1.7.0_65] >>>> at >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> [rt.jar:1.7.0_65] >>>> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65] >>>> at >>>> org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:168) >>>> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >>>> at >>>> org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269) >>>> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >>>> at >>>> org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227) >>>> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >>>> at >>>> org.jboss.resteasy.core.ResourceLocator.invokeOnTargetObject(ResourceLocator.java:158) >>>> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >>>> at >>>> org.jboss.resteasy.core.ResourceLocator.invoke(ResourceLocator.java:91) >>>> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >>>> at >>>> org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:541) >>>> [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] >>>> ... 27 more >>>> Caused by: java.io.FileNotFoundException: Template "index.ftl" not >>>> found. >>>> at >>>> freemarker.template.Configuration.getTemplate(Configuration.java:742) >>>> [freemarker-2.3.20.jar:2.3.20] >>>> at >>>> freemarker.template.Configuration.getTemplate(Configuration.java:665) >>>> [freemarker-2.3.20.jar:2.3.20] >>>> at >>>> org.keycloak.freemarker.FreeMarkerUtil.getTemplate(FreeMarkerUtil.java:54) >>>> [keycloak-forms-common-freemarker-1.2.0.Final.jar:1.2.0.Final] >>>> at >>>> org.keycloak.freemarker.FreeMarkerUtil.processTemplate(FreeMarkerUtil.java:34) >>>> [keycloak-forms-common-freemarker-1.2.0.Final.jar:1.2.0.Final] >>>> ... 38 more >>>> >>>> >>>> Any thoughts? >>>> >>>> -Matthias >>>> >>>> PS: I think it's unrelated, but I am running on EAP 6.4 >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >>> >> > > -- > Sent from Gmail Mobile > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150527/97c02d6e/attachment-0001.html From mposolda at redhat.com Thu May 28 03:50:56 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 28 May 2015 09:50:56 +0200 Subject: [keycloak-dev] Dynamically compute LIST values in ProviderConfigProperty In-Reply-To: <685616349.6565901.1432732664816.JavaMail.zimbra@redhat.com> References: <5565A573.3000702@redhat.com> <5565A7F3.1070506@redhat.com> <685616349.6565901.1432732664816.JavaMail.zimbra@redhat.com> Message-ID: <5566C8E0.50302@redhat.com> On 27.5.2015 15:17, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Marek Posolda" >> To: keycloak-dev at lists.jboss.org >> Sent: Wednesday, 27 May, 2015 1:18:11 PM >> Subject: Re: [keycloak-dev] Dynamically compute LIST values in ProviderConfigProperty >> >> On 27.5.2015 13:07, Marek Posolda wrote: >>> UserFederationMapper is using ConfiguredProvider like other mappers. >>> In Role LDAP Mapper, I want to display combobox with the list of all >>> the realm clients, so user can choose, which client roles will be >>> mapped to LDAP roles. I need RealmModel instance for this. Currently I >>> can see those possible solutions: >>> >>> 1) Make admin requests to have RealmModel (and possibly ClientModel) >>> available in KeycloakContext (currently is null). As I mentioned in >>> other mail yesterday, we can possibly set RealmModel in >>> RealmsAdminResource.getRealmAdmin . Similarly ClientModel can be set >>> later before ClientResource is instantiated. >>> >>> 2) Add RealmModel as argument on >>> "ConfiguredProvider.getConfigProperties" method >>> >>> 3) Use method "getConfigProperties(RealmModel realm)" just in my >>> provider and ignore the "getConfigProperties()" from ConfiguredProvider. >>> >>> Currently I have it already working with (3), but I don't like it very >>> much... It seems to me that (1) is best. Solution (2) is also not very >>> good IMO (also because protocolMappers are tight to the client and not >>> to the realm) > +1 To option 1 - we should get rid of passing the realm around and instead rely on KeycloakContext Great, thanks. I've added realm and client to admin requests (created https://issues.jboss.org/browse/KEYCLOAK-1355 for it) and removed getConfigProperties(realm) from Federation Mapper and change it to use realm from the context instead. Marek > >>> It looks to me that IdentityProviderMapper may also need realm to >>> retrieve the roles dynamically. The current solution where user >>> manually needs to fill "clientName.roleName" is likely not very good >>> (not user friendly and it won't work for realm role with dot in the >>> name like "my.cool.realm.role" ). > +1000 > >>> Also I wonder if ProviderConfigProperty should support MAP type in >>> addition to the list? Then we can use key/value pairs instead of just >>> flat values. That will allow that users will see client/role names in >>> the combobox in the UI, but chosen value will be client/role ID. >> I meant "chosen key", which will be used as the configuration value in >> the backend will be client/role ID. >> >>> WDYT? >>> Marek >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From mposolda at redhat.com Thu May 28 06:37:25 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 28 May 2015 12:37:25 +0200 Subject: [keycloak-dev] Dynamically compute LIST values in ProviderConfigProperty In-Reply-To: <5565D36A.90706@redhat.com> References: <5565A573.3000702@redhat.com> <5565A7F3.1070506@redhat.com> <685616349.6565901.1432732664816.JavaMail.zimbra@redhat.com> <5565D36A.90706@redhat.com> Message-ID: <5566EFE5.3030403@redhat.com> On 27.5.2015 16:23, Bill Burke wrote: > I was thinking that we'd just add new types beyond STRING, BOOLEAN, LIST > etc. Just add a ROLE_LIST and CLIENT_LIST ProviderConfigProperty type, > the admin console would see that type, and just display an appropriate > UI for selecting that type. Down the line we couldadd types like > CERTIFICATE_LIST, USER_SEARCH, etc... > > I don't think a getConfigProperties(RealmModel) is needed. The admin > console already knows the current realm and it can itself query for the > ROLE/Client list to display to choose from. > > Following me? Yes, looks like even better option. I've added CLIENT_LIST for now as that's needed in Role LDAP mapper. Marek > > Another approach would be to allow the Provider to specify a partial > html page and javascript to import. > > On 5/27/2015 9:17 AM, Stian Thorgersen wrote: >> >> ----- Original Message ----- >>> From: "Marek Posolda" >>> To: keycloak-dev at lists.jboss.org >>> Sent: Wednesday, 27 May, 2015 1:18:11 PM >>> Subject: Re: [keycloak-dev] Dynamically compute LIST values in ProviderConfigProperty >>> >>> On 27.5.2015 13:07, Marek Posolda wrote: >>>> UserFederationMapper is using ConfiguredProvider like other mappers. >>>> In Role LDAP Mapper, I want to display combobox with the list of all >>>> the realm clients, so user can choose, which client roles will be >>>> mapped to LDAP roles. I need RealmModel instance for this. Currently I >>>> can see those possible solutions: >>>> >>>> 1) Make admin requests to have RealmModel (and possibly ClientModel) >>>> available in KeycloakContext (currently is null). As I mentioned in >>>> other mail yesterday, we can possibly set RealmModel in >>>> RealmsAdminResource.getRealmAdmin . Similarly ClientModel can be set >>>> later before ClientResource is instantiated. >>>> >>>> 2) Add RealmModel as argument on >>>> "ConfiguredProvider.getConfigProperties" method >>>> >>>> 3) Use method "getConfigProperties(RealmModel realm)" just in my >>>> provider and ignore the "getConfigProperties()" from ConfiguredProvider. >>>> >>>> Currently I have it already working with (3), but I don't like it very >>>> much... It seems to me that (1) is best. Solution (2) is also not very >>>> good IMO (also because protocolMappers are tight to the client and not >>>> to the realm) >> +1 To option 1 - we should get rid of passing the realm around and instead rely on KeycloakContext >> >>>> It looks to me that IdentityProviderMapper may also need realm to >>>> retrieve the roles dynamically. The current solution where user >>>> manually needs to fill "clientName.roleName" is likely not very good >>>> (not user friendly and it won't work for realm role with dot in the >>>> name like "my.cool.realm.role" ). >> +1000 >> >>>> Also I wonder if ProviderConfigProperty should support MAP type in >>>> addition to the list? Then we can use key/value pairs instead of just >>>> flat values. That will allow that users will see client/role names in >>>> the combobox in the UI, but chosen value will be client/role ID. >>> I meant "chosen key", which will be used as the configuration value in >>> the backend will be client/role ID. >>> >>>> WDYT? >>>> Marek >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From bburke at redhat.com Thu May 28 07:04:01 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 28 May 2015 07:04:01 -0400 Subject: [keycloak-dev] Dynamically compute LIST values in ProviderConfigProperty In-Reply-To: <5566EFE5.3030403@redhat.com> References: <5565A573.3000702@redhat.com> <5565A7F3.1070506@redhat.com> <685616349.6565901.1432732664816.JavaMail.zimbra@redhat.com> <5565D36A.90706@redhat.com> <5566EFE5.3030403@redhat.com> Message-ID: <5566F621.1030009@redhat.com> On 5/28/2015 6:37 AM, Marek Posolda wrote: > On 27.5.2015 16:23, Bill Burke wrote: >> I was thinking that we'd just add new types beyond STRING, BOOLEAN, LIST >> etc. Just add a ROLE_LIST and CLIENT_LIST ProviderConfigProperty type, >> the admin console would see that type, and just display an appropriate >> UI for selecting that type. Down the line we couldadd types like >> CERTIFICATE_LIST, USER_SEARCH, etc... >> >> I don't think a getConfigProperties(RealmModel) is needed. The admin >> console already knows the current realm and it can itself query for the >> ROLE/Client list to display to choose from. >> >> Following me? > Yes, looks like even better option. I've added CLIENT_LIST for now as > that's needed in Role LDAP mapper. > I wonder if these input fragments could be encapsulated in a directive? Right now its just a big ng-show, ng-hide blob of goop. Bill -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From mposolda at redhat.com Thu May 28 10:15:17 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 28 May 2015 16:15:17 +0200 Subject: [keycloak-dev] Dynamically compute LIST values in ProviderConfigProperty In-Reply-To: <5566F621.1030009@redhat.com> References: <5565A573.3000702@redhat.com> <5565A7F3.1070506@redhat.com> <685616349.6565901.1432732664816.JavaMail.zimbra@redhat.com> <5565D36A.90706@redhat.com> <5566EFE5.3030403@redhat.com> <5566F621.1030009@redhat.com> Message-ID: <556722F5.3000809@redhat.com> On 28.5.2015 13:04, Bill Burke wrote: > > On 5/28/2015 6:37 AM, Marek Posolda wrote: >> On 27.5.2015 16:23, Bill Burke wrote: >>> I was thinking that we'd just add new types beyond STRING, BOOLEAN, LIST >>> etc. Just add a ROLE_LIST and CLIENT_LIST ProviderConfigProperty type, >>> the admin console would see that type, and just display an appropriate >>> UI for selecting that type. Down the line we couldadd types like >>> CERTIFICATE_LIST, USER_SEARCH, etc... >>> >>> I don't think a getConfigProperties(RealmModel) is needed. The admin >>> console already knows the current realm and it can itself query for the >>> ROLE/Client list to display to choose from. >>> >>> Following me? >> Yes, looks like even better option. I've added CLIENT_LIST for now as >> that's needed in Role LDAP mapper. >> > I wonder if these input fragments could be encapsulated in a directive? > Right now its just a big ng-show, ng-hide blob of goop. +1 In that case, we may also need some common loader, which will encapsulate all the needed loaded data? For example for "CLIENT_LIST" I've added just "ClientListLoader" to the partial for showing federated-mapper-detail.html because CLIENT_LIST needs to load and show the list of all the clients. Similarly ROLE_LIST may need to load all the roles etc. So instead of declare all the loaders, the partial, which will use the directive can declare this "common" loader, which will load all the data needed by all types (Client list, role list, ...) . So you won't need to declare 10 separate loaders but will declare just this one. Marek > > Bill > From stian at redhat.com Fri May 29 05:12:44 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 29 May 2015 05:12:44 -0400 (EDT) Subject: [keycloak-dev] Google has removed password from login screen In-Reply-To: <438643161.8432176.1432890685927.JavaMail.zimbra@redhat.com> Message-ID: <1654840310.8432581.1432890764070.JavaMail.zimbra@redhat.com> Google has recently removed the password from the first login screen. It now only displays the username. This is quite nice for users that log in with other mechanism than passwords (different local auth mechanisms or external idps). It would be nice if our new authentication SPI can support this use-case. From bburke at redhat.com Fri May 29 08:23:14 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 29 May 2015 08:23:14 -0400 Subject: [keycloak-dev] Google has removed password from login screen In-Reply-To: <1654840310.8432581.1432890764070.JavaMail.zimbra@redhat.com> References: <1654840310.8432581.1432890764070.JavaMail.zimbra@redhat.com> Message-ID: <55685A32.5020602@redhat.com> Yes, this will work with new auth SPI. I should probably go over it very soon. I'm a bit worried about the complexity as now its more a workflow definition than just enabling disabling credential types. On 5/29/2015 5:12 AM, Stian Thorgersen wrote: > Google has recently removed the password from the first login screen. It now only displays the username. This is quite nice for users that log in with other mechanism than passwords (different local auth mechanisms or external idps). > > It would be nice if our new authentication SPI can support this use-case. > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Fri May 29 20:40:57 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 29 May 2015 20:40:57 -0400 Subject: [keycloak-dev] confused on event builder on auth Message-ID: <55690719.7030700@redhat.com> What events are we supposed to be logging with the EventBuilder when authenticating and doing required actions? 1. All errors 2. all required action successes 3. all login success 2. Successful authentication prior to required actions? 3. Success after required actions? -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com