From: "Bill Burke" <bburke(a)redhat.com&gt; To: keycloak-dev(a)lists.jboss.org Sent: Wednesday, 11 March, 2015 8:06:04 PM Subject: [keycloak-dev] 1.2.beta1 planning, need you to defer things I'd like to do 1.2.beta1 by end of month or earlier. Please go through the jira list and defer things you are not going to get to in the next 1-2 weeks. Thanks.

I'm going to try and close existing bugs and implement features needed for jboss.org guys over the next 2 weeks as well as test out master to make sure things still work.

Bill -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

From: "Marek Posolda" <mposolda(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt;, "Bill Burke" <bburke(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Thursday, 12 March, 2015 10:48:53 AM Subject: Re: [keycloak-dev] 1.2.beta1 planning, need you to defer things On 12.3.2015 06:40, Stian Thorgersen wrote: > I'd like to reopen KEYCLOAK-311 as IMO it's not solved. This is not > referring to the claim mapping work you've done, it's something else. > > Before we can do a release we need to make sure that database migration > works (I know they don't atm as social providers and social links are > lost). We also need to add transformation of JSON exports and > representations so older versions can be imported into 1.2.0.Beta1. I did migration of social stuff for Mongo but not for jpa/liquibase though. I guess migration of protocol mappers would be needed too? As in 1.1.0.Final accessToken automatically has all the basic claims like username, email etc. So when people migrate to 1.2.0.Beta1, they would expect the same, which means that default builtin mappers for basic claims will need to be added for all the existing clients?

I have also some fear if export/import would work well together with protocol mappers. During import of previously exported application, the import shouldn't try to add all default mappers, but just those which were previously exported. Currently import invokes realm.addApplication(), which will trigger listeners for adding all default builtin mappers. I did not test it yet, but my bet is that it won't work well atm...

Marek > > With all the changes we've done for this release (modules, claim mapping, > identity brokering, oidc endpoints, ...) we need to do more testing this > time around! > > ----- Original Message ----- >> From: "Bill Burke" <bburke(a)redhat.com&gt; >> To: keycloak-dev(a)lists.jboss.org >> Sent: Wednesday, 11 March, 2015 8:06:04 PM >> Subject: [keycloak-dev] 1.2.beta1 planning, need you to defer things >> >> I'd like to do 1.2.beta1 by end of month or earlier. Please go through >> the jira list and defer things you are not going to get to in the next >> 1-2 weeks. Thanks. > Done > >> I'm going to try and close existing bugs and implement features needed >> for jboss.org guys over the next 2 weeks as well as test out master to >> make sure things still work. > With regards to jboss.org guys we shouldn't just add features because they > request it. Take for example KEYCLOAK-1045, which was easily solved with > we already have. Another one is KEYCLOAK-1051, which I think is a horrible > idea. > >> Bill >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev

On 12.3.2015 10:51, Stian Thorgersen wrote: > ----- Original Message ----- >> From: "Marek Posolda" <mposolda(a)redhat.com&gt; >> To: "Stian Thorgersen" <stian(a)redhat.com&gt;, "Bill Burke" <bburke(a)redhat.com&gt; >> Cc: keycloak-dev(a)lists.jboss.org >> Sent: Thursday, 12 March, 2015 10:48:53 AM >> Subject: Re: [keycloak-dev] 1.2.beta1 planning, need you to defer things >> >> On 12.3.2015 06:40, Stian Thorgersen wrote: >>> I'd like to reopen KEYCLOAK-311 as IMO it's not solved. This is not >>> referring to the claim mapping work you've done, it's something else. >>> >>> Before we can do a release we need to make sure that database migration >>> works (I know they don't atm as social providers and social links are >>> lost). We also need to add transformation of JSON exports and >>> representations so older versions can be imported into 1.2.0.Beta1. >> I did migration of social stuff for Mongo but not for jpa/liquibase >> though. I guess migration of protocol mappers would be needed too? As in >> 1.1.0.Final accessToken automatically has all the basic claims like >> username, email etc. So when people migrate to 1.2.0.Beta1, they would >> expect the same, which means that default builtin mappers for basic >> claims will need to be added for all the existing clients? > +1 Can you create a jira so we don't forget? Done https://issues.jboss.org/browse/KEYCLOAK-1098 JIRA for social migration of JPA model is https://issues.jboss.org/browse/KEYCLOAK-1004 . I will retest mongo migration again before release (there may be some additional changes in the identityProvider model in the meantime) >> I have also some fear if export/import would work well together with >> protocol mappers. During import of previously exported application, the >> import shouldn't try to add all default mappers, but just those which >> were previously exported. Currently import invokes >> realm.addApplication(), which will trigger listeners for adding all >> default builtin mappers. I did not test it yet, but my bet is that it >> won't work well atm... > +1 Can you test and jira please? Done https://issues.jboss.org/browse/KEYCLOAK-1099 >> Marek >>> With all the changes we've done for this release (modules, claim mapping, >>> identity brokering, oidc endpoints, ...) we need to do more testing this >>> time around! >>> >>> ----- Original Message ----- >>>> From: "Bill Burke" <bburke(a)redhat.com&gt; >>>> To: keycloak-dev(a)lists.jboss.org >>>> Sent: Wednesday, 11 March, 2015 8:06:04 PM >>>> Subject: [keycloak-dev] 1.2.beta1 planning, need you to defer things >>>> >>>> I'd like to do 1.2.beta1 by end of month or earlier. Please go through >>>> the jira list and defer things you are not going to get to in the next >>>> 1-2 weeks. Thanks. >>> Done >>> >>>> I'm going to try and close existing bugs and implement features needed >>>> for jboss.org guys over the next 2 weeks as well as test out master to >>>> make sure things still work. >>> With regards to jboss.org guys we shouldn't just add features because they >>> request it. Take for example KEYCLOAK-1045, which was easily solved with >>> we already have. Another one is KEYCLOAK-1051, which I think is a horrible >>> idea. >>> >>>> Bill >>>> >>>> -- >>>> Bill Burke >>>> JBoss, a division of Red Hat >>>> http://bill.burkecentral.com >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

----- Original Message ----- > From: "Marek Posolda" <mposolda(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt;, "Bill Burke" <bburke(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Thursday, 12 March, 2015 10:48:53 AM > Subject: Re: [keycloak-dev] 1.2.beta1 planning, need you to defer things > > On 12.3.2015 06:40, Stian Thorgersen wrote: >> I'd like to reopen KEYCLOAK-311 as IMO it's not solved. This is not >> referring to the claim mapping work you've done, it's something else. >> >> Before we can do a release we need to make sure that database migration >> works (I know they don't atm as social providers and social links are >> lost). We also need to add transformation of JSON exports and >> representations so older versions can be imported into 1.2.0.Beta1. > I did migration of social stuff for Mongo but not for jpa/liquibase > though. I guess migration of protocol mappers would be needed too? As in > 1.1.0.Final accessToken automatically has all the basic claims like > username, email etc. So when people migrate to 1.2.0.Beta1, they would > expect the same, which means that default builtin mappers for basic > claims will need to be added for all the existing clients? +1 Can you create a jira so we don't forget?

> > I have also some fear if export/import would work well together with > protocol mappers. During import of previously exported application, the > import shouldn't try to add all default mappers, but just those which > were previously exported. Currently import invokes > realm.addApplication(), which will trigger listeners for adding all > default builtin mappers. I did not test it yet, but my bet is that it > won't work well atm... +1 Can you test and jira please?

----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: keycloak-dev(a)lists.jboss.org > Sent: Thursday, 12 March, 2015 1:57:21 PM > Subject: Re: [keycloak-dev] 1.2.beta1 planning, need you to defer things > > > > On 3/12/2015 1:40 AM, Stian Thorgersen wrote: >> I'd like to reopen KEYCLOAK-311 as IMO it's not solved. This is not >> referring to the claim mapping work you've done, it's something else. >> > > I opened two jiras. One, a "claim validation" jira and another > broker->Usermodel mappers. That should have covered what 311 is not doing. Not IMO. We really need to have something that defines how the internal user profile looks like, attribute validation, what attributes are required, etc.. Also, I really don't think we should require users to modify registration screens and admin console if all they want to do is for example to add a DOB field.

> >> Before we can do a release we need to make sure that database migration >> works (I know they don't atm as social providers and social links are >> lost). We also need to add transformation of JSON exports and >> representations so older versions can be imported into 1.2.0.Beta1. >> > > Not sure, but json imports from older versions should be backwards > compatible. We're just doing migrations via json export/import right? No, we migrate the database directly. https://github.com/keycloak/keycloak/blob/master/misc/UpdatingDatabaseSch... > >>> >>> I'm going to try and close existing bugs and implement features needed >>> for jboss.org guys over the next 2 weeks as well as test out master to >>> make sure things still work. >> >> With regards to jboss.org guys we shouldn't just add features because they >> request it. Take for example KEYCLOAK-1045, which was easily solved with >> we already have. Another one is KEYCLOAK-1051, which I think is a horrible >> idea. >> > > I don't want to just add features either, but some of their things are > valid...i.e. finding out if a user is logged and who they are without > doing all the token stuff. That's exactly one of the things that are not necessary, I've added a POC that uses keycloak.js, which they where happy with. See KEYCLOAK-1045 and http://stianst.github.io/jbossorg/index.html.

From: "Bill Burke" <bburke(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Thursday, 12 March, 2015 3:48:46 PM Subject: Re: [keycloak-dev] 1.2.beta1 planning, need you to defer things On 3/12/2015 10:41 AM, Stian Thorgersen wrote: > > > ----- Original Message ----- >> From: "Bill Burke" <bburke(a)redhat.com&gt; >> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >> Cc: keycloak-dev(a)lists.jboss.org >> Sent: Thursday, 12 March, 2015 1:57:21 PM >> Subject: Re: [keycloak-dev] 1.2.beta1 planning, need you to defer things >> >> >> >> On 3/12/2015 1:40 AM, Stian Thorgersen wrote: >>> I'd like to reopen KEYCLOAK-311 as IMO it's not solved. This is not >>> referring to the claim mapping work you've done, it's something else. >>> >> >> I opened two jiras. One, a "claim validation" jira and another >> broker->Usermodel mappers. That should have covered what 311 is not >> doing. > > Not IMO. We really need to have something that defines how the internal > user profile looks like, attribute validation, what attributes are > required, etc.. Also, I really don't think we should require users to > modify registration screens and admin console if all they want to do is > for example to add a DOB field. > I disagree. They will be editing these pages anyways to get the look and feel they want. As i said over and over, you'll just be re-creating HTML within the data model.

>> >>> Before we can do a release we need to make sure that database migration >>> works (I know they don't atm as social providers and social links are >>> lost). We also need to add transformation of JSON exports and >>> representations so older versions can be imported into 1.2.0.Beta1. >>> >> >> Not sure, but json imports from older versions should be backwards >> compatible. We're just doing migrations via json export/import right? > > No, we migrate the database directly. > https://github.com/keycloak/keycloak/blob/master/misc/UpdatingDatabaseSch... > >> >>>> >>>> I'm going to try and close existing bugs and implement features needed >>>> for jboss.org guys over the next 2 weeks as well as test out master to >>>> make sure things still work. >>> >>> With regards to jboss.org guys we shouldn't just add features because >>> they >>> request it. Take for example KEYCLOAK-1045, which was easily solved with >>> we already have. Another one is KEYCLOAK-1051, which I think is a >>> horrible >>> idea. >>> >> >> I don't want to just add features either, but some of their things are >> valid...i.e. finding out if a user is logged and who they are without >> doing all the token stuff. > > That's exactly one of the things that are not necessary, I've added a POC > that uses keycloak.js, which they where happy with. See KEYCLOAK-1045 and > http://stianst.github.io/jbossorg/index.html. > I'll take a look, but IIRC there was a different issue described (not 1045), where a static home page shouldn't have to perform a full login and obtain a token just to know whether or not a user is logged in and who they are. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

On 3/12/2015 10:41 AM, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Bill Burke" <bburke(a)redhat.com&gt; >> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >> Cc: keycloak-dev(a)lists.jboss.org >> Sent: Thursday, 12 March, 2015 1:57:21 PM >> Subject: Re: [keycloak-dev] 1.2.beta1 planning, need you to defer things >> >> >> >> On 3/12/2015 1:40 AM, Stian Thorgersen wrote: >> ... >>>> I'm going to try and close existing bugs and implement features needed >>>> for jboss.org guys over the next 2 weeks as well as test out master to >>>> make sure things still work. >>> With regards to jboss.org guys we shouldn't just add features because they >>> request it. Take for example KEYCLOAK-1045, which was easily solved with >>> we already have. Another one is KEYCLOAK-1051, which I think is a horrible >>> idea. >>> >> I don't want to just add features either, but some of their things are >> valid...i.e. finding out if a user is logged and who they are without >> doing all the token stuff. > That's exactly one of the things that are not necessary, I've added a POC that uses keycloak.js, which they where happy with. See KEYCLOAK-1045 and http://stianst.github.io/jbossorg/index.html. > I'll take a look, but IIRC there was a different issue described (not 1045), where a static home page shouldn't have to perform a full login and obtain a token just to know whether or not a user is logged in and who they are.