From ssilvert at redhat.com Wed Jul 1 07:58:20 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Wed, 01 Jul 2015 07:58:20 -0400 Subject: [keycloak-dev] Idle timeout notificaion In-Reply-To: <559318B0.1090007@redhat.com> References: <5591AC0F.70102@redhat.com> <5591B7F9.6020700@redhat.com> <5591BB0C.5030209@redhat.com> <5591E431.8050802@redhat.com> <55928A5F.2070001@redhat.com> <5592981F.4040309@redhat.com> <5592AF24.4040403@redhat.com> <5592D511.9050901@redhat.com> <5592DB78.7050806@redhat.com> <5592DF2B.6020801@redhat.com> <5592E0DD.7060105@redhat.com> <559317AC.5000101@redhat.com> <559318B0.1090007@redhat.com> Message-ID: <5593D5DC.2070000@redhat.com> On 6/30/2015 6:31 PM, Bill Burke wrote: > > On 6/30/2015 6:26 PM, Bill Burke wrote: >> Again, you expect this to work? If the "user" is a browser, there is no >> way to notify them other than the iframe + javascript trick that is >> provided by OpenID Connect and provided support for keycloak.js > Sorry, I mistyped: > > Again, *how* do you expect this to work? If the "user" is a browser, > there is no way to notify them other than the iframe + javascript trick > that is provided by OpenID Connect and provided support for keycloak.js > At this point, I don't care that much about implementation details. I only care about what we will tell the customer about whether or not we will implement this feature. Of course, part of the answer might depend on how cleanly it can be implemented. But the larger question is just about whether it is something Keycloak should provide. Is this the kind of feature we ought to implement? I can tell them "yes", "no", or "maybe". But no matter which one we pick, I also need a rationale for the decision. From bburke at redhat.com Wed Jul 1 08:51:47 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 01 Jul 2015 08:51:47 -0400 Subject: [keycloak-dev] Idle timeout notificaion In-Reply-To: <5593D5DC.2070000@redhat.com> References: <5591AC0F.70102@redhat.com> <5591B7F9.6020700@redhat.com> <5591BB0C.5030209@redhat.com> <5591E431.8050802@redhat.com> <55928A5F.2070001@redhat.com> <5592981F.4040309@redhat.com> <5592AF24.4040403@redhat.com> <5592D511.9050901@redhat.com> <5592DB78.7050806@redhat.com> <5592DF2B.6020801@redhat.com> <5592E0DD.7060105@redhat.com> <559317AC.5000101@redhat.com> <559318B0.1090007@redhat.com> <5593D5DC.2070000@redhat.com> Message-ID: <5593E263.8010908@redhat.com> On 7/1/2015 7:58 AM, Stan Silvert wrote: > On 6/30/2015 6:31 PM, Bill Burke wrote: >> >> On 6/30/2015 6:26 PM, Bill Burke wrote: >>> Again, you expect this to work? If the "user" is a browser, there is no >>> way to notify them other than the iframe + javascript trick that is >>> provided by OpenID Connect and provided support for keycloak.js >> Sorry, I mistyped: >> >> Again, *how* do you expect this to work? If the "user" is a browser, >> there is no way to notify them other than the iframe + javascript trick >> that is provided by OpenID Connect and provided support for keycloak.js >> > At this point, I don't care that much about implementation details. I > only care about what we will tell the customer about whether or not we > will implement this feature. Of course, part of the answer might depend > on how cleanly it can be implemented. But the larger question is just > about whether it is something Keycloak should provide. > > Is this the kind of feature we ought to implement? I can tell them > "yes", "no", or "maybe". But no matter which one we pick, I also need a > rationale for the decision. We need to have backchannel logout happen when the session expiration thread finds old sessions. Also might be useful to break out the iframe OpenID trick into a smaller javascript library so that servlet apps can do it. http://openid.net/specs/openid-connect-session-1_0.html#ChangeNotification -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Thu Jul 2 03:05:58 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 2 Jul 2015 03:05:58 -0400 (EDT) Subject: [keycloak-dev] Locale propagation from secured application In-Reply-To: References: Message-ID: <454199664.30734671.1435820758950.JavaMail.zimbra@redhat.com> You can use the "ui_locales" query param. It's a space separated list of BCP47 [RFC5646] language tag values. ----- Original Message ----- > From: "David ?lvarez" > To: keycloak-dev at lists.jboss.org > Sent: Monday, 29 June, 2015 12:56:14 PM > Subject: [keycloak-dev] Locale propagation from secured application > > Hi! > > We have a Keycloak secured application. This application is a multilingual > application. > > In the application a free access zone is defined and a link to "login" is > available to users can access to a private area. > > In that scenario we need that the user selected language in application will > be applied in Keycloak login page. When a user require a login action this > code is executed: > > [...] > response.encodeRedirectURL("/index.xhtml"); > req.authenticate(response); > [...] > > Can we force an locale use in authenticate? Default locale value from > Keycloak configuration is allways applied. > > Thanks a lot! > > > -- > > David Alvarez Cabal > dalvarez at inventiaplus.com > > www.inventiaplus.com > 928 702 054 > > > > ADVERTENCIA > La informaci?n contenida en este correo electr?nico, y en su caso, cualquier > fichero anexo al mismo, son de car?cter privado y confidencial siendo para > uso exclusivo de su destinatario. Si usted no es el destinatario correcto, > el empleado o agente responsable de entregar el mensaje al destinatario, o > ha recibido esta comunicaci?n por error, le informamos que est? totalmente > prohibida cualquier divulgaci?n, distribuci?n o reproducci?n de esta > comunicaci?n seg?n la legislaci?n vigente y le rogamos que nos lo notifique > inmediatamente, procediendo a su destrucci?n sin continuar su lectura. > Le informamos que su direcci?n de correo electr?nico, as? como el resto de > los datos de car?cter personal de la tarjeta de visita que nos facilite, > podr?an ser objeto de tratamiento automatizado en nuestros ficheros, con la > finalidad de gestionar la agenda de contactos de INVENTIA PLUS, S.L.. Vd. > podr? en cualquier momento ejercer sus derechos de acceso, rectificaci?n, > cancelaci?n y oposici?n en los t?rminos establecidos en la Ley Org?nica > 15/1999 mediante notificaci?n escrita a la siguiente direcci?n: c/ Pintor, > n? 8, Pol. Ind. Salinetas, 35219, Telde, Las Palmas. > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Thu Jul 2 03:13:16 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 2 Jul 2015 03:13:16 -0400 (EDT) Subject: [keycloak-dev] Packaging of ApacheDS for examples? In-Reply-To: <559295C9.3040409@redhat.com> References: <559295C9.3040409@redhat.com> Message-ID: <59203649.30748852.1435821196209.JavaMail.zimbra@redhat.com> I don't like option a. Why is option c much more work? Doesn't seem like it should be that hard. ----- Original Message ----- > From: "Marek Posolda" > To: keycloak-dev at lists.jboss.org > Sent: Tuesday, 30 June, 2015 3:12:41 PM > Subject: [keycloak-dev] Packaging of ApacheDS for examples? > > I am thinking about adding LDAP example, which can be used as a base for LDAP > mappers based blog and screencast. > > It will contain the application to show some claims (also both singlevalued > and multivalued attributes). It will also contain JSON realm with > UserFederation configuration pointing to our ApacheDS and LDIF with some > simple users for testing. I already added end-to-end test to the testsuite > (LDAPMultipleAttributesTest.ldapPortalEndToEndTest ) > > > The only possible problem is how to easily bootstrap ApacheDS based LDAP > servers in user's environment. I am thinking about 3 approaches: > > a) Point to the embedded ApacheDS server from our testsuite. This will be > easy to do and it's what Kerberos example is already doing . Problem is that > it requires people to checkout the keycloak sources through github and build > them through maven, so not very user friendly > > b) Create docker image for ApacheDS servers (one for ldap example and another > for kerberos). Not sure if it's fine to require users to install docker > (even more pain might be on windows, when they need boot2docker or > something...) > > c) Packaging with ApacheDS based servers directly into our example package, > so people can just run something like: > > java -jar keycloak-examples/ldap/apacheds-embedded.jar > -Dldif.location=keycloak-examples/ldap/example.ldif > > and similarly for kerberos. > > For me it's easiest to go with (a) but not sure about usability... Regarding > usability (c) looks best but it's much more work. > > WDYT? > Marek > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Thu Jul 2 03:23:52 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 2 Jul 2015 03:23:52 -0400 (EDT) Subject: [keycloak-dev] Idle timeout notificaion In-Reply-To: <5593E263.8010908@redhat.com> References: <5591AC0F.70102@redhat.com> <5592DB78.7050806@redhat.com> <5592DF2B.6020801@redhat.com> <5592E0DD.7060105@redhat.com> <559317AC.5000101@redhat.com> <559318B0.1090007@redhat.com> <5593D5DC.2070000@redhat.com> <5593E263.8010908@redhat.com> Message-ID: <671948618.30753855.1435821832494.JavaMail.zimbra@redhat.com> Having this baked in is a nice to have, but hard to implemented and we have higher priorities. Create a JIRA for it. In the mean time depending on the load the customer has they can also implement this functionality on their end by using short access token lifespans and making the js adapter refresh the token with a background timer. If the js adapter fails to refresh the token it should tell the user it has been logged-out. Something like: window.setInterval(function() { keycloak.updateToken(10).error(function() { alert('user logged-out'); }); }, 30000); ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Wednesday, 1 July, 2015 2:51:47 PM > Subject: Re: [keycloak-dev] Idle timeout notificaion > > > > On 7/1/2015 7:58 AM, Stan Silvert wrote: > > On 6/30/2015 6:31 PM, Bill Burke wrote: > >> > >> On 6/30/2015 6:26 PM, Bill Burke wrote: > >>> Again, you expect this to work? If the "user" is a browser, there is no > >>> way to notify them other than the iframe + javascript trick that is > >>> provided by OpenID Connect and provided support for keycloak.js > >> Sorry, I mistyped: > >> > >> Again, *how* do you expect this to work? If the "user" is a browser, > >> there is no way to notify them other than the iframe + javascript trick > >> that is provided by OpenID Connect and provided support for keycloak.js > >> > > At this point, I don't care that much about implementation details. I > > only care about what we will tell the customer about whether or not we > > will implement this feature. Of course, part of the answer might depend > > on how cleanly it can be implemented. But the larger question is just > > about whether it is something Keycloak should provide. > > > > Is this the kind of feature we ought to implement? I can tell them > > "yes", "no", or "maybe". But no matter which one we pick, I also need a > > rationale for the decision. > > We need to have backchannel logout happen when the session expiration > thread finds old sessions. Also might be useful to break out the iframe > OpenID trick into a smaller javascript library so that servlet apps can > do it. > > http://openid.net/specs/openid-connect-session-1_0.html#ChangeNotification > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From mposolda at redhat.com Thu Jul 2 03:48:52 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 02 Jul 2015 09:48:52 +0200 Subject: [keycloak-dev] Packaging of ApacheDS for examples? In-Reply-To: <59203649.30748852.1435821196209.JavaMail.zimbra@redhat.com> References: <559295C9.3040409@redhat.com> <59203649.30748852.1435821196209.JavaMail.zimbra@redhat.com> Message-ID: <5594ECE4.4080103@redhat.com> Thanks, I will investigate (c) then . It's more work than (a), which is no work Well, it won't be that hard to do, just afraid of all the dependencies required for ApacheDS . Which might cause that size of keycloak-examples will grow to be very big (in that case we may need separate example package with embedded ApacheDS LDAP/Kerberos to download). I will investigate sizes etc and will send update. Marek On 2.7.2015 09:13, Stian Thorgersen wrote: > I don't like option a. Why is option c much more work? Doesn't seem like it should be that hard. > > ----- Original Message ----- >> From: "Marek Posolda" >> To: keycloak-dev at lists.jboss.org >> Sent: Tuesday, 30 June, 2015 3:12:41 PM >> Subject: [keycloak-dev] Packaging of ApacheDS for examples? >> >> I am thinking about adding LDAP example, which can be used as a base for LDAP >> mappers based blog and screencast. >> >> It will contain the application to show some claims (also both singlevalued >> and multivalued attributes). It will also contain JSON realm with >> UserFederation configuration pointing to our ApacheDS and LDIF with some >> simple users for testing. I already added end-to-end test to the testsuite >> (LDAPMultipleAttributesTest.ldapPortalEndToEndTest ) >> >> >> The only possible problem is how to easily bootstrap ApacheDS based LDAP >> servers in user's environment. I am thinking about 3 approaches: >> >> a) Point to the embedded ApacheDS server from our testsuite. This will be >> easy to do and it's what Kerberos example is already doing . Problem is that >> it requires people to checkout the keycloak sources through github and build >> them through maven, so not very user friendly >> >> b) Create docker image for ApacheDS servers (one for ldap example and another >> for kerberos). Not sure if it's fine to require users to install docker >> (even more pain might be on windows, when they need boot2docker or >> something...) >> >> c) Packaging with ApacheDS based servers directly into our example package, >> so people can just run something like: >> >> java -jar keycloak-examples/ldap/apacheds-embedded.jar >> -Dldif.location=keycloak-examples/ldap/example.ldif >> >> and similarly for kerberos. >> >> For me it's easiest to go with (a) but not sure about usability... Regarding >> usability (c) looks best but it's much more work. >> >> WDYT? >> Marek >> >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Thu Jul 2 03:56:48 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 2 Jul 2015 03:56:48 -0400 (EDT) Subject: [keycloak-dev] Packaging of ApacheDS for examples? In-Reply-To: <5594ECE4.4080103@redhat.com> References: <559295C9.3040409@redhat.com> <59203649.30748852.1435821196209.JavaMail.zimbra@redhat.com> <5594ECE4.4080103@redhat.com> Message-ID: <1096643411.30773117.1435823808275.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Marek Posolda" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Thursday, 2 July, 2015 9:48:52 AM > Subject: Re: [keycloak-dev] Packaging of ApacheDS for examples? > > Thanks, I will investigate (c) then . > > It's more work than (a), which is no work > > Well, it won't be that hard to do, just afraid of all the dependencies > required for ApacheDS . Which might cause that size of keycloak-examples > will grow to be very big (in that case we may need separate example > package with embedded ApacheDS LDAP/Kerberos to download). I will > investigate sizes etc and will send update. We don't package dependencies with the examples, only the source. So that shouldn't be a problem? > > Marek > > On 2.7.2015 09:13, Stian Thorgersen wrote: > > I don't like option a. Why is option c much more work? Doesn't seem like it > > should be that hard. > > > > ----- Original Message ----- > >> From: "Marek Posolda" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Tuesday, 30 June, 2015 3:12:41 PM > >> Subject: [keycloak-dev] Packaging of ApacheDS for examples? > >> > >> I am thinking about adding LDAP example, which can be used as a base for > >> LDAP > >> mappers based blog and screencast. > >> > >> It will contain the application to show some claims (also both > >> singlevalued > >> and multivalued attributes). It will also contain JSON realm with > >> UserFederation configuration pointing to our ApacheDS and LDIF with some > >> simple users for testing. I already added end-to-end test to the testsuite > >> (LDAPMultipleAttributesTest.ldapPortalEndToEndTest ) > >> > >> > >> The only possible problem is how to easily bootstrap ApacheDS based LDAP > >> servers in user's environment. I am thinking about 3 approaches: > >> > >> a) Point to the embedded ApacheDS server from our testsuite. This will be > >> easy to do and it's what Kerberos example is already doing . Problem is > >> that > >> it requires people to checkout the keycloak sources through github and > >> build > >> them through maven, so not very user friendly > >> > >> b) Create docker image for ApacheDS servers (one for ldap example and > >> another > >> for kerberos). Not sure if it's fine to require users to install docker > >> (even more pain might be on windows, when they need boot2docker or > >> something...) > >> > >> c) Packaging with ApacheDS based servers directly into our example > >> package, > >> so people can just run something like: > >> > >> java -jar keycloak-examples/ldap/apacheds-embedded.jar > >> -Dldif.location=keycloak-examples/ldap/example.ldif > >> > >> and similarly for kerberos. > >> > >> For me it's easiest to go with (a) but not sure about usability... > >> Regarding > >> usability (c) looks best but it's much more work. > >> > >> WDYT? > >> Marek > >> > >> > >> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > From bburke at redhat.com Thu Jul 2 06:54:04 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 02 Jul 2015 06:54:04 -0400 Subject: [keycloak-dev] Idle timeout notificaion In-Reply-To: <671948618.30753855.1435821832494.JavaMail.zimbra@redhat.com> References: <5591AC0F.70102@redhat.com> <5592DB78.7050806@redhat.com> <5592DF2B.6020801@redhat.com> <5592E0DD.7060105@redhat.com> <559317AC.5000101@redhat.com> <559318B0.1090007@redhat.com> <5593D5DC.2070000@redhat.com> <5593E263.8010908@redhat.com> <671948618.30753855.1435821832494.JavaMail.zimbra@redhat.com> Message-ID: <5595184C.9030403@redhat.com> I thought we already had the ability in the javascript adapter to check for logout via the iframe trick? Your demo at Devnation showed this. On 7/2/2015 3:23 AM, Stian Thorgersen wrote: > Having this baked in is a nice to have, but hard to implemented and we have higher priorities. > > Create a JIRA for it. > > In the mean time depending on the load the customer has they can also implement this functionality on their end by using short access token lifespans and making the js adapter refresh the token with a background timer. If the js adapter fails to refresh the token it should tell the user it has been logged-out. Something like: > > window.setInterval(function() { > keycloak.updateToken(10).error(function() { alert('user logged-out'); }); > }, 30000); > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Wednesday, 1 July, 2015 2:51:47 PM >> Subject: Re: [keycloak-dev] Idle timeout notificaion >> >> >> >> On 7/1/2015 7:58 AM, Stan Silvert wrote: >>> On 6/30/2015 6:31 PM, Bill Burke wrote: >>>> >>>> On 6/30/2015 6:26 PM, Bill Burke wrote: >>>>> Again, you expect this to work? If the "user" is a browser, there is no >>>>> way to notify them other than the iframe + javascript trick that is >>>>> provided by OpenID Connect and provided support for keycloak.js >>>> Sorry, I mistyped: >>>> >>>> Again, *how* do you expect this to work? If the "user" is a browser, >>>> there is no way to notify them other than the iframe + javascript trick >>>> that is provided by OpenID Connect and provided support for keycloak.js >>>> >>> At this point, I don't care that much about implementation details. I >>> only care about what we will tell the customer about whether or not we >>> will implement this feature. Of course, part of the answer might depend >>> on how cleanly it can be implemented. But the larger question is just >>> about whether it is something Keycloak should provide. >>> >>> Is this the kind of feature we ought to implement? I can tell them >>> "yes", "no", or "maybe". But no matter which one we pick, I also need a >>> rationale for the decision. >> >> We need to have backchannel logout happen when the session expiration >> thread finds old sessions. Also might be useful to break out the iframe >> OpenID trick into a smaller javascript library so that servlet apps can >> do it. >> >> http://openid.net/specs/openid-connect-session-1_0.html#ChangeNotification >> >> >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Thu Jul 2 06:56:25 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 2 Jul 2015 06:56:25 -0400 (EDT) Subject: [keycloak-dev] Idle timeout notificaion In-Reply-To: <5595184C.9030403@redhat.com> References: <5591AC0F.70102@redhat.com> <5592E0DD.7060105@redhat.com> <559317AC.5000101@redhat.com> <559318B0.1090007@redhat.com> <5593D5DC.2070000@redhat.com> <5593E263.8010908@redhat.com> <671948618.30753855.1435821832494.JavaMail.zimbra@redhat.com> <5595184C.9030403@redhat.com> Message-ID: <1272384471.30863578.1435834585612.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Thursday, 2 July, 2015 12:54:04 PM > Subject: Re: [keycloak-dev] Idle timeout notificaion > > I thought we already had the ability in the javascript adapter to check > for logout via the iframe trick? Your demo at Devnation showed this. Yes, but it only works for a manual logout where the session cookie is invalidated. If user is remotely logged-out or the session times out there's no update. > > On 7/2/2015 3:23 AM, Stian Thorgersen wrote: > > Having this baked in is a nice to have, but hard to implemented and we have > > higher priorities. > > > > Create a JIRA for it. > > > > In the mean time depending on the load the customer has they can also > > implement this functionality on their end by using short access token > > lifespans and making the js adapter refresh the token with a background > > timer. If the js adapter fails to refresh the token it should tell the > > user it has been logged-out. Something like: > > > > window.setInterval(function() { > > keycloak.updateToken(10).error(function() { alert('user > > logged-out'); }); > > }, 30000); > > > > ----- Original Message ----- > >> From: "Bill Burke" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Wednesday, 1 July, 2015 2:51:47 PM > >> Subject: Re: [keycloak-dev] Idle timeout notificaion > >> > >> > >> > >> On 7/1/2015 7:58 AM, Stan Silvert wrote: > >>> On 6/30/2015 6:31 PM, Bill Burke wrote: > >>>> > >>>> On 6/30/2015 6:26 PM, Bill Burke wrote: > >>>>> Again, you expect this to work? If the "user" is a browser, there is > >>>>> no > >>>>> way to notify them other than the iframe + javascript trick that is > >>>>> provided by OpenID Connect and provided support for keycloak.js > >>>> Sorry, I mistyped: > >>>> > >>>> Again, *how* do you expect this to work? If the "user" is a browser, > >>>> there is no way to notify them other than the iframe + javascript trick > >>>> that is provided by OpenID Connect and provided support for keycloak.js > >>>> > >>> At this point, I don't care that much about implementation details. I > >>> only care about what we will tell the customer about whether or not we > >>> will implement this feature. Of course, part of the answer might depend > >>> on how cleanly it can be implemented. But the larger question is just > >>> about whether it is something Keycloak should provide. > >>> > >>> Is this the kind of feature we ought to implement? I can tell them > >>> "yes", "no", or "maybe". But no matter which one we pick, I also need a > >>> rationale for the decision. > >> > >> We need to have backchannel logout happen when the session expiration > >> thread finds old sessions. Also might be useful to break out the iframe > >> OpenID trick into a smaller javascript library so that servlet apps can > >> do it. > >> > >> http://openid.net/specs/openid-connect-session-1_0.html#ChangeNotification > >> > >> > >> > >> -- > >> Bill Burke > >> JBoss, a division of Red Hat > >> http://bill.burkecentral.com > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > From bburke at redhat.com Thu Jul 2 07:02:54 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 02 Jul 2015 07:02:54 -0400 Subject: [keycloak-dev] Idle timeout notificaion In-Reply-To: <1272384471.30863578.1435834585612.JavaMail.zimbra@redhat.com> References: <5591AC0F.70102@redhat.com> <5592E0DD.7060105@redhat.com> <559317AC.5000101@redhat.com> <559318B0.1090007@redhat.com> <5593D5DC.2070000@redhat.com> <5593E263.8010908@redhat.com> <671948618.30753855.1435821832494.JavaMail.zimbra@redhat.com> <5595184C.9030403@redhat.com> <1272384471.30863578.1435834585612.JavaMail.zimbra@redhat.com> Message-ID: <55951A5E.6090008@redhat.com> Ya, then its just a periodic javascript call to the validate token endpoint. On 7/2/2015 6:56 AM, Stian Thorgersen wrote: > > > ----- Original Message ----- >> From: "Bill Burke" >> To: "Stian Thorgersen" >> Cc: keycloak-dev at lists.jboss.org >> Sent: Thursday, 2 July, 2015 12:54:04 PM >> Subject: Re: [keycloak-dev] Idle timeout notificaion >> >> I thought we already had the ability in the javascript adapter to check >> for logout via the iframe trick? Your demo at Devnation showed this. > > Yes, but it only works for a manual logout where the session cookie is invalidated. If user is remotely logged-out or the session times out there's no update. > >> >> On 7/2/2015 3:23 AM, Stian Thorgersen wrote: >>> Having this baked in is a nice to have, but hard to implemented and we have >>> higher priorities. >>> >>> Create a JIRA for it. >>> >>> In the mean time depending on the load the customer has they can also >>> implement this functionality on their end by using short access token >>> lifespans and making the js adapter refresh the token with a background >>> timer. If the js adapter fails to refresh the token it should tell the >>> user it has been logged-out. Something like: >>> >>> window.setInterval(function() { >>> keycloak.updateToken(10).error(function() { alert('user >>> logged-out'); }); >>> }, 30000); >>> >>> ----- Original Message ----- >>>> From: "Bill Burke" >>>> To: keycloak-dev at lists.jboss.org >>>> Sent: Wednesday, 1 July, 2015 2:51:47 PM >>>> Subject: Re: [keycloak-dev] Idle timeout notificaion >>>> >>>> >>>> >>>> On 7/1/2015 7:58 AM, Stan Silvert wrote: >>>>> On 6/30/2015 6:31 PM, Bill Burke wrote: >>>>>> >>>>>> On 6/30/2015 6:26 PM, Bill Burke wrote: >>>>>>> Again, you expect this to work? If the "user" is a browser, there is >>>>>>> no >>>>>>> way to notify them other than the iframe + javascript trick that is >>>>>>> provided by OpenID Connect and provided support for keycloak.js >>>>>> Sorry, I mistyped: >>>>>> >>>>>> Again, *how* do you expect this to work? If the "user" is a browser, >>>>>> there is no way to notify them other than the iframe + javascript trick >>>>>> that is provided by OpenID Connect and provided support for keycloak.js >>>>>> >>>>> At this point, I don't care that much about implementation details. I >>>>> only care about what we will tell the customer about whether or not we >>>>> will implement this feature. Of course, part of the answer might depend >>>>> on how cleanly it can be implemented. But the larger question is just >>>>> about whether it is something Keycloak should provide. >>>>> >>>>> Is this the kind of feature we ought to implement? I can tell them >>>>> "yes", "no", or "maybe". But no matter which one we pick, I also need a >>>>> rationale for the decision. >>>> >>>> We need to have backchannel logout happen when the session expiration >>>> thread finds old sessions. Also might be useful to break out the iframe >>>> OpenID trick into a smaller javascript library so that servlet apps can >>>> do it. >>>> >>>> http://openid.net/specs/openid-connect-session-1_0.html#ChangeNotification >>>> >>>> >>>> >>>> -- >>>> Bill Burke >>>> JBoss, a division of Red Hat >>>> http://bill.burkecentral.com >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Thu Jul 2 07:13:18 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 2 Jul 2015 07:13:18 -0400 (EDT) Subject: [keycloak-dev] Idle timeout notificaion In-Reply-To: <55951A5E.6090008@redhat.com> References: <5591AC0F.70102@redhat.com> <559318B0.1090007@redhat.com> <5593D5DC.2070000@redhat.com> <5593E263.8010908@redhat.com> <671948618.30753855.1435821832494.JavaMail.zimbra@redhat.com> <5595184C.9030403@redhat.com> <1272384471.30863578.1435834585612.JavaMail.zimbra@redhat.com> <55951A5E.6090008@redhat.com> Message-ID: <1744343047.30875204.1435835598510.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Thursday, 2 July, 2015 1:02:54 PM > Subject: Re: [keycloak-dev] Idle timeout notificaion > > Ya, then its just a periodic javascript call to the validate token endpoint. Or just refresh token regularly as I suggested ;) > > On 7/2/2015 6:56 AM, Stian Thorgersen wrote: > > > > > > ----- Original Message ----- > >> From: "Bill Burke" > >> To: "Stian Thorgersen" > >> Cc: keycloak-dev at lists.jboss.org > >> Sent: Thursday, 2 July, 2015 12:54:04 PM > >> Subject: Re: [keycloak-dev] Idle timeout notificaion > >> > >> I thought we already had the ability in the javascript adapter to check > >> for logout via the iframe trick? Your demo at Devnation showed this. > > > > Yes, but it only works for a manual logout where the session cookie is > > invalidated. If user is remotely logged-out or the session times out > > there's no update. > > > >> > >> On 7/2/2015 3:23 AM, Stian Thorgersen wrote: > >>> Having this baked in is a nice to have, but hard to implemented and we > >>> have > >>> higher priorities. > >>> > >>> Create a JIRA for it. > >>> > >>> In the mean time depending on the load the customer has they can also > >>> implement this functionality on their end by using short access token > >>> lifespans and making the js adapter refresh the token with a background > >>> timer. If the js adapter fails to refresh the token it should tell the > >>> user it has been logged-out. Something like: > >>> > >>> window.setInterval(function() { > >>> keycloak.updateToken(10).error(function() { alert('user > >>> logged-out'); }); > >>> }, 30000); > >>> > >>> ----- Original Message ----- > >>>> From: "Bill Burke" > >>>> To: keycloak-dev at lists.jboss.org > >>>> Sent: Wednesday, 1 July, 2015 2:51:47 PM > >>>> Subject: Re: [keycloak-dev] Idle timeout notificaion > >>>> > >>>> > >>>> > >>>> On 7/1/2015 7:58 AM, Stan Silvert wrote: > >>>>> On 6/30/2015 6:31 PM, Bill Burke wrote: > >>>>>> > >>>>>> On 6/30/2015 6:26 PM, Bill Burke wrote: > >>>>>>> Again, you expect this to work? If the "user" is a browser, there is > >>>>>>> no > >>>>>>> way to notify them other than the iframe + javascript trick that is > >>>>>>> provided by OpenID Connect and provided support for keycloak.js > >>>>>> Sorry, I mistyped: > >>>>>> > >>>>>> Again, *how* do you expect this to work? If the "user" is a browser, > >>>>>> there is no way to notify them other than the iframe + javascript > >>>>>> trick > >>>>>> that is provided by OpenID Connect and provided support for > >>>>>> keycloak.js > >>>>>> > >>>>> At this point, I don't care that much about implementation details. I > >>>>> only care about what we will tell the customer about whether or not we > >>>>> will implement this feature. Of course, part of the answer might > >>>>> depend > >>>>> on how cleanly it can be implemented. But the larger question is just > >>>>> about whether it is something Keycloak should provide. > >>>>> > >>>>> Is this the kind of feature we ought to implement? I can tell them > >>>>> "yes", "no", or "maybe". But no matter which one we pick, I also need > >>>>> a > >>>>> rationale for the decision. > >>>> > >>>> We need to have backchannel logout happen when the session expiration > >>>> thread finds old sessions. Also might be useful to break out the iframe > >>>> OpenID trick into a smaller javascript library so that servlet apps can > >>>> do it. > >>>> > >>>> http://openid.net/specs/openid-connect-session-1_0.html#ChangeNotification > >>>> > >>>> > >>>> > >>>> -- > >>>> Bill Burke > >>>> JBoss, a division of Red Hat > >>>> http://bill.burkecentral.com > >>>> _______________________________________________ > >>>> keycloak-dev mailing list > >>>> keycloak-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>> > >> > >> -- > >> Bill Burke > >> JBoss, a division of Red Hat > >> http://bill.burkecentral.com > >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > From bburke at redhat.com Thu Jul 2 10:37:21 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 02 Jul 2015 10:37:21 -0400 Subject: [keycloak-dev] Idle timeout notificaion In-Reply-To: <1744343047.30875204.1435835598510.JavaMail.zimbra@redhat.com> References: <5591AC0F.70102@redhat.com> <559318B0.1090007@redhat.com> <5593D5DC.2070000@redhat.com> <5593E263.8010908@redhat.com> <671948618.30753855.1435821832494.JavaMail.zimbra@redhat.com> <5595184C.9030403@redhat.com> <1272384471.30863578.1435834585612.JavaMail.zimbra@redhat.com> <55951A5E.6090008@redhat.com> <1744343047.30875204.1435835598510.JavaMail.zimbra@redhat.com> Message-ID: <55954CA1.70703@redhat.com> On 7/2/2015 7:13 AM, Stian Thorgersen wrote: > > > ----- Original Message ----- >> From: "Bill Burke" >> To: "Stian Thorgersen" >> Cc: keycloak-dev at lists.jboss.org >> Sent: Thursday, 2 July, 2015 1:02:54 PM >> Subject: Re: [keycloak-dev] Idle timeout notificaion >> >> Ya, then its just a periodic javascript call to the validate token endpoint. > > Or just refresh token regularly as I suggested ;) > Not really the same thing. Then the app would have to manage idle timeouts too instead of letting keycloak handle it. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Thu Jul 2 11:05:38 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 2 Jul 2015 11:05:38 -0400 (EDT) Subject: [keycloak-dev] Idle timeout notificaion In-Reply-To: <55954CA1.70703@redhat.com> References: <5591AC0F.70102@redhat.com> <5593E263.8010908@redhat.com> <671948618.30753855.1435821832494.JavaMail.zimbra@redhat.com> <5595184C.9030403@redhat.com> <1272384471.30863578.1435834585612.JavaMail.zimbra@redhat.com> <55951A5E.6090008@redhat.com> <1744343047.30875204.1435835598510.JavaMail.zimbra@redhat.com> <55954CA1.70703@redhat.com> Message-ID: <316099785.31102247.1435849538112.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Thursday, 2 July, 2015 4:37:21 PM > Subject: Re: [keycloak-dev] Idle timeout notificaion > > > > On 7/2/2015 7:13 AM, Stian Thorgersen wrote: > > > > > > ----- Original Message ----- > >> From: "Bill Burke" > >> To: "Stian Thorgersen" > >> Cc: keycloak-dev at lists.jboss.org > >> Sent: Thursday, 2 July, 2015 1:02:54 PM > >> Subject: Re: [keycloak-dev] Idle timeout notificaion > >> > >> Ya, then its just a periodic javascript call to the validate token > >> endpoint. > > > > Or just refresh token regularly as I suggested ;) > > > > Not really the same thing. Then the app would have to manage idle > timeouts too instead of letting keycloak handle it. Yep, you're right - it would act as a keep alive > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > From ssilvert at redhat.com Thu Jul 2 12:09:15 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Thu, 02 Jul 2015 12:09:15 -0400 Subject: [keycloak-dev] Idle timeout notificaion In-Reply-To: <671948618.30753855.1435821832494.JavaMail.zimbra@redhat.com> References: <5591AC0F.70102@redhat.com> <5592DB78.7050806@redhat.com> <5592DF2B.6020801@redhat.com> <5592E0DD.7060105@redhat.com> <559317AC.5000101@redhat.com> <559318B0.1090007@redhat.com> <5593D5DC.2070000@redhat.com> <5593E263.8010908@redhat.com> <671948618.30753855.1435821832494.JavaMail.zimbra@redhat.com> Message-ID: <5595622B.7090802@redhat.com> On 7/2/2015 3:23 AM, Stian Thorgersen wrote: > Having this baked in is a nice to have, but hard to implemented and we have higher priorities. > > Create a JIRA for it. https://issues.jboss.org/browse/KEYCLOAK-1511 > > In the mean time depending on the load the customer has they can also implement this functionality on their end by using short access token lifespans and making the js adapter refresh the token with a background timer. If the js adapter fails to refresh the token it should tell the user it has been logged-out. Something like: > > window.setInterval(function() { > keycloak.updateToken(10).error(function() { alert('user logged-out'); }); > }, 30000); > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Wednesday, 1 July, 2015 2:51:47 PM >> Subject: Re: [keycloak-dev] Idle timeout notificaion >> >> >> >> On 7/1/2015 7:58 AM, Stan Silvert wrote: >>> On 6/30/2015 6:31 PM, Bill Burke wrote: >>>> On 6/30/2015 6:26 PM, Bill Burke wrote: >>>>> Again, you expect this to work? If the "user" is a browser, there is no >>>>> way to notify them other than the iframe + javascript trick that is >>>>> provided by OpenID Connect and provided support for keycloak.js >>>> Sorry, I mistyped: >>>> >>>> Again, *how* do you expect this to work? If the "user" is a browser, >>>> there is no way to notify them other than the iframe + javascript trick >>>> that is provided by OpenID Connect and provided support for keycloak.js >>>> >>> At this point, I don't care that much about implementation details. I >>> only care about what we will tell the customer about whether or not we >>> will implement this feature. Of course, part of the answer might depend >>> on how cleanly it can be implemented. But the larger question is just >>> about whether it is something Keycloak should provide. >>> >>> Is this the kind of feature we ought to implement? I can tell them >>> "yes", "no", or "maybe". But no matter which one we pick, I also need a >>> rationale for the decision. >> We need to have backchannel logout happen when the session expiration >> thread finds old sessions. Also might be useful to break out the iframe >> OpenID trick into a smaller javascript library so that servlet apps can >> do it. >> >> http://openid.net/specs/openid-connect-session-1_0.html#ChangeNotification >> >> >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Fri Jul 3 04:14:16 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 3 Jul 2015 04:14:16 -0400 (EDT) Subject: [keycloak-dev] Enable remember me by default In-Reply-To: <1242974403.31570128.1435911150754.JavaMail.zimbra@redhat.com> Message-ID: <1777361058.31570699.1435911256872.JavaMail.zimbra@redhat.com> Should we have remember-me enabled by default for a new realm, and also have the option clicked by default on the login form? In most cases a user would want to have this enabled. In the case a user uses a shared computer it's recommended to use private/incognito mode in either case, which will automatically clear all cookies and history. From milorad.filipovic at panonit.com Fri Jul 3 04:40:58 2015 From: milorad.filipovic at panonit.com (Milorad Filipovic) Date: Fri, 03 Jul 2015 10:40:58 +0200 Subject: [keycloak-dev] Basic keycloak jetty adapter configuration Message-ID: <7da0-55964a80-1d-5c7da780@184551807> Hi, I am trying to implement basic keycloak login in my web application, but i cannot start the Jetty server once the adapter has been installed. I have a custom web app that needs to use Fispace keycloak authentiction and I have successfully integrated the Javascript adapter, but I am having trouble with the Jetty adapter. My Jetty version is 9.2.0.M0 Keycloak 1.3.1. Final Keycloak Jetty 9.2 adapter is downloaded from : http://sourceforge.net/projects/keycloak/files/1.3.1.Final/adapters/ Adapter is configured according to: http://keycloak.github.io/docs/userguide/html/ch08.html#jetty9-adapter I use keycloak.json provided from Fispace which is used also with the javascript adapter. But when I try to run jetty, i get the following error: 2015-07-03 10:27:34.047:WARN:oejx.XmlConfiguration:main: Config error at |???|?? java.lang.NoSuchMethodException: class org.eclipse.jetty.security.ConstraintSecurityHandler.setAuthenticator(class org.keycloak.adapters.jetty.KeycloakJettyAuthenticator) in file:/C:/Users/mrd/AppData/Local/Temp/jetty-0.0.0.0-8080-MVNJettyHello.war-_MVNJettyHello-any-5285823088457280813.dir/webapp/WEB-INF/jetty-web.xml 2015-07-03 10:27:34.047:WARN:oejx.XmlConfiguration:main: Config error at |???|?? java.lang.NoSuchMethodException: class org.eclipse.jetty.security.ConstraintSecurityHandler.setAuthenticator(class org.keycloak.adapters.jetty.KeycloakJettyAuthenticator) in file:/C:/Users/mrd/AppData/Local/Temp/jetty-0.0.0.0-8080-MVNJettyHello.war-_MVNJettyHello-any-5285823088457280813.dir/webapp/WEB-INF/jetty-web.xml 2015-07-03 10:27:34.057:WARN:oejw.WebAppContext:main: Failed startup of context o.e.j.w.WebAppContext at 13fcdbd{/MVNJettyHello,file:/C:/Users/mrd/AppData/Local/Temp/jetty-0.0.0.0-8080-MVNJettyHello.war-_MVNJettyHello-any-5285823088457280813.dir/webapp/,STARTING}{C:\jetty\jetty-distribution-9.2.11.v20150529\webapps\MVNJettyHello.war} java.lang.NoSuchMethodException: class org.eclipse.jetty.security.ConstraintSecurityHandler.setAuthenticator(class org.keycloak.adapters.jetty.KeycloakJettyAuthenticator) at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.set(XmlConfiguration.java:582) at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:411) at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.get(XmlConfiguration.java:662) at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:420) at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:298) at org.eclipse.jetty.xml.XmlConfiguration.configure(XmlConfiguration.java:248) at org.eclipse.jetty.webapp.JettyWebXmlConfiguration.configure(JettyWebXmlConfiguration.java:102) at org.eclipse.jetty.webapp.WebAppContext.configure(WebAppContext.java:479) at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1337) at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741) at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) at org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:41) at org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:186) at org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:498) at org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:146) at org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:180) at org.eclipse.jetty.deploy.providers.WebAppProvider.fileAdded(WebAppProvider.java:455) at org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:64) at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:609) at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:528) at org.eclipse.jetty.util.Scanner.scan(Scanner.java:391) at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:313) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) at org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.java:150) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) at org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManager.java:560) at org.eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.java:235) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132) at org.eclipse.jetty.server.Server.start(Server.java:387) at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114) at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61) at org.eclipse.jetty.server.Server.doStart(Server.java:354) at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) at org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1255) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1174) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.jetty.start.Main.invokeMain(Main.java:321) at org.eclipse.jetty.start.Main.start(Main.java:817) at org.eclipse.jetty.start.Main.main(Main.java:112) From ssilvert at redhat.com Fri Jul 3 06:54:05 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Fri, 03 Jul 2015 06:54:05 -0400 Subject: [keycloak-dev] Enable remember me by default In-Reply-To: <1777361058.31570699.1435911256872.JavaMail.zimbra@redhat.com> References: <1777361058.31570699.1435911256872.JavaMail.zimbra@redhat.com> Message-ID: <559669CD.6050604@redhat.com> On 7/3/2015 4:14 AM, Stian Thorgersen wrote: > Should we have remember-me enabled by default for a new realm, and also have the option clicked by default on the login form? > > In most cases a user would want to have this enabled. In the case a user uses a shared computer it's recommended to use private/incognito mode in either case, which will automatically clear all cookies and history. I vote no. I'm betting that most ordinary users don't even know that private/incognito mode exists. If they did, they wouldn't fully understand what it does. I'm also betting that most users don't really know what remember-me does either. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Fri Jul 3 07:29:31 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 3 Jul 2015 07:29:31 -0400 (EDT) Subject: [keycloak-dev] Enable remember me by default In-Reply-To: <559669CD.6050604@redhat.com> References: <1777361058.31570699.1435911256872.JavaMail.zimbra@redhat.com> <559669CD.6050604@redhat.com> Message-ID: <406691024.31707420.1435922971781.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Stan Silvert" > To: keycloak-dev at lists.jboss.org > Sent: Friday, 3 July, 2015 12:54:05 PM > Subject: Re: [keycloak-dev] Enable remember me by default > > On 7/3/2015 4:14 AM, Stian Thorgersen wrote: > > Should we have remember-me enabled by default for a new realm, and also > > have the option clicked by default on the login form? > > > > In most cases a user would want to have this enabled. In the case a user > > uses a shared computer it's recommended to use private/incognito mode in > > either case, which will automatically clear all cookies and history. > I vote no. I'm betting that most ordinary users don't even know that > private/incognito mode exists. If they did, they wouldn't fully > understand what it does. End of the day users have to understand that if they use a shared machine they should either use private mode or log out. Closing the browser isn't guaranteed to clear the session (Chrome could be running in background, there could be a minimized window, etc.). In fact quite a few sites do enable this by default, for example Google and Twitter. GitHub doesn't even provide an option they just always enable it. > > I'm also betting that most users don't really know what remember-me does > either. True - maybe we should change the label to "Stay signed in" > > _______________________________________________ > > 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 Jul 3 07:40:49 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 3 Jul 2015 07:40:49 -0400 (EDT) Subject: [keycloak-dev] Including Keycloak client adapters in WildFly 10 In-Reply-To: <471812210.31708102.1435923147793.JavaMail.zimbra@redhat.com> Message-ID: <2083988224.31710463.1435923649086.JavaMail.zimbra@redhat.com> Keycloak provides an adapter, including a WildFly extensions, to make it easier to add authentication to JavaEE applications with Keycloak. It includes a few modules. Currently 8 Keycloak specific modules and one 1 third-party. The third-party is net.iharder.base64. As the WildFly extensions includes a deployment processor that configures the authentication method as well as dependencies for a deployment it's easy to add authentication to a JavaEE application. All you need to do is specify it in standalone.xml, for example: ... myrealm MIIBIjAN... http://localhost:8081/auth EXTERNAL mywar 675356d8-2b6b-4602-a74f-7079e0555885 ... I'd like to explore if we can add this extension and the required modules directly to WildFly 10, rather than require users to add it themselves. From fmrage at hotmail.com Mon Jul 6 08:54:28 2015 From: fmrage at hotmail.com (Fabio Monteiro) Date: Mon, 6 Jul 2015 14:54:28 +0200 Subject: [keycloak-dev] Is it possible to make the login keycloak page look different between several applications? Message-ID: Hi there, We have a client that uses KeyCloak as a centralized server solution for grant and security access. We would like to know if it is possible to make the login page of KeyCloak look COMPLETELY different ? Even better, is it possible to simply use ONLY REST communications from a business app to handle everything Keycloak has to offer in terms of security and identity ?? Thanks a lot for your help, we are not sure about how to handle all this. Fabio Mfmrage at hotmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150706/34cc40f6/attachment.html From bburke at redhat.com Mon Jul 6 09:07:08 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 06 Jul 2015 09:07:08 -0400 Subject: [keycloak-dev] Is it possible to make the login keycloak page look different between several applications? In-Reply-To: References: Message-ID: <559A7D7C.5010501@redhat.com> Please post user questions on keycloak-user. Comments inline On 7/6/2015 8:54 AM, Fabio Monteiro wrote: > Hi there, > > We have a client that uses KeyCloak as a centralized server solution for > grant and security access. We would like to know if it is possible to > make the login page of KeyCloak look COMPLETELY different ? > It is possible to make keycloak login look entirely different. The login pages all use Freemarker templates and you have the ability to override anything you want piecemeal, or you can entirely change the look and feel. Here's a good example of that: https://developers.redhat.com/auth/realms/rhd/account Here's the documentation on themes: http://keycloak.github.io/docs/userguide/html/themes.html > Even better, is it possible to simply use ONLY REST communications from > a business app to handle everything Keycloak has to offer in terms of > security and identity ?? > Keycloak has a REST interface, but you are losing a lot of functionality if you just use that. Keycloak just becomes a backend store in that scenario... -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From marcelo.sampaio at serpro.gov.br Mon Jul 6 10:15:39 2015 From: marcelo.sampaio at serpro.gov.br (Marcelo Arthur Sampaio) Date: Mon, 06 Jul 2015 14:15:39 +0000 Subject: [keycloak-dev] Is it possible to make the login keycloak page look different between several applications? In-Reply-To: <6f6760f8a31edd37a81a64ca9257d0e8e77911c0@serpro.gov.br> References: <8e7a2ac31859128b0eb27d747bab1d37194c9cf7@serpro.gov.br> <3c99978c832525166a698ca5e2f5b907ceaf3f75@serpro.gov.br> <6f6760f8a31edd37a81a64ca9257d0e8e77911c0@serpro.gov.br> Message-ID: Hi, I'm try to add user using LDAP federation, but get this error: 11:08:40,891 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth].[Keycloak REST Interface]] (http-localhost/127.0.0.1:8080-6) JBWEB000236: Servlet.service() for servlet Keycloak REST Interface threw exception: java.lang.RuntimeException: request path: /auth/admin/realms/demo/users ??? at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:54) [keycloak-services-1.3.1.Final.jar:1.3.1.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.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.8.0_45] Caused by: java.lang.IllegalArgumentException: can't parse argument number: cn=teste ??? at java.text.MessageFormat.makeFormat(MessageFormat.java:1429) [rt.jar:1.8.0_45] ??? at java.text.MessageFormat.applyPattern(MessageFormat.java:479) [rt.jar:1.8.0_45] ??? at java.text.MessageFormat.(MessageFormat.java:380) [rt.jar:1.8.0_45] ??? at org.keycloak.services.messages.AdminMessagesProvider.getMessage(AdminMessagesProvider.java:32) [keycloak-services-1.3.1.Final.jar:1.3.1.Final] ??? at org.keycloak.services.resources.ModelExceptionMapper.toResponse(ModelExceptionMapper.java:27) [keycloak-services-1.3.1.Final.jar:1.3.1.Final] ??? at org.keycloak.services.resources.ModelExceptionMapper.toResponse(ModelExceptionMapper.java:17) [keycloak-services-1.3.1.Final.jar:1.3.1.Final] ??? at org.jboss.resteasy.core.SynchronousDispatcher.executeExceptionMapper(SynchronousDispatcher.java:343) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] ??? at org.jboss.resteasy.core.SynchronousDispatcher.unwrapException(SynchronousDispatcher.java:372) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] ??? at org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:361) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] ??? at org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:232) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] ??? at org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:208) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] ??? at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:556) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] ??? at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:523) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] ??? at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] ??? at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] ??? at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] ??? at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] ??? at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2] ??? at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] ??? at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] ??? at org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41) [keycloak-services-1.3.1.Final.jar:1.3.1.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.3.1.Final.jar:1.3.1.Final] ??? ... 13 more Caused by: java.lang.NumberFormatException: For input string: "cn=teste" ??? at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) [rt.jar:1.8.0_45] ??? at java.lang.Integer.parseInt(Integer.java:580) [rt.jar:1.8.0_45] ??? at java.lang.Integer.parseInt(Integer.java:615) [rt.jar:1.8.0_45] ??? at java.text.MessageFormat.makeFormat(MessageFormat.java:1427) [rt.jar:1.8.0_45] ??? ... 36 more - "Esta mensagem do SERVI?O FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa p?blica federal regida pelo disposto na Lei Federal n? 5.615, ? enviada exclusivamente a seu destinat?rio e pode conter informa??es confidenciais, protegidas por sigilo profissional. Sua utiliza??o desautorizada ? ilegal e sujeita o infrator ?s penas da lei. Se voc? a recebeu indevidamente, queira, por gentileza, reenvi?-la ao emitente, esclarecendo o equ?voco." "This message from SERVI?O FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) -- a government company established under Brazilian law (5.615/70) -- is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150706/83575dc4/attachment-0001.html From marcelo.sampaio at serpro.gov.br Mon Jul 6 10:16:46 2015 From: marcelo.sampaio at serpro.gov.br (Marcelo Arthur Sampaio) Date: Mon, 06 Jul 2015 14:16:46 +0000 Subject: [keycloak-dev] Error on add user in ldap federation In-Reply-To: <923d680658a47a6bb80b6990d028ff59e8a5d3e7@serpro.gov.br> References: <8e7a2ac31859128b0eb27d747bab1d37194c9cf7@serpro.gov.br> <3c99978c832525166a698ca5e2f5b907ceaf3f75@serpro.gov.br> <6f6760f8a31edd37a81a64ca9257d0e8e77911c0@serpro.gov.br> <923d680658a47a6bb80b6990d028ff59e8a5d3e7@serpro.gov.br> Message-ID: <05831e30366b19834d2d55e0bde3c23983cee78d@serpro.gov.br> > Hi, > > I'm try to add user using LDAP federation, but get this error: > > 11:08:40,891 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth].[Keycloak REST Interface]] (http-localhost/127.0.0.1:8080-6) JBWEB000236: Servlet.service() for servlet Keycloak REST Interface threw exception: java.lang.RuntimeException: request path: /auth/admin/realms/demo/users > ??? at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:54) [keycloak-services-1.3.1.Final.jar:1.3.1.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.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.8.0_45] > Caused by: java.lang.IllegalArgumentException: can't parse argument number> : cn=teste > ??? at java.text.MessageFormat.makeFormat(MessageFormat.java:1429) [rt.jar:1.8.0_45] > ??? at java.text.MessageFormat.applyPattern(MessageFormat.java:479) [rt.jar:1.8.0_45] > ??? at java.text.MessageFormat.(MessageFormat.java:380) [rt.jar:1.8.0_45] > ??? at org.keycloak.services.messages.AdminMessagesProvider.getMessage(AdminMessagesProvider.java:32) [keycloak-services-1.3.1.Final.jar:1.3.1.Final] > ??? at org.keycloak.services.resources.ModelExceptionMapper.toResponse(ModelExceptionMapper.java:27) [keycloak-services-1.3.1.Final.jar:1.3.1.Final] > ??? at org.keycloak.services.resources.ModelExceptionMapper.toResponse(ModelExceptionMapper.java:17) [keycloak-services-1.3.1.Final.jar:1.3.1.Final] > ??? at org.jboss.resteasy.core.SynchronousDispatcher.executeExceptionMapper(SynchronousDispatcher.java:343) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > ??? at org.jboss.resteasy.core.SynchronousDispatcher.unwrapException(SynchronousDispatcher.java:372) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > ??? at org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:361) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > ??? at org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:232) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > ??? at org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:208) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > ??? at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:556) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > ??? at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:523) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > ??? at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > ??? at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > ??? at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > ??? at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > ??? at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2] > ??? at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > ??? at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > ??? at org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41) [keycloak-services-1.3.1.Final.jar:1.3.1.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.3.1.Final.jar:1.3.1.Final] > ??? ... 13 more > Caused by: java.lang.NumberFormatException: For input string: > "cn=teste" > ??? at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) [rt.jar:1.8.0_45] > ??? at java.lang.Integer.parseInt(Integer.java:580) [rt.jar:1.8.0_45] > ??? at java.lang.Integer.parseInt(Integer.java:615) [rt.jar:1.8.0_45] > ??? at java.text.MessageFormat.makeFormat(MessageFormat.java:1427) [rt.jar:1.8.0_45] > ??? ... 36 more - "Esta mensagem do SERVI?O FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa p?blica federal regida pelo disposto na Lei Federal n? 5.615, ? enviada exclusivamente a seu destinat?rio e pode conter informa??es confidenciais, protegidas por sigilo profissional. Sua utiliza??o desautorizada ? ilegal e sujeita o infrator ?s penas da lei. Se voc? a recebeu indevidamente, queira, por gentileza, reenvi?-la ao emitente, esclarecendo o equ?voco." "This message from SERVI?O FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) -- a government company established under Brazilian law (5.615/70) -- is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150706/fedafa93/attachment.html From srossillo at smartling.com Mon Jul 6 10:42:36 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Mon, 6 Jul 2015 10:42:36 -0400 Subject: [keycloak-dev] Deadlocks on /realms/{realm-name}/protocol/openid-connect/token Message-ID: Hi, We?re seeing MySQL deadlocks on requests to /realms/{realm-name}/protocol/openid-connect/token ranging from 8 to > 40 per day causing internal server errors. The thrown exception doesn?t really give enough information on what caused the deadlock. This is on 1.2.0. Any thoughts? Stack below. 2015-07-06 08:46:01,599 [ERROR] [default task-1] (LoggingExceptionHandler.java:handleThrowable:80) UT005023: Exception handling request to /auth/realms/xyz/protocol/openid-connect/token: java.lang.RuntimeException: request path: /auth/realms/xyz/protocol/openid-connect/token at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:54) at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_79] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_79] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_79] Caused by: org.keycloak.models.ModelException: javax.persistence.PersistenceException: org.hibernate.exception.LockAcquisitionException: could not execute statement at org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:44) [keycloak-connections-jpa-1.2.Final.jar:1.2.0.Final] at org.keycloak.connections.jpa.JpaKeycloakTransaction.commit(JpaKeycloakTransaction.java:30) [keycloak-connections-jpa-1.2.Final.jar:1.2.0.Final] at org.keycloak.services.DefaultKeycloakTransactionManager.commit(DefaultKeycloakTransactionManager.java:55) [keycloak-services-1.2.Final.jar:1.2.0.Final] at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:43) [keycloak-services-1.2.Final.jar:1.2.0.Final] ... 28 more Caused by: javax.persistence.PersistenceException: org.hibernate.exception.LockAcquisitionException: could not execute statement at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1677) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.jpa.internal.TransactionImpl.commit(TransactionImpl.java:82) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] at org.keycloak.connections.jpa.JpaKeycloakTransaction.commit(JpaKeycloakTransaction.java:28) [keycloak-connections-jpa-1.2.Final.jar:1.2.0.Final] ... 30 more Caused by: org.hibernate.exception.LockAcquisitionException: could not execute statement at org.hibernate.dialect.MySQLDialect$1.convert(MySQLDialect.java:451) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:126) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:112) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:211) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:62) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:3281) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:3183) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:3525) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:159) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:463) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:349) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:350) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:56) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1222) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:425) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.beforeTransactionCommit(JdbcTransaction.java:101) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(AbstractTransactionImpl.java:177) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] at org.hibernate.jpa.internal.TransactionImpl.commit(TransactionImpl.java:77) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] ... 31 more Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_79] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_79] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_79] at java.lang.reflect.Constructor.newInstance(Constructor.java:526) [rt.jar:1.7.0_79] at com.mysql.jdbc.Util.handleNewInstance(Util.java:389) at com.mysql.jdbc.Util.getInstance(Util.java:372) at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:987) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3835) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3771) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2435) at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2582) at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2535) at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1911) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2145) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2081) at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2066) at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493) at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:208) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] ... 45 more From bburke at redhat.com Mon Jul 6 10:58:50 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 06 Jul 2015 10:58:50 -0400 Subject: [keycloak-dev] Deadlocks on /realms/{realm-name}/protocol/openid-connect/token In-Reply-To: References: Message-ID: <559A97AA.1080602@redhat.com> Are you using JPA user session storage? Everything but session data should be read-only unless some write operation snuck in Stack trace doesn't really help :( On 7/6/2015 10:42 AM, Scott Rossillo wrote: > Hi, > > We?re seeing MySQL deadlocks on requests to /realms/{realm-name}/protocol/openid-connect/token ranging from 8 to > 40 per day causing internal server errors. The thrown exception doesn?t really give enough information on what caused the deadlock. > > This is on 1.2.0. Any thoughts? Stack below. > > 2015-07-06 08:46:01,599 [ERROR] [default task-1] (LoggingExceptionHandler.java:handleThrowable:80) UT005023: Exception handling request to /auth/realms/xyz/protocol/openid-connect/token: java.lang.RuntimeException: request path: /auth/realms/xyz/protocol/openid-connect/token > at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:54) > at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_79] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_79] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_79] > Caused by: org.keycloak.models.ModelException: javax.persistence.PersistenceException: org.hibernate.exception.LockAcquisitionException: could not execute statement > at org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:44) [keycloak-connections-jpa-1.2.Final.jar:1.2.0.Final] > at org.keycloak.connections.jpa.JpaKeycloakTransaction.commit(JpaKeycloakTransaction.java:30) [keycloak-connections-jpa-1.2.Final.jar:1.2.0.Final] > at org.keycloak.services.DefaultKeycloakTransactionManager.commit(DefaultKeycloakTransactionManager.java:55) [keycloak-services-1.2.Final.jar:1.2.0.Final] > at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:43) [keycloak-services-1.2.Final.jar:1.2.0.Final] > ... 28 more > Caused by: javax.persistence.PersistenceException: org.hibernate.exception.LockAcquisitionException: could not execute statement > at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1677) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.jpa.internal.TransactionImpl.commit(TransactionImpl.java:82) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] > at org.keycloak.connections.jpa.JpaKeycloakTransaction.commit(JpaKeycloakTransaction.java:28) [keycloak-connections-jpa-1.2.Final.jar:1.2.0.Final] > ... 30 more > Caused by: org.hibernate.exception.LockAcquisitionException: could not execute statement > at org.hibernate.dialect.MySQLDialect$1.convert(MySQLDialect.java:451) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:126) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:112) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:211) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:62) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:3281) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:3183) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:3525) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:159) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:463) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:349) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:350) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:56) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1222) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:425) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.beforeTransactionCommit(JdbcTransaction.java:101) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(AbstractTransactionImpl.java:177) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > at org.hibernate.jpa.internal.TransactionImpl.commit(TransactionImpl.java:77) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] > ... 31 more > Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_79] > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_79] > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_79] > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) [rt.jar:1.7.0_79] > at com.mysql.jdbc.Util.handleNewInstance(Util.java:389) > at com.mysql.jdbc.Util.getInstance(Util.java:372) > at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:987) > at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3835) > at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3771) > at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2435) > at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2582) > at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2535) > at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1911) > at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2145) > at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2081) > at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2066) > at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493) > at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:208) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] > ... 45 more > _______________________________________________ > 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 srossillo at smartling.com Mon Jul 6 11:03:16 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Mon, 6 Jul 2015 11:03:16 -0400 Subject: [keycloak-dev] Deadlocks on /realms/{realm-name}/protocol/openid-connect/token In-Reply-To: <559A97AA.1080602@redhat.com> References: <559A97AA.1080602@redhat.com> Message-ID: <8FB4E1CF-7982-4D44-8852-8D4D494C64CA@smartling.com> Yes, using JPA user session storage. May have to add some code to get a better stack trace. > On Jul 6, 2015, at 10:58 AM, Bill Burke wrote: > > Are you using JPA user session storage? Everything but session data > should be read-only unless some write operation snuck in > > Stack trace doesn't really help :( > > On 7/6/2015 10:42 AM, Scott Rossillo wrote: >> Hi, >> >> We?re seeing MySQL deadlocks on requests to /realms/{realm-name}/protocol/openid-connect/token ranging from 8 to > 40 per day causing internal server errors. The thrown exception doesn?t really give enough information on what caused the deadlock. >> >> This is on 1.2.0. Any thoughts? Stack below. >> >> 2015-07-06 08:46:01,599 [ERROR] [default task-1] (LoggingExceptionHandler.java:handleThrowable:80) UT005023: Exception handling request to /auth/realms/xyz/protocol/openid-connect/token: java.lang.RuntimeException: request path: /auth/realms/xyz/protocol/openid-connect/token >> at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:54) >> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) >> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_79] >> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_79] >> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_79] >> Caused by: org.keycloak.models.ModelException: javax.persistence.PersistenceException: org.hibernate.exception.LockAcquisitionException: could not execute statement >> at org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:44) [keycloak-connections-jpa-1.2.Final.jar:1.2.0.Final] >> at org.keycloak.connections.jpa.JpaKeycloakTransaction.commit(JpaKeycloakTransaction.java:30) [keycloak-connections-jpa-1.2.Final.jar:1.2.0.Final] >> at org.keycloak.services.DefaultKeycloakTransactionManager.commit(DefaultKeycloakTransactionManager.java:55) [keycloak-services-1.2.Final.jar:1.2.0.Final] >> at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:43) [keycloak-services-1.2.Final.jar:1.2.0.Final] >> ... 28 more >> Caused by: javax.persistence.PersistenceException: org.hibernate.exception.LockAcquisitionException: could not execute statement >> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1677) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.jpa.internal.TransactionImpl.commit(TransactionImpl.java:82) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >> at org.keycloak.connections.jpa.JpaKeycloakTransaction.commit(JpaKeycloakTransaction.java:28) [keycloak-connections-jpa-1.2.Final.jar:1.2.0.Final] >> ... 30 more >> Caused by: org.hibernate.exception.LockAcquisitionException: could not execute statement >> at org.hibernate.dialect.MySQLDialect$1.convert(MySQLDialect.java:451) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:126) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:112) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:211) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:62) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:3281) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:3183) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:3525) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:159) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:463) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:349) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:350) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:56) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1222) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:425) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.beforeTransactionCommit(JdbcTransaction.java:101) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(AbstractTransactionImpl.java:177) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.jpa.internal.TransactionImpl.commit(TransactionImpl.java:77) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >> ... 31 more >> Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction >> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_79] >> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_79] >> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_79] >> at java.lang.reflect.Constructor.newInstance(Constructor.java:526) [rt.jar:1.7.0_79] >> at com.mysql.jdbc.Util.handleNewInstance(Util.java:389) >> at com.mysql.jdbc.Util.getInstance(Util.java:372) >> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:987) >> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3835) >> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3771) >> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2435) >> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2582) >> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2535) >> at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1911) >> at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2145) >> at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2081) >> at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2066) >> at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493) >> at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:208) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> ... 45 more >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Mon Jul 6 11:09:02 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 06 Jul 2015 11:09:02 -0400 Subject: [keycloak-dev] Deadlocks on /realms/{realm-name}/protocol/openid-connect/token In-Reply-To: <559A97AA.1080602@redhat.com> References: <559A97AA.1080602@redhat.com> Message-ID: <559A9A0E.6060704@redhat.com> Just reviewed code quickly. I don't see any updates for non user-session metadata under "/token" invocations. Initial social logins will do inserts and updates though, but that happens "/token" requests. Is there any way to get more info from MySQL? On 7/6/2015 10:58 AM, Bill Burke wrote: > Are you using JPA user session storage? Everything but session data > should be read-only unless some write operation snuck in > > Stack trace doesn't really help :( > > On 7/6/2015 10:42 AM, Scott Rossillo wrote: >> Hi, >> >> We?re seeing MySQL deadlocks on requests to /realms/{realm-name}/protocol/openid-connect/token ranging from 8 to > 40 per day causing internal server errors. The thrown exception doesn?t really give enough information on what caused the deadlock. >> >> This is on 1.2.0. Any thoughts? Stack below. >> >> 2015-07-06 08:46:01,599 [ERROR] [default task-1] (LoggingExceptionHandler.java:handleThrowable:80) UT005023: Exception handling request to /auth/realms/xyz/protocol/openid-connect/token: java.lang.RuntimeException: request path: /auth/realms/xyz/protocol/openid-connect/token >> at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:54) >> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) >> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_79] >> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_79] >> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_79] >> Caused by: org.keycloak.models.ModelException: javax.persistence.PersistenceException: org.hibernate.exception.LockAcquisitionException: could not execute statement >> at org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:44) [keycloak-connections-jpa-1.2.Final.jar:1.2.0.Final] >> at org.keycloak.connections.jpa.JpaKeycloakTransaction.commit(JpaKeycloakTransaction.java:30) [keycloak-connections-jpa-1.2.Final.jar:1.2.0.Final] >> at org.keycloak.services.DefaultKeycloakTransactionManager.commit(DefaultKeycloakTransactionManager.java:55) [keycloak-services-1.2.Final.jar:1.2.0.Final] >> at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:43) [keycloak-services-1.2.Final.jar:1.2.0.Final] >> ... 28 more >> Caused by: javax.persistence.PersistenceException: org.hibernate.exception.LockAcquisitionException: could not execute statement >> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1677) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.jpa.internal.TransactionImpl.commit(TransactionImpl.java:82) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >> at org.keycloak.connections.jpa.JpaKeycloakTransaction.commit(JpaKeycloakTransaction.java:28) [keycloak-connections-jpa-1.2.Final.jar:1.2.0.Final] >> ... 30 more >> Caused by: org.hibernate.exception.LockAcquisitionException: could not execute statement >> at org.hibernate.dialect.MySQLDialect$1.convert(MySQLDialect.java:451) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:126) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:112) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:211) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:62) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:3281) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:3183) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:3525) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:159) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:463) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:349) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:350) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:56) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1222) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:425) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.beforeTransactionCommit(JdbcTransaction.java:101) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(AbstractTransactionImpl.java:177) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> at org.hibernate.jpa.internal.TransactionImpl.commit(TransactionImpl.java:77) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >> ... 31 more >> Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction >> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_79] >> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_79] >> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_79] >> at java.lang.reflect.Constructor.newInstance(Constructor.java:526) [rt.jar:1.7.0_79] >> at com.mysql.jdbc.Util.handleNewInstance(Util.java:389) >> at com.mysql.jdbc.Util.getInstance(Util.java:372) >> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:987) >> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3835) >> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3771) >> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2435) >> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2582) >> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2535) >> at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1911) >> at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2145) >> at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2081) >> at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2066) >> at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493) >> at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:208) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >> ... 45 more >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Mon Jul 6 11:10:20 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 06 Jul 2015 11:10:20 -0400 Subject: [keycloak-dev] Deadlocks on /realms/{realm-name}/protocol/openid-connect/token In-Reply-To: <8FB4E1CF-7982-4D44-8852-8D4D494C64CA@smartling.com> References: <559A97AA.1080602@redhat.com> <8FB4E1CF-7982-4D44-8852-8D4D494C64CA@smartling.com> Message-ID: <559A9A5C.707@redhat.com> Ugh, then there are a ton of inserts/updates happening to the same few tables. On 7/6/2015 11:03 AM, Scott Rossillo wrote: > > Yes, using JPA user session storage. > > May have to add some code to get a better stack trace. > > > >> On Jul 6, 2015, at 10:58 AM, Bill Burke wrote: >> >> Are you using JPA user session storage? Everything but session data >> should be read-only unless some write operation snuck in >> >> Stack trace doesn't really help :( >> >> On 7/6/2015 10:42 AM, Scott Rossillo wrote: >>> Hi, >>> >>> We?re seeing MySQL deadlocks on requests to /realms/{realm-name}/protocol/openid-connect/token ranging from 8 to > 40 per day causing internal server errors. The thrown exception doesn?t really give enough information on what caused the deadlock. >>> >>> This is on 1.2.0. Any thoughts? Stack below. >>> >>> 2015-07-06 08:46:01,599 [ERROR] [default task-1] (LoggingExceptionHandler.java:handleThrowable:80) UT005023: Exception handling request to /auth/realms/xyz/protocol/openid-connect/token: java.lang.RuntimeException: request path: /auth/realms/xyz/protocol/openid-connect/token >>> at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:54) >>> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) >>> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >>> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_79] >>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_79] >>> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_79] >>> Caused by: org.keycloak.models.ModelException: javax.persistence.PersistenceException: org.hibernate.exception.LockAcquisitionException: could not execute statement >>> at org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:44) [keycloak-connections-jpa-1.2.Final.jar:1.2.0.Final] >>> at org.keycloak.connections.jpa.JpaKeycloakTransaction.commit(JpaKeycloakTransaction.java:30) [keycloak-connections-jpa-1.2.Final.jar:1.2.0.Final] >>> at org.keycloak.services.DefaultKeycloakTransactionManager.commit(DefaultKeycloakTransactionManager.java:55) [keycloak-services-1.2.Final.jar:1.2.0.Final] >>> at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:43) [keycloak-services-1.2.Final.jar:1.2.0.Final] >>> ... 28 more >>> Caused by: javax.persistence.PersistenceException: org.hibernate.exception.LockAcquisitionException: could not execute statement >>> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >>> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1677) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >>> at org.hibernate.jpa.internal.TransactionImpl.commit(TransactionImpl.java:82) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >>> at org.keycloak.connections.jpa.JpaKeycloakTransaction.commit(JpaKeycloakTransaction.java:28) [keycloak-connections-jpa-1.2.Final.jar:1.2.0.Final] >>> ... 30 more >>> Caused by: org.hibernate.exception.LockAcquisitionException: could not execute statement >>> at org.hibernate.dialect.MySQLDialect$1.convert(MySQLDialect.java:451) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:126) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:112) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:211) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:62) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:3281) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:3183) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:3525) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:159) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:463) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:349) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:350) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:56) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1222) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:425) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.beforeTransactionCommit(JdbcTransaction.java:101) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(AbstractTransactionImpl.java:177) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> at org.hibernate.jpa.internal.TransactionImpl.commit(TransactionImpl.java:77) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >>> ... 31 more >>> Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction >>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_79] >>> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_79] >>> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_79] >>> at java.lang.reflect.Constructor.newInstance(Constructor.java:526) [rt.jar:1.7.0_79] >>> at com.mysql.jdbc.Util.handleNewInstance(Util.java:389) >>> at com.mysql.jdbc.Util.getInstance(Util.java:372) >>> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:987) >>> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3835) >>> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3771) >>> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2435) >>> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2582) >>> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2535) >>> at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1911) >>> at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2145) >>> at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2081) >>> at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2066) >>> at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493) >>> at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:208) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>> ... 45 more >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From ssilvert at redhat.com Mon Jul 6 12:02:20 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Mon, 06 Jul 2015 12:02:20 -0400 Subject: [keycloak-dev] Idle timeout notificaion In-Reply-To: <5592D511.9050901@redhat.com> References: <5591AC0F.70102@redhat.com> <5591B7F9.6020700@redhat.com> <5591BB0C.5030209@redhat.com> <5591E431.8050802@redhat.com> <55928A5F.2070001@redhat.com> <5592981F.4040309@redhat.com> <5592AF24.4040403@redhat.com> <5592D511.9050901@redhat.com> Message-ID: <559AA68C.5040508@redhat.com> On 6/30/2015 1:42 PM, Bill Burke wrote: > Our background session expiration task currently just wipes away the > sessions in Keycloak server. If it was changed to performing a > backchannel logout, then the adapters would always get notified and > again, the app developer can just implement an HttpSessionListener. After talking to the customer, they say that this would be enough for now. Where is the code for the session expiration task? From srossillo at smartling.com Mon Jul 6 12:47:08 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Mon, 6 Jul 2015 12:47:08 -0400 Subject: [keycloak-dev] Deadlocks on /realms/{realm-name}/protocol/openid-connect/token In-Reply-To: <559A9A5C.707@redhat.com> References: <559A97AA.1080602@redhat.com> <8FB4E1CF-7982-4D44-8852-8D4D494C64CA@smartling.com> <559A9A5C.707@redhat.com> Message-ID: So, It would seem the cause is the ClearExpiredUserSessions scheduled task which is executing the named query, ?removeUserSessionByExpired?: delete from UserSessionEntity s where s.realmId = :realmId and (s.started < :maxTime or s.lastSessionRefresh < :idleTime) This is doing a table scan, causing locks on the USER_SESSION table's primary key. Based on the stock keycloak-server.json, it seems to be done every 15 minutes. Further complicating things is that scheduled tasks are going to run on every Keycloak server in a given environment, so if you have 3 servers, each will try to execute this cleanup at 15 minute intervals from its startup. ~ Scott > On Jul 6, 2015, at 11:10 AM, Bill Burke wrote: > > Ugh, then there are a ton of inserts/updates happening to the same few tables. > > On 7/6/2015 11:03 AM, Scott Rossillo wrote: >> >> Yes, using JPA user session storage. >> >> May have to add some code to get a better stack trace. >> >> >> >>> On Jul 6, 2015, at 10:58 AM, Bill Burke wrote: >>> >>> Are you using JPA user session storage? Everything but session data >>> should be read-only unless some write operation snuck in >>> >>> Stack trace doesn't really help :( >>> >>> On 7/6/2015 10:42 AM, Scott Rossillo wrote: >>>> Hi, >>>> >>>> We?re seeing MySQL deadlocks on requests to /realms/{realm-name}/protocol/openid-connect/token ranging from 8 to > 40 per day causing internal server errors. The thrown exception doesn?t really give enough information on what caused the deadlock. >>>> >>>> This is on 1.2.0. Any thoughts? Stack below. >>>> >>>> 2015-07-06 08:46:01,599 [ERROR] [default task-1] (LoggingExceptionHandler.java:handleThrowable:80) UT005023: Exception handling request to /auth/realms/xyz/protocol/openid-connect/token: java.lang.RuntimeException: request path: /auth/realms/xyz/protocol/openid-connect/token >>>> at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:54) >>>> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) >>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_79] >>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_79] >>>> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_79] >>>> Caused by: org.keycloak.models.ModelException: javax.persistence.PersistenceException: org.hibernate.exception.LockAcquisitionException: could not execute statement >>>> at org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:44) [keycloak-connections-jpa-1.2.Final.jar:1.2.0.Final] >>>> at org.keycloak.connections.jpa.JpaKeycloakTransaction.commit(JpaKeycloakTransaction.java:30) [keycloak-connections-jpa-1.2.Final.jar:1.2.0.Final] >>>> at org.keycloak.services.DefaultKeycloakTransactionManager.commit(DefaultKeycloakTransactionManager.java:55) [keycloak-services-1.2.Final.jar:1.2.0.Final] >>>> at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:43) [keycloak-services-1.2.Final.jar:1.2.0.Final] >>>> ... 28 more >>>> Caused by: javax.persistence.PersistenceException: org.hibernate.exception.LockAcquisitionException: could not execute statement >>>> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >>>> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1677) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >>>> at org.hibernate.jpa.internal.TransactionImpl.commit(TransactionImpl.java:82) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >>>> at org.keycloak.connections.jpa.JpaKeycloakTransaction.commit(JpaKeycloakTransaction.java:28) [keycloak-connections-jpa-1.2.Final.jar:1.2.0.Final] >>>> ... 30 more >>>> Caused by: org.hibernate.exception.LockAcquisitionException: could not execute statement >>>> at org.hibernate.dialect.MySQLDialect$1.convert(MySQLDialect.java:451) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>> at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>> at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:126) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>> at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:112) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>> at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:211) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>> at org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:62) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>> at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:3281) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>> at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:3183) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>> at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:3525) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>> at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:159) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:463) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:349) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>> at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:350) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>> at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:56) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>> at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1222) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>> at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:425) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>> at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.beforeTransactionCommit(JdbcTransaction.java:101) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>> at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(AbstractTransactionImpl.java:177) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>> at org.hibernate.jpa.internal.TransactionImpl.commit(TransactionImpl.java:77) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >>>> ... 31 more >>>> Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction >>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_79] >>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_79] >>>> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_79] >>>> at java.lang.reflect.Constructor.newInstance(Constructor.java:526) [rt.jar:1.7.0_79] >>>> at com.mysql.jdbc.Util.handleNewInstance(Util.java:389) >>>> at com.mysql.jdbc.Util.getInstance(Util.java:372) >>>> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:987) >>>> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3835) >>>> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3771) >>>> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2435) >>>> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2582) >>>> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2535) >>>> at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1911) >>>> at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2145) >>>> at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2081) >>>> at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2066) >>>> at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493) >>>> at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:208) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>> ... 45 more >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com From ssilvert at redhat.com Mon Jul 6 14:43:00 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Mon, 06 Jul 2015 14:43:00 -0400 Subject: [keycloak-dev] Idle timeout notificaion In-Reply-To: <559AA68C.5040508@redhat.com> References: <5591AC0F.70102@redhat.com> <5591B7F9.6020700@redhat.com> <5591BB0C.5030209@redhat.com> <5591E431.8050802@redhat.com> <55928A5F.2070001@redhat.com> <5592981F.4040309@redhat.com> <5592AF24.4040403@redhat.com> <5592D511.9050901@redhat.com> <559AA68C.5040508@redhat.com> Message-ID: <559ACC34.5090802@redhat.com> On 7/6/2015 12:02 PM, Stan Silvert wrote: > On 6/30/2015 1:42 PM, Bill Burke wrote: >> Our background session expiration task currently just wipes away the >> sessions in Keycloak server. If it was changed to performing a >> backchannel logout, then the adapters would always get notified and >> again, the app developer can just implement an HttpSessionListener. > After talking to the customer, they say that this would be enough for > now. Where is the code for the session expiration task? Nevermind. I found it. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From srossillo at smartling.com Mon Jul 6 15:05:30 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Mon, 6 Jul 2015 15:05:30 -0400 Subject: [keycloak-dev] Unable to assign roles from a federation provider In-Reply-To: <558149D5.5040106@redhat.com> References: <4154AAD4-3C42-422B-8FD5-FAA21732B91B@smartling.com> <558149D5.5040106@redhat.com> Message-ID: Hi Marek, Thank you. That did the trick! Best, Scott > On Jun 17, 2015, at 6:20 AM, Marek Posolda wrote: > > Hi, > > you should use method "userModel.grantRole(role)" to add new role mapping. Methods "getRoleMappings" and "getRealmRoleMappings" are used just for reading existing role mappings of user. > > Marek > > On 15.6.2015 16:49, Scott Rossillo wrote: >> Hey all, >> >> I was going to create a JIRA for this, but just want to make sure it?s an actual bug. We are not able to assign roles to a user from a federation provider. >> >> For example, we expected something like this to work from UserFederationProvider. getUserByUsername(RealmModel realm, String username): >> >> if (remoteUser.getRoles() != null) { >> for (String roleName : remoteUser.getRoles()) { >> RoleModel role = realm.getRole(roleName); >> userModel.getRoleMappings().add(role); // doesn?t work >> userModel.getRealmRoleMappings().add(role); // doesn?t work >> } >> } >> >> However, nothing but the default role is assigned even when we confirm additional roles are assigned to remoteUser and realm.getRole() returns a valid RoleModel. >> >> Create JIRA or should we be assigning roles from a UserFederationProvider in another way? >> >> Thanks >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150706/04749bdc/attachment.html From srossillo at smartling.com Tue Jul 7 11:17:02 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Tue, 7 Jul 2015 11:17:02 -0400 Subject: [keycloak-dev] Exposing environment variables and system properties to Freemarker templates Message-ID: I have a need to read environment variables and/or system properties in templates plus. Would this be something you would want to see contributed to the template system or should I just create my own template provider? Thanks, Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150707/17a33123/attachment.html From srossillo at smartling.com Tue Jul 7 12:04:56 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Tue, 7 Jul 2015 12:04:56 -0400 Subject: [keycloak-dev] Deadlocks on /realms/{realm-name}/protocol/openid-connect/token In-Reply-To: References: <559A97AA.1080602@redhat.com> <8FB4E1CF-7982-4D44-8852-8D4D494C64CA@smartling.com> <559A9A5C.707@redhat.com> Message-ID: <90F88CDF-D8AC-4124-B00B-E72B0AB06AD6@smartling.com> The removeUserSessionByExpired query is locking the USER_SESSION table to up to 1.2 seconds at a time and that?s enough to cause deadlocks since it acquires a table lock to do the delete. Indexes on started and lastSessionRefresh may help, but the query may have to be split up into two deletes to pick up the indexes correctly (at least with MySQL). ~ Scott > On Jul 6, 2015, at 12:47 PM, Scott Rossillo wrote: > > So, > > It would seem the cause is the ClearExpiredUserSessions scheduled task which is executing the named query, ?removeUserSessionByExpired?: > > delete from UserSessionEntity s where s.realmId = :realmId and (s.started < :maxTime or s.lastSessionRefresh < :idleTime) > > This is doing a table scan, causing locks on the USER_SESSION table's primary key. > > Based on the stock keycloak-server.json, it seems to be done every 15 minutes. Further complicating things is that scheduled tasks are going to run on every Keycloak server in a given environment, so if you have 3 servers, each will try to execute this cleanup at 15 minute intervals from its startup. > > ~ Scott > > >> On Jul 6, 2015, at 11:10 AM, Bill Burke wrote: >> >> Ugh, then there are a ton of inserts/updates happening to the same few tables. >> >> On 7/6/2015 11:03 AM, Scott Rossillo wrote: >>> >>> Yes, using JPA user session storage. >>> >>> May have to add some code to get a better stack trace. >>> >>> >>> >>>> On Jul 6, 2015, at 10:58 AM, Bill Burke wrote: >>>> >>>> Are you using JPA user session storage? Everything but session data >>>> should be read-only unless some write operation snuck in >>>> >>>> Stack trace doesn't really help :( >>>> >>>> On 7/6/2015 10:42 AM, Scott Rossillo wrote: >>>>> Hi, >>>>> >>>>> We?re seeing MySQL deadlocks on requests to /realms/{realm-name}/protocol/openid-connect/token ranging from 8 to > 40 per day causing internal server errors. The thrown exception doesn?t really give enough information on what caused the deadlock. >>>>> >>>>> This is on 1.2.0. Any thoughts? Stack below. >>>>> >>>>> 2015-07-06 08:46:01,599 [ERROR] [default task-1] (LoggingExceptionHandler.java:handleThrowable:80) UT005023: Exception handling request to /auth/realms/xyz/protocol/openid-connect/token: java.lang.RuntimeException: request path: /auth/realms/xyz/protocol/openid-connect/token >>>>> at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:54) >>>>> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) >>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>>> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>>> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>>> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>>> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>>> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>>> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>>> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_79] >>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_79] >>>>> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_79] >>>>> Caused by: org.keycloak.models.ModelException: javax.persistence.PersistenceException: org.hibernate.exception.LockAcquisitionException: could not execute statement >>>>> at org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:44) [keycloak-connections-jpa-1.2.Final.jar:1.2.0.Final] >>>>> at org.keycloak.connections.jpa.JpaKeycloakTransaction.commit(JpaKeycloakTransaction.java:30) [keycloak-connections-jpa-1.2.Final.jar:1.2.0.Final] >>>>> at org.keycloak.services.DefaultKeycloakTransactionManager.commit(DefaultKeycloakTransactionManager.java:55) [keycloak-services-1.2.Final.jar:1.2.0.Final] >>>>> at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:43) [keycloak-services-1.2.Final.jar:1.2.0.Final] >>>>> ... 28 more >>>>> Caused by: javax.persistence.PersistenceException: org.hibernate.exception.LockAcquisitionException: could not execute statement >>>>> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >>>>> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1677) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >>>>> at org.hibernate.jpa.internal.TransactionImpl.commit(TransactionImpl.java:82) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >>>>> at org.keycloak.connections.jpa.JpaKeycloakTransaction.commit(JpaKeycloakTransaction.java:28) [keycloak-connections-jpa-1.2.Final.jar:1.2.0.Final] >>>>> ... 30 more >>>>> Caused by: org.hibernate.exception.LockAcquisitionException: could not execute statement >>>>> at org.hibernate.dialect.MySQLDialect$1.convert(MySQLDialect.java:451) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>> at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>> at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:126) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>> at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:112) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>> at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:211) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>> at org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:62) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>> at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:3281) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>> at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:3183) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>> at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:3525) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>> at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:159) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:463) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:349) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>> at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:350) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>> at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:56) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>> at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1222) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>> at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:425) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>> at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.beforeTransactionCommit(JdbcTransaction.java:101) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>> at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(AbstractTransactionImpl.java:177) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>> at org.hibernate.jpa.internal.TransactionImpl.commit(TransactionImpl.java:77) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >>>>> ... 31 more >>>>> Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction >>>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_79] >>>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_79] >>>>> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_79] >>>>> at java.lang.reflect.Constructor.newInstance(Constructor.java:526) [rt.jar:1.7.0_79] >>>>> at com.mysql.jdbc.Util.handleNewInstance(Util.java:389) >>>>> at com.mysql.jdbc.Util.getInstance(Util.java:372) >>>>> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:987) >>>>> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3835) >>>>> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3771) >>>>> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2435) >>>>> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2582) >>>>> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2535) >>>>> at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1911) >>>>> at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2145) >>>>> at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2081) >>>>> at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2066) >>>>> at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493) >>>>> at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:208) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>> ... 45 more >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>> >>>> -- >>>> Bill Burke >>>> JBoss, a division of Red Hat >>>> http://bill.burkecentral.com >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com > From bburke at redhat.com Tue Jul 7 13:30:41 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 07 Jul 2015 13:30:41 -0400 Subject: [keycloak-dev] Exposing environment variables and system properties to Freemarker templates In-Reply-To: References: Message-ID: <559C0CC1.4050901@redhat.com> If you look what is going on now with authentication flows, you can see that it is possible to plug in your own authenticator that displays the login page. In there you could initialize whatever variables you wanted to expose. I don't have the UI done yet though and everything is hardcoded. On 7/7/2015 11:17 AM, Scott Rossillo wrote: > > I have a need to read environment variables and/or system properties in > templates plus. Would this be something you would want to see > contributed to the template system or should I just create my own > template provider? > > Thanks, > 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 bburke at redhat.com Wed Jul 8 12:14:25 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 08 Jul 2015 12:14:25 -0400 Subject: [keycloak-dev] Deadlocks on /realms/{realm-name}/protocol/openid-connect/token In-Reply-To: <90F88CDF-D8AC-4124-B00B-E72B0AB06AD6@smartling.com> References: <559A97AA.1080602@redhat.com> <8FB4E1CF-7982-4D44-8852-8D4D494C64CA@smartling.com> <559A9A5C.707@redhat.com> <90F88CDF-D8AC-4124-B00B-E72B0AB06AD6@smartling.com> Message-ID: <559D4C61.3080808@redhat.com> What do you think we should do about this? Do a paginated query within its own transaction and delete only a few of them at a time per transaction? Maybe consider getting off of JPA and moving to Infinispan? I know you guys are on the cloud, but Infinispan can be configured to use TCP instead of Multicast. On 7/7/2015 12:04 PM, Scott Rossillo wrote: > The removeUserSessionByExpired query is locking the USER_SESSION table to up to 1.2 seconds at a time and that?s enough to cause deadlocks since it acquires a table lock to do the delete. Indexes on started and lastSessionRefresh may help, but the query may have to be split up into two deletes to pick up the indexes correctly (at least with MySQL). > > ~ Scott > >> On Jul 6, 2015, at 12:47 PM, Scott Rossillo wrote: >> >> So, >> >> It would seem the cause is the ClearExpiredUserSessions scheduled task which is executing the named query, ?removeUserSessionByExpired?: >> >> delete from UserSessionEntity s where s.realmId = :realmId and (s.started < :maxTime or s.lastSessionRefresh < :idleTime) >> >> This is doing a table scan, causing locks on the USER_SESSION table's primary key. >> >> Based on the stock keycloak-server.json, it seems to be done every 15 minutes. Further complicating things is that scheduled tasks are going to run on every Keycloak server in a given environment, so if you have 3 servers, each will try to execute this cleanup at 15 minute intervals from its startup. >> >> ~ Scott >> >> >>> On Jul 6, 2015, at 11:10 AM, Bill Burke wrote: >>> >>> Ugh, then there are a ton of inserts/updates happening to the same few tables. >>> >>> On 7/6/2015 11:03 AM, Scott Rossillo wrote: >>>> >>>> Yes, using JPA user session storage. >>>> >>>> May have to add some code to get a better stack trace. >>>> >>>> >>>> >>>>> On Jul 6, 2015, at 10:58 AM, Bill Burke wrote: >>>>> >>>>> Are you using JPA user session storage? Everything but session data >>>>> should be read-only unless some write operation snuck in >>>>> >>>>> Stack trace doesn't really help :( >>>>> >>>>> On 7/6/2015 10:42 AM, Scott Rossillo wrote: >>>>>> Hi, >>>>>> >>>>>> We?re seeing MySQL deadlocks on requests to /realms/{realm-name}/protocol/openid-connect/token ranging from 8 to > 40 per day causing internal server errors. The thrown exception doesn?t really give enough information on what caused the deadlock. >>>>>> >>>>>> This is on 1.2.0. Any thoughts? Stack below. >>>>>> >>>>>> 2015-07-06 08:46:01,599 [ERROR] [default task-1] (LoggingExceptionHandler.java:handleThrowable:80) UT005023: Exception handling request to /auth/realms/xyz/protocol/openid-connect/token: java.lang.RuntimeException: request path: /auth/realms/xyz/protocol/openid-connect/token >>>>>> at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:54) >>>>>> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>>> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>>> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>>> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>>> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>>> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) >>>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>>>> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>>> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>>>> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>>>> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>>> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>>>> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>>> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>>>> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >>>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>>>> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>>> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>>> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>>> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>>> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>>>> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_79] >>>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_79] >>>>>> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_79] >>>>>> Caused by: org.keycloak.models.ModelException: javax.persistence.PersistenceException: org.hibernate.exception.LockAcquisitionException: could not execute statement >>>>>> at org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:44) [keycloak-connections-jpa-1.2.Final.jar:1.2.0.Final] >>>>>> at org.keycloak.connections.jpa.JpaKeycloakTransaction.commit(JpaKeycloakTransaction.java:30) [keycloak-connections-jpa-1.2.Final.jar:1.2.0.Final] >>>>>> at org.keycloak.services.DefaultKeycloakTransactionManager.commit(DefaultKeycloakTransactionManager.java:55) [keycloak-services-1.2.Final.jar:1.2.0.Final] >>>>>> at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:43) [keycloak-services-1.2.Final.jar:1.2.0.Final] >>>>>> ... 28 more >>>>>> Caused by: javax.persistence.PersistenceException: org.hibernate.exception.LockAcquisitionException: could not execute statement >>>>>> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >>>>>> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1677) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >>>>>> at org.hibernate.jpa.internal.TransactionImpl.commit(TransactionImpl.java:82) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >>>>>> at org.keycloak.connections.jpa.JpaKeycloakTransaction.commit(JpaKeycloakTransaction.java:28) [keycloak-connections-jpa-1.2.Final.jar:1.2.0.Final] >>>>>> ... 30 more >>>>>> Caused by: org.hibernate.exception.LockAcquisitionException: could not execute statement >>>>>> at org.hibernate.dialect.MySQLDialect$1.convert(MySQLDialect.java:451) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>> at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>> at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:126) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>> at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:112) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>> at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:211) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>> at org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:62) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>> at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:3281) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>> at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:3183) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>> at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:3525) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>> at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:159) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:463) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:349) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>> at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:350) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>> at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:56) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>> at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1222) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>> at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:425) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>> at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.beforeTransactionCommit(JdbcTransaction.java:101) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>> at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(AbstractTransactionImpl.java:177) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>> at org.hibernate.jpa.internal.TransactionImpl.commit(TransactionImpl.java:77) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >>>>>> ... 31 more >>>>>> Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction >>>>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_79] >>>>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_79] >>>>>> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_79] >>>>>> at java.lang.reflect.Constructor.newInstance(Constructor.java:526) [rt.jar:1.7.0_79] >>>>>> at com.mysql.jdbc.Util.handleNewInstance(Util.java:389) >>>>>> at com.mysql.jdbc.Util.getInstance(Util.java:372) >>>>>> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:987) >>>>>> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3835) >>>>>> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3771) >>>>>> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2435) >>>>>> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2582) >>>>>> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2535) >>>>>> at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1911) >>>>>> at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2145) >>>>>> at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2081) >>>>>> at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2066) >>>>>> at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493) >>>>>> at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:208) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>> ... 45 more >>>>>> _______________________________________________ >>>>>> keycloak-dev mailing list >>>>>> keycloak-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>> >>>>> >>>>> -- >>>>> Bill Burke >>>>> JBoss, a division of Red Hat >>>>> http://bill.burkecentral.com >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >> > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From srossillo at smartling.com Wed Jul 8 12:26:07 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Wed, 8 Jul 2015 12:26:07 -0400 Subject: [keycloak-dev] Deadlocks on /realms/{realm-name}/protocol/openid-connect/token In-Reply-To: <559D4C61.3080808@redhat.com> References: <559A97AA.1080602@redhat.com> <8FB4E1CF-7982-4D44-8852-8D4D494C64CA@smartling.com> <559A9A5C.707@redhat.com> <90F88CDF-D8AC-4124-B00B-E72B0AB06AD6@smartling.com> <559D4C61.3080808@redhat.com> Message-ID: <9F055322-2CE8-4D3A-BA0A-F3897DE94ECA@smartling.com> Hi Bill, I agree that Infinispan is the ideal solution and we will eventually migrate to it but there are complications preventing that for the moment. For now, local testing proves that indexing the started and lastSessionRefresh columns significantly reduces the delete cost but we have to use two delete statements for MySQL to pick up the indexes reliably. ~ Scott > On Jul 8, 2015, at 12:14 PM, Bill Burke wrote: > > What do you think we should do about this? Do a paginated query within its own transaction and delete only a few of them at a time per transaction? Maybe consider getting off of JPA and moving to Infinispan? I know you guys are on the cloud, but Infinispan can be configured to use TCP instead of Multicast. > > On 7/7/2015 12:04 PM, Scott Rossillo wrote: >> The removeUserSessionByExpired query is locking the USER_SESSION table to up to 1.2 seconds at a time and that?s enough to cause deadlocks since it acquires a table lock to do the delete. Indexes on started and lastSessionRefresh may help, but the query may have to be split up into two deletes to pick up the indexes correctly (at least with MySQL). >> >> ~ Scott >> >>> On Jul 6, 2015, at 12:47 PM, Scott Rossillo wrote: >>> >>> So, >>> >>> It would seem the cause is the ClearExpiredUserSessions scheduled task which is executing the named query, ?removeUserSessionByExpired?: >>> >>> delete from UserSessionEntity s where s.realmId = :realmId and (s.started < :maxTime or s.lastSessionRefresh < :idleTime) >>> >>> This is doing a table scan, causing locks on the USER_SESSION table's primary key. >>> >>> Based on the stock keycloak-server.json, it seems to be done every 15 minutes. Further complicating things is that scheduled tasks are going to run on every Keycloak server in a given environment, so if you have 3 servers, each will try to execute this cleanup at 15 minute intervals from its startup. >>> >>> ~ Scott >>> >>> >>>> On Jul 6, 2015, at 11:10 AM, Bill Burke wrote: >>>> >>>> Ugh, then there are a ton of inserts/updates happening to the same few tables. >>>> >>>> On 7/6/2015 11:03 AM, Scott Rossillo wrote: >>>>> >>>>> Yes, using JPA user session storage. >>>>> >>>>> May have to add some code to get a better stack trace. >>>>> >>>>> >>>>> >>>>>> On Jul 6, 2015, at 10:58 AM, Bill Burke wrote: >>>>>> >>>>>> Are you using JPA user session storage? Everything but session data >>>>>> should be read-only unless some write operation snuck in >>>>>> >>>>>> Stack trace doesn't really help :( >>>>>> >>>>>> On 7/6/2015 10:42 AM, Scott Rossillo wrote: >>>>>>> Hi, >>>>>>> >>>>>>> We?re seeing MySQL deadlocks on requests to /realms/{realm-name}/protocol/openid-connect/token ranging from 8 to > 40 per day causing internal server errors. The thrown exception doesn?t really give enough information on what caused the deadlock. >>>>>>> >>>>>>> This is on 1.2.0. Any thoughts? Stack below. >>>>>>> >>>>>>> 2015-07-06 08:46:01,599 [ERROR] [default task-1] (LoggingExceptionHandler.java:handleThrowable:80) UT005023: Exception handling request to /auth/realms/xyz/protocol/openid-connect/token: java.lang.RuntimeException: request path: /auth/realms/xyz/protocol/openid-connect/token >>>>>>> at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:54) >>>>>>> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>>>> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>>>> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>>>> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>>>> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>>>> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) >>>>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>>>>> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>>>> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>>>>> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>>>>> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>>>> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>>>>> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>>>> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>>>>> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) >>>>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>>>>> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>>>>> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>>>> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>>>> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>>>> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] >>>>>>> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>>>>> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final] >>>>>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_79] >>>>>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_79] >>>>>>> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_79] >>>>>>> Caused by: org.keycloak.models.ModelException: javax.persistence.PersistenceException: org.hibernate.exception.LockAcquisitionException: could not execute statement >>>>>>> at org.keycloak.connections.jpa.PersistenceExceptionConverter.convert(PersistenceExceptionConverter.java:44) [keycloak-connections-jpa-1.2.Final.jar:1.2.0.Final] >>>>>>> at org.keycloak.connections.jpa.JpaKeycloakTransaction.commit(JpaKeycloakTransaction.java:30) [keycloak-connections-jpa-1.2.Final.jar:1.2.0.Final] >>>>>>> at org.keycloak.services.DefaultKeycloakTransactionManager.commit(DefaultKeycloakTransactionManager.java:55) [keycloak-services-1.2.Final.jar:1.2.0.Final] >>>>>>> at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:43) [keycloak-services-1.2.Final.jar:1.2.0.Final] >>>>>>> ... 28 more >>>>>>> Caused by: javax.persistence.PersistenceException: org.hibernate.exception.LockAcquisitionException: could not execute statement >>>>>>> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1763) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >>>>>>> at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1677) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >>>>>>> at org.hibernate.jpa.internal.TransactionImpl.commit(TransactionImpl.java:82) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >>>>>>> at org.keycloak.connections.jpa.JpaKeycloakTransaction.commit(JpaKeycloakTransaction.java:28) [keycloak-connections-jpa-1.2.Final.jar:1.2.0.Final] >>>>>>> ... 30 more >>>>>>> Caused by: org.hibernate.exception.LockAcquisitionException: could not execute statement >>>>>>> at org.hibernate.dialect.MySQLDialect$1.convert(MySQLDialect.java:451) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>>> at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>>> at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:126) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>>> at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:112) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>>> at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:211) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>>> at org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:62) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>>> at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:3281) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>>> at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:3183) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>>> at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:3525) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>>> at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:159) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>>> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:463) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>>> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:349) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>>> at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:350) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>>> at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:56) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>>> at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1222) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>>> at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:425) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>>> at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.beforeTransactionCommit(JdbcTransaction.java:101) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>>> at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(AbstractTransactionImpl.java:177) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>>> at org.hibernate.jpa.internal.TransactionImpl.commit(TransactionImpl.java:77) [hibernate-entitymanager-4.3.7.Final.jar:4.3.7.Final] >>>>>>> ... 31 more >>>>>>> Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction >>>>>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_79] >>>>>>> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_79] >>>>>>> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_79] >>>>>>> at java.lang.reflect.Constructor.newInstance(Constructor.java:526) [rt.jar:1.7.0_79] >>>>>>> at com.mysql.jdbc.Util.handleNewInstance(Util.java:389) >>>>>>> at com.mysql.jdbc.Util.getInstance(Util.java:372) >>>>>>> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:987) >>>>>>> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3835) >>>>>>> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3771) >>>>>>> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2435) >>>>>>> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2582) >>>>>>> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2535) >>>>>>> at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1911) >>>>>>> at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2145) >>>>>>> at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2081) >>>>>>> at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2066) >>>>>>> at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493) >>>>>>> at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:208) [hibernate-core-4.3.7.Final.jar:4.3.7.Final] >>>>>>> ... 45 more >>>>>>> _______________________________________________ >>>>>>> keycloak-dev mailing list >>>>>>> keycloak-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>> >>>>>> >>>>>> -- >>>>>> Bill Burke >>>>>> JBoss, a division of Red Hat >>>>>> http://bill.burkecentral.com >>>>>> _______________________________________________ >>>>>> keycloak-dev mailing list >>>>>> keycloak-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>> >>>> -- >>>> Bill Burke >>>> JBoss, a division of Red Hat >>>> http://bill.burkecentral.com >>> >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com From bburke at redhat.com Wed Jul 8 19:22:04 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 08 Jul 2015 19:22:04 -0400 Subject: [keycloak-dev] new directive Message-ID: <559DB09C.7080305@redhat.com> I added a new directive that can be driven by Identity Mapper config types, Protocol Maper config types, and Authenticator config types. Those forms now use this directive. As part of this directive, I improved on role input. There is a new "Role" property type. If you specify that in your property description, a "Select Role" button appear next to the role input text box. If you click that you get a dialog to select a role. We can expand on the directive in the future to add types like 'Client', 'Certificate', 'User', etc... -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Wed Jul 8 19:49:09 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 08 Jul 2015 19:49:09 -0400 Subject: [keycloak-dev] Registration flow, Form SPI, and Recaptcha Support Message-ID: <559DB6F5.4090502@redhat.com> Added registration flow. As part of this a new Form SPI was created. This Form SPI should only be used when you have a form that has optional parts. For example, a form might have password and otp on it, but you don't want to process otp unless it is enabled. The registration flow now has a Recaptcha option that is disabled by default. I don't know why, but I had trouble getting this to work all the time on Firefox. To enable Recaptcha you do have to muck with our Security Defenses headers i.e. Content-Security-Policy. All this is documented in docbook. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From mstrukel at redhat.com Thu Jul 9 09:57:31 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Thu, 9 Jul 2015 09:57:31 -0400 (EDT) Subject: [keycloak-dev] Using feature packs for custom distributions In-Reply-To: <858942467.16646940.1436450079823.JavaMail.zimbra@redhat.com> Message-ID: <1078508222.16648070.1436450251162.JavaMail.zimbra@redhat.com> For Keycloak we?ve been trying to create a trimmed down distribution of Keycloak server, basing it on servlet-feature-pack rather than full-feature-pack, since we don?t need many of the subsystems. We?ve encountered some issues though that made us step back and stick to using full-feature-pack as a basis for Keycloak server distribution. If we find a way to address these issues in the future we?ll reconsider, but for now we don?t see much sense in basing our Keycloak distribution on servlet-feature-pack. There are two big isues for us: 1) Big module dependency trees Our goal was to reduce the distribution size by reducing the number of subsystems, and modules shipped. We guessed that since we don?t use EJB, JMS, WS - but basically just JAX-RS and datasources, the resulting distribution based on servlet-feature-pack wouldn?t get a lot bigger than OOTB servlet-feature-pack. But it turns out that enabling virtually any additional subsystem - in our case we want to use datasources, which are provided by org.jboss.as.connector - that pulls in around 90Mb of non-optional dependencies. That?s a lot just to get datasources support. What?s interesting is that adding a different subsystem support e.g. org.jboss.as.jaxrs pulls in the same dependency tree - i.e. adding JAXRS support pulls in the same dependency tree as adding Datasources support - that?s how intertwined the dependencies currently are. Using servlet-feature-pack for distributions that require some additional subsystems from full-feature-set is thus not very effective to significantly reduce custom distribution?s disk footprint. There is a tool I wrote as part of my analysis that I used to analyze the size of dependency trees: https://github.com/mstruk/keycloak-moduletool 2) Staying in-sync with changes in full-feature-pack Creating a custom feature pack that is a subset of full-feature-pack requires copying module.xml files from wildfly/feature-pack source tree into custom feature pack source tree. Adding org.jboss.as.connector means copying over hundreds of modules (186 to be precise). As Wildfly development moves on, any changes to module.xml files have to be synced into the custom feature pack. That has the potential to be a huge maintenance burden, and a source of errors. One way to address this would be extended syntax somewhere in feature pack definition project to say something like: And that would replace copying over module directories, and module.xml files. And guarantee that things remain in-sync. For our use-case this would also be addressed by wildfly providing a feature-pack definition that?s somewhere between servlet-feature-pack and full-feature-pack - as long as it contains datasources support, and jaxrs support ... Another thing is provisioning of feature packs, which I address in another email. - marko From mstrukel at redhat.com Thu Jul 9 10:02:54 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Thu, 9 Jul 2015 10:02:54 -0400 (EDT) Subject: [keycloak-dev] Feature pack provisioning In-Reply-To: <1954322073.16648436.1436450303191.JavaMail.zimbra@redhat.com> Message-ID: <930099469.16650706.1436450574022.JavaMail.zimbra@redhat.com> Currently wildfly-server-provisioning-maven-plugin always generates a full Wildfly distribution. For Keycloak project we have three different cases of provisioning, and it would be great to be able to cover it with a common wildfly provided tool: 1) full server distribution 2) overlay distribution (unzip into existing OOTB Wildfly distribution - your problem if you use unsupported Wildfly version) 3) provision into existing Wildfly server detecting version mismatches, and configuring existing and additional subsystems for Keycloak to run properly. First one is what?s currently supported, and what we use. Second one is what we currently hack up by extracting modules directory from (1) - it would support this use case better if wildfly-server-provisioning-maven-plugin could generate 'modules only' for example. The third one requires a CLI installer tool. I?m not aware that currently there is something for that, and we are loath to develop one from scratch. Is it realistic to expect 2) and 3) in not so distant future? - marko From mposolda at redhat.com Thu Jul 9 17:14:14 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 09 Jul 2015 23:14:14 +0200 Subject: [keycloak-dev] Packaging of ApacheDS for examples? In-Reply-To: <1096643411.30773117.1435823808275.JavaMail.zimbra@redhat.com> References: <559295C9.3040409@redhat.com> <59203649.30748852.1435821196209.JavaMail.zimbra@redhat.com> <5594ECE4.4080103@redhat.com> <1096643411.30773117.1435823808275.JavaMail.zimbra@redhat.com> Message-ID: <559EE426.508@redhat.com> Yes, I've pushed the LDAP example and refactored the Kerberos example and LDAP example to use embedded ApacheDS LDAP server. I've added separate module "keycloak-util-embedded-ldap", which contains ApacheDS stuff for running embedded LDAP/Kerberos and is shared for both testsuite and examples. Embedded LDAP example downloads all the dependencies during build, so the size of example distribution is not an issue. Marek On 2.7.2015 09:56, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Marek Posolda" >> To: "Stian Thorgersen" >> Cc: keycloak-dev at lists.jboss.org >> Sent: Thursday, 2 July, 2015 9:48:52 AM >> Subject: Re: [keycloak-dev] Packaging of ApacheDS for examples? >> >> Thanks, I will investigate (c) then . >> >> It's more work than (a), which is no work >> >> Well, it won't be that hard to do, just afraid of all the dependencies >> required for ApacheDS . Which might cause that size of keycloak-examples >> will grow to be very big (in that case we may need separate example >> package with embedded ApacheDS LDAP/Kerberos to download). I will >> investigate sizes etc and will send update. > We don't package dependencies with the examples, only the source. So that shouldn't be a problem? > >> Marek >> >> On 2.7.2015 09:13, Stian Thorgersen wrote: >>> I don't like option a. Why is option c much more work? Doesn't seem like it >>> should be that hard. >>> >>> ----- Original Message ----- >>>> From: "Marek Posolda" >>>> To: keycloak-dev at lists.jboss.org >>>> Sent: Tuesday, 30 June, 2015 3:12:41 PM >>>> Subject: [keycloak-dev] Packaging of ApacheDS for examples? >>>> >>>> I am thinking about adding LDAP example, which can be used as a base for >>>> LDAP >>>> mappers based blog and screencast. >>>> >>>> It will contain the application to show some claims (also both >>>> singlevalued >>>> and multivalued attributes). It will also contain JSON realm with >>>> UserFederation configuration pointing to our ApacheDS and LDIF with some >>>> simple users for testing. I already added end-to-end test to the testsuite >>>> (LDAPMultipleAttributesTest.ldapPortalEndToEndTest ) >>>> >>>> >>>> The only possible problem is how to easily bootstrap ApacheDS based LDAP >>>> servers in user's environment. I am thinking about 3 approaches: >>>> >>>> a) Point to the embedded ApacheDS server from our testsuite. This will be >>>> easy to do and it's what Kerberos example is already doing . Problem is >>>> that >>>> it requires people to checkout the keycloak sources through github and >>>> build >>>> them through maven, so not very user friendly >>>> >>>> b) Create docker image for ApacheDS servers (one for ldap example and >>>> another >>>> for kerberos). Not sure if it's fine to require users to install docker >>>> (even more pain might be on windows, when they need boot2docker or >>>> something...) >>>> >>>> c) Packaging with ApacheDS based servers directly into our example >>>> package, >>>> so people can just run something like: >>>> >>>> java -jar keycloak-examples/ldap/apacheds-embedded.jar >>>> -Dldif.location=keycloak-examples/ldap/example.ldif >>>> >>>> and similarly for kerberos. >>>> >>>> For me it's easiest to go with (a) but not sure about usability... >>>> Regarding >>>> usability (c) looks best but it's much more work. >>>> >>>> WDYT? >>>> Marek >>>> >>>> >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From mposolda at redhat.com Thu Jul 9 17:27:57 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 09 Jul 2015 23:27:57 +0200 Subject: [keycloak-dev] Error on add user in ldap federation In-Reply-To: <05831e30366b19834d2d55e0bde3c23983cee78d@serpro.gov.br> References: <8e7a2ac31859128b0eb27d747bab1d37194c9cf7@serpro.gov.br> <3c99978c832525166a698ca5e2f5b907ceaf3f75@serpro.gov.br> <6f6760f8a31edd37a81a64ca9257d0e8e77911c0@serpro.gov.br> <923d680658a47a6bb80b6990d028ff59e8a5d3e7@serpro.gov.br> <05831e30366b19834d2d55e0bde3c23983cee78d@serpro.gov.br> Message-ID: <559EE75D.9050708@redhat.com> Hi, I think it should be fixed in latest master - or at least we will see the "real" exception instead of the exception thrown during reporting "real" exception :) Among LDAP fixes, I've also added the example application showing integration with LDAP. It's here: https://github.com/keycloak/keycloak/tree/master/examples/ldap If you have opportunity to try it you can build latest master with the commands like this (you need java7, maven 3.1 or later and git): $ git clone https://github.com/keycloak/keycloak.git $ cd keycloak $ mvn clean install -DskipTests=true $ cd distribution $ mvn clean install then in $KEYCLOAK_HOME/distribution/demo-dist/target/keycloak-demo-1.4.0.Final-SNAPSHOT.zip is latest demo distribution (which contains the example) and in $KEYCLOAK_HOME/distribution/server-dist/target/keycloak-1.4.0.Final-SNAPSHOT.zip is latest server distribution . Marek On 6.7.2015 16:16, Marcelo Arthur Sampaio wrote: > > Hi, > > I'm try to add user using LDAP federation, but get this error: > > 11:08:40,891 ERROR > [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth].[Keycloak > REST Interface]] (http-localhost/127.0.0.1:8080-6) JBWEB000236: > Servlet.service() for servlet Keycloak REST Interface threw > exception: java.lang.RuntimeException: request path: > /auth/admin/realms/demo/users > at > org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:54) > [keycloak-services-1.3.1.Final.jar:1.3.1.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.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.8.0_45] > *Caused by: java.lang.IllegalArgumentException: can't parse > argument number*: cn=teste > at java.text.MessageFormat.makeFormat(MessageFormat.java:1429) > [rt.jar:1.8.0_45] > at > java.text.MessageFormat.applyPattern(MessageFormat.java:479) > [rt.jar:1.8.0_45] > at java.text.MessageFormat.(MessageFormat.java:380) > [rt.jar:1.8.0_45] > at > org.keycloak.services.messages.AdminMessagesProvider.getMessage(AdminMessagesProvider.java:32) > [keycloak-services-1.3.1.Final.jar:1.3.1.Final] > at > org.keycloak.services.resources.ModelExceptionMapper.toResponse(ModelExceptionMapper.java:27) > [keycloak-services-1.3.1.Final.jar:1.3.1.Final] > at > org.keycloak.services.resources.ModelExceptionMapper.toResponse(ModelExceptionMapper.java:17) > [keycloak-services-1.3.1.Final.jar:1.3.1.Final] > at > org.jboss.resteasy.core.SynchronousDispatcher.executeExceptionMapper(SynchronousDispatcher.java:343) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at > org.jboss.resteasy.core.SynchronousDispatcher.unwrapException(SynchronousDispatcher.java:372) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at > org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:361) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at > org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:232) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at > org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:208) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at > org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:556) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:523) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at > org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) > [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:] > at > javax.servlet.http.HttpServlet.service(HttpServlet.java:847) > [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2] > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) > [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1] > at > org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41) > [keycloak-services-1.3.1.Final.jar:1.3.1.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.3.1.Final.jar:1.3.1.Final] > ... 13 more > *Caused by: java.lang.NumberFormatException: For input string: > *"cn=teste" > at > java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) > [rt.jar:1.8.0_45] > at java.lang.Integer.parseInt(Integer.java:580) [rt.jar:1.8.0_45] > at java.lang.Integer.parseInt(Integer.java:615) [rt.jar:1.8.0_45] > at java.text.MessageFormat.makeFormat(MessageFormat.java:1427) > [rt.jar:1.8.0_45] > ... 36 more > > > - > > > "Esta mensagem do SERVI?O FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), > empresa p?blica federal regida pelo disposto na Lei Federal n? 5.615, > ? enviada exclusivamente a seu destinat?rio e pode conter informa??es > confidenciais, protegidas por sigilo profissional. Sua utiliza??o > desautorizada ? ilegal e sujeita o infrator ?s penas da lei. Se voc? a > recebeu indevidamente, queira, por gentileza, reenvi?-la ao emitente, > esclarecendo o equ?voco." > > "This message from SERVI?O FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) > -- a government company established under Brazilian law (5.615/70) -- > is directed exclusively to its addressee and may contain confidential > data, protected under professional secrecy rules. Its unauthorized use > is illegal and may subject the transgressor to the law's penalties. If > you're not the addressee, please send it back, elucidating the failure." > > > _______________________________________________ > 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/20150709/cc8a4235/attachment-0001.html From marcelo.sampaio at serpro.gov.br Fri Jul 10 15:02:32 2015 From: marcelo.sampaio at serpro.gov.br (Marcelo Arthur Sampaio) Date: Fri, 10 Jul 2015 19:02:32 +0000 Subject: [keycloak-dev] Custom KeycloakPrincipal in adapter Message-ID: <639500c89e16e56726f24084401e2a8720a41028@serpro.gov.br> Hi, I need to implement my custom security Principal. What is the best way to do it in adapter for jboss eap. Create new adapter for my business extends RefreshableKeycloakSecurityContext, KeycloakAuthenticatorValve and set the new valve class in KeycloakAdapterConfigDeploymentProcessor? I need to set new attributes in principal and get principal in the SecurityContext. There is an other way? Thanks. - "Esta mensagem do SERVI?O FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa p?blica federal regida pelo disposto na Lei Federal n? 5.615, ? enviada exclusivamente a seu destinat?rio e pode conter informa??es confidenciais, protegidas por sigilo profissional. Sua utiliza??o desautorizada ? ilegal e sujeita o infrator ?s penas da lei. Se voc? a recebeu indevidamente, queira, por gentileza, reenvi?-la ao emitente, esclarecendo o equ?voco." "This message from SERVI?O FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) -- a government company established under Brazilian law (5.615/70) -- is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150710/0f9b55b3/attachment.html From bburke at redhat.com Fri Jul 10 21:34:30 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 10 Jul 2015 21:34:30 -0400 Subject: [keycloak-dev] user impersonation committed Message-ID: <55A072A6.6000607@redhat.com> Taking a break from auth flows for a fe and took a first stab at user impersonation. Go to: /auth/realms/{realm}/impersonate * There's a new "impersonation" role that is in the same "client" as view-realm, view-user, etc... roles Both in master realm apps and in the realm-management client. * The admin role as this "impersonation" role in its composite * After impersonation, you are redirected to Account applications page. "Master" impersonate service: * If you visit the "master" impersonate service of the master realm, you will have a list of of realms to choose from based on which "impersonation" roles the user has assigned to him * If you impersonate a user from "master" you are logged out and a new user session is created as the impersonated user. * If you impersonate a user that is within a different realm than "master", you are not logged out of master. Per realm impersonate service. * If you visit the impersonate service of another realm other than "master", you will not have a list of realms and will only be able to impersonate a user in that realm. * When you impersonate, you are logged out and a new user session is created for that user. Questions: * I implemented this similarly to the AccountService with a new "impersonation" client. It is a freemarker form at the moment (csrf protected)! I'm not 100% sure I can implement it within the admin console. Gonna look into that next. * Would it be useful to retain this freemarker form and impersonation client? Or should it only be available within the admin console? * What should it look like in the admin console? Just an "impersonate" button on the User Detail page? -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From srossillo at smartling.com Fri Jul 10 21:54:22 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Fri, 10 Jul 2015 21:54:22 -0400 Subject: [keycloak-dev] Git History w/merges of upstream/master Message-ID: <18172C9C-E1B4-48ED-8E1A-9B2B8D927EA3@smartling.com> Not the biggest deal, but always see commits like: "Merge remote-tracking branch 'upstream/master? commits" If you `git pull ?rebase` you can avoid these and the project history will be a lot cleaner. ~ Scott From srossillo at smartling.com Fri Jul 10 22:04:45 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Fri, 10 Jul 2015 22:04:45 -0400 Subject: [keycloak-dev] user impersonation committed In-Reply-To: <55A072A6.6000607@redhat.com> References: <55A072A6.6000607@redhat.com> Message-ID: A few things: 1. Impersonation should be available via an admin endpoint. If I have the impersonation role, I should be able to make a call to impersonate another user. 2. It should be availabe in the admin console on the user details page and the list. I don?t think it makes sense to have to click into the user if you already found them in search results, etc. 3. What happens when user X decides to impersonate user Y and user X is already authenticated to clients? How does the impersonation for user X of user Y get propagated to clients? What happens on logout? > On Jul 10, 2015, at 9:34 PM, Bill Burke wrote: > > Taking a break from auth flows for a fe and took a first stab at user > impersonation. > > Go to: > > /auth/realms/{realm}/impersonate > > > * There's a new "impersonation" role that is in the same "client" as > view-realm, view-user, etc... roles Both in master realm apps and in > the realm-management client. > * The admin role as this "impersonation" role in its composite > * After impersonation, you are redirected to Account applications page. > > "Master" impersonate service: > > * If you visit the "master" impersonate service of the master realm, you > will have a list of of realms to choose from based on which > "impersonation" roles the user has assigned to him > * If you impersonate a user from "master" you are logged out and a new > user session is created as the impersonated user. > * If you impersonate a user that is within a different realm than > "master", you are not logged out of master. > > Per realm impersonate service. > * If you visit the impersonate service of another realm other than > "master", you will not have a list of realms and will only be able to > impersonate a user in that realm. > * When you impersonate, you are logged out and a new user session is > created for that user. > > > Questions: > * I implemented this similarly to the AccountService with a new > "impersonation" client. It is a freemarker form at the moment (csrf > protected)! I'm not 100% sure I can implement it within the admin > console. Gonna look into that next. > * Would it be useful to retain this freemarker form and impersonation > client? Or should it only be available within the admin console? > * What should it look like in the admin console? Just an "impersonate" > button on the User Detail page? > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Fri Jul 10 22:43:49 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 10 Jul 2015 22:43:49 -0400 Subject: [keycloak-dev] user impersonation committed In-Reply-To: References: <55A072A6.6000607@redhat.com> Message-ID: <55A082E5.9080309@redhat.com> On 7/10/2015 10:04 PM, Scott Rossillo wrote: > > A few things: > > 1. Impersonation should be available via an admin endpoint. If I have the impersonation role, I should be able to make a call to impersonate another user. I've only implemented browser impersonation (cookies). There is no token exchange at the moment. > 2. It should be availabe in the admin console on the user details page and the list. I don?t think it makes sense to have to click into the user if you already found them in search results, etc. Ok. > 3. What happens when user X decides to impersonate user Y and user X is already authenticated to clients? How does the impersonation for user X of user Y get propagated to clients? What happens on logout? > If User X and User Y are in the same realm, then User X will first be logged out (and a backchannel logout performed on all clients), then logged in as User Y. The plan is to redirect to the Account Applications page. If User X and User Y are in different realms, then User X stays logged in. I'm thinking that a new tab would be opened that is redirected to Account Applications page. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From mposolda at redhat.com Sat Jul 11 04:59:55 2015 From: mposolda at redhat.com (Marek Posolda) Date: Sat, 11 Jul 2015 10:59:55 +0200 Subject: [keycloak-dev] Custom KeycloakPrincipal in adapter In-Reply-To: <639500c89e16e56726f24084401e2a8720a41028@serpro.gov.br> References: <639500c89e16e56726f24084401e2a8720a41028@serpro.gov.br> Message-ID: <55A0DB0B.2060305@redhat.com> Not sure why you need this. But maybe easiest is to create just Http Servlet filter (this can be configured in web.xml and doesn't use any tomcat/jboss-web specific stuff) . In this filter, you will create HttpServletRequestWrapper wrapping the original HttpServletRequest, but you will override just the method "getUserPrincipal" in your wrapper class. Here you can do any hacking you want and return any principal instance you want. All the data from Keycloak (KeycloakSecurityContext, AccessToken, IDToken, original KeycloakPrincipal...) are already available in the filter, so you can use them for create your own principal. Marek On 10.7.2015 21:02, Marcelo Arthur Sampaio wrote: > Hi, > > I need to implement my custom security Principal. > What is the best way to do it in adapter for jboss eap. > > Create new adapter for my business extends > RefreshableKeycloakSecurityContext, KeycloakAuthenticatorValve and set > the new valve class in KeycloakAdapterConfigDeploymentProcessor? > > I need to set new attributes in principal and get principal in the > SecurityContext. > > There is an other way? > > Thanks. > - > > > "Esta mensagem do SERVI?O FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), > empresa p?blica federal regida pelo disposto na Lei Federal n? 5.615, > ? enviada exclusivamente a seu destinat?rio e pode conter informa??es > confidenciais, protegidas por sigilo profissional. Sua utiliza??o > desautorizada ? ilegal e sujeita o infrator ?s penas da lei. Se voc? a > recebeu indevidamente, queira, por gentileza, reenvi?-la ao emitente, > esclarecendo o equ?voco." > > "This message from SERVI?O FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) > -- a government company established under Brazilian law (5.615/70) -- > is directed exclusively to its addressee and may contain confidential > data, protected under professional secrecy rules. Its unauthorized use > is illegal and may subject the transgressor to the law's penalties. If > you're not the addressee, please send it back, elucidating the failure." > > > _______________________________________________ > 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/20150711/7eddb2f3/attachment.html From mposolda at redhat.com Sat Jul 11 05:06:25 2015 From: mposolda at redhat.com (Marek Posolda) Date: Sat, 11 Jul 2015 11:06:25 +0200 Subject: [keycloak-dev] Git History w/merges of upstream/master In-Reply-To: <18172C9C-E1B4-48ED-8E1A-9B2B8D927EA3@smartling.com> References: <18172C9C-E1B4-48ED-8E1A-9B2B8D927EA3@smartling.com> Message-ID: <55A0DC91.2060905@redhat.com> I don't have strong opinion on it. I am personally always doing rebase before sending PR to the master. And I agree that rebase is cleaner than merge. But unfortunately if you want to merge pull requests automatically on github (Clicking on button "Merge pull request" ), github will always merge the PR, not rebase. For the really linear commit history, we will need to avoid merging PRs in the github UI, which is more work for the person, who is merging the PR... Marek On 11.7.2015 03:54, Scott Rossillo wrote: > Not the biggest deal, but always see commits like: > > "Merge remote-tracking branch 'upstream/master? commits" > > If you `git pull ?rebase` you can avoid these and the project history will be a lot cleaner. > > ~ Scott > > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From srossillo at smartling.com Sat Jul 11 08:40:52 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Sat, 11 Jul 2015 12:40:52 +0000 Subject: [keycloak-dev] Git History w/merges of upstream/master In-Reply-To: <55A0DC91.2060905@redhat.com> References: <18172C9C-E1B4-48ED-8E1A-9B2B8D927EA3@smartling.com> <55A0DC91.2060905@redhat.com> Message-ID: Not a problem with PRs. I'd just say rebase before sending w PR rather than merging upstream/master. I was just suggesting anyway. Not a real issue. On Sat, Jul 11, 2015 at 5:06 AM Marek Posolda wrote: > I don't have strong opinion on it. I am personally always doing rebase > before sending PR to the master. And I agree that rebase is cleaner than > merge. > > But unfortunately if you want to merge pull requests automatically on > github (Clicking on button "Merge pull request" ), github will always > merge the PR, not rebase. For the really linear commit history, we will > need to avoid merging PRs in the github UI, which is more work for the > person, who is merging the PR... > > Marek > > On 11.7.2015 03:54, Scott Rossillo wrote: > > Not the biggest deal, but always see commits like: > > > > "Merge remote-tracking branch 'upstream/master? commits" > > > > If you `git pull ?rebase` you can avoid these and the project history > will be a lot cleaner. > > > > ~ 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/20150711/13010f95/attachment.html From bburke at redhat.com Sat Jul 11 11:38:45 2015 From: bburke at redhat.com (Bill Burke) Date: Sat, 11 Jul 2015 11:38:45 -0400 Subject: [keycloak-dev] user impersonation part II Message-ID: <55A13885.60405@redhat.com> Ok, I ditched the "impersonation" client and now impersonate is done through the admin console. There is a "Impersonate" button in the user-list screen next to each user, then there is an Impersonate button on the user detail page. If the user is in the same realm as the admin, the admin is logged out and the browser is redirected to Account.applications page. If the user is not in the same realm as the admin, a new browser tab is popped open and displays the Account.applications page. I still need to do admin events for this, then I'm done. Bill -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From mposolda at redhat.com Sat Jul 11 17:34:47 2015 From: mposolda at redhat.com (Marek Posolda) Date: Sat, 11 Jul 2015 23:34:47 +0200 Subject: [keycloak-dev] new directive In-Reply-To: <559DB09C.7080305@redhat.com> References: <559DB09C.7080305@redhat.com> Message-ID: <55A18BF7.4090608@redhat.com> Great, I've refactored federation mappers to use this directive as well and added ClientList type to the directive. ClientList is just combobox containing list of the clients and allow to select one of them. It's used actually by Role LDAP mapper. Not sure if it should be renamed to 'Client' instead of 'ClientList' ? Or do you mean something different by the type 'Client' ? Marek On 9.7.2015 01:22, Bill Burke wrote: > I added a new directive that can be driven by > Identity Mapper config types, Protocol Maper config types, and > Authenticator config types. Those forms now use this directive. > > As part of this directive, I improved on role input. There is a new > "Role" property type. If you specify that in your property description, > a "Select Role" button appear next to the role input text box. If you > click that you get a dialog to select a role. > > We can expand on the directive in the future to add > types like 'Client', 'Certificate', 'User', etc... > From velias at redhat.com Mon Jul 13 08:55:48 2015 From: velias at redhat.com (Vlastimil Elias) Date: Mon, 13 Jul 2015 14:55:48 +0200 Subject: [keycloak-dev] Extend informations shown on Server Info page Message-ID: <55A3B554.30702@redhat.com> Hi, we just discussed this topic with Stian on https://issues.jboss.org/browse/KEYCLOAK-1542 and we are not sure if it is worth to do or not so we should ask other KC devs for their opinion. Server Info page contains, beside Providers info, only keycloak version and server time. It should be good for real management/operations (based on my few year's experience with jboss.org JIRA, SSO and other system's operation) to extend it with other informations like: * server uptime * version, vendor and variant of jre used to run it * basic info about OS (type, version) * info about OS user KC runs under * info about locale nad timezone used for JVM * JVM memory statistics (total and free heap mem, perm gen mem) * basic info about DB in case of JPA (JDBC url, JDBC driver type and version, DB type and version) or info about used mongo (version etc) This page should contain this info for all cluster nodes in clustered environment. Stian objected that this info is available form EAP/WF console, but I think it is a bit problematic for common KC admin to access it there as it is not integrated with KC console. WDYT? Thanks in advance Vl. -- Vlastimil Elias Principal Software Engineer jboss.org Development Team -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150713/bbd9fe25/attachment.html From stian at redhat.com Mon Jul 13 09:13:39 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 13 Jul 2015 09:13:39 -0400 (EDT) Subject: [keycloak-dev] [wildfly-dev] Using feature packs for custom distributions In-Reply-To: References: <1078508222.16648070.1436450251162.JavaMail.zimbra@redhat.com> Message-ID: <2136328166.37140516.1436793219178.JavaMail.zimbra@redhat.com> As I see it the main issue with using core or servlets is the fact that we have to redefine modules. Currently AFAIK when pulling in a feature pack you end up pulling in all modules for that feature pack even if you disable subsystems/extensions that rely on those modules. Would it not be better to have individual subsystems define what modules they require and only pull in the required modules for the enabled subsystems/extensions? That would allow us to build on WF full and get all module definitions from there, while still reducing the size of our distribution. ----- Original Message ----- > From: "Toma? Cerar" > To: "Jason Greene" > Cc: wildfly-dev at lists.jboss.org, "keycloak dev" > Sent: Monday, 13 July, 2015 2:53:26 PM > Subject: Re: [wildfly-dev] Using feature packs for custom distributions > > > On Thu, Jul 9, 2015 at 5:13 PM, Jason Greene < jason.greene at redhat.com > > wrote: > > > > > For our use-case this would also be addressed by wildfly providing a > > feature-pack definition that?s somewhere between servlet-feature-pack and > > full-feature-pack - as long as it contains datasources support, and jaxrs > > support ? > > I think this is a good idea, to skip optional deps. > > > Should we add another feature pack "wildfly-web" that would be near EE web > profile? > We could only have feature pack without corresponding distribution. > This would allow downstream projects like keycloak to easier build custom > distribution using such feature pack. > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From velias at redhat.com Mon Jul 13 09:17:16 2015 From: velias at redhat.com (Vlastimil Elias) Date: Mon, 13 Jul 2015 15:17:16 +0200 Subject: [keycloak-dev] Operational monitoring of Keycloak server Message-ID: <55A3BA5C.2090906@redhat.com> Hi, as we deployed KC to production mode for https://developers.redhat.com we started to think about operational monitoring, for example from Nagios or other systems of this type. KC user guide doesn't contain any chapter covering this topic, also no any success over google search, so looks like KC doesn't have any solution for this yet. But I believe this is an important area which must be solved when KC is used for production. I can imagine monitoring of JDBC connection if JPA is used, monitoring of Mongo connection if used as store, monitoring of LDAP connection if LDAP federation is used etc. Also some statistics like numbers of active sso session, number of logins per minute etc should be provided there. Monitoring is not about Keycloak core itself, it should be available for extension developers also. For example we implemented own UserFederationProvider which calls backend REST services. We should be able to add info about this integration into monitoring endpoint to be able to catch problems with this REST API. It should be probably implemented same way as used by underlying WildFly/EAP (JPA/JDBC is probably available for monitoring there). I'm not sure if JMX is used there still or if some new framework is available for it. Or KC should use some form of KC REST API for this, which should be extended by additional info from KC extensions? What do you think? Vlastimil P.S we have https://issues.jboss.org/browse/RHD-552 for Red Hat Developer instance of KC -- Vlastimil Elias Principal Software Engineer jboss.org Development Team From stian at redhat.com Mon Jul 13 09:26:08 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 13 Jul 2015 09:26:08 -0400 (EDT) Subject: [keycloak-dev] Operational monitoring of Keycloak server In-Reply-To: <55A3BA5C.2090906@redhat.com> References: <55A3BA5C.2090906@redhat.com> Message-ID: <1307572132.37149706.1436793968827.JavaMail.zimbra@redhat.com> In WildFly/EAP that's DMR right? We're planning to make Keycloak managable through that as well. For example everything that goes into keycloak-server.json will eventually be moved to standalone.xml. Same with admin endpoints, everything you can do there you'll eventually be able to do through DMR and jboss-cli as well. However, IMO it would make sense to at least expose Keycloak specific information through the admin endpoints and console as well. Such number of sessions, etc.. ----- Original Message ----- > From: "Vlastimil Elias" > To: keycloak-dev at lists.jboss.org > Sent: Monday, 13 July, 2015 3:17:16 PM > Subject: [keycloak-dev] Operational monitoring of Keycloak server > > Hi, > > as we deployed KC to production mode for https://developers.redhat.com > we started to think about operational monitoring, for example from > Nagios or other systems of this type. > > KC user guide doesn't contain any chapter covering this topic, also no > any success over google search, so looks like KC doesn't have any > solution for this yet. > But I believe this is an important area which must be solved when KC is > used for production. > > I can imagine monitoring of JDBC connection if JPA is used, monitoring > of Mongo connection if used as store, monitoring of LDAP connection if > LDAP federation is used etc. > Also some statistics like numbers of active sso session, number of > logins per minute etc should be provided there. > > Monitoring is not about Keycloak core itself, it should be available for > extension developers also. For example we implemented own > UserFederationProvider which calls backend REST services. > We should be able to add info about this integration into monitoring > endpoint to be able to catch problems with this REST API. > > It should be probably implemented same way as used by underlying > WildFly/EAP (JPA/JDBC is probably available for monitoring there). I'm > not sure if JMX is used there still or if some new framework is > available for it. > Or KC should use some form of KC REST API for this, which should be > extended by additional info from KC extensions? > > What do you think? > > Vlastimil > > P.S we have https://issues.jboss.org/browse/RHD-552 for Red Hat > Developer instance of KC > > -- > 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 stian at redhat.com Mon Jul 13 10:34:13 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 13 Jul 2015 10:34:13 -0400 (EDT) Subject: [keycloak-dev] [wildfly-dev] Including Keycloak client adapters in WildFly 10 In-Reply-To: <1A8F606B-E548-4FD3-979E-819686D84922@redhat.com> References: <2083988224.31710463.1435923649086.JavaMail.zimbra@redhat.com> <1A8F606B-E548-4FD3-979E-819686D84922@redhat.com> Message-ID: <1019697788.37197427.1436798053853.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Jason Greene" > To: "Stian Thorgersen" > Cc: "keycloak dev" , wildfly-dev at lists.jboss.org > Sent: Tuesday, 7 July, 2015 11:19:52 PM > Subject: Re: [wildfly-dev] Including Keycloak client adapters in WildFly 10 > > > > On Jul 3, 2015, at 6:40 AM, Stian Thorgersen wrote: > > > > Keycloak provides an adapter, including a WildFly extensions, to make it > > easier to add authentication to JavaEE applications with Keycloak. > > Sorry for my delay replying. Comments are inline: > > > > > It includes a few modules. Currently 8 Keycloak specific modules and one 1 > > third-party. The third-party is net.iharder.base64. > > We already have many Base64 implementations. It?s pretty easy to pull one in > with cut and paste. Java 8 also provides one, so that could be used. We can copy/paste it, but would it not be better to include one Base64 lib in WildFly than have everyone have their own? > > > > > As the WildFly extensions includes a deployment processor that configures > > the authentication method as well as dependencies for a deployment it's > > easy to add authentication to a JavaEE application. All you need to do is > > specify it in standalone.xml, for example: > > > > ... > > 675356d8-2b6b-4602-a74f-7079e0555885 > > You probably already did this, but such an attribute should support vault > usage as well so that credentials can be kept out of configs. No, pretty sure we don't, but we should > > > > > ... > > > > I'd like to explore if we can add this extension and the required modules > > directly to WildFly 10, rather than require users to add it themselves. > > Can you sync up with the elytron team? They are making other changes in this > area, which are not yet in 10, and I want to make sure thats all compatible. Will do, we need to have a sync with them asap in either case to make sure the Elytron SPIs cover all use-cases we need. > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From stian at redhat.com Mon Jul 13 10:58:50 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 13 Jul 2015 10:58:50 -0400 (EDT) Subject: [keycloak-dev] Extend informations shown on Server Info page In-Reply-To: <55A3B554.30702@redhat.com> References: <55A3B554.30702@redhat.com> Message-ID: <579352747.37221548.1436799530647.JavaMail.zimbra@redhat.com> +1 To add it ----- Original Message ----- > From: "Vlastimil Elias" > To: keycloak-dev at lists.jboss.org > Sent: Monday, 13 July, 2015 2:55:48 PM > Subject: [keycloak-dev] Extend informations shown on Server Info page > > Hi, > > we just discussed this topic with Stian on > https://issues.jboss.org/browse/KEYCLOAK-1542 and we are not sure if it is > worth to do or not so we should ask other KC devs for their opinion. > Server Info page contains, beside Providers info, only keycloak version and > server time. It should be good for real management/operations (based on my > few year's experience with jboss.org JIRA, SSO and other system's operation) > to extend it with other informations like: > > > * server uptime > * version, vendor and variant of jre used to run it > * basic info about OS (type, version) > * info about OS user KC runs under > * info about locale nad timezone used for JVM > * JVM memory statistics (total and free heap mem, perm gen mem) > * basic info about DB in case of JPA (JDBC url, JDBC driver type and > version, DB type and version) or info about used mongo (version etc) > > > This page should contain this info for all cluster nodes in clustered > environment. > Stian objected that this info is available form EAP/WF console, but I think > it is a bit problematic for common KC admin to access it there as it is not > integrated with KC console. > > WDYT? > > Thanks in advance > > Vl. > -- > Vlastimil Elias > Principal Software Engineer > jboss.org Development Team > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From velias at redhat.com Mon Jul 13 11:06:34 2015 From: velias at redhat.com (Vlastimil Elias) Date: Mon, 13 Jul 2015 17:06:34 +0200 Subject: [keycloak-dev] Operational monitoring of Keycloak server In-Reply-To: <1307572132.37149706.1436793968827.JavaMail.zimbra@redhat.com> References: <55A3BA5C.2090906@redhat.com> <1307572132.37149706.1436793968827.JavaMail.zimbra@redhat.com> Message-ID: <55A3D3FA.9000600@redhat.com> Looks like I have to look at WildFly/EAP DMR to see what is possible to do with it, as I'm not sure if it is about remote monitoring also and if/how it can be use from monitoring systems like Splunk. Vl. On 13.7.2015 15:26, Stian Thorgersen wrote: > In WildFly/EAP that's DMR right? We're planning to make Keycloak managable through that as well. For example everything that goes into keycloak-server.json will eventually be moved to standalone.xml. Same with admin endpoints, everything you can do there you'll eventually be able to do through DMR and jboss-cli as well. > > However, IMO it would make sense to at least expose Keycloak specific information through the admin endpoints and console as well. Such number of sessions, etc.. > > ----- Original Message ----- >> From: "Vlastimil Elias" >> To: keycloak-dev at lists.jboss.org >> Sent: Monday, 13 July, 2015 3:17:16 PM >> Subject: [keycloak-dev] Operational monitoring of Keycloak server >> >> Hi, >> >> as we deployed KC to production mode for https://developers.redhat.com >> we started to think about operational monitoring, for example from >> Nagios or other systems of this type. >> >> KC user guide doesn't contain any chapter covering this topic, also no >> any success over google search, so looks like KC doesn't have any >> solution for this yet. >> But I believe this is an important area which must be solved when KC is >> used for production. >> >> I can imagine monitoring of JDBC connection if JPA is used, monitoring >> of Mongo connection if used as store, monitoring of LDAP connection if >> LDAP federation is used etc. >> Also some statistics like numbers of active sso session, number of >> logins per minute etc should be provided there. >> >> Monitoring is not about Keycloak core itself, it should be available for >> extension developers also. For example we implemented own >> UserFederationProvider which calls backend REST services. >> We should be able to add info about this integration into monitoring >> endpoint to be able to catch problems with this REST API. >> >> It should be probably implemented same way as used by underlying >> WildFly/EAP (JPA/JDBC is probably available for monitoring there). I'm >> not sure if JMX is used there still or if some new framework is >> available for it. >> Or KC should use some form of KC REST API for this, which should be >> extended by additional info from KC extensions? >> >> What do you think? >> >> Vlastimil >> >> P.S we have https://issues.jboss.org/browse/RHD-552 for Red Hat >> Developer instance of KC >> >> -- >> Vlastimil Elias >> Principal Software Engineer >> jboss.org Development Team >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> -- Vlastimil Elias Principal Software Engineer jboss.org Development Team From bburke at redhat.com Mon Jul 13 11:08:42 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 13 Jul 2015 11:08:42 -0400 Subject: [keycloak-dev] Extend informations shown on Server Info page In-Reply-To: <579352747.37221548.1436799530647.JavaMail.zimbra@redhat.com> References: <55A3B554.30702@redhat.com> <579352747.37221548.1436799530647.JavaMail.zimbra@redhat.com> Message-ID: <55A3D47A.10700@redhat.com> Yeah +1. Who cares if it is already in WF. Its not like you're duplicating anything that complicated. On 7/13/2015 10:58 AM, Stian Thorgersen wrote: > +1 To add it > > ----- Original Message ----- >> From: "Vlastimil Elias" >> To: keycloak-dev at lists.jboss.org >> Sent: Monday, 13 July, 2015 2:55:48 PM >> Subject: [keycloak-dev] Extend informations shown on Server Info page >> >> Hi, >> >> we just discussed this topic with Stian on >> https://issues.jboss.org/browse/KEYCLOAK-1542 and we are not sure if it is >> worth to do or not so we should ask other KC devs for their opinion. >> Server Info page contains, beside Providers info, only keycloak version and >> server time. It should be good for real management/operations (based on my >> few year's experience with jboss.org JIRA, SSO and other system's operation) >> to extend it with other informations like: >> >> >> * server uptime >> * version, vendor and variant of jre used to run it >> * basic info about OS (type, version) >> * info about OS user KC runs under >> * info about locale nad timezone used for JVM >> * JVM memory statistics (total and free heap mem, perm gen mem) >> * basic info about DB in case of JPA (JDBC url, JDBC driver type and >> version, DB type and version) or info about used mongo (version etc) >> >> >> This page should contain this info for all cluster nodes in clustered >> environment. >> Stian objected that this info is available form EAP/WF console, but I think >> it is a bit problematic for common KC admin to access it there as it is not >> integrated with KC console. >> >> WDYT? >> >> Thanks in advance >> >> Vl. >> -- >> 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 > _______________________________________________ > 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 Mon Jul 13 11:18:19 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 13 Jul 2015 11:18:19 -0400 (EDT) Subject: [keycloak-dev] Operational monitoring of Keycloak server In-Reply-To: <55A3D3FA.9000600@redhat.com> References: <55A3BA5C.2090906@redhat.com> <1307572132.37149706.1436793968827.JavaMail.zimbra@redhat.com> <55A3D3FA.9000600@redhat.com> Message-ID: <299925009.37235169.1436800699765.JavaMail.zimbra@redhat.com> So looks like we're at agreement to add the additional info you wanted to server info page. How about we add an additional endpoint server-stat that can collect some stats about the server? ----- Original Message ----- > From: "Vlastimil Elias" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Monday, 13 July, 2015 5:06:34 PM > Subject: Re: [keycloak-dev] Operational monitoring of Keycloak server > > Looks like I have to look at WildFly/EAP DMR to see what is possible to > do with it, as I'm not sure if it is about remote monitoring also and > if/how it can be use from monitoring systems like Splunk. > > Vl. > > On 13.7.2015 15:26, Stian Thorgersen wrote: > > In WildFly/EAP that's DMR right? We're planning to make Keycloak managable > > through that as well. For example everything that goes into > > keycloak-server.json will eventually be moved to standalone.xml. Same with > > admin endpoints, everything you can do there you'll eventually be able to > > do through DMR and jboss-cli as well. > > > > However, IMO it would make sense to at least expose Keycloak specific > > information through the admin endpoints and console as well. Such number > > of sessions, etc.. > > > > ----- Original Message ----- > >> From: "Vlastimil Elias" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Monday, 13 July, 2015 3:17:16 PM > >> Subject: [keycloak-dev] Operational monitoring of Keycloak server > >> > >> Hi, > >> > >> as we deployed KC to production mode for https://developers.redhat.com > >> we started to think about operational monitoring, for example from > >> Nagios or other systems of this type. > >> > >> KC user guide doesn't contain any chapter covering this topic, also no > >> any success over google search, so looks like KC doesn't have any > >> solution for this yet. > >> But I believe this is an important area which must be solved when KC is > >> used for production. > >> > >> I can imagine monitoring of JDBC connection if JPA is used, monitoring > >> of Mongo connection if used as store, monitoring of LDAP connection if > >> LDAP federation is used etc. > >> Also some statistics like numbers of active sso session, number of > >> logins per minute etc should be provided there. > >> > >> Monitoring is not about Keycloak core itself, it should be available for > >> extension developers also. For example we implemented own > >> UserFederationProvider which calls backend REST services. > >> We should be able to add info about this integration into monitoring > >> endpoint to be able to catch problems with this REST API. > >> > >> It should be probably implemented same way as used by underlying > >> WildFly/EAP (JPA/JDBC is probably available for monitoring there). I'm > >> not sure if JMX is used there still or if some new framework is > >> available for it. > >> Or KC should use some form of KC REST API for this, which should be > >> extended by additional info from KC extensions? > >> > >> What do you think? > >> > >> Vlastimil > >> > >> P.S we have https://issues.jboss.org/browse/RHD-552 for Red Hat > >> Developer instance of KC > >> > >> -- > >> 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 ssilvert at redhat.com Mon Jul 13 11:33:47 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Mon, 13 Jul 2015 11:33:47 -0400 Subject: [keycloak-dev] Extend informations shown on Server Info page In-Reply-To: <55A3D47A.10700@redhat.com> References: <55A3B554.30702@redhat.com> <579352747.37221548.1436799530647.JavaMail.zimbra@redhat.com> <55A3D47A.10700@redhat.com> Message-ID: <55A3DA5B.7030109@redhat.com> On 7/13/2015 11:08 AM, Bill Burke wrote: > Yeah +1. Who cares if it is already in WF. Its not like you're > duplicating anything that complicated. Yes, this kind of stuff is meant to be duplicated. Anything exposed as DMR is already accessible from multiple management clients including CLI, CLI GUI, Web Console, jconsole, JON, etc. Much of it is also exposed as JMX, which in this case wraps DMR. We do need to make sure that any new runtime stats are exposed as DMR. That way, any WildFly/EAP tool can consume it. > > On 7/13/2015 10:58 AM, Stian Thorgersen wrote: >> +1 To add it >> >> ----- Original Message ----- >>> From: "Vlastimil Elias" >>> To: keycloak-dev at lists.jboss.org >>> Sent: Monday, 13 July, 2015 2:55:48 PM >>> Subject: [keycloak-dev] Extend informations shown on Server Info page >>> >>> Hi, >>> >>> we just discussed this topic with Stian on >>> https://issues.jboss.org/browse/KEYCLOAK-1542 and we are not sure if it is >>> worth to do or not so we should ask other KC devs for their opinion. >>> Server Info page contains, beside Providers info, only keycloak version and >>> server time. It should be good for real management/operations (based on my >>> few year's experience with jboss.org JIRA, SSO and other system's operation) >>> to extend it with other informations like: >>> >>> >>> * server uptime >>> * version, vendor and variant of jre used to run it >>> * basic info about OS (type, version) >>> * info about OS user KC runs under >>> * info about locale nad timezone used for JVM >>> * JVM memory statistics (total and free heap mem, perm gen mem) >>> * basic info about DB in case of JPA (JDBC url, JDBC driver type and >>> version, DB type and version) or info about used mongo (version etc) >>> >>> >>> This page should contain this info for all cluster nodes in clustered >>> environment. >>> Stian objected that this info is available form EAP/WF console, but I think >>> it is a bit problematic for common KC admin to access it there as it is not >>> integrated with KC console. >>> >>> WDYT? >>> >>> Thanks in advance >>> >>> Vl. >>> -- >>> 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 >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> From mposolda at redhat.com Mon Jul 13 14:35:09 2015 From: mposolda at redhat.com (Marek Posolda) Date: Mon, 13 Jul 2015 20:35:09 +0200 Subject: [keycloak-dev] Extend informations shown on Server Info page In-Reply-To: <55A3DA5B.7030109@redhat.com> References: <55A3B554.30702@redhat.com> <579352747.37221548.1436799530647.JavaMail.zimbra@redhat.com> <55A3D47A.10700@redhat.com> <55A3DA5B.7030109@redhat.com> Message-ID: <55A404DD.7020804@redhat.com> +1 to add it as well. I wonder if we should create service to return all this info, so we can use it in more places? For example we can display the info in server.log at startup (even if it duplicates some wildfly logged info) and also display it in stacktrace when some exception happen. This might help support team to save some pain (they won't need to ask people about JVM, OS, database, configured providers etc as everything will be in the stacktrace attached to the support ticket) Marek On 13.7.2015 17:33, Stan Silvert wrote: > On 7/13/2015 11:08 AM, Bill Burke wrote: >> Yeah +1. Who cares if it is already in WF. Its not like you're >> duplicating anything that complicated. > Yes, this kind of stuff is meant to be duplicated. Anything exposed as > DMR is already accessible from multiple management clients including > CLI, CLI GUI, Web Console, jconsole, JON, etc. Much of it is also > exposed as JMX, which in this case wraps DMR. > > We do need to make sure that any new runtime stats are exposed as DMR. > That way, any WildFly/EAP tool can consume it. >> On 7/13/2015 10:58 AM, Stian Thorgersen wrote: >>> +1 To add it >>> >>> ----- Original Message ----- >>>> From: "Vlastimil Elias" >>>> To: keycloak-dev at lists.jboss.org >>>> Sent: Monday, 13 July, 2015 2:55:48 PM >>>> Subject: [keycloak-dev] Extend informations shown on Server Info page >>>> >>>> Hi, >>>> >>>> we just discussed this topic with Stian on >>>> https://issues.jboss.org/browse/KEYCLOAK-1542 and we are not sure if it is >>>> worth to do or not so we should ask other KC devs for their opinion. >>>> Server Info page contains, beside Providers info, only keycloak version and >>>> server time. It should be good for real management/operations (based on my >>>> few year's experience with jboss.org JIRA, SSO and other system's operation) >>>> to extend it with other informations like: >>>> >>>> >>>> * server uptime >>>> * version, vendor and variant of jre used to run it >>>> * basic info about OS (type, version) >>>> * info about OS user KC runs under >>>> * info about locale nad timezone used for JVM >>>> * JVM memory statistics (total and free heap mem, perm gen mem) >>>> * basic info about DB in case of JPA (JDBC url, JDBC driver type and >>>> version, DB type and version) or info about used mongo (version etc) >>>> >>>> >>>> This page should contain this info for all cluster nodes in clustered >>>> environment. >>>> Stian objected that this info is available form EAP/WF console, but I think >>>> it is a bit problematic for common KC admin to access it there as it is not >>>> integrated with KC console. >>>> >>>> WDYT? >>>> >>>> Thanks in advance >>>> >>>> Vl. >>>> -- >>>> 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 >>> _______________________________________________ >>> 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 Mon Jul 13 15:40:09 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Mon, 13 Jul 2015 15:40:09 -0400 Subject: [keycloak-dev] That thing for too many logins Message-ID: <55A41419.4060107@redhat.com> Customer: "Does Keycloak block logins after too many failed attempts?". Me: "Of course, that's really basic stuff." Customer: "I've looked all over the UI and I can't find it." Me: "I know it's there, but we did change the UI recently. Don't remember what it's called." I click around awhile. Me: "Oh, here it is. Failure Factor. It's under Security Defenses -> Brute Force Detection." Customer: "No wonder I couldn't find it." Me: "Yea, it needs to be called something else." What should Failure Factor be called? Maybe "Max Login Failures"? From ssilvert at redhat.com Mon Jul 13 15:54:41 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Mon, 13 Jul 2015 15:54:41 -0400 Subject: [keycloak-dev] Extend informations shown on Server Info page In-Reply-To: <55A404DD.7020804@redhat.com> References: <55A3B554.30702@redhat.com> <579352747.37221548.1436799530647.JavaMail.zimbra@redhat.com> <55A3D47A.10700@redhat.com> <55A3DA5B.7030109@redhat.com> <55A404DD.7020804@redhat.com> Message-ID: <55A41781.6020504@redhat.com> On 7/13/2015 2:35 PM, Marek Posolda wrote: > +1 to add it as well. > > I wonder if we should create service to return all this info, so we > can use it in more places? This stuff should be available via DMR. Not sure if we will also need to expose as a service. > For example we can display the info in server.log at startup (even if > it duplicates some wildfly logged info) and also display it in > stacktrace when some exception happen. This might help support team to > save some pain (they won't need to ask people about JVM, OS, database, > configured providers etc as everything will be in the stacktrace > attached to the support ticket) GSS has some cool stuff we can integrate with that will help them troubleshoot. I think the next version of web console in EAP exposes it. Saw a prototype several months ago. It lets you create a case and send logs, config files, etc. If I remember correctly, it also lets you search the solutions database. We need to talk to GSS about this before we craft something on our own. > > Marek > > On 13.7.2015 17:33, Stan Silvert wrote: >> On 7/13/2015 11:08 AM, Bill Burke wrote: >>> Yeah +1. Who cares if it is already in WF. Its not like you're >>> duplicating anything that complicated. >> Yes, this kind of stuff is meant to be duplicated. Anything exposed as >> DMR is already accessible from multiple management clients including >> CLI, CLI GUI, Web Console, jconsole, JON, etc. Much of it is also >> exposed as JMX, which in this case wraps DMR. >> >> We do need to make sure that any new runtime stats are exposed as DMR. >> That way, any WildFly/EAP tool can consume it. >>> On 7/13/2015 10:58 AM, Stian Thorgersen wrote: >>>> +1 To add it >>>> >>>> ----- Original Message ----- >>>>> From: "Vlastimil Elias" >>>>> To: keycloak-dev at lists.jboss.org >>>>> Sent: Monday, 13 July, 2015 2:55:48 PM >>>>> Subject: [keycloak-dev] Extend informations shown on Server Info page >>>>> >>>>> Hi, >>>>> >>>>> we just discussed this topic with Stian on >>>>> https://issues.jboss.org/browse/KEYCLOAK-1542 and we are not sure >>>>> if it is >>>>> worth to do or not so we should ask other KC devs for their opinion. >>>>> Server Info page contains, beside Providers info, only keycloak >>>>> version and >>>>> server time. It should be good for real management/operations >>>>> (based on my >>>>> few year's experience with jboss.org JIRA, SSO and other system's >>>>> operation) >>>>> to extend it with other informations like: >>>>> >>>>> >>>>> * server uptime >>>>> * version, vendor and variant of jre used to run it >>>>> * basic info about OS (type, version) >>>>> * info about OS user KC runs under >>>>> * info about locale nad timezone used for JVM >>>>> * JVM memory statistics (total and free heap mem, perm gen >>>>> mem) >>>>> * basic info about DB in case of JPA (JDBC url, JDBC driver >>>>> type and >>>>> version, DB type and version) or info about used mongo >>>>> (version etc) >>>>> >>>>> >>>>> This page should contain this info for all cluster nodes in clustered >>>>> environment. >>>>> Stian objected that this info is available form EAP/WF console, >>>>> but I think >>>>> it is a bit problematic for common KC admin to access it there as >>>>> it is not >>>>> integrated with KC console. >>>>> >>>>> WDYT? >>>>> >>>>> Thanks in advance >>>>> >>>>> Vl. >>>>> -- >>>>> 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 >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bburke at redhat.com Mon Jul 13 18:40:59 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 13 Jul 2015 18:40:59 -0400 Subject: [keycloak-dev] Extend informations shown on Server Info page In-Reply-To: <55A41781.6020504@redhat.com> References: <55A3B554.30702@redhat.com> <579352747.37221548.1436799530647.JavaMail.zimbra@redhat.com> <55A3D47A.10700@redhat.com> <55A3DA5B.7030109@redhat.com> <55A404DD.7020804@redhat.com> <55A41781.6020504@redhat.com> Message-ID: <55A43E7B.6070709@redhat.com> All he wants is server info. Don't see a problem duplicating this info on our server info page. GSS stuff sounds cool. On 7/13/2015 3:54 PM, Stan Silvert wrote: > On 7/13/2015 2:35 PM, Marek Posolda wrote: >> +1 to add it as well. >> >> I wonder if we should create service to return all this info, so we >> can use it in more places? > This stuff should be available via DMR. Not sure if we will also need > to expose as a service. >> For example we can display the info in server.log at startup (even if >> it duplicates some wildfly logged info) and also display it in >> stacktrace when some exception happen. This might help support team to >> save some pain (they won't need to ask people about JVM, OS, database, >> configured providers etc as everything will be in the stacktrace >> attached to the support ticket) > GSS has some cool stuff we can integrate with that will help them > troubleshoot. I think the next version of web console in EAP exposes > it. Saw a prototype several months ago. It lets you create a case and > send logs, config files, etc. If I remember correctly, it also lets you > search the solutions database. We need to talk to GSS about this before > we craft something on our own. >> >> Marek >> >> On 13.7.2015 17:33, Stan Silvert wrote: >>> On 7/13/2015 11:08 AM, Bill Burke wrote: >>>> Yeah +1. Who cares if it is already in WF. Its not like you're >>>> duplicating anything that complicated. >>> Yes, this kind of stuff is meant to be duplicated. Anything exposed as >>> DMR is already accessible from multiple management clients including >>> CLI, CLI GUI, Web Console, jconsole, JON, etc. Much of it is also >>> exposed as JMX, which in this case wraps DMR. >>> >>> We do need to make sure that any new runtime stats are exposed as DMR. >>> That way, any WildFly/EAP tool can consume it. >>>> On 7/13/2015 10:58 AM, Stian Thorgersen wrote: >>>>> +1 To add it >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Vlastimil Elias" >>>>>> To: keycloak-dev at lists.jboss.org >>>>>> Sent: Monday, 13 July, 2015 2:55:48 PM >>>>>> Subject: [keycloak-dev] Extend informations shown on Server Info page >>>>>> >>>>>> Hi, >>>>>> >>>>>> we just discussed this topic with Stian on >>>>>> https://issues.jboss.org/browse/KEYCLOAK-1542 and we are not sure >>>>>> if it is >>>>>> worth to do or not so we should ask other KC devs for their opinion. >>>>>> Server Info page contains, beside Providers info, only keycloak >>>>>> version and >>>>>> server time. It should be good for real management/operations >>>>>> (based on my >>>>>> few year's experience with jboss.org JIRA, SSO and other system's >>>>>> operation) >>>>>> to extend it with other informations like: >>>>>> >>>>>> >>>>>> * server uptime >>>>>> * version, vendor and variant of jre used to run it >>>>>> * basic info about OS (type, version) >>>>>> * info about OS user KC runs under >>>>>> * info about locale nad timezone used for JVM >>>>>> * JVM memory statistics (total and free heap mem, perm gen >>>>>> mem) >>>>>> * basic info about DB in case of JPA (JDBC url, JDBC driver >>>>>> type and >>>>>> version, DB type and version) or info about used mongo >>>>>> (version etc) >>>>>> >>>>>> >>>>>> This page should contain this info for all cluster nodes in clustered >>>>>> environment. >>>>>> Stian objected that this info is available form EAP/WF console, >>>>>> but I think >>>>>> it is a bit problematic for common KC admin to access it there as >>>>>> it is not >>>>>> integrated with KC console. >>>>>> >>>>>> WDYT? >>>>>> >>>>>> Thanks in advance >>>>>> >>>>>> Vl. >>>>>> -- >>>>>> 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 >>>>> _______________________________________________ >>>>> 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 matthew.casperson at autogeneral.com.au Mon Jul 13 22:30:57 2015 From: matthew.casperson at autogeneral.com.au (Matthew Casperson) Date: Tue, 14 Jul 2015 12:30:57 +1000 Subject: [keycloak-dev] How to login via Kerberos and Windows AD Message-ID: I have done the following steps in an attempt to configure Windows 2008 AD to work with KeyCloak: 1. Created a windows user called "Keycloak" 2. Run "setspn -s HTTP/virtual.local:8080 Keycloak"to assign the SPN to the user 3. Run "ktpass -out keycloak.keytab -princ HTTP/virtual.local:8080 at VIRTUAL.LOCAL -mapUser Keycloak -mapOp set -pass password -crypto RC4-HMAC-NT -pType KRB5_NT_PRINCIPAL" to get a keytab file. 4. Set "Kerberos Realm" to "VIRTUAL.LOCAL", "Server principal" to "HTTP/virtual.local:8080 at VIRTUAL.LOCAL" and set the location of the keytab file in the "Keycloak LDAP User Federation Provider" screen. 5. Saved the following in C:\Windows\krb5.ini: [domain_realm] .virtual.local = VIRTUAL.LOCAL virtual.local = VIRTUAL.LOCAL When I attempt to log in though, I get the following error: 02:21:58,009 INFO [stdout] (default task-4) principal is HTTP/virtual.local:8080 at VIRTUAL.LOCAL 02:21:58,009 INFO [stdout] (default task-4) Will use keytab 02:21:58,010 INFO [stdout] (default task-4) Commit Succeeded 02:21:58,010 INFO [stdout] (default task-4) 02:21:58,011 WARN [org.keycloak.federation.kerberos.impl.SPNEGOAuthenticator] (default task-4) SPNEGO login failed: jav a.security.PrivilegedActionException: GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag) at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_79] at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_79] at org.keycloak.federation.kerberos.impl.SPNEGOAuthenticator.authenticate(SPNEGOAuthenticator.java:46) I can't seem to find any reliable information on getting Keycloak configured with AD, nor on the error "GSSHeader did not find the right tag" (which seems to indicate everything from invalid config in the windows user account options to browsers requesting NTLM logins). Can anyone point me in the right direction with configuring windows and Keycloak for Kerberos based logins? -- *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/20150714/3f09faeb/attachment.html From srossillo at smartling.com Mon Jul 13 23:13:22 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Tue, 14 Jul 2015 03:13:22 +0000 Subject: [keycloak-dev] Operational monitoring of Keycloak server In-Reply-To: <299925009.37235169.1436800699765.JavaMail.zimbra@redhat.com> References: <55A3BA5C.2090906@redhat.com> <1307572132.37149706.1436793968827.JavaMail.zimbra@redhat.com> <55A3D3FA.9000600@redhat.com> <299925009.37235169.1436800699765.JavaMail.zimbra@redhat.com> Message-ID: Some type of health page would be great too for load balancers to monitor. Something that doesn't leak internal information but checks behind the scenes that: 1. Server can reach its databas(es) 2. Server cluster sync is working 3. Server can reach federation providers, etc. Endpoint should respond to get requests and return an http status reflective of server state. On Mon, Jul 13, 2015 at 11:18 AM Stian Thorgersen wrote: > So looks like we're at agreement to add the additional info you wanted to > server info page. > > How about we add an additional endpoint server-stat that can collect some > stats about the server? > > ----- Original Message ----- > > From: "Vlastimil Elias" > > To: "Stian Thorgersen" > > Cc: keycloak-dev at lists.jboss.org > > Sent: Monday, 13 July, 2015 5:06:34 PM > > Subject: Re: [keycloak-dev] Operational monitoring of Keycloak server > > > > Looks like I have to look at WildFly/EAP DMR to see what is possible to > > do with it, as I'm not sure if it is about remote monitoring also and > > if/how it can be use from monitoring systems like Splunk. > > > > Vl. > > > > On 13.7.2015 15:26, Stian Thorgersen wrote: > > > In WildFly/EAP that's DMR right? We're planning to make Keycloak > managable > > > through that as well. For example everything that goes into > > > keycloak-server.json will eventually be moved to standalone.xml. Same > with > > > admin endpoints, everything you can do there you'll eventually be able > to > > > do through DMR and jboss-cli as well. > > > > > > However, IMO it would make sense to at least expose Keycloak specific > > > information through the admin endpoints and console as well. Such > number > > > of sessions, etc.. > > > > > > ----- Original Message ----- > > >> From: "Vlastimil Elias" > > >> To: keycloak-dev at lists.jboss.org > > >> Sent: Monday, 13 July, 2015 3:17:16 PM > > >> Subject: [keycloak-dev] Operational monitoring of Keycloak server > > >> > > >> Hi, > > >> > > >> as we deployed KC to production mode for > https://developers.redhat.com > > >> we started to think about operational monitoring, for example from > > >> Nagios or other systems of this type. > > >> > > >> KC user guide doesn't contain any chapter covering this topic, also no > > >> any success over google search, so looks like KC doesn't have any > > >> solution for this yet. > > >> But I believe this is an important area which must be solved when KC > is > > >> used for production. > > >> > > >> I can imagine monitoring of JDBC connection if JPA is used, monitoring > > >> of Mongo connection if used as store, monitoring of LDAP connection if > > >> LDAP federation is used etc. > > >> Also some statistics like numbers of active sso session, number of > > >> logins per minute etc should be provided there. > > >> > > >> Monitoring is not about Keycloak core itself, it should be available > for > > >> extension developers also. For example we implemented own > > >> UserFederationProvider which calls backend REST services. > > >> We should be able to add info about this integration into monitoring > > >> endpoint to be able to catch problems with this REST API. > > >> > > >> It should be probably implemented same way as used by underlying > > >> WildFly/EAP (JPA/JDBC is probably available for monitoring there). I'm > > >> not sure if JMX is used there still or if some new framework is > > >> available for it. > > >> Or KC should use some form of KC REST API for this, which should be > > >> extended by additional info from KC extensions? > > >> > > >> What do you think? > > >> > > >> Vlastimil > > >> > > >> P.S we have https://issues.jboss.org/browse/RHD-552 for Red Hat > > >> Developer instance of KC > > >> > > >> -- > > >> 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 > > > > > _______________________________________________ > 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/20150714/de2854bc/attachment-0001.html From velias at redhat.com Tue Jul 14 02:34:29 2015 From: velias at redhat.com (Vlastimil Elias) Date: Tue, 14 Jul 2015 08:34:29 +0200 Subject: [keycloak-dev] Operational monitoring of Keycloak server In-Reply-To: References: <55A3BA5C.2090906@redhat.com> <1307572132.37149706.1436793968827.JavaMail.zimbra@redhat.com> <55A3D3FA.9000600@redhat.com> <299925009.37235169.1436800699765.JavaMail.zimbra@redhat.com> Message-ID: <55A4AD75.1030203@redhat.com> Yap, beside server-stat endpoint Stian talked about we should add some server-health endpoint also to be used for remote health monitoring by load balancers or systems like Nagios. Simple http endpoint without authentication (as it doesn't leak any sensitive information) is typically simplest way how to do this monitoring. Vl. On 14.7.2015 05:13, Scott Rossillo wrote: > Some type of health page would be great too for load balancers to > monitor. Something that doesn't leak internal information but checks > behind the scenes that: > 1. Server can reach its databas(es) > 2. Server cluster sync is working > 3. Server can reach federation providers, etc. > Endpoint should respond to get requests and return an http status > reflective of server state. > > On Mon, Jul 13, 2015 at 11:18 AM Stian Thorgersen > wrote: > > So looks like we're at agreement to add the additional info you > wanted to server info page. > > How about we add an additional endpoint server-stat that can > collect some stats about the server? > > ----- Original Message ----- > > From: "Vlastimil Elias" > > > To: "Stian Thorgersen" > > > Cc: keycloak-dev at lists.jboss.org > > > Sent: Monday, 13 July, 2015 5:06:34 PM > > Subject: Re: [keycloak-dev] Operational monitoring of Keycloak > server > > > > Looks like I have to look at WildFly/EAP DMR to see what is > possible to > > do with it, as I'm not sure if it is about remote monitoring > also and > > if/how it can be use from monitoring systems like Splunk. > > > > Vl. > > > > On 13.7.2015 15:26, Stian Thorgersen wrote: > > > In WildFly/EAP that's DMR right? We're planning to make > Keycloak managable > > > through that as well. For example everything that goes into > > > keycloak-server.json will eventually be moved to > standalone.xml. Same with > > > admin endpoints, everything you can do there you'll eventually > be able to > > > do through DMR and jboss-cli as well. > > > > > > However, IMO it would make sense to at least expose Keycloak > specific > > > information through the admin endpoints and console as well. > Such number > > > of sessions, etc.. > > > > > > ----- Original Message ----- > > >> From: "Vlastimil Elias" > > > >> To: keycloak-dev at lists.jboss.org > > > >> Sent: Monday, 13 July, 2015 3:17:16 PM > > >> Subject: [keycloak-dev] Operational monitoring of Keycloak server > > >> > > >> Hi, > > >> > > >> as we deployed KC to production mode for > https://developers.redhat.com > > >> we started to think about operational monitoring, for example > from > > >> Nagios or other systems of this type. > > >> > > >> KC user guide doesn't contain any chapter covering this > topic, also no > > >> any success over google search, so looks like KC doesn't have any > > >> solution for this yet. > > >> But I believe this is an important area which must be solved > when KC is > > >> used for production. > > >> > > >> I can imagine monitoring of JDBC connection if JPA is used, > monitoring > > >> of Mongo connection if used as store, monitoring of LDAP > connection if > > >> LDAP federation is used etc. > > >> Also some statistics like numbers of active sso session, > number of > > >> logins per minute etc should be provided there. > > >> > > >> Monitoring is not about Keycloak core itself, it should be > available for > > >> extension developers also. For example we implemented own > > >> UserFederationProvider which calls backend REST services. > > >> We should be able to add info about this integration into > monitoring > > >> endpoint to be able to catch problems with this REST API. > > >> > > >> It should be probably implemented same way as used by underlying > > >> WildFly/EAP (JPA/JDBC is probably available for monitoring > there). I'm > > >> not sure if JMX is used there still or if some new framework is > > >> available for it. > > >> Or KC should use some form of KC REST API for this, which > should be > > >> extended by additional info from KC extensions? > > >> > > >> What do you think? > > >> > > >> Vlastimil > > >> > > >> P.S we have https://issues.jboss.org/browse/RHD-552 for Red Hat > > >> Developer instance of KC > > >> > > >> -- > > >> 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 > > > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150714/e8021b14/attachment.html From stian at redhat.com Tue Jul 14 02:42:37 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 14 Jul 2015 02:42:37 -0400 (EDT) Subject: [keycloak-dev] Operational monitoring of Keycloak server In-Reply-To: <55A4AD75.1030203@redhat.com> References: <55A3BA5C.2090906@redhat.com> <1307572132.37149706.1436793968827.JavaMail.zimbra@redhat.com> <55A3D3FA.9000600@redhat.com> <299925009.37235169.1436800699765.JavaMail.zimbra@redhat.com> <55A4AD75.1030203@redhat.com> Message-ID: <2071278650.37809022.1436856157015.JavaMail.zimbra@redhat.com> Ok so we add one that just returns OK or ERROR which doesn't require authentication, but then we add another that can return more details, including stats and what the error is. For full health we should check all external services that are used (db, identity providers and user federation providers). Cluster sync will depend on what Infinispan exposes, but I imagine they'll have the required details avail. ----- Original Message ----- > From: "Vlastimil Elias" > To: "Scott Rossillo" , "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Tuesday, 14 July, 2015 8:34:29 AM > Subject: Re: [keycloak-dev] Operational monitoring of Keycloak server > > Yap, beside server-stat endpoint Stian talked about we should add some > server-health endpoint also to be used for remote health monitoring by > load balancers or systems like Nagios. > Simple http endpoint without authentication (as it doesn't leak any > sensitive information) is typically simplest way how to do this monitoring. > > Vl. > > On 14.7.2015 05:13, Scott Rossillo wrote: > > Some type of health page would be great too for load balancers to > > monitor. Something that doesn't leak internal information but checks > > behind the scenes that: > > 1. Server can reach its databas(es) > > 2. Server cluster sync is working > > 3. Server can reach federation providers, etc. > > Endpoint should respond to get requests and return an http status > > reflective of server state. > > > > On Mon, Jul 13, 2015 at 11:18 AM Stian Thorgersen > > wrote: > > > > So looks like we're at agreement to add the additional info you > > wanted to server info page. > > > > How about we add an additional endpoint server-stat that can > > collect some stats about the server? > > > > ----- Original Message ----- > > > From: "Vlastimil Elias" > > > > > To: "Stian Thorgersen" > > > > Cc: keycloak-dev at lists.jboss.org > > > > > Sent: Monday, 13 July, 2015 5:06:34 PM > > > Subject: Re: [keycloak-dev] Operational monitoring of Keycloak > > server > > > > > > Looks like I have to look at WildFly/EAP DMR to see what is > > possible to > > > do with it, as I'm not sure if it is about remote monitoring > > also and > > > if/how it can be use from monitoring systems like Splunk. > > > > > > Vl. > > > > > > On 13.7.2015 15:26, Stian Thorgersen wrote: > > > > In WildFly/EAP that's DMR right? We're planning to make > > Keycloak managable > > > > through that as well. For example everything that goes into > > > > keycloak-server.json will eventually be moved to > > standalone.xml. Same with > > > > admin endpoints, everything you can do there you'll eventually > > be able to > > > > do through DMR and jboss-cli as well. > > > > > > > > However, IMO it would make sense to at least expose Keycloak > > specific > > > > information through the admin endpoints and console as well. > > Such number > > > > of sessions, etc.. > > > > > > > > ----- Original Message ----- > > > >> From: "Vlastimil Elias" > > > > > >> To: keycloak-dev at lists.jboss.org > > > > > >> Sent: Monday, 13 July, 2015 3:17:16 PM > > > >> Subject: [keycloak-dev] Operational monitoring of Keycloak server > > > >> > > > >> Hi, > > > >> > > > >> as we deployed KC to production mode for > > https://developers.redhat.com > > > >> we started to think about operational monitoring, for example > > from > > > >> Nagios or other systems of this type. > > > >> > > > >> KC user guide doesn't contain any chapter covering this > > topic, also no > > > >> any success over google search, so looks like KC doesn't have any > > > >> solution for this yet. > > > >> But I believe this is an important area which must be solved > > when KC is > > > >> used for production. > > > >> > > > >> I can imagine monitoring of JDBC connection if JPA is used, > > monitoring > > > >> of Mongo connection if used as store, monitoring of LDAP > > connection if > > > >> LDAP federation is used etc. > > > >> Also some statistics like numbers of active sso session, > > number of > > > >> logins per minute etc should be provided there. > > > >> > > > >> Monitoring is not about Keycloak core itself, it should be > > available for > > > >> extension developers also. For example we implemented own > > > >> UserFederationProvider which calls backend REST services. > > > >> We should be able to add info about this integration into > > monitoring > > > >> endpoint to be able to catch problems with this REST API. > > > >> > > > >> It should be probably implemented same way as used by underlying > > > >> WildFly/EAP (JPA/JDBC is probably available for monitoring > > there). I'm > > > >> not sure if JMX is used there still or if some new framework is > > > >> available for it. > > > >> Or KC should use some form of KC REST API for this, which > > should be > > > >> extended by additional info from KC extensions? > > > >> > > > >> What do you think? > > > >> > > > >> Vlastimil > > > >> > > > >> P.S we have https://issues.jboss.org/browse/RHD-552 for Red Hat > > > >> Developer instance of KC > > > >> > > > >> -- > > > >> 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 > > > > > > > > _______________________________________________ > > 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 Tue Jul 14 02:45:45 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 14 Jul 2015 02:45:45 -0400 (EDT) Subject: [keycloak-dev] How to login via Kerberos and Windows AD In-Reply-To: References: Message-ID: <705522248.37810693.1436856345137.JavaMail.zimbra@redhat.com> Please use the user mailing list for support ----- Original Message ----- > From: "Matthew Casperson" > To: keycloak-dev at lists.jboss.org > Sent: Tuesday, 14 July, 2015 4:30:57 AM > Subject: [keycloak-dev] How to login via Kerberos and Windows AD > > I have done the following steps in an attempt to configure Windows 2008 AD to > work with KeyCloak: > > 1. Created a windows user called "Keycloak" > 2. Run "setspn -s HTTP/virtual.local:8080 Keycloak"to assign the SPN to > the user > 3. Run "ktpass -out keycloak.keytab -princ > HTTP/virtual.local:8080 at VIRTUAL.LOCAL -mapUser Keycloak -mapOp set -pass > password -crypto RC4-HMAC-NT -pType KRB5_NT_PRINCIPAL" to get a keytab > file. > 4. Set "Kerberos Realm" to "VIRTUAL.LOCAL", "Server principal" to > "HTTP/virtual.local:8080 at VIRTUAL.LOCAL" and set the location of the > keytab file in the "Keycloak LDAP User Federation Provider" screen. > 5. Saved the following in C:\Windows\krb5.ini: [domain_realm] > .virtual.local = VIRTUAL.LOCAL virtual.local = VIRTUAL.LOCAL > > When I attempt to log in though, I get the following error: > > 02:21:58,009 INFO [stdout] (default task-4) principal is > HTTP/virtual.local:8080 at VIRTUAL.LOCAL > 02:21:58,009 INFO [stdout] (default task-4) Will use keytab > 02:21:58,010 INFO [stdout] (default task-4) Commit Succeeded > 02:21:58,010 INFO [stdout] (default task-4) > 02:21:58,011 WARN [org.keycloak.federation.kerberos.impl.SPNEGOAuthenticator] > (default task-4) SPNEGO login failed: jav > a.security.PrivilegedActionException: GSSException: Defective token detected > (Mechanism level: GSSHeader did not find the right tag) > at java.security.AccessController.doPrivileged(Native Method) > [rt.jar:1.7.0_79] > at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_79] > at > org.keycloak.federation.kerberos.impl.SPNEGOAuthenticator.authenticate(SPNEGOAuthenticator.java:46) > > I can't seem to find any reliable information on getting Keycloak configured > with AD, nor on the error "GSSHeader did not find the right tag" (which > seems to indicate everything from invalid config in the windows user account > options to browsers requesting NTLM logins). > > Can anyone point me in the right direction with configuring windows and > Keycloak for Kerberos based logins? > > -- > 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 stian at redhat.com Tue Jul 14 02:47:31 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 14 Jul 2015 02:47:31 -0400 (EDT) Subject: [keycloak-dev] That thing for too many logins In-Reply-To: <55A41419.4060107@redhat.com> References: <55A41419.4060107@redhat.com> Message-ID: <2038804561.37811078.1436856451036.JavaMail.zimbra@redhat.com> +1 I found the labels on the brute force protection a bit confusing myself ----- Original Message ----- > From: "Stan Silvert" > To: keycloak-dev at lists.jboss.org > Sent: Monday, 13 July, 2015 9:40:09 PM > Subject: [keycloak-dev] That thing for too many logins > > Customer: "Does Keycloak block logins after too many failed attempts?". > Me: "Of course, that's really basic stuff." > Customer: "I've looked all over the UI and I can't find it." > Me: "I know it's there, but we did change the UI recently. Don't > remember what it's called." > > I click around awhile. > > Me: "Oh, here it is. Failure Factor. It's under Security Defenses -> > Brute Force Detection." > Customer: "No wonder I couldn't find it." > Me: "Yea, it needs to be called something else." > > What should Failure Factor be called? Maybe "Max Login Failures"? > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From velias at redhat.com Tue Jul 14 02:56:43 2015 From: velias at redhat.com (Vlastimil Elias) Date: Tue, 14 Jul 2015 08:56:43 +0200 Subject: [keycloak-dev] Operational monitoring of Keycloak server In-Reply-To: <2071278650.37809022.1436856157015.JavaMail.zimbra@redhat.com> References: <55A3BA5C.2090906@redhat.com> <1307572132.37149706.1436793968827.JavaMail.zimbra@redhat.com> <55A3D3FA.9000600@redhat.com> <299925009.37235169.1436800699765.JavaMail.zimbra@redhat.com> <55A4AD75.1030203@redhat.com> <2071278650.37809022.1436856157015.JavaMail.zimbra@redhat.com> Message-ID: <55A4B2AB.9080508@redhat.com> On 14.7.2015 08:42, Stian Thorgersen wrote: > Ok so we add one that just returns OK or ERROR which doesn't require authentication, but then we add another that can return more details, including stats and what the error is. Yep. Simple http endpoinds for now, later all this info may be expose over DMR or some other mechanism if necessary. > > For full health we should check all external services that are used (db, identity providers and user federation providers). Cluster sync will depend on what Infinispan exposes, but I imagine they'll have the required details avail. Beside endpoint for full health check (which should summarize all services into one flag if I understand correctly, which is good for loadbalancer) we should expose separate endpoint for each service health, as it is better for operational monitoring systems like Nagios. Admins are better informed what is going wrong and they can resolve situation more quickly without necessity to search cause of general failure flag somewhere else. Vl. > > ----- Original Message ----- >> From: "Vlastimil Elias" >> To: "Scott Rossillo" , "Stian Thorgersen" >> Cc: keycloak-dev at lists.jboss.org >> Sent: Tuesday, 14 July, 2015 8:34:29 AM >> Subject: Re: [keycloak-dev] Operational monitoring of Keycloak server >> >> Yap, beside server-stat endpoint Stian talked about we should add some >> server-health endpoint also to be used for remote health monitoring by >> load balancers or systems like Nagios. >> Simple http endpoint without authentication (as it doesn't leak any >> sensitive information) is typically simplest way how to do this monitoring. >> >> Vl. >> >> On 14.7.2015 05:13, Scott Rossillo wrote: >>> Some type of health page would be great too for load balancers to >>> monitor. Something that doesn't leak internal information but checks >>> behind the scenes that: >>> 1. Server can reach its databas(es) >>> 2. Server cluster sync is working >>> 3. Server can reach federation providers, etc. >>> Endpoint should respond to get requests and return an http status >>> reflective of server state. >>> >>> On Mon, Jul 13, 2015 at 11:18 AM Stian Thorgersen >> > wrote: >>> >>> So looks like we're at agreement to add the additional info you >>> wanted to server info page. >>> >>> How about we add an additional endpoint server-stat that can >>> collect some stats about the server? >>> >>> ----- Original Message ----- >>> > From: "Vlastimil Elias" >> > >>> > To: "Stian Thorgersen" > >>> > Cc: keycloak-dev at lists.jboss.org >>> >>> > Sent: Monday, 13 July, 2015 5:06:34 PM >>> > Subject: Re: [keycloak-dev] Operational monitoring of Keycloak >>> server >>> > >>> > Looks like I have to look at WildFly/EAP DMR to see what is >>> possible to >>> > do with it, as I'm not sure if it is about remote monitoring >>> also and >>> > if/how it can be use from monitoring systems like Splunk. >>> > >>> > Vl. >>> > >>> > On 13.7.2015 15:26, Stian Thorgersen wrote: >>> > > In WildFly/EAP that's DMR right? We're planning to make >>> Keycloak managable >>> > > through that as well. For example everything that goes into >>> > > keycloak-server.json will eventually be moved to >>> standalone.xml. Same with >>> > > admin endpoints, everything you can do there you'll eventually >>> be able to >>> > > do through DMR and jboss-cli as well. >>> > > >>> > > However, IMO it would make sense to at least expose Keycloak >>> specific >>> > > information through the admin endpoints and console as well. >>> Such number >>> > > of sessions, etc.. >>> > > >>> > > ----- Original Message ----- >>> > >> From: "Vlastimil Elias" >> > >>> > >> To: keycloak-dev at lists.jboss.org >>> >>> > >> Sent: Monday, 13 July, 2015 3:17:16 PM >>> > >> Subject: [keycloak-dev] Operational monitoring of Keycloak server >>> > >> >>> > >> Hi, >>> > >> >>> > >> as we deployed KC to production mode for >>> https://developers.redhat.com >>> > >> we started to think about operational monitoring, for example >>> from >>> > >> Nagios or other systems of this type. >>> > >> >>> > >> KC user guide doesn't contain any chapter covering this >>> topic, also no >>> > >> any success over google search, so looks like KC doesn't have any >>> > >> solution for this yet. >>> > >> But I believe this is an important area which must be solved >>> when KC is >>> > >> used for production. >>> > >> >>> > >> I can imagine monitoring of JDBC connection if JPA is used, >>> monitoring >>> > >> of Mongo connection if used as store, monitoring of LDAP >>> connection if >>> > >> LDAP federation is used etc. >>> > >> Also some statistics like numbers of active sso session, >>> number of >>> > >> logins per minute etc should be provided there. >>> > >> >>> > >> Monitoring is not about Keycloak core itself, it should be >>> available for >>> > >> extension developers also. For example we implemented own >>> > >> UserFederationProvider which calls backend REST services. >>> > >> We should be able to add info about this integration into >>> monitoring >>> > >> endpoint to be able to catch problems with this REST API. >>> > >> >>> > >> It should be probably implemented same way as used by underlying >>> > >> WildFly/EAP (JPA/JDBC is probably available for monitoring >>> there). I'm >>> > >> not sure if JMX is used there still or if some new framework is >>> > >> available for it. >>> > >> Or KC should use some form of KC REST API for this, which >>> should be >>> > >> extended by additional info from KC extensions? >>> > >> >>> > >> What do you think? >>> > >> >>> > >> Vlastimil >>> > >> >>> > >> P.S we have https://issues.jboss.org/browse/RHD-552 for Red Hat >>> > >> Developer instance of KC >>> > >> >>> > >> -- >>> > >> 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 >>> > >>> > >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> -- >> Vlastimil Elias >> Principal Software Engineer >> jboss.org Development Team >> >> -- Vlastimil Elias Principal Software Engineer jboss.org Development Team From stian at redhat.com Tue Jul 14 03:14:14 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 14 Jul 2015 03:14:14 -0400 (EDT) Subject: [keycloak-dev] Operational monitoring of Keycloak server In-Reply-To: <55A4B2AB.9080508@redhat.com> References: <55A3BA5C.2090906@redhat.com> <1307572132.37149706.1436793968827.JavaMail.zimbra@redhat.com> <55A3D3FA.9000600@redhat.com> <299925009.37235169.1436800699765.JavaMail.zimbra@redhat.com> <55A4AD75.1030203@redhat.com> <2071278650.37809022.1436856157015.JavaMail.zimbra@redhat.com> <55A4B2AB.9080508@redhat.com> Message-ID: <383530390.37875127.1436858054281.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Vlastimil Elias" > To: "Stian Thorgersen" > Cc: "Scott Rossillo" , keycloak-dev at lists.jboss.org > Sent: Tuesday, 14 July, 2015 8:56:43 AM > Subject: Re: [keycloak-dev] Operational monitoring of Keycloak server > > > > On 14.7.2015 08:42, Stian Thorgersen wrote: > > Ok so we add one that just returns OK or ERROR which doesn't require > > authentication, but then we add another that can return more details, > > including stats and what the error is. > Yep. Simple http endpoinds for now, later all this info may be expose > over DMR or some other mechanism if necessary. > > > > For full health we should check all external services that are used (db, > > identity providers and user federation providers). Cluster sync will > > depend on what Infinispan exposes, but I imagine they'll have the required > > details avail. > > Beside endpoint for full health check (which should summarize all > services into one flag if I understand correctly, which is good for > loadbalancer) we should expose separate endpoint for each service > health, as it is better for operational monitoring systems like Nagios. > Admins are better informed what is going wrong and they can resolve > situation more quickly without necessity to search cause of general > failure flag somewhere else. We could have a single health endpoint that returns a 200 or 500 and also returns a json doc with details. Something like: { realm: ok, users: ok, realmCache: error, userCache: error, identity-providers: { google: ok, facebook: error }, user-federation: { ldap: ok } } I wonder if that's to much details to expose without authentication. > > Vl. > > > > > ----- Original Message ----- > >> From: "Vlastimil Elias" > >> To: "Scott Rossillo" , "Stian Thorgersen" > >> > >> Cc: keycloak-dev at lists.jboss.org > >> Sent: Tuesday, 14 July, 2015 8:34:29 AM > >> Subject: Re: [keycloak-dev] Operational monitoring of Keycloak server > >> > >> Yap, beside server-stat endpoint Stian talked about we should add some > >> server-health endpoint also to be used for remote health monitoring by > >> load balancers or systems like Nagios. > >> Simple http endpoint without authentication (as it doesn't leak any > >> sensitive information) is typically simplest way how to do this > >> monitoring. > >> > >> Vl. > >> > >> On 14.7.2015 05:13, Scott Rossillo wrote: > >>> Some type of health page would be great too for load balancers to > >>> monitor. Something that doesn't leak internal information but checks > >>> behind the scenes that: > >>> 1. Server can reach its databas(es) > >>> 2. Server cluster sync is working > >>> 3. Server can reach federation providers, etc. > >>> Endpoint should respond to get requests and return an http status > >>> reflective of server state. > >>> > >>> On Mon, Jul 13, 2015 at 11:18 AM Stian Thorgersen >>> > wrote: > >>> > >>> So looks like we're at agreement to add the additional info you > >>> wanted to server info page. > >>> > >>> How about we add an additional endpoint server-stat that can > >>> collect some stats about the server? > >>> > >>> ----- Original Message ----- > >>> > From: "Vlastimil Elias" >>> > > >>> > To: "Stian Thorgersen" >>> > > > >>> > Cc: keycloak-dev at lists.jboss.org > >>> > >>> > Sent: Monday, 13 July, 2015 5:06:34 PM > >>> > Subject: Re: [keycloak-dev] Operational monitoring of Keycloak > >>> server > >>> > > >>> > Looks like I have to look at WildFly/EAP DMR to see what is > >>> possible to > >>> > do with it, as I'm not sure if it is about remote monitoring > >>> also and > >>> > if/how it can be use from monitoring systems like Splunk. > >>> > > >>> > Vl. > >>> > > >>> > On 13.7.2015 15:26, Stian Thorgersen wrote: > >>> > > In WildFly/EAP that's DMR right? We're planning to make > >>> Keycloak managable > >>> > > through that as well. For example everything that goes into > >>> > > keycloak-server.json will eventually be moved to > >>> standalone.xml. Same with > >>> > > admin endpoints, everything you can do there you'll eventually > >>> be able to > >>> > > do through DMR and jboss-cli as well. > >>> > > > >>> > > However, IMO it would make sense to at least expose Keycloak > >>> specific > >>> > > information through the admin endpoints and console as well. > >>> Such number > >>> > > of sessions, etc.. > >>> > > > >>> > > ----- Original Message ----- > >>> > >> From: "Vlastimil Elias" >>> > > >>> > >> To: keycloak-dev at lists.jboss.org > >>> > >>> > >> Sent: Monday, 13 July, 2015 3:17:16 PM > >>> > >> Subject: [keycloak-dev] Operational monitoring of Keycloak > >>> > >> server > >>> > >> > >>> > >> Hi, > >>> > >> > >>> > >> as we deployed KC to production mode for > >>> https://developers.redhat.com > >>> > >> we started to think about operational monitoring, for example > >>> from > >>> > >> Nagios or other systems of this type. > >>> > >> > >>> > >> KC user guide doesn't contain any chapter covering this > >>> topic, also no > >>> > >> any success over google search, so looks like KC doesn't have > >>> > >> any > >>> > >> solution for this yet. > >>> > >> But I believe this is an important area which must be solved > >>> when KC is > >>> > >> used for production. > >>> > >> > >>> > >> I can imagine monitoring of JDBC connection if JPA is used, > >>> monitoring > >>> > >> of Mongo connection if used as store, monitoring of LDAP > >>> connection if > >>> > >> LDAP federation is used etc. > >>> > >> Also some statistics like numbers of active sso session, > >>> number of > >>> > >> logins per minute etc should be provided there. > >>> > >> > >>> > >> Monitoring is not about Keycloak core itself, it should be > >>> available for > >>> > >> extension developers also. For example we implemented own > >>> > >> UserFederationProvider which calls backend REST services. > >>> > >> We should be able to add info about this integration into > >>> monitoring > >>> > >> endpoint to be able to catch problems with this REST API. > >>> > >> > >>> > >> It should be probably implemented same way as used by > >>> > >> underlying > >>> > >> WildFly/EAP (JPA/JDBC is probably available for monitoring > >>> there). I'm > >>> > >> not sure if JMX is used there still or if some new framework is > >>> > >> available for it. > >>> > >> Or KC should use some form of KC REST API for this, which > >>> should be > >>> > >> extended by additional info from KC extensions? > >>> > >> > >>> > >> What do you think? > >>> > >> > >>> > >> Vlastimil > >>> > >> > >>> > >> P.S we have https://issues.jboss.org/browse/RHD-552 for Red Hat > >>> > >> Developer instance of KC > >>> > >> > >>> > >> -- > >>> > >> 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 > >>> > > >>> > > >>> _______________________________________________ > >>> keycloak-dev mailing list > >>> keycloak-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>> > >> -- > >> Vlastimil Elias > >> Principal Software Engineer > >> jboss.org Development Team > >> > >> > > -- > Vlastimil Elias > Principal Software Engineer > jboss.org Development Team > > From stian at redhat.com Tue Jul 14 03:49:43 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 14 Jul 2015 03:49:43 -0400 (EDT) Subject: [keycloak-dev] Improve first login with identity provider In-Reply-To: <1976539821.37890686.1436859470273.JavaMail.zimbra@redhat.com> Message-ID: <468566795.37895483.1436860183378.JavaMail.zimbra@redhat.com> We should improve the first login with identity provider flow as it's less than elegant at the moment. Some of the suggestion below is how it already works and some not! The mechanism to detect existing accounts should include: * Username * Email * Firstname and lastname This needs to work both initially on the callback from the identity provider, but also after the user has updated the profile. If an existing account is detected the user should be given the option to do one of the following: * Cancel * Merge - this will require the user to authenticate as the existing user. Once authenticated the attributes, roles and identity-provider links from the new user are copied to the existing user (not overriding existing attributes/roles/links) * Continue - only if existing account is found by firstname and lastname For this to work it's probably easier to initially always create the account. To get around the case where email is duplicated we can set that as an temporary attribute rather than the email. We also need to make sure we can define what attributes are required for a user in a realm, including validation of each attribute. If any of these attributes are missing the user will have to update the profile. Finally, we should add a expires on a user account. If a user initiates the login with an identity provider, but never completes the above actions (for example closes the browser on the existing account screen, or the update profile screen) the account should automatically be removed after a given time. With regards to required actions it should be possible to configure one or more required actions for first login for a specific identity provider. It would be nice to nail down this flow once and for all! If we can all agree on the flow, we can allocate someone to implement it for 1.5. From velias at redhat.com Tue Jul 14 03:58:36 2015 From: velias at redhat.com (Vlastimil Elias) Date: Tue, 14 Jul 2015 09:58:36 +0200 Subject: [keycloak-dev] Operational monitoring of Keycloak server In-Reply-To: <383530390.37875127.1436858054281.JavaMail.zimbra@redhat.com> References: <55A3BA5C.2090906@redhat.com> <1307572132.37149706.1436793968827.JavaMail.zimbra@redhat.com> <55A3D3FA.9000600@redhat.com> <299925009.37235169.1436800699765.JavaMail.zimbra@redhat.com> <55A4AD75.1030203@redhat.com> <2071278650.37809022.1436856157015.JavaMail.zimbra@redhat.com> <55A4B2AB.9080508@redhat.com> <383530390.37875127.1436858054281.JavaMail.zimbra@redhat.com> Message-ID: <55A4C12C.8070305@redhat.com> On 14.7.2015 09:14, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Vlastimil Elias" >> To: "Stian Thorgersen" >> Cc: "Scott Rossillo" , keycloak-dev at lists.jboss.org >> Sent: Tuesday, 14 July, 2015 8:56:43 AM >> Subject: Re: [keycloak-dev] Operational monitoring of Keycloak server >> >> >> >> On 14.7.2015 08:42, Stian Thorgersen wrote: >>> Ok so we add one that just returns OK or ERROR which doesn't require >>> authentication, but then we add another that can return more details, >>> including stats and what the error is. >> Yep. Simple http endpoinds for now, later all this info may be expose >> over DMR or some other mechanism if necessary. >>> For full health we should check all external services that are used (db, >>> identity providers and user federation providers). Cluster sync will >>> depend on what Infinispan exposes, but I imagine they'll have the required >>> details avail. >> Beside endpoint for full health check (which should summarize all >> services into one flag if I understand correctly, which is good for >> loadbalancer) we should expose separate endpoint for each service >> health, as it is better for operational monitoring systems like Nagios. >> Admins are better informed what is going wrong and they can resolve >> situation more quickly without necessity to search cause of general >> failure flag somewhere else. > We could have a single health endpoint that returns a 200 or 500 and also returns a json doc with details. Something like: > > { > realm: ok, > users: ok, > realmCache: error, > userCache: error, > identity-providers: { > google: ok, > facebook: error > }, > user-federation: { > ldap: ok > } > } > > I wonder if that's to much details to expose without authentication. This should work, but I miss info about DB connection here. It is crucial from operational point of view as this allows sysadmins quickly detect that connection to DB is broken. I believe this kind of info can be safely exposed without authentication. If the endpoint is clearly documented then access can be always restricted on some network infra (webserver/proxy) ahead of KC. > >> Vl. >> >>> ----- Original Message ----- >>>> From: "Vlastimil Elias" >>>> To: "Scott Rossillo" , "Stian Thorgersen" >>>> >>>> Cc: keycloak-dev at lists.jboss.org >>>> Sent: Tuesday, 14 July, 2015 8:34:29 AM >>>> Subject: Re: [keycloak-dev] Operational monitoring of Keycloak server >>>> >>>> Yap, beside server-stat endpoint Stian talked about we should add some >>>> server-health endpoint also to be used for remote health monitoring by >>>> load balancers or systems like Nagios. >>>> Simple http endpoint without authentication (as it doesn't leak any >>>> sensitive information) is typically simplest way how to do this >>>> monitoring. >>>> >>>> Vl. >>>> >>>> On 14.7.2015 05:13, Scott Rossillo wrote: >>>>> Some type of health page would be great too for load balancers to >>>>> monitor. Something that doesn't leak internal information but checks >>>>> behind the scenes that: >>>>> 1. Server can reach its databas(es) >>>>> 2. Server cluster sync is working >>>>> 3. Server can reach federation providers, etc. >>>>> Endpoint should respond to get requests and return an http status >>>>> reflective of server state. >>>>> >>>>> On Mon, Jul 13, 2015 at 11:18 AM Stian Thorgersen >>>> > wrote: >>>>> >>>>> So looks like we're at agreement to add the additional info you >>>>> wanted to server info page. >>>>> >>>>> How about we add an additional endpoint server-stat that can >>>>> collect some stats about the server? >>>>> >>>>> ----- Original Message ----- >>>>> > From: "Vlastimil Elias" >>>> > >>>>> > To: "Stian Thorgersen" >>>> > > >>>>> > Cc: keycloak-dev at lists.jboss.org >>>>> >>>>> > Sent: Monday, 13 July, 2015 5:06:34 PM >>>>> > Subject: Re: [keycloak-dev] Operational monitoring of Keycloak >>>>> server >>>>> > >>>>> > Looks like I have to look at WildFly/EAP DMR to see what is >>>>> possible to >>>>> > do with it, as I'm not sure if it is about remote monitoring >>>>> also and >>>>> > if/how it can be use from monitoring systems like Splunk. >>>>> > >>>>> > Vl. >>>>> > >>>>> > On 13.7.2015 15:26, Stian Thorgersen wrote: >>>>> > > In WildFly/EAP that's DMR right? We're planning to make >>>>> Keycloak managable >>>>> > > through that as well. For example everything that goes into >>>>> > > keycloak-server.json will eventually be moved to >>>>> standalone.xml. Same with >>>>> > > admin endpoints, everything you can do there you'll eventually >>>>> be able to >>>>> > > do through DMR and jboss-cli as well. >>>>> > > >>>>> > > However, IMO it would make sense to at least expose Keycloak >>>>> specific >>>>> > > information through the admin endpoints and console as well. >>>>> Such number >>>>> > > of sessions, etc.. >>>>> > > >>>>> > > ----- Original Message ----- >>>>> > >> From: "Vlastimil Elias" >>>> > >>>>> > >> To: keycloak-dev at lists.jboss.org >>>>> >>>>> > >> Sent: Monday, 13 July, 2015 3:17:16 PM >>>>> > >> Subject: [keycloak-dev] Operational monitoring of Keycloak >>>>> > >> server >>>>> > >> >>>>> > >> Hi, >>>>> > >> >>>>> > >> as we deployed KC to production mode for >>>>> https://developers.redhat.com >>>>> > >> we started to think about operational monitoring, for example >>>>> from >>>>> > >> Nagios or other systems of this type. >>>>> > >> >>>>> > >> KC user guide doesn't contain any chapter covering this >>>>> topic, also no >>>>> > >> any success over google search, so looks like KC doesn't have >>>>> > >> any >>>>> > >> solution for this yet. >>>>> > >> But I believe this is an important area which must be solved >>>>> when KC is >>>>> > >> used for production. >>>>> > >> >>>>> > >> I can imagine monitoring of JDBC connection if JPA is used, >>>>> monitoring >>>>> > >> of Mongo connection if used as store, monitoring of LDAP >>>>> connection if >>>>> > >> LDAP federation is used etc. >>>>> > >> Also some statistics like numbers of active sso session, >>>>> number of >>>>> > >> logins per minute etc should be provided there. >>>>> > >> >>>>> > >> Monitoring is not about Keycloak core itself, it should be >>>>> available for >>>>> > >> extension developers also. For example we implemented own >>>>> > >> UserFederationProvider which calls backend REST services. >>>>> > >> We should be able to add info about this integration into >>>>> monitoring >>>>> > >> endpoint to be able to catch problems with this REST API. >>>>> > >> >>>>> > >> It should be probably implemented same way as used by >>>>> > >> underlying >>>>> > >> WildFly/EAP (JPA/JDBC is probably available for monitoring >>>>> there). I'm >>>>> > >> not sure if JMX is used there still or if some new framework is >>>>> > >> available for it. >>>>> > >> Or KC should use some form of KC REST API for this, which >>>>> should be >>>>> > >> extended by additional info from KC extensions? >>>>> > >> >>>>> > >> What do you think? >>>>> > >> >>>>> > >> Vlastimil >>>>> > >> >>>>> > >> P.S we have https://issues.jboss.org/browse/RHD-552 for Red Hat >>>>> > >> Developer instance of KC >>>>> > >> >>>>> > >> -- >>>>> > >> 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 >>>>> > >>>>> > >>>>> _______________________________________________ >>>>> keycloak-dev mailing list >>>>> keycloak-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>> >>>> -- >>>> Vlastimil Elias >>>> Principal Software Engineer >>>> jboss.org Development Team >>>> >>>> >> -- >> Vlastimil Elias >> Principal Software Engineer >> jboss.org Development Team >> >> -- Vlastimil Elias Principal Software Engineer jboss.org Development Team From stian at redhat.com Tue Jul 14 04:06:30 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 14 Jul 2015 04:06:30 -0400 (EDT) Subject: [keycloak-dev] Operational monitoring of Keycloak server In-Reply-To: <55A4C12C.8070305@redhat.com> References: <55A3BA5C.2090906@redhat.com> <299925009.37235169.1436800699765.JavaMail.zimbra@redhat.com> <55A4AD75.1030203@redhat.com> <2071278650.37809022.1436856157015.JavaMail.zimbra@redhat.com> <55A4B2AB.9080508@redhat.com> <383530390.37875127.1436858054281.JavaMail.zimbra@redhat.com> <55A4C12C.8070305@redhat.com> Message-ID: <1137820905.37901015.1436861190539.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Vlastimil Elias" > To: "Stian Thorgersen" > Cc: "Scott Rossillo" , keycloak-dev at lists.jboss.org > Sent: Tuesday, 14 July, 2015 9:58:36 AM > Subject: Re: [keycloak-dev] Operational monitoring of Keycloak server > > On 14.7.2015 09:14, Stian Thorgersen wrote: > > > > ----- Original Message ----- > >> From: "Vlastimil Elias" > >> To: "Stian Thorgersen" > >> Cc: "Scott Rossillo" , > >> keycloak-dev at lists.jboss.org > >> Sent: Tuesday, 14 July, 2015 8:56:43 AM > >> Subject: Re: [keycloak-dev] Operational monitoring of Keycloak server > >> > >> > >> > >> On 14.7.2015 08:42, Stian Thorgersen wrote: > >>> Ok so we add one that just returns OK or ERROR which doesn't require > >>> authentication, but then we add another that can return more details, > >>> including stats and what the error is. > >> Yep. Simple http endpoinds for now, later all this info may be expose > >> over DMR or some other mechanism if necessary. > >>> For full health we should check all external services that are used (db, > >>> identity providers and user federation providers). Cluster sync will > >>> depend on what Infinispan exposes, but I imagine they'll have the > >>> required > >>> details avail. > >> Beside endpoint for full health check (which should summarize all > >> services into one flag if I understand correctly, which is good for > >> loadbalancer) we should expose separate endpoint for each service > >> health, as it is better for operational monitoring systems like Nagios. > >> Admins are better informed what is going wrong and they can resolve > >> situation more quickly without necessity to search cause of general > >> failure flag somewhere else. > > We could have a single health endpoint that returns a 200 or 500 and also > > returns a json doc with details. Something like: > > > > { > > realm: ok, > > users: ok, > > realmCache: error, > > userCache: error, > > identity-providers: { > > google: ok, > > facebook: error > > }, > > user-federation: { > > ldap: ok > > } > > } > > > > I wonder if that's to much details to expose without authentication. > > This should work, but I miss info about DB connection here. It is > crucial from operational point of view as this allows sysadmins quickly > detect that connection to DB is broken. > > I believe this kind of info can be safely exposed without > authentication. If the endpoint is clearly documented then access can be > always restricted on some network infra (webserver/proxy) ahead of KC. DB is "realm" and "users". > > > > >> Vl. > >> > >>> ----- Original Message ----- > >>>> From: "Vlastimil Elias" > >>>> To: "Scott Rossillo" , "Stian Thorgersen" > >>>> > >>>> Cc: keycloak-dev at lists.jboss.org > >>>> Sent: Tuesday, 14 July, 2015 8:34:29 AM > >>>> Subject: Re: [keycloak-dev] Operational monitoring of Keycloak server > >>>> > >>>> Yap, beside server-stat endpoint Stian talked about we should add some > >>>> server-health endpoint also to be used for remote health monitoring by > >>>> load balancers or systems like Nagios. > >>>> Simple http endpoint without authentication (as it doesn't leak any > >>>> sensitive information) is typically simplest way how to do this > >>>> monitoring. > >>>> > >>>> Vl. > >>>> > >>>> On 14.7.2015 05:13, Scott Rossillo wrote: > >>>>> Some type of health page would be great too for load balancers to > >>>>> monitor. Something that doesn't leak internal information but checks > >>>>> behind the scenes that: > >>>>> 1. Server can reach its databas(es) > >>>>> 2. Server cluster sync is working > >>>>> 3. Server can reach federation providers, etc. > >>>>> Endpoint should respond to get requests and return an http status > >>>>> reflective of server state. > >>>>> > >>>>> On Mon, Jul 13, 2015 at 11:18 AM Stian Thorgersen >>>>> > wrote: > >>>>> > >>>>> So looks like we're at agreement to add the additional info you > >>>>> wanted to server info page. > >>>>> > >>>>> How about we add an additional endpoint server-stat that can > >>>>> collect some stats about the server? > >>>>> > >>>>> ----- Original Message ----- > >>>>> > From: "Vlastimil Elias" >>>>> > > >>>>> > To: "Stian Thorgersen" >>>>> > > > >>>>> > Cc: keycloak-dev at lists.jboss.org > >>>>> > >>>>> > Sent: Monday, 13 July, 2015 5:06:34 PM > >>>>> > Subject: Re: [keycloak-dev] Operational monitoring of Keycloak > >>>>> server > >>>>> > > >>>>> > Looks like I have to look at WildFly/EAP DMR to see what is > >>>>> possible to > >>>>> > do with it, as I'm not sure if it is about remote monitoring > >>>>> also and > >>>>> > if/how it can be use from monitoring systems like Splunk. > >>>>> > > >>>>> > Vl. > >>>>> > > >>>>> > On 13.7.2015 15:26, Stian Thorgersen wrote: > >>>>> > > In WildFly/EAP that's DMR right? We're planning to make > >>>>> Keycloak managable > >>>>> > > through that as well. For example everything that goes into > >>>>> > > keycloak-server.json will eventually be moved to > >>>>> standalone.xml. Same with > >>>>> > > admin endpoints, everything you can do there you'll > >>>>> > > eventually > >>>>> be able to > >>>>> > > do through DMR and jboss-cli as well. > >>>>> > > > >>>>> > > However, IMO it would make sense to at least expose Keycloak > >>>>> specific > >>>>> > > information through the admin endpoints and console as well. > >>>>> Such number > >>>>> > > of sessions, etc.. > >>>>> > > > >>>>> > > ----- Original Message ----- > >>>>> > >> From: "Vlastimil Elias" >>>>> > > >>>>> > >> To: keycloak-dev at lists.jboss.org > >>>>> > >>>>> > >> Sent: Monday, 13 July, 2015 3:17:16 PM > >>>>> > >> Subject: [keycloak-dev] Operational monitoring of Keycloak > >>>>> > >> server > >>>>> > >> > >>>>> > >> Hi, > >>>>> > >> > >>>>> > >> as we deployed KC to production mode for > >>>>> https://developers.redhat.com > >>>>> > >> we started to think about operational monitoring, for > >>>>> > >> example > >>>>> from > >>>>> > >> Nagios or other systems of this type. > >>>>> > >> > >>>>> > >> KC user guide doesn't contain any chapter covering this > >>>>> topic, also no > >>>>> > >> any success over google search, so looks like KC doesn't > >>>>> > >> have > >>>>> > >> any > >>>>> > >> solution for this yet. > >>>>> > >> But I believe this is an important area which must be solved > >>>>> when KC is > >>>>> > >> used for production. > >>>>> > >> > >>>>> > >> I can imagine monitoring of JDBC connection if JPA is used, > >>>>> monitoring > >>>>> > >> of Mongo connection if used as store, monitoring of LDAP > >>>>> connection if > >>>>> > >> LDAP federation is used etc. > >>>>> > >> Also some statistics like numbers of active sso session, > >>>>> number of > >>>>> > >> logins per minute etc should be provided there. > >>>>> > >> > >>>>> > >> Monitoring is not about Keycloak core itself, it should be > >>>>> available for > >>>>> > >> extension developers also. For example we implemented own > >>>>> > >> UserFederationProvider which calls backend REST services. > >>>>> > >> We should be able to add info about this integration into > >>>>> monitoring > >>>>> > >> endpoint to be able to catch problems with this REST API. > >>>>> > >> > >>>>> > >> It should be probably implemented same way as used by > >>>>> > >> underlying > >>>>> > >> WildFly/EAP (JPA/JDBC is probably available for monitoring > >>>>> there). I'm > >>>>> > >> not sure if JMX is used there still or if some new framework > >>>>> > >> is > >>>>> > >> available for it. > >>>>> > >> Or KC should use some form of KC REST API for this, which > >>>>> should be > >>>>> > >> extended by additional info from KC extensions? > >>>>> > >> > >>>>> > >> What do you think? > >>>>> > >> > >>>>> > >> Vlastimil > >>>>> > >> > >>>>> > >> P.S we have https://issues.jboss.org/browse/RHD-552 for Red > >>>>> > >> Hat > >>>>> > >> Developer instance of KC > >>>>> > >> > >>>>> > >> -- > >>>>> > >> 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 > >>>>> > > >>>>> > > >>>>> _______________________________________________ > >>>>> keycloak-dev mailing list > >>>>> keycloak-dev at lists.jboss.org > >>>>> > >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>>> > >>>> -- > >>>> Vlastimil Elias > >>>> Principal Software Engineer > >>>> jboss.org Development Team > >>>> > >>>> > >> -- > >> Vlastimil Elias > >> Principal Software Engineer > >> jboss.org Development Team > >> > >> > > -- > Vlastimil Elias > Principal Software Engineer > jboss.org Development Team > > From velias at redhat.com Tue Jul 14 05:22:32 2015 From: velias at redhat.com (Vlastimil Elias) Date: Tue, 14 Jul 2015 11:22:32 +0200 Subject: [keycloak-dev] Improve first login with identity provider In-Reply-To: <468566795.37895483.1436860183378.JavaMail.zimbra@redhat.com> References: <468566795.37895483.1436860183378.JavaMail.zimbra@redhat.com> Message-ID: <55A4D4D8.9020808@redhat.com> +1000 for all of these improvements On 14.7.2015 09:49, Stian Thorgersen wrote: > We should improve the first login with identity provider flow as it's less than elegant at the moment. Some of the suggestion below is how it already works and some not! > > The mechanism to detect existing accounts should include: > > * Username > * Email > * Firstname and lastname > > This needs to work both initially on the callback from the identity provider, but also after the user has updated the profile. If an existing account is detected the user should be given the option to do one of the following: > > * Cancel > * Merge - this will require the user to authenticate as the existing user. Once authenticated the attributes, roles and identity-provider links from the new user are copied to the existing user (not overriding existing attributes/roles/links) > * Continue - only if existing account is found by firstname and lastname > > For this to work it's probably easier to initially always create the account. To get around the case where email is duplicated we can set that as an temporary attribute rather than the email. > > We also need to make sure we can define what attributes are required for a user in a realm, including validation of each attribute. If any of these attributes are missing the user will have to update the profile. > > Finally, we should add a expires on a user account. If a user initiates the login with an identity provider, but never completes the above actions (for example closes the browser on the existing account screen, or the update profile screen) the account should automatically be removed after a given time. > > With regards to required actions it should be possible to configure one or more required actions for first login for a specific identity provider. > > It would be nice to nail down this flow once and for all! If we can all agree on the flow, we can allocate someone to implement it for 1.5. > _______________________________________________ > 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 Tue Jul 14 05:56:47 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 14 Jul 2015 05:56:47 -0400 (EDT) Subject: [keycloak-dev] Git History w/merges of upstream/master In-Reply-To: References: <18172C9C-E1B4-48ED-8E1A-9B2B8D927EA3@smartling.com> <55A0DC91.2060905@redhat.com> Message-ID: <2028460970.38027447.1436867807785.JavaMail.zimbra@redhat.com> In most cases a PR should be squashed into a single commit, but we should always send PRs and merge using GitHub as that runs Travis on the PR before committing. ----- Original Message ----- > From: "Scott Rossillo" > To: "Marek Posolda" , "keycloak-dev" > Sent: Saturday, 11 July, 2015 2:40:52 PM > Subject: Re: [keycloak-dev] Git History w/merges of upstream/master > > Not a problem with PRs. I'd just say rebase before sending w PR rather than > merging upstream/master. > > I was just suggesting anyway. Not a real issue. > On Sat, Jul 11, 2015 at 5:06 AM Marek Posolda < mposolda at redhat.com > wrote: > > > I don't have strong opinion on it. I am personally always doing rebase > before sending PR to the master. And I agree that rebase is cleaner than > merge. > > But unfortunately if you want to merge pull requests automatically on > github (Clicking on button "Merge pull request" ), github will always > merge the PR, not rebase. For the really linear commit history, we will > need to avoid merging PRs in the github UI, which is more work for the > person, who is merging the PR... > > Marek > > On 11.7.2015 03:54, Scott Rossillo wrote: > > Not the biggest deal, but always see commits like: > > > > "Merge remote-tracking branch 'upstream/master? commits" > > > > If you `git pull ?rebase` you can avoid these and the project history will > > be a lot cleaner. > > > > ~ Scott > > > > > > > > > > _______________________________________________ > > 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 Jul 14 06:19:48 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 14 Jul 2015 06:19:48 -0400 (EDT) Subject: [keycloak-dev] Heads up! Unify line endings In-Reply-To: <1672987888.38036788.1436869105323.JavaMail.zimbra@redhat.com> Message-ID: <1684320731.38038151.1436869188885.JavaMail.zimbra@redhat.com> I'm applying the changes Lukas proposed with regards to line endings tomorrow. This shouldn't have any impacts on merging changes, but just in case LET ME KNOW ASAP if you have a large amount of uncommitted changes and we'll hold off just in case. From mposolda at redhat.com Tue Jul 14 09:05:06 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 14 Jul 2015 15:05:06 +0200 Subject: [keycloak-dev] Improve first login with identity provider In-Reply-To: <55A4D4D8.9020808@redhat.com> References: <468566795.37895483.1436860183378.JavaMail.zimbra@redhat.com> <55A4D4D8.9020808@redhat.com> Message-ID: <55A50902.8040702@redhat.com> +1 for do it like this. It seems the biggest challenge is merging the accounts. Not sure if it's better creating temporary user accounts or rather keep all the state in ClientSession. It seems the both approaches has pros and cons... Do we want to support linking multiple accounts during single authentication? It looks we should support it too to have all the things covered properly. I mean the usecase like: 1) User is registered with username/password and email "john at gmail.com" 2) User clicks to "Sign in with Facebook" and authenticates. Keycloak displays "There is already account with john at gmail.com. Do you want to merge account?" 3) Now login screen is displayed again (IMO it should be without Facebook button this time) and user click to "Sign in with Google" 4) Keycloak again displays "There is already account with john at gmail.com. Do you want to merge account?" 5) Now login screen is displayed again (without both Facebook and Google buttons) and user finally login with username/password . After authentication is user john at gmail.com linked with both Facebok and Google Marek On 14.7.2015 11:22, Vlastimil Elias wrote: > +1000 for all of these improvements > > On 14.7.2015 09:49, Stian Thorgersen wrote: >> We should improve the first login with identity provider flow as it's less than elegant at the moment. Some of the suggestion below is how it already works and some not! >> >> The mechanism to detect existing accounts should include: >> >> * Username >> * Email >> * Firstname and lastname >> >> This needs to work both initially on the callback from the identity provider, but also after the user has updated the profile. If an existing account is detected the user should be given the option to do one of the following: >> >> * Cancel >> * Merge - this will require the user to authenticate as the existing user. Once authenticated the attributes, roles and identity-provider links from the new user are copied to the existing user (not overriding existing attributes/roles/links) >> * Continue - only if existing account is found by firstname and lastname >> >> For this to work it's probably easier to initially always create the account. To get around the case where email is duplicated we can set that as an temporary attribute rather than the email. >> >> We also need to make sure we can define what attributes are required for a user in a realm, including validation of each attribute. If any of these attributes are missing the user will have to update the profile. >> >> Finally, we should add a expires on a user account. If a user initiates the login with an identity provider, but never completes the above actions (for example closes the browser on the existing account screen, or the update profile screen) the account should automatically be removed after a given time. >> >> With regards to required actions it should be possible to configure one or more required actions for first login for a specific identity provider. >> >> It would be nice to nail down this flow once and for all! If we can all agree on the flow, we can allocate someone to implement it for 1.5. >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Tue Jul 14 09:09:25 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 14 Jul 2015 15:09:25 +0200 Subject: [keycloak-dev] Docs for older versions Message-ID: <55A50A05.2020901@redhat.com> It looks the docs http://keycloak.github.io/docs/userguide/html/index.html covers just latest version. Shouldn't we add the version to the URL and keep the docs for older versions as well? I mean something like: http://keycloak.github.io/docs/1.3.1.Final/userguide/html/index.html . The problem is that many people are still on older Keycloak version and if they look into latest docs, there are some informations which are not valid for the older versions (For example see keycloak-user mailing thread from today with subject "Dump user profile data from Social Identity Provider" ) Marek From stian at redhat.com Tue Jul 14 09:15:05 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 14 Jul 2015 09:15:05 -0400 (EDT) Subject: [keycloak-dev] Improve first login with identity provider In-Reply-To: <55A50902.8040702@redhat.com> References: <468566795.37895483.1436860183378.JavaMail.zimbra@redhat.com> <55A4D4D8.9020808@redhat.com> <55A50902.8040702@redhat.com> Message-ID: <264811219.38208150.1436879705647.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Marek Posolda" > To: "Vlastimil Elias" , keycloak-dev at lists.jboss.org > Sent: Tuesday, 14 July, 2015 3:05:06 PM > Subject: Re: [keycloak-dev] Improve first login with identity provider > > +1 for do it like this. It seems the biggest challenge is merging the > accounts. Not sure if it's better creating temporary user accounts or > rather keep all the state in ClientSession. It seems the both approaches > has pros and cons... > > Do we want to support linking multiple accounts during single > authentication? It looks we should support it too to have all the things > covered properly. I mean the usecase like: > > 1) User is registered with username/password and email "john at gmail.com" > 2) User clicks to "Sign in with Facebook" and authenticates. Keycloak > displays "There is already account with john at gmail.com. Do you want to > merge account?" > 3) Now login screen is displayed again (IMO it should be without > Facebook button this time) and user click to "Sign in with Google" > 4) Keycloak again displays "There is already account with > john at gmail.com. Do you want to merge account?" > 5) Now login screen is displayed again (without both Facebook and Google > buttons) and user finally login with username/password . After > authentication is user john at gmail.com linked with both Facebok and Google Yes, but I had a different approach in mind: 1) User is registered with username/password and email "john at gmail.com" 2) User clicks to "Sign in with Facebook" and authenticates. Keycloak creates the account, but sets the email address 'john at gmail.com' as an tmp attribute. Then it displays existing account blah blah, do you want to merge? 3) User clicks merge and is shown a login screen without username, but only password (and any linked identity providers) 4) Once user is logged in the account created in step 2 is merged with the account created in step 1. After it's merged the account from step 2 is deleted. This lets the user merge the account from Facebook at any point as long as it's within the expiration time. Newly created (but not active accounts, i.e. outstanding required actions) will have a expiration time and be removed by a background thread. > > Marek > > On 14.7.2015 11:22, Vlastimil Elias wrote: > > +1000 for all of these improvements > > > > On 14.7.2015 09:49, Stian Thorgersen wrote: > >> We should improve the first login with identity provider flow as it's less > >> than elegant at the moment. Some of the suggestion below is how it > >> already works and some not! > >> > >> The mechanism to detect existing accounts should include: > >> > >> * Username > >> * Email > >> * Firstname and lastname > >> > >> This needs to work both initially on the callback from the identity > >> provider, but also after the user has updated the profile. If an existing > >> account is detected the user should be given the option to do one of the > >> following: > >> > >> * Cancel > >> * Merge - this will require the user to authenticate as the existing user. > >> Once authenticated the attributes, roles and identity-provider links from > >> the new user are copied to the existing user (not overriding existing > >> attributes/roles/links) > >> * Continue - only if existing account is found by firstname and lastname > >> > >> For this to work it's probably easier to initially always create the > >> account. To get around the case where email is duplicated we can set that > >> as an temporary attribute rather than the email. > >> > >> We also need to make sure we can define what attributes are required for a > >> user in a realm, including validation of each attribute. If any of these > >> attributes are missing the user will have to update the profile. > >> > >> Finally, we should add a expires on a user account. If a user initiates > >> the login with an identity provider, but never completes the above > >> actions (for example closes the browser on the existing account screen, > >> or the update profile screen) the account should automatically be removed > >> after a given time. > >> > >> With regards to required actions it should be possible to configure one or > >> more required actions for first login for a specific identity provider. > >> > >> It would be nice to nail down this flow once and for all! If we can all > >> agree on the flow, we can allocate someone to implement it for 1.5. > >> _______________________________________________ > >> 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 Jul 14 09:15:58 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 14 Jul 2015 09:15:58 -0400 (EDT) Subject: [keycloak-dev] Docs for older versions In-Reply-To: <55A50A05.2020901@redhat.com> References: <55A50A05.2020901@redhat.com> Message-ID: <1004181609.38208636.1436879758424.JavaMail.zimbra@redhat.com> -1 IMO we shouldn't support old versions - docs are available to download through SourceForge ----- Original Message ----- > From: "Marek Posolda" > To: keycloak-dev at lists.jboss.org > Sent: Tuesday, 14 July, 2015 3:09:25 PM > Subject: [keycloak-dev] Docs for older versions > > It looks the docs > http://keycloak.github.io/docs/userguide/html/index.html covers just > latest version. Shouldn't we add the version to the URL and keep the > docs for older versions as well? I mean something like: > http://keycloak.github.io/docs/1.3.1.Final/userguide/html/index.html . > > The problem is that many people are still on older Keycloak version and > if they look into latest docs, there are some informations which are not > valid for the older versions (For example see keycloak-user mailing > thread from today with subject "Dump user profile data from Social > Identity Provider" ) > > Marek > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bburke at redhat.com Tue Jul 14 09:52:47 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 14 Jul 2015 09:52:47 -0400 Subject: [keycloak-dev] Improve first login with identity provider In-Reply-To: <468566795.37895483.1436860183378.JavaMail.zimbra@redhat.com> References: <468566795.37895483.1436860183378.JavaMail.zimbra@redhat.com> Message-ID: <55A5142F.4020205@redhat.com> I'm not convinced this is a slam dunk. I think what you are suggesting is a pain in the ass for users. Why would users ever care if accounts are linked? I don't ever see social sites prompting me to merge or link accounts. I have never linked social provider accounts on any website. Users should never be prompted beyond the initial login for anything if at all possible. In most cases, I think the default behavior should be to just have separate UserModels and store the email in an attribute. IMO, the vast majority of applications will work in this manner. Linking will be rare. IMO, I think jboss.org should work in this way too. WTF do users care if their accounts are linked or not for JBoss.org? They probably don't. And will probably be annoyed when they are required to do so. IMO, only email should be used to detect existing accounts. Google "Bill Burke" and you will get 56 million results. No, I'm not that popular, but my name is! Also the username bburke, bill.burke, or wburke is usually taken whenever I create an account on a social site. There's really two scenarios here. 1) User login 2) User wants to link accounts in Account Service page. For User login, there should be a global config page for IDP federation with a "duplicate account policy" with these options: * "None" - store email in an attribute * "Prompt" - prompt user if they want to merge and require them to login with the other accounts * "Require" - require the user to merge their accounts * "Trust" - trust the providers and automatically merge. Each IDP could have a switch "Trusted". With options of "always", "email-verified", "not-trusted". For merging, IMO, UserModels should never be deleted. A user may have made forum posts or done other actions under that userid. Instead that UserModel should be disabled and linked to the master UserModel. On 7/14/2015 3:49 AM, Stian Thorgersen wrote: > We should improve the first login with identity provider flow as it's less than elegant at the moment. Some of the suggestion below is how it already works and some not! > > The mechanism to detect existing accounts should include: > > * Username > * Email > * Firstname and lastname > > This needs to work both initially on the callback from the identity provider, but also after the user has updated the profile. If an existing account is detected the user should be given the option to do one of the following: > > * Cancel > * Merge - this will require the user to authenticate as the existing user. Once authenticated the attributes, roles and identity-provider links from the new user are copied to the existing user (not overriding existing attributes/roles/links) > * Continue - only if existing account is found by firstname and lastname > > For this to work it's probably easier to initially always create the account. To get around the case where email is duplicated we can set that as an temporary attribute rather than the email. > > We also need to make sure we can define what attributes are required for a user in a realm, including validation of each attribute. If any of these attributes are missing the user will have to update the profile. > > Finally, we should add a expires on a user account. If a user initiates the login with an identity provider, but never completes the above actions (for example closes the browser on the existing account screen, or the update profile screen) the account should automatically be removed after a given time. > > With regards to required actions it should be possible to configure one or more required actions for first login for a specific identity provider. > > It would be nice to nail down this flow once and for all! If we can all agree on the flow, we can allocate someone to implement it for 1.5. > _______________________________________________ > 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 Tue Jul 14 10:30:54 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 14 Jul 2015 16:30:54 +0200 Subject: [keycloak-dev] Improve first login with identity provider In-Reply-To: <264811219.38208150.1436879705647.JavaMail.zimbra@redhat.com> References: <468566795.37895483.1436860183378.JavaMail.zimbra@redhat.com> <55A4D4D8.9020808@redhat.com> <55A50902.8040702@redhat.com> <264811219.38208150.1436879705647.JavaMail.zimbra@redhat.com> Message-ID: <55A51D1E.2010607@redhat.com> On 14.7.2015 15:15, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Marek Posolda" >> To: "Vlastimil Elias" , keycloak-dev at lists.jboss.org >> Sent: Tuesday, 14 July, 2015 3:05:06 PM >> Subject: Re: [keycloak-dev] Improve first login with identity provider >> >> +1 for do it like this. It seems the biggest challenge is merging the >> accounts. Not sure if it's better creating temporary user accounts or >> rather keep all the state in ClientSession. It seems the both approaches >> has pros and cons... >> >> Do we want to support linking multiple accounts during single >> authentication? It looks we should support it too to have all the things >> covered properly. I mean the usecase like: >> >> 1) User is registered with username/password and email "john at gmail.com" >> 2) User clicks to "Sign in with Facebook" and authenticates. Keycloak >> displays "There is already account with john at gmail.com. Do you want to >> merge account?" >> 3) Now login screen is displayed again (IMO it should be without >> Facebook button this time) and user click to "Sign in with Google" >> 4) Keycloak again displays "There is already account with >> john at gmail.com. Do you want to merge account?" >> 5) Now login screen is displayed again (without both Facebook and Google >> buttons) and user finally login with username/password . After >> authentication is user john at gmail.com linked with both Facebok and Google > Yes, but I had a different approach in mind: > > 1) User is registered with username/password and email "john at gmail.com" > 2) User clicks to "Sign in with Facebook" and authenticates. Keycloak creates the account, but sets the email address 'john at gmail.com' as an tmp attribute. Then it displays existing account blah blah, do you want to merge? > 3) User clicks merge and is shown a login screen without username, but only password (and any linked identity providers) > 4) Once user is logged in the account created in step 2 is merged with the account created in step 1. After it's merged the account from step 2 is deleted. > > This lets the user merge the account from Facebook at any point as long as it's within the expiration time. Newly created (but not active accounts, i.e. outstanding required actions) will have a expiration time and be removed by a background thread. Yeah, I agree with creating separate temporary accounts. Was just wondering about use-case with chaining multiple identity providers during single authentication (both Facebook and Google). In this case, there will be 2 temporary accounts, so the question is if: - The "facebook" temporary account is merged with "google" temporary account after successful Google authentication (my step 4) - Both "facebook" and "google" temporary accounts are merged with the original john at gmail.com account after authentication is completely finished (my step 5) but maybe this is implementation detail? Not sure... IMO the period for keep these temporary accounts should be really small. I think user should finish the authentication (which will delete temporary accounts) within minutes (not the other day or so) and shouldn't never be assigned access token to. Otherwise there might be issues with temporary account already linked with some application data etc... Also for your step (3), we don't want to be limited just for the default password form right? I think that with Authentication SPI, people may want various authentication mechanisms (maybe some don't even want to use password at all). The tricky part is, that username is already known and we want people to just provide credentials (aka password) . But IMO if we limit only to form with password + identity providers, the issue will return again after some time... Marek >> Marek >> >> On 14.7.2015 11:22, Vlastimil Elias wrote: >>> +1000 for all of these improvements >>> >>> On 14.7.2015 09:49, Stian Thorgersen wrote: >>>> We should improve the first login with identity provider flow as it's less >>>> than elegant at the moment. Some of the suggestion below is how it >>>> already works and some not! >>>> >>>> The mechanism to detect existing accounts should include: >>>> >>>> * Username >>>> * Email >>>> * Firstname and lastname >>>> >>>> This needs to work both initially on the callback from the identity >>>> provider, but also after the user has updated the profile. If an existing >>>> account is detected the user should be given the option to do one of the >>>> following: >>>> >>>> * Cancel >>>> * Merge - this will require the user to authenticate as the existing user. >>>> Once authenticated the attributes, roles and identity-provider links from >>>> the new user are copied to the existing user (not overriding existing >>>> attributes/roles/links) >>>> * Continue - only if existing account is found by firstname and lastname >>>> >>>> For this to work it's probably easier to initially always create the >>>> account. To get around the case where email is duplicated we can set that >>>> as an temporary attribute rather than the email. >>>> >>>> We also need to make sure we can define what attributes are required for a >>>> user in a realm, including validation of each attribute. If any of these >>>> attributes are missing the user will have to update the profile. >>>> >>>> Finally, we should add a expires on a user account. If a user initiates >>>> the login with an identity provider, but never completes the above >>>> actions (for example closes the browser on the existing account screen, >>>> or the update profile screen) the account should automatically be removed >>>> after a given time. >>>> >>>> With regards to required actions it should be possible to configure one or >>>> more required actions for first login for a specific identity provider. >>>> >>>> It would be nice to nail down this flow once and for all! If we can all >>>> agree on the flow, we can allocate someone to implement it for 1.5. >>>> _______________________________________________ >>>> 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 Jul 14 11:11:52 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 14 Jul 2015 11:11:52 -0400 Subject: [keycloak-dev] Improve first login with identity provider In-Reply-To: <55A51D1E.2010607@redhat.com> References: <468566795.37895483.1436860183378.JavaMail.zimbra@redhat.com> <55A4D4D8.9020808@redhat.com> <55A50902.8040702@redhat.com> <264811219.38208150.1436879705647.JavaMail.zimbra@redhat.com> <55A51D1E.2010607@redhat.com> Message-ID: <55A526B8.90506@redhat.com> On 7/14/2015 10:30 AM, Marek Posolda wrote: > On 14.7.2015 15:15, Stian Thorgersen wrote: >> >> ----- Original Message ----- >>> From: "Marek Posolda" >>> To: "Vlastimil Elias" , keycloak-dev at lists.jboss.org >>> Sent: Tuesday, 14 July, 2015 3:05:06 PM >>> Subject: Re: [keycloak-dev] Improve first login with identity provider >>> >>> +1 for do it like this. It seems the biggest challenge is merging the >>> accounts. Not sure if it's better creating temporary user accounts or >>> rather keep all the state in ClientSession. It seems the both approaches >>> has pros and cons... >>> >>> Do we want to support linking multiple accounts during single >>> authentication? It looks we should support it too to have all the things >>> covered properly. I mean the usecase like: >>> >>> 1) User is registered with username/password and email "john at gmail.com" >>> 2) User clicks to "Sign in with Facebook" and authenticates. Keycloak >>> displays "There is already account with john at gmail.com. Do you want to >>> merge account?" >>> 3) Now login screen is displayed again (IMO it should be without >>> Facebook button this time) and user click to "Sign in with Google" >>> 4) Keycloak again displays "There is already account with >>> john at gmail.com. Do you want to merge account?" >>> 5) Now login screen is displayed again (without both Facebook and Google >>> buttons) and user finally login with username/password . After >>> authentication is user john at gmail.com linked with both Facebok and Google >> Yes, but I had a different approach in mind: >> >> 1) User is registered with username/password and email "john at gmail.com" >> 2) User clicks to "Sign in with Facebook" and authenticates. Keycloak creates the account, but sets the email address 'john at gmail.com' as an tmp attribute. Then it displays existing account blah blah, do you want to merge? >> 3) User clicks merge and is shown a login screen without username, but only password (and any linked identity providers) >> 4) Once user is logged in the account created in step 2 is merged with the account created in step 1. After it's merged the account from step 2 is deleted. >> >> This lets the user merge the account from Facebook at any point as long as it's within the expiration time. Newly created (but not active accounts, i.e. outstanding required actions) will have a expiration time and be removed by a background thread. > Yeah, I agree with creating separate temporary accounts. Was just > wondering about use-case with chaining multiple identity providers > during single authentication (both Facebook and Google). In this case, > there will be 2 temporary accounts, so the question is if: > - The "facebook" temporary account is merged with "google" temporary > account after successful Google authentication (my step 4) > - Both "facebook" and "google" temporary accounts are merged with the > original john at gmail.com account after authentication is completely > finished (my step 5) > > but maybe this is implementation detail? Not sure... > > IMO the period for keep these temporary accounts should be really small. > I think user should finish the authentication (which will delete > temporary accounts) within minutes (not the other day or so) and > shouldn't never be assigned access token to. Otherwise there might be > issues with temporary account already linked with some application data > etc... > > Also for your step (3), we don't want to be limited just for the default > password form right? I think that with Authentication SPI, people may > want various authentication mechanisms (maybe some don't even want to > use password at all). The tricky part is, that username is already known > and we want people to just provide credentials (aka password) . But IMO > if we limit only to form with password + identity providers, the issue > will return again after some time... > This is WAY too complicated. Please see my long previous email. There should never be any temporary accounts. I'll summarize my previous email again: * Existing accounts should only be detected by email. "Bill Burke" gets 56 million hits on Google. It is a very common name. Default behavior: 1) User registers with "bburke at redhat.com" and password 2) User does a social login, new account is created "bburke at redhat.com" is stored in a user attribute. i.e. "Alternative email". Website requires linking: 1) User registers with "bburke at redhat.com" and password 2) User logins with Facebook, "bburke at redhat.com" exists. Prompted "Account exists with same email you have registered at Facebook. You have been sent an email verification message. Please follow the directions of this email to login" 3) User goes to Inbox, clicks link in email, message screen appears "Your Facebook account has been linked. Click "Ok" to continue.". User gets forwarded to website. 4) Facebook is linked to pre-existing "bburke at redhat.com" account. This would be implemented with Authentication Flows. There would be no temporary account. Step #2 would create a ClientSession model and store all the facebook metadata within it. Step #3 would import the facebook metadata. Alternatively, you could just trust the IDP and do the link automatically. Does Google et. al. send an "email-verified" metadata? User wants to link accounts: 1) User goes to Account Service, Account LInking page 2) User is provided with list of IDPs i.e. (Facebook, Google, etc). And clicks one. 3) User is prompted to login via that IDP 4) User receives prompt "Your Facebook account has been linked. Click "OK" to continue". User gets forwarded to website. In this scenario, there is no removal of old accounts. The initiating account,X, would import the old Facebook account, Y. X would create a new federation link to Facebook. Y would be disabled and its facebook link removed. Y is marked as "merged" or "linked" and points to account X. You need to keep Y around as the user may have done a bunch of actions under that account...i.e. posted on jboss.org forums. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Tue Jul 14 13:01:16 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 14 Jul 2015 13:01:16 -0400 Subject: [keycloak-dev] RealmRep needs to be human craftable? Message-ID: <55A5405C.80704@redhat.com> In implementing import/export for authentication flows, i realized that it is not very human craftable. That is, not easy for a human to create a json rep of authentication flows. Do we still need to support that case? -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From mposolda at redhat.com Tue Jul 14 14:17:54 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 14 Jul 2015 20:17:54 +0200 Subject: [keycloak-dev] Requirements to Elytron for Client 2-way SSL authentication Message-ID: <55A55252.5030804@redhat.com> I want to doublecheck if we are on the same page regarding how client certificate authentication should work, so we know what are the requirements for Elytron to support it. This will allow us to improve things before the Elytron code freeze (end of August AFAIK) if needed. Right now, I am covering just Service accounts and authenticating of clients with the certificate. But I believe that for authenticate of users, the requirements will be similar. My view is: - Admin will upload certificate of some client via Keycloak admin console. (I guess many companies want to use their own certificate issued by their trusted CA. IMO later Keycloak should provide the ability to easily generate trusted certificates and act as CA - not sure if it's something Giriraj is looking at. But for now, I assume that trusted certificate is always provided by admin and uploaded to Keycloak admin console) - There is REST endpoint, which allows to authenticate with client certificate. For example "https://localhost:8443/auth/realms/demo/clients/certificate" . Client will be able to start SSL handshake with it's certificate when sending request to this endpoint. Server will then verify the underlying SSLSession from the SSL socket and check that valid client certificate was provided during handshake. It will authenticate client based on that. To cover this usecase, the Wildfly/Elytron should be able to: 1) Support "variable" 2-way SSL . In other words, there is possibility to set flag "setWantClientAuth(true)" in underlying SSLServerSocket. This means that I will be able to access admin console "https://localhost:8443/auth/admin" with my browser without client certificate, but I will be able to provide client certificate on the endpoint "https://localhost:8443/auth/realms/demo/clients/certificate" , which is deployed under same context 2) Dynamically upload it's truststore at runtime or provide SPI to add/remove/update certificates in truststore. This is needed, so that when admin uploads the certificate of client in KC admin console, I want my client to be able to authenticate with the certificate immediatelly without need to restart server and edit any JKS files . 3) Possibility to access underlying SSL Socket and SSL Session from the REST endpoint, so I am able to verify the certificate in REST endpoint (but maybe this one could be handled with our server subsystem if it's not available for normal apps?) WDYT? Am I missing something? Marek From marcelo.sampaio at serpro.gov.br Tue Jul 14 14:24:14 2015 From: marcelo.sampaio at serpro.gov.br (Marcelo Arthur Sampaio) Date: Tue, 14 Jul 2015 18:24:14 +0000 Subject: [keycloak-dev] Error when the value of "UUID LDAP attribute" is the same of the "Username LDAP attribute" Message-ID: <1c62c2e1be061ab1023743657e28243b28a4426d@serpro.gov.br> Hi, I get this error when the value of "UUID LDAP attribute" is the same of the? "Username LDAP attribute": Ex. "uid" Caused by: java.lang.NullPointerException ??? at org.keycloak.models.cache.DefaultCacheUserProvider.getUserByUsername(DefaultCacheUserProvider.java:149) [keycloak-invalidation-cache-model-1.3.1.Final.jar:1.3.1.Final] ??? at org.keycloak.federation.ldap.LDAPFederationProvider.importLDAPUsers(LDAPFederationProvider.java:391) The method org.keycloak.federation.ldap.LDAPUtils.getUsername(LDAPObject, LDAPConfig) dont return the username, because the attribute is not in the map. This occours because the uid is not added into the map of attributes. I looked at? org.keycloak.federation.ldap.idm.store.ldap.LDAPIdentityStore.populateAttributedType(SearchResult, Collection) line 402: ??????????????? if (ldapAttributeName.equalsIgnoreCase(getConfig().getUuidLDAPAttributeName())) { ??????????????????? Object uuidValue = ldapAttribute.get(); ??????????????????? ldapObject.setUuid(this.operationManager.decodeEntryUUID(uuidValue)); ??????????????? } else { ??????????????????? Set attrValues = new TreeSet<>(); ??????????????????? NamingEnumeration enumm = ldapAttribute.getAll(); ??????????????????? while (enumm.hasMoreElements()) { ??????????????????????? String attrVal = enumm.next().toString(); ??????????????????????? attrValues.add(attrVal); ??????????????????? } ... - "Esta mensagem do SERVI?O FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa p?blica federal regida pelo disposto na Lei Federal n? 5.615, ? enviada exclusivamente a seu destinat?rio e pode conter informa??es confidenciais, protegidas por sigilo profissional. Sua utiliza??o desautorizada ? ilegal e sujeita o infrator ?s penas da lei. Se voc? a recebeu indevidamente, queira, por gentileza, reenvi?-la ao emitente, esclarecendo o equ?voco." "This message from SERVI?O FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) -- a government company established under Brazilian law (5.615/70) -- is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150714/33585202/attachment.html From giriraj.sharma27 at gmail.com Tue Jul 14 14:50:58 2015 From: giriraj.sharma27 at gmail.com (Giriraj Sharma) Date: Wed, 15 Jul 2015 00:20:58 +0530 Subject: [keycloak-dev] Requirements to Elytron for Client 2-way SSL authentication In-Reply-To: <55A55252.5030804@redhat.com> References: <55A55252.5030804@redhat.com> Message-ID: HI Marek, I am basically looking after following high level use cases: * Create root CA and configure KC server * Create chained realm CA * Create cert for clients - and configure a WAR that uses it to auth the client * Create cert for user *We may have an abstract Keycloak CA which will simply act as the root CA. Certs of realms, users and clients will be signed via this root CA private key. Keycloak ssl will be configured with Keycloak abstract CA keys and certificates in standalone.xml . **Users will import their pkcs#12 or .pfx format of certificate and key into their browsers to enable mutual ssl auth. * *Admins will have ability to upload the root CA certificate/keys. In such a case, certs of realms, users and clients will be signed via the uploaded root CA's keys.* Configure Keycloak/WildFly SSL ... *So,In general, standalone.xml can be configured via Keycloak abstract CA's cert and key and users can import their pkcs#12 format into their browsers. I still need to dig around how to configure client war for client mutual SSL authentication with KC server.* On Tue, Jul 14, 2015 at 11:47 PM, Marek Posolda wrote: > I want to doublecheck if we are on the same page regarding how client > certificate authentication should work, so we know what are the > requirements for Elytron > to support it. This will allow us to improve things before the Elytron > code freeze (end of August AFAIK) if needed. > > Right now, I am covering just Service accounts and authenticating of > clients with the certificate. But I believe that for authenticate of > users, the requirements will be similar. > > My view is: > - Admin will upload certificate of some client via Keycloak admin > console. (I guess many companies want to use their own certificate > issued by their trusted CA. IMO later Keycloak should provide the > ability to easily generate trusted certificates and act as CA - not sure > if it's something Giriraj is looking at. But for now, I assume that > trusted certificate is always provided by admin and uploaded to Keycloak > admin console) > > - There is REST endpoint, which allows to authenticate with client > certificate. For example > "https://localhost:8443/auth/realms/demo/clients/certificate" . Client > will be able to start SSL handshake with it's certificate when sending > request to this endpoint. Server will then verify the underlying > SSLSession from the SSL socket and check that valid client certificate > was provided during handshake. It will authenticate client based on that. > > > To cover this usecase, the Wildfly/Elytron should be able to: > > 1) Support "variable" 2-way SSL . In other words, there is possibility > to set flag "setWantClientAuth(true)" in underlying SSLServerSocket. > This means that I will be able to access admin console > "https://localhost:8443/auth/admin" with my browser without client > certificate, but I will be able to provide client certificate on the > endpoint "https://localhost:8443/auth/realms/demo/clients/certificate" , > which is deployed under same context > > 2) Dynamically upload it's truststore at runtime or provide SPI to > add/remove/update certificates in truststore. This is needed, so that > when admin uploads the certificate of client in KC admin console, I want > my client to be able to authenticate with the certificate immediatelly > without need to restart server and edit any JKS files . > > 3) Possibility to access underlying SSL Socket and SSL Session from the > REST endpoint, so I am able to verify the certificate in REST endpoint > (but maybe this one could be handled with our server subsystem if it's > not available for normal apps?) > > WDYT? Am I missing something? > > Marek > _______________________________________________ > 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/20150715/2fda03fd/attachment-0001.html From mposolda at redhat.com Tue Jul 14 14:53:03 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 14 Jul 2015 20:53:03 +0200 Subject: [keycloak-dev] Requirements to Elytron for Client 2-way SSL authentication In-Reply-To: <55A55252.5030804@redhat.com> References: <55A55252.5030804@redhat.com> Message-ID: <55A55A8F.5070804@redhat.com> On 14.7.2015 20:17, Marek Posolda wrote: > I want to doublecheck if we are on the same page regarding how client > certificate authentication should work, so we know what are the > requirements for Elytron > to support it. This will allow us to improve things before the Elytron > code freeze (end of August AFAIK) if needed. > > Right now, I am covering just Service accounts and authenticating of > clients with the certificate. But I believe that for authenticate of > users, the requirements will be similar. > > My view is: > - Admin will upload certificate of some client via Keycloak admin > console. (I guess many companies want to use their own certificate > issued by their trusted CA. IMO later Keycloak should provide the > ability to easily generate trusted certificates and act as CA - not sure > if it's something Giriraj is looking at. But for now, I assume that > trusted certificate is always provided by admin and uploaded to Keycloak > admin console) > > - There is REST endpoint, which allows to authenticate with client > certificate. For example > "https://localhost:8443/auth/realms/demo/clients/certificate" . Client > will be able to start SSL handshake with it's certificate when sending > request to this endpoint. Server will then verify the underlying > SSLSession from the SSL socket and check that valid client certificate > was provided during handshake. It will authenticate client based on that. > > > To cover this usecase, the Wildfly/Elytron should be able to: > > 1) Support "variable" 2-way SSL . In other words, there is possibility > to set flag "setWantClientAuth(true)" in underlying SSLServerSocket. > This means that I will be able to access admin console > "https://localhost:8443/auth/admin" with my browser without client > certificate, but I will be able to provide client certificate on the > endpoint "https://localhost:8443/auth/realms/demo/clients/certificate" , > which is deployed under same context > > 2) Dynamically upload it's truststore at runtime or provide SPI to > add/remove/update certificates in truststore. This is needed, so that > when admin uploads the certificate of client in KC admin console, I want > my client to be able to authenticate with the certificate immediatelly > without need to restart server and edit any JKS files . ah, actually thinking that we can likely relax a bit on this one. As long as truststore contains root CA, the uploaded client certificates signed by that CA will be trusted too. So just need to check if elytron allows to trust certificates from provided truststore, which I hope shouldn't be an issue. Marek > > 3) Possibility to access underlying SSL Socket and SSL Session from the > REST endpoint, so I am able to verify the certificate in REST endpoint > (but maybe this one could be handled with our server subsystem if it's > not available for normal apps?) > > WDYT? Am I missing something? > > Marek > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From mposolda at redhat.com Tue Jul 14 14:56:59 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 14 Jul 2015 20:56:59 +0200 Subject: [keycloak-dev] Error when the value of "UUID LDAP attribute" is the same of the "Username LDAP attribute" In-Reply-To: <1c62c2e1be061ab1023743657e28243b28a4426d@serpro.gov.br> References: <1c62c2e1be061ab1023743657e28243b28a4426d@serpro.gov.br> Message-ID: <55A55B7B.5090203@redhat.com> Thanks for reporting this. Feel free to create JIRA and assign it to me. Thanks, Marek On 14.7.2015 20:24, Marcelo Arthur Sampaio wrote: > Hi, > > I get this error when the value of "UUID LDAP attribute" is the same > of the "Username LDAP attribute": Ex. "uid" > > Caused by: java.lang.NullPointerException > at > org.keycloak.models.cache.DefaultCacheUserProvider.getUserByUsername(DefaultCacheUserProvider.java:149) > [keycloak-invalidation-cache-model-1.3.1.Final.jar:1.3.1.Final] > at > org.keycloak.federation.ldap.LDAPFederationProvider.importLDAPUsers(LDAPFederationProvider.java:391) > > The method > org.keycloak.federation.ldap.LDAPUtils.getUsername(LDAPObject, LDAPConfig) > dont return the username, because the attribute is not in the map. > > This occours because the uid is not added into the map of attributes. > > I looked at > org.keycloak.federation.ldap.idm.store.ldap.LDAPIdentityStore.populateAttributedType(SearchResult, > Collection) line 402: > > if > (ldapAttributeName.equalsIgnoreCase(getConfig().getUuidLDAPAttributeName())) > { > Object uuidValue = ldapAttribute.get(); > ldapObject.setUuid(this.operationManager.decodeEntryUUID(uuidValue)); > } else { > Set attrValues = new TreeSet<>(); > NamingEnumeration enumm = ldapAttribute.getAll(); > while (enumm.hasMoreElements()) { > String attrVal = enumm.next().toString(); > attrValues.add(attrVal); > } ... > > > - > > > "Esta mensagem do SERVI?O FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), > empresa p?blica federal regida pelo disposto na Lei Federal n? 5.615, > ? enviada exclusivamente a seu destinat?rio e pode conter informa??es > confidenciais, protegidas por sigilo profissional. Sua utiliza??o > desautorizada ? ilegal e sujeita o infrator ?s penas da lei. Se voc? a > recebeu indevidamente, queira, por gentileza, reenvi?-la ao emitente, > esclarecendo o equ?voco." > > "This message from SERVI?O FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) > -- a government company established under Brazilian law (5.615/70) -- > is directed exclusively to its addressee and may contain confidential > data, protected under professional secrecy rules. Its unauthorized use > is illegal and may subject the transgressor to the law's penalties. If > you're not the addressee, please send it back, elucidating the failure." > > > _______________________________________________ > 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/20150714/baad555b/attachment.html From srossillo at smartling.com Tue Jul 14 15:16:12 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Tue, 14 Jul 2015 19:16:12 +0000 Subject: [keycloak-dev] Improve first login with identity provider In-Reply-To: <55A526B8.90506@redhat.com> References: <468566795.37895483.1436860183378.JavaMail.zimbra@redhat.com> <55A4D4D8.9020808@redhat.com> <55A50902.8040702@redhat.com> <264811219.38208150.1436879705647.JavaMail.zimbra@redhat.com> <55A51D1E.2010607@redhat.com> <55A526B8.90506@redhat.com> Message-ID: +1 for auto-merge. We modified the code to do that. I like Bill's approach with multiple options though as this is the most flexible and different people will have different requirements. On Tue, Jul 14, 2015 at 11:13 AM Bill Burke wrote: > > > On 7/14/2015 10:30 AM, Marek Posolda wrote: > > On 14.7.2015 15:15, Stian Thorgersen wrote: > >> > >> ----- Original Message ----- > >>> From: "Marek Posolda" > >>> To: "Vlastimil Elias" , > keycloak-dev at lists.jboss.org > >>> Sent: Tuesday, 14 July, 2015 3:05:06 PM > >>> Subject: Re: [keycloak-dev] Improve first login with identity provider > >>> > >>> +1 for do it like this. It seems the biggest challenge is merging the > >>> accounts. Not sure if it's better creating temporary user accounts or > >>> rather keep all the state in ClientSession. It seems the both > approaches > >>> has pros and cons... > >>> > >>> Do we want to support linking multiple accounts during single > >>> authentication? It looks we should support it too to have all the > things > >>> covered properly. I mean the usecase like: > >>> > >>> 1) User is registered with username/password and email "john at gmail.com > " > >>> 2) User clicks to "Sign in with Facebook" and authenticates. Keycloak > >>> displays "There is already account with john at gmail.com. Do you want to > >>> merge account?" > >>> 3) Now login screen is displayed again (IMO it should be without > >>> Facebook button this time) and user click to "Sign in with Google" > >>> 4) Keycloak again displays "There is already account with > >>> john at gmail.com. Do you want to merge account?" > >>> 5) Now login screen is displayed again (without both Facebook and > Google > >>> buttons) and user finally login with username/password . After > >>> authentication is user john at gmail.com linked with both Facebok and > Google > >> Yes, but I had a different approach in mind: > >> > >> 1) User is registered with username/password and email "john at gmail.com" > >> 2) User clicks to "Sign in with Facebook" and authenticates. Keycloak > creates the account, but sets the email address 'john at gmail.com' as an > tmp attribute. Then it displays existing account blah blah, do you want to > merge? > >> 3) User clicks merge and is shown a login screen without username, but > only password (and any linked identity providers) > >> 4) Once user is logged in the account created in step 2 is merged with > the account created in step 1. After it's merged the account from step 2 is > deleted. > >> > >> This lets the user merge the account from Facebook at any point as long > as it's within the expiration time. Newly created (but not active accounts, > i.e. outstanding required actions) will have a expiration time and be > removed by a background thread. > > Yeah, I agree with creating separate temporary accounts. Was just > > wondering about use-case with chaining multiple identity providers > > during single authentication (both Facebook and Google). In this case, > > there will be 2 temporary accounts, so the question is if: > > - The "facebook" temporary account is merged with "google" temporary > > account after successful Google authentication (my step 4) > > - Both "facebook" and "google" temporary accounts are merged with the > > original john at gmail.com account after authentication is completely > > finished (my step 5) > > > > but maybe this is implementation detail? Not sure... > > > > IMO the period for keep these temporary accounts should be really small. > > I think user should finish the authentication (which will delete > > temporary accounts) within minutes (not the other day or so) and > > shouldn't never be assigned access token to. Otherwise there might be > > issues with temporary account already linked with some application data > > etc... > > > > Also for your step (3), we don't want to be limited just for the default > > password form right? I think that with Authentication SPI, people may > > want various authentication mechanisms (maybe some don't even want to > > use password at all). The tricky part is, that username is already known > > and we want people to just provide credentials (aka password) . But IMO > > if we limit only to form with password + identity providers, the issue > > will return again after some time... > > > > This is WAY too complicated. Please see my long previous email. There > should never be any temporary accounts. I'll summarize my previous > email again: > > * Existing accounts should only be detected by email. "Bill Burke" gets > 56 million hits on Google. It is a very common name. > > Default behavior: > 1) User registers with "bburke at redhat.com" and password > 2) User does a social login, new account is created "bburke at redhat.com" > is stored in a user attribute. i.e. "Alternative email". > > Website requires linking: > 1) User registers with "bburke at redhat.com" and password > 2) User logins with Facebook, "bburke at redhat.com" exists. Prompted > "Account exists with same email you have registered at Facebook. You > have been sent an email verification message. Please follow the > directions of this email to login" > 3) User goes to Inbox, clicks link in email, message screen appears > "Your Facebook account has been linked. Click "Ok" to continue.". User > gets forwarded to website. > 4) Facebook is linked to pre-existing "bburke at redhat.com" account. > > This would be implemented with Authentication Flows. There would be no > temporary account. Step #2 would create a ClientSession model and store > all the facebook metadata within it. Step #3 would import the facebook > metadata. > > Alternatively, you could just trust the IDP and do the link > automatically. Does Google et. al. send an "email-verified" metadata? > > > User wants to link accounts: > 1) User goes to Account Service, Account LInking page > 2) User is provided with list of IDPs i.e. (Facebook, Google, etc). And > clicks one. > 3) User is prompted to login via that IDP > 4) User receives prompt "Your Facebook account has been linked. Click > "OK" to continue". User gets forwarded to website. > > In this scenario, there is no removal of old accounts. The initiating > account,X, would import the old Facebook account, Y. X would create a > new federation link to Facebook. Y would be disabled and its facebook > link removed. Y is marked as "merged" or "linked" and points to account > X. You need to keep Y around as the user may have done a bunch of > actions under that account...i.e. posted on jboss.org forums. > > > > -- > 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/20150714/87aa88cb/attachment-0001.html From srossillo at smartling.com Tue Jul 14 15:20:42 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Tue, 14 Jul 2015 19:20:42 +0000 Subject: [keycloak-dev] Docs for older versions In-Reply-To: <1004181609.38208636.1436879758424.JavaMail.zimbra@redhat.com> References: <55A50A05.2020901@redhat.com> <1004181609.38208636.1436879758424.JavaMail.zimbra@redhat.com> Message-ID: +1 Keeping docs doesn't mean it's supported. JDK and Spring framework docs are still hosted even if not supported anymore. It's a useful reference even once past eol. On Tue, Jul 14, 2015 at 9:17 AM Stian Thorgersen wrote: > -1 IMO we shouldn't support old versions - docs are available to download > through SourceForge > > ----- Original Message ----- > > From: "Marek Posolda" > > To: keycloak-dev at lists.jboss.org > > Sent: Tuesday, 14 July, 2015 3:09:25 PM > > Subject: [keycloak-dev] Docs for older versions > > > > It looks the docs > > http://keycloak.github.io/docs/userguide/html/index.html covers just > > latest version. Shouldn't we add the version to the URL and keep the > > docs for older versions as well? I mean something like: > > http://keycloak.github.io/docs/1.3.1.Final/userguide/html/index.html . > > > > The problem is that many people are still on older Keycloak version and > > if they look into latest docs, there are some informations which are not > > valid for the older versions (For example see keycloak-user mailing > > thread from today with subject "Dump user profile data from Social > > Identity Provider" ) > > > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150714/e992c284/attachment.html From bburke at redhat.com Tue Jul 14 16:48:28 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 14 Jul 2015 16:48:28 -0400 Subject: [keycloak-dev] Requirements to Elytron for Client 2-way SSL authentication In-Reply-To: <55A55252.5030804@redhat.com> References: <55A55252.5030804@redhat.com> Message-ID: <55A5759C.4090609@redhat.com> On 7/14/2015 2:17 PM, Marek Posolda wrote: > I want to doublecheck if we are on the same page regarding how client > certificate authentication should work, so we know what are the > requirements for Elytron > to support it. This will allow us to improve things before the Elytron > code freeze (end of August AFAIK) if needed. > > Right now, I am covering just Service accounts and authenticating of > clients with the certificate. But I believe that for authenticate of > users, the requirements will be similar. > > My view is: > - Admin will upload certificate of some client via Keycloak admin > console. (I guess many companies want to use their own certificate > issued by their trusted CA. IMO later Keycloak should provide the > ability to easily generate trusted certificates and act as CA - not sure > if it's something Giriraj is looking at. But for now, I assume that > trusted certificate is always provided by admin and uploaded to Keycloak > admin console) > Bouncycastle has all the utilities to create our own certificates. I was thinking that admin could upload one, or we could generate one for the user. > - There is REST endpoint, which allows to authenticate with client > certificate. For example > "https://localhost:8443/auth/realms/demo/clients/certificate" . Client > will be able to start SSL handshake with it's certificate when sending > request to this endpoint. Server will then verify the underlying > SSLSession from the SSL socket and check that valid client certificate > was provided during handshake. It will authenticate client based on that. > I'm not sure why you think a specifc URL is needed to do the SSL handshake. The 2-way SSL handshake happens *before* HTTP request is even processed Client app would redirect to the same SAML or OIDC endpoint it does now. The keycloak authentication flow would grab the certificate chain from HttpServletRequest, and validate the client certificate. > > To cover this usecase, the Wildfly/Elytron should be able to: > > 1) Support "variable" 2-way SSL . In other words, there is possibility > to set flag "setWantClientAuth(true)" in underlying SSLServerSocket. IIRC, you can't do this at runtime with NIO or BIO. You must set up the SSLContext at boot time. What can be a little more dynamic is the TrustManager, but I'm not sure we need this...read more below... > This means that I will be able to access admin console > "https://localhost:8443/auth/admin" with my browser without client > certificate, but I will be able to provide client certificate on the > endpoint "https://localhost:8443/auth/realms/demo/clients/certificate" , > which is deployed under same context > > 2) Dynamically upload it's truststore at runtime or provide SPI to > add/remove/update certificates in truststore. This is needed, so that > when admin uploads the certificate of client in KC admin console, I want > my client to be able to authenticate with the certificate immediatelly > without need to restart server and edit any JKS files . > I'm not sure we really need to have any special integration with Elytron. We just need to make sure that it can support certificate chains the way we want to support it. I'm pretty sure EAP 6.x can support what we want, read on... The certficate chain is available from the HttpServletRequest as per the spec. I'm not exactly sure on the specifics, but all you need is one "root" certificate in the web server's trust store. Then you could conceivably create a trusted certificate chain as follows: 1) Organization root certificate. 2) Root cert signs Realm cert. 3) Realm cert signs client cert. Following me? My guess is that it would be really easy to issue our own client certs and that we could have a Required Action that helped set this up. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Wed Jul 15 03:48:14 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 15 Jul 2015 03:48:14 -0400 (EDT) Subject: [keycloak-dev] RealmRep needs to be human craftable? In-Reply-To: <55A5405C.80704@redhat.com> References: <55A5405C.80704@redhat.com> Message-ID: <27274870.39145090.1436946494068.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Tuesday, 14 July, 2015 7:01:16 PM > Subject: [keycloak-dev] RealmRep needs to be human craftable? > > In implementing import/export for authentication flows, i realized that > it is not very human craftable. That is, not easy for a human to create > a json rep of authentication flows. > > Do we still need to support that case? I'd say so - shouldn't an advanced user be able to craft a custom authentication flow in json? > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From stian at redhat.com Wed Jul 15 04:00:44 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 15 Jul 2015 04:00:44 -0400 (EDT) Subject: [keycloak-dev] Improve first login with identity provider In-Reply-To: References: <468566795.37895483.1436860183378.JavaMail.zimbra@redhat.com> <55A4D4D8.9020808@redhat.com> <55A50902.8040702@redhat.com> <264811219.38208150.1436879705647.JavaMail.zimbra@redhat.com> <55A51D1E.2010607@redhat.com> <55A526B8.90506@redhat.com> Message-ID: <488879607.39150047.1436947244664.JavaMail.zimbra@redhat.com> After some thought I agree the proposal I made is way to complicated. Implementing the migrate account feature would be way to complicated, and probably not that often used. I like the idea of having an option on an IdP to trust email or not. We don't need that many options though, a simple on/off toggle will be enough. When login using a new IdP and email exists if this option is enabled we should just add the link to the existing account, if it's disabled we should just display the error message that email is already in use (like we do now), but we can improve on that message to make it more clear to the user what they have to do. That won't solve the initial problem that sparked this conservation though. If the user logs in with a IdP that doesn't require email we can now ask the user to enter the email address, but if they then add an email address that's already in use there's not an easy way to recover from that. Maybe that could be solved by not creating the account until the user has performed the initial set of required actions on a first login with IdP? ----- Original Message ----- > From: "Scott Rossillo" > To: "Bill Burke" , keycloak-dev at lists.jboss.org > Sent: Tuesday, 14 July, 2015 9:16:12 PM > Subject: Re: [keycloak-dev] Improve first login with identity provider > > +1 for auto-merge. We modified the code to do that. > I like Bill's approach with multiple options though as this is the most > flexible and different people will have different requirements. > > On Tue, Jul 14, 2015 at 11:13 AM Bill Burke < bburke at redhat.com > wrote: > > > > > On 7/14/2015 10:30 AM, Marek Posolda wrote: > > On 14.7.2015 15:15, Stian Thorgersen wrote: > >> > >> ----- Original Message ----- > >>> From: "Marek Posolda" < mposolda at redhat.com > > >>> To: "Vlastimil Elias" < velias at redhat.com >, keycloak-dev at lists.jboss.org > >>> Sent: Tuesday, 14 July, 2015 3:05:06 PM > >>> Subject: Re: [keycloak-dev] Improve first login with identity provider > >>> > >>> +1 for do it like this. It seems the biggest challenge is merging the > >>> accounts. Not sure if it's better creating temporary user accounts or > >>> rather keep all the state in ClientSession. It seems the both approaches > >>> has pros and cons... > >>> > >>> Do we want to support linking multiple accounts during single > >>> authentication? It looks we should support it too to have all the things > >>> covered properly. I mean the usecase like: > >>> > >>> 1) User is registered with username/password and email " john at gmail.com " > >>> 2) User clicks to "Sign in with Facebook" and authenticates. Keycloak > >>> displays "There is already account with john at gmail.com . Do you want to > >>> merge account?" > >>> 3) Now login screen is displayed again (IMO it should be without > >>> Facebook button this time) and user click to "Sign in with Google" > >>> 4) Keycloak again displays "There is already account with > >>> john at gmail.com . Do you want to merge account?" > >>> 5) Now login screen is displayed again (without both Facebook and Google > >>> buttons) and user finally login with username/password . After > >>> authentication is user john at gmail.com linked with both Facebok and Google > >> Yes, but I had a different approach in mind: > >> > >> 1) User is registered with username/password and email " john at gmail.com " > >> 2) User clicks to "Sign in with Facebook" and authenticates. Keycloak > >> creates the account, but sets the email address ' john at gmail.com ' as an > >> tmp attribute. Then it displays existing account blah blah, do you want > >> to merge? > >> 3) User clicks merge and is shown a login screen without username, but > >> only password (and any linked identity providers) > >> 4) Once user is logged in the account created in step 2 is merged with the > >> account created in step 1. After it's merged the account from step 2 is > >> deleted. > >> > >> This lets the user merge the account from Facebook at any point as long as > >> it's within the expiration time. Newly created (but not active accounts, > >> i.e. outstanding required actions) will have a expiration time and be > >> removed by a background thread. > > Yeah, I agree with creating separate temporary accounts. Was just > > wondering about use-case with chaining multiple identity providers > > during single authentication (both Facebook and Google). In this case, > > there will be 2 temporary accounts, so the question is if: > > - The "facebook" temporary account is merged with "google" temporary > > account after successful Google authentication (my step 4) > > - Both "facebook" and "google" temporary accounts are merged with the > > original john at gmail.com account after authentication is completely > > finished (my step 5) > > > > but maybe this is implementation detail? Not sure... > > > > IMO the period for keep these temporary accounts should be really small. > > I think user should finish the authentication (which will delete > > temporary accounts) within minutes (not the other day or so) and > > shouldn't never be assigned access token to. Otherwise there might be > > issues with temporary account already linked with some application data > > etc... > > > > Also for your step (3), we don't want to be limited just for the default > > password form right? I think that with Authentication SPI, people may > > want various authentication mechanisms (maybe some don't even want to > > use password at all). The tricky part is, that username is already known > > and we want people to just provide credentials (aka password) . But IMO > > if we limit only to form with password + identity providers, the issue > > will return again after some time... > > > > This is WAY too complicated. Please see my long previous email. There > should never be any temporary accounts. I'll summarize my previous > email again: > > * Existing accounts should only be detected by email. "Bill Burke" gets > 56 million hits on Google. It is a very common name. > > Default behavior: > 1) User registers with " bburke at redhat.com " and password > 2) User does a social login, new account is created " bburke at redhat.com " > is stored in a user attribute. i.e. "Alternative email". > > Website requires linking: > 1) User registers with " bburke at redhat.com " and password > 2) User logins with Facebook, " bburke at redhat.com " exists. Prompted > "Account exists with same email you have registered at Facebook. You > have been sent an email verification message. Please follow the > directions of this email to login" > 3) User goes to Inbox, clicks link in email, message screen appears > "Your Facebook account has been linked. Click "Ok" to continue.". User > gets forwarded to website. > 4) Facebook is linked to pre-existing " bburke at redhat.com " account. > > This would be implemented with Authentication Flows. There would be no > temporary account. Step #2 would create a ClientSession model and store > all the facebook metadata within it. Step #3 would import the facebook > metadata. > > Alternatively, you could just trust the IDP and do the link > automatically. Does Google et. al. send an "email-verified" metadata? > > > User wants to link accounts: > 1) User goes to Account Service, Account LInking page > 2) User is provided with list of IDPs i.e. (Facebook, Google, etc). And > clicks one. > 3) User is prompted to login via that IDP > 4) User receives prompt "Your Facebook account has been linked. Click > "OK" to continue". User gets forwarded to website. > > In this scenario, there is no removal of old accounts. The initiating > account,X, would import the old Facebook account, Y. X would create a > new federation link to Facebook. Y would be disabled and its facebook > link removed. Y is marked as "merged" or "linked" and points to account > X. You need to keep Y around as the user may have done a bunch of > actions under that account...i.e. posted on jboss.org forums. > > > > -- > 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 velias at redhat.com Wed Jul 15 04:04:48 2015 From: velias at redhat.com (Vlastimil Elias) Date: Wed, 15 Jul 2015 10:04:48 +0200 Subject: [keycloak-dev] Improve first login with identity provider In-Reply-To: <55A526B8.90506@redhat.com> References: <468566795.37895483.1436860183378.JavaMail.zimbra@redhat.com> <55A4D4D8.9020808@redhat.com> <55A50902.8040702@redhat.com> <264811219.38208150.1436879705647.JavaMail.zimbra@redhat.com> <55A51D1E.2010607@redhat.com> <55A526B8.90506@redhat.com> Message-ID: <55A61420.4070702@redhat.com> Hi Bill, I agree that account duplicity checking should be based on email only. My question is which flow will be applied in case if social IdP do not provide an email (it is a case for many Idp like Twitter, Github etc) but email is mandatory in Keycloak? User is asked to insert his email on "Update Your Account" page which is now implemented as "login action" which means that KC user account already exists in this phase. What to do if email duplicity is detected in this phase? Or do you plan to move "Update Your Account" page earlier into reg flow before user account is created in KC DB? I do not see description of this flow in any of your two emails in this thread but it have to be resolved somehow. See detailed problem description in https://issues.jboss.org/browse/KEYCLOAK-1540 - this is real problem reported by user of Red Hat Developer site. Thanks Vlastimil On 14.7.2015 17:11, Bill Burke wrote: > > On 7/14/2015 10:30 AM, Marek Posolda wrote: >> On 14.7.2015 15:15, Stian Thorgersen wrote: >>> ----- Original Message ----- >>>> From: "Marek Posolda" >>>> To: "Vlastimil Elias" , keycloak-dev at lists.jboss.org >>>> Sent: Tuesday, 14 July, 2015 3:05:06 PM >>>> Subject: Re: [keycloak-dev] Improve first login with identity provider >>>> >>>> +1 for do it like this. It seems the biggest challenge is merging the >>>> accounts. Not sure if it's better creating temporary user accounts or >>>> rather keep all the state in ClientSession. It seems the both approaches >>>> has pros and cons... >>>> >>>> Do we want to support linking multiple accounts during single >>>> authentication? It looks we should support it too to have all the things >>>> covered properly. I mean the usecase like: >>>> >>>> 1) User is registered with username/password and email "john at gmail.com" >>>> 2) User clicks to "Sign in with Facebook" and authenticates. Keycloak >>>> displays "There is already account with john at gmail.com. Do you want to >>>> merge account?" >>>> 3) Now login screen is displayed again (IMO it should be without >>>> Facebook button this time) and user click to "Sign in with Google" >>>> 4) Keycloak again displays "There is already account with >>>> john at gmail.com. Do you want to merge account?" >>>> 5) Now login screen is displayed again (without both Facebook and Google >>>> buttons) and user finally login with username/password . After >>>> authentication is user john at gmail.com linked with both Facebok and Google >>> Yes, but I had a different approach in mind: >>> >>> 1) User is registered with username/password and email "john at gmail.com" >>> 2) User clicks to "Sign in with Facebook" and authenticates. Keycloak creates the account, but sets the email address 'john at gmail.com' as an tmp attribute. Then it displays existing account blah blah, do you want to merge? >>> 3) User clicks merge and is shown a login screen without username, but only password (and any linked identity providers) >>> 4) Once user is logged in the account created in step 2 is merged with the account created in step 1. After it's merged the account from step 2 is deleted. >>> >>> This lets the user merge the account from Facebook at any point as long as it's within the expiration time. Newly created (but not active accounts, i.e. outstanding required actions) will have a expiration time and be removed by a background thread. >> Yeah, I agree with creating separate temporary accounts. Was just >> wondering about use-case with chaining multiple identity providers >> during single authentication (both Facebook and Google). In this case, >> there will be 2 temporary accounts, so the question is if: >> - The "facebook" temporary account is merged with "google" temporary >> account after successful Google authentication (my step 4) >> - Both "facebook" and "google" temporary accounts are merged with the >> original john at gmail.com account after authentication is completely >> finished (my step 5) >> >> but maybe this is implementation detail? Not sure... >> >> IMO the period for keep these temporary accounts should be really small. >> I think user should finish the authentication (which will delete >> temporary accounts) within minutes (not the other day or so) and >> shouldn't never be assigned access token to. Otherwise there might be >> issues with temporary account already linked with some application data >> etc... >> >> Also for your step (3), we don't want to be limited just for the default >> password form right? I think that with Authentication SPI, people may >> want various authentication mechanisms (maybe some don't even want to >> use password at all). The tricky part is, that username is already known >> and we want people to just provide credentials (aka password) . But IMO >> if we limit only to form with password + identity providers, the issue >> will return again after some time... >> > This is WAY too complicated. Please see my long previous email. There > should never be any temporary accounts. I'll summarize my previous > email again: > > * Existing accounts should only be detected by email. "Bill Burke" gets > 56 million hits on Google. It is a very common name. > > Default behavior: > 1) User registers with "bburke at redhat.com" and password > 2) User does a social login, new account is created "bburke at redhat.com" > is stored in a user attribute. i.e. "Alternative email". > > Website requires linking: > 1) User registers with "bburke at redhat.com" and password > 2) User logins with Facebook, "bburke at redhat.com" exists. Prompted > "Account exists with same email you have registered at Facebook. You > have been sent an email verification message. Please follow the > directions of this email to login" > 3) User goes to Inbox, clicks link in email, message screen appears > "Your Facebook account has been linked. Click "Ok" to continue.". User > gets forwarded to website. > 4) Facebook is linked to pre-existing "bburke at redhat.com" account. > > This would be implemented with Authentication Flows. There would be no > temporary account. Step #2 would create a ClientSession model and store > all the facebook metadata within it. Step #3 would import the facebook > metadata. > > Alternatively, you could just trust the IDP and do the link > automatically. Does Google et. al. send an "email-verified" metadata? > > > User wants to link accounts: > 1) User goes to Account Service, Account LInking page > 2) User is provided with list of IDPs i.e. (Facebook, Google, etc). And > clicks one. > 3) User is prompted to login via that IDP > 4) User receives prompt "Your Facebook account has been linked. Click > "OK" to continue". User gets forwarded to website. > > In this scenario, there is no removal of old accounts. The initiating > account,X, would import the old Facebook account, Y. X would create a > new federation link to Facebook. Y would be disabled and its facebook > link removed. Y is marked as "merged" or "linked" and points to account > X. You need to keep Y around as the user may have done a bunch of > actions under that account...i.e. posted on jboss.org forums. > > > -- Vlastimil Elias Principal Software Engineer jboss.org Development Team From stian at redhat.com Wed Jul 15 04:39:45 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 15 Jul 2015 04:39:45 -0400 (EDT) Subject: [keycloak-dev] Requirements to Elytron for Client 2-way SSL authentication In-Reply-To: <55A5759C.4090609@redhat.com> References: <55A55252.5030804@redhat.com> <55A5759C.4090609@redhat.com> Message-ID: <1100147628.39168512.1436949585709.JavaMail.zimbra@redhat.com> Giriraj is looking at the idea of a root CA certificate now. The main problem with that approach is to add it to the truststore used by Undertow so it can be created or uploaded at runtime through the admin console rather than having to manually configure it. In theory it should be possible to configure Undertow at runtime though to add this without Elytron. ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Tuesday, 14 July, 2015 10:48:28 PM > Subject: Re: [keycloak-dev] Requirements to Elytron for Client 2-way SSL authentication > > > > On 7/14/2015 2:17 PM, Marek Posolda wrote: > > I want to doublecheck if we are on the same page regarding how client > > certificate authentication should work, so we know what are the > > requirements for Elytron > > to support it. This will allow us to improve things before the Elytron > > code freeze (end of August AFAIK) if needed. > > > > Right now, I am covering just Service accounts and authenticating of > > clients with the certificate. But I believe that for authenticate of > > users, the requirements will be similar. > > > > My view is: > > - Admin will upload certificate of some client via Keycloak admin > > console. (I guess many companies want to use their own certificate > > issued by their trusted CA. IMO later Keycloak should provide the > > ability to easily generate trusted certificates and act as CA - not sure > > if it's something Giriraj is looking at. But for now, I assume that > > trusted certificate is always provided by admin and uploaded to Keycloak > > admin console) > > > > Bouncycastle has all the utilities to create our own certificates. I > was thinking that admin could upload one, or we could generate one for > the user. > > > - There is REST endpoint, which allows to authenticate with client > > certificate. For example > > "https://localhost:8443/auth/realms/demo/clients/certificate" . Client > > will be able to start SSL handshake with it's certificate when sending > > request to this endpoint. Server will then verify the underlying > > SSLSession from the SSL socket and check that valid client certificate > > was provided during handshake. It will authenticate client based on that. > > > > I'm not sure why you think a specifc URL is needed to do the SSL > handshake. The 2-way SSL handshake happens *before* HTTP request is > even processed > > Client app would redirect to the same SAML or OIDC endpoint it does now. > The keycloak authentication flow would grab the certificate chain from > HttpServletRequest, and validate the client certificate. > > > > > > To cover this usecase, the Wildfly/Elytron should be able to: > > > > 1) Support "variable" 2-way SSL . In other words, there is possibility > > to set flag "setWantClientAuth(true)" in underlying SSLServerSocket. > > IIRC, you can't do this at runtime with NIO or BIO. You must set up the > SSLContext at boot time. What can be a little more dynamic is the > TrustManager, but I'm not sure we need this...read more below... > > > This means that I will be able to access admin console > > "https://localhost:8443/auth/admin" with my browser without client > > certificate, but I will be able to provide client certificate on the > > endpoint "https://localhost:8443/auth/realms/demo/clients/certificate" , > > which is deployed under same context > > > > 2) Dynamically upload it's truststore at runtime or provide SPI to > > add/remove/update certificates in truststore. This is needed, so that > > when admin uploads the certificate of client in KC admin console, I want > > my client to be able to authenticate with the certificate immediatelly > > without need to restart server and edit any JKS files . > > > > I'm not sure we really need to have any special integration with > Elytron. We just need to make sure that it can support certificate > chains the way we want to support it. I'm pretty sure EAP 6.x can > support what we want, read on... > > The certficate chain is available from the HttpServletRequest as per the > spec. I'm not exactly sure on the specifics, but all you need is one > "root" certificate in the web server's trust store. Then you could > conceivably create a trusted certificate chain as follows: > > 1) Organization root certificate. > > 2) Root cert signs Realm cert. > > 3) Realm cert signs client cert. > > Following me? My guess is that it would be really easy to issue our own > client certs and that we could have a Required Action that helped set > this up. > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From velias at redhat.com Wed Jul 15 04:40:00 2015 From: velias at redhat.com (Vlastimil Elias) Date: Wed, 15 Jul 2015 10:40:00 +0200 Subject: [keycloak-dev] Improve first login with identity provider In-Reply-To: <488879607.39150047.1436947244664.JavaMail.zimbra@redhat.com> References: <468566795.37895483.1436860183378.JavaMail.zimbra@redhat.com> <55A4D4D8.9020808@redhat.com> <55A50902.8040702@redhat.com> <264811219.38208150.1436879705647.JavaMail.zimbra@redhat.com> <55A51D1E.2010607@redhat.com> <55A526B8.90506@redhat.com> <488879607.39150047.1436947244664.JavaMail.zimbra@redhat.com> Message-ID: <55A61C60.2000603@redhat.com> I agree also that solution with temporary user account is not ideal. Ideal solution (which I proposed originally) is to present "Update Account Page" as part of social registration flow before KC DB account is created. So you sort out all conflicts in this phase and then create final correct user or link social account to existing KC account. Vl. On 15.7.2015 10:00, Stian Thorgersen wrote: > After some thought I agree the proposal I made is way to complicated. Implementing the migrate account feature would be way to complicated, and probably not that often used. > > I like the idea of having an option on an IdP to trust email or not. We don't need that many options though, a simple on/off toggle will be enough. When login using a new IdP and email exists if this option is enabled we should just add the link to the existing account, if it's disabled we should just display the error message that email is already in use (like we do now), but we can improve on that message to make it more clear to the user what they have to do. > > That won't solve the initial problem that sparked this conservation though. If the user logs in with a IdP that doesn't require email we can now ask the user to enter the email address, but if they then add an email address that's already in use there's not an easy way to recover from that. Maybe that could be solved by not creating the account until the user has performed the initial set of required actions on a first login with IdP? > > ----- Original Message ----- >> From: "Scott Rossillo" >> To: "Bill Burke" , keycloak-dev at lists.jboss.org >> Sent: Tuesday, 14 July, 2015 9:16:12 PM >> Subject: Re: [keycloak-dev] Improve first login with identity provider >> >> +1 for auto-merge. We modified the code to do that. >> I like Bill's approach with multiple options though as this is the most >> flexible and different people will have different requirements. >> >> On Tue, Jul 14, 2015 at 11:13 AM Bill Burke < bburke at redhat.com > wrote: >> >> >> >> >> On 7/14/2015 10:30 AM, Marek Posolda wrote: >>> On 14.7.2015 15:15, Stian Thorgersen wrote: >>>> ----- Original Message ----- >>>>> From: "Marek Posolda" < mposolda at redhat.com > >>>>> To: "Vlastimil Elias" < velias at redhat.com >, keycloak-dev at lists.jboss.org >>>>> Sent: Tuesday, 14 July, 2015 3:05:06 PM >>>>> Subject: Re: [keycloak-dev] Improve first login with identity provider >>>>> >>>>> +1 for do it like this. It seems the biggest challenge is merging the >>>>> accounts. Not sure if it's better creating temporary user accounts or >>>>> rather keep all the state in ClientSession. It seems the both approaches >>>>> has pros and cons... >>>>> >>>>> Do we want to support linking multiple accounts during single >>>>> authentication? It looks we should support it too to have all the things >>>>> covered properly. I mean the usecase like: >>>>> >>>>> 1) User is registered with username/password and email " john at gmail.com " >>>>> 2) User clicks to "Sign in with Facebook" and authenticates. Keycloak >>>>> displays "There is already account with john at gmail.com . Do you want to >>>>> merge account?" >>>>> 3) Now login screen is displayed again (IMO it should be without >>>>> Facebook button this time) and user click to "Sign in with Google" >>>>> 4) Keycloak again displays "There is already account with >>>>> john at gmail.com . Do you want to merge account?" >>>>> 5) Now login screen is displayed again (without both Facebook and Google >>>>> buttons) and user finally login with username/password . After >>>>> authentication is user john at gmail.com linked with both Facebok and Google >>>> Yes, but I had a different approach in mind: >>>> >>>> 1) User is registered with username/password and email " john at gmail.com " >>>> 2) User clicks to "Sign in with Facebook" and authenticates. Keycloak >>>> creates the account, but sets the email address ' john at gmail.com ' as an >>>> tmp attribute. Then it displays existing account blah blah, do you want >>>> to merge? >>>> 3) User clicks merge and is shown a login screen without username, but >>>> only password (and any linked identity providers) >>>> 4) Once user is logged in the account created in step 2 is merged with the >>>> account created in step 1. After it's merged the account from step 2 is >>>> deleted. >>>> >>>> This lets the user merge the account from Facebook at any point as long as >>>> it's within the expiration time. Newly created (but not active accounts, >>>> i.e. outstanding required actions) will have a expiration time and be >>>> removed by a background thread. >>> Yeah, I agree with creating separate temporary accounts. Was just >>> wondering about use-case with chaining multiple identity providers >>> during single authentication (both Facebook and Google). In this case, >>> there will be 2 temporary accounts, so the question is if: >>> - The "facebook" temporary account is merged with "google" temporary >>> account after successful Google authentication (my step 4) >>> - Both "facebook" and "google" temporary accounts are merged with the >>> original john at gmail.com account after authentication is completely >>> finished (my step 5) >>> >>> but maybe this is implementation detail? Not sure... >>> >>> IMO the period for keep these temporary accounts should be really small. >>> I think user should finish the authentication (which will delete >>> temporary accounts) within minutes (not the other day or so) and >>> shouldn't never be assigned access token to. Otherwise there might be >>> issues with temporary account already linked with some application data >>> etc... >>> >>> Also for your step (3), we don't want to be limited just for the default >>> password form right? I think that with Authentication SPI, people may >>> want various authentication mechanisms (maybe some don't even want to >>> use password at all). The tricky part is, that username is already known >>> and we want people to just provide credentials (aka password) . But IMO >>> if we limit only to form with password + identity providers, the issue >>> will return again after some time... >>> >> This is WAY too complicated. Please see my long previous email. There >> should never be any temporary accounts. I'll summarize my previous >> email again: >> >> * Existing accounts should only be detected by email. "Bill Burke" gets >> 56 million hits on Google. It is a very common name. >> >> Default behavior: >> 1) User registers with " bburke at redhat.com " and password >> 2) User does a social login, new account is created " bburke at redhat.com " >> is stored in a user attribute. i.e. "Alternative email". >> >> Website requires linking: >> 1) User registers with " bburke at redhat.com " and password >> 2) User logins with Facebook, " bburke at redhat.com " exists. Prompted >> "Account exists with same email you have registered at Facebook. You >> have been sent an email verification message. Please follow the >> directions of this email to login" >> 3) User goes to Inbox, clicks link in email, message screen appears >> "Your Facebook account has been linked. Click "Ok" to continue.". User >> gets forwarded to website. >> 4) Facebook is linked to pre-existing " bburke at redhat.com " account. >> >> This would be implemented with Authentication Flows. There would be no >> temporary account. Step #2 would create a ClientSession model and store >> all the facebook metadata within it. Step #3 would import the facebook >> metadata. >> >> Alternatively, you could just trust the IDP and do the link >> automatically. Does Google et. al. send an "email-verified" metadata? >> >> >> User wants to link accounts: >> 1) User goes to Account Service, Account LInking page >> 2) User is provided with list of IDPs i.e. (Facebook, Google, etc). And >> clicks one. >> 3) User is prompted to login via that IDP >> 4) User receives prompt "Your Facebook account has been linked. Click >> "OK" to continue". User gets forwarded to website. >> >> In this scenario, there is no removal of old accounts. The initiating >> account,X, would import the old Facebook account, Y. X would create a >> new federation link to Facebook. Y would be disabled and its facebook >> link removed. Y is marked as "merged" or "linked" and points to account >> X. You need to keep Y around as the user may have done a bunch of >> actions under that account...i.e. posted on jboss.org forums. >> >> >> >> -- >> 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 -- Vlastimil Elias Principal Software Engineer jboss.org Development Team From velias at redhat.com Wed Jul 15 04:37:34 2015 From: velias at redhat.com (Vlastimil Elias) Date: Wed, 15 Jul 2015 10:37:34 +0200 Subject: [keycloak-dev] Improve first login with identity provider In-Reply-To: <55A5142F.4020205@redhat.com> References: <468566795.37895483.1436860183378.JavaMail.zimbra@redhat.com> <55A5142F.4020205@redhat.com> Message-ID: <55A61BCE.5080408@redhat.com> On 14.7.2015 15:52, Bill Burke wrote: > I'm not convinced this is a slam dunk. I think what you are suggesting > is a pain in the ass for users. Why would users ever care if accounts > are linked? I don't ever see social sites prompting me to merge or link > accounts. I have never linked social provider accounts on any website. > Users should never be prompted beyond the initial login for anything > if at all possible. > > In most cases, I think the default behavior should be to just have > separate UserModels and store the email in an attribute. IMO, the vast > majority of applications will work in this manner. Linking will be > rare. IMO, I think jboss.org should work in this way too. WTF do users > care if their accounts are linked or not for JBoss.org? Because you lost all your historical data if you start to use new account created over social login without linking. And you are also forced to enter another email address to this new account if email uniqueness is required. Many peoples do not want to use another email address. I agree that this is typically not a problem for new sites which starts with empty user base, but once you start to use KC with social linking for older site with existing user base the problem is more urgent. And also as your site will be older and users start to return to it after longer time when they forgot they used it previously. > They probably > don't. And will probably be annoyed when they are required to do so. > > IMO, only email should be used to detect existing accounts. Google > "Bill Burke" and you will get 56 million results. No, I'm not that > popular, but my name is! Also the username bburke, bill.burke, or > wburke is usually taken whenever I create an account on a social site. > > There's really two scenarios here. > > 1) User login > 2) User wants to link accounts in Account Service page. > > For User login, there should be a global config page for IDP federation > with a "duplicate account policy" with these options: > > * "None" - store email in an attribute > * "Prompt" - prompt user if they want to merge and require them to login > with the other accounts > * "Require" - require the user to merge their accounts > * "Trust" - trust the providers and automatically merge. > > Each IDP could have a switch "Trusted". With options of "always", > "email-verified", "not-trusted". > > For merging, IMO, UserModels should never be deleted. A user may have > made forum posts or done other actions under that userid. Instead that > UserModel should be disabled and linked to the master UserModel. > > On 7/14/2015 3:49 AM, Stian Thorgersen wrote: >> We should improve the first login with identity provider flow as it's less than elegant at the moment. Some of the suggestion below is how it already works and some not! >> >> The mechanism to detect existing accounts should include: >> >> * Username >> * Email >> * Firstname and lastname >> >> This needs to work both initially on the callback from the identity provider, but also after the user has updated the profile. If an existing account is detected the user should be given the option to do one of the following: >> >> * Cancel >> * Merge - this will require the user to authenticate as the existing user. Once authenticated the attributes, roles and identity-provider links from the new user are copied to the existing user (not overriding existing attributes/roles/links) >> * Continue - only if existing account is found by firstname and lastname >> >> For this to work it's probably easier to initially always create the account. To get around the case where email is duplicated we can set that as an temporary attribute rather than the email. >> >> We also need to make sure we can define what attributes are required for a user in a realm, including validation of each attribute. If any of these attributes are missing the user will have to update the profile. >> >> Finally, we should add a expires on a user account. If a user initiates the login with an identity provider, but never completes the above actions (for example closes the browser on the existing account screen, or the update profile screen) the account should automatically be removed after a given time. >> >> With regards to required actions it should be possible to configure one or more required actions for first login for a specific identity provider. >> >> It would be nice to nail down this flow once and for all! If we can all agree on the flow, we can allocate someone to implement it for 1.5. >> _______________________________________________ >> 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 mstrukel at redhat.com Wed Jul 15 06:20:36 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Wed, 15 Jul 2015 06:20:36 -0400 (EDT) Subject: [keycloak-dev] [wildfly-dev] Using feature packs for custom distributions In-Reply-To: <3DE1DB5E-9F74-4BE9-984A-877F462F37B6@redhat.com> References: <1078508222.16648070.1436450251162.JavaMail.zimbra@redhat.com> <3DE1DB5E-9F74-4BE9-984A-877F462F37B6@redhat.com> Message-ID: <788637847.19676911.1436955636449.JavaMail.zimbra@redhat.com> Thanks Bob for confirming that skipping optionals should work. My initial attempts at that were still pulling in the whole world, but I found it was due to a tiny bug in the tool I used that skipped some optionals but not all of them. Things look much more promising now ... ----- Original Message ----- > >> For our use-case this would also be addressed by wildfly providing a > >> feature-pack definition that?s somewhere between servlet-feature-pack and > >> full-feature-pack - as long as it contains datasources support, and jaxrs > >> support ? > > > > I think this is a good idea, to skip optional deps. > > This is what wildfly-swarm does. > > We consume the WF feature-packs, but only solve the tree from a few root > module.xml?s to extract only the subset we need. > > And if it?s optional=?true?, we pretend we don?t need it. That helps a lot. > > Also, as soon as something pulls in weld, you?re pretty screwed, since weld > then depends on most everything else, many times non-optionally. > > -Bob > > > > > > >> > >> Another thing is provisioning of feature packs, which I address in another > >> email. > >> > >> > >> - marko > >> > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> > > > > -- > > Jason T. Greene > > WildFly Lead / JBoss EAP Platform Architect > > JBoss, a division of Red Hat > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > From bburke at redhat.com Wed Jul 15 09:08:34 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 15 Jul 2015 09:08:34 -0400 Subject: [keycloak-dev] Improve first login with identity provider In-Reply-To: <55A61C60.2000603@redhat.com> References: <468566795.37895483.1436860183378.JavaMail.zimbra@redhat.com> <55A4D4D8.9020808@redhat.com> <55A50902.8040702@redhat.com> <264811219.38208150.1436879705647.JavaMail.zimbra@redhat.com> <55A51D1E.2010607@redhat.com> <55A526B8.90506@redhat.com> <488879607.39150047.1436947244664.JavaMail.zimbra@redhat.com> <55A61C60.2000603@redhat.com> Message-ID: <55A65B52.3070009@redhat.com> Looks like IDP logins will require configurable auth flows too like registration and login currently have in master. Man, all this stuff is going to be hard to get both easy to use and easy to extend. On 7/15/2015 4:40 AM, Vlastimil Elias wrote: > I agree also that solution with temporary user account is not ideal. > Ideal solution (which I proposed originally) is to present "Update > Account Page" as part of social registration flow before KC DB account > is created. So you sort out all conflicts in this phase and then create > final correct user or link social account to existing KC account. > > Vl. > > On 15.7.2015 10:00, Stian Thorgersen wrote: >> After some thought I agree the proposal I made is way to complicated. Implementing the migrate account feature would be way to complicated, and probably not that often used. >> >> I like the idea of having an option on an IdP to trust email or not. We don't need that many options though, a simple on/off toggle will be enough. When login using a new IdP and email exists if this option is enabled we should just add the link to the existing account, if it's disabled we should just display the error message that email is already in use (like we do now), but we can improve on that message to make it more clear to the user what they have to do. >> >> That won't solve the initial problem that sparked this conservation though. If the user logs in with a IdP that doesn't require email we can now ask the user to enter the email address, but if they then add an email address that's already in use there's not an easy way to recover from that. Maybe that could be solved by not creating the account until the user has performed the initial set of required actions on a first login with IdP? >> >> ----- Original Message ----- >>> From: "Scott Rossillo" >>> To: "Bill Burke" , keycloak-dev at lists.jboss.org >>> Sent: Tuesday, 14 July, 2015 9:16:12 PM >>> Subject: Re: [keycloak-dev] Improve first login with identity provider >>> >>> +1 for auto-merge. We modified the code to do that. >>> I like Bill's approach with multiple options though as this is the most >>> flexible and different people will have different requirements. >>> >>> On Tue, Jul 14, 2015 at 11:13 AM Bill Burke < bburke at redhat.com > wrote: >>> >>> >>> >>> >>> On 7/14/2015 10:30 AM, Marek Posolda wrote: >>>> On 14.7.2015 15:15, Stian Thorgersen wrote: >>>>> ----- Original Message ----- >>>>>> From: "Marek Posolda" < mposolda at redhat.com > >>>>>> To: "Vlastimil Elias" < velias at redhat.com >, keycloak-dev at lists.jboss.org >>>>>> Sent: Tuesday, 14 July, 2015 3:05:06 PM >>>>>> Subject: Re: [keycloak-dev] Improve first login with identity provider >>>>>> >>>>>> +1 for do it like this. It seems the biggest challenge is merging the >>>>>> accounts. Not sure if it's better creating temporary user accounts or >>>>>> rather keep all the state in ClientSession. It seems the both approaches >>>>>> has pros and cons... >>>>>> >>>>>> Do we want to support linking multiple accounts during single >>>>>> authentication? It looks we should support it too to have all the things >>>>>> covered properly. I mean the usecase like: >>>>>> >>>>>> 1) User is registered with username/password and email " john at gmail.com " >>>>>> 2) User clicks to "Sign in with Facebook" and authenticates. Keycloak >>>>>> displays "There is already account with john at gmail.com . Do you want to >>>>>> merge account?" >>>>>> 3) Now login screen is displayed again (IMO it should be without >>>>>> Facebook button this time) and user click to "Sign in with Google" >>>>>> 4) Keycloak again displays "There is already account with >>>>>> john at gmail.com . Do you want to merge account?" >>>>>> 5) Now login screen is displayed again (without both Facebook and Google >>>>>> buttons) and user finally login with username/password . After >>>>>> authentication is user john at gmail.com linked with both Facebok and Google >>>>> Yes, but I had a different approach in mind: >>>>> >>>>> 1) User is registered with username/password and email " john at gmail.com " >>>>> 2) User clicks to "Sign in with Facebook" and authenticates. Keycloak >>>>> creates the account, but sets the email address ' john at gmail.com ' as an >>>>> tmp attribute. Then it displays existing account blah blah, do you want >>>>> to merge? >>>>> 3) User clicks merge and is shown a login screen without username, but >>>>> only password (and any linked identity providers) >>>>> 4) Once user is logged in the account created in step 2 is merged with the >>>>> account created in step 1. After it's merged the account from step 2 is >>>>> deleted. >>>>> >>>>> This lets the user merge the account from Facebook at any point as long as >>>>> it's within the expiration time. Newly created (but not active accounts, >>>>> i.e. outstanding required actions) will have a expiration time and be >>>>> removed by a background thread. >>>> Yeah, I agree with creating separate temporary accounts. Was just >>>> wondering about use-case with chaining multiple identity providers >>>> during single authentication (both Facebook and Google). In this case, >>>> there will be 2 temporary accounts, so the question is if: >>>> - The "facebook" temporary account is merged with "google" temporary >>>> account after successful Google authentication (my step 4) >>>> - Both "facebook" and "google" temporary accounts are merged with the >>>> original john at gmail.com account after authentication is completely >>>> finished (my step 5) >>>> >>>> but maybe this is implementation detail? Not sure... >>>> >>>> IMO the period for keep these temporary accounts should be really small. >>>> I think user should finish the authentication (which will delete >>>> temporary accounts) within minutes (not the other day or so) and >>>> shouldn't never be assigned access token to. Otherwise there might be >>>> issues with temporary account already linked with some application data >>>> etc... >>>> >>>> Also for your step (3), we don't want to be limited just for the default >>>> password form right? I think that with Authentication SPI, people may >>>> want various authentication mechanisms (maybe some don't even want to >>>> use password at all). The tricky part is, that username is already known >>>> and we want people to just provide credentials (aka password) . But IMO >>>> if we limit only to form with password + identity providers, the issue >>>> will return again after some time... >>>> >>> This is WAY too complicated. Please see my long previous email. There >>> should never be any temporary accounts. I'll summarize my previous >>> email again: >>> >>> * Existing accounts should only be detected by email. "Bill Burke" gets >>> 56 million hits on Google. It is a very common name. >>> >>> Default behavior: >>> 1) User registers with " bburke at redhat.com " and password >>> 2) User does a social login, new account is created " bburke at redhat.com " >>> is stored in a user attribute. i.e. "Alternative email". >>> >>> Website requires linking: >>> 1) User registers with " bburke at redhat.com " and password >>> 2) User logins with Facebook, " bburke at redhat.com " exists. Prompted >>> "Account exists with same email you have registered at Facebook. You >>> have been sent an email verification message. Please follow the >>> directions of this email to login" >>> 3) User goes to Inbox, clicks link in email, message screen appears >>> "Your Facebook account has been linked. Click "Ok" to continue.". User >>> gets forwarded to website. >>> 4) Facebook is linked to pre-existing " bburke at redhat.com " account. >>> >>> This would be implemented with Authentication Flows. There would be no >>> temporary account. Step #2 would create a ClientSession model and store >>> all the facebook metadata within it. Step #3 would import the facebook >>> metadata. >>> >>> Alternatively, you could just trust the IDP and do the link >>> automatically. Does Google et. al. send an "email-verified" metadata? >>> >>> >>> User wants to link accounts: >>> 1) User goes to Account Service, Account LInking page >>> 2) User is provided with list of IDPs i.e. (Facebook, Google, etc). And >>> clicks one. >>> 3) User is prompted to login via that IDP >>> 4) User receives prompt "Your Facebook account has been linked. Click >>> "OK" to continue". User gets forwarded to website. >>> >>> In this scenario, there is no removal of old accounts. The initiating >>> account,X, would import the old Facebook account, Y. X would create a >>> new federation link to Facebook. Y would be disabled and its facebook >>> link removed. Y is marked as "merged" or "linked" and points to account >>> X. You need to keep Y around as the user may have done a bunch of >>> actions under that account...i.e. posted on jboss.org forums. >>> >>> >>> >>> -- >>> 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 > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From srossillo at smartling.com Wed Jul 15 21:31:30 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Thu, 16 Jul 2015 01:31:30 +0000 Subject: [keycloak-dev] Improve first login with identity provider In-Reply-To: <55A65B52.3070009@redhat.com> References: <468566795.37895483.1436860183378.JavaMail.zimbra@redhat.com> <55A4D4D8.9020808@redhat.com> <55A50902.8040702@redhat.com> <264811219.38208150.1436879705647.JavaMail.zimbra@redhat.com> <55A51D1E.2010607@redhat.com> <55A526B8.90506@redhat.com> <488879607.39150047.1436947244664.JavaMail.zimbra@redhat.com> <55A61C60.2000603@redhat.com> <55A65B52.3070009@redhat.com> Message-ID: Why can't we just require email scope from upstream IDPs? What system these days doesn't use email as some sort of unique identifier, including Twitter and Github? On Wed, Jul 15, 2015 at 9:09 AM Bill Burke wrote: > Looks like IDP logins will require configurable auth flows too like > registration and login currently have in master. Man, all this stuff is > going to be hard to get both easy to use and easy to extend. > > On 7/15/2015 4:40 AM, Vlastimil Elias wrote: > > I agree also that solution with temporary user account is not ideal. > > Ideal solution (which I proposed originally) is to present "Update > > Account Page" as part of social registration flow before KC DB account > > is created. So you sort out all conflicts in this phase and then create > > final correct user or link social account to existing KC account. > > > > Vl. > > > > On 15.7.2015 10:00, Stian Thorgersen wrote: > >> After some thought I agree the proposal I made is way to complicated. > Implementing the migrate account feature would be way to complicated, and > probably not that often used. > >> > >> I like the idea of having an option on an IdP to trust email or not. We > don't need that many options though, a simple on/off toggle will be enough. > When login using a new IdP and email exists if this option is enabled we > should just add the link to the existing account, if it's disabled we > should just display the error message that email is already in use (like we > do now), but we can improve on that message to make it more clear to the > user what they have to do. > >> > >> That won't solve the initial problem that sparked this conservation > though. If the user logs in with a IdP that doesn't require email we can > now ask the user to enter the email address, but if they then add an email > address that's already in use there's not an easy way to recover from that. > Maybe that could be solved by not creating the account until the user has > performed the initial set of required actions on a first login with IdP? > >> > >> ----- Original Message ----- > >>> From: "Scott Rossillo" > >>> To: "Bill Burke" , keycloak-dev at lists.jboss.org > >>> Sent: Tuesday, 14 July, 2015 9:16:12 PM > >>> Subject: Re: [keycloak-dev] Improve first login with identity provider > >>> > >>> +1 for auto-merge. We modified the code to do that. > >>> I like Bill's approach with multiple options though as this is the most > >>> flexible and different people will have different requirements. > >>> > >>> On Tue, Jul 14, 2015 at 11:13 AM Bill Burke < bburke at redhat.com > > wrote: > >>> > >>> > >>> > >>> > >>> On 7/14/2015 10:30 AM, Marek Posolda wrote: > >>>> On 14.7.2015 15:15, Stian Thorgersen wrote: > >>>>> ----- Original Message ----- > >>>>>> From: "Marek Posolda" < mposolda at redhat.com > > >>>>>> To: "Vlastimil Elias" < velias at redhat.com >, > keycloak-dev at lists.jboss.org > >>>>>> Sent: Tuesday, 14 July, 2015 3:05:06 PM > >>>>>> Subject: Re: [keycloak-dev] Improve first login with identity > provider > >>>>>> > >>>>>> +1 for do it like this. It seems the biggest challenge is merging > the > >>>>>> accounts. Not sure if it's better creating temporary user accounts > or > >>>>>> rather keep all the state in ClientSession. It seems the both > approaches > >>>>>> has pros and cons... > >>>>>> > >>>>>> Do we want to support linking multiple accounts during single > >>>>>> authentication? It looks we should support it too to have all the > things > >>>>>> covered properly. I mean the usecase like: > >>>>>> > >>>>>> 1) User is registered with username/password and email " > john at gmail.com " > >>>>>> 2) User clicks to "Sign in with Facebook" and authenticates. > Keycloak > >>>>>> displays "There is already account with john at gmail.com . Do you > want to > >>>>>> merge account?" > >>>>>> 3) Now login screen is displayed again (IMO it should be without > >>>>>> Facebook button this time) and user click to "Sign in with Google" > >>>>>> 4) Keycloak again displays "There is already account with > >>>>>> john at gmail.com . Do you want to merge account?" > >>>>>> 5) Now login screen is displayed again (without both Facebook and > Google > >>>>>> buttons) and user finally login with username/password . After > >>>>>> authentication is user john at gmail.com linked with both Facebok and > Google > >>>>> Yes, but I had a different approach in mind: > >>>>> > >>>>> 1) User is registered with username/password and email " > john at gmail.com " > >>>>> 2) User clicks to "Sign in with Facebook" and authenticates. Keycloak > >>>>> creates the account, but sets the email address ' john at gmail.com ' > as an > >>>>> tmp attribute. Then it displays existing account blah blah, do you > want > >>>>> to merge? > >>>>> 3) User clicks merge and is shown a login screen without username, > but > >>>>> only password (and any linked identity providers) > >>>>> 4) Once user is logged in the account created in step 2 is merged > with the > >>>>> account created in step 1. After it's merged the account from step 2 > is > >>>>> deleted. > >>>>> > >>>>> This lets the user merge the account from Facebook at any point as > long as > >>>>> it's within the expiration time. Newly created (but not active > accounts, > >>>>> i.e. outstanding required actions) will have a expiration time and be > >>>>> removed by a background thread. > >>>> Yeah, I agree with creating separate temporary accounts. Was just > >>>> wondering about use-case with chaining multiple identity providers > >>>> during single authentication (both Facebook and Google). In this case, > >>>> there will be 2 temporary accounts, so the question is if: > >>>> - The "facebook" temporary account is merged with "google" temporary > >>>> account after successful Google authentication (my step 4) > >>>> - Both "facebook" and "google" temporary accounts are merged with the > >>>> original john at gmail.com account after authentication is completely > >>>> finished (my step 5) > >>>> > >>>> but maybe this is implementation detail? Not sure... > >>>> > >>>> IMO the period for keep these temporary accounts should be really > small. > >>>> I think user should finish the authentication (which will delete > >>>> temporary accounts) within minutes (not the other day or so) and > >>>> shouldn't never be assigned access token to. Otherwise there might be > >>>> issues with temporary account already linked with some application > data > >>>> etc... > >>>> > >>>> Also for your step (3), we don't want to be limited just for the > default > >>>> password form right? I think that with Authentication SPI, people may > >>>> want various authentication mechanisms (maybe some don't even want to > >>>> use password at all). The tricky part is, that username is already > known > >>>> and we want people to just provide credentials (aka password) . But > IMO > >>>> if we limit only to form with password + identity providers, the issue > >>>> will return again after some time... > >>>> > >>> This is WAY too complicated. Please see my long previous email. There > >>> should never be any temporary accounts. I'll summarize my previous > >>> email again: > >>> > >>> * Existing accounts should only be detected by email. "Bill Burke" gets > >>> 56 million hits on Google. It is a very common name. > >>> > >>> Default behavior: > >>> 1) User registers with " bburke at redhat.com " and password > >>> 2) User does a social login, new account is created " > bburke at redhat.com " > >>> is stored in a user attribute. i.e. "Alternative email". > >>> > >>> Website requires linking: > >>> 1) User registers with " bburke at redhat.com " and password > >>> 2) User logins with Facebook, " bburke at redhat.com " exists. Prompted > >>> "Account exists with same email you have registered at Facebook. You > >>> have been sent an email verification message. Please follow the > >>> directions of this email to login" > >>> 3) User goes to Inbox, clicks link in email, message screen appears > >>> "Your Facebook account has been linked. Click "Ok" to continue.". User > >>> gets forwarded to website. > >>> 4) Facebook is linked to pre-existing " bburke at redhat.com " account. > >>> > >>> This would be implemented with Authentication Flows. There would be no > >>> temporary account. Step #2 would create a ClientSession model and store > >>> all the facebook metadata within it. Step #3 would import the facebook > >>> metadata. > >>> > >>> Alternatively, you could just trust the IDP and do the link > >>> automatically. Does Google et. al. send an "email-verified" metadata? > >>> > >>> > >>> User wants to link accounts: > >>> 1) User goes to Account Service, Account LInking page > >>> 2) User is provided with list of IDPs i.e. (Facebook, Google, etc). And > >>> clicks one. > >>> 3) User is prompted to login via that IDP > >>> 4) User receives prompt "Your Facebook account has been linked. Click > >>> "OK" to continue". User gets forwarded to website. > >>> > >>> In this scenario, there is no removal of old accounts. The initiating > >>> account,X, would import the old Facebook account, Y. X would create a > >>> new federation link to Facebook. Y would be disabled and its facebook > >>> link removed. Y is marked as "merged" or "linked" and points to account > >>> X. You need to keep Y around as the user may have done a bunch of > >>> actions under that account...i.e. posted on jboss.org forums. > >>> > >>> > >>> > >>> -- > >>> 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 > > > > -- > 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/20150716/608ae69f/attachment.html From velias at redhat.com Thu Jul 16 02:15:29 2015 From: velias at redhat.com (Vlastimil Elias) Date: Thu, 16 Jul 2015 08:15:29 +0200 Subject: [keycloak-dev] Operational monitoring of Keycloak server In-Reply-To: <1137820905.37901015.1436861190539.JavaMail.zimbra@redhat.com> References: <55A3BA5C.2090906@redhat.com> <299925009.37235169.1436800699765.JavaMail.zimbra@redhat.com> <55A4AD75.1030203@redhat.com> <2071278650.37809022.1436856157015.JavaMail.zimbra@redhat.com> <55A4B2AB.9080508@redhat.com> <383530390.37875127.1436858054281.JavaMail.zimbra@redhat.com> <55A4C12C.8070305@redhat.com> <1137820905.37901015.1436861190539.JavaMail.zimbra@redhat.com> Message-ID: <55A74C01.4020104@redhat.com> Hi, OK, if DB is "realm" and "users" then it have to be well documented as it is not obvious for people without deeper knowledge of KC. Do we have JIRA issue for this or should I create one? Vl. On 14.7.2015 10:06, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Vlastimil Elias" >> To: "Stian Thorgersen" >> Cc: "Scott Rossillo" , keycloak-dev at lists.jboss.org >> Sent: Tuesday, 14 July, 2015 9:58:36 AM >> Subject: Re: [keycloak-dev] Operational monitoring of Keycloak server >> >> On 14.7.2015 09:14, Stian Thorgersen wrote: >>> ----- Original Message ----- >>>> From: "Vlastimil Elias" >>>> To: "Stian Thorgersen" >>>> Cc: "Scott Rossillo" , >>>> keycloak-dev at lists.jboss.org >>>> Sent: Tuesday, 14 July, 2015 8:56:43 AM >>>> Subject: Re: [keycloak-dev] Operational monitoring of Keycloak server >>>> >>>> >>>> >>>> On 14.7.2015 08:42, Stian Thorgersen wrote: >>>>> Ok so we add one that just returns OK or ERROR which doesn't require >>>>> authentication, but then we add another that can return more details, >>>>> including stats and what the error is. >>>> Yep. Simple http endpoinds for now, later all this info may be expose >>>> over DMR or some other mechanism if necessary. >>>>> For full health we should check all external services that are used (db, >>>>> identity providers and user federation providers). Cluster sync will >>>>> depend on what Infinispan exposes, but I imagine they'll have the >>>>> required >>>>> details avail. >>>> Beside endpoint for full health check (which should summarize all >>>> services into one flag if I understand correctly, which is good for >>>> loadbalancer) we should expose separate endpoint for each service >>>> health, as it is better for operational monitoring systems like Nagios. >>>> Admins are better informed what is going wrong and they can resolve >>>> situation more quickly without necessity to search cause of general >>>> failure flag somewhere else. >>> We could have a single health endpoint that returns a 200 or 500 and also >>> returns a json doc with details. Something like: >>> >>> { >>> realm: ok, >>> users: ok, >>> realmCache: error, >>> userCache: error, >>> identity-providers: { >>> google: ok, >>> facebook: error >>> }, >>> user-federation: { >>> ldap: ok >>> } >>> } >>> >>> I wonder if that's to much details to expose without authentication. >> This should work, but I miss info about DB connection here. It is >> crucial from operational point of view as this allows sysadmins quickly >> detect that connection to DB is broken. >> >> I believe this kind of info can be safely exposed without >> authentication. If the endpoint is clearly documented then access can be >> always restricted on some network infra (webserver/proxy) ahead of KC. > DB is "realm" and "users". > >>>> Vl. >>>> >>>>> ----- Original Message ----- >>>>>> From: "Vlastimil Elias" >>>>>> To: "Scott Rossillo" , "Stian Thorgersen" >>>>>> >>>>>> Cc: keycloak-dev at lists.jboss.org >>>>>> Sent: Tuesday, 14 July, 2015 8:34:29 AM >>>>>> Subject: Re: [keycloak-dev] Operational monitoring of Keycloak server >>>>>> >>>>>> Yap, beside server-stat endpoint Stian talked about we should add some >>>>>> server-health endpoint also to be used for remote health monitoring by >>>>>> load balancers or systems like Nagios. >>>>>> Simple http endpoint without authentication (as it doesn't leak any >>>>>> sensitive information) is typically simplest way how to do this >>>>>> monitoring. >>>>>> >>>>>> Vl. >>>>>> >>>>>> On 14.7.2015 05:13, Scott Rossillo wrote: >>>>>>> Some type of health page would be great too for load balancers to >>>>>>> monitor. Something that doesn't leak internal information but checks >>>>>>> behind the scenes that: >>>>>>> 1. Server can reach its databas(es) >>>>>>> 2. Server cluster sync is working >>>>>>> 3. Server can reach federation providers, etc. >>>>>>> Endpoint should respond to get requests and return an http status >>>>>>> reflective of server state. >>>>>>> >>>>>>> On Mon, Jul 13, 2015 at 11:18 AM Stian Thorgersen >>>>>> > wrote: >>>>>>> >>>>>>> So looks like we're at agreement to add the additional info you >>>>>>> wanted to server info page. >>>>>>> >>>>>>> How about we add an additional endpoint server-stat that can >>>>>>> collect some stats about the server? >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> > From: "Vlastimil Elias" >>>>>> > >>>>>>> > To: "Stian Thorgersen" >>>>>> > > >>>>>>> > Cc: keycloak-dev at lists.jboss.org >>>>>>> >>>>>>> > Sent: Monday, 13 July, 2015 5:06:34 PM >>>>>>> > Subject: Re: [keycloak-dev] Operational monitoring of Keycloak >>>>>>> server >>>>>>> > >>>>>>> > Looks like I have to look at WildFly/EAP DMR to see what is >>>>>>> possible to >>>>>>> > do with it, as I'm not sure if it is about remote monitoring >>>>>>> also and >>>>>>> > if/how it can be use from monitoring systems like Splunk. >>>>>>> > >>>>>>> > Vl. >>>>>>> > >>>>>>> > On 13.7.2015 15:26, Stian Thorgersen wrote: >>>>>>> > > In WildFly/EAP that's DMR right? We're planning to make >>>>>>> Keycloak managable >>>>>>> > > through that as well. For example everything that goes into >>>>>>> > > keycloak-server.json will eventually be moved to >>>>>>> standalone.xml. Same with >>>>>>> > > admin endpoints, everything you can do there you'll >>>>>>> > > eventually >>>>>>> be able to >>>>>>> > > do through DMR and jboss-cli as well. >>>>>>> > > >>>>>>> > > However, IMO it would make sense to at least expose Keycloak >>>>>>> specific >>>>>>> > > information through the admin endpoints and console as well. >>>>>>> Such number >>>>>>> > > of sessions, etc.. >>>>>>> > > >>>>>>> > > ----- Original Message ----- >>>>>>> > >> From: "Vlastimil Elias" >>>>>> > >>>>>>> > >> To: keycloak-dev at lists.jboss.org >>>>>>> >>>>>>> > >> Sent: Monday, 13 July, 2015 3:17:16 PM >>>>>>> > >> Subject: [keycloak-dev] Operational monitoring of Keycloak >>>>>>> > >> server >>>>>>> > >> >>>>>>> > >> Hi, >>>>>>> > >> >>>>>>> > >> as we deployed KC to production mode for >>>>>>> https://developers.redhat.com >>>>>>> > >> we started to think about operational monitoring, for >>>>>>> > >> example >>>>>>> from >>>>>>> > >> Nagios or other systems of this type. >>>>>>> > >> >>>>>>> > >> KC user guide doesn't contain any chapter covering this >>>>>>> topic, also no >>>>>>> > >> any success over google search, so looks like KC doesn't >>>>>>> > >> have >>>>>>> > >> any >>>>>>> > >> solution for this yet. >>>>>>> > >> But I believe this is an important area which must be solved >>>>>>> when KC is >>>>>>> > >> used for production. >>>>>>> > >> >>>>>>> > >> I can imagine monitoring of JDBC connection if JPA is used, >>>>>>> monitoring >>>>>>> > >> of Mongo connection if used as store, monitoring of LDAP >>>>>>> connection if >>>>>>> > >> LDAP federation is used etc. >>>>>>> > >> Also some statistics like numbers of active sso session, >>>>>>> number of >>>>>>> > >> logins per minute etc should be provided there. >>>>>>> > >> >>>>>>> > >> Monitoring is not about Keycloak core itself, it should be >>>>>>> available for >>>>>>> > >> extension developers also. For example we implemented own >>>>>>> > >> UserFederationProvider which calls backend REST services. >>>>>>> > >> We should be able to add info about this integration into >>>>>>> monitoring >>>>>>> > >> endpoint to be able to catch problems with this REST API. >>>>>>> > >> >>>>>>> > >> It should be probably implemented same way as used by >>>>>>> > >> underlying >>>>>>> > >> WildFly/EAP (JPA/JDBC is probably available for monitoring >>>>>>> there). I'm >>>>>>> > >> not sure if JMX is used there still or if some new framework >>>>>>> > >> is >>>>>>> > >> available for it. >>>>>>> > >> Or KC should use some form of KC REST API for this, which >>>>>>> should be >>>>>>> > >> extended by additional info from KC extensions? >>>>>>> > >> >>>>>>> > >> What do you think? >>>>>>> > >> >>>>>>> > >> Vlastimil >>>>>>> > >> >>>>>>> > >> P.S we have https://issues.jboss.org/browse/RHD-552 for Red >>>>>>> > >> Hat >>>>>>> > >> Developer instance of KC >>>>>>> > >> >>>>>>> > >> -- >>>>>>> > >> 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 >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ >>>>>>> keycloak-dev mailing list >>>>>>> keycloak-dev at lists.jboss.org >>>>>>> >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>> >>>>>> -- >>>>>> Vlastimil Elias >>>>>> Principal Software Engineer >>>>>> jboss.org Development Team >>>>>> >>>>>> >>>> -- >>>> Vlastimil Elias >>>> Principal Software Engineer >>>> jboss.org Development Team >>>> >>>> >> -- >> Vlastimil Elias >> Principal Software Engineer >> jboss.org Development Team >> >> -- Vlastimil Elias Principal Software Engineer jboss.org Development Team From velias at redhat.com Thu Jul 16 02:38:39 2015 From: velias at redhat.com (Vlastimil Elias) Date: Thu, 16 Jul 2015 08:38:39 +0200 Subject: [keycloak-dev] Improve first login with identity provider In-Reply-To: References: <468566795.37895483.1436860183378.JavaMail.zimbra@redhat.com> <55A4D4D8.9020808@redhat.com> <55A50902.8040702@redhat.com> <264811219.38208150.1436879705647.JavaMail.zimbra@redhat.com> <55A51D1E.2010607@redhat.com> <55A526B8.90506@redhat.com> <488879607.39150047.1436947244664.JavaMail.zimbra@redhat.com> <55A61C60.2000603@redhat.com> <55A65B52.3070009@redhat.com> Message-ID: <55A7516F.5030504@redhat.com> On 16.7.2015 03:31, Scott Rossillo wrote: > Why can't we just require email scope from upstream IDPs? What system > these days doesn't use email as some sort of unique identifier, > including Twitter and Github? You should be surprised ;-). Some Oauth providers simply doesn't have separate email scope, some of them doesn't return email at all (twitter, StackOverflow), some of them doesn't return email in some cases, eg. Github does not return email if user sets "Public email" to "Don't show my email address" in his user profile Setting (which looks like error for me that this setting affects REST API, but it is how it works). Facebook user can deny providing email during approving login for your server on Facebok's "Consent" page. Vl. > > On Wed, Jul 15, 2015 at 9:09 AM Bill Burke > wrote: > > Looks like IDP logins will require configurable auth flows too like > registration and login currently have in master. Man, all this > stuff is > going to be hard to get both easy to use and easy to extend. > > On 7/15/2015 4:40 AM, Vlastimil Elias wrote: > > I agree also that solution with temporary user account is not ideal. > > Ideal solution (which I proposed originally) is to present "Update > > Account Page" as part of social registration flow before KC DB > account > > is created. So you sort out all conflicts in this phase and then > create > > final correct user or link social account to existing KC account. > > > > Vl. > > > > On 15.7.2015 10:00, Stian Thorgersen wrote: > >> After some thought I agree the proposal I made is way to > complicated. Implementing the migrate account feature would be way > to complicated, and probably not that often used. > >> > >> I like the idea of having an option on an IdP to trust email or > not. We don't need that many options though, a simple on/off > toggle will be enough. When login using a new IdP and email exists > if this option is enabled we should just add the link to the > existing account, if it's disabled we should just display the > error message that email is already in use (like we do now), but > we can improve on that message to make it more clear to the user > what they have to do. > >> > >> That won't solve the initial problem that sparked this > conservation though. If the user logs in with a IdP that doesn't > require email we can now ask the user to enter the email address, > but if they then add an email address that's already in use > there's not an easy way to recover from that. Maybe that could be > solved by not creating the account until the user has performed > the initial set of required actions on a first login with IdP? > >> > >> ----- Original Message ----- > >>> From: "Scott Rossillo" > > >>> To: "Bill Burke" >, keycloak-dev at lists.jboss.org > > >>> Sent: Tuesday, 14 July, 2015 9:16:12 PM > >>> Subject: Re: [keycloak-dev] Improve first login with identity > provider > >>> > >>> +1 for auto-merge. We modified the code to do that. > >>> I like Bill's approach with multiple options though as this is > the most > >>> flexible and different people will have different requirements. > >>> > >>> On Tue, Jul 14, 2015 at 11:13 AM Bill Burke < > bburke at redhat.com > wrote: > >>> > >>> > >>> > >>> > >>> On 7/14/2015 10:30 AM, Marek Posolda wrote: > >>>> On 14.7.2015 15:15, Stian Thorgersen wrote: > >>>>> ----- Original Message ----- > >>>>>> From: "Marek Posolda" < mposolda at redhat.com > > > >>>>>> To: "Vlastimil Elias" < velias at redhat.com > >, keycloak-dev at lists.jboss.org > > >>>>>> Sent: Tuesday, 14 July, 2015 3:05:06 PM > >>>>>> Subject: Re: [keycloak-dev] Improve first login with > identity provider > >>>>>> > >>>>>> +1 for do it like this. It seems the biggest challenge is > merging the > >>>>>> accounts. Not sure if it's better creating temporary user > accounts or > >>>>>> rather keep all the state in ClientSession. It seems the > both approaches > >>>>>> has pros and cons... > >>>>>> > >>>>>> Do we want to support linking multiple accounts during single > >>>>>> authentication? It looks we should support it too to have > all the things > >>>>>> covered properly. I mean the usecase like: > >>>>>> > >>>>>> 1) User is registered with username/password and email " > john at gmail.com " > >>>>>> 2) User clicks to "Sign in with Facebook" and > authenticates. Keycloak > >>>>>> displays "There is already account with john at gmail.com > . Do you want to > >>>>>> merge account?" > >>>>>> 3) Now login screen is displayed again (IMO it should be > without > >>>>>> Facebook button this time) and user click to "Sign in with > Google" > >>>>>> 4) Keycloak again displays "There is already account with > >>>>>> john at gmail.com . Do you want to > merge account?" > >>>>>> 5) Now login screen is displayed again (without both > Facebook and Google > >>>>>> buttons) and user finally login with username/password . After > >>>>>> authentication is user john at gmail.com > linked with both Facebok and Google > >>>>> Yes, but I had a different approach in mind: > >>>>> > >>>>> 1) User is registered with username/password and email " > john at gmail.com " > >>>>> 2) User clicks to "Sign in with Facebook" and authenticates. > Keycloak > >>>>> creates the account, but sets the email address ' > john at gmail.com ' as an > >>>>> tmp attribute. Then it displays existing account blah blah, > do you want > >>>>> to merge? > >>>>> 3) User clicks merge and is shown a login screen without > username, but > >>>>> only password (and any linked identity providers) > >>>>> 4) Once user is logged in the account created in step 2 is > merged with the > >>>>> account created in step 1. After it's merged the account > from step 2 is > >>>>> deleted. > >>>>> > >>>>> This lets the user merge the account from Facebook at any > point as long as > >>>>> it's within the expiration time. Newly created (but not > active accounts, > >>>>> i.e. outstanding required actions) will have a expiration > time and be > >>>>> removed by a background thread. > >>>> Yeah, I agree with creating separate temporary accounts. Was just > >>>> wondering about use-case with chaining multiple identity > providers > >>>> during single authentication (both Facebook and Google). In > this case, > >>>> there will be 2 temporary accounts, so the question is if: > >>>> - The "facebook" temporary account is merged with "google" > temporary > >>>> account after successful Google authentication (my step 4) > >>>> - Both "facebook" and "google" temporary accounts are merged > with the > >>>> original john at gmail.com account after > authentication is completely > >>>> finished (my step 5) > >>>> > >>>> but maybe this is implementation detail? Not sure... > >>>> > >>>> IMO the period for keep these temporary accounts should be > really small. > >>>> I think user should finish the authentication (which will delete > >>>> temporary accounts) within minutes (not the other day or so) and > >>>> shouldn't never be assigned access token to. Otherwise there > might be > >>>> issues with temporary account already linked with some > application data > >>>> etc... > >>>> > >>>> Also for your step (3), we don't want to be limited just for > the default > >>>> password form right? I think that with Authentication SPI, > people may > >>>> want various authentication mechanisms (maybe some don't even > want to > >>>> use password at all). The tricky part is, that username is > already known > >>>> and we want people to just provide credentials (aka password) > . But IMO > >>>> if we limit only to form with password + identity providers, > the issue > >>>> will return again after some time... > >>>> > >>> This is WAY too complicated. Please see my long previous > email. There > >>> should never be any temporary accounts. I'll summarize my previous > >>> email again: > >>> > >>> * Existing accounts should only be detected by email. "Bill > Burke" gets > >>> 56 million hits on Google. It is a very common name. > >>> > >>> Default behavior: > >>> 1) User registers with " bburke at redhat.com > " and password > >>> 2) User does a social login, new account is created " > bburke at redhat.com " > >>> is stored in a user attribute. i.e. "Alternative email". > >>> > >>> Website requires linking: > >>> 1) User registers with " bburke at redhat.com > " and password > >>> 2) User logins with Facebook, " bburke at redhat.com > " exists. Prompted > >>> "Account exists with same email you have registered at > Facebook. You > >>> have been sent an email verification message. Please follow the > >>> directions of this email to login" > >>> 3) User goes to Inbox, clicks link in email, message screen > appears > >>> "Your Facebook account has been linked. Click "Ok" to > continue.". User > >>> gets forwarded to website. > >>> 4) Facebook is linked to pre-existing " bburke at redhat.com > " account. > >>> > >>> This would be implemented with Authentication Flows. There > would be no > >>> temporary account. Step #2 would create a ClientSession model > and store > >>> all the facebook metadata within it. Step #3 would import the > facebook > >>> metadata. > >>> > >>> Alternatively, you could just trust the IDP and do the link > >>> automatically. Does Google et. al. send an "email-verified" > metadata? > >>> > >>> > >>> User wants to link accounts: > >>> 1) User goes to Account Service, Account LInking page > >>> 2) User is provided with list of IDPs i.e. (Facebook, Google, > etc). And > >>> clicks one. > >>> 3) User is prompted to login via that IDP > >>> 4) User receives prompt "Your Facebook account has been > linked. Click > >>> "OK" to continue". User gets forwarded to website. > >>> > >>> In this scenario, there is no removal of old accounts. The > initiating > >>> account,X, would import the old Facebook account, Y. X would > create a > >>> new federation link to Facebook. Y would be disabled and its > facebook > >>> link removed. Y is marked as "merged" or "linked" and points > to account > >>> X. You need to keep Y around as the user may have done a bunch of > >>> actions under that account...i.e. posted on jboss.org > forums. > >>> > >>> > >>> > >>> -- > >>> 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 > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Vlastimil Elias Principal Software Engineer jboss.org Development Team -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150716/36a2ef90/attachment-0001.html From stian at redhat.com Thu Jul 16 02:49:56 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 16 Jul 2015 02:49:56 -0400 (EDT) Subject: [keycloak-dev] Operational monitoring of Keycloak server In-Reply-To: <55A74C01.4020104@redhat.com> References: <55A3BA5C.2090906@redhat.com> <55A4AD75.1030203@redhat.com> <2071278650.37809022.1436856157015.JavaMail.zimbra@redhat.com> <55A4B2AB.9080508@redhat.com> <383530390.37875127.1436858054281.JavaMail.zimbra@redhat.com> <55A4C12C.8070305@redhat.com> <1137820905.37901015.1436861190539.JavaMail.zimbra@redhat.com> <55A74C01.4020104@redhat.com> Message-ID: <760752165.39790007.1437029396675.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Vlastimil Elias" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Thursday, 16 July, 2015 8:15:29 AM > Subject: Re: [keycloak-dev] Operational monitoring of Keycloak server > > Hi, > > OK, if DB is "realm" and "users" then it have to be well documented as > it is not obvious for people without deeper knowledge of KC. We could always call it realm-database or something, but we have 3 different stores so should be separate status for them > > Do we have JIRA issue for this or should I create one? Nope, so please create one > > Vl. > > > On 14.7.2015 10:06, Stian Thorgersen wrote: > > > > ----- Original Message ----- > >> From: "Vlastimil Elias" > >> To: "Stian Thorgersen" > >> Cc: "Scott Rossillo" , > >> keycloak-dev at lists.jboss.org > >> Sent: Tuesday, 14 July, 2015 9:58:36 AM > >> Subject: Re: [keycloak-dev] Operational monitoring of Keycloak server > >> > >> On 14.7.2015 09:14, Stian Thorgersen wrote: > >>> ----- Original Message ----- > >>>> From: "Vlastimil Elias" > >>>> To: "Stian Thorgersen" > >>>> Cc: "Scott Rossillo" , > >>>> keycloak-dev at lists.jboss.org > >>>> Sent: Tuesday, 14 July, 2015 8:56:43 AM > >>>> Subject: Re: [keycloak-dev] Operational monitoring of Keycloak server > >>>> > >>>> > >>>> > >>>> On 14.7.2015 08:42, Stian Thorgersen wrote: > >>>>> Ok so we add one that just returns OK or ERROR which doesn't require > >>>>> authentication, but then we add another that can return more details, > >>>>> including stats and what the error is. > >>>> Yep. Simple http endpoinds for now, later all this info may be expose > >>>> over DMR or some other mechanism if necessary. > >>>>> For full health we should check all external services that are used > >>>>> (db, > >>>>> identity providers and user federation providers). Cluster sync will > >>>>> depend on what Infinispan exposes, but I imagine they'll have the > >>>>> required > >>>>> details avail. > >>>> Beside endpoint for full health check (which should summarize all > >>>> services into one flag if I understand correctly, which is good for > >>>> loadbalancer) we should expose separate endpoint for each service > >>>> health, as it is better for operational monitoring systems like Nagios. > >>>> Admins are better informed what is going wrong and they can resolve > >>>> situation more quickly without necessity to search cause of general > >>>> failure flag somewhere else. > >>> We could have a single health endpoint that returns a 200 or 500 and also > >>> returns a json doc with details. Something like: > >>> > >>> { > >>> realm: ok, > >>> users: ok, > >>> realmCache: error, > >>> userCache: error, > >>> identity-providers: { > >>> google: ok, > >>> facebook: error > >>> }, > >>> user-federation: { > >>> ldap: ok > >>> } > >>> } > >>> > >>> I wonder if that's to much details to expose without authentication. > >> This should work, but I miss info about DB connection here. It is > >> crucial from operational point of view as this allows sysadmins quickly > >> detect that connection to DB is broken. > >> > >> I believe this kind of info can be safely exposed without > >> authentication. If the endpoint is clearly documented then access can be > >> always restricted on some network infra (webserver/proxy) ahead of KC. > > DB is "realm" and "users". > > > >>>> Vl. > >>>> > >>>>> ----- Original Message ----- > >>>>>> From: "Vlastimil Elias" > >>>>>> To: "Scott Rossillo" , "Stian Thorgersen" > >>>>>> > >>>>>> Cc: keycloak-dev at lists.jboss.org > >>>>>> Sent: Tuesday, 14 July, 2015 8:34:29 AM > >>>>>> Subject: Re: [keycloak-dev] Operational monitoring of Keycloak server > >>>>>> > >>>>>> Yap, beside server-stat endpoint Stian talked about we should add some > >>>>>> server-health endpoint also to be used for remote health monitoring by > >>>>>> load balancers or systems like Nagios. > >>>>>> Simple http endpoint without authentication (as it doesn't leak any > >>>>>> sensitive information) is typically simplest way how to do this > >>>>>> monitoring. > >>>>>> > >>>>>> Vl. > >>>>>> > >>>>>> On 14.7.2015 05:13, Scott Rossillo wrote: > >>>>>>> Some type of health page would be great too for load balancers to > >>>>>>> monitor. Something that doesn't leak internal information but checks > >>>>>>> behind the scenes that: > >>>>>>> 1. Server can reach its databas(es) > >>>>>>> 2. Server cluster sync is working > >>>>>>> 3. Server can reach federation providers, etc. > >>>>>>> Endpoint should respond to get requests and return an http status > >>>>>>> reflective of server state. > >>>>>>> > >>>>>>> On Mon, Jul 13, 2015 at 11:18 AM Stian Thorgersen >>>>>>> > wrote: > >>>>>>> > >>>>>>> So looks like we're at agreement to add the additional info > >>>>>>> you > >>>>>>> wanted to server info page. > >>>>>>> > >>>>>>> How about we add an additional endpoint server-stat that can > >>>>>>> collect some stats about the server? > >>>>>>> > >>>>>>> ----- Original Message ----- > >>>>>>> > From: "Vlastimil Elias" >>>>>>> > > >>>>>>> > To: "Stian Thorgersen" >>>>>>> > > > >>>>>>> > Cc: keycloak-dev at lists.jboss.org > >>>>>>> > >>>>>>> > Sent: Monday, 13 July, 2015 5:06:34 PM > >>>>>>> > Subject: Re: [keycloak-dev] Operational monitoring of > >>>>>>> > Keycloak > >>>>>>> server > >>>>>>> > > >>>>>>> > Looks like I have to look at WildFly/EAP DMR to see what is > >>>>>>> possible to > >>>>>>> > do with it, as I'm not sure if it is about remote monitoring > >>>>>>> also and > >>>>>>> > if/how it can be use from monitoring systems like Splunk. > >>>>>>> > > >>>>>>> > Vl. > >>>>>>> > > >>>>>>> > On 13.7.2015 15:26, Stian Thorgersen wrote: > >>>>>>> > > In WildFly/EAP that's DMR right? We're planning to make > >>>>>>> Keycloak managable > >>>>>>> > > through that as well. For example everything that goes > >>>>>>> > > into > >>>>>>> > > keycloak-server.json will eventually be moved to > >>>>>>> standalone.xml. Same with > >>>>>>> > > admin endpoints, everything you can do there you'll > >>>>>>> > > eventually > >>>>>>> be able to > >>>>>>> > > do through DMR and jboss-cli as well. > >>>>>>> > > > >>>>>>> > > However, IMO it would make sense to at least expose > >>>>>>> > > Keycloak > >>>>>>> specific > >>>>>>> > > information through the admin endpoints and console as > >>>>>>> > > well. > >>>>>>> Such number > >>>>>>> > > of sessions, etc.. > >>>>>>> > > > >>>>>>> > > ----- Original Message ----- > >>>>>>> > >> From: "Vlastimil Elias" >>>>>>> > > >>>>>>> > >> To: keycloak-dev at lists.jboss.org > >>>>>>> > >>>>>>> > >> Sent: Monday, 13 July, 2015 3:17:16 PM > >>>>>>> > >> Subject: [keycloak-dev] Operational monitoring of > >>>>>>> > >> Keycloak > >>>>>>> > >> server > >>>>>>> > >> > >>>>>>> > >> Hi, > >>>>>>> > >> > >>>>>>> > >> as we deployed KC to production mode for > >>>>>>> https://developers.redhat.com > >>>>>>> > >> we started to think about operational monitoring, for > >>>>>>> > >> example > >>>>>>> from > >>>>>>> > >> Nagios or other systems of this type. > >>>>>>> > >> > >>>>>>> > >> KC user guide doesn't contain any chapter covering this > >>>>>>> topic, also no > >>>>>>> > >> any success over google search, so looks like KC doesn't > >>>>>>> > >> have > >>>>>>> > >> any > >>>>>>> > >> solution for this yet. > >>>>>>> > >> But I believe this is an important area which must be > >>>>>>> > >> solved > >>>>>>> when KC is > >>>>>>> > >> used for production. > >>>>>>> > >> > >>>>>>> > >> I can imagine monitoring of JDBC connection if JPA is > >>>>>>> > >> used, > >>>>>>> monitoring > >>>>>>> > >> of Mongo connection if used as store, monitoring of LDAP > >>>>>>> connection if > >>>>>>> > >> LDAP federation is used etc. > >>>>>>> > >> Also some statistics like numbers of active sso session, > >>>>>>> number of > >>>>>>> > >> logins per minute etc should be provided there. > >>>>>>> > >> > >>>>>>> > >> Monitoring is not about Keycloak core itself, it should > >>>>>>> > >> be > >>>>>>> available for > >>>>>>> > >> extension developers also. For example we implemented own > >>>>>>> > >> UserFederationProvider which calls backend REST services. > >>>>>>> > >> We should be able to add info about this integration into > >>>>>>> monitoring > >>>>>>> > >> endpoint to be able to catch problems with this REST API. > >>>>>>> > >> > >>>>>>> > >> It should be probably implemented same way as used by > >>>>>>> > >> underlying > >>>>>>> > >> WildFly/EAP (JPA/JDBC is probably available for > >>>>>>> > >> monitoring > >>>>>>> there). I'm > >>>>>>> > >> not sure if JMX is used there still or if some new > >>>>>>> > >> framework > >>>>>>> > >> is > >>>>>>> > >> available for it. > >>>>>>> > >> Or KC should use some form of KC REST API for this, which > >>>>>>> should be > >>>>>>> > >> extended by additional info from KC extensions? > >>>>>>> > >> > >>>>>>> > >> What do you think? > >>>>>>> > >> > >>>>>>> > >> Vlastimil > >>>>>>> > >> > >>>>>>> > >> P.S we have https://issues.jboss.org/browse/RHD-552 for > >>>>>>> > >> Red > >>>>>>> > >> Hat > >>>>>>> > >> Developer instance of KC > >>>>>>> > >> > >>>>>>> > >> -- > >>>>>>> > >> 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 > >>>>>>> > > >>>>>>> > > >>>>>>> _______________________________________________ > >>>>>>> keycloak-dev mailing list > >>>>>>> keycloak-dev at lists.jboss.org > >>>>>>> > >>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >>>>>>> > >>>>>> -- > >>>>>> Vlastimil Elias > >>>>>> Principal Software Engineer > >>>>>> jboss.org Development Team > >>>>>> > >>>>>> > >>>> -- > >>>> Vlastimil Elias > >>>> Principal Software Engineer > >>>> jboss.org Development Team > >>>> > >>>> > >> -- > >> Vlastimil Elias > >> Principal Software Engineer > >> jboss.org Development Team > >> > >> > > -- > Vlastimil Elias > Principal Software Engineer > jboss.org Development Team > > From mposolda at redhat.com Thu Jul 16 04:20:01 2015 From: mposolda at redhat.com (Marek Posolda) Date: Thu, 16 Jul 2015 10:20:01 +0200 Subject: [keycloak-dev] Requirements to Elytron for Client 2-way SSL authentication In-Reply-To: <55A5759C.4090609@redhat.com> References: <55A55252.5030804@redhat.com> <55A5759C.4090609@redhat.com> Message-ID: <55A76931.6080502@redhat.com> On 14.7.2015 22:48, Bill Burke wrote: > > On 7/14/2015 2:17 PM, Marek Posolda wrote: >> I want to doublecheck if we are on the same page regarding how client >> certificate authentication should work, so we know what are the >> requirements for Elytron >> to support it. This will allow us to improve things before the Elytron >> code freeze (end of August AFAIK) if needed. >> >> Right now, I am covering just Service accounts and authenticating of >> clients with the certificate. But I believe that for authenticate of >> users, the requirements will be similar. >> >> My view is: >> - Admin will upload certificate of some client via Keycloak admin >> console. (I guess many companies want to use their own certificate >> issued by their trusted CA. IMO later Keycloak should provide the >> ability to easily generate trusted certificates and act as CA - not sure >> if it's something Giriraj is looking at. But for now, I assume that >> trusted certificate is always provided by admin and uploaded to Keycloak >> admin console) >> > Bouncycastle has all the utilities to create our own certificates. I > was thinking that admin could upload one, or we could generate one for > the user. +1 for possibility of both upload and generate certificates. > >> - There is REST endpoint, which allows to authenticate with client >> certificate. For example >> "https://localhost:8443/auth/realms/demo/clients/certificate" . Client >> will be able to start SSL handshake with it's certificate when sending >> request to this endpoint. Server will then verify the underlying >> SSLSession from the SSL socket and check that valid client certificate >> was provided during handshake. It will authenticate client based on that. >> > I'm not sure why you think a specifc URL is needed to do the SSL > handshake. The 2-way SSL handshake happens *before* HTTP request is > even processed > > Client app would redirect to the same SAML or OIDC endpoint it does now. > The keycloak authentication flow would grab the certificate chain from > HttpServletRequest, and validate the client certificate. Sure, we need some code on server, which will retrieve the certificate from the request and authenticate client based on that. I don't care if it's specific URL endpoint or configured authentication flow. But note that ATM I am looking at authenticating clients (Service accounts) not users. Do we want also authentication of clients to be that dynamic and use Authentication SPI? I am not against that, but we would need a way to separate configured authentication flows to be different for users and for clients authentication. For example: Admin may want to authenticate users with password+TOTP , but authenticate clients with client credentials grant or client certificate ATM it seems that for authentication of clients, we need to support quite many different mechanisms (Client credentials grant, signed JWT token, client certificate, kerberos keytab), maybe more will come and will be requested by people. So having possibility to add another mechanism dynamically would be cool. There is difference though that for client authentication we don't want to display any forms, so the supported mechanisms might be limited as well in comparison to user authentication. > > >> To cover this usecase, the Wildfly/Elytron should be able to: >> >> 1) Support "variable" 2-way SSL . In other words, there is possibility >> to set flag "setWantClientAuth(true)" in underlying SSLServerSocket. > IIRC, you can't do this at runtime with NIO or BIO. You must set up the > SSLContext at boot time. What can be a little more dynamic is the > TrustManager, but I'm not sure we need this...read more below... Here I meant that we need a way to ensure that client certificates are "wanted" (not mandatory). Now I am seeing that in EAP6 you have this possibility (Set the attribute |verify-client="want" of HTTPS connector), so looks it is supported for Wildfly10 as well. I will try to doublecheck for sure... | > >> This means that I will be able to access admin console >> "https://localhost:8443/auth/admin" with my browser without client >> certificate, but I will be able to provide client certificate on the >> endpoint "https://localhost:8443/auth/realms/demo/clients/certificate" , >> which is deployed under same context >> >> 2) Dynamically upload it's truststore at runtime or provide SPI to >> add/remove/update certificates in truststore. This is needed, so that >> when admin uploads the certificate of client in KC admin console, I want >> my client to be able to authenticate with the certificate immediatelly >> without need to restart server and edit any JKS files . >> > I'm not sure we really need to have any special integration with > Elytron. We just need to make sure that it can support certificate > chains the way we want to support it. I'm pretty sure EAP 6.x can > support what we want, read on... > > The certficate chain is available from the HttpServletRequest as per the > spec. I'm not exactly sure on the specifics, but all you need is one > "root" certificate in the web server's trust store. Then you could > conceivably create a trusted certificate chain as follows: > > 1) Organization root certificate. > > 2) Root cert signs Realm cert. > > 3) Realm cert signs client cert. > > Following me? My guess is that it would be really easy to issue our own > client certs and that we could have a Required Action that helped set > this up. > Yeah, so if we can just put root certificate in truststore at startup, it's easy. The issue might be if we want root CA to be added to truststore at "runtime" as Stian mentioned in other mail. Will try to doublecheck if it's possible. Marek -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150716/b8bf7981/attachment.html From stian at redhat.com Thu Jul 16 06:57:07 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 16 Jul 2015 06:57:07 -0400 (EDT) Subject: [keycloak-dev] Requirements to Elytron for Client 2-way SSL authentication In-Reply-To: <55A76931.6080502@redhat.com> References: <55A55252.5030804@redhat.com> <55A5759C.4090609@redhat.com> <55A76931.6080502@redhat.com> Message-ID: <1439568054.39921774.1437044227983.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Marek Posolda" > To: "Bill Burke" , keycloak-dev at lists.jboss.org > Sent: Thursday, 16 July, 2015 10:20:01 AM > Subject: Re: [keycloak-dev] Requirements to Elytron for Client 2-way SSL authentication > > On 14.7.2015 22:48, Bill Burke wrote: > > > > On 7/14/2015 2:17 PM, Marek Posolda wrote: > > > > I want to doublecheck if we are on the same page regarding how client > certificate authentication should work, so we know what are the > requirements for Elytron > to support it. This will allow us to improve things before the Elytron > code freeze (end of August AFAIK) if needed. > > Right now, I am covering just Service accounts and authenticating of > clients with the certificate. But I believe that for authenticate of > users, the requirements will be similar. > > My view is: > - Admin will upload certificate of some client via Keycloak admin > console. (I guess many companies want to use their own certificate > issued by their trusted CA. IMO later Keycloak should provide the > ability to easily generate trusted certificates and act as CA - not sure > if it's something Giriraj is looking at. But for now, I assume that > trusted certificate is always provided by admin and uploaded to Keycloak > admin console) > Bouncycastle has all the utilities to create our own certificates. I > was thinking that admin could upload one, or we could generate one for > the user. > +1 for possibility of both upload and generate certificates. > > > > > > > - There is REST endpoint, which allows to authenticate with client > certificate. For example > "https://localhost:8443/auth/realms/demo/clients/certificate" . Client > will be able to start SSL handshake with it's certificate when sending > request to this endpoint. Server will then verify the underlying > SSLSession from the SSL socket and check that valid client certificate > was provided during handshake. It will authenticate client based on that. > I'm not sure why you think a specifc URL is needed to do the SSL > handshake. The 2-way SSL handshake happens *before* HTTP request is > even processed > > Client app would redirect to the same SAML or OIDC endpoint it does now. > The keycloak authentication flow would grab the certificate chain from > HttpServletRequest, and validate the client certificate. > Sure, we need some code on server, which will retrieve the certificate from > the request and authenticate client based on that. I don't care if it's > specific URL endpoint or configured authentication flow. > > But note that ATM I am looking at authenticating clients (Service accounts) > not users. Do we want also authentication of clients to be that dynamic and > use Authentication SPI? I am not against that, but we would need a way to > separate configured authentication flows to be different for users and for > clients authentication. > > For example: Admin may want to authenticate users with password+TOTP , but > authenticate clients with client credentials grant or client certificate > > ATM it seems that for authentication of clients, we need to support quite > many different mechanisms (Client credentials grant, signed JWT token, > client certificate, kerberos keytab), maybe more will come and will be > requested by people. So having possibility to add another mechanism > dynamically would be cool. There is difference though that for client > authentication we don't want to display any forms, so the supported > mechanisms might be limited as well in comparison to user authentication. Would be good to have some SPI for client authentication. It can be much simpler than for users though. A client will have a set of "credentials" associated with it and there will be a set of authentication mechanisms available. There's no flows really is there for authenticating a client? > > > > > > > To cover this usecase, the Wildfly/Elytron should be able to: > > 1) Support "variable" 2-way SSL . In other words, there is possibility > to set flag "setWantClientAuth(true)" in underlying SSLServerSocket. > IIRC, you can't do this at runtime with NIO or BIO. You must set up the > SSLContext at boot time. What can be a little more dynamic is the > TrustManager, but I'm not sure we need this...read more below... > Here I meant that we need a way to ensure that client certificates are > "wanted" (not mandatory). Now I am seeing that in EAP6 you have this > possibility (Set the attribute verify-client = "want" of HTTPS connector), > so looks > it is supported for Wildfly10 as well. I will try to doublecheck for sure... > > > > > > > This means that I will be able to access admin console > "https://localhost:8443/auth/admin" with my browser without client > certificate, but I will be able to provide client certificate on the > endpoint "https://localhost:8443/auth/realms/demo/clients/certificate" , > which is deployed under same context > > 2) Dynamically upload it's truststore at runtime or provide SPI to > add/remove/update certificates in truststore. This is needed, so that > when admin uploads the certificate of client in KC admin console, I want > my client to be able to authenticate with the certificate immediatelly > without need to restart server and edit any JKS files . > I'm not sure we really need to have any special integration with > Elytron. We just need to make sure that it can support certificate > chains the way we want to support it. I'm pretty sure EAP 6.x can > support what we want, read on... > > The certficate chain is available from the HttpServletRequest as per the > spec. I'm not exactly sure on the specifics, but all you need is one > "root" certificate in the web server's trust store. Then you could > conceivably create a trusted certificate chain as follows: > > 1) Organization root certificate. > > 2) Root cert signs Realm cert. > > 3) Realm cert signs client cert. > > Following me? My guess is that it would be really easy to issue our own > client certs and that we could have a Required Action that helped set > this up. > Yeah, so if we can just put root certificate in truststore at startup, it's > easy. The issue might be if we want root CA to be added to truststore at > "runtime" as Stian mentioned in other mail. Will try to doublecheck if it's > possible. > > Marek > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Thu Jul 16 07:02:54 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 16 Jul 2015 07:02:54 -0400 (EDT) Subject: [keycloak-dev] 1.4.0.Final release on 28th In-Reply-To: <2109363388.39923216.1437044508315.JavaMail.zimbra@redhat.com> Message-ID: <916613838.39923541.1437044574214.JavaMail.zimbra@redhat.com> I'm aiming to release 1.4.0.Final on the 28th so we need to wrap things up next week. From marcelo.sampaio at serpro.gov.br Thu Jul 16 08:08:36 2015 From: marcelo.sampaio at serpro.gov.br (Marcelo Arthur Sampaio) Date: Thu, 16 Jul 2015 12:08:36 +0000 Subject: [keycloak-dev] Custom KeycloakPrincipal in adapter In-Reply-To: <066c6b337219038d4b76b126bf9929991432327b@serpro.gov.br> References: <639500c89e16e56726f24084401e2a8720a41028@serpro.gov.br> <55A0DB0B.2060305@redhat.com> <53b19034fc4c9e6996f72a755db490f3d24e2d41@serpro.gov.br> <1a341fc7d5e6555715273bd3d1334d83e99dcb23@serpro.gov.br> <98e8979d82af8fd40b86e50a88a3782a8df218e5@serpro.gov.br> <066c6b337219038d4b76b126bf9929991432327b@serpro.gov.br> Message-ID: <0fe16ec13ff056fff2cdb28ebfa30f51ba94e8d1@serpro.gov.br> Hi, I created my custom valve to set my user principal in the security context. It would be possible to change the org.keycloak.subsystem.as7.KeycloakAdapterConfigDeploymentProcessor class so that the custom valve? I would like to be able to set my custom valve and extends the keycloakValve. Line 93: valve.setValveClass (KeycloakAuthenticatorValve.class.getName ()); maybe change to config the valve in module.xml or other config file. Thanks. Em 11/07/2015 05:59:55, Marek Posolda escreveu: > > Not sure why you need this. But maybe easiest is to create just Http Servlet filter (this can be configured in web.xml and doesn't use any tomcat/jboss-web specific stuff) . In this filter, you will create HttpServletRequestWrapper wrapping the original HttpServletRequest, but you will override just the method "getUserPrincipal" in your wrapper class. Here you can do any hacking you want and return any principal instance you want. All the data from Keycloak (KeycloakSecurityContext, AccessToken, IDToken, original KeycloakPrincipal...) are already available in the filter, so you can use them for create your own principal. > > Marek > > On 10.7.2015 21:02, Marcelo Arthur Sampaio wrote: > > > > > Hi, > > > > I need to implement my custom security Principal. > > What is the best way to do it in adapter for jboss eap. > > > > Create new adapter for my business extends RefreshableKeycloakSecurityContext, KeycloakAuthenticatorValve and set the new valve class in KeycloakAdapterConfigDeploymentProcessor? > > > > I need to set new attributes in principal and get principal in the SecurityContext. > > > > There is an other way? > > > > Thanks. > > - > > > > > > "Esta mensagem do SERVI?O FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa p?blica federal regida pelo disposto na Lei Federal n? 5.615, ? enviada exclusivamente a seu destinat?rio e pode conter informa??es confidenciais, protegidas por sigilo profissional. Sua utiliza??o desautorizada ? ilegal e sujeita o infrator ?s penas da lei. Se voc? a recebeu indevidamente, queira, por gentileza, reenvi?-la ao emitente, esclarecendo o equ?voco." > > > > "This message from SERVI?O FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) -- a government company established under Brazilian law (5.615/70) -- is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure." > > > > _______________________________________________ keycloak-dev mailing list > > keycloak-dev at lists.jboss.org> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev> > > - "Esta mensagem do SERVI?O FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa p?blica federal regida pelo disposto na Lei Federal n? 5.615, ? enviada exclusivamente a seu destinat?rio e pode conter informa??es confidenciais, protegidas por sigilo profissional. Sua utiliza??o desautorizada ? ilegal e sujeita o infrator ?s penas da lei. Se voc? a recebeu indevidamente, queira, por gentileza, reenvi?-la ao emitente, esclarecendo o equ?voco." "This message from SERVI?O FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) -- a government company established under Brazilian law (5.615/70) -- is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150716/bbc94b1b/attachment.html From bburke at redhat.com Thu Jul 16 08:40:11 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 16 Jul 2015 08:40:11 -0400 Subject: [keycloak-dev] Requirements to Elytron for Client 2-way SSL authentication In-Reply-To: <55A76931.6080502@redhat.com> References: <55A55252.5030804@redhat.com> <55A5759C.4090609@redhat.com> <55A76931.6080502@redhat.com> Message-ID: <55A7A62B.2080701@redhat.com> On 7/16/2015 4:20 AM, Marek Posolda wrote: >> I'm not sure we really need to have any special integration with >> Elytron. We just need to make sure that it can support certificate >> chains the way we want to support it. I'm pretty sure EAP 6.x can >> support what we want, read on... >> >> The certficate chain is available from the HttpServletRequest as per the >> spec. I'm not exactly sure on the specifics, but all you need is one >> "root" certificate in the web server's trust store. Then you could >> conceivably create a trusted certificate chain as follows: >> >> 1) Organization root certificate. >> >> 2) Root cert signs Realm cert. >> >> 3) Realm cert signs client cert. >> >> Following me? My guess is that it would be really easy to issue our own >> client certs and that we could have a Required Action that helped set >> this up. >> > Yeah, so if we can just put root certificate in truststore at startup, > it's easy. The issue might be if we want root CA to be added to > truststore at "runtime" as Stian mentioned in other mail. Will try to > doublecheck if it's possible. > I don't know how well cert chains are supported. I guess you'll find out :) For client auth, shouldn't we just support the best practices and whatever the spec requires? 2-way SSL is a pain in the ass, wouldn't you be better off with PIN+OTP? Much easier to set up and manage. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Thu Jul 16 08:57:58 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 16 Jul 2015 08:57:58 -0400 (EDT) Subject: [keycloak-dev] Requirements to Elytron for Client 2-way SSL authentication In-Reply-To: <55A7A62B.2080701@redhat.com> References: <55A55252.5030804@redhat.com> <55A5759C.4090609@redhat.com> <55A76931.6080502@redhat.com> <55A7A62B.2080701@redhat.com> Message-ID: <1753443761.39968886.1437051478341.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: "Marek Posolda" , keycloak-dev at lists.jboss.org > Sent: Thursday, 16 July, 2015 2:40:11 PM > Subject: Re: [keycloak-dev] Requirements to Elytron for Client 2-way SSL authentication > > > > On 7/16/2015 4:20 AM, Marek Posolda wrote: > >> I'm not sure we really need to have any special integration with > >> Elytron. We just need to make sure that it can support certificate > >> chains the way we want to support it. I'm pretty sure EAP 6.x can > >> support what we want, read on... > >> > >> The certficate chain is available from the HttpServletRequest as per the > >> spec. I'm not exactly sure on the specifics, but all you need is one > >> "root" certificate in the web server's trust store. Then you could > >> conceivably create a trusted certificate chain as follows: > >> > >> 1) Organization root certificate. > >> > >> 2) Root cert signs Realm cert. > >> > >> 3) Realm cert signs client cert. > >> > >> Following me? My guess is that it would be really easy to issue our own > >> client certs and that we could have a Required Action that helped set > >> this up. > >> > > Yeah, so if we can just put root certificate in truststore at startup, > > it's easy. The issue might be if we want root CA to be added to > > truststore at "runtime" as Stian mentioned in other mail. Will try to > > doublecheck if it's possible. > > > > I don't know how well cert chains are supported. I guess you'll find out :) > > > For client auth, shouldn't we just support the best practices and > whatever the spec requires? 2-way SSL is a pain in the ass, wouldn't > you be better off with PIN+OTP? Much easier to set up and manage. I was thinking 2-way ssl would be easier - ssl is required in either case so a client has to have that enabled, why not utilize that to also authenticate the client? > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From bburke at redhat.com Thu Jul 16 20:29:48 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 16 Jul 2015 20:29:48 -0400 Subject: [keycloak-dev] deprecated removals in future Message-ID: <55A84C7C.1050207@redhat.com> We're accumulating deprecated metadata in models and data model. Eventually we should draw a line in the sand and say we will only support migration from a certain version to current. i.e. Keycloak 2.0 would only allow migration from the last 1.x version. We need to clean all the old stuff out prior to product. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Fri Jul 17 02:22:36 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 17 Jul 2015 02:22:36 -0400 (EDT) Subject: [keycloak-dev] deprecated removals in future In-Reply-To: <55A84C7C.1050207@redhat.com> References: <55A84C7C.1050207@redhat.com> Message-ID: <1352841341.40862378.1437114156177.JavaMail.zimbra@redhat.com> We shouldn't need deprecated stuff in realm model and user model. That's what the migration stuff is there to do. Problem with regards to json representations is that we don't have an elegant way to deal with migration. If we add that we won't have the problem of keeping deprecated stuff around and it'll just be a matter of keeping some json transformation classes similar to what we do for jpa/mongo. ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Friday, 17 July, 2015 2:29:48 AM > Subject: [keycloak-dev] deprecated removals in future > > We're accumulating deprecated metadata in models and data model. > Eventually we should draw a line in the sand and say we will only > support migration from a certain version to current. > > i.e. Keycloak 2.0 would only allow migration from the last 1.x version. > > We need to clean all the old stuff out prior to product. > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From mposolda at redhat.com Fri Jul 17 02:24:50 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 17 Jul 2015 08:24:50 +0200 Subject: [keycloak-dev] deprecated removals in future In-Reply-To: <55A84C7C.1050207@redhat.com> References: <55A84C7C.1050207@redhat.com> Message-ID: <55A89FB2.3050704@redhat.com> +1 Hopefully we can drop backwards compatibility for JSON reps between 1.X and 2.0 (ie. realm JSON representation exported in 1.X is not supposed to work to be imported in 2.0). That will allow us to drop old metadata from JSON and models and just create DB migration scripts for 1.X to 2.0 migration. Marek On 17.7.2015 02:29, Bill Burke wrote: > We're accumulating deprecated metadata in models and data model. > Eventually we should draw a line in the sand and say we will only > support migration from a certain version to current. > > i.e. Keycloak 2.0 would only allow migration from the last 1.x version. > > We need to clean all the old stuff out prior to product. From stian at redhat.com Fri Jul 17 02:28:33 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 17 Jul 2015 02:28:33 -0400 (EDT) Subject: [keycloak-dev] deprecated removals in future In-Reply-To: <55A89FB2.3050704@redhat.com> References: <55A84C7C.1050207@redhat.com> <55A89FB2.3050704@redhat.com> Message-ID: <662658053.40863005.1437114513697.JavaMail.zimbra@redhat.com> -1 It'll actually be more work to drop backwards compatibility for the model as we'd have to write a new "starting" point. For JSON representations it's just messy and has deprecated stuff in it because I did a crap job at implementing it. If we write a proper way to migrate json representations we won't need this and it'll just be a transformation pipeline that transforms the json to match the representation classes. ----- Original Message ----- > From: "Marek Posolda" > To: "Bill Burke" , keycloak-dev at lists.jboss.org > Sent: Friday, 17 July, 2015 8:24:50 AM > Subject: Re: [keycloak-dev] deprecated removals in future > > +1 > > Hopefully we can drop backwards compatibility for JSON reps between 1.X > and 2.0 (ie. realm JSON representation exported in 1.X is not supposed > to work to be imported in 2.0). That will allow us to drop old metadata > from JSON and models and just create DB migration scripts for 1.X to 2.0 > migration. > > Marek > > On 17.7.2015 02:29, Bill Burke wrote: > > We're accumulating deprecated metadata in models and data model. > > Eventually we should draw a line in the sand and say we will only > > support migration from a certain version to current. > > > > i.e. Keycloak 2.0 would only allow migration from the last 1.x version. > > > > We need to clean all the old stuff out prior to product. > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From mposolda at redhat.com Fri Jul 17 02:35:48 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 17 Jul 2015 08:35:48 +0200 Subject: [keycloak-dev] deprecated removals in future In-Reply-To: <1352841341.40862378.1437114156177.JavaMail.zimbra@redhat.com> References: <55A84C7C.1050207@redhat.com> <1352841341.40862378.1437114156177.JavaMail.zimbra@redhat.com> Message-ID: <55A8A244.8040004@redhat.com> On 17.7.2015 08:22, Stian Thorgersen wrote: > We shouldn't need deprecated stuff in realm model and user model. That's what the migration stuff is there to do. > > Problem with regards to json representations is that we don't have an elegant way to deal with migration. If we add that we won't have the problem of keeping deprecated stuff around and it'll just be a matter of keeping some json transformation classes similar to what we do for jpa/mongo. Maybe for JSON representations, we can use "JsonAnyGetter" and "JsonAnySetter" annotations to migrate old properties from representation classes. Problem is, that this approach is always a bit more work than keeping the old properties and migrate them directly. Like for DB, we have 2 approaches for migrations right now: 1) MigrationModelManager, which is easier to use, but it requires that all the old properties are still kept on JPA and Mongo entity classes. 2) Liquibase and Mongo specific migrations, which migrates old data at DB level and doesn't require old properties to be kept. But it's pain to write migration scripts for them. Maybe easiest is between minor versions to keep old properties and use the "easy" way of migrations, but for major versions, use the generic approach and get rid of all the outdated stuff from both JSON and DB? Marek > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Friday, 17 July, 2015 2:29:48 AM >> Subject: [keycloak-dev] deprecated removals in future >> >> We're accumulating deprecated metadata in models and data model. >> Eventually we should draw a line in the sand and say we will only >> support migration from a certain version to current. >> >> i.e. Keycloak 2.0 would only allow migration from the last 1.x version. >> >> We need to clean all the old stuff out prior to product. >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150717/4d25a85b/attachment.html From stian at redhat.com Fri Jul 17 03:34:19 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 17 Jul 2015 03:34:19 -0400 (EDT) Subject: [keycloak-dev] deprecated removals in future In-Reply-To: <55A8A244.8040004@redhat.com> References: <55A84C7C.1050207@redhat.com> <1352841341.40862378.1437114156177.JavaMail.zimbra@redhat.com> <55A8A244.8040004@redhat.com> Message-ID: <1522968040.40879867.1437118459445.JavaMail.zimbra@redhat.com> Let's discuss this and the simplified realm model next Thursday. ----- Original Message ----- > From: "Marek Posolda" > To: "Stian Thorgersen" , "Bill Burke" > Cc: keycloak-dev at lists.jboss.org > Sent: Friday, 17 July, 2015 8:35:48 AM > Subject: Re: [keycloak-dev] deprecated removals in future > > On 17.7.2015 08:22, Stian Thorgersen wrote: > > We shouldn't need deprecated stuff in realm model and user model. That's > > what the migration stuff is there to do. > > > > Problem with regards to json representations is that we don't have an > > elegant way to deal with migration. If we add that we won't have the > > problem of keeping deprecated stuff around and it'll just be a matter of > > keeping some json transformation classes similar to what we do for > > jpa/mongo. > Maybe for JSON representations, we can use "JsonAnyGetter" and > "JsonAnySetter" annotations to migrate old properties from > representation classes. Problem is, that this approach is always a bit > more work than keeping the old properties and migrate them directly. > > Like for DB, we have 2 approaches for migrations right now: > 1) MigrationModelManager, which is easier to use, but it requires that > all the old properties are still kept on JPA and Mongo entity classes. > 2) Liquibase and Mongo specific migrations, which migrates old data at > DB level and doesn't require old properties to be kept. But it's pain to > write migration scripts for them. > > Maybe easiest is between minor versions to keep old properties and use > the "easy" way of migrations, but for major versions, use the generic > approach and get rid of all the outdated stuff from both JSON and DB? > > Marek > > > > ----- Original Message ----- > >> From: "Bill Burke" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Friday, 17 July, 2015 2:29:48 AM > >> Subject: [keycloak-dev] deprecated removals in future > >> > >> We're accumulating deprecated metadata in models and data model. > >> Eventually we should draw a line in the sand and say we will only > >> support migration from a certain version to current. > >> > >> i.e. Keycloak 2.0 would only allow migration from the last 1.x version. > >> > >> We need to clean all the old stuff out prior to product. > >> -- > >> Bill Burke > >> JBoss, a division of Red Hat > >> http://bill.burkecentral.com > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > From stian at redhat.com Fri Jul 17 04:00:52 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 17 Jul 2015 04:00:52 -0400 (EDT) Subject: [keycloak-dev] [wildfly-dev] Feature pack provisioning In-Reply-To: <031C9ABB-1162-49A2-84D4-1E88A292C641@redhat.com> References: <930099469.16650706.1436450574022.JavaMail.zimbra@redhat.com> <031C9ABB-1162-49A2-84D4-1E88A292C641@redhat.com> Message-ID: <1204482943.40886040.1437120052439.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Jason Greene" > To: "Marko Strukelj" > Cc: "keycloak dev" , "WildFly Developers" > Sent: Thursday, 16 July, 2015 12:11:53 AM > Subject: Re: [wildfly-dev] Feature pack provisioning > > The feature-pack build tool is a tool thats intended for creating WildFly > distributions (#1), its not intended to create layered project/products[A] / > overlays (#2). For #2, the solution is really just packaging a subsystem in > an extension jar, and thats something easily achieved with just the standard > maven tools. > > I can certainly see why you would want to do #1 or #2, but I have a hard time > seeing why you would want to do both. #1 is our standalone Keycloak server distribution - this is the recommended distribution for production or non-JEE developers #2 is intended to be used by JEE developers so they can have the KC server bits available in a single WF instance for development - this is intended as a distribution for JEE developers only > > As to #3, the notion of a runtime provisioning system similar to something > like a yum tool is a long term goal, which I totally agree we need, but its > going to be a while before we can get there (Definitely not 10 nor 11). > Alexey has been assembling requirements for it, and has some ideas around > the packaging format. We really want to get it right, so the plan is to let > it grow organically until its proven to be a solid system, and only then > switch to it. > > [A] > https://developer.jboss.org/hfurl/redirectToHFURL.jspa?url=/docs/DOC-47927¶ms= > > On Jul 9, 2015, at 9:02 AM, Marko Strukelj wrote: > > > > > > Currently wildfly-server-provisioning-maven-plugin always generates a full > > Wildfly distribution. For Keycloak project we have three different cases > > of provisioning, and it would be great to be able to cover it with a > > common wildfly provided tool: > > > > 1) full server distribution > > 2) overlay distribution (unzip into existing OOTB Wildfly distribution - > > your problem if you use unsupported Wildfly version) > > 3) provision into existing Wildfly server detecting version mismatches, and > > configuring existing and additional subsystems for Keycloak to run > > properly. > > > > > > First one is what?s currently supported, and what we use. > > > > Second one is what we currently hack up by extracting modules directory > > from (1) - it would support this use case better if > > wildfly-server-provisioning-maven-plugin could generate 'modules only' for > > example. > > > > The third one requires a CLI installer tool. I?m not aware that currently > > there is something for that, and we are loath to develop one from scratch. > > > > Is it realistic to expect 2) and 3) in not so distant future? > > > > > > - marko > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From stian at redhat.com Fri Jul 17 08:05:12 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 17 Jul 2015 08:05:12 -0400 (EDT) Subject: [keycloak-dev] READ THIS! Updated line endings on all files In-Reply-To: <1194768751.40956730.1437134152442.JavaMail.zimbra@redhat.com> Message-ID: <2128066613.40960882.1437134712202.JavaMail.zimbra@redhat.com> Due to files have different line-endings if they are edited on Linux or Windows there's often issues with merging. To resolved this we've added .gitattributes file that sets the default line ending on files. This makes Git automatically convert line endings for us. One issue is that if you have commits that are not yet in master you may have issues rebasing on master after this change. This is caused by files you've changed may have different line endings causing in a merge conflict. This is easily resolved though. Instead of doing a regular rebase run it with: git rebase -Xignore-space-at-eol upstream/master If that doesn't work try: git rebase -X renormalize upstream/master If neither of those works let me know and we'll figure out something! From bburke at redhat.com Fri Jul 17 08:33:31 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 17 Jul 2015 08:33:31 -0400 Subject: [keycloak-dev] deprecated removals in future In-Reply-To: <662658053.40863005.1437114513697.JavaMail.zimbra@redhat.com> References: <55A84C7C.1050207@redhat.com> <55A89FB2.3050704@redhat.com> <662658053.40863005.1437114513697.JavaMail.zimbra@redhat.com> Message-ID: <55A8F61B.5020907@redhat.com> I'm not spending a week+ writing error prone raw JDBC and generic JSON scripts. There's a lot of model migration code that would be a shit ton of raw SQL if you wanted to convert it. A new starting point would be half a days work. On 7/17/2015 2:28 AM, Stian Thorgersen wrote: > -1 It'll actually be more work to drop backwards compatibility for the model as we'd have to write a new "starting" point. For JSON representations it's just messy and has deprecated stuff in it because I did a crap job at implementing it. If we write a proper way to migrate json representations we won't need this and it'll just be a transformation pipeline that transforms the json to match the representation classes. > > ----- Original Message ----- >> From: "Marek Posolda" >> To: "Bill Burke" , keycloak-dev at lists.jboss.org >> Sent: Friday, 17 July, 2015 8:24:50 AM >> Subject: Re: [keycloak-dev] deprecated removals in future >> >> +1 >> >> Hopefully we can drop backwards compatibility for JSON reps between 1.X >> and 2.0 (ie. realm JSON representation exported in 1.X is not supposed >> to work to be imported in 2.0). That will allow us to drop old metadata >> from JSON and models and just create DB migration scripts for 1.X to 2.0 >> migration. >> >> Marek >> >> On 17.7.2015 02:29, Bill Burke wrote: >>> We're accumulating deprecated metadata in models and data model. >>> Eventually we should draw a line in the sand and say we will only >>> support migration from a certain version to current. >>> >>> i.e. Keycloak 2.0 would only allow migration from the last 1.x version. >>> >>> We need to clean all the old stuff out prior to product. >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Fri Jul 17 09:21:03 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 17 Jul 2015 09:21:03 -0400 (EDT) Subject: [keycloak-dev] deprecated removals in future In-Reply-To: <55A8F61B.5020907@redhat.com> References: <55A84C7C.1050207@redhat.com> <55A89FB2.3050704@redhat.com> <662658053.40863005.1437114513697.JavaMail.zimbra@redhat.com> <55A8F61B.5020907@redhat.com> Message-ID: <1920602867.40997219.1437139263821.JavaMail.zimbra@redhat.com> Yeah, so let's drop the SQL stuff. We'll only have one single realm provider which is backed by json representations. Then we store json representations in Mongo or as blobs in the database. After that we only have to deal with one migration. ----- Original Message ----- > From: "Bill Burke" > To: "Stian Thorgersen" , "Marek Posolda" > Cc: keycloak-dev at lists.jboss.org > Sent: Friday, 17 July, 2015 2:33:31 PM > Subject: Re: [keycloak-dev] deprecated removals in future > > I'm not spending a week+ writing error prone raw JDBC and generic JSON > scripts. There's a lot of model migration code that would be a shit ton > of raw SQL if you wanted to convert it. A new starting point would be > half a days work. > > On 7/17/2015 2:28 AM, Stian Thorgersen wrote: > > -1 It'll actually be more work to drop backwards compatibility for the > > model as we'd have to write a new "starting" point. For JSON > > representations it's just messy and has deprecated stuff in it because I > > did a crap job at implementing it. If we write a proper way to migrate > > json representations we won't need this and it'll just be a transformation > > pipeline that transforms the json to match the representation classes. > > > > ----- Original Message ----- > >> From: "Marek Posolda" > >> To: "Bill Burke" , keycloak-dev at lists.jboss.org > >> Sent: Friday, 17 July, 2015 8:24:50 AM > >> Subject: Re: [keycloak-dev] deprecated removals in future > >> > >> +1 > >> > >> Hopefully we can drop backwards compatibility for JSON reps between 1.X > >> and 2.0 (ie. realm JSON representation exported in 1.X is not supposed > >> to work to be imported in 2.0). That will allow us to drop old metadata > >> from JSON and models and just create DB migration scripts for 1.X to 2.0 > >> migration. > >> > >> Marek > >> > >> On 17.7.2015 02:29, Bill Burke wrote: > >>> We're accumulating deprecated metadata in models and data model. > >>> Eventually we should draw a line in the sand and say we will only > >>> support migration from a certain version to current. > >>> > >>> i.e. Keycloak 2.0 would only allow migration from the last 1.x version. > >>> > >>> We need to clean all the old stuff out prior to product. > >> > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > From bburke at redhat.com Fri Jul 17 09:45:30 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 17 Jul 2015 09:45:30 -0400 Subject: [keycloak-dev] deprecated removals in future In-Reply-To: <1920602867.40997219.1437139263821.JavaMail.zimbra@redhat.com> References: <55A84C7C.1050207@redhat.com> <55A89FB2.3050704@redhat.com> <662658053.40863005.1437114513697.JavaMail.zimbra@redhat.com> <55A8F61B.5020907@redhat.com> <1920602867.40997219.1437139263821.JavaMail.zimbra@redhat.com> Message-ID: <55A906FA.20909@redhat.com> You would still need to write a shit ton of raw SQL and JSON scripts to convert from old models (1.0, 1.1, 1.2, 1.3, 1.4, etc...) to the new Json realm model you want to instill. I really worry that we'll be writing a crappy version of Mongo on top of a relational store. On 7/17/2015 9:21 AM, Stian Thorgersen wrote: > Yeah, so let's drop the SQL stuff. We'll only have one single realm provider which is backed by json representations. Then we store json representations in Mongo or as blobs in the database. > > After that we only have to deal with one migration. > > ----- Original Message ----- >> From: "Bill Burke" >> To: "Stian Thorgersen" , "Marek Posolda" >> Cc: keycloak-dev at lists.jboss.org >> Sent: Friday, 17 July, 2015 2:33:31 PM >> Subject: Re: [keycloak-dev] deprecated removals in future >> >> I'm not spending a week+ writing error prone raw JDBC and generic JSON >> scripts. There's a lot of model migration code that would be a shit ton >> of raw SQL if you wanted to convert it. A new starting point would be >> half a days work. >> >> On 7/17/2015 2:28 AM, Stian Thorgersen wrote: >>> -1 It'll actually be more work to drop backwards compatibility for the >>> model as we'd have to write a new "starting" point. For JSON >>> representations it's just messy and has deprecated stuff in it because I >>> did a crap job at implementing it. If we write a proper way to migrate >>> json representations we won't need this and it'll just be a transformation >>> pipeline that transforms the json to match the representation classes. >>> >>> ----- Original Message ----- >>>> From: "Marek Posolda" >>>> To: "Bill Burke" , keycloak-dev at lists.jboss.org >>>> Sent: Friday, 17 July, 2015 8:24:50 AM >>>> Subject: Re: [keycloak-dev] deprecated removals in future >>>> >>>> +1 >>>> >>>> Hopefully we can drop backwards compatibility for JSON reps between 1.X >>>> and 2.0 (ie. realm JSON representation exported in 1.X is not supposed >>>> to work to be imported in 2.0). That will allow us to drop old metadata >>>> from JSON and models and just create DB migration scripts for 1.X to 2.0 >>>> migration. >>>> >>>> Marek >>>> >>>> On 17.7.2015 02:29, Bill Burke wrote: >>>>> We're accumulating deprecated metadata in models and data model. >>>>> Eventually we should draw a line in the sand and say we will only >>>>> support migration from a certain version to current. >>>>> >>>>> i.e. Keycloak 2.0 would only allow migration from the last 1.x version. >>>>> >>>>> We need to clean all the old stuff out prior to product. >>>> >>>> _______________________________________________ >>>> 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 >> -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From mposolda at redhat.com Fri Jul 17 13:37:58 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 17 Jul 2015 19:37:58 +0200 Subject: [keycloak-dev] Email/ username case-sensitivity issues Message-ID: <55A93D76.7050909@redhat.com> There are some case-sensitivity issues, which cause that sometimes you can add object with duplicated email/username into DB etc. Some details are at https://issues.jboss.org/browse/KEYCLOAK-1545 or https://issues.jboss.org/browse/KEYCLOAK-1551 . Those issues happened with LDAP, but generally issues are not LDAP specific - for example even without LDAP integration you can add user with email "JOHN at keycloak.org" and then "john at keycloak.org" . Second user is created successfully, which doesn't look correct to me. The solutions I can see is: 1) Ensure that username and email is always added lowercased into DB and then searched lowercased. We already fixed similar issues earlier, but not entirely . Right now, we are adding username lowercased and searching both username and email lowercased, but we are not adding email lowercased. I've sent PR when I am convert both username and email to lowercase in UserAdapter.setEmail and UserAdapter.setUserName - https://github.com/mposolda/keycloak/commit/66f16bf654fc22570ce9ef7b34c47039266fe61d 2) Another approach can be to add usernames and emails case sensitively, but instead ensure that DB searching is case insensitive (lowercased). For JPA there is "lower" function in HQL, but I am not sure if it's supported for various databases (and I would really like to avoid DB specific failures TBH...;-) ). For Mongo there is possibility to search with regex to achieve case-insensitive search but it sucks due to performance- so in this case we may need to add separate columns username_lowercased and email_lowercased, which will be used for searching to ensure index is used... I like (1) much more and that's what I used in PR. Any objections against merging it? Or is it bad to assume that email are case insensitive? Strictly said, the "local" part of email is supposed to be case sensitive, so "JOHN at keycloak.org" and "john at keycloak.org" are theoretically different emails. But in reality most organizations and mail servers treat them as same emails - including Google. Just checked that I can successfully login to Google with MPosOLDA at gmail.com . Marek From mposolda at redhat.com Fri Jul 17 13:53:44 2015 From: mposolda at redhat.com (Marek Posolda) Date: Fri, 17 Jul 2015 19:53:44 +0200 Subject: [keycloak-dev] deprecated removals in future In-Reply-To: <55A906FA.20909@redhat.com> References: <55A84C7C.1050207@redhat.com> <55A89FB2.3050704@redhat.com> <662658053.40863005.1437114513697.JavaMail.zimbra@redhat.com> <55A8F61B.5020907@redhat.com> <1920602867.40997219.1437139263821.JavaMail.zimbra@redhat.com> <55A906FA.20909@redhat.com> Message-ID: <55A94128.9070900@redhat.com> The approach like MigrationModelManager or our current JSON migration is cool and easy, but it stops working if you want to get rid of outdated properties. For example if you want to remove RealmModel.getFoo() but MigrateTo13.java is using getFoo property, you will see the errors with new versions where property "foo" on RealmModel is not available anymore... So what if we use something like "milestones" releases and support migration just between those? For example milestone release can be 1.5 , 1.10 and 1.15 (or 2.0 or whatever). Then if someone wants to migrate from 1.0 to 1.12 he needs to go by migration path like: - First migrate from 1.0 to 1.5 - Then migrate from 1.5 to 1.10 - Finally migrate from 1.10 to 1.12 For the 1.0 to 1.5 we can use the "easy" approach with keeping of all the outdated properties on models and JSON representations. Then in 1.6 we will start from scratch and remove previous migrations and old properties until 1.5. So migration to 1.6 is supported just from 1.5 etc. For the 1.6 we will start from scratch with everything including liquibase DDL scripts - to avoid situation when there are more and more liquibase commands executed at initial boot. Marek On 17.7.2015 15:45, Bill Burke wrote: > You would still need to write a shit ton of raw SQL and JSON scripts > to convert from old models (1.0, 1.1, 1.2, 1.3, 1.4, etc...) to the > new Json realm model you want to instill. > > I really worry that we'll be writing a crappy version of Mongo on top > of a relational store. > > On 7/17/2015 9:21 AM, Stian Thorgersen wrote: >> Yeah, so let's drop the SQL stuff. We'll only have one single realm >> provider which is backed by json representations. Then we store json >> representations in Mongo or as blobs in the database. >> >> After that we only have to deal with one migration. >> >> ----- Original Message ----- >>> From: "Bill Burke" >>> To: "Stian Thorgersen" , "Marek Posolda" >>> >>> Cc: keycloak-dev at lists.jboss.org >>> Sent: Friday, 17 July, 2015 2:33:31 PM >>> Subject: Re: [keycloak-dev] deprecated removals in future >>> >>> I'm not spending a week+ writing error prone raw JDBC and generic JSON >>> scripts. There's a lot of model migration code that would be a shit >>> ton >>> of raw SQL if you wanted to convert it. A new starting point would be >>> half a days work. >>> >>> On 7/17/2015 2:28 AM, Stian Thorgersen wrote: >>>> -1 It'll actually be more work to drop backwards compatibility for the >>>> model as we'd have to write a new "starting" point. For JSON >>>> representations it's just messy and has deprecated stuff in it >>>> because I >>>> did a crap job at implementing it. If we write a proper way to migrate >>>> json representations we won't need this and it'll just be a >>>> transformation >>>> pipeline that transforms the json to match the representation classes. >>>> >>>> ----- Original Message ----- >>>>> From: "Marek Posolda" >>>>> To: "Bill Burke" , keycloak-dev at lists.jboss.org >>>>> Sent: Friday, 17 July, 2015 8:24:50 AM >>>>> Subject: Re: [keycloak-dev] deprecated removals in future >>>>> >>>>> +1 >>>>> >>>>> Hopefully we can drop backwards compatibility for JSON reps >>>>> between 1.X >>>>> and 2.0 (ie. realm JSON representation exported in 1.X is not >>>>> supposed >>>>> to work to be imported in 2.0). That will allow us to drop old >>>>> metadata >>>>> from JSON and models and just create DB migration scripts for 1.X >>>>> to 2.0 >>>>> migration. >>>>> >>>>> Marek >>>>> >>>>> On 17.7.2015 02:29, Bill Burke wrote: >>>>>> We're accumulating deprecated metadata in models and data model. >>>>>> Eventually we should draw a line in the sand and say we will only >>>>>> support migration from a certain version to current. >>>>>> >>>>>> i.e. Keycloak 2.0 would only allow migration from the last 1.x >>>>>> version. >>>>>> >>>>>> We need to clean all the old stuff out prior to product. >>>>> >>>>> _______________________________________________ >>>>> 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 srossillo at smartling.com Fri Jul 17 23:13:22 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Sat, 18 Jul 2015 03:13:22 +0000 Subject: [keycloak-dev] Tell if user is logged in via idp Message-ID: Is there a way to tell if a user logged in via an idp? We don't see anything on the access token or id token to indicate. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150718/5f0cbc55/attachment.html From bburke at redhat.com Sat Jul 18 09:07:29 2015 From: bburke at redhat.com (Bill Burke) Date: Sat, 18 Jul 2015 09:07:29 -0400 Subject: [keycloak-dev] Tell if user is logged in via idp In-Reply-To: References: Message-ID: <55AA4F91.3080708@redhat.com> nada. jira? On 7/17/2015 11:13 PM, Scott Rossillo wrote: > Is there a way to tell if a user logged in via an idp? We don't see > anything on the access token or id token to indicate. > > > _______________________________________________ > 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 Mon Jul 20 00:37:18 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 20 Jul 2015 00:37:18 -0400 (EDT) Subject: [keycloak-dev] deprecated removals in future In-Reply-To: <55A94128.9070900@redhat.com> References: <55A84C7C.1050207@redhat.com> <55A89FB2.3050704@redhat.com> <662658053.40863005.1437114513697.JavaMail.zimbra@redhat.com> <55A8F61B.5020907@redhat.com> <1920602867.40997219.1437139263821.JavaMail.zimbra@redhat.com> <55A906FA.20909@redhat.com> <55A94128.9070900@redhat.com> Message-ID: <493890314.308320.1437367038268.JavaMail.zimbra@redhat.com> -1000 A user should be allowed to upgrade from any version, not only because of convenience, but also because there may be no other option. For example we've had users that have been unable to upgrade to certain versions in the past due to bugs in the migration stuff. What if someone is stuck on an old version 1.2, while version 1.5 is required to upgrade to version 2.0 and the user can't upgrade to 1.3, 1.4 or 1.5? We'd have to do a 1.2.1 release for the user just to allow them to upgrade. ----- Original Message ----- > From: "Marek Posolda" > To: "Bill Burke" , "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Friday, 17 July, 2015 7:53:44 PM > Subject: Re: [keycloak-dev] deprecated removals in future > > The approach like MigrationModelManager or our current JSON migration is > cool and easy, but it stops working if you want to get rid of outdated > properties. For example if you want to remove RealmModel.getFoo() but > MigrateTo13.java is using getFoo property, you will see the errors with > new versions where property "foo" on RealmModel is not available anymore... > > So what if we use something like "milestones" releases and support > migration just between those? For example milestone release can be 1.5 , > 1.10 and 1.15 (or 2.0 or whatever). Then if someone wants to migrate > from 1.0 to 1.12 he needs to go by migration path like: > - First migrate from 1.0 to 1.5 > - Then migrate from 1.5 to 1.10 > - Finally migrate from 1.10 to 1.12 > > For the 1.0 to 1.5 we can use the "easy" approach with keeping of all > the outdated properties on models and JSON representations. Then in 1.6 > we will start from scratch and remove previous migrations and old > properties until 1.5. So migration to 1.6 is supported just from 1.5 etc. > > For the 1.6 we will start from scratch with everything including > liquibase DDL scripts - to avoid situation when there are more and more > liquibase commands executed at initial boot. > > Marek > > On 17.7.2015 15:45, Bill Burke wrote: > > You would still need to write a shit ton of raw SQL and JSON scripts > > to convert from old models (1.0, 1.1, 1.2, 1.3, 1.4, etc...) to the > > new Json realm model you want to instill. > > > > I really worry that we'll be writing a crappy version of Mongo on top > > of a relational store. > > > > On 7/17/2015 9:21 AM, Stian Thorgersen wrote: > >> Yeah, so let's drop the SQL stuff. We'll only have one single realm > >> provider which is backed by json representations. Then we store json > >> representations in Mongo or as blobs in the database. > >> > >> After that we only have to deal with one migration. > >> > >> ----- Original Message ----- > >>> From: "Bill Burke" > >>> To: "Stian Thorgersen" , "Marek Posolda" > >>> > >>> Cc: keycloak-dev at lists.jboss.org > >>> Sent: Friday, 17 July, 2015 2:33:31 PM > >>> Subject: Re: [keycloak-dev] deprecated removals in future > >>> > >>> I'm not spending a week+ writing error prone raw JDBC and generic JSON > >>> scripts. There's a lot of model migration code that would be a shit > >>> ton > >>> of raw SQL if you wanted to convert it. A new starting point would be > >>> half a days work. > >>> > >>> On 7/17/2015 2:28 AM, Stian Thorgersen wrote: > >>>> -1 It'll actually be more work to drop backwards compatibility for the > >>>> model as we'd have to write a new "starting" point. For JSON > >>>> representations it's just messy and has deprecated stuff in it > >>>> because I > >>>> did a crap job at implementing it. If we write a proper way to migrate > >>>> json representations we won't need this and it'll just be a > >>>> transformation > >>>> pipeline that transforms the json to match the representation classes. > >>>> > >>>> ----- Original Message ----- > >>>>> From: "Marek Posolda" > >>>>> To: "Bill Burke" , keycloak-dev at lists.jboss.org > >>>>> Sent: Friday, 17 July, 2015 8:24:50 AM > >>>>> Subject: Re: [keycloak-dev] deprecated removals in future > >>>>> > >>>>> +1 > >>>>> > >>>>> Hopefully we can drop backwards compatibility for JSON reps > >>>>> between 1.X > >>>>> and 2.0 (ie. realm JSON representation exported in 1.X is not > >>>>> supposed > >>>>> to work to be imported in 2.0). That will allow us to drop old > >>>>> metadata > >>>>> from JSON and models and just create DB migration scripts for 1.X > >>>>> to 2.0 > >>>>> migration. > >>>>> > >>>>> Marek > >>>>> > >>>>> On 17.7.2015 02:29, Bill Burke wrote: > >>>>>> We're accumulating deprecated metadata in models and data model. > >>>>>> Eventually we should draw a line in the sand and say we will only > >>>>>> support migration from a certain version to current. > >>>>>> > >>>>>> i.e. Keycloak 2.0 would only allow migration from the last 1.x > >>>>>> version. > >>>>>> > >>>>>> We need to clean all the old stuff out prior to product. > >>>>> > >>>>> _______________________________________________ > >>>>> 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 Mon Jul 20 00:39:16 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 20 Jul 2015 00:39:16 -0400 (EDT) Subject: [keycloak-dev] deprecated removals in future In-Reply-To: <55A906FA.20909@redhat.com> References: <55A84C7C.1050207@redhat.com> <55A89FB2.3050704@redhat.com> <662658053.40863005.1437114513697.JavaMail.zimbra@redhat.com> <55A8F61B.5020907@redhat.com> <1920602867.40997219.1437139263821.JavaMail.zimbra@redhat.com> <55A906FA.20909@redhat.com> Message-ID: <97212026.308430.1437367156675.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: "Stian Thorgersen" > Cc: "Marek Posolda" , keycloak-dev at lists.jboss.org > Sent: Friday, 17 July, 2015 3:45:30 PM > Subject: Re: [keycloak-dev] deprecated removals in future > > You would still need to write a shit ton of raw SQL and JSON scripts to > convert from old models (1.0, 1.1, 1.2, 1.3, 1.4, etc...) to the new > Json realm model you want to instill. What shit ton of raw SQL do you need to write? It's just export to JSON and re-import. > > I really worry that we'll be writing a crappy version of Mongo on top of > a relational store. Nope, because Mongo is a document store. We'd be writing a primitive key-value store. > > On 7/17/2015 9:21 AM, Stian Thorgersen wrote: > > Yeah, so let's drop the SQL stuff. We'll only have one single realm > > provider which is backed by json representations. Then we store json > > representations in Mongo or as blobs in the database. > > > > After that we only have to deal with one migration. > > > > ----- Original Message ----- > >> From: "Bill Burke" > >> To: "Stian Thorgersen" , "Marek Posolda" > >> > >> Cc: keycloak-dev at lists.jboss.org > >> Sent: Friday, 17 July, 2015 2:33:31 PM > >> Subject: Re: [keycloak-dev] deprecated removals in future > >> > >> I'm not spending a week+ writing error prone raw JDBC and generic JSON > >> scripts. There's a lot of model migration code that would be a shit ton > >> of raw SQL if you wanted to convert it. A new starting point would be > >> half a days work. > >> > >> On 7/17/2015 2:28 AM, Stian Thorgersen wrote: > >>> -1 It'll actually be more work to drop backwards compatibility for the > >>> model as we'd have to write a new "starting" point. For JSON > >>> representations it's just messy and has deprecated stuff in it because I > >>> did a crap job at implementing it. If we write a proper way to migrate > >>> json representations we won't need this and it'll just be a > >>> transformation > >>> pipeline that transforms the json to match the representation classes. > >>> > >>> ----- Original Message ----- > >>>> From: "Marek Posolda" > >>>> To: "Bill Burke" , keycloak-dev at lists.jboss.org > >>>> Sent: Friday, 17 July, 2015 8:24:50 AM > >>>> Subject: Re: [keycloak-dev] deprecated removals in future > >>>> > >>>> +1 > >>>> > >>>> Hopefully we can drop backwards compatibility for JSON reps between 1.X > >>>> and 2.0 (ie. realm JSON representation exported in 1.X is not supposed > >>>> to work to be imported in 2.0). That will allow us to drop old metadata > >>>> from JSON and models and just create DB migration scripts for 1.X to 2.0 > >>>> migration. > >>>> > >>>> Marek > >>>> > >>>> On 17.7.2015 02:29, Bill Burke wrote: > >>>>> We're accumulating deprecated metadata in models and data model. > >>>>> Eventually we should draw a line in the sand and say we will only > >>>>> support migration from a certain version to current. > >>>>> > >>>>> i.e. Keycloak 2.0 would only allow migration from the last 1.x version. > >>>>> > >>>>> We need to clean all the old stuff out prior to product. > >>>> > >>>> _______________________________________________ > >>>> 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 > >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > From stian at redhat.com Mon Jul 20 00:42:49 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 20 Jul 2015 00:42:49 -0400 (EDT) Subject: [keycloak-dev] Email/ username case-sensitivity issues In-Reply-To: <55A93D76.7050909@redhat.com> References: <55A93D76.7050909@redhat.com> Message-ID: <1192901092.308667.1437367369880.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Marek Posolda" > To: keycloak-dev at lists.jboss.org > Sent: Friday, 17 July, 2015 7:37:58 PM > Subject: [keycloak-dev] Email/ username case-sensitivity issues > > There are some case-sensitivity issues, which cause that sometimes you > can add object with duplicated email/username into DB etc. Some details > are at https://issues.jboss.org/browse/KEYCLOAK-1545 or > https://issues.jboss.org/browse/KEYCLOAK-1551 . Those issues happened > with LDAP, but generally issues are not LDAP specific - for example even > without LDAP integration you can add user with email "JOHN at keycloak.org" > and then "john at keycloak.org" . Second user is created successfully, > which doesn't look correct to me. > > The solutions I can see is: > 1) Ensure that username and email is always added lowercased into DB and > then searched lowercased. We already fixed similar issues earlier, but > not entirely . Right now, we are adding username lowercased and > searching both username and email lowercased, but we are not adding > email lowercased. I've sent PR when I am convert both username and email > to lowercase in UserAdapter.setEmail and UserAdapter.setUserName - > https://github.com/mposolda/keycloak/commit/66f16bf654fc22570ce9ef7b34c47039266fe61d > > > 2) Another approach can be to add usernames and emails case sensitively, > but instead ensure that DB searching is case insensitive (lowercased). > For JPA there is "lower" function in HQL, but I am not sure if it's > supported for various databases (and I would really like to avoid DB > specific failures TBH...;-) ). For Mongo there is possibility to > search with regex to achieve case-insensitive search but it sucks due to > performance- so in this case we may need to add separate columns > username_lowercased and email_lowercased, which will be used for > searching to ensure index is used... > > I like (1) much more and that's what I used in PR. Any objections > against merging it? +1 To (1) that's what we intended to do the first time around, but seem to have forgotten email by mistake. We had the same discussion then about local part being case sensitive back then as well ;) > > Or is it bad to assume that email are case insensitive? Strictly said, > the "local" part of email is supposed to be case sensitive, so > "JOHN at keycloak.org" and "john at keycloak.org" are theoretically different > emails. But in reality most organizations and mail servers treat them as > same emails - including Google. Just checked that I can successfully > login to Google with MPosOLDA at gmail.com . > > Marek > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From stian at redhat.com Mon Jul 20 02:10:12 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 20 Jul 2015 02:10:12 -0400 (EDT) Subject: [keycloak-dev] Email/ username case-sensitivity issues In-Reply-To: <1192901092.308667.1437367369880.JavaMail.zimbra@redhat.com> References: <55A93D76.7050909@redhat.com> <1192901092.308667.1437367369880.JavaMail.zimbra@redhat.com> Message-ID: <1813781116.369421.1437372612621.JavaMail.zimbra@redhat.com> Marek: assigned https://issues.jboss.org/browse/KEYCLOAK-1544 to you as it's related to fix you've done ----- Original Message ----- > From: "Stian Thorgersen" > To: "Marek Posolda" > Cc: keycloak-dev at lists.jboss.org > Sent: Monday, 20 July, 2015 6:42:49 AM > Subject: Re: [keycloak-dev] Email/ username case-sensitivity issues > > > > ----- Original Message ----- > > From: "Marek Posolda" > > To: keycloak-dev at lists.jboss.org > > Sent: Friday, 17 July, 2015 7:37:58 PM > > Subject: [keycloak-dev] Email/ username case-sensitivity issues > > > > There are some case-sensitivity issues, which cause that sometimes you > > can add object with duplicated email/username into DB etc. Some details > > are at https://issues.jboss.org/browse/KEYCLOAK-1545 or > > https://issues.jboss.org/browse/KEYCLOAK-1551 . Those issues happened > > with LDAP, but generally issues are not LDAP specific - for example even > > without LDAP integration you can add user with email "JOHN at keycloak.org" > > and then "john at keycloak.org" . Second user is created successfully, > > which doesn't look correct to me. > > > > The solutions I can see is: > > 1) Ensure that username and email is always added lowercased into DB and > > then searched lowercased. We already fixed similar issues earlier, but > > not entirely . Right now, we are adding username lowercased and > > searching both username and email lowercased, but we are not adding > > email lowercased. I've sent PR when I am convert both username and email > > to lowercase in UserAdapter.setEmail and UserAdapter.setUserName - > > https://github.com/mposolda/keycloak/commit/66f16bf654fc22570ce9ef7b34c47039266fe61d > > > > > > 2) Another approach can be to add usernames and emails case sensitively, > > but instead ensure that DB searching is case insensitive (lowercased). > > For JPA there is "lower" function in HQL, but I am not sure if it's > > supported for various databases (and I would really like to avoid DB > > specific failures TBH...;-) ). For Mongo there is possibility to > > search with regex to achieve case-insensitive search but it sucks due to > > performance- so in this case we may need to add separate columns > > username_lowercased and email_lowercased, which will be used for > > searching to ensure index is used... > > > > I like (1) much more and that's what I used in PR. Any objections > > against merging it? > > +1 To (1) that's what we intended to do the first time around, but seem to > have forgotten email by mistake. We had the same discussion then about local > part being case sensitive back then as well ;) > > > > > Or is it bad to assume that email are case insensitive? Strictly said, > > the "local" part of email is supposed to be case sensitive, so > > "JOHN at keycloak.org" and "john at keycloak.org" are theoretically different > > emails. But in reality most organizations and mail servers treat them as > > same emails - including Google. Just checked that I can successfully > > login to Google with MPosOLDA at gmail.com . > > > > 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 ssilvert at redhat.com Mon Jul 20 07:50:25 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Mon, 20 Jul 2015 07:50:25 -0400 Subject: [keycloak-dev] How should reset-password-email work? Message-ID: <55ACE081.9050102@redhat.com> http://keycloak.github.io/docs/rest-api/admin/realms/%7Brealm%7D/users/%7Bid%7D/reset-password-email/index.html I'm looking into KEYCLOAK-1543 [1], which concerns the REST API for reset-password-email [2]. I want to make sure I understand how this is meant to work. You make a call to send the user a reset-password email. And you specify a client id and a redirect uri. I assume the redirect uri is the place the user is sent after he changes his password? (via a link he clicks to continue) Right now, it looks like the code is checking the client config to make sure that the redirect uri is included in the client's "valid redirect uri's". So if redirect uri is specified then client id is also required? The problem is that currently, the redirect uri is ignored and the user is always sent to the base uri of the client. Please let me know if any of the above is incorrect. I want to make sure I have this right as I fix it and update the documentation. [1] https://issues.jboss.org/browse/KEYCLOAK-1543 [2] http://keycloak.github.io/docs/rest-api/admin/realms/%7Brealm%7D/users/%7Bid%7D/reset-password-email/index.html From stian at redhat.com Mon Jul 20 09:25:40 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 20 Jul 2015 09:25:40 -0400 (EDT) Subject: [keycloak-dev] How should reset-password-email work? In-Reply-To: <55ACE081.9050102@redhat.com> References: <55ACE081.9050102@redhat.com> Message-ID: <1061449494.622807.1437398740048.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Stan Silvert" > To: keycloak-dev at lists.jboss.org > Sent: Monday, 20 July, 2015 1:50:25 PM > Subject: [keycloak-dev] How should reset-password-email work? > > http://keycloak.github.io/docs/rest-api/admin/realms/%7Brealm%7D/users/%7Bid%7D/reset-password-email/index.html > > I'm looking into KEYCLOAK-1543 [1], which concerns the REST API for > reset-password-email [2]. I want to make sure I understand how this is > meant to work. > > You make a call to send the user a reset-password email. And you > specify a client id and a redirect uri. I assume the redirect uri is > the place the user is sent after he changes his password? (via a link > he clicks to continue) > > Right now, it looks like the code is checking the client config to make > sure that the redirect uri is included in the client's "valid redirect > uri's". So if redirect uri is specified then client id is also required? > > The problem is that currently, the redirect uri is ignored and the user > is always sent to the base uri of the client. Actually I don't think it should be possible to specify a redirect uri for this endpoint. The endpoint is intended for an admin to send a login link to a user and so it can't be part of a login flow. As it's not for a login flow it doesn't make sense to use a redirect uri. Instead it should just be able to specify client and have the user sent to the base uri of the client. > > Please let me know if any of the above is incorrect. I want to make > sure I have this right as I fix it and update the documentation. > > [1] https://issues.jboss.org/browse/KEYCLOAK-1543 > [2] > http://keycloak.github.io/docs/rest-api/admin/realms/%7Brealm%7D/users/%7Bid%7D/reset-password-email/index.html > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From srossillo at smartling.com Mon Jul 20 10:42:34 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Mon, 20 Jul 2015 10:42:34 -0400 Subject: [keycloak-dev] Tell if user is logged in via idp In-Reply-To: <55AA4F91.3080708@redhat.com> References: <55AA4F91.3080708@redhat.com> Message-ID: https://issues.jboss.org/browse/KEYCLOAK-1585 > On Jul 18, 2015, at 9:07 AM, Bill Burke wrote: > > nada. jira? > > On 7/17/2015 11:13 PM, Scott Rossillo wrote: >> Is there a way to tell if a user logged in via an idp? We don't see >> anything on the access token or id token to indicate. >> >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Mon Jul 20 11:21:56 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 20 Jul 2015 11:21:56 -0400 Subject: [keycloak-dev] deprecated removals in future In-Reply-To: <493890314.308320.1437367038268.JavaMail.zimbra@redhat.com> References: <55A84C7C.1050207@redhat.com> <55A89FB2.3050704@redhat.com> <662658053.40863005.1437114513697.JavaMail.zimbra@redhat.com> <55A8F61B.5020907@redhat.com> <1920602867.40997219.1437139263821.JavaMail.zimbra@redhat.com> <55A906FA.20909@redhat.com> <55A94128.9070900@redhat.com> <493890314.308320.1437367038268.JavaMail.zimbra@redhat.com> Message-ID: <55AD1214.3020306@redhat.com> They would upgrade to 1.5 first, then upgrade to 2.x. On 7/20/2015 12:37 AM, Stian Thorgersen wrote: > -1000 A user should be allowed to upgrade from any version, not only because of convenience, but also because there may be no other option. For example we've had users that have been unable to upgrade to certain versions in the past due to bugs in the migration stuff. What if someone is stuck on an old version 1.2, while version 1.5 is required to upgrade to version 2.0 and the user can't upgrade to 1.3, 1.4 or 1.5? We'd have to do a 1.2.1 release for the user just to allow them to upgrade. > > ----- Original Message ----- >> From: "Marek Posolda" >> To: "Bill Burke" , "Stian Thorgersen" >> Cc: keycloak-dev at lists.jboss.org >> Sent: Friday, 17 July, 2015 7:53:44 PM >> Subject: Re: [keycloak-dev] deprecated removals in future >> >> The approach like MigrationModelManager or our current JSON migration is >> cool and easy, but it stops working if you want to get rid of outdated >> properties. For example if you want to remove RealmModel.getFoo() but >> MigrateTo13.java is using getFoo property, you will see the errors with >> new versions where property "foo" on RealmModel is not available anymore... >> >> So what if we use something like "milestones" releases and support >> migration just between those? For example milestone release can be 1.5 , >> 1.10 and 1.15 (or 2.0 or whatever). Then if someone wants to migrate >> from 1.0 to 1.12 he needs to go by migration path like: >> - First migrate from 1.0 to 1.5 >> - Then migrate from 1.5 to 1.10 >> - Finally migrate from 1.10 to 1.12 >> >> For the 1.0 to 1.5 we can use the "easy" approach with keeping of all >> the outdated properties on models and JSON representations. Then in 1.6 >> we will start from scratch and remove previous migrations and old >> properties until 1.5. So migration to 1.6 is supported just from 1.5 etc. >> >> For the 1.6 we will start from scratch with everything including >> liquibase DDL scripts - to avoid situation when there are more and more >> liquibase commands executed at initial boot. >> >> Marek >> >> On 17.7.2015 15:45, Bill Burke wrote: >>> You would still need to write a shit ton of raw SQL and JSON scripts >>> to convert from old models (1.0, 1.1, 1.2, 1.3, 1.4, etc...) to the >>> new Json realm model you want to instill. >>> >>> I really worry that we'll be writing a crappy version of Mongo on top >>> of a relational store. >>> >>> On 7/17/2015 9:21 AM, Stian Thorgersen wrote: >>>> Yeah, so let's drop the SQL stuff. We'll only have one single realm >>>> provider which is backed by json representations. Then we store json >>>> representations in Mongo or as blobs in the database. >>>> >>>> After that we only have to deal with one migration. >>>> >>>> ----- Original Message ----- >>>>> From: "Bill Burke" >>>>> To: "Stian Thorgersen" , "Marek Posolda" >>>>> >>>>> Cc: keycloak-dev at lists.jboss.org >>>>> Sent: Friday, 17 July, 2015 2:33:31 PM >>>>> Subject: Re: [keycloak-dev] deprecated removals in future >>>>> >>>>> I'm not spending a week+ writing error prone raw JDBC and generic JSON >>>>> scripts. There's a lot of model migration code that would be a shit >>>>> ton >>>>> of raw SQL if you wanted to convert it. A new starting point would be >>>>> half a days work. >>>>> >>>>> On 7/17/2015 2:28 AM, Stian Thorgersen wrote: >>>>>> -1 It'll actually be more work to drop backwards compatibility for the >>>>>> model as we'd have to write a new "starting" point. For JSON >>>>>> representations it's just messy and has deprecated stuff in it >>>>>> because I >>>>>> did a crap job at implementing it. If we write a proper way to migrate >>>>>> json representations we won't need this and it'll just be a >>>>>> transformation >>>>>> pipeline that transforms the json to match the representation classes. >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Marek Posolda" >>>>>>> To: "Bill Burke" , keycloak-dev at lists.jboss.org >>>>>>> Sent: Friday, 17 July, 2015 8:24:50 AM >>>>>>> Subject: Re: [keycloak-dev] deprecated removals in future >>>>>>> >>>>>>> +1 >>>>>>> >>>>>>> Hopefully we can drop backwards compatibility for JSON reps >>>>>>> between 1.X >>>>>>> and 2.0 (ie. realm JSON representation exported in 1.X is not >>>>>>> supposed >>>>>>> to work to be imported in 2.0). That will allow us to drop old >>>>>>> metadata >>>>>>> from JSON and models and just create DB migration scripts for 1.X >>>>>>> to 2.0 >>>>>>> migration. >>>>>>> >>>>>>> Marek >>>>>>> >>>>>>> On 17.7.2015 02:29, Bill Burke wrote: >>>>>>>> We're accumulating deprecated metadata in models and data model. >>>>>>>> Eventually we should draw a line in the sand and say we will only >>>>>>>> support migration from a certain version to current. >>>>>>>> >>>>>>>> i.e. Keycloak 2.0 would only allow migration from the last 1.x >>>>>>>> version. >>>>>>>> >>>>>>>> We need to clean all the old stuff out prior to product. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>> >> >> -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Mon Jul 20 11:27:19 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 20 Jul 2015 11:27:19 -0400 Subject: [keycloak-dev] deprecated removals in future In-Reply-To: <97212026.308430.1437367156675.JavaMail.zimbra@redhat.com> References: <55A84C7C.1050207@redhat.com> <55A89FB2.3050704@redhat.com> <662658053.40863005.1437114513697.JavaMail.zimbra@redhat.com> <55A8F61B.5020907@redhat.com> <1920602867.40997219.1437139263821.JavaMail.zimbra@redhat.com> <55A906FA.20909@redhat.com> <97212026.308430.1437367156675.JavaMail.zimbra@redhat.com> Message-ID: <55AD1357.3@redhat.com> On 7/20/2015 12:39 AM, Stian Thorgersen wrote: > > > ----- Original Message ----- >> From: "Bill Burke" >> To: "Stian Thorgersen" >> Cc: "Marek Posolda" , keycloak-dev at lists.jboss.org >> Sent: Friday, 17 July, 2015 3:45:30 PM >> Subject: Re: [keycloak-dev] deprecated removals in future >> >> You would still need to write a shit ton of raw SQL and JSON scripts to >> convert from old models (1.0, 1.1, 1.2, 1.3, 1.4, etc...) to the new >> Json realm model you want to instill. > > What shit ton of raw SQL do you need to write? It's just export to JSON and re-import. > You would have to make raw SQL queries to support 1.0-1.x so that you could import that relational data into the new json model. Or, you'd have to write a ton of raw json parsers that worked with the old export model. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Mon Jul 20 11:30:26 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 20 Jul 2015 11:30:26 -0400 Subject: [keycloak-dev] Tell if user is logged in via idp In-Reply-To: References: <55AA4F91.3080708@redhat.com> Message-ID: <55AD1412.606@redhat.com> YOu could also write 2 mappers to do this. One at the idp broker to put in a flag in the user session, another protocol mapper to take this data and map it into the token. On 7/20/2015 10:42 AM, Scott Rossillo wrote: > > https://issues.jboss.org/browse/KEYCLOAK-1585 > >> On Jul 18, 2015, at 9:07 AM, Bill Burke wrote: >> >> nada. jira? >> >> On 7/17/2015 11:13 PM, Scott Rossillo wrote: >>> Is there a way to tell if a user logged in via an idp? We don't see >>> anything on the access token or id token to indicate. >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Mon Jul 20 12:08:01 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 20 Jul 2015 12:08:01 -0400 (EDT) Subject: [keycloak-dev] deprecated removals in future In-Reply-To: <55AD1214.3020306@redhat.com> References: <55A84C7C.1050207@redhat.com> <662658053.40863005.1437114513697.JavaMail.zimbra@redhat.com> <55A8F61B.5020907@redhat.com> <1920602867.40997219.1437139263821.JavaMail.zimbra@redhat.com> <55A906FA.20909@redhat.com> <55A94128.9070900@redhat.com> <493890314.308320.1437367038268.JavaMail.zimbra@redhat.com> <55AD1214.3020306@redhat.com> Message-ID: <488779788.827421.1437408481563.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: "Stian Thorgersen" , "Marek Posolda" > Cc: keycloak-dev at lists.jboss.org > Sent: Monday, 20 July, 2015 5:21:56 PM > Subject: Re: [keycloak-dev] deprecated removals in future > > They would upgrade to 1.5 first, then upgrade to 2.x. In the example I gave they are not able to upgrade to 1.5 as there was a bug in the migration that made it not work the db they use. So we'd have to release a 1.5.1 for them. I seriously don't think we should be putting these kinda off restrictions in place. It's going to come back and bite us. > > On 7/20/2015 12:37 AM, Stian Thorgersen wrote: > > -1000 A user should be allowed to upgrade from any version, not only > > because of convenience, but also because there may be no other option. For > > example we've had users that have been unable to upgrade to certain > > versions in the past due to bugs in the migration stuff. What if someone > > is stuck on an old version 1.2, while version 1.5 is required to upgrade > > to version 2.0 and the user can't upgrade to 1.3, 1.4 or 1.5? We'd have to > > do a 1.2.1 release for the user just to allow them to upgrade. > > > > ----- Original Message ----- > >> From: "Marek Posolda" > >> To: "Bill Burke" , "Stian Thorgersen" > >> > >> Cc: keycloak-dev at lists.jboss.org > >> Sent: Friday, 17 July, 2015 7:53:44 PM > >> Subject: Re: [keycloak-dev] deprecated removals in future > >> > >> The approach like MigrationModelManager or our current JSON migration is > >> cool and easy, but it stops working if you want to get rid of outdated > >> properties. For example if you want to remove RealmModel.getFoo() but > >> MigrateTo13.java is using getFoo property, you will see the errors with > >> new versions where property "foo" on RealmModel is not available > >> anymore... > >> > >> So what if we use something like "milestones" releases and support > >> migration just between those? For example milestone release can be 1.5 , > >> 1.10 and 1.15 (or 2.0 or whatever). Then if someone wants to migrate > >> from 1.0 to 1.12 he needs to go by migration path like: > >> - First migrate from 1.0 to 1.5 > >> - Then migrate from 1.5 to 1.10 > >> - Finally migrate from 1.10 to 1.12 > >> > >> For the 1.0 to 1.5 we can use the "easy" approach with keeping of all > >> the outdated properties on models and JSON representations. Then in 1.6 > >> we will start from scratch and remove previous migrations and old > >> properties until 1.5. So migration to 1.6 is supported just from 1.5 etc. > >> > >> For the 1.6 we will start from scratch with everything including > >> liquibase DDL scripts - to avoid situation when there are more and more > >> liquibase commands executed at initial boot. > >> > >> Marek > >> > >> On 17.7.2015 15:45, Bill Burke wrote: > >>> You would still need to write a shit ton of raw SQL and JSON scripts > >>> to convert from old models (1.0, 1.1, 1.2, 1.3, 1.4, etc...) to the > >>> new Json realm model you want to instill. > >>> > >>> I really worry that we'll be writing a crappy version of Mongo on top > >>> of a relational store. > >>> > >>> On 7/17/2015 9:21 AM, Stian Thorgersen wrote: > >>>> Yeah, so let's drop the SQL stuff. We'll only have one single realm > >>>> provider which is backed by json representations. Then we store json > >>>> representations in Mongo or as blobs in the database. > >>>> > >>>> After that we only have to deal with one migration. > >>>> > >>>> ----- Original Message ----- > >>>>> From: "Bill Burke" > >>>>> To: "Stian Thorgersen" , "Marek Posolda" > >>>>> > >>>>> Cc: keycloak-dev at lists.jboss.org > >>>>> Sent: Friday, 17 July, 2015 2:33:31 PM > >>>>> Subject: Re: [keycloak-dev] deprecated removals in future > >>>>> > >>>>> I'm not spending a week+ writing error prone raw JDBC and generic JSON > >>>>> scripts. There's a lot of model migration code that would be a shit > >>>>> ton > >>>>> of raw SQL if you wanted to convert it. A new starting point would be > >>>>> half a days work. > >>>>> > >>>>> On 7/17/2015 2:28 AM, Stian Thorgersen wrote: > >>>>>> -1 It'll actually be more work to drop backwards compatibility for the > >>>>>> model as we'd have to write a new "starting" point. For JSON > >>>>>> representations it's just messy and has deprecated stuff in it > >>>>>> because I > >>>>>> did a crap job at implementing it. If we write a proper way to migrate > >>>>>> json representations we won't need this and it'll just be a > >>>>>> transformation > >>>>>> pipeline that transforms the json to match the representation classes. > >>>>>> > >>>>>> ----- Original Message ----- > >>>>>>> From: "Marek Posolda" > >>>>>>> To: "Bill Burke" , keycloak-dev at lists.jboss.org > >>>>>>> Sent: Friday, 17 July, 2015 8:24:50 AM > >>>>>>> Subject: Re: [keycloak-dev] deprecated removals in future > >>>>>>> > >>>>>>> +1 > >>>>>>> > >>>>>>> Hopefully we can drop backwards compatibility for JSON reps > >>>>>>> between 1.X > >>>>>>> and 2.0 (ie. realm JSON representation exported in 1.X is not > >>>>>>> supposed > >>>>>>> to work to be imported in 2.0). That will allow us to drop old > >>>>>>> metadata > >>>>>>> from JSON and models and just create DB migration scripts for 1.X > >>>>>>> to 2.0 > >>>>>>> migration. > >>>>>>> > >>>>>>> Marek > >>>>>>> > >>>>>>> On 17.7.2015 02:29, Bill Burke wrote: > >>>>>>>> We're accumulating deprecated metadata in models and data model. > >>>>>>>> Eventually we should draw a line in the sand and say we will only > >>>>>>>> support migration from a certain version to current. > >>>>>>>> > >>>>>>>> i.e. Keycloak 2.0 would only allow migration from the last 1.x > >>>>>>>> version. > >>>>>>>> > >>>>>>>> We need to clean all the old stuff out prior to product. > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> 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 > >>>>> > >>> > >> > >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > From stian at redhat.com Tue Jul 21 02:50:50 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 21 Jul 2015 02:50:50 -0400 (EDT) Subject: [keycloak-dev] Storage and migration issues In-Reply-To: <1747569569.1324534.1437460593210.JavaMail.zimbra@redhat.com> Message-ID: <1510622001.1327626.1437461450323.JavaMail.zimbra@redhat.com> Maintaining the storage providers are a incredible time sync and very error prone. On top of that we also have migration to deal with. It would be worth to improve this before we go to product. Why is storage so horrible?: * Multiple implementations - JPA + Mongo + Representations + Cache * Multiple database providers - every time we add anything it seems to break on at least one database * Migration - we have 4 different types of migration to deal with. Representations, JPA, Mongo and the generic one as well Not only do we spend a lot of time even adding the simplest thing to the model, but we also spend a lot of time getting it to work on all supported databases before release. This all made me think that we have to many options! I don't think users care how we store realm and client meta-data. They may care about users though. With that regards I think we should have a single realm store that is managed by Keycloak instead of supporting an external store. For users we'd still have the option to use JPA or Mongo, but that's a significantly simpler model, in fact I don't think we've barely touched it for a long time. We could also use the same managed store for users OOTB. For the realm store I'd like to use either a document store or a key-value store. Relational databases are just to much of a pain to get to work, migration is painful and it makes users expect that the database of their choice will work as well. Alternatives could be: * Cassandra * MongoDB * Plain files - we'd have a revision number of a realm or client and we'd replicate the details with Infinispan and store on all nodes * Infinispan store - Infinispan has built-in support for persisting data * DMR - in domain mode WildFly manages atomic updates to all nodes. Not sure if standalone.xml etc can deal with the amount of data we have though. * Continue storing in any store, but store a JSON blob for realms and clients. In relational database we'd have two tables, realms and clients, with an id, revision and blob With regards to migration I think we DO need to support updating from any version. In community this is an incredibly nice to have, but could also be more than that if a user is stuck on an old version and can't update to the intermediate version due to a bug. However, in product it's going to be required. Think about it a major release is supported for 8 years or something. We could end up with having 4 or more major versions out there at any given time. We can't expect a customer that's been on product v1 to upgrade to v2, then v3 to be able to upgrade to v4. From mposolda at redhat.com Tue Jul 21 02:57:07 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 21 Jul 2015 08:57:07 +0200 Subject: [keycloak-dev] deprecated removals in future In-Reply-To: <488779788.827421.1437408481563.JavaMail.zimbra@redhat.com> References: <55A84C7C.1050207@redhat.com> <662658053.40863005.1437114513697.JavaMail.zimbra@redhat.com> <55A8F61B.5020907@redhat.com> <1920602867.40997219.1437139263821.JavaMail.zimbra@redhat.com> <55A906FA.20909@redhat.com> <55A94128.9070900@redhat.com> <493890314.308320.1437367038268.JavaMail.zimbra@redhat.com> <55AD1214.3020306@redhat.com> <488779788.827421.1437408481563.JavaMail.zimbra@redhat.com> Message-ID: <55ADED43.6030108@redhat.com> On 20.7.2015 18:08, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Bill Burke" >> To: "Stian Thorgersen" , "Marek Posolda" >> Cc: keycloak-dev at lists.jboss.org >> Sent: Monday, 20 July, 2015 5:21:56 PM >> Subject: Re: [keycloak-dev] deprecated removals in future >> >> They would upgrade to 1.5 first, then upgrade to 2.x. > In the example I gave they are not able to upgrade to 1.5 as there was a bug in the migration that made it not work the db they use. So we'd have to release a 1.5.1 for them. > > I seriously don't think we should be putting these kinda off restrictions in place. It's going to come back and bite us. Not sure which way is better... It looks easier to me to fix potential migration bug and release 1.5.1 then supporting migration from 1.0 to any version. Also note that there are some RDBMS, which don't work right now but we need to support them . Right now some of them ( at least IBM DB2 and Postgres PLUS ) are broken even in the first jpa-changelog-1.0.0.Final . So supporting them might require to do changes in the old liquibase scripts (like jpa-changelog-1.0.0.Final ) but that's not good as it could break migration for other databases. Doing "cut off" at some point and start from scratch allows us to easily add support for those RDBMS without breaking migration for other dbs. BTW. Are we only JBoss project having similar issues? Maybe we can inspire from some others? I know JPP had IDM and JCR databases to deal with, where migration wasn't so bad due to the most of the stuff was saved as key/value pairs. Not sure about other projects. There is also project Windup - http://windup.jboss.org/ but that's probably not for DB migration... Marek > >> On 7/20/2015 12:37 AM, Stian Thorgersen wrote: >>> -1000 A user should be allowed to upgrade from any version, not only >>> because of convenience, but also because there may be no other option. For >>> example we've had users that have been unable to upgrade to certain >>> versions in the past due to bugs in the migration stuff. What if someone >>> is stuck on an old version 1.2, while version 1.5 is required to upgrade >>> to version 2.0 and the user can't upgrade to 1.3, 1.4 or 1.5? We'd have to >>> do a 1.2.1 release for the user just to allow them to upgrade. >>> >>> ----- Original Message ----- >>>> From: "Marek Posolda" >>>> To: "Bill Burke" , "Stian Thorgersen" >>>> >>>> Cc: keycloak-dev at lists.jboss.org >>>> Sent: Friday, 17 July, 2015 7:53:44 PM >>>> Subject: Re: [keycloak-dev] deprecated removals in future >>>> >>>> The approach like MigrationModelManager or our current JSON migration is >>>> cool and easy, but it stops working if you want to get rid of outdated >>>> properties. For example if you want to remove RealmModel.getFoo() but >>>> MigrateTo13.java is using getFoo property, you will see the errors with >>>> new versions where property "foo" on RealmModel is not available >>>> anymore... >>>> >>>> So what if we use something like "milestones" releases and support >>>> migration just between those? For example milestone release can be 1.5 , >>>> 1.10 and 1.15 (or 2.0 or whatever). Then if someone wants to migrate >>>> from 1.0 to 1.12 he needs to go by migration path like: >>>> - First migrate from 1.0 to 1.5 >>>> - Then migrate from 1.5 to 1.10 >>>> - Finally migrate from 1.10 to 1.12 >>>> >>>> For the 1.0 to 1.5 we can use the "easy" approach with keeping of all >>>> the outdated properties on models and JSON representations. Then in 1.6 >>>> we will start from scratch and remove previous migrations and old >>>> properties until 1.5. So migration to 1.6 is supported just from 1.5 etc. >>>> >>>> For the 1.6 we will start from scratch with everything including >>>> liquibase DDL scripts - to avoid situation when there are more and more >>>> liquibase commands executed at initial boot. >>>> >>>> Marek >>>> >>>> On 17.7.2015 15:45, Bill Burke wrote: >>>>> You would still need to write a shit ton of raw SQL and JSON scripts >>>>> to convert from old models (1.0, 1.1, 1.2, 1.3, 1.4, etc...) to the >>>>> new Json realm model you want to instill. >>>>> >>>>> I really worry that we'll be writing a crappy version of Mongo on top >>>>> of a relational store. >>>>> >>>>> On 7/17/2015 9:21 AM, Stian Thorgersen wrote: >>>>>> Yeah, so let's drop the SQL stuff. We'll only have one single realm >>>>>> provider which is backed by json representations. Then we store json >>>>>> representations in Mongo or as blobs in the database. >>>>>> >>>>>> After that we only have to deal with one migration. >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Bill Burke" >>>>>>> To: "Stian Thorgersen" , "Marek Posolda" >>>>>>> >>>>>>> Cc: keycloak-dev at lists.jboss.org >>>>>>> Sent: Friday, 17 July, 2015 2:33:31 PM >>>>>>> Subject: Re: [keycloak-dev] deprecated removals in future >>>>>>> >>>>>>> I'm not spending a week+ writing error prone raw JDBC and generic JSON >>>>>>> scripts. There's a lot of model migration code that would be a shit >>>>>>> ton >>>>>>> of raw SQL if you wanted to convert it. A new starting point would be >>>>>>> half a days work. >>>>>>> >>>>>>> On 7/17/2015 2:28 AM, Stian Thorgersen wrote: >>>>>>>> -1 It'll actually be more work to drop backwards compatibility for the >>>>>>>> model as we'd have to write a new "starting" point. For JSON >>>>>>>> representations it's just messy and has deprecated stuff in it >>>>>>>> because I >>>>>>>> did a crap job at implementing it. If we write a proper way to migrate >>>>>>>> json representations we won't need this and it'll just be a >>>>>>>> transformation >>>>>>>> pipeline that transforms the json to match the representation classes. >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>>> From: "Marek Posolda" >>>>>>>>> To: "Bill Burke" , keycloak-dev at lists.jboss.org >>>>>>>>> Sent: Friday, 17 July, 2015 8:24:50 AM >>>>>>>>> Subject: Re: [keycloak-dev] deprecated removals in future >>>>>>>>> >>>>>>>>> +1 >>>>>>>>> >>>>>>>>> Hopefully we can drop backwards compatibility for JSON reps >>>>>>>>> between 1.X >>>>>>>>> and 2.0 (ie. realm JSON representation exported in 1.X is not >>>>>>>>> supposed >>>>>>>>> to work to be imported in 2.0). That will allow us to drop old >>>>>>>>> metadata >>>>>>>>> from JSON and models and just create DB migration scripts for 1.X >>>>>>>>> to 2.0 >>>>>>>>> migration. >>>>>>>>> >>>>>>>>> Marek >>>>>>>>> >>>>>>>>> On 17.7.2015 02:29, Bill Burke wrote: >>>>>>>>>> We're accumulating deprecated metadata in models and data model. >>>>>>>>>> Eventually we should draw a line in the sand and say we will only >>>>>>>>>> support migration from a certain version to current. >>>>>>>>>> >>>>>>>>>> i.e. Keycloak 2.0 would only allow migration from the last 1.x >>>>>>>>>> version. >>>>>>>>>> >>>>>>>>>> We need to clean all the old stuff out prior to product. >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>> >>>> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> From mposolda at redhat.com Tue Jul 21 02:58:53 2015 From: mposolda at redhat.com (Marek Posolda) Date: Tue, 21 Jul 2015 08:58:53 +0200 Subject: [keycloak-dev] Email/ username case-sensitivity issues In-Reply-To: <1813781116.369421.1437372612621.JavaMail.zimbra@redhat.com> References: <55A93D76.7050909@redhat.com> <1192901092.308667.1437367369880.JavaMail.zimbra@redhat.com> <1813781116.369421.1437372612621.JavaMail.zimbra@redhat.com> Message-ID: <55ADEDAD.2010908@redhat.com> Thanks for the confirmation. PR merged, going to resolve all the related jiras assigned to me. Marek On 20.7.2015 08:10, Stian Thorgersen wrote: > Marek: assigned https://issues.jboss.org/browse/KEYCLOAK-1544 to you as it's related to fix you've done > > ----- Original Message ----- >> From: "Stian Thorgersen" >> To: "Marek Posolda" >> Cc: keycloak-dev at lists.jboss.org >> Sent: Monday, 20 July, 2015 6:42:49 AM >> Subject: Re: [keycloak-dev] Email/ username case-sensitivity issues >> >> >> >> ----- Original Message ----- >>> From: "Marek Posolda" >>> To: keycloak-dev at lists.jboss.org >>> Sent: Friday, 17 July, 2015 7:37:58 PM >>> Subject: [keycloak-dev] Email/ username case-sensitivity issues >>> >>> There are some case-sensitivity issues, which cause that sometimes you >>> can add object with duplicated email/username into DB etc. Some details >>> are at https://issues.jboss.org/browse/KEYCLOAK-1545 or >>> https://issues.jboss.org/browse/KEYCLOAK-1551 . Those issues happened >>> with LDAP, but generally issues are not LDAP specific - for example even >>> without LDAP integration you can add user with email "JOHN at keycloak.org" >>> and then "john at keycloak.org" . Second user is created successfully, >>> which doesn't look correct to me. >>> >>> The solutions I can see is: >>> 1) Ensure that username and email is always added lowercased into DB and >>> then searched lowercased. We already fixed similar issues earlier, but >>> not entirely . Right now, we are adding username lowercased and >>> searching both username and email lowercased, but we are not adding >>> email lowercased. I've sent PR when I am convert both username and email >>> to lowercase in UserAdapter.setEmail and UserAdapter.setUserName - >>> https://github.com/mposolda/keycloak/commit/66f16bf654fc22570ce9ef7b34c47039266fe61d >>> >>> >>> 2) Another approach can be to add usernames and emails case sensitively, >>> but instead ensure that DB searching is case insensitive (lowercased). >>> For JPA there is "lower" function in HQL, but I am not sure if it's >>> supported for various databases (and I would really like to avoid DB >>> specific failures TBH...;-) ). For Mongo there is possibility to >>> search with regex to achieve case-insensitive search but it sucks due to >>> performance- so in this case we may need to add separate columns >>> username_lowercased and email_lowercased, which will be used for >>> searching to ensure index is used... >>> >>> I like (1) much more and that's what I used in PR. Any objections >>> against merging it? >> +1 To (1) that's what we intended to do the first time around, but seem to >> have forgotten email by mistake. We had the same discussion then about local >> part being case sensitive back then as well ;) >> >>> Or is it bad to assume that email are case insensitive? Strictly said, >>> the "local" part of email is supposed to be case sensitive, so >>> "JOHN at keycloak.org" and "john at keycloak.org" are theoretically different >>> emails. But in reality most organizations and mail servers treat them as >>> same emails - including Google. Just checked that I can successfully >>> login to Google with MPosOLDA at gmail.com . >>> >>> 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 stian at redhat.com Tue Jul 21 04:54:50 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 21 Jul 2015 04:54:50 -0400 (EDT) Subject: [keycloak-dev] Release status In-Reply-To: <823866641.1382909.1437467774018.JavaMail.zimbra@redhat.com> Message-ID: <611277532.1391431.1437468890573.JavaMail.zimbra@redhat.com> I'd like all changes in and issues fixed by the end of the week for 1.4 release. There's still quite a few issues remaining. Auth/required actions: ---------- There's quite a few issues outstanding in JIRA related to the new authentication SPIs: KEYCLOAK-1457 Auth flow for non-browser auth KEYCLOAK-1552 NPE if brute force detection enabled KEYCLOAK-1508 Re-Login fails after session timeout KEYCLOAK-1489 auth timeouts should restart flow KEYCLOAK-1481 reimplement AuthenticationManagerTest KEYCLOAK-1466 Find better way to propagate BruteForceProtector KEYCLOAK-1465 Cleanup obsolete auth code KEYCLOAK-1463 Need better UI for Terms and Conditions KEYCLOAK-1457 Auth flow for non-browser auth KEYCLOAK-1455 remove user.isTotp() usage KEYCLOAK-1450 Re-enable Brute Force Protection Also, what's the status with regards to: * Migration * Is brute force enabled? * Is the improvements with regards to login time outs added? * Do we need to polish the UI with regards to auth work? Service Accounts: ----------------- Marek told me service accounts and client credential grants is going to be ready later today. This won't include additional client authentication mechanisms. UXP improvements: ----------------- Still a few minor things left. I also need to review what's been done so far. The biggest issue left is updating tables to match the pattern from PatternFly, but that'll be delayed to 1.5 as it's a pretty big task. Database: --------- We have tests failing on some databases, as well as a few db related bugs. Other things: ------------- * KEYCLOAK-1539 Accessing secured resource should not return 200 OK when not authenticated - adapters redirect to login page even for json/xml requests. That doesn't make any sense. We should only redirect to login page if Accept header is */*, text/* or text/html. * KEYCLOAK-1472 WF8 Adapter: Preflight request is redirected for auth. - adapters redirect to login page for OPTIONS request. That doesn't make sense. We don't actually know the valid web origins for non-authenticated requests though. So what should we do? Is there anything else that needs to be done for 1.4 that's not in JIRA? From stian at redhat.com Tue Jul 21 05:54:54 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 21 Jul 2015 05:54:54 -0400 (EDT) Subject: [keycloak-dev] Keycloak OpenShift Cartridge updated to 1.3.1.Final In-Reply-To: <885940784.1408605.1437472440055.JavaMail.zimbra@redhat.com> Message-ID: <1525379670.1408788.1437472494893.JavaMail.zimbra@redhat.com> Keycloak OpenShift Cartridge updated to 1.3.1.Final From bburke at redhat.com Tue Jul 21 11:15:48 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 21 Jul 2015 11:15:48 -0400 Subject: [keycloak-dev] Release status In-Reply-To: <611277532.1391431.1437468890573.JavaMail.zimbra@redhat.com> References: <611277532.1391431.1437468890573.JavaMail.zimbra@redhat.com> Message-ID: <55AE6224.1060805@redhat.com> On 7/21/2015 4:54 AM, Stian Thorgersen wrote: > I'd like all changes in and issues fixed by the end of the week for 1.4 release. There's still quite a few issues remaining. > > > Auth/required actions: > ---------- > There's quite a few issues outstanding in JIRA related to the new authentication SPIs: > > KEYCLOAK-1457 Auth flow for non-browser auth > KEYCLOAK-1552 NPE if brute force detection enabled > KEYCLOAK-1508 Re-Login fails after session timeout > KEYCLOAK-1489 auth timeouts should restart flow > KEYCLOAK-1481 reimplement AuthenticationManagerTest > KEYCLOAK-1466 Find better way to propagate BruteForceProtector > KEYCLOAK-1465 Cleanup obsolete auth code > KEYCLOAK-1463 Need better UI for Terms and Conditions > KEYCLOAK-1457 Auth flow for non-browser auth > KEYCLOAK-1455 remove user.isTotp() usage > KEYCLOAK-1450 Re-enable Brute Force Protection > I'm working on 1457 right now which is a blocker for 1465. > Also, what's the status with regards to: > > * Migration Implemented. Not really tested beyond what we already have for test scripts. > * Is brute force enabled? Need to work on this this week. > * Is the improvements with regards to login time outs added? Still some work here. > * Do we need to polish the UI with regards to auth work? > Yes, we need some polish. I'm horrible at creating nice UIs unless there is some template to work from. I don't have one to work from for the auth work. > Other things: > ------------- > * KEYCLOAK-1539 Accessing secured resource should not return 200 OK when not authenticated - adapters redirect to login page even for json/xml requests. That doesn't make any sense. We should only redirect to login page if Accept header is */*, text/* or text/html. We're not changing the adapters to change their response based on Accept header. That is a horrible hack solution. See my recent comment on this issue in jira. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Tue Jul 21 11:23:41 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 21 Jul 2015 11:23:41 -0400 Subject: [keycloak-dev] Storage and migration issues In-Reply-To: <1510622001.1327626.1437461450323.JavaMail.zimbra@redhat.com> References: <1510622001.1327626.1437461450323.JavaMail.zimbra@redhat.com> Message-ID: <55AE63FD.4000200@redhat.com> I'm not convinced any of this will make things any better. It just might introduce different problems. We're still going to have to support a relational model for User storage so we're still going to have to deal with the headaches of supporting different RDBMS dbs. I wish we could just drop Mongo. Does Red Hat even support Mongo in product? What are the advantages of storing in Mongo anyways? I do agree that its a pain that at least one of these model backends seems to break all the time. Our migration and import/export facilities are not well tested. * Representations are just going to always be different than the data model. This could be because of REST API backwards compatibility and usability. There also seems to be this mandate that exported datamodels must be human creatable and readable. This means referencing everything by name instead of ID and/or creating more hierarchical structures that look nice to humans. All of which don't map very well to a functional datastore. * The way we do caching gives us a lot of flexibility. We can have specific caching logic for various parts of the data model. All of which is datastore type agnostic. * A lot of users are using UserSession RDBMS store because they can't use, or don't know how to use Infinispan in the cloud. * I don't think users are going to want to manage 2 different types of databases, i.e. Mongo + RDBMS. * User databases need to be queryable in all sorts of ways. This pretty much requires a relational model. * Would client databases need to be queryable? I do not agree at all that we need to be able to migrate any old version of community Keycloak. I want 1st version of product to be clean and not have tons of baggage from deprecated and obsolete APIs, SPIs, and data models. Keycloak will be close to 3 years old when we go to product. It will have changed a lot. Sure, we should support migrating between any version of product because thats one of the things people pay us for. But community? It just seems like our queue is so big and the benefits of this are questionable. On 7/21/2015 2:50 AM, Stian Thorgersen wrote: > Maintaining the storage providers are a incredible time sync and very error prone. On top of that we also have migration to deal with. It would be worth to improve this before we go to product. > > Why is storage so horrible?: > > * Multiple implementations - JPA + Mongo + Representations + Cache > * Multiple database providers - every time we add anything it seems to break on at least one database > * Migration - we have 4 different types of migration to deal with. Representations, JPA, Mongo and the generic one as well > > Not only do we spend a lot of time even adding the simplest thing to the model, but we also spend a lot of time getting it to work on all supported databases before release. > > This all made me think that we have to many options! I don't think users care how we store realm and client meta-data. They may care about users though. With that regards I think we should have a single realm store that is managed by Keycloak instead of supporting an external store. For users we'd still have the option to use JPA or Mongo, but that's a significantly simpler model, in fact I don't think we've barely touched it for a long time. We could also use the same managed store for users OOTB. > > For the realm store I'd like to use either a document store or a key-value store. Relational databases are just to much of a pain to get to work, migration is painful and it makes users expect that the database of their choice will work as well. > > Alternatives could be: > > * Cassandra > * MongoDB > * Plain files - we'd have a revision number of a realm or client and we'd replicate the details with Infinispan and store on all nodes > * Infinispan store - Infinispan has built-in support for persisting data > * DMR - in domain mode WildFly manages atomic updates to all nodes. Not sure if standalone.xml etc can deal with the amount of data we have though. > * Continue storing in any store, but store a JSON blob for realms and clients. In relational database we'd have two tables, realms and clients, with an id, revision and blob > > With regards to migration I think we DO need to support updating from any version. In community this is an incredibly nice to have, but could also be more than that if a user is stuck on an old version and can't update to the intermediate version due to a bug. However, in product it's going to be required. Think about it a major release is supported for 8 years or something. We could end up with having 4 or more major versions out there at any given time. We can't expect a customer that's been on product v1 to upgrade to v2, then v3 to be able to upgrade to v4. > _______________________________________________ > 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 srossillo at smartling.com Tue Jul 21 12:07:24 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Tue, 21 Jul 2015 12:07:24 -0400 Subject: [keycloak-dev] Storage and migration issues In-Reply-To: <55AE63FD.4000200@redhat.com> References: <1510622001.1327626.1437461450323.JavaMail.zimbra@redhat.com> <55AE63FD.4000200@redhat.com> Message-ID: Please do not stick community users without an upgrade path. I know upgrades can be painful but isn?t this part of the reason for using Liquibase? Also consider that some of today?s community users may wish to become paying customers. If we can?t get from 1.x to whatever becomes product, we can?t pay RedHat. :) Besides, keeping the upgrades working keeps the product honest and fosters a more open community of users and contributors. IMO, the only real advantage of Mongo over an RDBMS for Keycloak is that it can be easily replicated and sharded. So, in theory, performance and uptime can be improved over a relational DB. However, in practice, some of the RDBMS systems can be set up for serious HA. I?ve been reading the threads on compatibility and I?m not so sure I understand why deprecated APIs and SPIs are required to be kept around to support an upgrade? Is that for non RDBMS data stores? > On Jul 21, 2015, at 11:23 AM, Bill Burke wrote: > > I'm not convinced any of this will make things any better. It just > might introduce different problems. We're still going to have to > support a relational model for User storage so we're still going to have > to deal with the headaches of supporting different RDBMS dbs. I wish we > could just drop Mongo. Does Red Hat even support Mongo in product? What > are the advantages of storing in Mongo anyways? > > I do agree that its a pain that at least one of these model backends > seems to break all the time. Our migration and import/export facilities > are not well tested. > > * Representations are just going to always be different than the data > model. This could be because of REST API backwards compatibility and > usability. There also seems to be this mandate that exported datamodels > must be human creatable and readable. This means referencing everything > by name instead of ID and/or creating more hierarchical structures that > look nice to humans. All of which don't map very well to a functional > datastore. > * The way we do caching gives us a lot of flexibility. We can have > specific caching logic for various parts of the data model. All of > which is datastore type agnostic. > * A lot of users are using UserSession RDBMS store because they can't > use, or don't know how to use Infinispan in the cloud. > * I don't think users are going to want to manage 2 different types of > databases, i.e. Mongo + RDBMS. > * User databases need to be queryable in all sorts of ways. This pretty > much requires a relational model. > * Would client databases need to be queryable? > > > I do not agree at all that we need to be able to migrate any old version > of community Keycloak. I want 1st version of product to be clean and > not have tons of baggage from deprecated and obsolete APIs, SPIs, and > data models. Keycloak will be close to 3 years old when we go to > product. It will have changed a lot. Sure, we should support migrating > between any version of product because thats one of the things people > pay us for. But community? > > It just seems like our queue is so big and the benefits of this are > questionable. > > On 7/21/2015 2:50 AM, Stian Thorgersen wrote: >> Maintaining the storage providers are a incredible time sync and very error prone. On top of that we also have migration to deal with. It would be worth to improve this before we go to product. >> >> Why is storage so horrible?: >> >> * Multiple implementations - JPA + Mongo + Representations + Cache >> * Multiple database providers - every time we add anything it seems to break on at least one database >> * Migration - we have 4 different types of migration to deal with. Representations, JPA, Mongo and the generic one as well >> >> Not only do we spend a lot of time even adding the simplest thing to the model, but we also spend a lot of time getting it to work on all supported databases before release. >> >> This all made me think that we have to many options! I don't think users care how we store realm and client meta-data. They may care about users though. With that regards I think we should have a single realm store that is managed by Keycloak instead of supporting an external store. For users we'd still have the option to use JPA or Mongo, but that's a significantly simpler model, in fact I don't think we've barely touched it for a long time. We could also use the same managed store for users OOTB. >> >> For the realm store I'd like to use either a document store or a key-value store. Relational databases are just to much of a pain to get to work, migration is painful and it makes users expect that the database of their choice will work as well. >> >> Alternatives could be: >> >> * Cassandra >> * MongoDB >> * Plain files - we'd have a revision number of a realm or client and we'd replicate the details with Infinispan and store on all nodes >> * Infinispan store - Infinispan has built-in support for persisting data >> * DMR - in domain mode WildFly manages atomic updates to all nodes. Not sure if standalone.xml etc can deal with the amount of data we have though. >> * Continue storing in any store, but store a JSON blob for realms and clients. In relational database we'd have two tables, realms and clients, with an id, revision and blob >> >> With regards to migration I think we DO need to support updating from any version. In community this is an incredibly nice to have, but could also be more than that if a user is stuck on an old version and can't update to the intermediate version due to a bug. However, in product it's going to be required. Think about it a major release is supported for 8 years or something. We could end up with having 4 or more major versions out there at any given time. We can't expect a customer that's been on product v1 to upgrade to v2, then v3 to be able to upgrade to v4. >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Tue Jul 21 13:06:30 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 21 Jul 2015 13:06:30 -0400 (EDT) Subject: [keycloak-dev] Release status In-Reply-To: <55AE6224.1060805@redhat.com> References: <611277532.1391431.1437468890573.JavaMail.zimbra@redhat.com> <55AE6224.1060805@redhat.com> Message-ID: <1120510949.1737115.1437498390598.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Tuesday, 21 July, 2015 5:15:48 PM > Subject: Re: [keycloak-dev] Release status > > > > On 7/21/2015 4:54 AM, Stian Thorgersen wrote: > > I'd like all changes in and issues fixed by the end of the week for 1.4 > > release. There's still quite a few issues remaining. > > > > > > Auth/required actions: > > ---------- > > There's quite a few issues outstanding in JIRA related to the new > > authentication SPIs: > > > > KEYCLOAK-1457 Auth flow for non-browser auth > > KEYCLOAK-1552 NPE if brute force detection enabled > > KEYCLOAK-1508 Re-Login fails after session timeout > > KEYCLOAK-1489 auth timeouts should restart flow > > KEYCLOAK-1481 reimplement AuthenticationManagerTest > > KEYCLOAK-1466 Find better way to propagate BruteForceProtector > > KEYCLOAK-1465 Cleanup obsolete auth code > > KEYCLOAK-1463 Need better UI for Terms and Conditions > > KEYCLOAK-1457 Auth flow for non-browser auth > > KEYCLOAK-1455 remove user.isTotp() usage > > KEYCLOAK-1450 Re-enable Brute Force Protection > > > > I'm working on 1457 right now which is a blocker for 1465. > > > Also, what's the status with regards to: > > > > * Migration > > Implemented. Not really tested beyond what we already have for test > scripts. > > > * Is brute force enabled? > > Need to work on this this week. > > > * Is the improvements with regards to login time outs added? > > Still some work here. > > > * Do we need to polish the UI with regards to auth work? > > > > Yes, we need some polish. I'm horrible at creating nice UIs unless > there is some template to work from. I don't have one to work from for > the auth work. I can take a stab at cleaning it up a little bit - then we can have the UXP guys review it later > > > Other things: > > ------------- > > * KEYCLOAK-1539 Accessing secured resource should not return 200 OK when > > not authenticated - adapters redirect to login page even for json/xml > > requests. That doesn't make any sense. We should only redirect to login > > page if Accept header is */*, text/* or text/html. > > We're not changing the adapters to change their response based on Accept > header. That is a horrible hack solution. See my recent comment on > this issue in jira. I don't understand why that's a hack solution? Returning a redirect to a html page for something requesting a json document just isn't right. > > > -- > 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 Tue Jul 21 13:53:50 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 21 Jul 2015 13:53:50 -0400 Subject: [keycloak-dev] Storage and migration issues In-Reply-To: References: <1510622001.1327626.1437461450323.JavaMail.zimbra@redhat.com> <55AE63FD.4000200@redhat.com> Message-ID: <55AE872E.7070001@redhat.com> In the near future, Marek and I just want to drop support for migrating earlier keycloak community versions so we can clean up the codebase and datamodel and drop a bunch of migration code. The idea would be that you would have to upgrade to 1.7 community before you could upgrade to 2.0 community. As it is, we don't do point releases of earlier community versions anyways. On 7/21/2015 12:07 PM, Scott Rossillo wrote: > > Please do not stick community users without an upgrade path. I know upgrades can be painful but isn?t this part of the reason for using Liquibase? Also consider that some of today?s community users may wish to become paying customers. If we can?t get from 1.x to whatever becomes product, we can?t pay RedHat. :) Besides, keeping the upgrades working keeps the product honest and fosters a more open community of users and contributors. > > IMO, the only real advantage of Mongo over an RDBMS for Keycloak is that it can be easily replicated and sharded. So, in theory, performance and uptime can be improved over a relational DB. However, in practice, some of the RDBMS systems can be set up for serious HA. > > I?ve been reading the threads on compatibility and I?m not so sure I understand why deprecated APIs and SPIs are required to be kept around to support an upgrade? Is that for non RDBMS data stores? > > >> On Jul 21, 2015, at 11:23 AM, Bill Burke wrote: >> >> I'm not convinced any of this will make things any better. It just >> might introduce different problems. We're still going to have to >> support a relational model for User storage so we're still going to have >> to deal with the headaches of supporting different RDBMS dbs. I wish we >> could just drop Mongo. Does Red Hat even support Mongo in product? What >> are the advantages of storing in Mongo anyways? >> >> I do agree that its a pain that at least one of these model backends >> seems to break all the time. Our migration and import/export facilities >> are not well tested. >> >> * Representations are just going to always be different than the data >> model. This could be because of REST API backwards compatibility and >> usability. There also seems to be this mandate that exported datamodels >> must be human creatable and readable. This means referencing everything >> by name instead of ID and/or creating more hierarchical structures that >> look nice to humans. All of which don't map very well to a functional >> datastore. >> * The way we do caching gives us a lot of flexibility. We can have >> specific caching logic for various parts of the data model. All of >> which is datastore type agnostic. >> * A lot of users are using UserSession RDBMS store because they can't >> use, or don't know how to use Infinispan in the cloud. >> * I don't think users are going to want to manage 2 different types of >> databases, i.e. Mongo + RDBMS. >> * User databases need to be queryable in all sorts of ways. This pretty >> much requires a relational model. >> * Would client databases need to be queryable? >> >> >> I do not agree at all that we need to be able to migrate any old version >> of community Keycloak. I want 1st version of product to be clean and >> not have tons of baggage from deprecated and obsolete APIs, SPIs, and >> data models. Keycloak will be close to 3 years old when we go to >> product. It will have changed a lot. Sure, we should support migrating >> between any version of product because thats one of the things people >> pay us for. But community? >> >> It just seems like our queue is so big and the benefits of this are >> questionable. >> >> On 7/21/2015 2:50 AM, Stian Thorgersen wrote: >>> Maintaining the storage providers are a incredible time sync and very error prone. On top of that we also have migration to deal with. It would be worth to improve this before we go to product. >>> >>> Why is storage so horrible?: >>> >>> * Multiple implementations - JPA + Mongo + Representations + Cache >>> * Multiple database providers - every time we add anything it seems to break on at least one database >>> * Migration - we have 4 different types of migration to deal with. Representations, JPA, Mongo and the generic one as well >>> >>> Not only do we spend a lot of time even adding the simplest thing to the model, but we also spend a lot of time getting it to work on all supported databases before release. >>> >>> This all made me think that we have to many options! I don't think users care how we store realm and client meta-data. They may care about users though. With that regards I think we should have a single realm store that is managed by Keycloak instead of supporting an external store. For users we'd still have the option to use JPA or Mongo, but that's a significantly simpler model, in fact I don't think we've barely touched it for a long time. We could also use the same managed store for users OOTB. >>> >>> For the realm store I'd like to use either a document store or a key-value store. Relational databases are just to much of a pain to get to work, migration is painful and it makes users expect that the database of their choice will work as well. >>> >>> Alternatives could be: >>> >>> * Cassandra >>> * MongoDB >>> * Plain files - we'd have a revision number of a realm or client and we'd replicate the details with Infinispan and store on all nodes >>> * Infinispan store - Infinispan has built-in support for persisting data >>> * DMR - in domain mode WildFly manages atomic updates to all nodes. Not sure if standalone.xml etc can deal with the amount of data we have though. >>> * Continue storing in any store, but store a JSON blob for realms and clients. In relational database we'd have two tables, realms and clients, with an id, revision and blob >>> >>> With regards to migration I think we DO need to support updating from any version. In community this is an incredibly nice to have, but could also be more than that if a user is stuck on an old version and can't update to the intermediate version due to a bug. However, in product it's going to be required. Think about it a major release is supported for 8 years or something. We could end up with having 4 or more major versions out there at any given time. We can't expect a customer that's been on product v1 to upgrade to v2, then v3 to be able to upgrade to v4. >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Tue Jul 21 14:03:13 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 21 Jul 2015 14:03:13 -0400 Subject: [keycloak-dev] Release status In-Reply-To: <1120510949.1737115.1437498390598.JavaMail.zimbra@redhat.com> References: <611277532.1391431.1437468890573.JavaMail.zimbra@redhat.com> <55AE6224.1060805@redhat.com> <1120510949.1737115.1437498390598.JavaMail.zimbra@redhat.com> Message-ID: <55AE8961.3020102@redhat.com> On 7/21/2015 1:06 PM, Stian Thorgersen wrote: > >> >>> Other things: >>> ------------- >>> * KEYCLOAK-1539 Accessing secured resource should not return 200 OK when >>> not authenticated - adapters redirect to login page even for json/xml >>> requests. That doesn't make any sense. We should only redirect to login >>> page if Accept header is */*, text/* or text/html. >> >> We're not changing the adapters to change their response based on Accept >> header. That is a horrible hack solution. See my recent comment on >> this issue in jira. > > I don't understand why that's a hack solution? Returning a redirect to a html page for something requesting a json document just isn't right. > REST clients often don't set the Accept header. A REST client might be requesting text/* or text/html within their Accept header. I'm not sure you can do this based on User Agent either. I think some client libs set the User Agent to mozilla, not sure though. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From srossillo at smartling.com Tue Jul 21 14:40:30 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Tue, 21 Jul 2015 14:40:30 -0400 Subject: [keycloak-dev] Storage and migration issues In-Reply-To: References: <1510622001.1327626.1437461450323.JavaMail.zimbra@redhat.com> <55AE63FD.4000200@redhat.com> Message-ID: <9F48F64D-CEF6-4657-837F-B3D6A0575E40@smartling.com> I don?t see a problem with that. > On Jul 21, 2015, at 12:07 PM, Scott Rossillo wrote: > > > Please do not stick community users without an upgrade path. I know upgrades can be painful but isn?t this part of the reason for using Liquibase? Also consider that some of today?s community users may wish to become paying customers. If we can?t get from 1.x to whatever becomes product, we can?t pay RedHat. :) Besides, keeping the upgrades working keeps the product honest and fosters a more open community of users and contributors. > > IMO, the only real advantage of Mongo over an RDBMS for Keycloak is that it can be easily replicated and sharded. So, in theory, performance and uptime can be improved over a relational DB. However, in practice, some of the RDBMS systems can be set up for serious HA. > > I?ve been reading the threads on compatibility and I?m not so sure I understand why deprecated APIs and SPIs are required to be kept around to support an upgrade? Is that for non RDBMS data stores? > > >> On Jul 21, 2015, at 11:23 AM, Bill Burke wrote: >> >> I'm not convinced any of this will make things any better. It just >> might introduce different problems. We're still going to have to >> support a relational model for User storage so we're still going to have >> to deal with the headaches of supporting different RDBMS dbs. I wish we >> could just drop Mongo. Does Red Hat even support Mongo in product? What >> are the advantages of storing in Mongo anyways? >> >> I do agree that its a pain that at least one of these model backends >> seems to break all the time. Our migration and import/export facilities >> are not well tested. >> >> * Representations are just going to always be different than the data >> model. This could be because of REST API backwards compatibility and >> usability. There also seems to be this mandate that exported datamodels >> must be human creatable and readable. This means referencing everything >> by name instead of ID and/or creating more hierarchical structures that >> look nice to humans. All of which don't map very well to a functional >> datastore. >> * The way we do caching gives us a lot of flexibility. We can have >> specific caching logic for various parts of the data model. All of >> which is datastore type agnostic. >> * A lot of users are using UserSession RDBMS store because they can't >> use, or don't know how to use Infinispan in the cloud. >> * I don't think users are going to want to manage 2 different types of >> databases, i.e. Mongo + RDBMS. >> * User databases need to be queryable in all sorts of ways. This pretty >> much requires a relational model. >> * Would client databases need to be queryable? >> >> >> I do not agree at all that we need to be able to migrate any old version >> of community Keycloak. I want 1st version of product to be clean and >> not have tons of baggage from deprecated and obsolete APIs, SPIs, and >> data models. Keycloak will be close to 3 years old when we go to >> product. It will have changed a lot. Sure, we should support migrating >> between any version of product because thats one of the things people >> pay us for. But community? >> >> It just seems like our queue is so big and the benefits of this are >> questionable. >> >> On 7/21/2015 2:50 AM, Stian Thorgersen wrote: >>> Maintaining the storage providers are a incredible time sync and very error prone. On top of that we also have migration to deal with. It would be worth to improve this before we go to product. >>> >>> Why is storage so horrible?: >>> >>> * Multiple implementations - JPA + Mongo + Representations + Cache >>> * Multiple database providers - every time we add anything it seems to break on at least one database >>> * Migration - we have 4 different types of migration to deal with. Representations, JPA, Mongo and the generic one as well >>> >>> Not only do we spend a lot of time even adding the simplest thing to the model, but we also spend a lot of time getting it to work on all supported databases before release. >>> >>> This all made me think that we have to many options! I don't think users care how we store realm and client meta-data. They may care about users though. With that regards I think we should have a single realm store that is managed by Keycloak instead of supporting an external store. For users we'd still have the option to use JPA or Mongo, but that's a significantly simpler model, in fact I don't think we've barely touched it for a long time. We could also use the same managed store for users OOTB. >>> >>> For the realm store I'd like to use either a document store or a key-value store. Relational databases are just to much of a pain to get to work, migration is painful and it makes users expect that the database of their choice will work as well. >>> >>> Alternatives could be: >>> >>> * Cassandra >>> * MongoDB >>> * Plain files - we'd have a revision number of a realm or client and we'd replicate the details with Infinispan and store on all nodes >>> * Infinispan store - Infinispan has built-in support for persisting data >>> * DMR - in domain mode WildFly manages atomic updates to all nodes. Not sure if standalone.xml etc can deal with the amount of data we have though. >>> * Continue storing in any store, but store a JSON blob for realms and clients. In relational database we'd have two tables, realms and clients, with an id, revision and blob >>> >>> With regards to migration I think we DO need to support updating from any version. In community this is an incredibly nice to have, but could also be more than that if a user is stuck on an old version and can't update to the intermediate version due to a bug. However, in product it's going to be required. Think about it a major release is supported for 8 years or something. We could end up with having 4 or more major versions out there at any given time. We can't expect a customer that's been on product v1 to upgrade to v2, then v3 to be able to upgrade to v4. >>> _______________________________________________ >>> 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 gerbermichi at me.com Wed Jul 22 04:07:15 2015 From: gerbermichi at me.com (Michael Gerber) Date: Wed, 22 Jul 2015 08:07:15 +0000 (GMT) Subject: [keycloak-dev] Kerberos with IE does not work Message-ID: Hi all My kerberos configuration works fine with FireFox and Chrome, but it does not work with IE. It shows a prompt where the user has to enter a username and password. I can successfully get an access code, but I can not get an access token, because IE overwrites the?Authorization header in the AJAX request. (see?http://stackoverflow.com/questions/28615850/internet-explorer-11-replaces-authorization-header) I can fix this by adding? document.execCommand('ClearAuthenticationCache', 'false'); above of? var req = new XMLHttpRequest(); approximately at the line 374 in the keycloack.js file. Is there another solution for this problem? cheers Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150722/c89f6427/attachment.html From mposolda at redhat.com Wed Jul 22 05:41:34 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 22 Jul 2015 11:41:34 +0200 Subject: [keycloak-dev] Service accounts - version 1 commited Message-ID: <55AF654E.5060800@redhat.com> Few points to how it works now: - There is new boolean flag setServiceAccountsEnabled on ClientModel. That's the only model change - There is new tab "Service accounts" for confidential clients in admin console . Right now, service account authentication is available just for confidential clients, not bearer-only or public clients. The tab contains just one on/off switch for enable/disable service account authentication support. It's disabled by default. I think for the next release we can add the table with Authentication mechanisms for clients, so admin can choose for example that Client Credentials Grant is "DISABLED" and Certificate authentication is "ALTERNATIVE" etc. Right now, the client authentication is available just through OAuth2 Client Credentials Grant (authentication with clientId + client secret) - When service account enabled for client "foo", new user "service-account-foo" is created . I've added the "service-account-" prefix just to make more visible that this is not normal user, but user dedicated to service account. The user has also attribute with client DB ID (It's really DB ID, not clientId) and the binding between client and user is through this attribute. Hence when admin renames clientId of this client or renames the username of service account user, the binding still works. The roles available to this user are used in the token dedicated to service account. - The existing TokenEndpoint is reused for service account authentication. Just new grantType "client_credentials" is added as per OAuth2 specs. - The token retrieved through service account has few additional attributes available in otherClaims(). Those are added by protocol mappers, which are created when service account authentication is enabled. Right now, it's just clientID, clientHost and client address (host and address are retrieved dynamically from ClientConnection used during auth request to TokenEndpoint). Should we have more info available in service account access token? - Sample app "service-account-example" added to the demo - Only missing piece for the 1.4 release seems to be docs unless you have additional feedback. WDYT? Marek From mposolda at redhat.com Wed Jul 22 05:45:59 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 22 Jul 2015 11:45:59 +0200 Subject: [keycloak-dev] Kerberos with IE does not work In-Reply-To: References: Message-ID: <55AF6657.4060009@redhat.com> Hi Michael, No idea if there is other solution, I've never tried SPNEGO with Internet explorer TBH :( Could you please create JIRA for this? Thanks, Marek On 22.7.2015 10:07, Michael Gerber wrote: > Hi all > > My kerberos configuration works fine with FireFox and Chrome, but it > does not work with IE. > It shows a prompt where the user has to enter a username and password. > > I can successfully get an access code, but I can not get an access > token, because IE overwrites the Authorization header in the AJAX > request. (see > http://stackoverflow.com/questions/28615850/internet-explorer-11-replaces-authorization-header) > > I can fix this by adding > document.execCommand('ClearAuthenticationCache', 'false'); > above of > var req = new XMLHttpRequest(); > approximately at the line 374 in the keycloack.js file. > > Is there another solution for this problem? > > cheers > Michael > > > _______________________________________________ > 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/20150722/8e196258/attachment.html From Martin.Hipfinger at oebb.at Wed Jul 22 06:10:25 2015 From: Martin.Hipfinger at oebb.at (=?iso-8859-1?Q?Hipfinger_Martin_=28BCC=2E=D6BB=2ETicketShop=2EMA=29?=) Date: Wed, 22 Jul 2015 10:10:25 +0000 Subject: [keycloak-dev] multi tenant configuration with 1.3.1? Message-ID: <1CBE59D9C302B841A9562E1A3A6F5B73330769CF@LAXEX004.oebb.at> Hi, we're running keycloak 1.1 with several overlays - in detail: - A new datasource per overlay /opt/keycloak/bin/jboss-cli.sh --commands="connect, data-source add --name=xxxDS --connection-url=jdbc:oracle:thin:@xxxxx:1522:xxxxx --jndi-name=java:jboss/datasources/xxxDS --driver-name=ojdbc --password=xxx --user-name=XXX" - A new auth-server entry /opt/keycloak/bin/jboss-cli.sh --commands="connect, /subsystem=keycloak/auth-server=xxx-server/:add(web-context=xxx, enabled=true)" - An own keycloak-server.json "connectionsJpa": { "default": { "dataSource": "java:jboss/datasources/xxxDS", "databaseSchema": "update" } } "connectionsInfinispan": { "default" : { "cacheContainer" : "java:jboss/infinispan/xxxKeycloak" } /opt/keycloak/bin/jboss-cli.sh --commands="connect, /subsystem=keycloak/auth-server=xxx-server:update-server-config(bytes-to-upload=/opt/keycloak/standalone/configuration/keycloak-server-xxx.json,overwrite=true)" This configuration isn't supported anymore with 1.3.1 - do you have any hint for me, how to achieve a similar config with 1.3.1? br, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150722/93242959/attachment-0001.html From stian at redhat.com Wed Jul 22 06:30:42 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 22 Jul 2015 06:30:42 -0400 (EDT) Subject: [keycloak-dev] multi tenant configuration with 1.3.1? In-Reply-To: <1CBE59D9C302B841A9562E1A3A6F5B73330769CF@LAXEX004.oebb.at> References: <1CBE59D9C302B841A9562E1A3A6F5B73330769CF@LAXEX004.oebb.at> Message-ID: <1993079511.2621774.1437561042399.JavaMail.zimbra@redhat.com> Please use user mailing list for support questions ----- Original Message ----- > From: "Hipfinger Martin (BCC.?BB.TicketShop.MA)" > To: keycloak-dev at lists.jboss.org > Sent: Wednesday, 22 July, 2015 12:10:25 PM > Subject: [keycloak-dev] multi tenant configuration with 1.3.1? > > > > Hi, > > > > we?re running keycloak 1.1 with several overlays ? in detail: > > > > - A new datasource per overlay > > /opt/keycloak/bin/jboss-cli.sh --commands="connect, data-source add --name= > xxx DS --connection-url=jdbc:oracle:thin:@ xxxxx:1522:xxxxx > --jndi-name=java:jboss/datasources/ xxx DS --driver-name=ojdbc --password= > xxx --user-name= XXX " > > > > - A new auth-server entry > > /opt/keycloak/bin/jboss-cli.sh --commands="connect, > /subsystem=keycloak/auth-server= xxx -server/:add(web-context= xxx , > enabled=true)" > > > > - An own keycloak-server.json > > "connectionsJpa": { > > "default": { > > "dataSource": "java:jboss/datasources/ xxx DS", > > "databaseSchema": "update" > > } > > } > > "connectionsInfinispan": { > > "default" : { > > "cacheContainer" : "java:jboss/infinispan/ xxx Keycloak" > > } > > > > /opt/keycloak/bin/jboss-cli.sh --commands=?connect, > /subsystem=keycloak/auth-server= xxx > -server:update-server-config(bytes-to-upload=/opt/keycloak/standalone/configuration/keycloak-server- > xxx .json,overwrite=true)? > > > > This configuration isn?t supported anymore with 1.3.1 - do you have any hint > for me, how to achieve a similar config with 1.3.1? > > > > br, > > Martin > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Wed Jul 22 07:32:06 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 22 Jul 2015 07:32:06 -0400 (EDT) Subject: [keycloak-dev] Service accounts - version 1 commited In-Reply-To: <55AF654E.5060800@redhat.com> References: <55AF654E.5060800@redhat.com> Message-ID: <839864171.2645633.1437564726842.JavaMail.zimbra@redhat.com> A few comments: * Do we need the ''Service Account' tab? It seems the enable/disable option should be on the 'Settings' tab in either case. We already have tab for 'Credentials' which is where alternative auth methods should be configured (all confidential clients should be able to use alternative auth methods, not just those that use service accounts). * I assume currently to set role mappings for the client you'd have to somehow find the associated user? That seems a bit cumbersome to me. We should at the very least add a link, but even better as it's only role mappings we want to configure I think 'service account users' should be hidden from regular users lists and instead we should have a role mappings tab on the client. ----- Original Message ----- > From: "Marek Posolda" > To: keycloak-dev at lists.jboss.org > Sent: Wednesday, 22 July, 2015 11:41:34 AM > Subject: [keycloak-dev] Service accounts - version 1 commited > > Few points to how it works now: > > - There is new boolean flag setServiceAccountsEnabled on ClientModel. > That's the only model change > > - There is new tab "Service accounts" for confidential clients in admin > console . Right now, service account authentication is available just > for confidential clients, not bearer-only or public clients. The tab > contains just one on/off switch for enable/disable service account > authentication support. It's disabled by default. I think for the next > release we can add the table with Authentication mechanisms for clients, > so admin can choose for example that Client Credentials Grant is > "DISABLED" and Certificate authentication is "ALTERNATIVE" etc. Right > now, the client authentication is available just through OAuth2 Client > Credentials Grant (authentication with clientId + client secret) > > - When service account enabled for client "foo", new user > "service-account-foo" is created . I've added the "service-account-" > prefix just to make more visible that this is not normal user, but user > dedicated to service account. The user has also attribute with client DB > ID (It's really DB ID, not clientId) and the binding between client and > user is through this attribute. Hence when admin renames clientId of > this client or renames the username of service account user, the binding > still works. The roles available to this user are used in the token > dedicated to service account. > > - The existing TokenEndpoint is reused for service account > authentication. Just new grantType "client_credentials" is added as per > OAuth2 specs. > > - The token retrieved through service account has few additional > attributes available in otherClaims(). Those are added by protocol > mappers, which are created when service account authentication is > enabled. Right now, it's just clientID, clientHost and client address > (host and address are retrieved dynamically from ClientConnection used > during auth request to TokenEndpoint). Should we have more info > available in service account access token? > > - Sample app "service-account-example" added to the demo > > - Only missing piece for the 1.4 release seems to be docs unless you > have additional feedback. > > 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 Jul 22 08:17:40 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 22 Jul 2015 08:17:40 -0400 Subject: [keycloak-dev] Kerberos with IE does not work In-Reply-To: References: Message-ID: <55AF89E4.6000507@redhat.com> So, the problem isn't that kerberos doesn't work, its that code to token doesn't work (neither does bearer)? On 7/22/2015 4:07 AM, Michael Gerber wrote: > Hi all > > My kerberos configuration works fine with FireFox and Chrome, but it > does not work with IE. > It shows a prompt where the user has to enter a username and password. > > I can successfully get an access code, but I can not get an access > token, because IE overwrites the Authorization header in the AJAX > request. (see > http://stackoverflow.com/questions/28615850/internet-explorer-11-replaces-authorization-header) > > I can fix this by adding > document.execCommand('ClearAuthenticationCache', 'false'); > above of > var req = new XMLHttpRequest(); > approximately at the line 374 in the keycloack.js file. > > Is there another solution for this problem? > > cheers > Michael > > > _______________________________________________ > 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 gerbermichi at me.com Wed Jul 22 09:00:14 2015 From: gerbermichi at me.com (Michael Gerber) Date: Wed, 22 Jul 2015 13:00:14 +0000 (GMT) Subject: [keycloak-dev] Kerberos with IE does not work Message-ID: <6c83dc7c-d0fa-45fc-bb75-cc4ac94c5682@me.com> Yes, kerberos works fine.? AuthorizeClientUtil.authorizeClient(authorizationHeader, formParams, event, realm);? throws an?UnauthorizedException exception because the authorization header contains?Negotiate xxx instead of Basic xxx. Jira:?https://issues.jboss.org/browse/KEYCLOAK-1595 Am 22. Juli 2015 um 14:23 schrieb Bill Burke : So, the problem isn't that kerberos doesn't work, its that code to token doesn't work (neither does bearer)? On 7/22/2015 4:07 AM, Michael Gerber wrote: Hi all My kerberos configuration works fine with FireFox and Chrome, but it does not work with IE. It shows a prompt where the user has to enter a username and password. I can successfully get an access code, but I can not get an access token, because IE overwrites the Authorization header in the AJAX request. (see http://stackoverflow.com/questions/28615850/internet-explorer-11-replaces-authorization-header) I can fix this by adding document.execCommand('ClearAuthenticationCache', 'false'); above of var req = new XMLHttpRequest(); approximately at the line 374 in the keycloack.js file. Is there another solution for this problem? cheers Michael _______________________________________________ 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/20150722/eee9f6d1/attachment.html From mposolda at redhat.com Wed Jul 22 09:56:18 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 22 Jul 2015 15:56:18 +0200 Subject: [keycloak-dev] Service accounts - version 1 commited In-Reply-To: <839864171.2645633.1437564726842.JavaMail.zimbra@redhat.com> References: <55AF654E.5060800@redhat.com> <839864171.2645633.1437564726842.JavaMail.zimbra@redhat.com> Message-ID: <55AFA102.1000102@redhat.com> On 22.7.2015 13:32, Stian Thorgersen wrote: > A few comments: > > * Do we need the ''Service Account' tab? It seems the enable/disable option should be on the 'Settings' tab in either case. We already have tab for 'Credentials' which is where alternative auth methods should be configured (all confidential clients should be able to use alternative auth methods, not just those that use service accounts). Yeah, that seems to be better. I will delete 'Service Account' tab and put the option to the 'Settings' . The credentials tab won't be changed for now as there are no more supported authentication mechanisms. > * I assume currently to set role mappings for the client you'd have to somehow find the associated user? That seems a bit cumbersome to me. We should at the very least add a link, but even better as it's only role mappings we want to configure I think 'service account users' should be hidden from regular users lists and instead we should have a role mappings tab on the client. I can add the tab for role mappings, which will point to role mappings of the linked user. I agree that will be much better regarding usability. But for hiding the 'service account user' from the user list, it will require changes in the search model methods (like UserProvider.searchForUser + maybe UserProvider.searchForUserByAttributes ). Do you want me to go that way? One additional question, does it makes sense to save the 'service account user' into federation when it's enabled for the realm? For me, rather not, so I can use "session.userStorage()" directly to save this user. Thinking if someone may want to have service account saved in LDAP including his role mappings, but it's probably just hypothetical usecase... Marek > > ----- Original Message ----- >> From: "Marek Posolda" >> To: keycloak-dev at lists.jboss.org >> Sent: Wednesday, 22 July, 2015 11:41:34 AM >> Subject: [keycloak-dev] Service accounts - version 1 commited >> >> Few points to how it works now: >> >> - There is new boolean flag setServiceAccountsEnabled on ClientModel. >> That's the only model change >> >> - There is new tab "Service accounts" for confidential clients in admin >> console . Right now, service account authentication is available just >> for confidential clients, not bearer-only or public clients. The tab >> contains just one on/off switch for enable/disable service account >> authentication support. It's disabled by default. I think for the next >> release we can add the table with Authentication mechanisms for clients, >> so admin can choose for example that Client Credentials Grant is >> "DISABLED" and Certificate authentication is "ALTERNATIVE" etc. Right >> now, the client authentication is available just through OAuth2 Client >> Credentials Grant (authentication with clientId + client secret) >> >> - When service account enabled for client "foo", new user >> "service-account-foo" is created . I've added the "service-account-" >> prefix just to make more visible that this is not normal user, but user >> dedicated to service account. The user has also attribute with client DB >> ID (It's really DB ID, not clientId) and the binding between client and >> user is through this attribute. Hence when admin renames clientId of >> this client or renames the username of service account user, the binding >> still works. The roles available to this user are used in the token >> dedicated to service account. >> >> - The existing TokenEndpoint is reused for service account >> authentication. Just new grantType "client_credentials" is added as per >> OAuth2 specs. >> >> - The token retrieved through service account has few additional >> attributes available in otherClaims(). Those are added by protocol >> mappers, which are created when service account authentication is >> enabled. Right now, it's just clientID, clientHost and client address >> (host and address are retrieved dynamically from ClientConnection used >> during auth request to TokenEndpoint). Should we have more info >> available in service account access token? >> >> - Sample app "service-account-example" added to the demo >> >> - Only missing piece for the 1.4 release seems to be docs unless you >> have additional feedback. >> >> WDYT? >> >> 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 Jul 22 10:21:24 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 22 Jul 2015 10:21:24 -0400 (EDT) Subject: [keycloak-dev] Service accounts - version 1 commited In-Reply-To: <55AFA102.1000102@redhat.com> References: <55AF654E.5060800@redhat.com> <839864171.2645633.1437564726842.JavaMail.zimbra@redhat.com> <55AFA102.1000102@redhat.com> Message-ID: <877038106.2759930.1437574884245.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Marek Posolda" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Wednesday, 22 July, 2015 3:56:18 PM > Subject: Re: [keycloak-dev] Service accounts - version 1 commited > > On 22.7.2015 13:32, Stian Thorgersen wrote: > > A few comments: > > > > * Do we need the ''Service Account' tab? It seems the enable/disable option > > should be on the 'Settings' tab in either case. We already have tab for > > 'Credentials' which is where alternative auth methods should be configured > > (all confidential clients should be able to use alternative auth methods, > > not just those that use service accounts). > Yeah, that seems to be better. I will delete 'Service Account' tab and > put the option to the 'Settings' . The credentials tab won't be changed > for now as there are no more supported authentication mechanisms. > > * I assume currently to set role mappings for the client you'd have to > > somehow find the associated user? That seems a bit cumbersome to me. We > > should at the very least add a link, but even better as it's only role > > mappings we want to configure I think 'service account users' should be > > hidden from regular users lists and instead we should have a role mappings > > tab on the client. > I can add the tab for role mappings, which will point to role mappings > of the linked user. I agree that will be much better regarding usability. > > But for hiding the 'service account user' from the user list, it will > require changes in the search model methods (like > UserProvider.searchForUser + maybe > UserProvider.searchForUserByAttributes ). Do you want me to go that way? Rather than adding an attribute would it be better to add a flag directly on UserModel/Entity? > > One additional question, does it makes sense to save the 'service > account user' into federation when it's enabled for the realm? For me, > rather not, so I can use "session.userStorage()" directly to save this > user. Thinking if someone may want to have service account saved in LDAP > including his role mappings, but it's probably just hypothetical usecase... I'd lean towards not saving in federation at first, then we consider adding if requested. > > Marek > > > > ----- Original Message ----- > >> From: "Marek Posolda" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Wednesday, 22 July, 2015 11:41:34 AM > >> Subject: [keycloak-dev] Service accounts - version 1 commited > >> > >> Few points to how it works now: > >> > >> - There is new boolean flag setServiceAccountsEnabled on ClientModel. > >> That's the only model change > >> > >> - There is new tab "Service accounts" for confidential clients in admin > >> console . Right now, service account authentication is available just > >> for confidential clients, not bearer-only or public clients. The tab > >> contains just one on/off switch for enable/disable service account > >> authentication support. It's disabled by default. I think for the next > >> release we can add the table with Authentication mechanisms for clients, > >> so admin can choose for example that Client Credentials Grant is > >> "DISABLED" and Certificate authentication is "ALTERNATIVE" etc. Right > >> now, the client authentication is available just through OAuth2 Client > >> Credentials Grant (authentication with clientId + client secret) > >> > >> - When service account enabled for client "foo", new user > >> "service-account-foo" is created . I've added the "service-account-" > >> prefix just to make more visible that this is not normal user, but user > >> dedicated to service account. The user has also attribute with client DB > >> ID (It's really DB ID, not clientId) and the binding between client and > >> user is through this attribute. Hence when admin renames clientId of > >> this client or renames the username of service account user, the binding > >> still works. The roles available to this user are used in the token > >> dedicated to service account. > >> > >> - The existing TokenEndpoint is reused for service account > >> authentication. Just new grantType "client_credentials" is added as per > >> OAuth2 specs. > >> > >> - The token retrieved through service account has few additional > >> attributes available in otherClaims(). Those are added by protocol > >> mappers, which are created when service account authentication is > >> enabled. Right now, it's just clientID, clientHost and client address > >> (host and address are retrieved dynamically from ClientConnection used > >> during auth request to TokenEndpoint). Should we have more info > >> available in service account access token? > >> > >> - Sample app "service-account-example" added to the demo > >> > >> - Only missing piece for the 1.4 release seems to be docs unless you > >> have additional feedback. > >> > >> 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 Wed Jul 22 10:30:17 2015 From: mposolda at redhat.com (Marek Posolda) Date: Wed, 22 Jul 2015 16:30:17 +0200 Subject: [keycloak-dev] Service accounts - version 1 commited In-Reply-To: <877038106.2759930.1437574884245.JavaMail.zimbra@redhat.com> References: <55AF654E.5060800@redhat.com> <839864171.2645633.1437564726842.JavaMail.zimbra@redhat.com> <55AFA102.1000102@redhat.com> <877038106.2759930.1437574884245.JavaMail.zimbra@redhat.com> Message-ID: <55AFA8F9.3060507@redhat.com> On 22.7.2015 16:21, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Marek Posolda" >> To: "Stian Thorgersen" >> Cc: keycloak-dev at lists.jboss.org >> Sent: Wednesday, 22 July, 2015 3:56:18 PM >> Subject: Re: [keycloak-dev] Service accounts - version 1 commited >> >> On 22.7.2015 13:32, Stian Thorgersen wrote: >>> A few comments: >>> >>> * Do we need the ''Service Account' tab? It seems the enable/disable option >>> should be on the 'Settings' tab in either case. We already have tab for >>> 'Credentials' which is where alternative auth methods should be configured >>> (all confidential clients should be able to use alternative auth methods, >>> not just those that use service accounts). >> Yeah, that seems to be better. I will delete 'Service Account' tab and >> put the option to the 'Settings' . The credentials tab won't be changed >> for now as there are no more supported authentication mechanisms. >>> * I assume currently to set role mappings for the client you'd have to >>> somehow find the associated user? That seems a bit cumbersome to me. We >>> should at the very least add a link, but even better as it's only role >>> mappings we want to configure I think 'service account users' should be >>> hidden from regular users lists and instead we should have a role mappings >>> tab on the client. >> I can add the tab for role mappings, which will point to role mappings >> of the linked user. I agree that will be much better regarding usability. >> >> But for hiding the 'service account user' from the user list, it will >> require changes in the search model methods (like >> UserProvider.searchForUser + maybe >> UserProvider.searchForUserByAttributes ). Do you want me to go that way? > Rather than adding an attribute would it be better to add a flag directly on UserModel/Entity? I wanted to avoid that to minimize model changes :-) But maybe it's best option... Anyway, the UserProvider.searchForUser will be changed to not include users with this flag (or attribute) true. Is it ok? Marek > >> One additional question, does it makes sense to save the 'service >> account user' into federation when it's enabled for the realm? For me, >> rather not, so I can use "session.userStorage()" directly to save this >> user. Thinking if someone may want to have service account saved in LDAP >> including his role mappings, but it's probably just hypothetical usecase... > I'd lean towards not saving in federation at first, then we consider adding if requested. > >> Marek >>> ----- Original Message ----- >>>> From: "Marek Posolda" >>>> To: keycloak-dev at lists.jboss.org >>>> Sent: Wednesday, 22 July, 2015 11:41:34 AM >>>> Subject: [keycloak-dev] Service accounts - version 1 commited >>>> >>>> Few points to how it works now: >>>> >>>> - There is new boolean flag setServiceAccountsEnabled on ClientModel. >>>> That's the only model change >>>> >>>> - There is new tab "Service accounts" for confidential clients in admin >>>> console . Right now, service account authentication is available just >>>> for confidential clients, not bearer-only or public clients. The tab >>>> contains just one on/off switch for enable/disable service account >>>> authentication support. It's disabled by default. I think for the next >>>> release we can add the table with Authentication mechanisms for clients, >>>> so admin can choose for example that Client Credentials Grant is >>>> "DISABLED" and Certificate authentication is "ALTERNATIVE" etc. Right >>>> now, the client authentication is available just through OAuth2 Client >>>> Credentials Grant (authentication with clientId + client secret) >>>> >>>> - When service account enabled for client "foo", new user >>>> "service-account-foo" is created . I've added the "service-account-" >>>> prefix just to make more visible that this is not normal user, but user >>>> dedicated to service account. The user has also attribute with client DB >>>> ID (It's really DB ID, not clientId) and the binding between client and >>>> user is through this attribute. Hence when admin renames clientId of >>>> this client or renames the username of service account user, the binding >>>> still works. The roles available to this user are used in the token >>>> dedicated to service account. >>>> >>>> - The existing TokenEndpoint is reused for service account >>>> authentication. Just new grantType "client_credentials" is added as per >>>> OAuth2 specs. >>>> >>>> - The token retrieved through service account has few additional >>>> attributes available in otherClaims(). Those are added by protocol >>>> mappers, which are created when service account authentication is >>>> enabled. Right now, it's just clientID, clientHost and client address >>>> (host and address are retrieved dynamically from ClientConnection used >>>> during auth request to TokenEndpoint). Should we have more info >>>> available in service account access token? >>>> >>>> - Sample app "service-account-example" added to the demo >>>> >>>> - Only missing piece for the 1.4 release seems to be docs unless you >>>> have additional feedback. >>>> >>>> WDYT? >>>> >>>> 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 Jul 22 11:23:33 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 22 Jul 2015 11:23:33 -0400 (EDT) Subject: [keycloak-dev] Service accounts - version 1 commited In-Reply-To: <55AFA8F9.3060507@redhat.com> References: <55AF654E.5060800@redhat.com> <839864171.2645633.1437564726842.JavaMail.zimbra@redhat.com> <55AFA102.1000102@redhat.com> <877038106.2759930.1437574884245.JavaMail.zimbra@redhat.com> <55AFA8F9.3060507@redhat.com> Message-ID: <1012233293.2797906.1437578613366.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Marek Posolda" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Wednesday, 22 July, 2015 4:30:17 PM > Subject: Re: [keycloak-dev] Service accounts - version 1 commited > > On 22.7.2015 16:21, Stian Thorgersen wrote: > > > > ----- Original Message ----- > >> From: "Marek Posolda" > >> To: "Stian Thorgersen" > >> Cc: keycloak-dev at lists.jboss.org > >> Sent: Wednesday, 22 July, 2015 3:56:18 PM > >> Subject: Re: [keycloak-dev] Service accounts - version 1 commited > >> > >> On 22.7.2015 13:32, Stian Thorgersen wrote: > >>> A few comments: > >>> > >>> * Do we need the ''Service Account' tab? It seems the enable/disable > >>> option > >>> should be on the 'Settings' tab in either case. We already have tab for > >>> 'Credentials' which is where alternative auth methods should be > >>> configured > >>> (all confidential clients should be able to use alternative auth methods, > >>> not just those that use service accounts). > >> Yeah, that seems to be better. I will delete 'Service Account' tab and > >> put the option to the 'Settings' . The credentials tab won't be changed > >> for now as there are no more supported authentication mechanisms. > >>> * I assume currently to set role mappings for the client you'd have to > >>> somehow find the associated user? That seems a bit cumbersome to me. We > >>> should at the very least add a link, but even better as it's only role > >>> mappings we want to configure I think 'service account users' should be > >>> hidden from regular users lists and instead we should have a role > >>> mappings > >>> tab on the client. > >> I can add the tab for role mappings, which will point to role mappings > >> of the linked user. I agree that will be much better regarding usability. > >> > >> But for hiding the 'service account user' from the user list, it will > >> require changes in the search model methods (like > >> UserProvider.searchForUser + maybe > >> UserProvider.searchForUserByAttributes ). Do you want me to go that way? > > Rather than adding an attribute would it be better to add a flag directly > > on UserModel/Entity? > I wanted to avoid that to minimize model changes :-) > > But maybe it's best option... Anyway, the UserProvider.searchForUser > will be changed to not include users with this flag (or attribute) true. > Is it ok? +1 > > Marek > > > >> One additional question, does it makes sense to save the 'service > >> account user' into federation when it's enabled for the realm? For me, > >> rather not, so I can use "session.userStorage()" directly to save this > >> user. Thinking if someone may want to have service account saved in LDAP > >> including his role mappings, but it's probably just hypothetical > >> usecase... > > I'd lean towards not saving in federation at first, then we consider adding > > if requested. > > > >> Marek > >>> ----- Original Message ----- > >>>> From: "Marek Posolda" > >>>> To: keycloak-dev at lists.jboss.org > >>>> Sent: Wednesday, 22 July, 2015 11:41:34 AM > >>>> Subject: [keycloak-dev] Service accounts - version 1 commited > >>>> > >>>> Few points to how it works now: > >>>> > >>>> - There is new boolean flag setServiceAccountsEnabled on ClientModel. > >>>> That's the only model change > >>>> > >>>> - There is new tab "Service accounts" for confidential clients in admin > >>>> console . Right now, service account authentication is available just > >>>> for confidential clients, not bearer-only or public clients. The tab > >>>> contains just one on/off switch for enable/disable service account > >>>> authentication support. It's disabled by default. I think for the next > >>>> release we can add the table with Authentication mechanisms for clients, > >>>> so admin can choose for example that Client Credentials Grant is > >>>> "DISABLED" and Certificate authentication is "ALTERNATIVE" etc. Right > >>>> now, the client authentication is available just through OAuth2 Client > >>>> Credentials Grant (authentication with clientId + client secret) > >>>> > >>>> - When service account enabled for client "foo", new user > >>>> "service-account-foo" is created . I've added the "service-account-" > >>>> prefix just to make more visible that this is not normal user, but user > >>>> dedicated to service account. The user has also attribute with client DB > >>>> ID (It's really DB ID, not clientId) and the binding between client and > >>>> user is through this attribute. Hence when admin renames clientId of > >>>> this client or renames the username of service account user, the binding > >>>> still works. The roles available to this user are used in the token > >>>> dedicated to service account. > >>>> > >>>> - The existing TokenEndpoint is reused for service account > >>>> authentication. Just new grantType "client_credentials" is added as per > >>>> OAuth2 specs. > >>>> > >>>> - The token retrieved through service account has few additional > >>>> attributes available in otherClaims(). Those are added by protocol > >>>> mappers, which are created when service account authentication is > >>>> enabled. Right now, it's just clientID, clientHost and client address > >>>> (host and address are retrieved dynamically from ClientConnection used > >>>> during auth request to TokenEndpoint). Should we have more info > >>>> available in service account access token? > >>>> > >>>> - Sample app "service-account-example" added to the demo > >>>> > >>>> - Only missing piece for the 1.4 release seems to be docs unless you > >>>> have additional feedback. > >>>> > >>>> 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 Jul 22 14:50:04 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 22 Jul 2015 14:50:04 -0400 Subject: [keycloak-dev] brute force improved Message-ID: <55AFE5DC.20606@redhat.com> we finally have some unit tests for it (my bad). You can also unlock a locked user, or unlock all users too. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From srossillo at smartling.com Wed Jul 22 21:35:16 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Wed, 22 Jul 2015 21:35:16 -0400 Subject: [keycloak-dev] Username Inconsistencies Message-ID: When users have signed up via username and password, their username is their email address. However, if they first sign up via a social provider, they get a username of provider.email_address. Seems inconsistent. A user with a username and password who then logs in via a social provider retains just their email as the username. The username should never contain the provider, IMO. This is happening on 1.2.x. Has this been fixed in master? If so, is there an easy way to back port the fix? Thanks, Scott From bburke at redhat.com Wed Jul 22 22:25:20 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 22 Jul 2015 22:25:20 -0400 Subject: [keycloak-dev] Username Inconsistencies In-Reply-To: References: Message-ID: <55B05090.2010308@redhat.com> Doesn't 1.2.x have a way to map the username? On 7/22/2015 9:35 PM, Scott Rossillo wrote: > When users have signed up via username and password, their username is their email address. However, if they first sign up via a social provider, they get a username of provider.email_address. Seems inconsistent. A user with a username and password who then logs in via a social provider retains just their email as the username. > > The username should never contain the provider, IMO. This is happening on 1.2.x. Has this been fixed in master? If so, is there an easy way to back port the fix? > > Thanks, > 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 ornot2008 at yahoo.com Thu Jul 23 08:12:07 2015 From: ornot2008 at yahoo.com (Mai Zi) Date: Thu, 23 Jul 2015 12:12:07 +0000 (UTC) Subject: [keycloak-dev] Is it possible to complete a login process with program ? Message-ID: <2011143159.1109342.1437653527153.JavaMail.yahoo@mail.yahoo.com> Hi, there,? I am new in this domain so pls help me even my question looks too naive.? What I want to do is as below: 1) Add a user with RESTful ?API .?2) get the token with direct access grant . All above will happen with ?program.? We can add a user , but ?can not get the token . It seems the user can not ?login in .? We missed something ? Is there any example code ? Thanks in advance.? Mai -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150723/39935b27/attachment.html From stian at redhat.com Thu Jul 23 08:20:43 2015 From: stian at redhat.com (Stian Thorgersen) Date: Thu, 23 Jul 2015 08:20:43 -0400 (EDT) Subject: [keycloak-dev] Is it possible to complete a login process with program ? In-Reply-To: <2011143159.1109342.1437653527153.JavaMail.yahoo@mail.yahoo.com> References: <2011143159.1109342.1437653527153.JavaMail.yahoo@mail.yahoo.com> Message-ID: <550064274.3370566.1437654043389.JavaMail.zimbra@redhat.com> Please use user mailing list for support questions ----- Original Message ----- > From: "Mai Zi" > To: keycloak-dev at lists.jboss.org > Sent: Thursday, 23 July, 2015 2:12:07 PM > Subject: [keycloak-dev] Is it possible to complete a login process with program ? > > Hi, there, > > I am new in this domain so pls help me even my question looks too naive. > > > What I want to do is as below: > > 1) Add a user with RESTful API . > 2) get the token with direct access grant . > > > All above will happen with program. > > We can add a user , but can not get the token . It seems the user can not > login in . > > We missed something ? > > Is there any example code ? > > > Thanks in advance. > > > Mai > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Thu Jul 23 11:16:23 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 23 Jul 2015 11:16:23 -0400 Subject: [keycloak-dev] timeouts Message-ID: <55B10547.4070205@redhat.com> Was thinking about this more and I think it might be ok to have a session cookie that has all the initial information needed to restore the client session and restart the login without having to redirect back to the client. The session cookie would match up against the code query param that is passed around. This would probably be good enough protection. Only thing an attacker would be able to do is restart the login. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Fri Jul 24 03:14:55 2015 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 24 Jul 2015 03:14:55 -0400 (EDT) Subject: [keycloak-dev] timeouts In-Reply-To: <55B10547.4070205@redhat.com> References: <55B10547.4070205@redhat.com> Message-ID: <717662370.3884901.1437722095323.JavaMail.zimbra@redhat.com> +1 I can't see why basically just saving the initial request from the client is a problem - sounds like it would be a proper solution to the problem ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Thursday, 23 July, 2015 5:16:23 PM > Subject: [keycloak-dev] timeouts > > Was thinking about this more and I think it might be ok to have a > session cookie that has all the initial information needed to restore > the client session and restart the login without having to redirect back > to the client. The session cookie would match up against the code query > param that is passed around. This would probably be good enough > protection. Only thing an attacker would be able to do is restart the > login. > > -- > 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 Sat Jul 25 12:50:42 2015 From: bburke at redhat.com (Bill Burke) Date: Sat, 25 Jul 2015 12:50:42 -0400 Subject: [keycloak-dev] timeouts In-Reply-To: <717662370.3884901.1437722095323.JavaMail.zimbra@redhat.com> References: <55B10547.4070205@redhat.com> <717662370.3884901.1437722095323.JavaMail.zimbra@redhat.com> Message-ID: <55B3BE62.2090501@redhat.com> I implemented this as a JWS with hmac256 of the realm's secret code. It stores the client session as json based on whatever it is at the start of authentication process. This is about 700 bytes in size. combine this with our other cookies, I think we are still well below the 4k max on per domain total cookie size. You will also get a message "You took too long to login. Login process starting from beginning." I know some people were complaining that you have to enter in your username/password twice, but IMO, there's no way around this at this time without reworking the auth spi significantly. I'm not sure if it is even possible yet. On 7/24/2015 3:14 AM, Stian Thorgersen wrote: > +1 I can't see why basically just saving the initial request from the client is a problem - sounds like it would be a proper solution to the problem > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Thursday, 23 July, 2015 5:16:23 PM >> Subject: [keycloak-dev] timeouts >> >> Was thinking about this more and I think it might be ok to have a >> session cookie that has all the initial information needed to restore >> the client session and restart the login without having to redirect back >> to the client. The session cookie would match up against the code query >> param that is passed around. This would probably be good enough >> protection. Only thing an attacker would be able to do is restart the >> login. >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Sat Jul 25 12:57:13 2015 From: bburke at redhat.com (Bill Burke) Date: Sat, 25 Jul 2015 12:57:13 -0400 Subject: [keycloak-dev] defaults for user session storage Message-ID: <55B3BFE9.10703@redhat.com> For our testsuite and for the distro, I'd like to make infinispan the default storage as this will probably be the most used solution. This also means we need to make sure replication is set up to be secured/encrypted by default. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Sun Jul 26 09:31:18 2015 From: bburke at redhat.com (Bill Burke) Date: Sun, 26 Jul 2015 09:31:18 -0400 Subject: [keycloak-dev] i'll take a look at infinispan/mongo failures Message-ID: <55B4E126.3050802@redhat.com> -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Mon Jul 27 01:48:28 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 27 Jul 2015 01:48:28 -0400 (EDT) Subject: [keycloak-dev] timeouts In-Reply-To: <55B3BE62.2090501@redhat.com> References: <55B10547.4070205@redhat.com> <717662370.3884901.1437722095323.JavaMail.zimbra@redhat.com> <55B3BE62.2090501@redhat.com> Message-ID: <1411905990.409653.1437976108493.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Saturday, 25 July, 2015 6:50:42 PM > Subject: Re: [keycloak-dev] timeouts > > I implemented this as a JWS with hmac256 of the realm's secret code. It > stores the client session as json based on whatever it is at the start > of authentication process. This is about 700 bytes in size. combine > this with our other cookies, I think we are still well below the 4k max > on per domain total cookie size. > > You will also get a message "You took too long to login. Login process > starting from beginning." > > I know some people were complaining that you have to enter in your > username/password twice, but IMO, there's no way around this at this > time without reworking the auth spi significantly. I'm not sure if it > is even possible yet. I think what we have now is the best trade-off considering usability and security, so IMO problem is solved now. > > On 7/24/2015 3:14 AM, Stian Thorgersen wrote: > > +1 I can't see why basically just saving the initial request from the > > client is a problem - sounds like it would be a proper solution to the > > problem > > > > ----- Original Message ----- > >> From: "Bill Burke" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Thursday, 23 July, 2015 5:16:23 PM > >> Subject: [keycloak-dev] timeouts > >> > >> Was thinking about this more and I think it might be ok to have a > >> session cookie that has all the initial information needed to restore > >> the client session and restart the login without having to redirect back > >> to the client. The session cookie would match up against the code query > >> param that is passed around. This would probably be good enough > >> protection. Only thing an attacker would be able to do is restart the > >> login. > >> > >> -- > >> Bill Burke > >> JBoss, a division of Red Hat > >> http://bill.burkecentral.com > >> _______________________________________________ > >> keycloak-dev mailing list > >> keycloak-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > From stian at redhat.com Mon Jul 27 01:56:27 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 27 Jul 2015 01:56:27 -0400 (EDT) Subject: [keycloak-dev] defaults for user session storage In-Reply-To: <55B3BFE9.10703@redhat.com> References: <55B3BFE9.10703@redhat.com> Message-ID: <302331826.410748.1437976587720.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Saturday, 25 July, 2015 6:57:13 PM > Subject: [keycloak-dev] defaults for user session storage > > For our testsuite and for the distro, I'd like to make infinispan the > default storage as this will probably be the most used solution. This > also means we need to make sure replication is set up to be > secured/encrypted by default. +1 We should delete the in-mem cache and only keep the Infinispan cache. We could even remove the no cache option and just always use Infinispan. I don't think replication needs to be encrypted by default. We don't send anything sensitive as we're just using an invalidation cache. So no realm keys, etc are transmitted. In either case the database connection is in most cases not encrypted so these things are actually being sent on the local network. > > -- > 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 Jul 27 02:42:21 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 27 Jul 2015 02:42:21 -0400 (EDT) Subject: [keycloak-dev] defaults for user session storage In-Reply-To: <302331826.410748.1437976587720.JavaMail.zimbra@redhat.com> References: <55B3BFE9.10703@redhat.com> <302331826.410748.1437976587720.JavaMail.zimbra@redhat.com> Message-ID: <707111397.421639.1437979341669.JavaMail.zimbra@redhat.com> https://issues.jboss.org/browse/KEYCLOAK-1702 https://issues.jboss.org/browse/KEYCLOAK-1703 ----- Original Message ----- > From: "Stian Thorgersen" > To: "Bill Burke" > Cc: keycloak-dev at lists.jboss.org > Sent: Monday, 27 July, 2015 7:56:27 AM > Subject: Re: [keycloak-dev] defaults for user session storage > > > > ----- Original Message ----- > > From: "Bill Burke" > > To: keycloak-dev at lists.jboss.org > > Sent: Saturday, 25 July, 2015 6:57:13 PM > > Subject: [keycloak-dev] defaults for user session storage > > > > For our testsuite and for the distro, I'd like to make infinispan the > > default storage as this will probably be the most used solution. This > > also means we need to make sure replication is set up to be > > secured/encrypted by default. > > +1 We should delete the in-mem cache and only keep the Infinispan cache. We > could even remove the no cache option and just always use Infinispan. > > I don't think replication needs to be encrypted by default. We don't send > anything sensitive as we're just using an invalidation cache. So no realm > keys, etc are transmitted. In either case the database connection is in most > cases not encrypted so these things are actually being sent on the local > network. > > > > > -- > > Bill Burke > > JBoss, a division of Red Hat > > http://bill.burkecentral.com > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From stian at redhat.com Mon Jul 27 03:58:47 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 27 Jul 2015 03:58:47 -0400 (EDT) Subject: [keycloak-dev] i'll take a look at infinispan/mongo failures In-Reply-To: <55B4E126.3050802@redhat.com> References: <55B4E126.3050802@redhat.com> Message-ID: <1220014446.455246.1437983927204.JavaMail.zimbra@redhat.com> Mongo is passing. Fixed Infinispan issue: https://github.com/keycloak/keycloak/commit/c7915fa95dc6fac505b783ab4529b765071a83e6 ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Sunday, 26 July, 2015 3:31:18 PM > Subject: [keycloak-dev] i'll take a look at infinispan/mongo failures > > > -- > 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 lars.frauenrath at traveltainment.de Mon Jul 27 04:16:30 2015 From: lars.frauenrath at traveltainment.de (Lars Frauenrath) Date: Mon, 27 Jul 2015 08:16:30 +0000 Subject: [keycloak-dev] Securing wars via keycloak subsystem Message-ID: <24A96690C67C15499D588133A8985E2109FF2428@EX-TT-AC-01.traveltainment.int> Hey guys, as the subject says I want to secure my war files via keycloak subsystem. I use an wildfly 8 server in standalone mode and got the following configuration from the keycloak admin console (by now I configured keycloak with keycloak.json): " TOMAMappingConfigurationService TOMAMappingConfigurationService true true MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAioI1Q9NTQ+FB/6nFRl6QXqjoNNHld8K8KgdL9xhDJtAOn2jhY9/sfQASs5heBWh9IQeVlYFkhmN5jYzKtPMLZnlMTW6fE4yTRSw5RdbGldgX8LedFAt5vSU2rVJWMkExDynDe8zHNbMKvereFeTQ3oDqEA/Ks22fUdmf2Pj+Cpzuj+ncyRYSut02MTGpQML9975D+1z5AmlokkWlk+VADjZ/3zberEJS8I49uQryqtC6OtxayVezEj270Iwx9lwmRIa2aoJZGQRncafW0Dukgx+lAxJinjiSR0UngTXwQXw1OfH9xfi7v6oHcrmExp4xahKom+cW9MyhCL51ElJi4QIDAQAB http://localhost:8080/auth EXTERNAL " As in the documentation described I deleted the keycloak.json files and the part of the web.xml file where keycloak as authentication method is defined. Now I have the problem, that keycloak seems not to be deployed. I cannot access the admin console or login to my application because of an "404 - Not found"-Error. Any ideas what I did wrong? PS: Excuse my English. :) Kind regards, Lars -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150727/56bf4892/attachment-0001.html From stian at redhat.com Mon Jul 27 05:46:51 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 27 Jul 2015 05:46:51 -0400 (EDT) Subject: [keycloak-dev] Testing today, release tomorrow In-Reply-To: <1508838274.535297.1437990283423.JavaMail.zimbra@redhat.com> Message-ID: <261600209.541374.1437990411141.JavaMail.zimbra@redhat.com> All, We've started testing for 1.4.0 release. If everything goes smoothly I aim to release tomorrow. Only outstanding issues are: * KEYCLOAK-1543 reset-password-email ignores redirect_uri - can we reject this Stan? * KEYCLOAK-1455 remove user.isTotp() usage - can we postpone to 1.5? * KEYCLOAK-1698 Make SAML Signature CanonicalizationMethod configurable - I assume this is a minor change and will be added today? If not we should postpone to 1.5 Anything else that needs to be sorted before release? Let me know asap! From lars.frauenrath at traveltainment.de Mon Jul 27 09:25:19 2015 From: lars.frauenrath at traveltainment.de (Lars Frauenrath) Date: Mon, 27 Jul 2015 13:25:19 +0000 Subject: [keycloak-dev] Topic 10: Edit: Securing wars via keycloak subsystem Message-ID: <24A96690C67C15499D588133A8985E2109FF44B3@EX-TT-AC-01.traveltainment.int> Hi, I could resolve a part of my problem and can access the admin console now but have no access to the application. At the moment I get 2 different errors. 1. 404 - Not found 2. 403 - Forbidden (this occurred when I add " keycloak.config.resolver org.keycloak.adapters.KeycloakConfigResolver " to my web.xml file) These errors occurred when I want to login to my application. But, before the login page loads the error occurres, so I hadn't the chance to login anyway. I configured the following things: 1. Unziped keycloak-overlay-1.2.0.Final in Wildfly directory 2. Added keycloak extension to wildfly 8 3. Added security-domain to security subsystem 4. Added the keycloak subsystem: TOMAMappingConfigurationService TOMAMappingConfigurationService true true MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCuJgP4a3CTCYG8Rkg9AoJ58reMmCljx5xc7c6VpqnDHzJ4Gc7JlXYnwUu9dKO8vOWWjRnu7U2WAAjFyDn+xE8UIs1/lkfod6dD83ooT8ehOTyPUMU13956+EKJowgttExnmwyMqWugOLY7RnxwTDwooacJEUJQTqUYGElNeYH5dwIDAQAB http://localhost:8080/auth EXTERNAL password 5. Added security roles and security-constraints to web.xml of my application 6. Added realm, application, roles, users and user-role-mapping within the keycloak administration console 7. Deploy application + keycloak-ds.xml + auth-server.war to the wildfly 8 I hope you can help me. Kind regards, Lars -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150727/9670938d/attachment.html From bburke at redhat.com Mon Jul 27 09:38:01 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 27 Jul 2015 09:38:01 -0400 Subject: [keycloak-dev] Testing today, release tomorrow In-Reply-To: <261600209.541374.1437990411141.JavaMail.zimbra@redhat.com> References: <261600209.541374.1437990411141.JavaMail.zimbra@redhat.com> Message-ID: <55B63439.40808@redhat.com> On 7/27/2015 5:46 AM, Stian Thorgersen wrote: > * KEYCLOAK-1698 Make SAML Signature CanonicalizationMethod configurable - I assume this is a minor change and will be added today? If not we should postpone to 1.5 > I need to put this in for RHT-IT. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Mon Jul 27 09:41:25 2015 From: stian at redhat.com (Stian Thorgersen) Date: Mon, 27 Jul 2015 09:41:25 -0400 (EDT) Subject: [keycloak-dev] Testing today, release tomorrow In-Reply-To: <55B63439.40808@redhat.com> References: <261600209.541374.1437990411141.JavaMail.zimbra@redhat.com> <55B63439.40808@redhat.com> Message-ID: <910032741.717165.1438004485224.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Monday, 27 July, 2015 3:38:01 PM > Subject: Re: [keycloak-dev] Testing today, release tomorrow > > > > On 7/27/2015 5:46 AM, Stian Thorgersen wrote: > > * KEYCLOAK-1698 Make SAML Signature CanonicalizationMethod configurable - I > > assume this is a minor change and will be added today? If not we should > > postpone to 1.5 > > > > I need to put this in for RHT-IT. Is it a big change? Do you have an ETA? > > -- > 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 mstrukel at redhat.com Mon Jul 27 09:59:13 2015 From: mstrukel at redhat.com (Marko Strukelj) Date: Mon, 27 Jul 2015 09:59:13 -0400 (EDT) Subject: [keycloak-dev] Topic 10: Edit: Securing wars via keycloak subsystem In-Reply-To: <24A96690C67C15499D588133A8985E2109FF44B3@EX-TT-AC-01.traveltainment.int> References: <24A96690C67C15499D588133A8985E2109FF44B3@EX-TT-AC-01.traveltainment.int> Message-ID: <1421123550.741733.1438005553495.JavaMail.zimbra@redhat.com> Please use keycloak-user mailing list for usage related questions ... ----- Original Message ----- > > > Hi, > > > > I could resolve a part of my problem and can access the admin console now but > have no access to the application. > > > > At the moment I get 2 different errors. > > 1. 404 ? Not found > > 2. 403 ? Forbidden (this occurred when I add ? > > > > keycloak.config.resolver > > org.keycloak.adapters.KeycloakConfigResolver > > ? > > to my web.xml file) > > > > These errors occurred when I want to login to my application. But, before the > login page loads the error occurres, so I hadn?t the chance to login anyway. > > > > I configured the following things: > > 1. Unziped keycloak-overlay-1.2.0.Final in Wildfly directory > > 2. Added keycloak extension to wildfly 8 > > 3. Added security-domain to security subsystem > > 4. Added the keycloak subsystem: > > > > > > TOMAMappingConfigurationService > > TOMAMappingConfigurationService > > true > > true > > MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCuJgP4a3CTCYG8Rkg9AoJ58reMmCljx5xc7c6VpqnDHzJ4Gc7JlXYnwUu9dKO8vOWWjRnu7U2WAAjFyDn+xE8UIs1/lkfod6dD83ooT8ehOTyPUMU13956+EKJowgttExnmwyMqWugOLY7RnxwTDwooacJEUJQTqUYGElNeYH5dwIDAQAB > > http://localhost:8080/auth > > EXTERNAL > > password > > > > > > 5. Added security roles and security-constraints to web.xml of my application > > 6. Added realm, application, roles, users and user-role-mapping within the > keycloak administration console > > 7. Deploy application + keycloak-ds.xml + auth-server.war to the wildfly 8 > > > > > > I hope you can help me. > > > > Kind regards, > > Lars > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From ssilvert at redhat.com Mon Jul 27 11:26:36 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Mon, 27 Jul 2015 11:26:36 -0400 Subject: [keycloak-dev] Testing today, release tomorrow In-Reply-To: <261600209.541374.1437990411141.JavaMail.zimbra@redhat.com> References: <261600209.541374.1437990411141.JavaMail.zimbra@redhat.com> Message-ID: <55B64DAC.9000807@redhat.com> On 7/27/2015 5:46 AM, Stian Thorgersen wrote: > All, > > We've started testing for 1.4.0 release. If everything goes smoothly I aim to release tomorrow. > > Only outstanding issues are: > > * KEYCLOAK-1543 reset-password-email ignores redirect_uri - can we reject this Stan? I think there was some confusion about what the redirect_uri was supposed to do. I suggested a workaround but I haven't heard back as to whether the workaround worked. I certainly wouldn't hold up the release for this one, but we can wait to make a decision about rejecting it until I do hear back. > * KEYCLOAK-1455 remove user.isTotp() usage - can we postpone to 1.5? > * KEYCLOAK-1698 Make SAML Signature CanonicalizationMethod configurable - I assume this is a minor change and will be added today? If not we should postpone to 1.5 > > Anything else that needs to be sorted before release? Let me know asap! > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From bburke at redhat.com Mon Jul 27 11:59:19 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 27 Jul 2015 11:59:19 -0400 Subject: [keycloak-dev] Testing today, release tomorrow In-Reply-To: <910032741.717165.1438004485224.JavaMail.zimbra@redhat.com> References: <261600209.541374.1437990411141.JavaMail.zimbra@redhat.com> <55B63439.40808@redhat.com> <910032741.717165.1438004485224.JavaMail.zimbra@redhat.com> Message-ID: <55B65557.3050306@redhat.com> On 7/27/2015 9:41 AM, Stian Thorgersen wrote: > > > ----- Original Message ----- >> From: "Bill Burke" >> To: keycloak-dev at lists.jboss.org >> Sent: Monday, 27 July, 2015 3:38:01 PM >> Subject: Re: [keycloak-dev] Testing today, release tomorrow >> >> >> >> On 7/27/2015 5:46 AM, Stian Thorgersen wrote: >>> * KEYCLOAK-1698 Make SAML Signature CanonicalizationMethod configurable - I >>> assume this is a minor change and will be added today? If not we should >>> postpone to 1.5 >>> >> >> I need to put this in for RHT-IT. > > Is it a big change? Do you have an ETA? > travis is running. Fix incoming. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Mon Jul 27 15:36:13 2015 From: bburke at redhat.com (Bill Burke) Date: Mon, 27 Jul 2015 15:36:13 -0400 Subject: [keycloak-dev] travis failing in some arquillian tests? Message-ID: <55B6882D.1090505@redhat.com> Travis build took 40+ minutes to complete in failure. I just merged in my fixes because I think this is a problem with the build itself and not my code. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From srehorn at gmail.com Mon Jul 27 22:12:08 2015 From: srehorn at gmail.com (Scott Rehorn) Date: Mon, 27 Jul 2015 19:12:08 -0700 Subject: [keycloak-dev] RFC: organizations Message-ID: Hello Bill, Stian, and the rest of the keycloak-dev list from Dell Software (software division of Dell Computers). As Bill and Stian already know, our team at Dell has been integrating our own extensions to Keycloak to build a SaaS-based identity broker, and Bill and Stian suggested that we run the first of our main extensions out into the mailing list for further discussion. Here is an overview to solicit some first impressions and additional ideas in this area. We think this extension is necessary for our own use cases, and, if it seems like a broadly useful modification, then we can contribute the code for it. Proposal: introduce a new entity called "organizations" to provide a means of delivering specific claim values to authenticated users known in that organization Rationale: in our group at Dell Software, we have to support the notion of tenancy within a single realm, but we are trying to avoid the term ?tenant? as it?s too overloaded. Our typical use case is to use Keycloak+our extensions as an external system which acts as identity broker for a constrained set of IdPs and claims authority for users. If we use realm-per-organization, then we wind up with a large set of repeated IdP configurations. By introducing an entity for ?organizations? then we have a centralized place to store metadata for users and related client/RP instances. Example: clients A and B are SSO apps which both use KC for authentication and authorization. If a user logs into client A, he is redirected to an IdP (via Keycloak brokering) where he authenticates. After authentication, the user of client A receives in his claimset additional assertions, e.g., subscriptionId=2057 and organizationName=CheeseCompany which are derived from the org definition which says that the authenticated user belongs to Cheese Company under a particular subscription. A different user in a different organization would have a different subscription to and would receive a different subscriptionId and organizationName. Implementation strategy and code impact: our current implementation is derived from the IdentityProviders model and exposes an API only at '/organizations'. We haven?t done the UI level, but it would be similar to the identity providers UX (top-level admin managed item in left menu). Relationship to ?groups?: we think that the concept of organizations is conceptually distinct enough to treat it as a hierarchical construct. An organization can have IdPs and users it recognizes, and such grouping of related clients needing common assertions could be accomplished with groups, but our current thinking is that the groups-everywhere approach is a little too general ? e.g., you **can** simulate relational database semantics with tags and selections based on combinations of tags, but when something is clearly hierarchical, why not use a hierarchy? Groups would be a separate construct could then be treated as tags to enable multiple memberships etc., much like roles are handled in KC now. Thanks for your attention and we look forward to working with you. - scott r -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150727/d6a8e570/attachment.html From stian at redhat.com Tue Jul 28 00:41:55 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 28 Jul 2015 00:41:55 -0400 (EDT) Subject: [keycloak-dev] travis failing in some arquillian tests? In-Reply-To: <55B6882D.1090505@redhat.com> References: <55B6882D.1090505@redhat.com> Message-ID: <1427369629.1067444.1438058515737.JavaMail.zimbra@redhat.com> I've seen this once or twice on Travis that tests just don't complete. There's an option rerun the tests on Travis, which will kill the test in progress and start another one. This shouldn't obviously be the case though and we need to figure out what's going on. ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Monday, 27 July, 2015 9:36:13 PM > Subject: [keycloak-dev] travis failing in some arquillian tests? > > Travis build took 40+ minutes to complete in failure. I just merged in > my fixes because I think this is a problem with the build itself and not > my code. > > -- > 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 juraci at kroehling.de Tue Jul 28 02:12:14 2015 From: juraci at kroehling.de (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Tue, 28 Jul 2015 08:12:14 +0200 Subject: [keycloak-dev] RFC: organizations In-Reply-To: References: Message-ID: <55B71D3E.9030304@kroehling.de> Scott, On 07/28/2015 04:12 AM, Scott Rehorn wrote: > Proposal: introduce a new entity called "organizations" to provide a > means of delivering specific claim values to authenticated users known > in that organization > > Rationale: in our group at Dell Software, we have to support the notion > of tenancy within a single realm, but we are trying to avoid the term > ?tenant? as it?s too overloaded. Our typical use case is to use > Keycloak+our extensions as an external system which acts as identity > broker for a constrained set of IdPs and claims authority for users. If > we use realm-per-organization, then we wind up with a large set of > repeated IdP configurations. By introducing an entity for > ?organizations? then we have a centralized place to store metadata for > users and related client/RP instances. We have a *very* similar use case and we have implemented the notion of "Organizations" (and "Personas") in Hawkular, in a module named "Hawkular Accounts". In our case, an user can belong to multiple organizations, and can have different roles within each organization ("Super User" in "Operations", but "Monitor" on "Marketing"). If our use cases converge, I think we should work together on this. Our code is currently located here and includes some documentation about how it works and what's our use case: https://github.com/hawkular/hawkular-accounts - Juca. From stian at redhat.com Tue Jul 28 03:00:40 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 28 Jul 2015 03:00:40 -0400 (EDT) Subject: [keycloak-dev] RFC: organizations In-Reply-To: References: Message-ID: <1470735792.1165344.1438066840010.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Scott Rehorn" > To: keycloak-dev at lists.jboss.org > Sent: Tuesday, 28 July, 2015 4:12:08 AM > Subject: [keycloak-dev] RFC: organizations > > Hello Bill, Stian, and the rest of the keycloak-dev list from Dell Software > (software division of Dell Computers). > > As Bill and Stian already know, our team at Dell has been integrating our own > extensions to Keycloak to build a SaaS-based identity broker, and Bill and > Stian suggested that we run the first of our main extensions out into the > mailing list for further discussion. Here is an overview to solicit some > first impressions and additional ideas in this area. We think this extension > is necessary for our own use cases, and, if it seems like a broadly useful > modification, then we can contribute the code for it. > > > > Proposal: introduce a new entity called "organizations" to provide a means of > delivering specific claim values to authenticated users known in that > organization > > > > Rationale: in our group at Dell Software, we have to support the notion of > tenancy within a single realm, but we are trying to avoid the term ?tenant? > as it?s too overloaded. Our typical use case is to use Keycloak+our > extensions as an external system which acts as identity broker for a > constrained set of IdPs and claims authority for users. If we use > realm-per-organization, then we wind up with a large set of repeated IdP > configurations. By introducing an entity for ?organizations? then we have a > centralized place to store metadata for users and related client/RP > instances. > > > > Example: clients A and B are SSO apps which both use KC for authentication > and authorization. If a user logs into client A, he is redirected to an IdP > (via Keycloak brokering) where he authenticates. After authentication, the > user of client A receives in his claimset additional assertions, e.g., > subscriptionId=2057 and organizationName=CheeseCompany which are derived > from the org definition which says that the authenticated user belongs to > Cheese Company under a particular subscription. A different user in a > different organization would have a different subscription to and would > receive a different subscriptionId and organizationName > > > > Implementation strategy and code impact: our current implementation is > derived from the IdentityProviders model and exposes an API only at > '/organizations'. We haven?t done the UI level, but it would be similar to > the identity providers UX (top-level admin managed item in left menu). What's '/organizations' used for? If it's to view/configure organizations shouldn't it be contained within the admin endpoints? > > > > Relationship to ?groups?: we think that the concept of organizations is > conceptually distinct enough to treat it as a hierarchical construct. An > organization can have IdPs and users it recognizes, and such grouping of > related clients needing common assertions could be accomplished with groups, > but our current thinking is that the groups-everywhere approach is a little > too general ? e.g., you * can * simulate relational database semantics with > tags and selections based on combinations of tags, but when something is > clearly hierarchical, why not use a hierarchy? Groups would be a separate > construct could then be treated as tags to enable multiple memberships etc., > much like roles are handled in KC now. I don't quite understand how this works. Is the following correct or not: * A realm has one or more organizations * An organization has one or more attributes (key -> value pairs) * A user is associated with one or more organizations * An IdP is associated with one or more organizations Then when a user logs in the attributes available would be the union of: * Attributes from organization associated with IdP (if IdP was used to authenticate) * Attributes from organization associated with user * Attributes from user Further token contains attributes as configured by mappers for client. > > > > > Thanks for your attention and we look forward to working with you. > > > > > - scott r > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Tue Jul 28 03:04:16 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 28 Jul 2015 03:04:16 -0400 (EDT) Subject: [keycloak-dev] RFC: organizations In-Reply-To: <55B71D3E.9030304@kroehling.de> References: <55B71D3E.9030304@kroehling.de> Message-ID: <96541706.1166912.1438067056821.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Juraci Paix?o Kr?hling" > To: keycloak-dev at lists.jboss.org > Sent: Tuesday, 28 July, 2015 8:12:14 AM > Subject: Re: [keycloak-dev] RFC: organizations > > Scott, > On 07/28/2015 04:12 AM, Scott Rehorn wrote: > > Proposal: introduce a new entity called "organizations" to provide a > > means of delivering specific claim values to authenticated users known > > in that organization > > > > Rationale: in our group at Dell Software, we have to support the notion > > of tenancy within a single realm, but we are trying to avoid the term > > ?tenant? as it?s too overloaded. Our typical use case is to use > > Keycloak+our extensions as an external system which acts as identity > > broker for a constrained set of IdPs and claims authority for users. If > > we use realm-per-organization, then we wind up with a large set of > > repeated IdP configurations. By introducing an entity for > > ?organizations? then we have a centralized place to store metadata for > > users and related client/RP instances. > > We have a *very* similar use case and we have implemented the notion of > "Organizations" (and "Personas") in Hawkular, in a module named > "Hawkular Accounts". In our case, an user can belong to multiple > organizations, and can have different roles within each organization > ("Super User" in "Operations", but "Monitor" on "Marketing"). Can you not already model that in Keycloak by having a separate clients for "Operations" and "Marketing" with the corresponding roles? > > If our use cases converge, I think we should work together on this. > > Our code is currently located here and includes some documentation about > how it works and what's our use case: > https://github.com/hawkular/hawkular-accounts > > > - Juca. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From jpkroehling at redhat.com Tue Jul 28 04:18:21 2015 From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Tue, 28 Jul 2015 10:18:21 +0200 Subject: [keycloak-dev] RFC: organizations In-Reply-To: <96541706.1166912.1438067056821.JavaMail.zimbra@redhat.com> References: <55B71D3E.9030304@kroehling.de> <96541706.1166912.1438067056821.JavaMail.zimbra@redhat.com> Message-ID: <55B73ACD.4080708@redhat.com> On 07/28/2015 09:04 AM, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Juraci Paix?o Kr?hling" >> To: keycloak-dev at lists.jboss.org >> Sent: Tuesday, 28 July, 2015 8:12:14 AM >> Subject: Re: [keycloak-dev] RFC: organizations >> >> We have a *very* similar use case and we have implemented the notion of >> "Organizations" (and "Personas") in Hawkular, in a module named >> "Hawkular Accounts". In our case, an user can belong to multiple >> organizations, and can have different roles within each organization >> ("Super User" in "Operations", but "Monitor" on "Marketing"). > > Can you not already model that in Keycloak by having a separate clients for "Operations" and "Marketing" with the corresponding roles? With the current features related to Clients, it might actually be possible. Would it be possible to restrict which users can login with which clients? For instance: - jdoe registers - jdoe creates "Acme, Inc" (and is then super user there) - jsmith registers - jsmith creates "Red Hat, Inc" (and is then super user there) - jdoe invites jsmith to "Acme, Inc" to be "Monitor" there So: - jdoe should never have access to "Red Hat, Inc" - jsmith should have access to: - his "own" resources (not part of any organization) - resources owned by "Acme, Inc" (as Monitor) - resources owned by "Red Hat, Inc" (as Super User). This scenario is the main reason why we have Hawkular Accounts between the individual HK components and Keycloak. With this covered, I think pretty much all of the other use cases can be worked out quite easily. - Juca. From stian at redhat.com Tue Jul 28 04:31:58 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 28 Jul 2015 04:31:58 -0400 (EDT) Subject: [keycloak-dev] RFC: organizations In-Reply-To: <55B73ACD.4080708@redhat.com> References: <55B71D3E.9030304@kroehling.de> <96541706.1166912.1438067056821.JavaMail.zimbra@redhat.com> <55B73ACD.4080708@redhat.com> Message-ID: <2063885814.1221794.1438072318061.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Juraci Paix?o Kr?hling" > To: keycloak-dev at lists.jboss.org > Sent: Tuesday, 28 July, 2015 10:18:21 AM > Subject: Re: [keycloak-dev] RFC: organizations > > On 07/28/2015 09:04 AM, Stian Thorgersen wrote: > > > > ----- Original Message ----- > >> From: "Juraci Paix?o Kr?hling" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Tuesday, 28 July, 2015 8:12:14 AM > >> Subject: Re: [keycloak-dev] RFC: organizations > >> > >> We have a *very* similar use case and we have implemented the notion of > >> "Organizations" (and "Personas") in Hawkular, in a module named > >> "Hawkular Accounts". In our case, an user can belong to multiple > >> organizations, and can have different roles within each organization > >> ("Super User" in "Operations", but "Monitor" on "Marketing"). > > > > Can you not already model that in Keycloak by having a separate clients for > > "Operations" and "Marketing" with the corresponding roles? > > With the current features related to Clients, it might actually be > possible. Would it be possible to restrict which users can login with > which clients? For instance: > > - jdoe registers > - jdoe creates "Acme, Inc" (and is then super user there) > - jsmith registers > - jsmith creates "Red Hat, Inc" (and is then super user there) > - jdoe invites jsmith to "Acme, Inc" to be "Monitor" there > > So: > - jdoe should never have access to "Red Hat, Inc" > - jsmith should have access to: > - his "own" resources (not part of any organization) > - resources owned by "Acme, Inc" (as Monitor) > - resources owned by "Red Hat, Inc" (as Super User). > > This scenario is the main reason why we have Hawkular Accounts between > the individual HK components and Keycloak. With this covered, I think > pretty much all of the other use cases can be worked out quite easily. I'll add a bit to this example: Within a realm there's 4 services (bearer-only clients): * Acme Email Service * Acme Monitor Service * Red Hat Email Service * Red Hat Monitor Service Each client has one or more roles. For example Acme Email and Red Hat email both have view-email, read-email and send-email. To model the above super users you'd add two composite realm roles: * acme-super - add mapping on all roles for Acme Email and Acme Monitor * redhat-super - add mapping on all roles for Red Hat Email and Red Hat Monitor A user can now have a role mapping on acme-super to get all roles for Acme clients, or you can add role mappings to individual roles within each client. That's what you want isn't it? Further you can also utilize scope on applications (confidential for server-side web app, or public for client-side web apps) to limit the roles a application can obtain. For example the HTML5 application 'Acme Email Reader' could either have a scope on all roles within 'Acme Email Service' or 'acme-super'. It should probably not have scope on any roles for 'Red Hat Email'. > > - Juca. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From jpkroehling at redhat.com Tue Jul 28 05:09:04 2015 From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Tue, 28 Jul 2015 11:09:04 +0200 Subject: [keycloak-dev] RFC: organizations In-Reply-To: <2063885814.1221794.1438072318061.JavaMail.zimbra@redhat.com> References: <55B71D3E.9030304@kroehling.de> <96541706.1166912.1438067056821.JavaMail.zimbra@redhat.com> <55B73ACD.4080708@redhat.com> <2063885814.1221794.1438072318061.JavaMail.zimbra@redhat.com> Message-ID: <55B746B0.7060604@redhat.com> On 07/28/2015 10:31 AM, Stian Thorgersen wrote: > I'll add a bit to this example: > > Within a realm there's 4 services (bearer-only clients): > > * Acme Email Service > * Acme Monitor Service > * Red Hat Email Service > * Red Hat Monitor Service Is there a way to have a relationship between Acme Email Service and Acme Monitor Service? Are they different clients? We'd need a stable ID between related services, which would be our "tenant". So, if user jdoe creates a resource in our application while acting as SuperUser for Acme, we have to store this resource with the information that it belongs to Acme, so that users of Red Hat wouldn't have access to it. > Each client has one or more roles. For example Acme Email and Red Hat email both have view-email, read-email and send-email. > > To model the above super users you'd add two composite realm roles: > > * acme-super - add mapping on all roles for Acme Email and Acme Monitor > * redhat-super - add mapping on all roles for Red Hat Email and Red Hat Monitor Meaning that for each new "organization", a new set of roles would have to be duplicated. Basically, acme-super and redhat-super are exactly the same, except for the names. But if I get it right, this is how it would look like: - user jdoe registers, is "super" on the realm itself - user jdoe creates Acme, and is acme-super there, effectively being super on the client - user jsmith creates Red Hat, invites jdoe as "monitor" there - user jdoe is now super on the realm, acme-super on the Acme client and redhat-monitor on the Red Hat client. So, if a request comes in to our backend for jdoe while using the UI as Red Hat, our backend would see only "redhat-monitor" as the role, right? > A user can now have a role mapping on acme-super to get all roles for Acme clients, or you can add role mappings to individual roles within each client. This means that I would be able to be Super User on Acme, but only Monitor on Red Hat, right? > That's what you want isn't it? I think it could work, yes, but that doesn't feel right, to be honest. It seems like we'd be doing some workarounds to implement a concept that doesn't quite exist on Keycloak, which would cause a massive data duplication. For one realm containing two clients and 8 roles each, this seems doable, but for one realm containing 2.000 clients (nested or not) and 8 roles each, that *sounds* like a maintenance/migration/performance nightmare. > Further you can also utilize scope on applications (confidential for server-side web app, or public for client-side web apps) to limit the roles a application can obtain. For example the HTML5 application 'Acme Email Reader' could either have a scope on all roles within 'Acme Email Service' or 'acme-super'. It should probably not have scope on any roles for 'Red Hat Email'. Sounds like a bonus feature, but I don't think this would bring any benefit for us. We have only one frontend and one backend (with several modules). So, the same application available to Acme is available to Red Hat. - Juca. From stian at redhat.com Tue Jul 28 06:08:35 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 28 Jul 2015 06:08:35 -0400 (EDT) Subject: [keycloak-dev] Keycloak spotted in the wild: https://www.smartling.com/ In-Reply-To: <593244250.1260523.1438078110240.JavaMail.zimbra@redhat.com> Message-ID: <1826460468.1260561.1438078115053.JavaMail.zimbra@redhat.com> Keycloak spotted in the wild: https://www.smartling.com/ From ssilvert at redhat.com Tue Jul 28 08:17:33 2015 From: ssilvert at redhat.com (Stan Silvert) Date: Tue, 28 Jul 2015 08:17:33 -0400 Subject: [keycloak-dev] Keycloak spotted in the wild: https://www.smartling.com/ In-Reply-To: <1826460468.1260561.1438078115053.JavaMail.zimbra@redhat.com> References: <1826460468.1260561.1438078115053.JavaMail.zimbra@redhat.com> Message-ID: <55B772DD.6090104@redhat.com> Cool. How did you spot it? On 7/28/2015 6:08 AM, Stian Thorgersen wrote: > Keycloak spotted in the wild: https://www.smartling.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 Jul 28 08:19:14 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 28 Jul 2015 08:19:14 -0400 (EDT) Subject: [keycloak-dev] RFC: organizations In-Reply-To: <55B746B0.7060604@redhat.com> References: <55B71D3E.9030304@kroehling.de> <96541706.1166912.1438067056821.JavaMail.zimbra@redhat.com> <55B73ACD.4080708@redhat.com> <2063885814.1221794.1438072318061.JavaMail.zimbra@redhat.com> <55B746B0.7060604@redhat.com> Message-ID: <191910487.1352110.1438085954399.JavaMail.zimbra@redhat.com> I think we've successfully managed to abstract ourselves completely away from your real requirements ;) Can you start another thread listing your exact requirements? Then we can see if it's possible to model it with existing roles, client roles and composite roles. ----- Original Message ----- > From: "Juraci Paix?o Kr?hling" > To: "Stian Thorgersen" > Cc: keycloak-dev at lists.jboss.org > Sent: Tuesday, 28 July, 2015 11:09:04 AM > Subject: Re: [keycloak-dev] RFC: organizations > > On 07/28/2015 10:31 AM, Stian Thorgersen wrote: > > I'll add a bit to this example: > > > > Within a realm there's 4 services (bearer-only clients): > > > > * Acme Email Service > > * Acme Monitor Service > > * Red Hat Email Service > > * Red Hat Monitor Service > > Is there a way to have a relationship between Acme Email Service and > Acme Monitor Service? Are they different clients? We'd need a stable ID > between related services, which would be our "tenant". So, if user jdoe > creates a resource in our application while acting as SuperUser for > Acme, we have to store this resource with the information that it > belongs to Acme, so that users of Red Hat wouldn't have access to it. > > > Each client has one or more roles. For example Acme Email and Red Hat email > > both have view-email, read-email and send-email. > > > > To model the above super users you'd add two composite realm roles: > > > > * acme-super - add mapping on all roles for Acme Email and Acme Monitor > > * redhat-super - add mapping on all roles for Red Hat Email and Red Hat > > Monitor > > Meaning that for each new "organization", a new set of roles would have > to be duplicated. Basically, acme-super and redhat-super are exactly the > same, except for the names. > > But if I get it right, this is how it would look like: > > - user jdoe registers, is "super" on the realm itself > - user jdoe creates Acme, and is acme-super there, effectively being > super on the client > - user jsmith creates Red Hat, invites jdoe as "monitor" there > - user jdoe is now super on the realm, acme-super on the Acme client and > redhat-monitor on the Red Hat client. > > So, if a request comes in to our backend for jdoe while using the UI as > Red Hat, our backend would see only "redhat-monitor" as the role, right? > > > A user can now have a role mapping on acme-super to get all roles for Acme > > clients, or you can add role mappings to individual roles within each > > client. > > This means that I would be able to be Super User on Acme, but only > Monitor on Red Hat, right? > > > That's what you want isn't it? > > I think it could work, yes, but that doesn't feel right, to be honest. > It seems like we'd be doing some workarounds to implement a concept that > doesn't quite exist on Keycloak, which would cause a massive data > duplication. For one realm containing two clients and 8 roles each, this > seems doable, but for one realm containing 2.000 clients (nested or not) > and 8 roles each, that *sounds* like a maintenance/migration/performance > nightmare. > > > Further you can also utilize scope on applications (confidential for > > server-side web app, or public for client-side web apps) to limit the > > roles a application can obtain. For example the HTML5 application 'Acme > > Email Reader' could either have a scope on all roles within 'Acme Email > > Service' or 'acme-super'. It should probably not have scope on any roles > > for 'Red Hat Email'. > > Sounds like a bonus feature, but I don't think this would bring any > benefit for us. We have only one frontend and one backend (with several > modules). So, the same application available to Acme is available to Red > Hat. > > - Juca. > From stian at redhat.com Tue Jul 28 08:20:22 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 28 Jul 2015 08:20:22 -0400 (EDT) Subject: [keycloak-dev] Keycloak spotted in the wild: https://www.smartling.com/ In-Reply-To: <55B772DD.6090104@redhat.com> References: <1826460468.1260561.1438078115053.JavaMail.zimbra@redhat.com> <55B772DD.6090104@redhat.com> Message-ID: <1768982463.1352551.1438086022864.JavaMail.zimbra@redhat.com> Searched for Keycloak on Bintray ----- Original Message ----- > From: "Stan Silvert" > To: keycloak-dev at lists.jboss.org > Sent: Tuesday, 28 July, 2015 2:17:33 PM > Subject: Re: [keycloak-dev] Keycloak spotted in the wild: https://www.smartling.com/ > > Cool. How did you spot it? > > On 7/28/2015 6:08 AM, Stian Thorgersen wrote: > > Keycloak spotted in the wild: https://www.smartling.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 Tue Jul 28 08:53:57 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 28 Jul 2015 08:53:57 -0400 Subject: [keycloak-dev] Hawkular Re: RFC: organizations In-Reply-To: <55B746B0.7060604@redhat.com> References: <55B71D3E.9030304@kroehling.de> <96541706.1166912.1438067056821.JavaMail.zimbra@redhat.com> <55B73ACD.4080708@redhat.com> <2063885814.1221794.1438072318061.JavaMail.zimbra@redhat.com> <55B746B0.7060604@redhat.com> Message-ID: <55B77B65.3010404@redhat.com> Let's separate this discussion into Hawkular and Dell threads as they are coming at it similar at different angles. We need some type of concept of group and/or organization. But the discussion here is whether or not you can model Hawkular in Keycloak now, as it currently stands: On 7/28/2015 5:09 AM, Juraci Paix?o Kr?hling wrote: > On 07/28/2015 10:31 AM, Stian Thorgersen wrote: >> I'll add a bit to this example: >> >> Within a realm there's 4 services (bearer-only clients): >> >> * Acme Email Service >> * Acme Monitor Service >> * Red Hat Email Service >> * Red Hat Monitor Service > > Is there a way to have a relationship between Acme Email Service and > Acme Monitor Service? Are they different clients? We'd need a stable ID > between related services, which would be our "tenant". So, if user jdoe > creates a resource in our application while acting as SuperUser for > Acme, we have to store this resource with the information that it > belongs to Acme, so that users of Red Hat wouldn't have access to it. > What you could do is store a user attribute that defines the "organizational" metadata. Then a client mapper that maps this metadata into the assertion/claim. Then your application stores the organizational assertion as an attribute of the resource you create in the application's database. >> Each client has one or more roles. For example Acme Email and Red Hat email both have view-email, read-email and send-email. >> >> To model the above super users you'd add two composite realm roles: >> >> * acme-super - add mapping on all roles for Acme Email and Acme Monitor >> * redhat-super - add mapping on all roles for Red Hat Email and Red Hat Monitor > > Meaning that for each new "organization", a new set of roles would have > to be duplicated. Basically, acme-super and redhat-super are exactly the > same, except for the names. > > But if I get it right, this is how it would look like: > > - user jdoe registers, is "super" on the realm itself > - user jdoe creates Acme, and is acme-super there, effectively being > super on the client > - user jsmith creates Red Hat, invites jdoe as "monitor" there > - user jdoe is now super on the realm, acme-super on the Acme client and > redhat-monitor on the Red Hat client. > > So, if a request comes in to our backend for jdoe while using the UI as > Red Hat, our backend would see only "redhat-monitor" as the role, right? > >> A user can now have a role mapping on acme-super to get all roles for Acme clients, or you can add role mappings to individual roles within each client. > > This means that I would be able to be Super User on Acme, but only > Monitor on Red Hat, right? > >> That's what you want isn't it? > > I think it could work, yes, but that doesn't feel right, to be honest. > It seems like we'd be doing some workarounds to implement a concept that > doesn't quite exist on Keycloak, which would cause a massive data > duplication. For one realm containing two clients and 8 roles each, this > seems doable, but for one realm containing 2.000 clients (nested or not) > and 8 roles each, that *sounds* like a maintenance/migration/performance > nightmare. > 1 roles =~ 100 bytes of information 2000 * 8 * 100 = 1.6 meg of data...What's the big deal? Realm/client metadata is all cached too and almost never changes. This is not an issue here. What is the issue is that its a pain in the ass to maintain/migrate things as you would have to manage roles... >> Further you can also utilize scope on applications (confidential for server-side web app, or public for client-side web apps) to limit the roles a application can obtain. For example the HTML5 application 'Acme Email Reader' could either have a scope on all roles within 'Acme Email Service' or 'acme-super'. It should probably not have scope on any roles for 'Red Hat Email'. > > Sounds like a bonus feature, but I don't think this would bring any > benefit for us. We have only one frontend and one backend (with several > modules). So, the same application available to Acme is available to Red > Hat. > Well, your problem makes more sense now. You have one client that manages multiple resources each of which the user could have different permissions. Keycloak also has the concept of "Composite Roles". A composite role is a role that is associated with other roles. So, if a user has a user/role mapping of the composite, they also associatively have a mapping to the related roles. So, you could define a composite role for each organization and associate roles with this composite. Then users can be assigned these composite roles instead of each fine grain role. Honestly though, it sounds like Hawkular might be more dynamic. That resources can be created/destroyed quite often. It might be best to use Keycloak mostly as an authentication mechanisms with only really coarse grain authorization. And to store only basic organizational metadata about the user. Keycloak shouldn't be used as a store for application specific metadata. There's a point where you have to draw the line between an Identity store and an Application store. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Tue Jul 28 08:55:19 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 28 Jul 2015 08:55:19 -0400 Subject: [keycloak-dev] Keycloak spotted in the wild: https://www.smartling.com/ In-Reply-To: <1768982463.1352551.1438086022864.JavaMail.zimbra@redhat.com> References: <1826460468.1260561.1438078115053.JavaMail.zimbra@redhat.com> <55B772DD.6090104@redhat.com> <1768982463.1352551.1438086022864.JavaMail.zimbra@redhat.com> Message-ID: <55B77BB7.8030000@redhat.com> YOU LIE! This is Scott Rosillo's company.... :) On 7/28/2015 8:20 AM, Stian Thorgersen wrote: > Searched for Keycloak on Bintray > > ----- Original Message ----- >> From: "Stan Silvert" >> To: keycloak-dev at lists.jboss.org >> Sent: Tuesday, 28 July, 2015 2:17:33 PM >> Subject: Re: [keycloak-dev] Keycloak spotted in the wild: https://www.smartling.com/ >> >> Cool. How did you spot it? >> >> On 7/28/2015 6:08 AM, Stian Thorgersen wrote: >>> Keycloak spotted in the wild: https://www.smartling.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 > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From stian at redhat.com Tue Jul 28 09:01:44 2015 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 28 Jul 2015 09:01:44 -0400 (EDT) Subject: [keycloak-dev] Keycloak spotted in the wild: https://www.smartling.com/ In-Reply-To: <55B77BB7.8030000@redhat.com> References: <1826460468.1260561.1438078115053.JavaMail.zimbra@redhat.com> <55B772DD.6090104@redhat.com> <1768982463.1352551.1438086022864.JavaMail.zimbra@redhat.com> <55B77BB7.8030000@redhat.com> Message-ID: <1060569917.1373333.1438088504073.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Tuesday, 28 July, 2015 2:55:19 PM > Subject: Re: [keycloak-dev] Keycloak spotted in the wild: https://www.smartling.com/ > > YOU LIE! This is Scott Rosillo's company.... :) I didn't even make the connection - I'm useles! > > On 7/28/2015 8:20 AM, Stian Thorgersen wrote: > > Searched for Keycloak on Bintray > > > > ----- Original Message ----- > >> From: "Stan Silvert" > >> To: keycloak-dev at lists.jboss.org > >> Sent: Tuesday, 28 July, 2015 2:17:33 PM > >> Subject: Re: [keycloak-dev] Keycloak spotted in the wild: > >> https://www.smartling.com/ > >> > >> Cool. How did you spot it? > >> > >> On 7/28/2015 6:08 AM, Stian Thorgersen wrote: > >>> Keycloak spotted in the wild: https://www.smartling.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 > > > > -- > 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 jpkroehling at redhat.com Tue Jul 28 09:57:41 2015 From: jpkroehling at redhat.com (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Tue, 28 Jul 2015 15:57:41 +0200 Subject: [keycloak-dev] Hawkular requirements (was Re: RFC: organizations) In-Reply-To: <191910487.1352110.1438085954399.JavaMail.zimbra@redhat.com> References: <55B71D3E.9030304@kroehling.de> <96541706.1166912.1438067056821.JavaMail.zimbra@redhat.com> <55B73ACD.4080708@redhat.com> <2063885814.1221794.1438072318061.JavaMail.zimbra@redhat.com> <55B746B0.7060604@redhat.com> <191910487.1352110.1438085954399.JavaMail.zimbra@redhat.com> Message-ID: <55B78A55.4040204@redhat.com> Sure. Please, keep in mind that we have two possible deployment scenarios: SaaS and Hosted. For SaaS (and some specific customers on Hosted), we need to have multi tenancy, so, data from one "organization" should be isolated from another. At the same time, we need users from one organization to possibly have access to data from other organizations. Note that we use the same role names and semantics as Wildfly: https://docs.jboss.org/author/display/WFLY9/RBAC Case #1, simplest possible scenario: - a new user registers on Hawkular SaaS and wants to monitor a website. No one else should have access to the metrics collected for this user. Case #2, most complex scenario: - Acme, Inc has several departments: Marketing, Sales and so on. Each one has a small operations team, which is responsible for their day-to-day activities (creating a database, adding an application server, deploying an application, increasing memory, ...). - A member of the Marketing department should not be able to view/manage resources from, say, Sales. - Acme, Inc has a NOC, which is responsible for the 24x7 monitoring. They should have read-only access to metrics from all machines of Acme, Inc, no matter which department. We are currently solving this by having "Hawkular Accounts" to sit between Keycloak and the Hawkular modules (Alerts, Metrics, Inventory, ...) and providing a "Current Persona". This "persona" is a representation of the tenant + the rights that the user has for this tenant. So, the Persona might be an User acting as Monitor on an Organization, or might be an User acting on its own Resources as SuperUser. Permission checking is performed on the business side by the modules, by calling an API which is similar to PicketLink's Permission API. So, we have the following concepts on Hawkular Accounts: - Organization - "Acme, Inc" - Roles - SuperUser - Monitor - Auditor - ... - User - "jmuller" - Persona - "jmuller" - "jmuller" acting as "SuperUser" of "Acme, Inc" - Resource - "virtual-machine-1" - "travel-request-webapp" - Operation - "add-memory" - "monitor-cpu" - "deploy-war" - "read-datasources" - Permission - "SuperUser" can "add-memory" to "virtual-machine-1" - Organization membership - "jmuller" is "SuperUser" on "Acme, Inc" - "Acme, Inc" is "SuperUser" on "Acme Sales" - "Acme NOC" is "Monitor" on "Acme, Inc" On the simplest case (case 1): - User is Persona. So, when the user registers and adds the website to be monitored, the website is owned by the user (ie: SuperUser of Resource is User). On the complex case (case 2): - User jmuller registers and creates the organization "Acme, Inc" and is, therefore, the SuperUser of it. - User jmuller switches the context to "Acme, Inc" on the UI - Acme Sales is created as an Organization inside Acme, Inc (Acme, Inc owns it) - Acme Marketing is created as an Organization inside Acme, Inc (ditto) - Acme NOC is created as an Organization inside Acme, Inc (ditto) - User jmuller invites jdoe to be SuperUser of Acme Sales - User jdoe switches the context to "Acme Sales" on the UI - Acme Sales (via jdoe) creates the host "acme-sales-prod-1" and is the SuperUser of it. - As jdoe is a SuperUser member of Acme Sales, jdoe is therefore SuperUser of "acme-sales-prod-1" - User jmuller invites jsmith to be SuperUser of Acme NOC - Organization Acme NOC is granted Monitor on Acme, Inc - As jsmith is a SuperUser of NOC, but as NOC is only Monitor on Acme, Inc, then jsmith is also only Monitor on Acme Sales. - User jmuller is SuperUser on "Acme, Inc", so, is also a SuperUser of "Acme Sales", "Acme Marketing", "Acme NOC". - User jim creates "Red Hat, Inc", which has no access to Acme, Inc data. When the user jsmith (SuperUser of NOC) selects "Acme Sales" on the Hawkular Accounts switcher, an HTTP header is sent with the request, with the ID of the "Acme Sales" as the Persona-ID. When an operation needs to be done in a resource that is owned by Acme Sales, the relevant Hawkular module asks Hawkular Accounts whether the current persona can perform the Operation on the Resource. On this case, jsmith is only Monitor on Acme Sales, so, if it's a read only operation, the permission is granted. I realize that there are terms which are specific to Hawkular, but I tried to make it as clear as possible for those who have no knowledge of those terms. In case something is not clear, let me know. - Juca. On 07/28/2015 02:19 PM, Stian Thorgersen wrote: > I think we've successfully managed to abstract ourselves completely away from your real requirements ;) > > Can you start another thread listing your exact requirements? Then we can see if it's possible to model it with existing roles, client roles and composite roles. > > ----- Original Message ----- >> From: "Juraci Paix?o Kr?hling" >> To: "Stian Thorgersen" >> Cc: keycloak-dev at lists.jboss.org >> Sent: Tuesday, 28 July, 2015 11:09:04 AM >> Subject: Re: [keycloak-dev] RFC: organizations >> >> On 07/28/2015 10:31 AM, Stian Thorgersen wrote: >>> I'll add a bit to this example: >>> >>> Within a realm there's 4 services (bearer-only clients): >>> >>> * Acme Email Service >>> * Acme Monitor Service >>> * Red Hat Email Service >>> * Red Hat Monitor Service >> >> Is there a way to have a relationship between Acme Email Service and >> Acme Monitor Service? Are they different clients? We'd need a stable ID >> between related services, which would be our "tenant". So, if user jdoe >> creates a resource in our application while acting as SuperUser for >> Acme, we have to store this resource with the information that it >> belongs to Acme, so that users of Red Hat wouldn't have access to it. >> >>> Each client has one or more roles. For example Acme Email and Red Hat email >>> both have view-email, read-email and send-email. >>> >>> To model the above super users you'd add two composite realm roles: >>> >>> * acme-super - add mapping on all roles for Acme Email and Acme Monitor >>> * redhat-super - add mapping on all roles for Red Hat Email and Red Hat >>> Monitor >> >> Meaning that for each new "organization", a new set of roles would have >> to be duplicated. Basically, acme-super and redhat-super are exactly the >> same, except for the names. >> >> But if I get it right, this is how it would look like: >> >> - user jdoe registers, is "super" on the realm itself >> - user jdoe creates Acme, and is acme-super there, effectively being >> super on the client >> - user jsmith creates Red Hat, invites jdoe as "monitor" there >> - user jdoe is now super on the realm, acme-super on the Acme client and >> redhat-monitor on the Red Hat client. >> >> So, if a request comes in to our backend for jdoe while using the UI as >> Red Hat, our backend would see only "redhat-monitor" as the role, right? >> >>> A user can now have a role mapping on acme-super to get all roles for Acme >>> clients, or you can add role mappings to individual roles within each >>> client. >> >> This means that I would be able to be Super User on Acme, but only >> Monitor on Red Hat, right? >> >>> That's what you want isn't it? >> >> I think it could work, yes, but that doesn't feel right, to be honest. >> It seems like we'd be doing some workarounds to implement a concept that >> doesn't quite exist on Keycloak, which would cause a massive data >> duplication. For one realm containing two clients and 8 roles each, this >> seems doable, but for one realm containing 2.000 clients (nested or not) >> and 8 roles each, that *sounds* like a maintenance/migration/performance >> nightmare. >> >>> Further you can also utilize scope on applications (confidential for >>> server-side web app, or public for client-side web apps) to limit the >>> roles a application can obtain. For example the HTML5 application 'Acme >>> Email Reader' could either have a scope on all roles within 'Acme Email >>> Service' or 'acme-super'. It should probably not have scope on any roles >>> for 'Red Hat Email'. >> >> Sounds like a bonus feature, but I don't think this would bring any >> benefit for us. We have only one frontend and one backend (with several >> modules). So, the same application available to Acme is available to Red >> Hat. >> >> - Juca. >> From bburke at redhat.com Tue Jul 28 12:08:05 2015 From: bburke at redhat.com (Bill Burke) Date: Tue, 28 Jul 2015 12:08:05 -0400 Subject: [keycloak-dev] Hawkular requirements (was Re: RFC: organizations) In-Reply-To: <55B78A55.4040204@redhat.com> References: <55B71D3E.9030304@kroehling.de> <96541706.1166912.1438067056821.JavaMail.zimbra@redhat.com> <55B73ACD.4080708@redhat.com> <2063885814.1221794.1438072318061.JavaMail.zimbra@redhat.com> <55B746B0.7060604@redhat.com> <191910487.1352110.1438085954399.JavaMail.zimbra@redhat.com> <55B78A55.4040204@redhat.com> Message-ID: <55B7A8E5.2050308@redhat.com> I think it is appropriate to model resource access separately, outside of Keycloak. The reason for this is basically how SAML/OIDC and single sign in works. It should be: 1. User visits Hawkular 2. User is redirected to Keycloak to login 3. User logins in 4. User is redirected back to Hawkular with a set of assertions If you were using Keycloak to model resource access, then Hawkular would have to continuously hit Keycloak in the background to * create/destroy/modify resource definitions * enable/disable permissions of the user for each resource * verify permissions of the user for each resource I just don't think an authentication server should be used to manage application data. Would you require that a company's LDAP store start storing Hawkular specific metadata to manage all these resources? No. You would not. Which is why I think Keycloak should only be storing things like does this user belong to this group or organization. That's it. Keycloak should not be managing access to the resources of a specific application. On 7/28/2015 9:57 AM, Juraci Paix?o Kr?hling wrote: > Sure. Please, keep in mind that we have two possible deployment > scenarios: SaaS and Hosted. > > For SaaS (and some specific customers on Hosted), we need to have multi > tenancy, so, data from one "organization" should be isolated from > another. At the same time, we need users from one organization to > possibly have access to data from other organizations. > > Note that we use the same role names and semantics as Wildfly: > https://docs.jboss.org/author/display/WFLY9/RBAC > > Case #1, simplest possible scenario: > - a new user registers on Hawkular SaaS and wants to monitor a website. > No one else should have access to the metrics collected for this user. > > Case #2, most complex scenario: > - Acme, Inc has several departments: Marketing, Sales and so on. Each > one has a small operations team, which is responsible for their > day-to-day activities (creating a database, adding an application > server, deploying an application, increasing memory, ...). > - A member of the Marketing department should not be able to view/manage > resources from, say, Sales. > - Acme, Inc has a NOC, which is responsible for the 24x7 monitoring. > They should have read-only access to metrics from all machines of Acme, > Inc, no matter which department. > > > We are currently solving this by having "Hawkular Accounts" to sit > between Keycloak and the Hawkular modules (Alerts, Metrics, Inventory, > ...) and providing a "Current Persona". This "persona" is a > representation of the tenant + the rights that the user has for this > tenant. So, the Persona might be an User acting as Monitor on an > Organization, or might be an User acting on its own Resources as > SuperUser. Permission checking is performed on the business side by the > modules, by calling an API which is similar to PicketLink's Permission API. > > So, we have the following concepts on Hawkular Accounts: > > - Organization > - "Acme, Inc" > > - Roles > - SuperUser > - Monitor > - Auditor > - ... > > - User > - "jmuller" > > - Persona > - "jmuller" > - "jmuller" acting as "SuperUser" of "Acme, Inc" > > - Resource > - "virtual-machine-1" > - "travel-request-webapp" > > - Operation > - "add-memory" > - "monitor-cpu" > - "deploy-war" > - "read-datasources" > > - Permission > - "SuperUser" can "add-memory" to "virtual-machine-1" > > - Organization membership > - "jmuller" is "SuperUser" on "Acme, Inc" > - "Acme, Inc" is "SuperUser" on "Acme Sales" > - "Acme NOC" is "Monitor" on "Acme, Inc" > > > On the simplest case (case 1): > - User is Persona. So, when the user registers and adds the website to > be monitored, the website is owned by the user (ie: SuperUser of > Resource is User). > > On the complex case (case 2): > - User jmuller registers and creates the organization "Acme, Inc" and > is, therefore, the SuperUser of it. > - User jmuller switches the context to "Acme, Inc" on the UI > - Acme Sales is created as an Organization inside Acme, Inc (Acme, Inc > owns it) > - Acme Marketing is created as an Organization inside Acme, Inc (ditto) > - Acme NOC is created as an Organization inside Acme, Inc (ditto) > - User jmuller invites jdoe to be SuperUser of Acme Sales > - User jdoe switches the context to "Acme Sales" on the UI > - Acme Sales (via jdoe) creates the host "acme-sales-prod-1" and is the > SuperUser of it. > - As jdoe is a SuperUser member of Acme Sales, jdoe is therefore > SuperUser of "acme-sales-prod-1" > - User jmuller invites jsmith to be SuperUser of Acme NOC > - Organization Acme NOC is granted Monitor on Acme, Inc > - As jsmith is a SuperUser of NOC, but as NOC is only Monitor on Acme, > Inc, then jsmith is also only Monitor on Acme Sales. > - User jmuller is SuperUser on "Acme, Inc", so, is also a SuperUser of > "Acme Sales", "Acme Marketing", "Acme NOC". > - User jim creates "Red Hat, Inc", which has no access to Acme, Inc data. > > When the user jsmith (SuperUser of NOC) selects "Acme Sales" on the > Hawkular Accounts switcher, an HTTP header is sent with the request, > with the ID of the "Acme Sales" as the Persona-ID. When an operation > needs to be done in a resource that is owned by Acme Sales, the relevant > Hawkular module asks Hawkular Accounts whether the current persona can > perform the Operation on the Resource. On this case, jsmith is only > Monitor on Acme Sales, so, if it's a read only operation, the permission > is granted. > > I realize that there are terms which are specific to Hawkular, but I > tried to make it as clear as possible for those who have no knowledge of > those terms. In case something is not clear, let me know. > > - Juca. > > > On 07/28/2015 02:19 PM, Stian Thorgersen wrote: >> I think we've successfully managed to abstract ourselves completely away from your real requirements ;) >> >> Can you start another thread listing your exact requirements? Then we can see if it's possible to model it with existing roles, client roles and composite roles. >> >> ----- Original Message ----- >>> From: "Juraci Paix?o Kr?hling" >>> To: "Stian Thorgersen" >>> Cc: keycloak-dev at lists.jboss.org >>> Sent: Tuesday, 28 July, 2015 11:09:04 AM >>> Subject: Re: [keycloak-dev] RFC: organizations >>> >>> On 07/28/2015 10:31 AM, Stian Thorgersen wrote: >>>> I'll add a bit to this example: >>>> >>>> Within a realm there's 4 services (bearer-only clients): >>>> >>>> * Acme Email Service >>>> * Acme Monitor Service >>>> * Red Hat Email Service >>>> * Red Hat Monitor Service >>> >>> Is there a way to have a relationship between Acme Email Service and >>> Acme Monitor Service? Are they different clients? We'd need a stable ID >>> between related services, which would be our "tenant". So, if user jdoe >>> creates a resource in our application while acting as SuperUser for >>> Acme, we have to store this resource with the information that it >>> belongs to Acme, so that users of Red Hat wouldn't have access to it. >>> >>>> Each client has one or more roles. For example Acme Email and Red Hat email >>>> both have view-email, read-email and send-email. >>>> >>>> To model the above super users you'd add two composite realm roles: >>>> >>>> * acme-super - add mapping on all roles for Acme Email and Acme Monitor >>>> * redhat-super - add mapping on all roles for Red Hat Email and Red Hat >>>> Monitor >>> >>> Meaning that for each new "organization", a new set of roles would have >>> to be duplicated. Basically, acme-super and redhat-super are exactly the >>> same, except for the names. >>> >>> But if I get it right, this is how it would look like: >>> >>> - user jdoe registers, is "super" on the realm itself >>> - user jdoe creates Acme, and is acme-super there, effectively being >>> super on the client >>> - user jsmith creates Red Hat, invites jdoe as "monitor" there >>> - user jdoe is now super on the realm, acme-super on the Acme client and >>> redhat-monitor on the Red Hat client. >>> >>> So, if a request comes in to our backend for jdoe while using the UI as >>> Red Hat, our backend would see only "redhat-monitor" as the role, right? >>> >>>> A user can now have a role mapping on acme-super to get all roles for Acme >>>> clients, or you can add role mappings to individual roles within each >>>> client. >>> >>> This means that I would be able to be Super User on Acme, but only >>> Monitor on Red Hat, right? >>> >>>> That's what you want isn't it? >>> >>> I think it could work, yes, but that doesn't feel right, to be honest. >>> It seems like we'd be doing some workarounds to implement a concept that >>> doesn't quite exist on Keycloak, which would cause a massive data >>> duplication. For one realm containing two clients and 8 roles each, this >>> seems doable, but for one realm containing 2.000 clients (nested or not) >>> and 8 roles each, that *sounds* like a maintenance/migration/performance >>> nightmare. >>> >>>> Further you can also utilize scope on applications (confidential for >>>> server-side web app, or public for client-side web apps) to limit the >>>> roles a application can obtain. For example the HTML5 application 'Acme >>>> Email Reader' could either have a scope on all roles within 'Acme Email >>>> Service' or 'acme-super'. It should probably not have scope on any roles >>>> for 'Red Hat Email'. >>> >>> Sounds like a bonus feature, but I don't think this would bring any >>> benefit for us. We have only one frontend and one backend (with several >>> modules). So, the same application available to Acme is available to Red >>> Hat. >>> >>> - Juca. >>> > _______________________________________________ > 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 Scott.Rehorn at software.dell.com Tue Jul 28 19:22:38 2015 From: Scott.Rehorn at software.dell.com (Scott Rehorn) Date: Tue, 28 Jul 2015 23:22:38 +0000 Subject: [keycloak-dev] RFC: organizations Message-ID: Comments inline... On 7/28/15, 12:00 AM, "keycloak-dev-bounces at lists.jboss.org on behalf of Stian Thorgersen" wrote: > > >----- Original Message ----- >> From: "Scott Rehorn" >> To: keycloak-dev at lists.jboss.org >> Sent: Tuesday, 28 July, 2015 4:12:08 AM >> Subject: [keycloak-dev] RFC: organizations >> >> Hello Bill, Stian, and the rest of the keycloak-dev list from Dell >>Software >> (software division of Dell Computers). >> >> As Bill and Stian already know, our team at Dell has been integrating >>our own >> extensions to Keycloak to build a SaaS-based identity broker, and Bill >>and >> Stian suggested that we run the first of our main extensions out into >>the >> mailing list for further discussion. Here is an overview to solicit some >> first impressions and additional ideas in this area. We think this >>extension >> is necessary for our own use cases, and, if it seems like a broadly >>useful >> modification, then we can contribute the code for it. >> >> >> >> Proposal: introduce a new entity called "organizations" to provide a >>means of >> delivering specific claim values to authenticated users known in that >> organization >> >> >> >> Rationale: in our group at Dell Software, we have to support the notion >>of >> tenancy within a single realm, but we are trying to avoid the term >>?tenant? >> as it?s too overloaded. Our typical use case is to use Keycloak+our >> extensions as an external system which acts as identity broker for a >> constrained set of IdPs and claims authority for users. If we use >> realm-per-organization, then we wind up with a large set of repeated IdP >> configurations. By introducing an entity for ?organizations? then we >>have a >> centralized place to store metadata for users and related client/RP >> instances. >> >> >> >> Example: clients A and B are SSO apps which both use KC for >>authentication >> and authorization. If a user logs into client A, he is redirected to an >>IdP >> (via Keycloak brokering) where he authenticates. After authentication, >>the >> user of client A receives in his claimset additional assertions, e.g., >> subscriptionId=2057 and organizationName=CheeseCompany which are derived >> from the org definition which says that the authenticated user belongs >>to >> Cheese Company under a particular subscription. A different user in a >> different organization would have a different subscription to and would >> receive a different subscriptionId and organizationName >> >> >> >> Implementation strategy and code impact: our current implementation is >> derived from the IdentityProviders model and exposes an API only at >> '/organizations'. We haven?t done the UI level, but it would be similar >>to >> the identity providers UX (top-level admin managed item in left menu). > >What's '/organizations' used for? If it's to view/configure organizations >shouldn't it be contained within the admin endpoints? My mistake - I was abbreviating implicitly :) - I actually meant that the URL would be more like /auth/admin/organizations. > >> >> >> >> Relationship to ?groups?: we think that the concept of organizations is >> conceptually distinct enough to treat it as a hierarchical construct. An >> organization can have IdPs and users it recognizes, and such grouping of >> related clients needing common assertions could be accomplished with >>groups, >> but our current thinking is that the groups-everywhere approach is a >>little >> too general ? e.g., you * can * simulate relational database semantics >>with >> tags and selections based on combinations of tags, but when something is >> clearly hierarchical, why not use a hierarchy? Groups would be a >>separate >> construct could then be treated as tags to enable multiple memberships >>etc., >> much like roles are handled in KC now. > >I don't quite understand how this works. Is the following correct or not: > >* A realm has one or more organizations >* An organization has one or more attributes (key -> value pairs) >* A user is associated with one or more organizations >* An IdP is associated with one or more organizations > >Then when a user logs in the attributes available would be the union of: > >* Attributes from organization associated with IdP (if IdP was used to >authenticate) >* Attributes from organization associated with user >* Attributes from user > >Further token contains attributes as configured by mappers for client. That?s correct. > >> >> >> >> >> Thanks for your attention and we look forward to working with you. >> >> >> >> >> - scott r >> >> >> >> _______________________________________________ >> 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 harshmahey at msn.com Wed Jul 29 01:27:31 2015 From: harshmahey at msn.com (H Mahey) Date: Tue, 28 Jul 2015 23:27:31 -0600 Subject: [keycloak-dev] Create User with REST API from Java In-Reply-To: References: , , Message-ID: Hi guys,I apologize if i am not suppose to set communication to the whole group like this.I am not able to start a thread in the key cloak forum so am trying this option. I am new to Keycloak and trying to create a user via REST call and i am getting 401 Unauthorized error.So this what i am trying to do1. Start the Keycloak server 2. Create a realm- test-realm and assigned manag-user role to it3. Create user "test-realm-user01" and assigned all the roles i could to him.4. In my java code, i get a token and then i am trying to create a user using that token and it throws 401 Attached is the code of what i am doing. Please let me know if i am doing anything wrong here. (I understand that we should UI from doing all the stuff..but here i am that i want to try this out) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150728/3846c5a9/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: KeyCloakAdminAdapter.java Type: application/octet-stream Size: 6622 bytes Desc: not available Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150728/3846c5a9/attachment.obj From stian at redhat.com Wed Jul 29 02:55:16 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 29 Jul 2015 02:55:16 -0400 (EDT) Subject: [keycloak-dev] Create User with REST API from Java In-Reply-To: References: Message-ID: <2224026.175619.1438152916983.JavaMail.zimbra@redhat.com> Please use user mailing list for support questions: https://lists.jboss.org/mailman/listinfo/keycloak-user ----- Original Message ----- > From: "H Mahey" > To: keycloak-dev at lists.jboss.org > Sent: Wednesday, 29 July, 2015 7:27:31 AM > Subject: [keycloak-dev] Create User with REST API from Java > > Hi guys, > I apologize if i am not suppose to set communication to the whole group like > this. > I am not able to start a thread in the key cloak forum so am trying this > option. > > I am new to Keycloak and trying to create a user via REST call and i am > getting 401 Unauthorized error. > So this what i am trying to do > 1. Start the Keycloak server > 2. Create a realm- test-realm and assigned manag-user role to it > 3. Create user "test-realm-user01" and assigned all the roles i could to him. > 4. In my java code, i get a token and then i am trying to create a user using > that token and it throws 401 > > Attached is the code of what i am doing. > > Please let me know if i am doing anything wrong here. > > (I understand that we should UI from doing all the stuff..but here i am that > i want to try this out) > > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Wed Jul 29 03:05:09 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 29 Jul 2015 03:05:09 -0400 (EDT) Subject: [keycloak-dev] Hawkular requirements (was Re: RFC: organizations) In-Reply-To: <55B7A8E5.2050308@redhat.com> References: <96541706.1166912.1438067056821.JavaMail.zimbra@redhat.com> <55B73ACD.4080708@redhat.com> <2063885814.1221794.1438072318061.JavaMail.zimbra@redhat.com> <55B746B0.7060604@redhat.com> <191910487.1352110.1438085954399.JavaMail.zimbra@redhat.com> <55B78A55.4040204@redhat.com> <55B7A8E5.2050308@redhat.com> Message-ID: <353433249.177920.1438153509233.JavaMail.zimbra@redhat.com> Agree, Keycloak (as an authentication server) should be limited to providing roles (and other claims/attributes, maybe we can groups and even roles within groups). We could look at adding something more of an authorization server (UMA) where a resource provider uses the users token to contact the authorization server to check if a user has a specific permission on a specific resources. It's an interesting challenge and maybe something we can look at in the future, but I think it's going to be mid-end 2016 at least. ----- Original Message ----- > From: "Bill Burke" > To: keycloak-dev at lists.jboss.org > Sent: Tuesday, 28 July, 2015 6:08:05 PM > Subject: Re: [keycloak-dev] Hawkular requirements (was Re: RFC: organizations) > > I think it is appropriate to model resource access separately, outside > of Keycloak. The reason for this is basically how SAML/OIDC and single > sign in works. It should be: > > 1. User visits Hawkular > 2. User is redirected to Keycloak to login > 3. User logins in > 4. User is redirected back to Hawkular with a set of assertions > > If you were using Keycloak to model resource access, then Hawkular would > have to continuously hit Keycloak in the background to > > * create/destroy/modify resource definitions > * enable/disable permissions of the user for each resource > * verify permissions of the user for each resource > > I just don't think an authentication server should be used to manage > application data. Would you require that a company's LDAP store start > storing Hawkular specific metadata to manage all these resources? No. > You would not. Which is why I think Keycloak should only be storing > things like does this user belong to this group or organization. That's > it. Keycloak should not be managing access to the resources of a > specific application. > > On 7/28/2015 9:57 AM, Juraci Paix?o Kr?hling wrote: > > Sure. Please, keep in mind that we have two possible deployment > > scenarios: SaaS and Hosted. > > > > For SaaS (and some specific customers on Hosted), we need to have multi > > tenancy, so, data from one "organization" should be isolated from > > another. At the same time, we need users from one organization to > > possibly have access to data from other organizations. > > > > Note that we use the same role names and semantics as Wildfly: > > https://docs.jboss.org/author/display/WFLY9/RBAC > > > > Case #1, simplest possible scenario: > > - a new user registers on Hawkular SaaS and wants to monitor a website. > > No one else should have access to the metrics collected for this user. > > > > Case #2, most complex scenario: > > - Acme, Inc has several departments: Marketing, Sales and so on. Each > > one has a small operations team, which is responsible for their > > day-to-day activities (creating a database, adding an application > > server, deploying an application, increasing memory, ...). > > - A member of the Marketing department should not be able to view/manage > > resources from, say, Sales. > > - Acme, Inc has a NOC, which is responsible for the 24x7 monitoring. > > They should have read-only access to metrics from all machines of Acme, > > Inc, no matter which department. > > > > > > We are currently solving this by having "Hawkular Accounts" to sit > > between Keycloak and the Hawkular modules (Alerts, Metrics, Inventory, > > ...) and providing a "Current Persona". This "persona" is a > > representation of the tenant + the rights that the user has for this > > tenant. So, the Persona might be an User acting as Monitor on an > > Organization, or might be an User acting on its own Resources as > > SuperUser. Permission checking is performed on the business side by the > > modules, by calling an API which is similar to PicketLink's Permission API. > > > > So, we have the following concepts on Hawkular Accounts: > > > > - Organization > > - "Acme, Inc" > > > > - Roles > > - SuperUser > > - Monitor > > - Auditor > > - ... > > > > - User > > - "jmuller" > > > > - Persona > > - "jmuller" > > - "jmuller" acting as "SuperUser" of "Acme, Inc" > > > > - Resource > > - "virtual-machine-1" > > - "travel-request-webapp" > > > > - Operation > > - "add-memory" > > - "monitor-cpu" > > - "deploy-war" > > - "read-datasources" > > > > - Permission > > - "SuperUser" can "add-memory" to "virtual-machine-1" > > > > - Organization membership > > - "jmuller" is "SuperUser" on "Acme, Inc" > > - "Acme, Inc" is "SuperUser" on "Acme Sales" > > - "Acme NOC" is "Monitor" on "Acme, Inc" > > > > > > On the simplest case (case 1): > > - User is Persona. So, when the user registers and adds the website to > > be monitored, the website is owned by the user (ie: SuperUser of > > Resource is User). > > > > On the complex case (case 2): > > - User jmuller registers and creates the organization "Acme, Inc" and > > is, therefore, the SuperUser of it. > > - User jmuller switches the context to "Acme, Inc" on the UI > > - Acme Sales is created as an Organization inside Acme, Inc (Acme, Inc > > owns it) > > - Acme Marketing is created as an Organization inside Acme, Inc (ditto) > > - Acme NOC is created as an Organization inside Acme, Inc (ditto) > > - User jmuller invites jdoe to be SuperUser of Acme Sales > > - User jdoe switches the context to "Acme Sales" on the UI > > - Acme Sales (via jdoe) creates the host "acme-sales-prod-1" and is the > > SuperUser of it. > > - As jdoe is a SuperUser member of Acme Sales, jdoe is therefore > > SuperUser of "acme-sales-prod-1" > > - User jmuller invites jsmith to be SuperUser of Acme NOC > > - Organization Acme NOC is granted Monitor on Acme, Inc > > - As jsmith is a SuperUser of NOC, but as NOC is only Monitor on Acme, > > Inc, then jsmith is also only Monitor on Acme Sales. > > - User jmuller is SuperUser on "Acme, Inc", so, is also a SuperUser of > > "Acme Sales", "Acme Marketing", "Acme NOC". > > - User jim creates "Red Hat, Inc", which has no access to Acme, Inc data. > > > > When the user jsmith (SuperUser of NOC) selects "Acme Sales" on the > > Hawkular Accounts switcher, an HTTP header is sent with the request, > > with the ID of the "Acme Sales" as the Persona-ID. When an operation > > needs to be done in a resource that is owned by Acme Sales, the relevant > > Hawkular module asks Hawkular Accounts whether the current persona can > > perform the Operation on the Resource. On this case, jsmith is only > > Monitor on Acme Sales, so, if it's a read only operation, the permission > > is granted. > > > > I realize that there are terms which are specific to Hawkular, but I > > tried to make it as clear as possible for those who have no knowledge of > > those terms. In case something is not clear, let me know. > > > > - Juca. > > > > > > On 07/28/2015 02:19 PM, Stian Thorgersen wrote: > >> I think we've successfully managed to abstract ourselves completely away > >> from your real requirements ;) > >> > >> Can you start another thread listing your exact requirements? Then we can > >> see if it's possible to model it with existing roles, client roles and > >> composite roles. > >> > >> ----- Original Message ----- > >>> From: "Juraci Paix?o Kr?hling" > >>> To: "Stian Thorgersen" > >>> Cc: keycloak-dev at lists.jboss.org > >>> Sent: Tuesday, 28 July, 2015 11:09:04 AM > >>> Subject: Re: [keycloak-dev] RFC: organizations > >>> > >>> On 07/28/2015 10:31 AM, Stian Thorgersen wrote: > >>>> I'll add a bit to this example: > >>>> > >>>> Within a realm there's 4 services (bearer-only clients): > >>>> > >>>> * Acme Email Service > >>>> * Acme Monitor Service > >>>> * Red Hat Email Service > >>>> * Red Hat Monitor Service > >>> > >>> Is there a way to have a relationship between Acme Email Service and > >>> Acme Monitor Service? Are they different clients? We'd need a stable ID > >>> between related services, which would be our "tenant". So, if user jdoe > >>> creates a resource in our application while acting as SuperUser for > >>> Acme, we have to store this resource with the information that it > >>> belongs to Acme, so that users of Red Hat wouldn't have access to it. > >>> > >>>> Each client has one or more roles. For example Acme Email and Red Hat > >>>> email > >>>> both have view-email, read-email and send-email. > >>>> > >>>> To model the above super users you'd add two composite realm roles: > >>>> > >>>> * acme-super - add mapping on all roles for Acme Email and Acme Monitor > >>>> * redhat-super - add mapping on all roles for Red Hat Email and Red Hat > >>>> Monitor > >>> > >>> Meaning that for each new "organization", a new set of roles would have > >>> to be duplicated. Basically, acme-super and redhat-super are exactly the > >>> same, except for the names. > >>> > >>> But if I get it right, this is how it would look like: > >>> > >>> - user jdoe registers, is "super" on the realm itself > >>> - user jdoe creates Acme, and is acme-super there, effectively being > >>> super on the client > >>> - user jsmith creates Red Hat, invites jdoe as "monitor" there > >>> - user jdoe is now super on the realm, acme-super on the Acme client and > >>> redhat-monitor on the Red Hat client. > >>> > >>> So, if a request comes in to our backend for jdoe while using the UI as > >>> Red Hat, our backend would see only "redhat-monitor" as the role, right? > >>> > >>>> A user can now have a role mapping on acme-super to get all roles for > >>>> Acme > >>>> clients, or you can add role mappings to individual roles within each > >>>> client. > >>> > >>> This means that I would be able to be Super User on Acme, but only > >>> Monitor on Red Hat, right? > >>> > >>>> That's what you want isn't it? > >>> > >>> I think it could work, yes, but that doesn't feel right, to be honest. > >>> It seems like we'd be doing some workarounds to implement a concept that > >>> doesn't quite exist on Keycloak, which would cause a massive data > >>> duplication. For one realm containing two clients and 8 roles each, this > >>> seems doable, but for one realm containing 2.000 clients (nested or not) > >>> and 8 roles each, that *sounds* like a maintenance/migration/performance > >>> nightmare. > >>> > >>>> Further you can also utilize scope on applications (confidential for > >>>> server-side web app, or public for client-side web apps) to limit the > >>>> roles a application can obtain. For example the HTML5 application 'Acme > >>>> Email Reader' could either have a scope on all roles within 'Acme Email > >>>> Service' or 'acme-super'. It should probably not have scope on any roles > >>>> for 'Red Hat Email'. > >>> > >>> Sounds like a bonus feature, but I don't think this would bring any > >>> benefit for us. We have only one frontend and one backend (with several > >>> modules). So, the same application available to Acme is available to Red > >>> Hat. > >>> > >>> - Juca. > >>> > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev From stian at redhat.com Wed Jul 29 03:19:53 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 29 Jul 2015 03:19:53 -0400 (EDT) Subject: [keycloak-dev] Removal of JPA and Mongo user session providers In-Reply-To: <2050145505.181667.1438154063649.JavaMail.zimbra@redhat.com> Message-ID: <458076099.183431.1438154393372.JavaMail.zimbra@redhat.com> We are planning on removing the JPA and Mongo user session providers. For increased durability for user sessions we highly recommend using a cluster and using a distributed cache with 2 or more owners, or using a replicated cache. We are also going to look at using persistence in Infinispan. The reasoning behind this is that we'd like to focus on creating one really good user session provider based on Infinispan instead of maintaining multiple implementations. From stian at redhat.com Wed Jul 29 03:47:45 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 29 Jul 2015 03:47:45 -0400 (EDT) Subject: [keycloak-dev] Truststores In-Reply-To: <932329188.189378.1438155956632.JavaMail.zimbra@redhat.com> Message-ID: <750984643.190015.1438156065487.JavaMail.zimbra@redhat.com> We need to be able to configure the truststore used by Keycloak when connecting to user federation providers, identity brokers and clients. Ideally this should be achievable through the admin console, but failing that we at least need to document how to create and configure a truststore manually. Further we should probably also use the same truststore for database connections. We should probably introduce a TruststoreSPI? From juraci at kroehling.de Wed Jul 29 03:48:45 2015 From: juraci at kroehling.de (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Wed, 29 Jul 2015 09:48:45 +0200 Subject: [keycloak-dev] Hawkular requirements (was Re: RFC: organizations) In-Reply-To: <55B7A8E5.2050308@redhat.com> References: <55B71D3E.9030304@kroehling.de> <96541706.1166912.1438067056821.JavaMail.zimbra@redhat.com> <55B73ACD.4080708@redhat.com> <2063885814.1221794.1438072318061.JavaMail.zimbra@redhat.com> <55B746B0.7060604@redhat.com> <191910487.1352110.1438085954399.JavaMail.zimbra@redhat.com> <55B78A55.4040204@redhat.com> <55B7A8E5.2050308@redhat.com> Message-ID: <55B8855D.3000905@kroehling.de> On 07/28/2015 06:08 PM, Bill Burke wrote: > I think it is appropriate to model resource access separately, outside > of Keycloak. The reason for this is basically how SAML/OIDC and single > sign in works. It should be: Indeed. Which is basically what we have today. But if Organizations were something that would be implemented in Keycloak, I could focus on Operations/Resources/Permissions, while Organizations/Roles/Users would still be managed by Keycloak. But I'm afraid that our use case is too specific to be useful to the community as a whole, even if we take only the organization part into consideration. - Juca. From stian at redhat.com Wed Jul 29 03:57:00 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 29 Jul 2015 03:57:00 -0400 (EDT) Subject: [keycloak-dev] Hawkular requirements (was Re: RFC: organizations) In-Reply-To: <55B8855D.3000905@kroehling.de> References: <55B73ACD.4080708@redhat.com> <2063885814.1221794.1438072318061.JavaMail.zimbra@redhat.com> <55B746B0.7060604@redhat.com> <191910487.1352110.1438085954399.JavaMail.zimbra@redhat.com> <55B78A55.4040204@redhat.com> <55B7A8E5.2050308@redhat.com> <55B8855D.3000905@kroehling.de> Message-ID: <462637210.192268.1438156620073.JavaMail.zimbra@redhat.com> Can you not just add a realm role to represent an "organization"? ----- Original Message ----- > From: "Juraci Paix?o Kr?hling" > To: keycloak-dev at lists.jboss.org > Sent: Wednesday, 29 July, 2015 9:48:45 AM > Subject: Re: [keycloak-dev] Hawkular requirements (was Re: RFC: organizations) > > On 07/28/2015 06:08 PM, Bill Burke wrote: > > I think it is appropriate to model resource access separately, outside > > of Keycloak. The reason for this is basically how SAML/OIDC and single > > sign in works. It should be: > > Indeed. Which is basically what we have today. But if Organizations were > something that would be implemented in Keycloak, I could focus on > Operations/Resources/Permissions, while Organizations/Roles/Users would > still be managed by Keycloak. But I'm afraid that our use case is too > specific to be useful to the community as a whole, even if we take only > the organization part into consideration. > > - Juca. > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > From stian at redhat.com Wed Jul 29 07:26:54 2015 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 29 Jul 2015 07:26:54 -0400 (EDT) Subject: [keycloak-dev] Keycloak 1.4.0.Final released Message-ID: <2005079436.255171.1438169214154.JavaMail.zimbra@redhat.com> http://blog.keycloak.org/2015/07/keycloak-140final-released.html From gerbermichi at me.com Wed Jul 29 08:05:03 2015 From: gerbermichi at me.com (Michael Gerber) Date: Wed, 29 Jul 2015 12:05:03 +0000 (GMT) Subject: [keycloak-dev] Kerberos with IE does not work Message-ID: <0ffc3f95-04e0-4c52-8955-029cae835c1d@me.com> I could find a solution for my IE problem. IE overwrites the Authorization header in the XMLHttpRequest (/protocol/openid-connect/token) with "Authorization: Negotiate".? To solve this problem, I added on the client the client_id and?client_secret to the form and changed the authorizeClient method, so it checks first the form data instead of the authorization http header. Have a look at my code:? https://github.com/gerbermichi/keycloak/commit/32880b210ed27f782a2f9fcd01da4df21ee0953c Should I create a pull request for the changes or do you have a better solution? cheers Michael Am 22. Juli 2015 um 11:46 schrieb Marek Posolda : Hi Michael, No idea if there is other solution, I've never tried SPNEGO with Internet explorer TBH :( Could you please create JIRA for this? Thanks, Marek On 22.7.2015 10:07, Michael Gerber wrote: Hi all My kerberos configuration works fine with FireFox and Chrome, but it does not work with IE. It shows a prompt where the user has to enter a username and password. I can successfully get an access code, but I can not get an access token, because IE overwrites the?Authorization header in the AJAX request. (see?http://stackoverflow.com/questions/28615850/internet-explorer-11-replaces-authorization-header) I can fix this by adding? document.execCommand('ClearAuthenticationCache', 'false'); above of? var req = new XMLHttpRequest(); approximately at the line 374 in the keycloack.js file. Is there another solution for this problem? cheers Michael _______________________________________________ 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/20150729/83f61473/attachment.html From bburke at redhat.com Wed Jul 29 08:27:07 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 29 Jul 2015 08:27:07 -0400 Subject: [keycloak-dev] Kerberos with IE does not work In-Reply-To: <0ffc3f95-04e0-4c52-8955-029cae835c1d@me.com> References: <0ffc3f95-04e0-4c52-8955-029cae835c1d@me.com> Message-ID: <55B8C69B.4090900@redhat.com> The trick you found earlier doesn't work? http://stackoverflow.com/questions/28615850/internet-explorer-11-replaces-authorization-header Also, what if in keycloak.js if kc.clientSecret is null? Just remove the client secret IMO. You shouldn't be exposing the client secret as it is now public to everybody in the world.... On 7/29/2015 8:05 AM, Michael Gerber wrote: > I could find a solution for my IE problem. > > IE overwrites the Authorization header in the XMLHttpRequest > (/protocol/openid-connect/token) with "Authorization: Negotiate". > > To solve this problem, I added on the client the client_id > and client_secret to the form and changed the authorizeClient method, so > it checks first the form data instead of the authorization http header. > > Have a look at my code: > https://github.com/gerbermichi/keycloak/commit/32880b210ed27f782a2f9fcd01da4df21ee0953c > > Should I create a pull request for the changes or do you have a better > solution? > > cheers > Michael > > > > Am 22. Juli 2015 um 11:46 schrieb Marek Posolda >: > >> Hi Michael, >> >> No idea if there is other solution, I've never tried SPNEGO with >> Internet explorer TBH :( >> >> Could you please create JIRA for this? >> >> Thanks, >> Marek >> >> On 22.7.2015 10:07, Michael Gerber wrote: >>> Hi all >>> >>> My kerberos configuration works fine with FireFox and Chrome, but it >>> does not work with IE. >>> It shows a prompt where the user has to enter a username and password. >>> >>> I can successfully get an access code, but I can not get an access >>> token, because IE overwrites the Authorization header in the AJAX >>> request. (see >>> http://stackoverflow.com/questions/28615850/internet-explorer-11-replaces-authorization-header) >>> >>> I can fix this by adding >>> document.execCommand('ClearAuthenticationCache', 'false'); >>> above of >>> var req = new XMLHttpRequest(); >>> approximately at the line 374 in the keycloack.js file. >>> >>> Is there another solution for this problem? >>> >>> cheers >>> Michael >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Wed Jul 29 08:36:10 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 29 Jul 2015 08:36:10 -0400 Subject: [keycloak-dev] Keycloak 1.4.0.Final released In-Reply-To: <2005079436.255171.1438169214154.JavaMail.zimbra@redhat.com> References: <2005079436.255171.1438169214154.JavaMail.zimbra@redhat.com> Message-ID: <55B8C8BA.2060202@redhat.com> You did not mention clearly and brightly that downloads have been moved off of Sourceforge. On 7/29/2015 7:26 AM, Stian Thorgersen wrote: > http://blog.keycloak.org/2015/07/keycloak-140final-released.html > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Wed Jul 29 08:37:30 2015 From: bburke at redhat.com (Bill Burke) Date: Wed, 29 Jul 2015 08:37:30 -0400 Subject: [keycloak-dev] Downloads moved!!! Message-ID: <55B8C90A.1050705@redhat.com> If you can't find 1.4.0 on sf.net/projects/keycloak that is because downloads have been moved to: keycloak.org/downloads Sourceforge has had massive outages and it is not possible to upload files for weeks now, so all downloads will be from keycloak.org/downloads now. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From gerbermichi at me.com Wed Jul 29 10:37:19 2015 From: gerbermichi at me.com (Michael Gerber) Date: Wed, 29 Jul 2015 14:37:19 +0000 (GMT) Subject: [keycloak-dev] Kerberos with IE does not work Message-ID: <416acc5a-f78d-47dd-b33a-03912d857fcc@me.com> The?ClearAuthenticationCache command deletes the following data: - Session cookies - sessionStorage - HTTP Authentication (e.g. Digest or Basic HTTP credentials) - HTTPS Client Certificates (e.g. sites that use certificates or SmartCards) But keycloak needs the session cookie, otherwise the user has to relogin after each page reload. Isn't the clientSecret anyway public if it is send in the Authorization header?? Am 29. Juli 2015 um 14:27 schrieb Bill Burke : The trick you found earlier doesn't work? http://stackoverflow.com/questions/28615850/internet-explorer-11-replaces-authorization-header Also, what if in keycloak.js if kc.clientSecret is null? Just remove the client secret IMO. You shouldn't be exposing the client secret as it is now public to everybody in the world.... On 7/29/2015 8:05 AM, Michael Gerber wrote: I could find a solution for my IE problem. IE overwrites the Authorization header in the XMLHttpRequest (/protocol/openid-connect/token) with "Authorization: Negotiate". To solve this problem, I added on the client the client_id and client_secret to the form and changed the authorizeClient method, so it checks first the form data instead of the authorization http header. Have a look at my code: https://github.com/gerbermichi/keycloak/commit/32880b210ed27f782a2f9fcd01da4df21ee0953c Should I create a pull request for the changes or do you have a better solution? cheers Michael Am 22. Juli 2015 um 11:46 schrieb Marek Posolda >: Hi Michael, No idea if there is other solution, I've never tried SPNEGO with Internet explorer TBH :( Could you please create JIRA for this? Thanks, Marek On 22.7.2015 10:07, Michael Gerber wrote: Hi all My kerberos configuration works fine with FireFox and Chrome, but it does not work with IE. It shows a prompt where the user has to enter a username and password. I can successfully get an access code, but I can not get an access token, because IE overwrites the Authorization header in the AJAX request. (see http://stackoverflow.com/questions/28615850/internet-explorer-11-replaces-authorization-header) I can fix this by adding document.execCommand('ClearAuthenticationCache', 'false'); above of var req = new XMLHttpRequest(); approximately at the line 374 in the keycloack.js file. Is there another solution for this problem? cheers Michael _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-dev mailing list keycloak-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150729/50cca412/attachment-0001.html From juraci at kroehling.de Thu Jul 30 09:33:48 2015 From: juraci at kroehling.de (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Thu, 30 Jul 2015 15:33:48 +0200 Subject: [keycloak-dev] Hawkular requirements (was Re: RFC: organizations) In-Reply-To: <462637210.192268.1438156620073.JavaMail.zimbra@redhat.com> References: <55B73ACD.4080708@redhat.com> <2063885814.1221794.1438072318061.JavaMail.zimbra@redhat.com> <55B746B0.7060604@redhat.com> <191910487.1352110.1438085954399.JavaMail.zimbra@redhat.com> <55B78A55.4040204@redhat.com> <55B7A8E5.2050308@redhat.com> <55B8855D.3000905@kroehling.de> <462637210.192268.1438156620073.JavaMail.zimbra@redhat.com> Message-ID: <55BA27BC.4040400@kroehling.de> On 07/29/2015 09:57 AM, Stian Thorgersen wrote: > Can you not just add a realm role to represent an "organization"? So, each organization would be a realm? Not sure that would solve the use cases I presented before, specially this part: - As jsmith is a SuperUser of NOC, but as NOC is only Monitor on Acme, Inc, then jsmith is also only Monitor on Acme Sales. I did try to play a bit with this idea a bit locally, but I'm not sure I'm reproducing correctly what you have in mind. - Juca. From bruno at abstractj.org Thu Jul 30 11:37:54 2015 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 30 Jul 2015 12:37:54 -0300 Subject: [keycloak-dev] SAML 2.0 Profile for OAuth 2.0 Message-ID: Good morning, I was playing with SAML and was wondering if we have something close to this RFC (https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-23) implemented or planned. I couldn't find anything related at the documentation and examples. The motivation behind this is the integration of native mobile clients with providers implementing SAML. Thanks in advance. -- -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150730/bfe8d3eb/attachment.html From bburke at redhat.com Thu Jul 30 18:24:30 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 30 Jul 2015 18:24:30 -0400 Subject: [keycloak-dev] Hawkular requirements (was Re: RFC: organizations) In-Reply-To: <55BA27BC.4040400@kroehling.de> References: <55B73ACD.4080708@redhat.com> <2063885814.1221794.1438072318061.JavaMail.zimbra@redhat.com> <55B746B0.7060604@redhat.com> <191910487.1352110.1438085954399.JavaMail.zimbra@redhat.com> <55B78A55.4040204@redhat.com> <55B7A8E5.2050308@redhat.com> <55B8855D.3000905@kroehling.de> <462637210.192268.1438156620073.JavaMail.zimbra@redhat.com> <55BA27BC.4040400@kroehling.de> Message-ID: <55BAA41E.3080904@redhat.com> No, he's saying each organization is a realm-level role. On 7/30/2015 9:33 AM, Juraci Paix?o Kr?hling wrote: > On 07/29/2015 09:57 AM, Stian Thorgersen wrote: >> Can you not just add a realm role to represent an "organization"? > > So, each organization would be a realm? Not sure that would solve the > use cases I presented before, specially this part: > > - As jsmith is a SuperUser of NOC, but as NOC is only Monitor on Acme, > Inc, then jsmith is also only Monitor on Acme Sales. > > I did try to play a bit with this idea a bit locally, but I'm not sure > I'm reproducing correctly what you have in mind. > > - Juca. > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From bburke at redhat.com Thu Jul 30 18:28:35 2015 From: bburke at redhat.com (Bill Burke) Date: Thu, 30 Jul 2015 18:28:35 -0400 Subject: [keycloak-dev] groups vs. organizations Message-ID: <55BAA513.9090009@redhat.com> Scott, I'm trying to wrap my head around how your concept of an organization is different than a group. Wouldn't an organization just be a more stricter form of a group? A group could have any arbitrary roles and attributes associated with it. An organization could too. Is the difference that the organization has a specific common set of attributes? i.e. what's in saml organization descriptors. My thinking is that we'd have both organizations and groups. They would work the same exact way except organization would have some pre-defined attribute types. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com From srossillo at smartling.com Thu Jul 30 19:59:31 2015 From: srossillo at smartling.com (Scott Rossillo) Date: Thu, 30 Jul 2015 23:59:31 +0000 Subject: [keycloak-dev] Keycloak spotted in the wild: https://www.smartling.com/ In-Reply-To: <1060569917.1373333.1438088504073.JavaMail.zimbra@redhat.com> References: <1826460468.1260561.1438078115053.JavaMail.zimbra@redhat.com> <55B772DD.6090104@redhat.com> <1768982463.1352551.1438086022864.JavaMail.zimbra@redhat.com> <55B77BB7.8030000@redhat.com> <1060569917.1373333.1438088504073.JavaMail.zimbra@redhat.com> Message-ID: Funny. :) On Tue, Jul 28, 2015 at 9:02 AM Stian Thorgersen wrote: > > > ----- Original Message ----- > > From: "Bill Burke" > > To: keycloak-dev at lists.jboss.org > > Sent: Tuesday, 28 July, 2015 2:55:19 PM > > Subject: Re: [keycloak-dev] Keycloak spotted in the wild: > https://www.smartling.com/ > > > > YOU LIE! This is Scott Rosillo's company.... :) > > I didn't even make the connection - I'm useles! > > > > > On 7/28/2015 8:20 AM, Stian Thorgersen wrote: > > > Searched for Keycloak on Bintray > > > > > > ----- Original Message ----- > > >> From: "Stan Silvert" > > >> To: keycloak-dev at lists.jboss.org > > >> Sent: Tuesday, 28 July, 2015 2:17:33 PM > > >> Subject: Re: [keycloak-dev] Keycloak spotted in the wild: > > >> https://www.smartling.com/ > > >> > > >> Cool. How did you spot it? > > >> > > >> On 7/28/2015 6:08 AM, Stian Thorgersen wrote: > > >>> Keycloak spotted in the wild: https://www.smartling.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 > > > > > > > -- > > Bill Burke > > JBoss, a division of Red Hat > > http://bill.burkecentral.com > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150730/2fb1c49a/attachment.html From juraci at kroehling.de Fri Jul 31 02:47:53 2015 From: juraci at kroehling.de (=?UTF-8?Q?Juraci_Paix=c3=a3o_Kr=c3=b6hling?=) Date: Fri, 31 Jul 2015 08:47:53 +0200 Subject: [keycloak-dev] Hawkular requirements (was Re: RFC: organizations) In-Reply-To: <55BAA41E.3080904@redhat.com> References: <55B73ACD.4080708@redhat.com> <2063885814.1221794.1438072318061.JavaMail.zimbra@redhat.com> <55B746B0.7060604@redhat.com> <191910487.1352110.1438085954399.JavaMail.zimbra@redhat.com> <55B78A55.4040204@redhat.com> <55B7A8E5.2050308@redhat.com> <55B8855D.3000905@kroehling.de> <462637210.192268.1438156620073.JavaMail.zimbra@redhat.com> <55BA27BC.4040400@kroehling.de> <55BAA41E.3080904@redhat.com> Message-ID: <55BB1A19.5090800@kroehling.de> Sorry, that's what I meant (and how I tested). Replace "realm" with "realm-role" on my previous message. - Juca. On 07/31/2015 12:24 AM, Bill Burke wrote: > No, he's saying each organization is a realm-level role. > > On 7/30/2015 9:33 AM, Juraci Paix?o Kr?hling wrote: >> On 07/29/2015 09:57 AM, Stian Thorgersen wrote: >>> Can you not just add a realm role to represent an "organization"? >> >> So, each organization would be a realm? Not sure that would solve the >> use cases I presented before, specially this part: >> >> - As jsmith is a SuperUser of NOC, but as NOC is only Monitor on Acme, >> Inc, then jsmith is also only Monitor on Acme Sales. >> >> I did try to play a bit with this idea a bit locally, but I'm not sure >> I'm reproducing correctly what you have in mind. >> >> - Juca. >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > From satyajit.das at spire2grow.com Fri Jul 31 03:16:49 2015 From: satyajit.das at spire2grow.com (Satyajit Das) Date: Fri, 31 Jul 2015 12:46:49 +0530 Subject: [keycloak-dev] Securing Rest Services Via KeyCloak Message-ID: Hi Team, I have 2 requirements: 1) I an authenticate y web login to visit my desired page. But after the login I want to have the token to be sent to business layer for further authentication. How can i get the token. 2) I want to secure the rest services. where in , If i make a call to any restful service that produces and consumes jSON format data. Scenario is: I make a call to the restful service. The authentication should kick in. If success i can go ahead and play with other rest services. Any help will be highly appreciated. Regards, Satya. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150731/0feb76f0/attachment.html From bburke at redhat.com Fri Jul 31 07:11:35 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 31 Jul 2015 07:11:35 -0400 Subject: [keycloak-dev] Securing Rest Services Via KeyCloak In-Reply-To: References: Message-ID: <55BB57E7.5070207@redhat.com> Take a look at the customer-app example. It is a web page that displays a list of customers from a REST service. On 7/31/2015 3:16 AM, Satyajit Das wrote: > Hi Team, > > I have 2 requirements: > > 1) I an authenticate y web login to visit my desired page. But after the > login I want to have the token to be sent to business layer for further > authentication. How can i get the token. > > 2) I want to secure the rest services. where in , If i make a call to > any restful service that produces and consumes jSON format data. > > Scenario is: I make a call to the restful service. The authentication > should kick in. If success i can go ahead and play with other rest > services. > > Any help will be highly appreciated. > > Regards, > Satya. > > > _______________________________________________ > 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 Scott.Rehorn at software.dell.com Fri Jul 31 14:42:55 2015 From: Scott.Rehorn at software.dell.com (Scott Rehorn) Date: Fri, 31 Jul 2015 18:42:55 +0000 Subject: [keycloak-dev] groups vs. organizations In-Reply-To: <55BAA513.9090009@redhat.com> References: <55BAA513.9090009@redhat.com> Message-ID: I think it is true that an organization is kind of a special case of a ?group?. We had specific requirements for the concept of what amounted to a single group just to bind a few shared attributes between related relying parties (clients). We decided to deliberately push a group concept for ?later? because there are a bunch of complicating factors with groups. One is that groups are often defined in people?s IdPs (esp. with Active Directory), and the policy for mapping or merging those defs dragged in more complexity than we wanted to do right away. Another is that groups often want to be nested and that?s again more complexity than we were willing to bite off for so simple a function as an org. To answer your specific question about the specific common set of attributes - if I?m following your question, we reluctantly call this ?schema? in that it?s a known, predefined set of attribute keys which can have arbitrary values (and that new attribute keys are not normally added by userland code). We have expectation that defining attributes as enforceable ?schema" (including validation for values) is a feature that will be required for orgs and users but our first cut doesn?t go that far. So I think that while organizations *could* be implemented as a group with special constraints, it would stretch the abstraction a little too far. Normally, I?m a ?turtles-all-the-way-down? kind of guy, but in this case, I think that org (or tenants) is a valuable concept to exist separate from the idea of a group. In fact, it might come down to an implementation style - from the API/UX perspective, presentation of ?orgs? might just be sugar on top of more general graph-style group implementation. On 7/30/15, 3:28 PM, "Bill Burke" wrote: >Scott, > >I'm trying to wrap my head around how your concept of an organization is >different than a group. Wouldn't an organization just be a more >stricter form of a group? A group could have any arbitrary roles and >attributes associated with it. An organization could too. > >Is the difference that the organization has a specific common set of >attributes? i.e. what's in saml organization descriptors. > >My thinking is that we'd have both organizations and groups. They would >work the same exact way except organization would have some pre-defined >attribute types. > >-- >Bill Burke >JBoss, a division of Red Hat >http://bill.burkecentral.com From bburke at redhat.com Fri Jul 31 17:24:47 2015 From: bburke at redhat.com (Bill Burke) Date: Fri, 31 Jul 2015 17:24:47 -0400 Subject: [keycloak-dev] groups vs. organizations In-Reply-To: References: <55BAA513.9090009@redhat.com> Message-ID: <55BBE79F.5090703@redhat.com> On 7/31/2015 2:42 PM, Scott Rehorn wrote: > I think it is true that an organization is kind of a special case of a > ?group?. We had specific requirements for the concept of what amounted to > a single group just to bind a few shared attributes between related > relying parties (clients). We decided to deliberately push a group concept > for ?later? because there are a bunch of complicating factors with groups. > One is that groups are often defined in people?s IdPs (esp. with Active > Directory), and the policy for mapping or merging those defs dragged in > more complexity than we wanted to do right away. Another is that groups > often want to be nested and that?s again more complexity than we were > willing to bite off for so simple a function as an org. > You're going to have to explain what this complication is as it relates to people's IDPs and AD/LDAP. Also, we have already dealt with nesting via Composite Roles in Keycloak so its not that big a deal. Maybe we shouldn't call it a "Group" or an "Organization". Stian floated the idea of calling it a Composite. Maybe that is just too developery/engineery and not Opssy/Sys Adminny enough and we need to have "Group" and "Organization" even though they are the same concept logically? > To answer your specific question about the specific common set of > attributes - if I?m following your question, we reluctantly call this > ?schema? in that it?s a known, predefined set of attribute keys which can > have arbitrary values (and that new attribute keys are not normally added > by userland code). We have expectation that defining attributes as > enforceable ?schema" (including validation for values) is a feature that > will be required for orgs and users but our first cut doesn?t go that far. > Yeah, I guess there would be similar but not necessarily common schema. An organization could be a set of companies who are your customers and would have different metadata than organizations that are a divisions and teams in your own company. One question I have for you guys, is what does it mean for a client to belong to a Dell organization/tenant? What if a broker belongs to an organization? Are they inheriting a set of mappers or something? > So I think that while organizations *could* be implemented as a group with > special constraints, it would stretch the abstraction a little too far. I don't see how an organization implemented as a group would stretch the abstraction too far. They both can have users as members and users would inherit their attributes. Both let their users inherit metadata. Both have arbitrary attribute schemas. While groups and organizations might be different concepts to an admin, logically they work in the same exact way. For example, we used to have a distinction between Applications and OAuth Clients. We merged them because it was just a lot of duplicate code and caused a lot of additional clutter in the UI and the concepts were almost identical. I don't want to create the same situation with Groups and Organizations then have to go back and merge the concepts later on. The most important thing is to have a UI that covers most use cases and that is easy to understand. This means we need to constantly improve and consolidate the UI. Make things simpler. Have intuitive default behavior, and so on. The reason Stian and I founded Keycloak was because we were so sick of how complex security was. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com