From: "Stian Thorgersen" <stian(a)redhat.com&gt; To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; Sent: Tuesday, 16 December, 2014 12:46:04 PM Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final ----- Original Message ----- > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; > Sent: Tuesday, 16 December, 2014 12:38:35 PM > Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final > > Stian, > > Regarding my tasks, I will be more dedicated to KC once I decrease my PL > backlog a bit. This week is becoming very productive and will help me to > plan my work load with more focus on my KC tasks. > Great, I was hoping that'd be the case :) > Release date for 1.1.0.Final is 09/Feb/15, right ? No, hopefully around 09/Jan/15. With regards to identity brokering do you think you'll be able to wrap-it up by then or would you need longer? For the other OpenID Connect tasks (1.2) we'll just do them in priority order. If you get stuck on PL issues we can push them out, or someone else can help you. > > Regards. > > ----- Original Message ----- > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > To: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; > Sent: Tuesday, December 16, 2014 9:13:44 AM > Subject: [keycloak-dev] Remaining work for 1.1.0.Final > > Before we start any new features we should release 1.1.0.Final. Are there > any > outstanding tasks not listed in JIRA: > > https://issues.jboss.org/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20res... > > There's quite a lot of bugs associated with the release. I'd like us to try > to get rid of as many as possible before releasing, so would be great if > everyone can do some bug fixing before starting on features for 1.2. > > Let's aim for a release shortly after we all return in the New Year. > > ---- > > Features for 1.2 includes: > > * SAML redirect logout (KEYCLOAK-771, Bill) > * Custom user profiles (KEYCLOAK-311, Bill) > * Kerberos brokering (KEYCLOAK-828, Marek) > * LDAP enhancement (KEYCLOAK-886, Marek) > * OpenID Connect Interop Testing (KEYCLOAK-524, Pedro) > * OpenID Connect Discovery (KEYCLOAK-571, Pedro) > * OpenID Connect Dynamic Registration (KEYCLOAK-684, Pedro) > * OpenID Connect Session Management - review and finish missing parts > (KEYCLOAK-451, Pedro) > * Fabric8 integration (Stian) > > ---- > > I've started creating JIRA's for tasks we defined at the F2F and I'll also > create agile boards (or use labels) to make it easy to identify categories > of tasks. Main plan is to make it easy for us to pull out for example all > tasks related to EAP, IDM, etc. > > I've also dropped the 1.x version. All tasks should now be scheduled for > current version, the next version or not have a version associated with it. > _______________________________________________ > 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

From: "Stian Thorgersen" <stian(a)redhat.com&gt; To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; Sent: Tuesday, December 16, 2014 9:46:04 AM Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final ----- Original Message ----- > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; > Sent: Tuesday, 16 December, 2014 12:38:35 PM > Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final > > Stian, > > Regarding my tasks, I will be more dedicated to KC once I decrease my PL > backlog a bit. This week is becoming very productive and will help me to > plan my work load with more focus on my KC tasks. > Great, I was hoping that'd be the case :) > Release date for 1.1.0.Final is 09/Feb/15, right ? No, hopefully around 09/Jan/15. With regards to identity brokering do you think you'll be able to wrap-it up by then or would you need longer?

For the other OpenID Connect tasks (1.2) we'll just do them in priority order. If you get stuck on PL issues we can push them out, or someone else can help you. > > Regards. > > ----- Original Message ----- > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > To: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; > Sent: Tuesday, December 16, 2014 9:13:44 AM > Subject: [keycloak-dev] Remaining work for 1.1.0.Final > > Before we start any new features we should release 1.1.0.Final. Are there > any > outstanding tasks not listed in JIRA: > > https://issues.jboss.org/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20res... > > There's quite a lot of bugs associated with the release. I'd like us to try > to get rid of as many as possible before releasing, so would be great if > everyone can do some bug fixing before starting on features for 1.2. > > Let's aim for a release shortly after we all return in the New Year. > > ---- > > Features for 1.2 includes: > > * SAML redirect logout (KEYCLOAK-771, Bill) > * Custom user profiles (KEYCLOAK-311, Bill) > * Kerberos brokering (KEYCLOAK-828, Marek) > * LDAP enhancement (KEYCLOAK-886, Marek) > * OpenID Connect Interop Testing (KEYCLOAK-524, Pedro) > * OpenID Connect Discovery (KEYCLOAK-571, Pedro) > * OpenID Connect Dynamic Registration (KEYCLOAK-684, Pedro) > * OpenID Connect Session Management - review and finish missing parts > (KEYCLOAK-451, Pedro) > * Fabric8 integration (Stian) > > ---- > > I've started creating JIRA's for tasks we defined at the F2F and I'll also > create agile boards (or use labels) to make it easy to identify categories > of tasks. Main plan is to make it easy for us to pull out for example all > tasks related to EAP, IDM, etc. > > I've also dropped the 1.x version. All tasks should now be scheduled for > current version, the next version or not have a version associated with it. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >

From: "Stian Thorgersen" <stian(a)redhat.com&gt; To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; Sent: Tuesday, December 16, 2014 10:37:11 AM Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final ----- Original Message ----- > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; > Sent: Tuesday, 16 December, 2014 1:25:50 PM > Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final > > Btw, regarding SAML brokering. I'm trying to focus on KC integration with a > PL SAML IdP. I think that will help people (customers and community) > already > using PL to adopt KC without forcing them to drop existing infrastructure > and investments. And that will also help them to think about a migration > plan. Makes sense. We should also provide a migration path for the stored users. If we moved to PL IDM that'd be easy, but not sure that'll happen straight away. Maybe we could provide a PL IDM user federation provider?

> > ----- Original Message ----- > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; > Sent: Tuesday, December 16, 2014 10:15:40 AM > Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final > > ----- Original Message ----- > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; > > Sent: Tuesday, December 16, 2014 9:46:04 AM > > Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final > > > > > > > > ----- Original Message ----- > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; > > > Sent: Tuesday, 16 December, 2014 12:38:35 PM > > > Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final > > > > > > Stian, > > > > > > Regarding my tasks, I will be more dedicated to KC once I decrease > > > my > > > PL > > > backlog a bit. This week is becoming very productive and will help > > > me > > > to > > > plan my work load with more focus on my KC tasks. > > > > > > > Great, I was hoping that'd be the case :) > > > > > Release date for 1.1.0.Final is 09/Feb/15, right ? > > > > No, hopefully around 09/Jan/15. With regards to identity brokering do you > > think you'll be able to wrap-it up by then or would you need longer? > > In JIRA, 1.1.0.Final is targeted to 09/Feb/15. That is why I asked ... > > Regarding the brokering stuff, the missing bits are: > > - Remove old social references from code. > - Review Account page. > - Add more config options to SAML brokering > - Upload IdP metadata > - Signature and Encryption support > - Http Binding Configuration for AuthnRequests > - NameID Format configuration for AuthnRequests > - Automatic redirection when no credential is supported and a single IdP is > configured/enabled. > - Test KC brokering. > - Requires a better OIDC support in KC. We already have some JIRAs for > that. > > There is also the attribute mapping stuff. Which will allow users to > resolve > claims/attributes from trusted IdPs. But to support that, I think we first > need the custom claim/profiles in place. However, this is not a blocker for > a first release IMO. > > The broker is already doing the job. UI, model, REST endpoints, persistence > and SPI are fine. We have everything we need to focus only on the > functional > bits. > > > > > For the other OpenID Connect tasks (1.2) we'll just do them in priority > > order. If you get stuck on PL issues we can push them out, or someone > > else > > can help you. > > > > > > > > Regards. > > > > > > ----- Original Message ----- > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > To: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; > > > Sent: Tuesday, December 16, 2014 9:13:44 AM > > > Subject: [keycloak-dev] Remaining work for 1.1.0.Final > > > > > > Before we start any new features we should release 1.1.0.Final. Are > > > there > > > any > > > outstanding tasks not listed in JIRA: > > > > > > https://issues.jboss.org/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20res... > > > > > > There's quite a lot of bugs associated with the release. I'd like us to > > > try > > > to get rid of as many as possible before releasing, so would be great > > > if > > > everyone can do some bug fixing before starting on features for 1.2. > > > > > > Let's aim for a release shortly after we all return in the New Year. > > > > > > ---- > > > > > > Features for 1.2 includes: > > > > > > * SAML redirect logout (KEYCLOAK-771, Bill) > > > * Custom user profiles (KEYCLOAK-311, Bill) > > > * Kerberos brokering (KEYCLOAK-828, Marek) > > > * LDAP enhancement (KEYCLOAK-886, Marek) > > > * OpenID Connect Interop Testing (KEYCLOAK-524, Pedro) > > > * OpenID Connect Discovery (KEYCLOAK-571, Pedro) > > > * OpenID Connect Dynamic Registration (KEYCLOAK-684, Pedro) > > > * OpenID Connect Session Management - review and finish missing parts > > > (KEYCLOAK-451, Pedro) > > > * Fabric8 integration (Stian) > > > > > > ---- > > > > > > I've started creating JIRA's for tasks we defined at the F2F and I'll > > > also > > > create agile boards (or use labels) to make it easy to identify > > > categories > > > of tasks. Main plan is to make it easy for us to pull out for example > > > all > > > tasks related to EAP, IDM, etc. > > > > > > I've also dropped the 1.x version. All tasks should now be scheduled > > > for > > > current version, the next version or not have a version associated with > > > it. > > > _______________________________________________ > > > 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 >

From: "Marek Posolda" <mposolda(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt;, "Pedro Igor Silva" <psilva(a)redhat.com&gt; Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; Sent: Tuesday, December 16, 2014 11:42:44 AM Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final On 16.12.2014 13:37, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >> Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; >> Sent: Tuesday, 16 December, 2014 1:25:50 PM >> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final >> >> Btw, regarding SAML brokering. I'm trying to focus on KC integration with >> a >> PL SAML IdP. I think that will help people (customers and community) >> already >> using PL to adopt KC without forcing them to drop existing infrastructure >> and investments. And that will also help them to think about a migration >> plan. > Makes sense. We should also provide a migration path for the stored users. > If we moved to PL IDM that'd be easy, but not sure that'll happen straight > away. Maybe we could provide a PL IDM user federation provider? Well, we defacto already have it :) Our LDAPFederationProvider is using Picketlink IDM API to bridge between keycloak model and org.picketlink.idm.model.basic.User . There is no direct interaction with LDAP, but everything goes through PL IDM API. In early stage when we discussed ldap integration and using PL IDM API for it, we also discussed that it could be nice if people could provide different source of PL IDM store. So there is PartitionManagerProvider interface, which provides access to pl idm PartitionManager. Right now we have just one implementation LDAPPartitionManagerProvider, which returns picketlink PartitionManager configured to use LDAP store based on ldap configuration provided by keycloak admin console. So theoretically only thing, which people need to do is to provide their own PartitionManagerProvider when they can configure PL IDM stores according to their environment. And this PartitionManagerProvider would need to be configured in keycloak-server.json, so it has precedence over the default LDAP based impl. Only condition is that their users should be retrievable with usage of org.picketlink.idm.model.basic.User from PL IDM Basic model.

Marek > >> ----- Original Message ----- >> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >> Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; >> Sent: Tuesday, December 16, 2014 10:15:40 AM >> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final >> >> ----- Original Message ----- >>> From: "Stian Thorgersen" <stian(a)redhat.com&gt; >>> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>> Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; >>> Sent: Tuesday, December 16, 2014 9:46:04 AM >>> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final >>> >>> >>> >>> ----- Original Message ----- >>>> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >>>> Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; >>>> Sent: Tuesday, 16 December, 2014 12:38:35 PM >>>> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final >>>> >>>> Stian, >>>> >>>> Regarding my tasks, I will be more dedicated to KC once I decrease >>>> my >>>> PL >>>> backlog a bit. This week is becoming very productive and will help >>>> me >>>> to >>>> plan my work load with more focus on my KC tasks. >>>> >>> Great, I was hoping that'd be the case :) >>> >>>> Release date for 1.1.0.Final is 09/Feb/15, right ? >>> No, hopefully around 09/Jan/15. With regards to identity brokering do you >>> think you'll be able to wrap-it up by then or would you need longer? >> In JIRA, 1.1.0.Final is targeted to 09/Feb/15. That is why I asked ... >> >> Regarding the brokering stuff, the missing bits are: >> >> - Remove old social references from code. >> - Review Account page. >> - Add more config options to SAML brokering >> - Upload IdP metadata >> - Signature and Encryption support >> - Http Binding Configuration for AuthnRequests >> - NameID Format configuration for AuthnRequests >> - Automatic redirection when no credential is supported and a single IdP >> is >> configured/enabled. >> - Test KC brokering. >> - Requires a better OIDC support in KC. We already have some JIRAs for >> that. >> >> There is also the attribute mapping stuff. Which will allow users to >> resolve >> claims/attributes from trusted IdPs. But to support that, I think we first >> need the custom claim/profiles in place. However, this is not a blocker >> for >> a first release IMO. >> >> The broker is already doing the job. UI, model, REST endpoints, >> persistence >> and SPI are fine. We have everything we need to focus only on the >> functional >> bits. >> >>> For the other OpenID Connect tasks (1.2) we'll just do them in priority >>> order. If you get stuck on PL issues we can push them out, or someone >>> else >>> can help you. >>> >>>> Regards. >>>> >>>> ----- Original Message ----- >>>> From: "Stian Thorgersen" <stian(a)redhat.com&gt; >>>> To: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; >>>> Sent: Tuesday, December 16, 2014 9:13:44 AM >>>> Subject: [keycloak-dev] Remaining work for 1.1.0.Final >>>> >>>> Before we start any new features we should release 1.1.0.Final. Are >>>> there >>>> any >>>> outstanding tasks not listed in JIRA: >>>> >>>> https://issues.jboss.org/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20res... >>>> >>>> There's quite a lot of bugs associated with the release. I'd like us to >>>> try >>>> to get rid of as many as possible before releasing, so would be great if >>>> everyone can do some bug fixing before starting on features for 1.2. >>>> >>>> Let's aim for a release shortly after we all return in the New Year. >>>> >>>> ---- >>>> >>>> Features for 1.2 includes: >>>> >>>> * SAML redirect logout (KEYCLOAK-771, Bill) >>>> * Custom user profiles (KEYCLOAK-311, Bill) >>>> * Kerberos brokering (KEYCLOAK-828, Marek) >>>> * LDAP enhancement (KEYCLOAK-886, Marek) >>>> * OpenID Connect Interop Testing (KEYCLOAK-524, Pedro) >>>> * OpenID Connect Discovery (KEYCLOAK-571, Pedro) >>>> * OpenID Connect Dynamic Registration (KEYCLOAK-684, Pedro) >>>> * OpenID Connect Session Management - review and finish missing parts >>>> (KEYCLOAK-451, Pedro) >>>> * Fabric8 integration (Stian) >>>> >>>> ---- >>>> >>>> I've started creating JIRA's for tasks we defined at the F2F and I'll >>>> also >>>> create agile boards (or use labels) to make it easy to identify >>>> categories >>>> of tasks. Main plan is to make it easy for us to pull out for example >>>> all >>>> tasks related to EAP, IDM, etc. >>>> >>>> I've also dropped the 1.x version. All tasks should now be scheduled for >>>> current version, the next version or not have a version associated with >>>> it. >>>> _______________________________________________ >>>> 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

From: "Marek Posolda" <mposolda(a)redhat.com&gt; To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; Cc: "Stian Thorgersen" <stian(a)redhat.com&gt;, "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; Sent: Tuesday, 16 December, 2014 3:25:27 PM Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final On 16.12.2014 14:55, Pedro Igor Silva wrote: > ----- Original Message ----- >> From: "Marek Posolda" <mposolda(a)redhat.com&gt; >> To: "Stian Thorgersen" <stian(a)redhat.com&gt;, "Pedro Igor Silva" >> <psilva(a)redhat.com&gt; >> Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; >> Sent: Tuesday, December 16, 2014 11:42:44 AM >> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final >> >> On 16.12.2014 13:37, Stian Thorgersen wrote: >>> ----- Original Message ----- >>>> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >>>> Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; >>>> Sent: Tuesday, 16 December, 2014 1:25:50 PM >>>> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final >>>> >>>> Btw, regarding SAML brokering. I'm trying to focus on KC integration >>>> with >>>> a >>>> PL SAML IdP. I think that will help people (customers and community) >>>> already >>>> using PL to adopt KC without forcing them to drop existing >>>> infrastructure >>>> and investments. And that will also help them to think about a migration >>>> plan. >>> Makes sense. We should also provide a migration path for the stored >>> users. >>> If we moved to PL IDM that'd be easy, but not sure that'll happen >>> straight >>> away. Maybe we could provide a PL IDM user federation provider? >> Well, we defacto already have it :) Our LDAPFederationProvider is using >> Picketlink IDM API to bridge between keycloak model and >> org.picketlink.idm.model.basic.User . There is no direct interaction >> with LDAP, but everything goes through PL IDM API. >> >> In early stage when we discussed ldap integration and using PL IDM API >> for it, we also discussed that it could be nice if people could provide >> different source of PL IDM store. So there is PartitionManagerProvider >> interface, which provides access to pl idm PartitionManager. Right now >> we have just one implementation LDAPPartitionManagerProvider, which >> returns picketlink PartitionManager configured to use LDAP store based >> on ldap configuration provided by keycloak admin console. >> >> So theoretically only thing, which people need to do is to provide their >> own PartitionManagerProvider when they can configure PL IDM stores >> according to their environment. And this PartitionManagerProvider would >> need to be configured in keycloak-server.json, so it has precedence over >> the default LDAP based impl. Only condition is that their users should >> be retrievable with usage of org.picketlink.idm.model.basic.User from PL >> IDM Basic model. > Or they can just provide a JNDI url where the PartitionManager is located, > when using the subsystem. Also, PL IDM has the concept of stereotypes [1]. > What means, in theory, that you can deal with any identity model > definition (eg.: not only the basic identity model). yeah, so we can do something like "SubsystemPartitionManagerProvider", which will allow people to retrieve PartitionManager from JNDI URL and they won't need to code anything by themselves. Only provide JDNI URL in configuration.

> > [1] > http://docs.jboss.org/picketlink/2/latest/reference/html-single/#sect-Ste... > >> Marek >>>> ----- Original Message ----- >>>> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >>>> Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; >>>> Sent: Tuesday, December 16, 2014 10:15:40 AM >>>> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final >>>> >>>> ----- Original Message ----- >>>>> From: "Stian Thorgersen" <stian(a)redhat.com&gt; >>>>> To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>>> Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; >>>>> Sent: Tuesday, December 16, 2014 9:46:04 AM >>>>> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>>>> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >>>>>> Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; >>>>>> Sent: Tuesday, 16 December, 2014 12:38:35 PM >>>>>> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final >>>>>> >>>>>> Stian, >>>>>> >>>>>> Regarding my tasks, I will be more dedicated to KC once I >>>>>> decrease >>>>>> my >>>>>> PL >>>>>> backlog a bit. This week is becoming very productive and will >>>>>> help >>>>>> me >>>>>> to >>>>>> plan my work load with more focus on my KC tasks. >>>>>> >>>>> Great, I was hoping that'd be the case :) >>>>> >>>>>> Release date for 1.1.0.Final is 09/Feb/15, right ? >>>>> No, hopefully around 09/Jan/15. With regards to identity brokering do >>>>> you >>>>> think you'll be able to wrap-it up by then or would you need longer? >>>> In JIRA, 1.1.0.Final is targeted to 09/Feb/15. That is why I asked ... >>>> >>>> Regarding the brokering stuff, the missing bits are: >>>> >>>> - Remove old social references from code. >>>> - Review Account page. >>>> - Add more config options to SAML brokering >>>> - Upload IdP metadata >>>> - Signature and Encryption support >>>> - Http Binding Configuration for AuthnRequests >>>> - NameID Format configuration for AuthnRequests >>>> - Automatic redirection when no credential is supported and a single IdP >>>> is >>>> configured/enabled. >>>> - Test KC brokering. >>>> - Requires a better OIDC support in KC. We already have some JIRAs >>>> for >>>> that. >>>> >>>> There is also the attribute mapping stuff. Which will allow users to >>>> resolve >>>> claims/attributes from trusted IdPs. But to support that, I think we >>>> first >>>> need the custom claim/profiles in place. However, this is not a blocker >>>> for >>>> a first release IMO. >>>> >>>> The broker is already doing the job. UI, model, REST endpoints, >>>> persistence >>>> and SPI are fine. We have everything we need to focus only on the >>>> functional >>>> bits. >>>> >>>>> For the other OpenID Connect tasks (1.2) we'll just do them in priority >>>>> order. If you get stuck on PL issues we can push them out, or someone >>>>> else >>>>> can help you. >>>>> >>>>>> Regards. >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: "Stian Thorgersen" <stian(a)redhat.com&gt; >>>>>> To: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; >>>>>> Sent: Tuesday, December 16, 2014 9:13:44 AM >>>>>> Subject: [keycloak-dev] Remaining work for 1.1.0.Final >>>>>> >>>>>> Before we start any new features we should release 1.1.0.Final. Are >>>>>> there >>>>>> any >>>>>> outstanding tasks not listed in JIRA: >>>>>> >>>>>> https://issues.jboss.org/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20res... >>>>>> >>>>>> There's quite a lot of bugs associated with the release. I'd like us >>>>>> to >>>>>> try >>>>>> to get rid of as many as possible before releasing, so would be great >>>>>> if >>>>>> everyone can do some bug fixing before starting on features for 1.2. >>>>>> >>>>>> Let's aim for a release shortly after we all return in the New Year. >>>>>> >>>>>> ---- >>>>>> >>>>>> Features for 1.2 includes: >>>>>> >>>>>> * SAML redirect logout (KEYCLOAK-771, Bill) >>>>>> * Custom user profiles (KEYCLOAK-311, Bill) >>>>>> * Kerberos brokering (KEYCLOAK-828, Marek) >>>>>> * LDAP enhancement (KEYCLOAK-886, Marek) >>>>>> * OpenID Connect Interop Testing (KEYCLOAK-524, Pedro) >>>>>> * OpenID Connect Discovery (KEYCLOAK-571, Pedro) >>>>>> * OpenID Connect Dynamic Registration (KEYCLOAK-684, Pedro) >>>>>> * OpenID Connect Session Management - review and finish missing parts >>>>>> (KEYCLOAK-451, Pedro) >>>>>> * Fabric8 integration (Stian) >>>>>> >>>>>> ---- >>>>>> >>>>>> I've started creating JIRA's for tasks we defined at the F2F and I'll >>>>>> also >>>>>> create agile boards (or use labels) to make it easy to identify >>>>>> categories >>>>>> of tasks. Main plan is to make it easy for us to pull out for example >>>>>> all >>>>>> tasks related to EAP, IDM, etc. >>>>>> >>>>>> I've also dropped the 1.x version. All tasks should now be scheduled >>>>>> for >>>>>> current version, the next version or not have a version associated >>>>>> with >>>>>> it. >>>>>> _______________________________________________ >>>>>> 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 >>

From: "Marek Posolda" <mposolda(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: "Pedro Igor Silva" <psilva(a)redhat.com&gt;, "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; Sent: Tuesday, 16 December, 2014 6:15:30 PM Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final On 16.12.2014 15:27, Stian Thorgersen wrote: >>>>> Makes sense. We should also provide a migration path for the stored >>>>> > >>>users. >>>>> > >>>If we moved to PL IDM that'd be easy, but not sure that'll happen >>>>> > >>>straight >>>>> > >>>away. Maybe we could provide a PL IDM user federation provider? >>>> > >>Well, we defacto already have it:) Our LDAPFederationProvider is >>>> > >>using >>>> > >>Picketlink IDM API to bridge between keycloak model and >>>> > >>org.picketlink.idm.model.basic.User . There is no direct interaction >>>> > >>with LDAP, but everything goes through PL IDM API. >>>> > >> >>>> > >>In early stage when we discussed ldap integration and using PL IDM >>>> > >>API >>>> > >>for it, we also discussed that it could be nice if people could >>>> > >>provide >>>> > >>different source of PL IDM store. So there is >>>> > >>PartitionManagerProvider >>>> > >>interface, which provides access to pl idm PartitionManager. Right >>>> > >>now >>>> > >>we have just one implementation LDAPPartitionManagerProvider, which >>>> > >>returns picketlink PartitionManager configured to use LDAP store >>>> > >>based >>>> > >>on ldap configuration provided by keycloak admin console. >>>> > >> >>>> > >>So theoretically only thing, which people need to do is to provide >>>> > >>their >>>> > >>own PartitionManagerProvider when they can configure PL IDM stores >>>> > >>according to their environment. And this PartitionManagerProvider >>>> > >>would >>>> > >>need to be configured in keycloak-server.json, so it has precedence >>>> > >>over >>>> > >>the default LDAP based impl. Only condition is that their users >>>> > >>should >>>> > >>be retrievable with usage of org.picketlink.idm.model.basic.User >>>> > >>from PL >>>> > >>IDM Basic model. >>> > >Or they can just provide a JNDI url where the PartitionManager is >>> > >located, >>> > >when using the subsystem. Also, PL IDM has the concept of stereotypes >>> > >[1]. >>> > >What means, in theory, that you can deal with any identity model >>> > >definition (eg.: not only the basic identity model). >> >yeah, so we can do something like "SubsystemPartitionManagerProvider", >> >which will allow people to retrieve PartitionManager from JNDI URL and >> >they won't need to code anything by themselves. Only provide JDNI URL in >> >configuration. > What about following the same pattern as we use for JPA and Infinispan. The > default provider can either be configured to create on on it's own or you > can set the data-source / jndi-name? > Yeah, that should work well. Tricky thing is how to configure it in admin console? Right now we have 'ldap' federation provider, which allows to configure ldap settings and this is the provider, which delegates to picketlink. So possible solution is: 1) Add another provider in admin console. So they will be both 'ldap' and 'picketlink' providers available. In the screen for 'ldap' provider, people can configure LDAP like it's now. In the screen for 'picketlink' provider, people can configure just JNDI URL from where they can retrieve PartitionManager from picketlink subsystem. Implementation wise, we can have 2 implementations of UserFederationProviderFactory, which will differ just in the detail on how to retrieve PartitionManager - https://github.com/keycloak/keycloak/blob/master/federation/ldap/src/main... . The 'ldap' impl can call: session.getProvider(PartitionManagerProvider.class, 'ldap') to retrieve LDAPPartitionManagerProvider. The 'picketlink' impl can call: session.getProvider(PartitionManagerProvider.class, 'picketlink') to retrieve SubsystemPartitionManagerProvider (or PicketlinkPartitionManagerProvider ?), which will retrieve PartitionManager from configured JNDI URL. 2) Have single impl of UserFederationProvider and in admin console, there may be checkbox. If checked, people can configure JNDI URL. If not checked, people can configure LDAP like it's now. I like (1) more. Solution (2) make it a bit harder to enable LDAP integration. Better ideas?

Marek

From: "Bill Burke" <bburke(a)redhat.com&gt; To: keycloak-dev(a)lists.jboss.org Sent: Wednesday, 17 December, 2014 2:01:20 PM Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final On 12/17/2014 3:11 AM, Stian Thorgersen wrote: >> Yeah, that should work well. Tricky thing is how to configure it in >> admin console? Right now we have 'ldap' federation provider, which >> allows to configure ldap settings and this is the provider, which >> delegates to picketlink. So possible solution is: >> >> 1) Add another provider in admin console. So they will be both 'ldap' >> and 'picketlink' providers available. In the screen for 'ldap' provider, >> people can configure LDAP like it's now. In the screen for 'picketlink' >> provider, people can configure just JNDI URL from where they can >> retrieve PartitionManager from picketlink subsystem. Implementation >> wise, we can have 2 implementations of UserFederationProviderFactory, >> which will differ just in the detail on how to retrieve PartitionManager >> - >> https://github.com/keycloak/keycloak/blob/master/federation/ldap/src/main... >> . >> The 'ldap' impl can call: >> session.getProvider(PartitionManagerProvider.class, 'ldap') to retrieve >> LDAPPartitionManagerProvider. >> The 'picketlink' impl can call: >> session.getProvider(PartitionManagerProvider.class, 'picketlink') to >> retrieve SubsystemPartitionManagerProvider (or >> PicketlinkPartitionManagerProvider ?), which will retrieve >> PartitionManager from configured JNDI URL. >> >> 2) Have single impl of UserFederationProvider and in admin console, >> there may be checkbox. If checked, people can configure JNDI URL. If not >> checked, people can configure LDAP like it's now. >> >> I like (1) more. Solution (2) make it a bit harder to enable LDAP >> integration. Better ideas? > > Hm.... I don't like either of those, but don't have any better ideas :/ > If the PL IDM API user is using the default PL IDM API security model, then we can write something generic and plug it in via a JNDI reference (1). I don't understand why you are against this Stian. Its just PL IDM API integration.

I don't like #2 at all. Users should have no knowledge of PL IDM API when using our default LDAP provider. My hope is that our LDAP provider becomes sophisticated enough that the user never needs to see any code even for the most complex LDAP deployments. -- 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: "Bill Burke" <bburke(a)redhat.com&gt; To: keycloak-dev(a)lists.jboss.org Sent: Tuesday, December 16, 2014 12:55:26 PM Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final On 12/16/2014 8:55 AM, Pedro Igor Silva wrote: > ----- Original Message ----- >> From: "Marek Posolda" <mposolda(a)redhat.com&gt; >> To: "Stian Thorgersen" <stian(a)redhat.com&gt;, "Pedro Igor Silva" >> <psilva(a)redhat.com&gt; >> Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; >> Sent: Tuesday, December 16, 2014 11:42:44 AM >> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final >> >> On 16.12.2014 13:37, Stian Thorgersen wrote: >>> >>> ----- Original Message ----- >>>> From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; >>>> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >>>> Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; >>>> Sent: Tuesday, 16 December, 2014 1:25:50 PM >>>> Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final >>>> >>>> Btw, regarding SAML brokering. I'm trying to focus on KC integration >>>> with >>>> a >>>> PL SAML IdP. I think that will help people (customers and community) >>>> already >>>> using PL to adopt KC without forcing them to drop existing >>>> infrastructure >>>> and investments. And that will also help them to think about a migration >>>> plan. >>> Makes sense. We should also provide a migration path for the stored >>> users. >>> If we moved to PL IDM that'd be easy, but not sure that'll happen >>> straight >>> away. Maybe we could provide a PL IDM user federation provider? >> Well, we defacto already have it :) Our LDAPFederationProvider is using >> Picketlink IDM API to bridge between keycloak model and >> org.picketlink.idm.model.basic.User . There is no direct interaction >> with LDAP, but everything goes through PL IDM API. >> >> In early stage when we discussed ldap integration and using PL IDM API >> for it, we also discussed that it could be nice if people could provide >> different source of PL IDM store. So there is PartitionManagerProvider >> interface, which provides access to pl idm PartitionManager. Right now >> we have just one implementation LDAPPartitionManagerProvider, which >> returns picketlink PartitionManager configured to use LDAP store based >> on ldap configuration provided by keycloak admin console. >> >> So theoretically only thing, which people need to do is to provide their >> own PartitionManagerProvider when they can configure PL IDM stores >> according to their environment. And this PartitionManagerProvider would >> need to be configured in keycloak-server.json, so it has precedence over >> the default LDAP based impl. Only condition is that their users should >> be retrievable with usage of org.picketlink.idm.model.basic.User from PL >> IDM Basic model. > > Or they can just provide a JNDI url where the PartitionManager is located, > when using the subsystem. Also, PL IDM has the concept of stereotypes [1]. > What means, in theory, that you can deal with any identity model > definition (eg.: not only the basic identity model). > > [1] > http://docs.jboss.org/picketlink/2/latest/reference/html-single/#sect-Ste... > There would still need to be code to map from the user's "stereotype" to the Keycloak metamodel.

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: "Stian Thorgersen" <stian(a)redhat.com&gt; To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; Sent: Tuesday, December 16, 2014 10:33:05 AM Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final ----- Original Message ----- > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; > Sent: Tuesday, 16 December, 2014 1:15:40 PM > Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final > > ----- Original Message ----- > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > To: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; > > Sent: Tuesday, December 16, 2014 9:46:04 AM > > Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final > > > > > > > > ----- Original Message ----- > > > From: "Pedro Igor Silva" <psilva(a)redhat.com&gt; > > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; > > > Sent: Tuesday, 16 December, 2014 12:38:35 PM > > > Subject: Re: [keycloak-dev] Remaining work for 1.1.0.Final > > > > > > Stian, > > > > > > Regarding my tasks, I will be more dedicated to KC once I decrease > > > my > > > PL > > > backlog a bit. This week is becoming very productive and will help > > > me > > > to > > > plan my work load with more focus on my KC tasks. > > > > > > > Great, I was hoping that'd be the case :) > > > > > Release date for 1.1.0.Final is 09/Feb/15, right ? > > > > No, hopefully around 09/Jan/15. With regards to identity brokering do you > > think you'll be able to wrap-it up by then or would you need longer? > > In JIRA, 1.1.0.Final is targeted to 09/Feb/15. That is why I asked ... Not any more ;) > > Regarding the brokering stuff, the missing bits are: > > - Remove old social references from code. > - Review Account page. > - Add more config options to SAML brokering > - Upload IdP metadata > - Signature and Encryption support > - Http Binding Configuration for AuthnRequests > - NameID Format configuration for AuthnRequests > - Automatic redirection when no credential is supported and a single IdP is > configured/enabled. > - Test KC brokering. > - Requires a better OIDC support in KC. We already have some JIRAs for > that. > > There is also the attribute mapping stuff. Which will allow users to > resolve > claims/attributes from trusted IdPs. But to support that, I think we first > need the custom claim/profiles in place. However, this is not a blocker for > a first release IMO. Yes, mapping can (and probably has to) wait. There's still a fair amount of work you've listed there though. Let's revisit in Jan before we do a release. We can always push it to 1.2.0.Beta1, which would be in Feb/March. May be better to introduce this in a beta than a final in either case.

> > The broker is already doing the job. UI, model, REST endpoints, persistence > and SPI are fine. We have everything we need to focus only on the > functional > bits. > > > > > For the other OpenID Connect tasks (1.2) we'll just do them in priority > > order. If you get stuck on PL issues we can push them out, or someone > > else > > can help you. > > > > > > > > Regards. > > > > > > ----- Original Message ----- > > > From: "Stian Thorgersen" <stian(a)redhat.com&gt; > > > To: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; > > > Sent: Tuesday, December 16, 2014 9:13:44 AM > > > Subject: [keycloak-dev] Remaining work for 1.1.0.Final > > > > > > Before we start any new features we should release 1.1.0.Final. Are > > > there > > > any > > > outstanding tasks not listed in JIRA: > > > > > > https://issues.jboss.org/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20res... > > > > > > There's quite a lot of bugs associated with the release. I'd like us to > > > try > > > to get rid of as many as possible before releasing, so would be great > > > if > > > everyone can do some bug fixing before starting on features for 1.2. > > > > > > Let's aim for a release shortly after we all return in the New Year. > > > > > > ---- > > > > > > Features for 1.2 includes: > > > > > > * SAML redirect logout (KEYCLOAK-771, Bill) > > > * Custom user profiles (KEYCLOAK-311, Bill) > > > * Kerberos brokering (KEYCLOAK-828, Marek) > > > * LDAP enhancement (KEYCLOAK-886, Marek) > > > * OpenID Connect Interop Testing (KEYCLOAK-524, Pedro) > > > * OpenID Connect Discovery (KEYCLOAK-571, Pedro) > > > * OpenID Connect Dynamic Registration (KEYCLOAK-684, Pedro) > > > * OpenID Connect Session Management - review and finish missing parts > > > (KEYCLOAK-451, Pedro) > > > * Fabric8 integration (Stian) > > > > > > ---- > > > > > > I've started creating JIRA's for tasks we defined at the F2F and I'll > > > also > > > create agile boards (or use labels) to make it easy to identify > > > categories > > > of tasks. Main plan is to make it easy for us to pull out for example > > > all > > > tasks related to EAP, IDM, etc. > > > > > > I've also dropped the 1.x version. All tasks should now be scheduled > > > for > > > current version, the next version or not have a version associated with > > > it. > > > _______________________________________________ > > > keycloak-dev mailing list > > > keycloak-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > >

Is Pedro's work already included? Don't forget SAML/OIDC brokering. On 12/16/2014 6:13 AM, Stian Thorgersen wrote: > Before we start any new features we should release 1.1.0.Final. Are there any outstanding tasks not listed in JIRA: > > https://issues.jboss.org/issues/?jql=project%20%3D%20KEYCLOAK%20AND%20res... > > There's quite a lot of bugs associated with the release. I'd like us to try to get rid of as many as possible before releasing, so would be great if everyone can do some bug fixing before starting on features for 1.2. > > Let's aim for a release shortly after we all return in the New Year. > > ---- > > Features for 1.2 includes: > > * SAML redirect logout (KEYCLOAK-771, Bill) > * Custom user profiles (KEYCLOAK-311, Bill) > * Kerberos brokering (KEYCLOAK-828, Marek) > * LDAP enhancement (KEYCLOAK-886, Marek) > * OpenID Connect Interop Testing (KEYCLOAK-524, Pedro) > * OpenID Connect Discovery (KEYCLOAK-571, Pedro) > * OpenID Connect Dynamic Registration (KEYCLOAK-684, Pedro) > * OpenID Connect Session Management - review and finish missing parts (KEYCLOAK-451, Pedro) > * Fabric8 integration (Stian) > > ---- > > I've started creating JIRA's for tasks we defined at the F2F and I'll also create agile boards (or use labels) to make it easy to identify categories of tasks. Main plan is to make it easy for us to pull out for example all tasks related to EAP, IDM, etc. > > I've also dropped the 1.x version. All tasks should now be scheduled for current version, the next version or not have a version associated with it. > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >