From gerbermichi at me.com  Sun Feb  1 10:09:35 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Sun, 01 Feb 2015 16:09:35 +0100
Subject: [keycloak-dev] Looking for a workaround...
In-Reply-To: <742926378.3966720.1422624340264.JavaMail.zimbra@redhat.com>
References: <ef0cd52d-966b-45c8-bb13-cf99cc9c5267@me.com>
	<742926378.3966720.1422624340264.JavaMail.zimbra@redhat.com>
Message-ID: <E031EBDE-B9EC-47F1-9B8C-C6BDBCC76CD1@me.com>

I would look at the following scenario:
A user starts with the login process and then takes a long break (15 mins or more) without locking his computer. 

There are critical processes like password changes, which should definitely expires after a view minutes and others like authentication which does not matter if they don?t expire during this break.

critical actions:
- OAUTH_GRANT
- CODE_TO_TOKEN (already seperate)
- VERIFY_EMAIL
- RECOVER_PASSWORD
- UPDATE_PROFILE
- CONFIGURE_TOTP
- UPDATE_PASSWORD

non-critical actions:
- AUTHENTICATE
- SOCIAL_CALLBACK

> Am 30.01.2015 um 14:25 schrieb Stian Thorgersen <stian at redhat.com>:
> 
> What groups would you propose?
> 
> ----- Original Message -----
>> From: "Michael Gerber" <gerbermichi at me.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Monday, 26 January, 2015 4:23:49 PM
>> Subject: Re: [keycloak-dev] Looking for a workaround...
>> 
>>> ----- Original Message -----
>>>> From: "Michael Gerber" <gerbermichi at me.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Sent: Monday, January 26, 2015 2:10:59 PM
>>>> Subject: Re: [keycloak-dev] Looking for a workaround...
>>>> ----- Original Message -----
>>>> From: "Michael Gerber" <gerbermichi at me.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> 
>>>> Sent: Monday, January 26, 2015 1:37:53 PM
>>>> Subject: [keycloak-dev] Looking for a workaround...
>>>> Hi all,
>>>> I receive a lot of bug reports from our test team because of the following
>>>> two issues:
>>>> - Reset password leads to 400 Bad Request (
>>>> https://issues.jboss.org/browse/KEYCLOAK-1014 )
>>>> This is a tricky one - we can't ignore the state variable as that would
>>>> make
>>>> it vulnerable.
>>>> We could probably come up with an alternative way to generate and verify
>>>> state variable though. Could be a HMAC for example.
>>>> So you would remove the state cookie?
>>> 
>>> It could potentially be a solution - I started a separate thread on
>>> keycloak-dev to discuss this.
>>> 
>>>> - Login attempt after "Login user action lifespan" leads to "Invalid
>>>> username
>>>> or password." ( https://issues.jboss.org/browse/KEYCLOAK-1015 )
>>>> I agree that the error message is not very good, but I disagree with
>>>> removing
>>>> the expiration. Why not increase it to say 30 min? That's probably a more
>>>> sensible timeout for reset password as well.
>>>> I prefer an expiration of 5 min for the password update process, but thats
>>>> a
>>>> bit short for the authentication or password reset process.
>>>> I think the best solution would be different expiration times for the
>>>> different processes, wouldn't it?
>>> 
>>> Maybe - we do try to keep configuration options to a minimum as these
>>> introduce complexity as well as potentials for bug/security issues.
>> 
>> I totaly understand that.
>> You have currently the following actions:
>> OAUTH_GRANT,
>> CODE_TO_TOKEN,
>> VERIFY_EMAIL,
>> UPDATE_PROFILE,
>> CONFIGURE_TOTP,
>> UPDATE_PASSWORD,
>> RECOVER_PASSWORD,
>> AUTHENTICATE,
>> SOCIAL_CALLBACK
>> 
>> And it doesn't make sense to have a different conffiguration for every one...
>> But maybe we can group it into different groups?
>> 
>>> 
>>> 
>>>> Do you have any good ideas for a workaround?
>>>> Best
>>>> Michael
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> 
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>> 



From guydavis.ca at gmail.com  Sun Feb  1 10:16:01 2015
From: guydavis.ca at gmail.com (Guy Davis)
Date: Sun, 1 Feb 2015 08:16:01 -0700
Subject: [keycloak-dev] Building Keycloak from master
In-Reply-To: <54C6006C.5090909@redhat.com>
References: <CAAgmn1ou2FYOhPOtYj2DYK4F5kVFW=JVixW_p_zB5z_aBfEcJg@mail.gmail.com>
	<489787969.15871227.1422021187952.JavaMail.zimbra@redhat.com>
	<CAAgmn1o2-FPs__y8Z_kKK+zYCybUVjeGYnEFE3EfSEJir=HU+g@mail.gmail.com>
	<54C6006C.5090909@redhat.com>
Message-ID: <CAAgmn1rmKRQ3Jqh+fKP4y_4Fp114wRh4sH1z-gxc2OJcuNwzpA@mail.gmail.com>

Hi Marek,

Yes, I now can get a successful build this week against master.  However, I
don't see any packaged build output, similar to what I can download for the
1.1.0 release.  Is there a Maven command to get that packaged output that
for the master branch that I could then try to deploy into my JBoss EAP
6.1alpha container?

Your (and others) help is much appreciated.

Guy

On Mon, Jan 26, 2015 at 1:53 AM, Marek Posolda <mposolda at redhat.com> wrote:

>  Maybe you can try:
>
> mvn clean install -DskipTests=true
>
> Hope it helps,
> Marek
>
>
> On 23.1.2015 17:46, Guy Davis wrote:
>
> Hi Stian,
>
> Thanks for the correct maven command.  Yes, the failed tests seem to be
> preventing the generation of deployable artifiacts in a 'build' or similar
> folder.  Is there anyway to disable unit test execution on master to get
> the artifacts to try?
>
>  [image: Inline image 1]
>
>  Thanks,
> Guy
>
> On Fri, Jan 23, 2015 at 6:53 AM, Stian Thorgersen <stian at redhat.com>
> wrote:
>
>>
>>
>> ----- Original Message -----
>> > From: "Guy Davis" <guydavis.ca at gmail.com>
>> > To: keycloak-dev at lists.jboss.org
>> > Sent: Friday, January 23, 2015 2:39:04 PM
>> > Subject: [keycloak-dev] Building Keycloak from master
>> >
>> > Good day,
>> >
>> > I've been able to get the 1.1.0.Beta2 distribution running inside my
>> JBoss
>> > EAP 6.1alpha with the JBoss 7 adapter. However, I would like to try the
>> > latest work related to identity brokering by building the master
>> branch. I
>> > couldn't find build instructions in the master checkout from Git, so
>> tried
>> > the following generic steps:
>> >
>> >
>> >     1. mvn compile --> Succeeded
>> >     2. mvn package --> Failed with test errors.
>> >
>> > It would be great if you could point me to the steps to build master
>> into a
>> > distribution that I could then deploy into my local JBoss. I'm very much
>> > looking forward to trying out the latest work.
>>
>> # mvn clean install
>>
>> There seems to be some tests failing in master atm though
>>
>> >
>> > Thanks much,
>> > Guy
>> >
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150201/eca90e3b/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 40998 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150201/eca90e3b/attachment-0001.png 

From stian at redhat.com  Mon Feb  2 03:07:17 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 2 Feb 2015 03:07:17 -0500 (EST)
Subject: [keycloak-dev] Looking for a workaround...
In-Reply-To: <E031EBDE-B9EC-47F1-9B8C-C6BDBCC76CD1@me.com>
References: <ef0cd52d-966b-45c8-bb13-cf99cc9c5267@me.com>
	<742926378.3966720.1422624340264.JavaMail.zimbra@redhat.com>
	<E031EBDE-B9EC-47F1-9B8C-C6BDBCC76CD1@me.com>
Message-ID: <538053894.5208653.1422864437879.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Sunday, 1 February, 2015 4:09:35 PM
> Subject: Re: [keycloak-dev] Looking for a workaround...
> 
> I would look at the following scenario:
> A user starts with the login process and then takes a long break (15 mins or
> more) without locking his computer.

Is this not a relatively uncommon use-case? Would a error message with a link back to the application be a good enough solution?

> 
> There are critical processes like password changes, which should definitely
> expires after a view minutes and others like authentication which does not
> matter if they don?t expire during this break.

As above we need to improve the error page in this case. With a way back to the application as well.

> 
> critical actions:
> - OAUTH_GRANT
> - CODE_TO_TOKEN (already seperate)
> - VERIFY_EMAIL
> - RECOVER_PASSWORD
> - UPDATE_PROFILE
> - CONFIGURE_TOTP
> - UPDATE_PASSWORD
> 
> non-critical actions:
> - AUTHENTICATE
> - SOCIAL_CALLBACK
> 
> > Am 30.01.2015 um 14:25 schrieb Stian Thorgersen <stian at redhat.com>:
> > 
> > What groups would you propose?
> > 
> > ----- Original Message -----
> >> From: "Michael Gerber" <gerbermichi at me.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >> Sent: Monday, 26 January, 2015 4:23:49 PM
> >> Subject: Re: [keycloak-dev] Looking for a workaround...
> >> 
> >>> ----- Original Message -----
> >>>> From: "Michael Gerber" <gerbermichi at me.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>> Sent: Monday, January 26, 2015 2:10:59 PM
> >>>> Subject: Re: [keycloak-dev] Looking for a workaround...
> >>>> ----- Original Message -----
> >>>> From: "Michael Gerber" <gerbermichi at me.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> 
> >>>> Sent: Monday, January 26, 2015 1:37:53 PM
> >>>> Subject: [keycloak-dev] Looking for a workaround...
> >>>> Hi all,
> >>>> I receive a lot of bug reports from our test team because of the
> >>>> following
> >>>> two issues:
> >>>> - Reset password leads to 400 Bad Request (
> >>>> https://issues.jboss.org/browse/KEYCLOAK-1014 )
> >>>> This is a tricky one - we can't ignore the state variable as that would
> >>>> make
> >>>> it vulnerable.
> >>>> We could probably come up with an alternative way to generate and verify
> >>>> state variable though. Could be a HMAC for example.
> >>>> So you would remove the state cookie?
> >>> 
> >>> It could potentially be a solution - I started a separate thread on
> >>> keycloak-dev to discuss this.
> >>> 
> >>>> - Login attempt after "Login user action lifespan" leads to "Invalid
> >>>> username
> >>>> or password." ( https://issues.jboss.org/browse/KEYCLOAK-1015 )
> >>>> I agree that the error message is not very good, but I disagree with
> >>>> removing
> >>>> the expiration. Why not increase it to say 30 min? That's probably a
> >>>> more
> >>>> sensible timeout for reset password as well.
> >>>> I prefer an expiration of 5 min for the password update process, but
> >>>> thats
> >>>> a
> >>>> bit short for the authentication or password reset process.
> >>>> I think the best solution would be different expiration times for the
> >>>> different processes, wouldn't it?
> >>> 
> >>> Maybe - we do try to keep configuration options to a minimum as these
> >>> introduce complexity as well as potentials for bug/security issues.
> >> 
> >> I totaly understand that.
> >> You have currently the following actions:
> >> OAUTH_GRANT,
> >> CODE_TO_TOKEN,
> >> VERIFY_EMAIL,
> >> UPDATE_PROFILE,
> >> CONFIGURE_TOTP,
> >> UPDATE_PASSWORD,
> >> RECOVER_PASSWORD,
> >> AUTHENTICATE,
> >> SOCIAL_CALLBACK
> >> 
> >> And it doesn't make sense to have a different conffiguration for every
> >> one...
> >> But maybe we can group it into different groups?
> >> 
> >>> 
> >>> 
> >>>> Do you have any good ideas for a workaround?
> >>>> Best
> >>>> Michael
> >>>> _______________________________________________
> >>>> keycloak-dev mailing list
> >>>> keycloak-dev at lists.jboss.org
> >>>> 
> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>> 
> 
> 


From stian at redhat.com  Mon Feb  2 03:08:14 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 2 Feb 2015 03:08:14 -0500 (EST)
Subject: [keycloak-dev] Building Keycloak from master
In-Reply-To: <CAAgmn1rmKRQ3Jqh+fKP4y_4Fp114wRh4sH1z-gxc2OJcuNwzpA@mail.gmail.com>
References: <CAAgmn1ou2FYOhPOtYj2DYK4F5kVFW=JVixW_p_zB5z_aBfEcJg@mail.gmail.com>
	<489787969.15871227.1422021187952.JavaMail.zimbra@redhat.com>
	<CAAgmn1o2-FPs__y8Z_kKK+zYCybUVjeGYnEFE3EfSEJir=HU+g@mail.gmail.com>
	<54C6006C.5090909@redhat.com>
	<CAAgmn1rmKRQ3Jqh+fKP4y_4Fp114wRh4sH1z-gxc2OJcuNwzpA@mail.gmail.com>
Message-ID: <984667245.5209056.1422864494764.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Guy Davis" <guydavis.ca at gmail.com>
> To: "Marek Posolda" <mposolda at redhat.com>
> Cc: "Stian Thorgersen" <stian at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Sunday, 1 February, 2015 4:16:01 PM
> Subject: Re: [keycloak-dev] Building Keycloak from master
> 
> Hi Marek,
> 
> Yes, I now can get a successful build this week against master.  However, I
> don't see any packaged build output, similar to what I can download for the
> 1.1.0 release.  Is there a Maven command to get that packaged output that
> for the master branch that I could then try to deploy into my JBoss EAP
> 6.1alpha container?
> 
> Your (and others) help is much appreciated.

# mvn clean install -Pdistribution

The dists end up in distribution/appliance-dist/target

> 
> Guy
> 
> On Mon, Jan 26, 2015 at 1:53 AM, Marek Posolda <mposolda at redhat.com> wrote:
> 
> >  Maybe you can try:
> >
> > mvn clean install -DskipTests=true
> >
> > Hope it helps,
> > Marek
> >
> >
> > On 23.1.2015 17:46, Guy Davis wrote:
> >
> > Hi Stian,
> >
> > Thanks for the correct maven command.  Yes, the failed tests seem to be
> > preventing the generation of deployable artifiacts in a 'build' or similar
> > folder.  Is there anyway to disable unit test execution on master to get
> > the artifacts to try?
> >
> >  [image: Inline image 1]
> >
> >  Thanks,
> > Guy
> >
> > On Fri, Jan 23, 2015 at 6:53 AM, Stian Thorgersen <stian at redhat.com>
> > wrote:
> >
> >>
> >>
> >> ----- Original Message -----
> >> > From: "Guy Davis" <guydavis.ca at gmail.com>
> >> > To: keycloak-dev at lists.jboss.org
> >> > Sent: Friday, January 23, 2015 2:39:04 PM
> >> > Subject: [keycloak-dev] Building Keycloak from master
> >> >
> >> > Good day,
> >> >
> >> > I've been able to get the 1.1.0.Beta2 distribution running inside my
> >> JBoss
> >> > EAP 6.1alpha with the JBoss 7 adapter. However, I would like to try the
> >> > latest work related to identity brokering by building the master
> >> branch. I
> >> > couldn't find build instructions in the master checkout from Git, so
> >> tried
> >> > the following generic steps:
> >> >
> >> >
> >> >     1. mvn compile --> Succeeded
> >> >     2. mvn package --> Failed with test errors.
> >> >
> >> > It would be great if you could point me to the steps to build master
> >> into a
> >> > distribution that I could then deploy into my local JBoss. I'm very much
> >> > looking forward to trying out the latest work.
> >>
> >> # mvn clean install
> >>
> >> There seems to be some tests failing in master atm though
> >>
> >> >
> >> > Thanks much,
> >> > Guy
> >> >
> >> > _______________________________________________
> >> > keycloak-dev mailing list
> >> > keycloak-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >
> >
> >
> > _______________________________________________
> > keycloak-dev mailing
> > listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
> >
> 

From mposolda at redhat.com  Mon Feb  2 03:30:03 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 02 Feb 2015 09:30:03 +0100
Subject: [keycloak-dev] Facing Issue with Resource Server in Clustered
 Environment
In-Reply-To: <C5AF53298BAB5F4A88B28966E43B40AD0565BB76@xmb-aln-x12.cisco.com>
References: <C5AF53298BAB5F4A88B28966E43B40AD0565BB00@xmb-aln-x12.cisco.com>	<1743939526.3724664.1422602848465.JavaMail.zimbra@redhat.com>	<C5AF53298BAB5F4A88B28966E43B40AD0565BB18@xmb-aln-x12.cisco.com>	<1683679347.3736800.1422604072720.JavaMail.zimbra@redhat.com>
	<C5AF53298BAB5F4A88B28966E43B40AD0565BB76@xmb-aln-x12.cisco.com>
Message-ID: <54CF358B.2030308@redhat.com>

Hi,

it's not stateless by default. Data about keycloak authenticated 
principal are saved in HTTP session by default and can be replicated 
across cluster nodes (replication works as long as your application is 
marked as "distributable" in web.xml).

However we support stateless adapter, which won't save anything in HTTP 
Session and won't create HTTP session and JSESSIONID cookie at all 
(unless you're calling httpRequest.getSession() in your own 
application). Instead all the data are saved in cookie.

Some more info in docs: 
http://docs.jboss.org/keycloak/docs/1.1.0.Final/userguide/html/applicationClustering.html#stateless-token-store

Marek

On 30.1.2015 11:26, Bappaditya Gorai (bgorai) wrote:
> Thanks for clarifying.  So, I think adapter has become stateless in 1.1.0.Final. Is my understanding correct?
>
>
> -----Original Message-----
> From: Stian Thorgersen [mailto:stian at redhat.com]
> Sent: Friday, January 30, 2015 1:18 PM
> To: Bappaditya Gorai (bgorai)
> Cc: keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] Facing Issue with Resource Server in Clustered Environment
>
>
>
> ----- Original Message -----
>> From: "Bappaditya Gorai (bgorai)" <bgorai at cisco.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Friday, 30 January, 2015 8:38:49 AM
>> Subject: RE: [keycloak-dev] Facing Issue with Resource Server in Clustered	Environment
>>
>> We are not talking about clustering for Keycloak server. The setup is
>> for Resource Server (Keycloak Adapter)  in clustered environment.
> Same answer
>
>> Thanks
>> Bappaditya Gorai
>>
>> -----Original Message-----
>> From: Stian Thorgersen [mailto:stian at redhat.com]
>> Sent: Friday, January 30, 2015 12:57 PM
>> To: Bappaditya Gorai (bgorai)
>> Cc: keycloak-dev at lists.jboss.org
>> Subject: Re: [keycloak-dev] Facing Issue with Resource Server in
>> Clustered Environment
>>
>> 1.0.4.Final had very limited support for clustering, please upgrade to
>> 1.1.0.Final and refer to chapter 24 and 25 in the documentation
>> (http://docs.jboss.org/keycloak/docs/1.1.0.Final/userguide/html/clustering.html).
>>
>> ----- Original Message -----
>>> From: "Bappaditya Gorai (bgorai)" <bgorai at cisco.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Friday, 30 January, 2015 8:22:26 AM
>>> Subject: [keycloak-dev] Facing Issue with Resource Server in Clustered
>>> 	Environment
>>>
>>>
>>>
>>> Hi Team,
>>>
>>> Please find the details on setup and observation below. Please
>>> provide your suggestion on how to overcome this issue. We are using
>>> Keycloak 1.0.4.Final (Adapter & Server).
>>>
>>>
>>>
>>>
>>>
>>> Setup:
>>>
>>> 1. We have brought up Jboss cluster ( Using mod_cluster, httpd )
>>> with
>>> 2 nodes in domain mode and enabled session replication between these nodes.
>>>
>>> 2. Our Recourse server is deployed in this clustered environment
>>> with distributable and Sticky session Off.
>>>
>>>
>>>
>>> Behavior observed :
>>>
>>> During the Authorization/Authentication process ,when Initial
>>> call(Resource
>>> Access) lands on master and next redirection (post Code To token)
>>> falls on slave Adapter is treating it as a new session and
>>> redirecting to login URL again. So we ended up with circular redirection error.
>>> After further investigation seems like session replication delay is
>>> causing adapter to behave this way. As the redirection call happens
>>> very quickly and this results in circular redirection error.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> NOTE: Sticky Session in mod_cluster environment solves the issue but
>>> it does not provide true load balancing. Therefore we are not
>>> considering Stick session option.
>>>
>>>
>>>
>>>
>>>
>>> Thanks
>>>
>>> Bappaditya Gorai
>>>
>>> _______________________________________________
>>> 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 gerbermichi at me.com  Mon Feb  2 03:32:14 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Mon, 02 Feb 2015 08:32:14 +0000 (GMT)
Subject: [keycloak-dev] Looking for a workaround...
Message-ID: <9bc331a6-963a-424a-ab97-709efdc04165@me.com>



Am 02. Februar 2015 um 09:07 schrieb Stian Thorgersen <stian at redhat.com>:



----- Original Message -----
From: "Michael Gerber" <gerbermichi at me.com>
To: "Stian Thorgersen" <stian at redhat.com>
Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
Sent: Sunday, 1 February, 2015 4:09:35 PM
Subject: Re: [keycloak-dev] Looking for a workaround...
I would look at the following scenario:
A user starts with the login process and then takes a long break (15 mins or
more) without locking his computer.

Is this not a relatively uncommon use-case? Would a error message with a link back to the application be a good enough solution?
?
Unfortunately, it isn't. We have got customers which use one computer for multiple users. And this users are used to logout from the application without closing the browser.
The new user then uses the same browser to login. And this action would lead to an error, which is for the user not understandable.



There are critical processes like password changes, which should definitely
expires after a view minutes and others like authentication which does not
matter if they don?t expire during this break.

As above we need to improve the error page in this case. With a way back to the application as well.

critical actions:
- OAUTH_GRANT
- CODE_TO_TOKEN (already seperate)
- VERIFY_EMAIL
- RECOVER_PASSWORD
- UPDATE_PROFILE
- CONFIGURE_TOTP
- UPDATE_PASSWORD
non-critical actions:
- AUTHENTICATE
- SOCIAL_CALLBACK
> Am 30.01.2015 um 14:25 schrieb Stian Thorgersen <stian at redhat.com>:
>
> What groups would you propose?
>
> ----- Original Message -----
>> From: "Michael Gerber" <gerbermichi at me.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Monday, 26 January, 2015 4:23:49 PM
>> Subject: Re: [keycloak-dev] Looking for a workaround...
>>
>>> ----- Original Message -----
>>>> From: "Michael Gerber" <gerbermichi at me.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Sent: Monday, January 26, 2015 2:10:59 PM
>>>> Subject: Re: [keycloak-dev] Looking for a workaround...
>>>> ----- Original Message -----
>>>> From: "Michael Gerber" <gerbermichi at me.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>>
>>>> Sent: Monday, January 26, 2015 1:37:53 PM
>>>> Subject: [keycloak-dev] Looking for a workaround...
>>>> Hi all,
>>>> I receive a lot of bug reports from our test team because of the
>>>> following
>>>> two issues:
>>>> - Reset password leads to 400 Bad Request (
>>>> https://issues.jboss.org/browse/KEYCLOAK-1014 )
>>>> This is a tricky one - we can't ignore the state variable as that would
>>>> make
>>>> it vulnerable.
>>>> We could probably come up with an alternative way to generate and verify
>>>> state variable though. Could be a HMAC for example.
>>>> So you would remove the state cookie?
>>>
>>> It could potentially be a solution - I started a separate thread on
>>> keycloak-dev to discuss this.
>>>
>>>> - Login attempt after "Login user action lifespan" leads to "Invalid
>>>> username
>>>> or password." ( https://issues.jboss.org/browse/KEYCLOAK-1015 )
>>>> I agree that the error message is not very good, but I disagree with
>>>> removing
>>>> the expiration. Why not increase it to say 30 min? That's probably a
>>>> more
>>>> sensible timeout for reset password as well.
>>>> I prefer an expiration of 5 min for the password update process, but
>>>> thats
>>>> a
>>>> bit short for the authentication or password reset process.
>>>> I think the best solution would be different expiration times for the
>>>> different processes, wouldn't it?
>>>
>>> Maybe - we do try to keep configuration options to a minimum as these
>>> introduce complexity as well as potentials for bug/security issues.
>>
>> I totaly understand that.
>> You have currently the following actions:
>> OAUTH_GRANT,
>> CODE_TO_TOKEN,
>> VERIFY_EMAIL,
>> UPDATE_PROFILE,
>> CONFIGURE_TOTP,
>> UPDATE_PASSWORD,
>> RECOVER_PASSWORD,
>> AUTHENTICATE,
>> SOCIAL_CALLBACK
>>
>> And it doesn't make sense to have a different conffiguration for every
>> one...
>> But maybe we can group it into different groups?
>>
>>>
>>>
>>>> Do you have any good ideas for a workaround?
>>>> Best
>>>> 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/20150202/f4fea3c6/attachment-0001.html 

From daniel.baxter at cira.ca  Mon Feb  2 11:03:44 2015
From: daniel.baxter at cira.ca (Daniel Baxter)
Date: Mon, 2 Feb 2015 16:03:44 +0000
Subject: [keycloak-dev] Slow Direct Grants API endpoint
In-Reply-To: <1931160200.10779706.1421325416961.JavaMail.zimbra@redhat.com>
References: <152ADF7679FD37488EE24A3FB5CA9AE1D4DA05CA@EXCH-01.CORP.CIRA.CA>
	<853465969.10046513.1421243158655.JavaMail.zimbra@redhat.com>
	<152ADF7679FD37488EE24A3FB5CA9AE1D4DA11BF@EXCH-01.CORP.CIRA.CA>
	<86460392.10074076.1421245169796.JavaMail.zimbra@redhat.com>
	<152ADF7679FD37488EE24A3FB5CA9AE1D4DA11F7@EXCH-01.CORP.CIRA.CA>
	<1931160200.10779706.1421325416961.JavaMail.zimbra@redhat.com>
Message-ID: <152ADF7679FD37488EE24A3FB5CA9AE1D4DC840E@EXCH-02.CORP.CIRA.CA>

Hi,

I have just finished some testing on 1.1.0 Final and found that the core problem was that through an abundance of caution we have configured hash iterations to 100,000 (which I of course typoed to 1M on Beta 2 when I configured it). The performance delta between 1.0 and 1.1 is explained by the typo there. However, even with the change to 100K in place I found the end point was still too slow (600~800ms) and discovered that it scaled linearly down as I reduced the iterations.

So I guess the question now is how many iterations is the default and how many would be a recommended "overly cautious" amount of iterations. I understand that keycloak defaults to Bcrypt hashing which is designed explicitly to be computationally expensive so I imagine iterations in the scope of 10-50 is probably sufficient to keep the passwords safe.

- Daniel

-----Original Message-----
From: Stian Thorgersen [mailto:stian at redhat.com] 
Sent: Thursday, January 15, 2015 7:37 AM
To: Daniel Baxter
Cc: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] Slow Direct Grants API endpoint

Just ran some perf tests with default settings, 10 users and 10000 requests:

  Version                Average (ms)    Throughput
  -------------------------------------------------
  1.0.4.Final            18              468
  1.1.0.Beta2            19              470
  1.1.0.Final-SNAPSHOT   20              426


----- Original Message -----
> From: "Daniel Baxter" <daniel.baxter at cira.ca>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 14 January, 2015 3:56:03 PM
> Subject: RE: [keycloak-dev] Slow Direct Grants API endpoint
> 
> Honestly I don't know how to check what is being used. I assume it 
> would be whatever Keycloak Appliance defaults to. I checked with the 
> guy who configured 1.0.4 for the other application and he doesn't know 
> what we are using or how to configure it either. Sorry.
> 
> - Daniel
> 
> -----Original Message-----
> From: Stian Thorgersen [mailto:stian at redhat.com]
> Sent: Wednesday, January 14, 2015 9:19 AM
> To: Daniel Baxter
> Cc: keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] Slow Direct Grants API endpoint
> 
> What user session provider are you using?
> 
> ----- Original Message -----
> > From: "Daniel Baxter" <daniel.baxter at cira.ca>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Wednesday, 14 January, 2015 3:01:17 PM
> > Subject: RE: [keycloak-dev] Slow Direct Grants API endpoint
> > 
> > I am working with our ops team to configure 1.1.x with the same 
> > level of hardware as our development 1.0.4 system (right now it is 
> > running locally on a XEON workstation with piles of RAM).
> > 
> > Both are connected to postgres databases and I am the only person 
> > working on this portion of the project so it is just 1 user at a 
> > time right now for 1.1.x. I have tested the database connection and 
> > there is no real discernable performance irregularities for anything 
> > that runs against that database.
> > 
> > For Keycloak itself, it is mostly straight out of the box appliance 
> > install for both 1.0.4 and 1.1.x and it runs on a single machine for 
> > development use (I believe our prod deployment is/will be clustered).
> > The performance I am seeing is timeable on a stop watch for 1.1 and 
> > near enough to instant for
> > 1.0.4 (under 500 ms). Easily an order of magnitude. Given the 
> > response I got (regarding the unexpectedness of the slow behaviour) 
> > I want to make sure I have a completely fair comparison and am 
> > working to set up
> > 1.1 on a dedicated development server to make the comparison 
> > completely fair.
> > 
> > - Daniel
> > 
> > -----Original Message-----
> > From: Stian Thorgersen [mailto:stian at redhat.com]
> > Sent: Wednesday, January 14, 2015 8:46 AM
> > To: Daniel Baxter
> > Cc: keycloak-dev at lists.jboss.org
> > Subject: Re: [keycloak-dev] Slow Direct Grants API endpoint
> > 
> > Direct grants are expected to be a little bit slower in 1.1.x due to 
> > the requirement to persist more, but should certainly not be seconds.
> > 
> > Can you give some more details please? Including
> > 
> > * What DB are you using?
> > * Are you using mem, infinispan or jpa user session provider?
> > * Clustered?
> > * How many concurrent requests/users are you testing with?
> > 
> > Any more accurate performance stats would also be helpful
> > 
> > ----- Original Message -----
> > > From: "Daniel Baxter" <daniel.baxter at cira.ca>
> > > To: keycloak-dev at lists.jboss.org
> > > Sent: Monday, 12 January, 2015 9:23:42 PM
> > > Subject: [keycloak-dev] Slow Direct Grants API endpoint
> > > 
> > > 
> > > 
> > > Hi,
> > > 
> > > 
> > > 
> > > I am attempting to integrate Keycloak into an existing application 
> > > to replace the homegrown user management system in place. We have 
> > > a new project built from the ground up on Keycloak 1.0.4.Final 
> > > which is exhibiting good performance. However this app that I am 
> > > porting has a remoting component that connects to the server with 
> > > bare username/password credentials over the EJB Remoting 
> > > framework. I was hoping to use 1.1.0 (currently Beta2) which 
> > > provides a DirectAccessGrantsLoginModule which does exactly what I 
> > > want (turns username and password into a KeycloakPrincipal). 
> > > However, the turn around time from Keycloak is on the order of several seconds.
> > > 
> > > 
> > > 
> > > I have used a bare REST client to execute the POSTs to both our
> > > 1.0.4 Keycloak and 1.1.0 Keycloak instances and have noted an 
> > > order of magnitude difference in getting a response. Is this a 
> > > known issue (I cannot find anything in the public bugs/tasks 
> > > list)? Or is this due to the Beta status leaving additional 
> > > performance affecting logging or instrumentation in place?
> > > 
> > > 
> > > 
> > > Thanks,
> > > 
> > > 
> > > 
> > > Daniel
> > > 
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> 


From lvadali at cisco.com  Tue Feb  3 02:03:56 2015
From: lvadali at cisco.com (Lakshmi Narayana VADALI (lvadali))
Date: Tue, 3 Feb 2015 07:03:56 +0000
Subject: [keycloak-dev] Do we have Login SPI with Keycloak_1.1.0_Final?
Message-ID: <BEA822DA38EAC24E869EEB395ABFA21C0D166FB5@xmb-aln-x08.cisco.com>


Congrats Team for Keycloak 1.1.0.Final Release loaded with features.

We are planning to integrate our code with Latest Keycloak.  So Can you please confirm do we have full support for Below features in Keycloak_1.1.0_Final Release.


1.       Login SPI

2.       HA Support

3.       Clustering Support

Thanks,
Lakshmi Narayana V
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150203/9604b7a5/attachment.html 

From jaekun.choi at gmail.com  Tue Feb  3 02:42:56 2015
From: jaekun.choi at gmail.com (Jae Choi)
Date: Tue, 3 Feb 2015 18:42:56 +1100
Subject: [keycloak-dev] How to refresh and update token
Message-ID: <CAPLm6jJO3tVftxyXL3dF3PxSEQ0X86dAY5hW7CRKb752=G_Exw@mail.gmail.com>

Is there a way to refresh token with Javascript Angular adaptor so that
Custom User Federator is updated again?

I'm actually storing token retrieved from another service provider as user
attribute. It is stored first time when the user logs in (and saves the
user data into the Keycloak database) but there isn't easy way to update
the attribute with the adaptor?

Thanks,

-- 
Kind Regards,
Jae Choi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150203/8e4fa09b/attachment.html 

From stian at redhat.com  Tue Feb  3 02:59:00 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 3 Feb 2015 02:59:00 -0500 (EST)
Subject: [keycloak-dev] Slow Direct Grants API endpoint
In-Reply-To: <152ADF7679FD37488EE24A3FB5CA9AE1D4DC840E@EXCH-02.CORP.CIRA.CA>
References: <152ADF7679FD37488EE24A3FB5CA9AE1D4DA05CA@EXCH-01.CORP.CIRA.CA>
	<853465969.10046513.1421243158655.JavaMail.zimbra@redhat.com>
	<152ADF7679FD37488EE24A3FB5CA9AE1D4DA11BF@EXCH-01.CORP.CIRA.CA>
	<86460392.10074076.1421245169796.JavaMail.zimbra@redhat.com>
	<152ADF7679FD37488EE24A3FB5CA9AE1D4DA11F7@EXCH-01.CORP.CIRA.CA>
	<1931160200.10779706.1421325416961.JavaMail.zimbra@redhat.com>
	<152ADF7679FD37488EE24A3FB5CA9AE1D4DC840E@EXCH-02.CORP.CIRA.CA>
Message-ID: <1548314231.6086338.1422950340992.JavaMail.zimbra@redhat.com>

Yep, that would do it ;)

The hashing algorithm used by Keycloak is PBKDF2 and we only use 1 iteration by default, but we highly recommend increasing that though. We should probably also considering increasing the default.

It's hard to give a definitive answer to this question as it is all relative, but for increased safety I'd say you should be looking at 5-10K iterations. Obviously the higher the better and you can and should cluster Keycloak for increased scalability and availability.

----- Original Message -----
> From: "Daniel Baxter" <daniel.baxter at cira.ca>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 2 February, 2015 5:03:44 PM
> Subject: RE: [keycloak-dev] Slow Direct Grants API endpoint
> 
> Hi,
> 
> I have just finished some testing on 1.1.0 Final and found that the core
> problem was that through an abundance of caution we have configured hash
> iterations to 100,000 (which I of course typoed to 1M on Beta 2 when I
> configured it). The performance delta between 1.0 and 1.1 is explained by
> the typo there. However, even with the change to 100K in place I found the
> end point was still too slow (600~800ms) and discovered that it scaled
> linearly down as I reduced the iterations.
> 
> So I guess the question now is how many iterations is the default and how
> many would be a recommended "overly cautious" amount of iterations. I
> understand that keycloak defaults to Bcrypt hashing which is designed
> explicitly to be computationally expensive so I imagine iterations in the
> scope of 10-50 is probably sufficient to keep the passwords safe.
> 
> - Daniel
> 
> -----Original Message-----
> From: Stian Thorgersen [mailto:stian at redhat.com]
> Sent: Thursday, January 15, 2015 7:37 AM
> To: Daniel Baxter
> Cc: keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] Slow Direct Grants API endpoint
> 
> Just ran some perf tests with default settings, 10 users and 10000 requests:
> 
>   Version                Average (ms)    Throughput
>   -------------------------------------------------
>   1.0.4.Final            18              468
>   1.1.0.Beta2            19              470
>   1.1.0.Final-SNAPSHOT   20              426
> 
> 
> ----- Original Message -----
> > From: "Daniel Baxter" <daniel.baxter at cira.ca>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Wednesday, 14 January, 2015 3:56:03 PM
> > Subject: RE: [keycloak-dev] Slow Direct Grants API endpoint
> > 
> > Honestly I don't know how to check what is being used. I assume it
> > would be whatever Keycloak Appliance defaults to. I checked with the
> > guy who configured 1.0.4 for the other application and he doesn't know
> > what we are using or how to configure it either. Sorry.
> > 
> > - Daniel
> > 
> > -----Original Message-----
> > From: Stian Thorgersen [mailto:stian at redhat.com]
> > Sent: Wednesday, January 14, 2015 9:19 AM
> > To: Daniel Baxter
> > Cc: keycloak-dev at lists.jboss.org
> > Subject: Re: [keycloak-dev] Slow Direct Grants API endpoint
> > 
> > What user session provider are you using?
> > 
> > ----- Original Message -----
> > > From: "Daniel Baxter" <daniel.baxter at cira.ca>
> > > To: "Stian Thorgersen" <stian at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Wednesday, 14 January, 2015 3:01:17 PM
> > > Subject: RE: [keycloak-dev] Slow Direct Grants API endpoint
> > > 
> > > I am working with our ops team to configure 1.1.x with the same
> > > level of hardware as our development 1.0.4 system (right now it is
> > > running locally on a XEON workstation with piles of RAM).
> > > 
> > > Both are connected to postgres databases and I am the only person
> > > working on this portion of the project so it is just 1 user at a
> > > time right now for 1.1.x. I have tested the database connection and
> > > there is no real discernable performance irregularities for anything
> > > that runs against that database.
> > > 
> > > For Keycloak itself, it is mostly straight out of the box appliance
> > > install for both 1.0.4 and 1.1.x and it runs on a single machine for
> > > development use (I believe our prod deployment is/will be clustered).
> > > The performance I am seeing is timeable on a stop watch for 1.1 and
> > > near enough to instant for
> > > 1.0.4 (under 500 ms). Easily an order of magnitude. Given the
> > > response I got (regarding the unexpectedness of the slow behaviour)
> > > I want to make sure I have a completely fair comparison and am
> > > working to set up
> > > 1.1 on a dedicated development server to make the comparison
> > > completely fair.
> > > 
> > > - Daniel
> > > 
> > > -----Original Message-----
> > > From: Stian Thorgersen [mailto:stian at redhat.com]
> > > Sent: Wednesday, January 14, 2015 8:46 AM
> > > To: Daniel Baxter
> > > Cc: keycloak-dev at lists.jboss.org
> > > Subject: Re: [keycloak-dev] Slow Direct Grants API endpoint
> > > 
> > > Direct grants are expected to be a little bit slower in 1.1.x due to
> > > the requirement to persist more, but should certainly not be seconds.
> > > 
> > > Can you give some more details please? Including
> > > 
> > > * What DB are you using?
> > > * Are you using mem, infinispan or jpa user session provider?
> > > * Clustered?
> > > * How many concurrent requests/users are you testing with?
> > > 
> > > Any more accurate performance stats would also be helpful
> > > 
> > > ----- Original Message -----
> > > > From: "Daniel Baxter" <daniel.baxter at cira.ca>
> > > > To: keycloak-dev at lists.jboss.org
> > > > Sent: Monday, 12 January, 2015 9:23:42 PM
> > > > Subject: [keycloak-dev] Slow Direct Grants API endpoint
> > > > 
> > > > 
> > > > 
> > > > Hi,
> > > > 
> > > > 
> > > > 
> > > > I am attempting to integrate Keycloak into an existing application
> > > > to replace the homegrown user management system in place. We have
> > > > a new project built from the ground up on Keycloak 1.0.4.Final
> > > > which is exhibiting good performance. However this app that I am
> > > > porting has a remoting component that connects to the server with
> > > > bare username/password credentials over the EJB Remoting
> > > > framework. I was hoping to use 1.1.0 (currently Beta2) which
> > > > provides a DirectAccessGrantsLoginModule which does exactly what I
> > > > want (turns username and password into a KeycloakPrincipal).
> > > > However, the turn around time from Keycloak is on the order of several
> > > > seconds.
> > > > 
> > > > 
> > > > 
> > > > I have used a bare REST client to execute the POSTs to both our
> > > > 1.0.4 Keycloak and 1.1.0 Keycloak instances and have noted an
> > > > order of magnitude difference in getting a response. Is this a
> > > > known issue (I cannot find anything in the public bugs/tasks
> > > > list)? Or is this due to the Beta status leaving additional
> > > > performance affecting logging or instrumentation in place?
> > > > 
> > > > 
> > > > 
> > > > Thanks,
> > > > 
> > > > 
> > > > 
> > > > Daniel
> > > > 
> > > > _______________________________________________
> > > > keycloak-dev mailing list
> > > > keycloak-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > 
> > 
> 

From stian at redhat.com  Tue Feb  3 03:10:06 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 3 Feb 2015 03:10:06 -0500 (EST)
Subject: [keycloak-dev] Do we have Login SPI with Keycloak_1.1.0_Final?
In-Reply-To: <BEA822DA38EAC24E869EEB395ABFA21C0D166FB5@xmb-aln-x08.cisco.com>
References: <BEA822DA38EAC24E869EEB395ABFA21C0D166FB5@xmb-aln-x08.cisco.com>
Message-ID: <1399704026.6089139.1422951006878.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Lakshmi Narayana VADALI (lvadali)" <lvadali at cisco.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 3 February, 2015 8:03:56 AM
> Subject: [keycloak-dev] Do we have Login SPI with Keycloak_1.1.0_Final?
> 
> 
> 
> 
> 
> Congrats Team for Keycloak 1.1.0.Final Release loaded with features.
> 
> 
> 
> We are planning to integrate our code with Latest Keycloak. So Can you please
> confirm do we have full support for Below features in Keycloak_1.1.0_Final
> Release.
> 
> 
> 
> 1. Login SPI

Not sure what you're referring to

> 
> 2. HA Support

Yes

> 
> 3. Clustering Support

Yes, it's one of the top new features in 1.1, so yes of course

> 
> 
> 
> Thanks,
> 
> Lakshmi Narayana V
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From mposolda at redhat.com  Tue Feb  3 04:05:19 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 03 Feb 2015 10:05:19 +0100
Subject: [keycloak-dev] Automatic logout from KC admin console for
	non-authorized users
Message-ID: <54D08F4F.90109@redhat.com>

Right now, when user goes to keycloak admin console and he doesn't have 
access (any admin roles assigned), he is logged out automatically. It's 
done by "whoami" endpoint, which returns 401 in this case.

Shouldn't we instead just display some notification like "Forbidden, you 
don't have access" instead of automatically logout user?

My point is links between various admin consoles. For example when user 
is logged in hawtio admin console and he click on link to Keycloak admin 
console. But when he don't have access, he is logged out automatically, 
which does SSO logout and logout him also from hawtio. To me it looks 
like bit confusing behaviour tbh.

Also do we have plan to add support for referrer in KC admin console 
similarly like account mgmt has?

Marek

From stian at redhat.com  Tue Feb  3 04:08:50 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 3 Feb 2015 04:08:50 -0500 (EST)
Subject: [keycloak-dev] WildFly integration (READ ME!)
In-Reply-To: <602835294.6101502.1422953552435.JavaMail.zimbra@redhat.com>
Message-ID: <969708031.6108771.1422954530044.JavaMail.zimbra@redhat.com>

All,

We have a few decisions to make in the not so far future. I'm away from Thursday, so let's have a hangout when I get back on the 17th February if that works for everyone.

The list of things to discuss includes:

* Drop keycloak-server.json - Should we drop our own configuration file and use DMR (standalone.xml)

* Keycloak CLI - Should we create our own or use WildFly CLI

* Admin operations exposed over DMR - Should we expose none, some or all admin operations over DMR? If we expose all should we deprecate the current REST endpoints?

* Packaging/distribution - How do we distribute Keycloak? Options:
  - Full WildFly
  - Core/web WildFly
  - Overlay/installer/feature-pack to install to existing WF and EAP
  - WAR bundle

* How should we deal with providers, themes and keycloak-server.json in domain-mode

* MSC all the way - We can deploy directly through the Undertow sub-system instead of deploying a WAR from the sub-system

* Split sub-systems - Should we split the sub-system in two? One for the auth-server and another for the adapter

* Deployable to other containers - Should it be possible to deploy Keycloak to Tomcat, Jetty, Fuse, etc..? One option could be to have reduced features in other containers (for example no client-cert)

Please add any other relevant topics.

Next big discussion I want to have is about distribution of adapters, but let's do one at a time ;)

From stian at redhat.com  Tue Feb  3 04:15:07 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 3 Feb 2015 04:15:07 -0500 (EST)
Subject: [keycloak-dev] Automatic logout from KC admin console
	for	non-authorized users
In-Reply-To: <54D08F4F.90109@redhat.com>
References: <54D08F4F.90109@redhat.com>
Message-ID: <2101531218.6110818.1422954907605.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 3 February, 2015 10:05:19 AM
> Subject: [keycloak-dev] Automatic logout from KC admin console for	non-authorized users
> 
> Right now, when user goes to keycloak admin console and he doesn't have
> access (any admin roles assigned), he is logged out automatically. It's
> done by "whoami" endpoint, which returns 401 in this case.

+1000 Logging-out the user is just plain stupid, cant' believe we do that

> 
> Shouldn't we instead just display some notification like "Forbidden, you
> don't have access" instead of automatically logout user?
> 
> My point is links between various admin consoles. For example when user
> is logged in hawtio admin console and he click on link to Keycloak admin
> console. But when he don't have access, he is logged out automatically,
> which does SSO logout and logout him also from hawtio. To me it looks
> like bit confusing behaviour tbh.
> 
> Also do we have plan to add support for referrer in KC admin console
> similarly like account mgmt has?

I don't think referrer is the correct approach. What about if we add a feature to Keycloak that lets you retrieve all applications a user has access to (where a user has at least one role?) and that has a base url configured for it (maybe this should be changed to default page). Then we can use this information to add an application switcher to all consoles (like Google has, see attachment). This is probably something we should discuss with Management .Next guys though ;)

> 
> Marek
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: app-switcher.png
Type: image/png
Size: 25938 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150203/e3302abb/attachment-0001.png 

From gerbermichi at me.com  Tue Feb  3 04:16:57 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Tue, 03 Feb 2015 09:16:57 +0000 (GMT)
Subject: [keycloak-dev] Looking for a workaround...
Message-ID: <3e5b29d6-633d-49b6-881a-3424a086bf2a@me.com>

Hi All,

I've seen that both bugs have the Fix Version 1.1.1.Final, that's great.
Do you already know the release date for this version?

Best
Michael

Am 02. Februar 2015 um 09:32 schrieb Michael Gerber <gerbermichi at me.com>:



Am 02. Februar 2015 um 09:07 schrieb Stian Thorgersen <stian at redhat.com>:



----- Original Message -----
From: "Michael Gerber" <gerbermichi at me.com>
To: "Stian Thorgersen" <stian at redhat.com>
Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
Sent: Sunday, 1 February, 2015 4:09:35 PM
Subject: Re: [keycloak-dev] Looking for a workaround...
I would look at the following scenario:
A user starts with the login process and then takes a long break (15 mins or
more) without locking his computer.

Is this not a relatively uncommon use-case? Would a error message with a link back to the application be a good enough solution?
?
Unfortunately, it isn't. We have got customers which use one computer for multiple users. And this users are used to logout from the application without closing the browser.
The new user then uses the same browser to login. And this action would lead to an error, which is for the user not understandable.



There are critical processes like password changes, which should definitely
expires after a view minutes and others like authentication which does not
matter if they don?t expire during this break.

As above we need to improve the error page in this case. With a way back to the application as well.

critical actions:
- OAUTH_GRANT
- CODE_TO_TOKEN (already seperate)
- VERIFY_EMAIL
- RECOVER_PASSWORD
- UPDATE_PROFILE
- CONFIGURE_TOTP
- UPDATE_PASSWORD
non-critical actions:
- AUTHENTICATE
- SOCIAL_CALLBACK
> Am 30.01.2015 um 14:25 schrieb Stian Thorgersen <stian at redhat.com>:
>
> What groups would you propose?
>
> ----- Original Message -----
>> From: "Michael Gerber" <gerbermichi at me.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Monday, 26 January, 2015 4:23:49 PM
>> Subject: Re: [keycloak-dev] Looking for a workaround...
>>
>>> ----- Original Message -----
>>>> From: "Michael Gerber" <gerbermichi at me.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Sent: Monday, January 26, 2015 2:10:59 PM
>>>> Subject: Re: [keycloak-dev] Looking for a workaround...
>>>> ----- Original Message -----
>>>> From: "Michael Gerber" <gerbermichi at me.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>>
>>>> Sent: Monday, January 26, 2015 1:37:53 PM
>>>> Subject: [keycloak-dev] Looking for a workaround...
>>>> Hi all,
>>>> I receive a lot of bug reports from our test team because of the
>>>> following
>>>> two issues:
>>>> - Reset password leads to 400 Bad Request (
>>>> https://issues.jboss.org/browse/KEYCLOAK-1014 )
>>>> This is a tricky one - we can't ignore the state variable as that would
>>>> make
>>>> it vulnerable.
>>>> We could probably come up with an alternative way to generate and verify
>>>> state variable though. Could be a HMAC for example.
>>>> So you would remove the state cookie?
>>>
>>> It could potentially be a solution - I started a separate thread on
>>> keycloak-dev to discuss this.
>>>
>>>> - Login attempt after "Login user action lifespan" leads to "Invalid
>>>> username
>>>> or password." ( https://issues.jboss.org/browse/KEYCLOAK-1015 )
>>>> I agree that the error message is not very good, but I disagree with
>>>> removing
>>>> the expiration. Why not increase it to say 30 min? That's probably a
>>>> more
>>>> sensible timeout for reset password as well.
>>>> I prefer an expiration of 5 min for the password update process, but
>>>> thats
>>>> a
>>>> bit short for the authentication or password reset process.
>>>> I think the best solution would be different expiration times for the
>>>> different processes, wouldn't it?
>>>
>>> Maybe - we do try to keep configuration options to a minimum as these
>>> introduce complexity as well as potentials for bug/security issues.
>>
>> I totaly understand that.
>> You have currently the following actions:
>> OAUTH_GRANT,
>> CODE_TO_TOKEN,
>> VERIFY_EMAIL,
>> UPDATE_PROFILE,
>> CONFIGURE_TOTP,
>> UPDATE_PASSWORD,
>> RECOVER_PASSWORD,
>> AUTHENTICATE,
>> SOCIAL_CALLBACK
>>
>> And it doesn't make sense to have a different conffiguration for every
>> one...
>> But maybe we can group it into different groups?
>>
>>>
>>>
>>>> Do you have any good ideas for a workaround?
>>>> Best
>>>> 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/20150203/2de6cc0c/attachment.html 

From mposolda at redhat.com  Tue Feb  3 04:31:13 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 03 Feb 2015 10:31:13 +0100
Subject: [keycloak-dev] Automatic logout from KC admin console for
 non-authorized users
In-Reply-To: <2101531218.6110818.1422954907605.JavaMail.zimbra@redhat.com>
References: <54D08F4F.90109@redhat.com>
	<2101531218.6110818.1422954907605.JavaMail.zimbra@redhat.com>
Message-ID: <54D09561.4030306@redhat.com>

On 3.2.2015 10:15, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 3 February, 2015 10:05:19 AM
>> Subject: [keycloak-dev] Automatic logout from KC admin console for	non-authorized users
>>
>> Right now, when user goes to keycloak admin console and he doesn't have
>> access (any admin roles assigned), he is logged out automatically. It's
>> done by "whoami" endpoint, which returns 401 in this case.
> +1000 Logging-out the user is just plain stupid, cant' believe we do that
I've created https://issues.jboss.org/browse/KEYCLOAK-1025
>
>> Shouldn't we instead just display some notification like "Forbidden, you
>> don't have access" instead of automatically logout user?
>>
>> My point is links between various admin consoles. For example when user
>> is logged in hawtio admin console and he click on link to Keycloak admin
>> console. But when he don't have access, he is logged out automatically,
>> which does SSO logout and logout him also from hawtio. To me it looks
>> like bit confusing behaviour tbh.
>>
>> Also do we have plan to add support for referrer in KC admin console
>> similarly like account mgmt has?
> I don't think referrer is the correct approach. What about if we add a feature to Keycloak that lets you retrieve all applications a user has access to (where a user has at least one role?) and that has a base url configured for it (maybe this should be changed to default page). Then we can use this information to add an application switcher to all consoles (like Google has, see attachment). This is probably something we should discuss with Management .Next guys though ;)
Looks like great solution from long-term perspective. It's perhaps 
something to discuss with management .next to see if other "product 
consoles" are interested in this feature.

Marek
>
>> Marek
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From lvadali at cisco.com  Tue Feb  3 04:58:09 2015
From: lvadali at cisco.com (Lakshmi Narayana VADALI (lvadali))
Date: Tue, 3 Feb 2015 09:58:09 +0000
Subject: [keycloak-dev] Do we have Login SPI with Keycloak_1.1.0_Final?
In-Reply-To: <1399704026.6089139.1422951006878.JavaMail.zimbra@redhat.com>
References: <BEA822DA38EAC24E869EEB395ABFA21C0D166FB5@xmb-aln-x08.cisco.com>
	<1399704026.6089139.1422951006878.JavaMail.zimbra@redhat.com>
Message-ID: <BEA822DA38EAC24E869EEB395ABFA21C0D167015@xmb-aln-x08.cisco.com>

By LogIn SPI  we mean any SPI for Customizing authentication. 

We need to authenticate  devices which will come for authentication with their  certificate. 
As per keycloak-dev suggestion currently (Integrated with Keycloak_1.0.4_Final) we are following below procedure
	1. Create a new jaxrs class with two methods, one that returns the nounce and another that authenticates the client, look at TokenService as a reference for this, specifically at TokenService.grantAccessToken.
	2. Extend KeycloakApplication to add your new class 
	3. Create your own auth-server war - see 'project-integrations/aerogear-ups' as a reference for this
Also we were told that keycloak will come up with hooks whereby we can plug in our authentication mechanism. We want to know whether hooks(LogIn SPI) are provided with Latest Keycloak 1.1.0_Final Release. 

For reference attaching previous discussion with Keycloak-dev.

Our Requirement:
Instead of Existing one step authentication(user/pass), We  need custom certificate based authentication which is 2-step Authentication as below:
    1. Bypass Login screen , instead generate nonce(UUID) and provide intermediate Endpoint URL for Certificate based authentication.
    2. Client will come to Certificate based authentication with its certificate and encrypted UUID.  After Validating Encrypted UUID 
       and Client certificate server should generate ?Access code?.


Thanks,
Lakshmi Narayana V


-----Original Message-----
From: Stian Thorgersen [mailto:stian at redhat.com] 
Sent: Tuesday, February 03, 2015 1:40 PM
To: Lakshmi Narayana VADALI (lvadali)
Cc: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] Do we have Login SPI with Keycloak_1.1.0_Final?



----- Original Message -----
> From: "Lakshmi Narayana VADALI (lvadali)" <lvadali at cisco.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 3 February, 2015 8:03:56 AM
> Subject: [keycloak-dev] Do we have Login SPI with Keycloak_1.1.0_Final?
> 
> 
> 
> 
> 
> Congrats Team for Keycloak 1.1.0.Final Release loaded with features.
> 
> 
> 
> We are planning to integrate our code with Latest Keycloak. So Can you 
> please confirm do we have full support for Below features in 
> Keycloak_1.1.0_Final Release.
> 
> 
> 
> 1. Login SPI

Not sure what you're referring to

> 
> 2. HA Support

Yes

> 
> 3. Clustering Support

Yes, it's one of the top new features in 1.1, so yes of course

> 
> 
> 
> Thanks,
> 
> Lakshmi Narayana V
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
-------------- next part --------------
An embedded message was scrubbed...
From: Stian Thorgersen <stian at redhat.com>
Subject: Re: [keycloak-dev] Customising Keycloak Authentication flow
Date: Tue, 9 Sep 2014 09:43:43 +0000
Size: 8441
Url: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150203/61ef02dc/attachment-0001.mht 

From stian at redhat.com  Tue Feb  3 05:08:00 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 3 Feb 2015 05:08:00 -0500 (EST)
Subject: [keycloak-dev] Do we have Login SPI with Keycloak_1.1.0_Final?
In-Reply-To: <BEA822DA38EAC24E869EEB395ABFA21C0D167015@xmb-aln-x08.cisco.com>
References: <BEA822DA38EAC24E869EEB395ABFA21C0D166FB5@xmb-aln-x08.cisco.com>
	<1399704026.6089139.1422951006878.JavaMail.zimbra@redhat.com>
	<BEA822DA38EAC24E869EEB395ABFA21C0D167015@xmb-aln-x08.cisco.com>
Message-ID: <141351273.6152700.1422958080217.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Lakshmi Narayana VADALI (lvadali)" <lvadali at cisco.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 3 February, 2015 10:58:09 AM
> Subject: RE: [keycloak-dev] Do we have Login SPI with Keycloak_1.1.0_Final?
> 
> By LogIn SPI  we mean any SPI for Customizing authentication.
> 
> We need to authenticate  devices which will come for authentication with
> their  certificate.
> As per keycloak-dev suggestion currently (Integrated with
> Keycloak_1.0.4_Final) we are following below procedure
> 	1. Create a new jaxrs class with two methods, one that returns the nounce
> 	and another that authenticates the client, look at TokenService as a
> 	reference for this, specifically at TokenService.grantAccessToken.
> 	2. Extend KeycloakApplication to add your new class
> 	3. Create your own auth-server war - see 'project-integrations/aerogear-ups'
> 	as a reference for this
> Also we were told that keycloak will come up with hooks whereby we can plug
> in our authentication mechanism. We want to know whether hooks(LogIn SPI)
> are provided with Latest Keycloak 1.1.0_Final Release.

No this is not available yet, and you will have to modify the above a fair bit to make it work.

> 
> For reference attaching previous discussion with Keycloak-dev.
> 
> Our Requirement:
> Instead of Existing one step authentication(user/pass), We  need custom
> certificate based authentication which is 2-step Authentication as below:
>     1. Bypass Login screen , instead generate nonce(UUID) and provide
>     intermediate Endpoint URL for Certificate based authentication.
>     2. Client will come to Certificate based authentication with its
>     certificate and encrypted UUID.  After Validating Encrypted UUID
>        and Client certificate server should generate ?Access code?.

Assuming this is to authenticate clients, not users, you should use direct grant, not regular login.

> 
> 
> Thanks,
> Lakshmi Narayana V
> 
> 
> -----Original Message-----
> From: Stian Thorgersen [mailto:stian at redhat.com]
> Sent: Tuesday, February 03, 2015 1:40 PM
> To: Lakshmi Narayana VADALI (lvadali)
> Cc: keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] Do we have Login SPI with Keycloak_1.1.0_Final?
> 
> 
> 
> ----- Original Message -----
> > From: "Lakshmi Narayana VADALI (lvadali)" <lvadali at cisco.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, 3 February, 2015 8:03:56 AM
> > Subject: [keycloak-dev] Do we have Login SPI with Keycloak_1.1.0_Final?
> > 
> > 
> > 
> > 
> > 
> > Congrats Team for Keycloak 1.1.0.Final Release loaded with features.
> > 
> > 
> > 
> > We are planning to integrate our code with Latest Keycloak. So Can you
> > please confirm do we have full support for Below features in
> > Keycloak_1.1.0_Final Release.
> > 
> > 
> > 
> > 1. Login SPI
> 
> Not sure what you're referring to
> 
> > 
> > 2. HA Support
> 
> Yes
> 
> > 
> > 3. Clustering Support
> 
> Yes, it's one of the top new features in 1.1, so yes of course
> 
> > 
> > 
> > 
> > Thanks,
> > 
> > Lakshmi Narayana V
> > 
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 


From mposolda at redhat.com  Tue Feb  3 17:00:07 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 03 Feb 2015 23:00:07 +0100
Subject: [keycloak-dev] Improve browser caching?
Message-ID: <54D144E7.1020108@redhat.com>

We seem to have many questions each release related to non-working 
things due to stale browser cache. Usually it's due to changes in admin 
console, but it may be even worse if we ever change something in CSS/JS 
of login or account mgmt, as those are available for end users.

I wonder if we can somehow improve this? One possible solution is to 
attach the redundant parameter with version to the cached resources. 
Something like: "/auth/theme/.../stylesheet.css?v=1.1.0.Final", so 
upgrade to next version will force browser to reload the resource.

The problem is longer (and not so nice) URLs and also some refactoring 
needed. For freemarker templates, we can add version parameter at 
runtime. However for admin console HTML pages, we would need to add 
version somehow at compile time though.

There is also possibility to attach hash instead of version (Juca 
mentioned this to me some time ago), but not sure if it's big difference.

Any better ideas? Or should we rather just keep it as it is?

Marek

From psilva at redhat.com  Tue Feb  3 17:07:11 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 3 Feb 2015 17:07:11 -0500 (EST)
Subject: [keycloak-dev] Improve browser caching?
In-Reply-To: <54D144E7.1020108@redhat.com>
References: <54D144E7.1020108@redhat.com>
Message-ID: <443814738.6134227.1423001231974.JavaMail.zimbra@redhat.com>

What about have something that intercept requests to disable browser caching ? A servlet filter or something ...

----- Original Message -----
From: "Marek Posolda" <mposolda at redhat.com>
To: keycloak-dev at lists.jboss.org
Sent: Tuesday, February 3, 2015 8:00:07 PM
Subject: [keycloak-dev] Improve browser caching?

We seem to have many questions each release related to non-working 
things due to stale browser cache. Usually it's due to changes in admin 
console, but it may be even worse if we ever change something in CSS/JS 
of login or account mgmt, as those are available for end users.

I wonder if we can somehow improve this? One possible solution is to 
attach the redundant parameter with version to the cached resources. 
Something like: "/auth/theme/.../stylesheet.css?v=1.1.0.Final", so 
upgrade to next version will force browser to reload the resource.

The problem is longer (and not so nice) URLs and also some refactoring 
needed. For freemarker templates, we can add version parameter at 
runtime. However for admin console HTML pages, we would need to add 
version somehow at compile time though.

There is also possibility to attach hash instead of version (Juca 
mentioned this to me some time ago), but not sure if it's big difference.

Any better ideas? Or should we rather just keep it as it is?

Marek
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev

From ssilvert at redhat.com  Tue Feb  3 18:11:44 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Tue, 03 Feb 2015 18:11:44 -0500
Subject: [keycloak-dev] Automatic logout from KC admin console for
 non-authorized users
In-Reply-To: <54D09561.4030306@redhat.com>
References: <54D08F4F.90109@redhat.com>
	<2101531218.6110818.1422954907605.JavaMail.zimbra@redhat.com>
	<54D09561.4030306@redhat.com>
Message-ID: <54D155B0.9010205@redhat.com>

On 2/3/2015 4:31 AM, Marek Posolda wrote:
> On 3.2.2015 10:15, Stian Thorgersen wrote:
>> ----- Original Message -----
>>> From: "Marek Posolda" <mposolda at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Tuesday, 3 February, 2015 10:05:19 AM
>>> Subject: [keycloak-dev] Automatic logout from KC admin console for	non-authorized users
>>>
>>> Right now, when user goes to keycloak admin console and he doesn't have
>>> access (any admin roles assigned), he is logged out automatically. It's
>>> done by "whoami" endpoint, which returns 401 in this case.
>> +1000 Logging-out the user is just plain stupid, cant' believe we do that
> I've created https://issues.jboss.org/browse/KEYCLOAK-1025
>>> Shouldn't we instead just display some notification like "Forbidden, you
>>> don't have access" instead of automatically logout user?
>>>
>>> My point is links between various admin consoles. For example when user
>>> is logged in hawtio admin console and he click on link to Keycloak admin
>>> console. But when he don't have access, he is logged out automatically,
>>> which does SSO logout and logout him also from hawtio. To me it looks
>>> like bit confusing behaviour tbh.
>>>
>>> Also do we have plan to add support for referrer in KC admin console
>>> similarly like account mgmt has?
>> I don't think referrer is the correct approach. What about if we add a feature to Keycloak that lets you retrieve all applications a user has access to (where a user has at least one role?) and that has a base url configured for it (maybe this should be changed to default page). Then we can use this information to add an application switcher to all consoles (like Google has, see attachment). This is probably something we should discuss with Management .Next guys though ;)
> Looks like great solution from long-term perspective. It's perhaps
> something to discuss with management .next to see if other "product
> consoles" are interested in this feature.
+1  There definitely is interest.
>
> Marek
>>> 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  Wed Feb  4 02:55:01 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 4 Feb 2015 02:55:01 -0500 (EST)
Subject: [keycloak-dev] Improve browser caching?
In-Reply-To: <54D144E7.1020108@redhat.com>
References: <54D144E7.1020108@redhat.com>
Message-ID: <1930900459.7040936.1423036501669.JavaMail.zimbra@redhat.com>

https://issues.jboss.org/browse/KEYCLOAK-1017 ;)

I was thinking it would be cleaner to add it to the URL of theme resources.

/auth/theme/.../<VERSION>/stylesheet.css

This works better for relative URLs.

Not sure I like using the release version, we could have a short hash or just an incrementing number.

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 3 February, 2015 11:00:07 PM
> Subject: [keycloak-dev] Improve browser caching?
> 
> We seem to have many questions each release related to non-working
> things due to stale browser cache. Usually it's due to changes in admin
> console, but it may be even worse if we ever change something in CSS/JS
> of login or account mgmt, as those are available for end users.
> 
> I wonder if we can somehow improve this? One possible solution is to
> attach the redundant parameter with version to the cached resources.
> Something like: "/auth/theme/.../stylesheet.css?v=1.1.0.Final", so
> upgrade to next version will force browser to reload the resource.
> 
> The problem is longer (and not so nice) URLs and also some refactoring
> needed. For freemarker templates, we can add version parameter at
> runtime. However for admin console HTML pages, we would need to add
> version somehow at compile time though.
> 
> There is also possibility to attach hash instead of version (Juca
> mentioned this to me some time ago), but not sure if it's big difference.
> 
> Any better ideas? Or should we rather just keep it as it is?
> 
> 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 Feb  4 02:55:40 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 4 Feb 2015 02:55:40 -0500 (EST)
Subject: [keycloak-dev] Improve browser caching?
In-Reply-To: <443814738.6134227.1423001231974.JavaMail.zimbra@redhat.com>
References: <54D144E7.1020108@redhat.com>
	<443814738.6134227.1423001231974.JavaMail.zimbra@redhat.com>
Message-ID: <38511940.7041030.1423036540030.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Marek Posolda" <mposolda at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 3 February, 2015 11:07:11 PM
> Subject: Re: [keycloak-dev] Improve browser caching?
> 
> What about have something that intercept requests to disable browser caching
> ? A servlet filter or something ...

We actively enable browsing caching to increase performance, so not sure why we would want a filter to disable it?

> 
> ----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, February 3, 2015 8:00:07 PM
> Subject: [keycloak-dev] Improve browser caching?
> 
> We seem to have many questions each release related to non-working
> things due to stale browser cache. Usually it's due to changes in admin
> console, but it may be even worse if we ever change something in CSS/JS
> of login or account mgmt, as those are available for end users.
> 
> I wonder if we can somehow improve this? One possible solution is to
> attach the redundant parameter with version to the cached resources.
> Something like: "/auth/theme/.../stylesheet.css?v=1.1.0.Final", so
> upgrade to next version will force browser to reload the resource.
> 
> The problem is longer (and not so nice) URLs and also some refactoring
> needed. For freemarker templates, we can add version parameter at
> runtime. However for admin console HTML pages, we would need to add
> version somehow at compile time though.
> 
> There is also possibility to attach hash instead of version (Juca
> mentioned this to me some time ago), but not sure if it's big difference.
> 
> Any better ideas? Or should we rather just keep it as it is?
> 
> 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 mposolda at redhat.com  Wed Feb  4 03:11:36 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 04 Feb 2015 09:11:36 +0100
Subject: [keycloak-dev] Improve browser caching?
In-Reply-To: <1930900459.7040936.1423036501669.JavaMail.zimbra@redhat.com>
References: <54D144E7.1020108@redhat.com>
	<1930900459.7040936.1423036501669.JavaMail.zimbra@redhat.com>
Message-ID: <54D1D438.3010400@redhat.com>

On 4.2.2015 08:55, Stian Thorgersen wrote:
> https://issues.jboss.org/browse/KEYCLOAK-1017 ;)
>
> I was thinking it would be cleaner to add it to the URL of theme resources.
>
> /auth/theme/.../<VERSION>/stylesheet.css
>
> This works better for relative URLs.
+1
>
> Not sure I like using the release version, we could have a short hash or just an incrementing number.
Sure, we can use whatever of this. Hash might have an advantage that can 
be generated at compile time though. So it's even better for us during 
development as version is still "1.2.0.Beta1-SNAPSHOT" but hash will 
always change (not sure about KeycloakServer, which is usually executed 
directly from IDE and bypasses maven, but maybe there is some solution 
for this too).

Marek
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 3 February, 2015 11:00:07 PM
>> Subject: [keycloak-dev] Improve browser caching?
>>
>> We seem to have many questions each release related to non-working
>> things due to stale browser cache. Usually it's due to changes in admin
>> console, but it may be even worse if we ever change something in CSS/JS
>> of login or account mgmt, as those are available for end users.
>>
>> I wonder if we can somehow improve this? One possible solution is to
>> attach the redundant parameter with version to the cached resources.
>> Something like: "/auth/theme/.../stylesheet.css?v=1.1.0.Final", so
>> upgrade to next version will force browser to reload the resource.
>>
>> The problem is longer (and not so nice) URLs and also some refactoring
>> needed. For freemarker templates, we can add version parameter at
>> runtime. However for admin console HTML pages, we would need to add
>> version somehow at compile time though.
>>
>> There is also possibility to attach hash instead of version (Juca
>> mentioned this to me some time ago), but not sure if it's big difference.
>>
>> Any better ideas? Or should we rather just keep it as it is?
>>
>> Marek
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From psilva at redhat.com  Wed Feb  4 07:18:17 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 4 Feb 2015 07:18:17 -0500 (EST)
Subject: [keycloak-dev] Improve browser caching?
In-Reply-To: <38511940.7041030.1423036540030.JavaMail.zimbra@redhat.com>
References: <54D144E7.1020108@redhat.com>
	<443814738.6134227.1423001231974.JavaMail.zimbra@redhat.com>
	<38511940.7041030.1423036540030.JavaMail.zimbra@redhat.com>
Message-ID: <1906399019.6317606.1423052297429.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "Marek Posolda" <mposolda at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Wednesday, February 4, 2015 5:55:40 AM
> Subject: Re: [keycloak-dev] Improve browser caching?
> 
> 
> 
> ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "Marek Posolda" <mposolda at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, 3 February, 2015 11:07:11 PM
> > Subject: Re: [keycloak-dev] Improve browser caching?
> > 
> > What about have something that intercept requests to disable browser
> > caching
> > ? A servlet filter or something ...
> 
> We actively enable browsing caching to increase performance, so not sure why
> we would want a filter to disable it?

Actually, manage caching. So you can control how http caching is set in responses. If you want to disable, you just change a config. Or if you want to set a default expiration time for pages or specific resources.

> 
> > 
> > ----- Original Message -----
> > From: "Marek Posolda" <mposolda at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, February 3, 2015 8:00:07 PM
> > Subject: [keycloak-dev] Improve browser caching?
> > 
> > We seem to have many questions each release related to non-working
> > things due to stale browser cache. Usually it's due to changes in admin
> > console, but it may be even worse if we ever change something in CSS/JS
> > of login or account mgmt, as those are available for end users.
> > 
> > I wonder if we can somehow improve this? One possible solution is to
> > attach the redundant parameter with version to the cached resources.
> > Something like: "/auth/theme/.../stylesheet.css?v=1.1.0.Final", so
> > upgrade to next version will force browser to reload the resource.
> > 
> > The problem is longer (and not so nice) URLs and also some refactoring
> > needed. For freemarker templates, we can add version parameter at
> > runtime. However for admin console HTML pages, we would need to add
> > version somehow at compile time though.
> > 
> > There is also possibility to attach hash instead of version (Juca
> > mentioned this to me some time ago), but not sure if it's big difference.
> > 
> > Any better ideas? Or should we rather just keep it as it is?
> > 
> > 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  Wed Feb  4 07:22:29 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 4 Feb 2015 07:22:29 -0500 (EST)
Subject: [keycloak-dev] Improve browser caching?
In-Reply-To: <1906399019.6317606.1423052297429.JavaMail.zimbra@redhat.com>
References: <54D144E7.1020108@redhat.com>
	<443814738.6134227.1423001231974.JavaMail.zimbra@redhat.com>
	<38511940.7041030.1423036540030.JavaMail.zimbra@redhat.com>
	<1906399019.6317606.1423052297429.JavaMail.zimbra@redhat.com>
Message-ID: <245042899.7334709.1423052549765.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Marek Posolda" <mposolda at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Wednesday, 4 February, 2015 1:18:17 PM
> Subject: Re: [keycloak-dev] Improve browser caching?
> 
> ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: "Marek Posolda" <mposolda at redhat.com>, keycloak-dev at lists.jboss.org
> > Sent: Wednesday, February 4, 2015 5:55:40 AM
> > Subject: Re: [keycloak-dev] Improve browser caching?
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Pedro Igor Silva" <psilva at redhat.com>
> > > To: "Marek Posolda" <mposolda at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Tuesday, 3 February, 2015 11:07:11 PM
> > > Subject: Re: [keycloak-dev] Improve browser caching?
> > > 
> > > What about have something that intercept requests to disable browser
> > > caching
> > > ? A servlet filter or something ...
> > 
> > We actively enable browsing caching to increase performance, so not sure
> > why
> > we would want a filter to disable it?
> 
> Actually, manage caching. So you can control how http caching is set in
> responses. If you want to disable, you just change a config. Or if you want
> to set a default expiration time for pages or specific resources.

We already manage caching though. We set max-age to allow browsers to cache resources that are not dynamic. We could use etags, but that still requires a request to the server. So the only decent solution I can think of is making sure we have a unique url, which we can do by adding a version/hash or something.

> 
> > 
> > > 
> > > ----- Original Message -----
> > > From: "Marek Posolda" <mposolda at redhat.com>
> > > To: keycloak-dev at lists.jboss.org
> > > Sent: Tuesday, February 3, 2015 8:00:07 PM
> > > Subject: [keycloak-dev] Improve browser caching?
> > > 
> > > We seem to have many questions each release related to non-working
> > > things due to stale browser cache. Usually it's due to changes in admin
> > > console, but it may be even worse if we ever change something in CSS/JS
> > > of login or account mgmt, as those are available for end users.
> > > 
> > > I wonder if we can somehow improve this? One possible solution is to
> > > attach the redundant parameter with version to the cached resources.
> > > Something like: "/auth/theme/.../stylesheet.css?v=1.1.0.Final", so
> > > upgrade to next version will force browser to reload the resource.
> > > 
> > > The problem is longer (and not so nice) URLs and also some refactoring
> > > needed. For freemarker templates, we can add version parameter at
> > > runtime. However for admin console HTML pages, we would need to add
> > > version somehow at compile time though.
> > > 
> > > There is also possibility to attach hash instead of version (Juca
> > > mentioned this to me some time ago), but not sure if it's big difference.
> > > 
> > > Any better ideas? Or should we rather just keep it as it is?
> > > 
> > > 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 psilva at redhat.com  Wed Feb  4 07:23:03 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 4 Feb 2015 07:23:03 -0500 (EST)
Subject: [keycloak-dev] Improve browser caching?
In-Reply-To: <38511940.7041030.1423036540030.JavaMail.zimbra@redhat.com>
References: <54D144E7.1020108@redhat.com>
	<443814738.6134227.1423001231974.JavaMail.zimbra@redhat.com>
	<38511940.7041030.1423036540030.JavaMail.zimbra@redhat.com>
Message-ID: <2035717319.6319207.1423052583031.JavaMail.zimbra@redhat.com>

Or just use KC behind an Apache server and forget about managing that in KC :)

----- Original Message -----
From: "Stian Thorgersen" <stian at redhat.com>
To: "Pedro Igor Silva" <psilva at redhat.com>
Cc: "Marek Posolda" <mposolda at redhat.com>, keycloak-dev at lists.jboss.org
Sent: Wednesday, February 4, 2015 5:55:40 AM
Subject: Re: [keycloak-dev] Improve browser caching?



----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Marek Posolda" <mposolda at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 3 February, 2015 11:07:11 PM
> Subject: Re: [keycloak-dev] Improve browser caching?
> 
> What about have something that intercept requests to disable browser caching
> ? A servlet filter or something ...

We actively enable browsing caching to increase performance, so not sure why we would want a filter to disable it?

> 
> ----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, February 3, 2015 8:00:07 PM
> Subject: [keycloak-dev] Improve browser caching?
> 
> We seem to have many questions each release related to non-working
> things due to stale browser cache. Usually it's due to changes in admin
> console, but it may be even worse if we ever change something in CSS/JS
> of login or account mgmt, as those are available for end users.
> 
> I wonder if we can somehow improve this? One possible solution is to
> attach the redundant parameter with version to the cached resources.
> Something like: "/auth/theme/.../stylesheet.css?v=1.1.0.Final", so
> upgrade to next version will force browser to reload the resource.
> 
> The problem is longer (and not so nice) URLs and also some refactoring
> needed. For freemarker templates, we can add version parameter at
> runtime. However for admin console HTML pages, we would need to add
> version somehow at compile time though.
> 
> There is also possibility to attach hash instead of version (Juca
> mentioned this to me some time ago), but not sure if it's big difference.
> 
> Any better ideas? Or should we rather just keep it as it is?
> 
> 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 bgorai at cisco.com  Wed Feb  4 07:37:12 2015
From: bgorai at cisco.com (Bappaditya Gorai (bgorai))
Date: Wed, 4 Feb 2015 12:37:12 +0000
Subject: [keycloak-dev] Facing Issue with Resource Server in Clustered
 Environment
In-Reply-To: <54CF358B.2030308@redhat.com>
References: <C5AF53298BAB5F4A88B28966E43B40AD0565BB00@xmb-aln-x12.cisco.com>
	<1743939526.3724664.1422602848465.JavaMail.zimbra@redhat.com>
	<C5AF53298BAB5F4A88B28966E43B40AD0565BB18@xmb-aln-x12.cisco.com>
	<1683679347.3736800.1422604072720.JavaMail.zimbra@redhat.com>
	<C5AF53298BAB5F4A88B28966E43B40AD0565BB76@xmb-aln-x12.cisco.com>
	<54CF358B.2030308@redhat.com>
Message-ID: <C5AF53298BAB5F4A88B28966E43B40AD0565C3E0@xmb-aln-x12.cisco.com>

Thanks for the detailed description. Still, It seems in case of Clustered Resource environment (distributable without Sticky sessions) we are relying on session replication to happen immediately between CODE_TO_TOKEN and Resource Hit(302), which may or may not happen. We are now facing the same issue where After CODE_TO_TOKEN client is redirected to Login URL again.

Are we addressing this scenario with 1.1.0 Final ?


Thanks
Bappaditya Gorai

-----Original Message-----
From: Marek Posolda [mailto:mposolda at redhat.com]
Sent: Monday, February 02, 2015 2:00 PM
To: Bappaditya Gorai (bgorai); Stian Thorgersen
Cc: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] Facing Issue with Resource Server in Clustered Environment

Hi,

it's not stateless by default. Data about keycloak authenticated principal are saved in HTTP session by default and can be replicated across cluster nodes (replication works as long as your application is marked as "distributable" in web.xml).

However we support stateless adapter, which won't save anything in HTTP Session and won't create HTTP session and JSESSIONID cookie at all (unless you're calling httpRequest.getSession() in your own application). Instead all the data are saved in cookie.

Some more info in docs:
http://docs.jboss.org/keycloak/docs/1.1.0.Final/userguide/html/applicationClustering.html#stateless-token-store

Marek

On 30.1.2015 11:26, Bappaditya Gorai (bgorai) wrote:
> Thanks for clarifying.  So, I think adapter has become stateless in 1.1.0.Final. Is my understanding correct?
>
>
> -----Original Message-----
> From: Stian Thorgersen [mailto:stian at redhat.com]
> Sent: Friday, January 30, 2015 1:18 PM
> To: Bappaditya Gorai (bgorai)
> Cc: keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
> Subject: Re: [keycloak-dev] Facing Issue with Resource Server in
> Clustered Environment
>
>
>
> ----- Original Message -----
>> From: "Bappaditya Gorai (bgorai)" <bgorai at cisco.com<mailto:bgorai at cisco.com>>
>> To: "Stian Thorgersen" <stian at redhat.com<mailto:stian at redhat.com>>
>> Cc: keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
>> Sent: Friday, 30 January, 2015 8:38:49 AM
>> Subject: RE: [keycloak-dev] Facing Issue with Resource Server in Clustered   Environment
>>
>> We are not talking about clustering for Keycloak server. The setup is
>> for Resource Server (Keycloak Adapter)  in clustered environment.
> Same answer
>
>> Thanks
>> Bappaditya Gorai
>>
>> -----Original Message-----
>> From: Stian Thorgersen [mailto:stian at redhat.com]
>> Sent: Friday, January 30, 2015 12:57 PM
>> To: Bappaditya Gorai (bgorai)
>> Cc: keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
>> Subject: Re: [keycloak-dev] Facing Issue with Resource Server in
>> Clustered Environment
>>
>> 1.0.4.Final had very limited support for clustering, please upgrade
>> to 1.1.0.Final and refer to chapter 24 and 25 in the documentation
>> (http://docs.jboss.org/keycloak/docs/1.1.0.Final/userguide/html/clustering.html).
>>
>> ----- Original Message -----
>>> From: "Bappaditya Gorai (bgorai)" <bgorai at cisco.com<mailto:bgorai at cisco.com>>
>>> To: keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
>>> Sent: Friday, 30 January, 2015 8:22:26 AM
>>> Subject: [keycloak-dev] Facing Issue with Resource Server in Clustered
>>>     Environment
>>>
>>>
>>>
>>> Hi Team,
>>>
>>> Please find the details on setup and observation below. Please
>>> provide your suggestion on how to overcome this issue. We are using
>>> Keycloak 1.0.4.Final (Adapter & Server).
>>>
>>>
>>>
>>>
>>>
>>> Setup:
>>>
>>> 1. We have brought up Jboss cluster ( Using mod_cluster, httpd )
>>> with
>>> 2 nodes in domain mode and enabled session replication between these nodes.
>>>
>>> 2. Our Recourse server is deployed in this clustered environment
>>> with distributable and Sticky session Off.
>>>
>>>
>>>
>>> Behavior observed :
>>>
>>> During the Authorization/Authentication process ,when Initial
>>> call(Resource
>>> Access) lands on master and next redirection (post Code To token)
>>> falls on slave Adapter is treating it as a new session and
>>> redirecting to login URL again. So we ended up with circular redirection error.
>>> After further investigation seems like session replication delay is
>>> causing adapter to behave this way. As the redirection call happens
>>> very quickly and this results in circular redirection error.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> NOTE: Sticky Session in mod_cluster environment solves the issue but
>>> it does not provide true load balancing. Therefore we are not
>>> considering Stick session option.
>>>
>>>
>>>
>>>
>>>
>>> Thanks
>>>
>>> Bappaditya Gorai
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150204/60e2b452/attachment.html 

From mposolda at redhat.com  Wed Feb  4 09:35:57 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 04 Feb 2015 15:35:57 +0100
Subject: [keycloak-dev] Facing Issue with Resource Server in Clustered
 Environment
In-Reply-To: <C5AF53298BAB5F4A88B28966E43B40AD0565C3E0@xmb-aln-x12.cisco.com>
References: <C5AF53298BAB5F4A88B28966E43B40AD0565BB00@xmb-aln-x12.cisco.com>	<1743939526.3724664.1422602848465.JavaMail.zimbra@redhat.com>	<C5AF53298BAB5F4A88B28966E43B40AD0565BB18@xmb-aln-x12.cisco.com>	<1683679347.3736800.1422604072720.JavaMail.zimbra@redhat.com>
	<C5AF53298BAB5F4A88B28966E43B40AD0565BB76@xmb-aln-x12.cisco.com>
	<54CF358B.2030308@redhat.com>
	<C5AF53298BAB5F4A88B28966E43B40AD0565C3E0@xmb-aln-x12.cisco.com>
Message-ID: <54D22E4D.1040800@redhat.com>

Hi,

I am not sure about the details of your environment. You mentioned that 
you're not interested in clustering of keycloak server. So am I 
understand correctly that you have just 1 node as keycloak server and 2 
nodes with your application deployed? Are you using "distributable" tag 
in web.xml of your app on both nodes to ensure session replication? Are 
you using loadbalancer?

Marek

On 4.2.2015 13:37, Bappaditya Gorai (bgorai) wrote:
> Thanks for the detailed description. Still, It seems in case of 
> Clustered Resource environment (distributable without Sticky sessions) 
> we are relying on session replication to happen immediately between 
> CODE_TO_TOKEN and Resource Hit(302), which may or may not happen. We 
> are now facing the same issue where After CODE_TO_TOKEN client is 
> redirected to Login URL again.
> Are we addressing this scenario with 1.1.0 Final ?
> Thanks
> Bappaditya Gorai
> -----Original Message-----
> From: Marek Posolda [mailto:mposolda at redhat.com]
> Sent: Monday, February 02, 2015 2:00 PM
> To: Bappaditya Gorai (bgorai); Stian Thorgersen
> Cc: keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] Facing Issue with Resource Server in 
> Clustered Environment
> Hi,
> it's not stateless by default. Data about keycloak authenticated 
> principal are saved in HTTP session by default and can be replicated 
> across cluster nodes (replication works as long as your application is 
> marked as "distributable" in web.xml).
> However we support stateless adapter, which won't save anything in 
> HTTP Session and won't create HTTP session and JSESSIONID cookie at 
> all (unless you're calling httpRequest.getSession() in your own 
> application). Instead all the data are saved in cookie.
> Some more info in docs:
> http://docs.jboss.org/keycloak/docs/1.1.0.Final/userguide/html/applicationClustering.html#stateless-token-store
> Marek
> On 30.1.2015 11:26, Bappaditya Gorai (bgorai) wrote:
> > Thanks for clarifying.  So, I think adapter has become stateless in 1.1.0.Final. Is my understanding correct?
> >
> >
> > -----Original Message-----
> > From: Stian Thorgersen [mailto:stian at redhat.com]
> > Sent: Friday, January 30, 2015 1:18 PM
> > To: Bappaditya Gorai (bgorai)
> > Cc:keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> > Subject: Re: [keycloak-dev] Facing Issue with Resource Server in
> > Clustered Environment
> >
> >
> >
> > ----- Original Message -----
> >> From: "Bappaditya Gorai (bgorai)" <bgorai at cisco.com <mailto:bgorai at cisco.com>>
> >> To: "Stian Thorgersen" <stian at redhat.com <mailto:stian at redhat.com>>
> >> Cc:keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> >> Sent: Friday, 30 January, 2015 8:38:49 AM
> >> Subject: RE: [keycloak-dev] Facing Issue with Resource Server in Clustered   Environment
> >>
> >> We are not talking about clustering for Keycloak server. The setup is
> >> for Resource Server (Keycloak Adapter)  in clustered environment.
> > Same answer
> >
> >> Thanks
> >> Bappaditya Gorai
> >>
> >> -----Original Message-----
> >> From: Stian Thorgersen [mailto:stian at redhat.com]
> >> Sent: Friday, January 30, 2015 12:57 PM
> >> To: Bappaditya Gorai (bgorai)
> >> Cc:keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> >> Subject: Re: [keycloak-dev] Facing Issue with Resource Server in
> >> Clustered Environment
> >>
> >> 1.0.4.Final had very limited support for clustering, please upgrade
> >> to 1.1.0.Final and refer to chapter 24 and 25 in the documentation
> >> (http://docs.jboss.org/keycloak/docs/1.1.0.Final/userguide/html/clustering.html).
> >>
> >> ----- Original Message -----
> >>> From: "Bappaditya Gorai (bgorai)" <bgorai at cisco.com <mailto:bgorai at cisco.com>>
> >>> To:keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> >>> Sent: Friday, 30 January, 2015 8:22:26 AM
> >>> Subject: [keycloak-dev] Facing Issue with Resource Server in Clustered
> >>>      Environment
> >>>
> >>>
> >>>
> >>> Hi Team,
> >>>
> >>> Please find the details on setup and observation below. Please
> >>> provide your suggestion on how to overcome this issue. We are using
> >>> Keycloak 1.0.4.Final (Adapter & Server).
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Setup:
> >>>
> >>> 1. We have brought up Jboss cluster ( Using mod_cluster, httpd )
> >>> with
> >>> 2 nodes in domain mode and enabled session replication between these nodes.
> >>>
> >>> 2. Our Recourse server is deployed in this clustered environment
> >>> with distributable and Sticky session Off.
> >>>
> >>>
> >>>
> >>> Behavior observed :
> >>>
> >>> During the Authorization/Authentication process ,when Initial
> >>> call(Resource
> >>> Access) lands on master and next redirection (post Code To token)
> >>> falls on slave Adapter is treating it as a new session and
> >>> redirecting to login URL again. So we ended up with circular redirection error.
> >>> After further investigation seems like session replication delay is
> >>> causing adapter to behave this way. As the redirection call happens
> >>> very quickly and this results in circular redirection error.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> NOTE: Sticky Session in mod_cluster environment solves the issue but
> >>> it does not provide true load balancing. Therefore we are not
> >>> considering Stick session option.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Thanks
> >>>
> >>> Bappaditya Gorai
> >>>
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>>keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> >>>https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > _______________________________________________
> > keycloak-dev mailing list
> >keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> >https://lists.jboss.org/mailman/listinfo/keycloak-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150204/f58b0fdd/attachment-0001.html 

From bgorai at cisco.com  Thu Feb  5 00:45:44 2015
From: bgorai at cisco.com (Bappaditya Gorai (bgorai))
Date: Thu, 5 Feb 2015 05:45:44 +0000
Subject: [keycloak-dev] Facing Issue with Resource Server in Clustered
 Environment
In-Reply-To: <54D22E4D.1040800@redhat.com>
References: <C5AF53298BAB5F4A88B28966E43B40AD0565BB00@xmb-aln-x12.cisco.com>
	<1743939526.3724664.1422602848465.JavaMail.zimbra@redhat.com>
	<C5AF53298BAB5F4A88B28966E43B40AD0565BB18@xmb-aln-x12.cisco.com>
	<1683679347.3736800.1422604072720.JavaMail.zimbra@redhat.com>
	<C5AF53298BAB5F4A88B28966E43B40AD0565BB76@xmb-aln-x12.cisco.com>
	<54CF358B.2030308@redhat.com>
	<C5AF53298BAB5F4A88B28966E43B40AD0565C3E0@xmb-aln-x12.cisco.com>
	<54D22E4D.1040800@redhat.com>
Message-ID: <C5AF53298BAB5F4A88B28966E43B40AD0565C4BB@xmb-aln-x12.cisco.com>

Please find my response inline for your queries.

Thanks
Bappaditya Gorai

From: Marek Posolda [mailto:mposolda at redhat.com]
Sent: Wednesday, February 04, 2015 8:06 PM
To: Bappaditya Gorai (bgorai); Stian Thorgersen
Cc: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] Facing Issue with Resource Server in Clustered Environment

Hi,

I am not sure about the details of your environment. You mentioned that you're not interested in clustering of keycloak server.

So am I understand correctly that you have just 1 node as keycloak server and 2 nodes with your application deployed?
[[Bappaditya]]  Yes, only one instance of keycloak Server (Running in standalone mode).  My Application is deployed in 2 nodes (cluster) and running in domain mode.

Are you using "distributable" tag in web.xml of your app on both nodes to ensure session replication?
[[Bappaditya]] Yes, Application is using  "distributable" tag in web.xml.

Are you using loadbalancer?
[[Bappaditya]]  We are using mod_cluster & httpd. Sticky sessions disabled.


Marek

On 4.2.2015 13:37, Bappaditya Gorai (bgorai) wrote:
Thanks for the detailed description. Still, It seems in case of Clustered Resource environment (distributable without Sticky sessions) we are relying on session replication to happen immediately between CODE_TO_TOKEN and Resource Hit(302), which may or may not happen. We are now facing the same issue where After CODE_TO_TOKEN client is redirected to Login URL again.

Are we addressing this scenario with 1.1.0 Final ?


Thanks
Bappaditya Gorai

-----Original Message-----
From: Marek Posolda [mailto:mposolda at redhat.com]
Sent: Monday, February 02, 2015 2:00 PM
To: Bappaditya Gorai (bgorai); Stian Thorgersen
Cc: keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
Subject: Re: [keycloak-dev] Facing Issue with Resource Server in Clustered Environment

Hi,

it's not stateless by default. Data about keycloak authenticated principal are saved in HTTP session by default and can be replicated across cluster nodes (replication works as long as your application is marked as "distributable" in web.xml).

However we support stateless adapter, which won't save anything in HTTP Session and won't create HTTP session and JSESSIONID cookie at all (unless you're calling httpRequest.getSession() in your own application). Instead all the data are saved in cookie.

Some more info in docs:
http://docs.jboss.org/keycloak/docs/1.1.0.Final/userguide/html/applicationClustering.html#stateless-token-store<http://docs.jboss.org/keycloak/docs/1.1.0.Final/userguide/html/applicationClustering.html>

Marek

On 30.1.2015 11:26, Bappaditya Gorai (bgorai) wrote:
> Thanks for clarifying.  So, I think adapter has become stateless in 1.1.0.Final. Is my understanding correct?
>
>
> -----Original Message-----
> From: Stian Thorgersen [mailto:stian at redhat.com]
> Sent: Friday, January 30, 2015 1:18 PM
> To: Bappaditya Gorai (bgorai)
> Cc: keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
> Subject: Re: [keycloak-dev] Facing Issue with Resource Server in
> Clustered Environment
>
>
>
> ----- Original Message -----
>> From: "Bappaditya Gorai (bgorai)" <bgorai at cisco.com<mailto:bgorai at cisco.com>>
>> To: "Stian Thorgersen" <stian at redhat.com<mailto:stian at redhat.com>>
>> Cc: keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
>> Sent: Friday, 30 January, 2015 8:38:49 AM
>> Subject: RE: [keycloak-dev] Facing Issue with Resource Server in Clustered   Environment
>>
>> We are not talking about clustering for Keycloak server. The setup is
>> for Resource Server (Keycloak Adapter)  in clustered environment.
> Same answer
>
>> Thanks
>> Bappaditya Gorai
>>
>> -----Original Message-----
>> From: Stian Thorgersen [mailto:stian at redhat.com]
>> Sent: Friday, January 30, 2015 12:57 PM
>> To: Bappaditya Gorai (bgorai)
>> Cc: keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
>> Subject: Re: [keycloak-dev] Facing Issue with Resource Server in
>> Clustered Environment
>>
>> 1.0.4.Final had very limited support for clustering, please upgrade
>> to 1.1.0.Final and refer to chapter 24 and 25 in the documentation
>> (http://docs.jboss.org/keycloak/docs/1.1.0.Final/userguide/html/clustering.html).
>>
>> ----- Original Message -----
>>> From: "Bappaditya Gorai (bgorai)" <bgorai at cisco.com<mailto:bgorai at cisco.com>>
>>> To: keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
>>> Sent: Friday, 30 January, 2015 8:22:26 AM
>>> Subject: [keycloak-dev] Facing Issue with Resource Server in Clustered
>>>      Environment
>>>
>>>
>>>
>>> Hi Team,
>>>
>>> Please find the details on setup and observation below. Please
>>> provide your suggestion on how to overcome this issue. We are using
>>> Keycloak 1.0.4.Final (Adapter & Server).
>>>
>>>
>>>
>>>
>>>
>>> Setup:
>>>
>>> 1. We have brought up Jboss cluster ( Using mod_cluster, httpd )
>>> with
>>> 2 nodes in domain mode and enabled session replication between these nodes.
>>>
>>> 2. Our Recourse server is deployed in this clustered environment
>>> with distributable and Sticky session Off.
>>>
>>>
>>>
>>> Behavior observed :
>>>
>>> During the Authorization/Authentication process ,when Initial
>>> call(Resource
>>> Access) lands on master and next redirection (post Code To token)
>>> falls on slave Adapter is treating it as a new session and
>>> redirecting to login URL again. So we ended up with circular redirection error.
>>> After further investigation seems like session replication delay is
>>> causing adapter to behave this way. As the redirection call happens
>>> very quickly and this results in circular redirection error.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> NOTE: Sticky Session in mod_cluster environment solves the issue but
>>> it does not provide true load balancing. Therefore we are not
>>> considering Stick session option.
>>>
>>>
>>>
>>>
>>>
>>> Thanks
>>>
>>> Bappaditya Gorai
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150205/0a20ad65/attachment.html 

From daniel.baxter at cira.ca  Thu Feb  5 08:56:01 2015
From: daniel.baxter at cira.ca (Daniel Baxter)
Date: Thu, 5 Feb 2015 13:56:01 +0000
Subject: [keycloak-dev] Slow Direct Grants API endpoint
In-Reply-To: <1548314231.6086338.1422950340992.JavaMail.zimbra@redhat.com>
References: <152ADF7679FD37488EE24A3FB5CA9AE1D4DA05CA@EXCH-01.CORP.CIRA.CA>
	<853465969.10046513.1421243158655.JavaMail.zimbra@redhat.com>
	<152ADF7679FD37488EE24A3FB5CA9AE1D4DA11BF@EXCH-01.CORP.CIRA.CA>
	<86460392.10074076.1421245169796.JavaMail.zimbra@redhat.com>
	<152ADF7679FD37488EE24A3FB5CA9AE1D4DA11F7@EXCH-01.CORP.CIRA.CA>
	<1931160200.10779706.1421325416961.JavaMail.zimbra@redhat.com>
	<152ADF7679FD37488EE24A3FB5CA9AE1D4DC840E@EXCH-02.CORP.CIRA.CA>
	<1548314231.6086338.1422950340992.JavaMail.zimbra@redhat.com>
Message-ID: <152ADF7679FD37488EE24A3FB5CA9AE1D4DE4A1C@EXCH-01.CORP.CIRA.CA>

Hi,

We finally got some load testing done with our system and with the hash adjustments it was pretty close to the same performance we were seeing before porting over. One thing I noticed is that every Direct Grants Access creates a session in Keycloak. Is it possible to perform a sessionless grant or at least get back the same session?

A note about our architecture. We have 2 interfaces to our app; 1 web which runs in container with the EJB services and uses the web authentication perfectly. The second interface is a netty app that runs outside of the JBoss container to handle network api requests into our system with a specific protocol that is then handed over to the EJB services running in JBoss using a Remoting endpoint. In Weblogic we got a WorkContext when we did this which allowed us to authenticate against the EJB services once per session. However, JBoss seems to be missing the concept of a WorkContext and we are required to pass over java.naming.security.principal and java.naming.security.credentials with the jndi properties every time we do a Remote EJB call. This is where we are using Direct Grants Authentication because the jndi props are passing over only a username and password to the services and we have been required to authenticate each time to access the services.

Now I want to avoid having to ping back with a Logout message on each call termination because it will add the travel time as lag to each API call and would prefer a sessionless authentication. Or is there a known tool or API for maintaining the Remoting session on JBoss similar to how the WorkContext works on Weblogic so we don't have to authenticate every hop over the Remoting endpoint.

If there is sample code for Keycloak authenticated Remoting app to look at that might also be helpful.

Thanks,

Daniel

-----Original Message-----
From: Stian Thorgersen [mailto:stian at redhat.com] 
Sent: Tuesday, February 03, 2015 2:59 AM
To: Daniel Baxter
Cc: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] Slow Direct Grants API endpoint

Yep, that would do it ;)

The hashing algorithm used by Keycloak is PBKDF2 and we only use 1 iteration by default, but we highly recommend increasing that though. We should probably also considering increasing the default.

It's hard to give a definitive answer to this question as it is all relative, but for increased safety I'd say you should be looking at 5-10K iterations. Obviously the higher the better and you can and should cluster Keycloak for increased scalability and availability.

----- Original Message -----
> From: "Daniel Baxter" <daniel.baxter at cira.ca>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 2 February, 2015 5:03:44 PM
> Subject: RE: [keycloak-dev] Slow Direct Grants API endpoint
> 
> Hi,
> 
> I have just finished some testing on 1.1.0 Final and found that the 
> core problem was that through an abundance of caution we have 
> configured hash iterations to 100,000 (which I of course typoed to 1M 
> on Beta 2 when I configured it). The performance delta between 1.0 and 
> 1.1 is explained by the typo there. However, even with the change to 
> 100K in place I found the end point was still too slow (600~800ms) and 
> discovered that it scaled linearly down as I reduced the iterations.
> 
> So I guess the question now is how many iterations is the default and 
> how many would be a recommended "overly cautious" amount of 
> iterations. I understand that keycloak defaults to Bcrypt hashing 
> which is designed explicitly to be computationally expensive so I 
> imagine iterations in the scope of 10-50 is probably sufficient to keep the passwords safe.
> 
> - Daniel
> 
> -----Original Message-----
> From: Stian Thorgersen [mailto:stian at redhat.com]
> Sent: Thursday, January 15, 2015 7:37 AM
> To: Daniel Baxter
> Cc: keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] Slow Direct Grants API endpoint
> 
> Just ran some perf tests with default settings, 10 users and 10000 requests:
> 
>   Version                Average (ms)    Throughput
>   -------------------------------------------------
>   1.0.4.Final            18              468
>   1.1.0.Beta2            19              470
>   1.1.0.Final-SNAPSHOT   20              426
> 
> 
> ----- Original Message -----
> > From: "Daniel Baxter" <daniel.baxter at cira.ca>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Wednesday, 14 January, 2015 3:56:03 PM
> > Subject: RE: [keycloak-dev] Slow Direct Grants API endpoint
> > 
> > Honestly I don't know how to check what is being used. I assume it 
> > would be whatever Keycloak Appliance defaults to. I checked with the 
> > guy who configured 1.0.4 for the other application and he doesn't 
> > know what we are using or how to configure it either. Sorry.
> > 
> > - Daniel
> > 
> > -----Original Message-----
> > From: Stian Thorgersen [mailto:stian at redhat.com]
> > Sent: Wednesday, January 14, 2015 9:19 AM
> > To: Daniel Baxter
> > Cc: keycloak-dev at lists.jboss.org
> > Subject: Re: [keycloak-dev] Slow Direct Grants API endpoint
> > 
> > What user session provider are you using?
> > 
> > ----- Original Message -----
> > > From: "Daniel Baxter" <daniel.baxter at cira.ca>
> > > To: "Stian Thorgersen" <stian at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Wednesday, 14 January, 2015 3:01:17 PM
> > > Subject: RE: [keycloak-dev] Slow Direct Grants API endpoint
> > > 
> > > I am working with our ops team to configure 1.1.x with the same 
> > > level of hardware as our development 1.0.4 system (right now it is 
> > > running locally on a XEON workstation with piles of RAM).
> > > 
> > > Both are connected to postgres databases and I am the only person 
> > > working on this portion of the project so it is just 1 user at a 
> > > time right now for 1.1.x. I have tested the database connection 
> > > and there is no real discernable performance irregularities for 
> > > anything that runs against that database.
> > > 
> > > For Keycloak itself, it is mostly straight out of the box 
> > > appliance install for both 1.0.4 and 1.1.x and it runs on a single 
> > > machine for development use (I believe our prod deployment is/will be clustered).
> > > The performance I am seeing is timeable on a stop watch for 1.1 
> > > and near enough to instant for
> > > 1.0.4 (under 500 ms). Easily an order of magnitude. Given the 
> > > response I got (regarding the unexpectedness of the slow 
> > > behaviour) I want to make sure I have a completely fair comparison 
> > > and am working to set up
> > > 1.1 on a dedicated development server to make the comparison 
> > > completely fair.
> > > 
> > > - Daniel
> > > 
> > > -----Original Message-----
> > > From: Stian Thorgersen [mailto:stian at redhat.com]
> > > Sent: Wednesday, January 14, 2015 8:46 AM
> > > To: Daniel Baxter
> > > Cc: keycloak-dev at lists.jboss.org
> > > Subject: Re: [keycloak-dev] Slow Direct Grants API endpoint
> > > 
> > > Direct grants are expected to be a little bit slower in 1.1.x due 
> > > to the requirement to persist more, but should certainly not be seconds.
> > > 
> > > Can you give some more details please? Including
> > > 
> > > * What DB are you using?
> > > * Are you using mem, infinispan or jpa user session provider?
> > > * Clustered?
> > > * How many concurrent requests/users are you testing with?
> > > 
> > > Any more accurate performance stats would also be helpful
> > > 
> > > ----- Original Message -----
> > > > From: "Daniel Baxter" <daniel.baxter at cira.ca>
> > > > To: keycloak-dev at lists.jboss.org
> > > > Sent: Monday, 12 January, 2015 9:23:42 PM
> > > > Subject: [keycloak-dev] Slow Direct Grants API endpoint
> > > > 
> > > > 
> > > > 
> > > > Hi,
> > > > 
> > > > 
> > > > 
> > > > I am attempting to integrate Keycloak into an existing 
> > > > application to replace the homegrown user management system in 
> > > > place. We have a new project built from the ground up on 
> > > > Keycloak 1.0.4.Final which is exhibiting good performance. 
> > > > However this app that I am porting has a remoting component that 
> > > > connects to the server with bare username/password credentials 
> > > > over the EJB Remoting framework. I was hoping to use 1.1.0 
> > > > (currently Beta2) which provides a DirectAccessGrantsLoginModule 
> > > > which does exactly what I want (turns username and password into a KeycloakPrincipal).
> > > > However, the turn around time from Keycloak is on the order of 
> > > > several seconds.
> > > > 
> > > > 
> > > > 
> > > > I have used a bare REST client to execute the POSTs to both our
> > > > 1.0.4 Keycloak and 1.1.0 Keycloak instances and have noted an 
> > > > order of magnitude difference in getting a response. Is this a 
> > > > known issue (I cannot find anything in the public bugs/tasks 
> > > > list)? Or is this due to the Beta status leaving additional 
> > > > performance affecting logging or instrumentation in place?
> > > > 
> > > > 
> > > > 
> > > > Thanks,
> > > > 
> > > > 
> > > > 
> > > > Daniel
> > > > 
> > > > _______________________________________________
> > > > keycloak-dev mailing list
> > > > keycloak-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > 
> > 
> 


From bburke at redhat.com  Thu Feb  5 09:05:03 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 05 Feb 2015 09:05:03 -0500
Subject: [keycloak-dev] Slow Direct Grants API endpoint
In-Reply-To: <152ADF7679FD37488EE24A3FB5CA9AE1D4DE4A1C@EXCH-01.CORP.CIRA.CA>
References: <152ADF7679FD37488EE24A3FB5CA9AE1D4DA05CA@EXCH-01.CORP.CIRA.CA>	<853465969.10046513.1421243158655.JavaMail.zimbra@redhat.com>	<152ADF7679FD37488EE24A3FB5CA9AE1D4DA11BF@EXCH-01.CORP.CIRA.CA>	<86460392.10074076.1421245169796.JavaMail.zimbra@redhat.com>	<152ADF7679FD37488EE24A3FB5CA9AE1D4DA11F7@EXCH-01.CORP.CIRA.CA>	<1931160200.10779706.1421325416961.JavaMail.zimbra@redhat.com>	<152ADF7679FD37488EE24A3FB5CA9AE1D4DC840E@EXCH-02.CORP.CIRA.CA>	<1548314231.6086338.1422950340992.JavaMail.zimbra@redhat.com>
	<152ADF7679FD37488EE24A3FB5CA9AE1D4DE4A1C@EXCH-01.CORP.CIRA.CA>
Message-ID: <54D3788F.5050207@redhat.com>

UserSession is basically the representation of the token ithin the auth 
server.  Auth server uses it to keep track of the token so that the 
admin knows who has what tokens where, when, and how...

So no, can't do sessionless direct grants.

On 2/5/2015 8:56 AM, Daniel Baxter wrote:
> Hi,
>
> We finally got some load testing done with our system and with the hash adjustments it was pretty close to the same performance we were seeing before porting over. One thing I noticed is that every Direct Grants Access creates a session in Keycloak. Is it possible to perform a sessionless grant or at least get back the same session?
>
> A note about our architecture. We have 2 interfaces to our app; 1 web which runs in container with the EJB services and uses the web authentication perfectly. The second interface is a netty app that runs outside of the JBoss container to handle network api requests into our system with a specific protocol that is then handed over to the EJB services running in JBoss using a Remoting endpoint. In Weblogic we got a WorkContext when we did this which allowed us to authenticate against the EJB services once per session. However, JBoss seems to be missing the concept of a WorkContext and we are required to pass over java.naming.security.principal and java.naming.security.credentials with the jndi properties every time we do a Remote EJB call. This is where we are using Direct Grants Authentication because the jndi props are passing over only a username and password to the services and we have been required to authenticate each time to access the services.
>
> Now I want to avoid having to ping back with a Logout message on each call termination because it will add the travel time as lag to each API call and would prefer a sessionless authentication. Or is there a known tool or API for maintaining the Remoting session on JBoss similar to how the WorkContext works on Weblogic so we don't have to authenticate every hop over the Remoting endpoint.
>
> If there is sample code for Keycloak authenticated Remoting app to look at that might also be helpful.
>
> Thanks,
>
> Daniel
>
> -----Original Message-----
> From: Stian Thorgersen [mailto:stian at redhat.com]
> Sent: Tuesday, February 03, 2015 2:59 AM
> To: Daniel Baxter
> Cc: keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] Slow Direct Grants API endpoint
>
> Yep, that would do it ;)
>
> The hashing algorithm used by Keycloak is PBKDF2 and we only use 1 iteration by default, but we highly recommend increasing that though. We should probably also considering increasing the default.
>
> It's hard to give a definitive answer to this question as it is all relative, but for increased safety I'd say you should be looking at 5-10K iterations. Obviously the higher the better and you can and should cluster Keycloak for increased scalability and availability.
>
> ----- Original Message -----
>> From: "Daniel Baxter" <daniel.baxter at cira.ca>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Monday, 2 February, 2015 5:03:44 PM
>> Subject: RE: [keycloak-dev] Slow Direct Grants API endpoint
>>
>> Hi,
>>
>> I have just finished some testing on 1.1.0 Final and found that the
>> core problem was that through an abundance of caution we have
>> configured hash iterations to 100,000 (which I of course typoed to 1M
>> on Beta 2 when I configured it). The performance delta between 1.0 and
>> 1.1 is explained by the typo there. However, even with the change to
>> 100K in place I found the end point was still too slow (600~800ms) and
>> discovered that it scaled linearly down as I reduced the iterations.
>>
>> So I guess the question now is how many iterations is the default and
>> how many would be a recommended "overly cautious" amount of
>> iterations. I understand that keycloak defaults to Bcrypt hashing
>> which is designed explicitly to be computationally expensive so I
>> imagine iterations in the scope of 10-50 is probably sufficient to keep the passwords safe.
>>
>> - Daniel
>>
>> -----Original Message-----
>> From: Stian Thorgersen [mailto:stian at redhat.com]
>> Sent: Thursday, January 15, 2015 7:37 AM
>> To: Daniel Baxter
>> Cc: keycloak-dev at lists.jboss.org
>> Subject: Re: [keycloak-dev] Slow Direct Grants API endpoint
>>
>> Just ran some perf tests with default settings, 10 users and 10000 requests:
>>
>>    Version                Average (ms)    Throughput
>>    -------------------------------------------------
>>    1.0.4.Final            18              468
>>    1.1.0.Beta2            19              470
>>    1.1.0.Final-SNAPSHOT   20              426
>>
>>
>> ----- Original Message -----
>>> From: "Daniel Baxter" <daniel.baxter at cira.ca>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Wednesday, 14 January, 2015 3:56:03 PM
>>> Subject: RE: [keycloak-dev] Slow Direct Grants API endpoint
>>>
>>> Honestly I don't know how to check what is being used. I assume it
>>> would be whatever Keycloak Appliance defaults to. I checked with the
>>> guy who configured 1.0.4 for the other application and he doesn't
>>> know what we are using or how to configure it either. Sorry.
>>>
>>> - Daniel
>>>
>>> -----Original Message-----
>>> From: Stian Thorgersen [mailto:stian at redhat.com]
>>> Sent: Wednesday, January 14, 2015 9:19 AM
>>> To: Daniel Baxter
>>> Cc: keycloak-dev at lists.jboss.org
>>> Subject: Re: [keycloak-dev] Slow Direct Grants API endpoint
>>>
>>> What user session provider are you using?
>>>
>>> ----- Original Message -----
>>>> From: "Daniel Baxter" <daniel.baxter at cira.ca>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Wednesday, 14 January, 2015 3:01:17 PM
>>>> Subject: RE: [keycloak-dev] Slow Direct Grants API endpoint
>>>>
>>>> I am working with our ops team to configure 1.1.x with the same
>>>> level of hardware as our development 1.0.4 system (right now it is
>>>> running locally on a XEON workstation with piles of RAM).
>>>>
>>>> Both are connected to postgres databases and I am the only person
>>>> working on this portion of the project so it is just 1 user at a
>>>> time right now for 1.1.x. I have tested the database connection
>>>> and there is no real discernable performance irregularities for
>>>> anything that runs against that database.
>>>>
>>>> For Keycloak itself, it is mostly straight out of the box
>>>> appliance install for both 1.0.4 and 1.1.x and it runs on a single
>>>> machine for development use (I believe our prod deployment is/will be clustered).
>>>> The performance I am seeing is timeable on a stop watch for 1.1
>>>> and near enough to instant for
>>>> 1.0.4 (under 500 ms). Easily an order of magnitude. Given the
>>>> response I got (regarding the unexpectedness of the slow
>>>> behaviour) I want to make sure I have a completely fair comparison
>>>> and am working to set up
>>>> 1.1 on a dedicated development server to make the comparison
>>>> completely fair.
>>>>
>>>> - Daniel
>>>>
>>>> -----Original Message-----
>>>> From: Stian Thorgersen [mailto:stian at redhat.com]
>>>> Sent: Wednesday, January 14, 2015 8:46 AM
>>>> To: Daniel Baxter
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Subject: Re: [keycloak-dev] Slow Direct Grants API endpoint
>>>>
>>>> Direct grants are expected to be a little bit slower in 1.1.x due
>>>> to the requirement to persist more, but should certainly not be seconds.
>>>>
>>>> Can you give some more details please? Including
>>>>
>>>> * What DB are you using?
>>>> * Are you using mem, infinispan or jpa user session provider?
>>>> * Clustered?
>>>> * How many concurrent requests/users are you testing with?
>>>>
>>>> Any more accurate performance stats would also be helpful
>>>>
>>>> ----- Original Message -----
>>>>> From: "Daniel Baxter" <daniel.baxter at cira.ca>
>>>>> To: keycloak-dev at lists.jboss.org
>>>>> Sent: Monday, 12 January, 2015 9:23:42 PM
>>>>> Subject: [keycloak-dev] Slow Direct Grants API endpoint
>>>>>
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>> I am attempting to integrate Keycloak into an existing
>>>>> application to replace the homegrown user management system in
>>>>> place. We have a new project built from the ground up on
>>>>> Keycloak 1.0.4.Final which is exhibiting good performance.
>>>>> However this app that I am porting has a remoting component that
>>>>> connects to the server with bare username/password credentials
>>>>> over the EJB Remoting framework. I was hoping to use 1.1.0
>>>>> (currently Beta2) which provides a DirectAccessGrantsLoginModule
>>>>> which does exactly what I want (turns username and password into a KeycloakPrincipal).
>>>>> However, the turn around time from Keycloak is on the order of
>>>>> several seconds.
>>>>>
>>>>>
>>>>>
>>>>> I have used a bare REST client to execute the POSTs to both our
>>>>> 1.0.4 Keycloak and 1.1.0 Keycloak instances and have noted an
>>>>> order of magnitude difference in getting a response. Is this a
>>>>> known issue (I cannot find anything in the public bugs/tasks
>>>>> list)? Or is this due to the Beta status leaving additional
>>>>> performance affecting logging or instrumentation in place?
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>>
>>>>>
>>>>> Daniel
>>>>>
>>>>> _______________________________________________
>>>>> 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 coolmind182006 at gmail.com  Thu Feb  5 11:43:26 2015
From: coolmind182006 at gmail.com (coolmind182006 .)
Date: Thu, 5 Feb 2015 22:13:26 +0530
Subject: [keycloak-dev] keycloak-oauth-plugin hosting request
In-Reply-To: <CAM7bvCRhJjC8jXdQpsk_nmLpJkHwHOikE9g_D6G5LXheLsQt2Q@mail.gmail.com>
References: <CAM7bvCQBnAabSyOPTB=F3-LhhPe1jpvNgmsezAGv4QaaNfTXQw@mail.gmail.com>
	<977292214.7534857.1421048407668.JavaMail.zimbra@redhat.com>
	<CAM7bvCSzTupgYmh3uYxkGKe-KXcLc-v_k4cckuEND0YHPws24Q@mail.gmail.com>
	<1091169952.2994208.1422538171584.JavaMail.zimbra@redhat.com>
	<CAM7bvCRhJjC8jXdQpsk_nmLpJkHwHOikE9g_D6G5LXheLsQt2Q@mail.gmail.com>
Message-ID: <CAM7bvCQKQykFP-c3p0bEYp6Kq1Oh+nW=ep_y1WPHkjnwE7EEUQ@mail.gmail.com>

Further I have documented the design approach followed in keycloak here :

https://www.prokarma.com/blog/2015/02/03/lightweight-application-development

On Fri, Jan 30, 2015 at 10:59 PM, coolmind182006 . <coolmind182006 at gmail.com
> wrote:

> Thanks Stian,
>
> I am planning to provide Authorization for Jenkins, which is not yet
> implemented, After I am done with that, How that would be merged with
> keycloak repo ?, since I don't have write access to keycloak some manual
> work would be required to merge the code back to keycloak repo from my
> personal repo
>
> Further I written a blog on deploying keycloak on Tomcat
> <https://reachmnadeem.wordpress.com/2015/01/14/deploying-keycloak-in-tomcat/>and
> Tomee
> <https://reachmnadeem.wordpress.com/2015/01/14/deploying-keycloak-in-tomee/>
>
> And Finally Sonarqube is also integrated with Keycloak
> <https://reachmnadeem.wordpress.com/2015/01/22/integrating-keycloak-with-sonarqube/>
>
> I will provide authorization soon for sonarqube as well
>
>
>
>
>
> On Thu, Jan 29, 2015 at 6:59 PM, Stian Thorgersen <stian at redhat.com>
> wrote:
>
>> Finally got a chance to move and look at your video.
>>
>> I imported your repo to:
>> https://github.com/keycloak/jenkins-keycloak-plugin
>>
>> I also updated
>> https://wiki.jenkins-ci.org/display/JENKINS/keycloak-plugin to link to
>> the above repo.
>>
>> Really cool stuff, thanks for contributing this to us :)
>>
>> ----- Original Message -----
>> > From: "coolmind182006 ." <coolmind182006 at gmail.com>
>> > To: "Stian Thorgersen" <stian at redhat.com>
>> > Cc: keycloak-dev at lists.jboss.org
>> > Sent: Monday, January 12, 2015 7:20:24 PM
>> > Subject: Re: [keycloak-dev] keycloak-oauth-plugin hosting request
>> >
>> > Thanks a bundle, Let me know if I have to do anything..
>> >
>> >
>> >
>> > On Mon, Jan 12, 2015 at 1:10 PM, Stian Thorgersen <stian at redhat.com>
>> wrote:
>> >
>> > > Awesome, we'd love to pull this in to our GitHub
>> > >
>> > > ----- Original Message -----
>> > > > From: "coolmind182006 ." <coolmind182006 at gmail.com>
>> > > > To: keycloak-dev at lists.jboss.org
>> > > > Sent: Sunday, 11 January, 2015 12:22:03 PM
>> > > > Subject: [keycloak-dev] keycloak-oauth-plugin hosting request
>> > > >
>> > > >
>> > > > plugin name : keycloak-oauth
>> > > > github account : mnadeem
>> > > > existing repository :
>> https://github.com/mnadeem/jenkins-keycloak-plugin
>> > > > wiki :
>> https://wiki.jenkins-ci.org/display/JENKINS/keycloak-oauth-plugin
>> > > >
>> > > > _______________________________________________
>> > > > 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/20150205/837a366f/attachment.html 

From jorge.arias at corestechno.com  Thu Feb  5 12:39:01 2015
From: jorge.arias at corestechno.com (Jorge Dario Arias Lopez)
Date: Thu, 5 Feb 2015 12:39:01 -0500
Subject: [keycloak-dev] Authorization in angular
Message-ID: <CAG_H39ieccLLmOoR7OcWgZavM31Zm5yDogxA6VkDHbg9FMtbiA@mail.gmail.com>

Hi I'm developing a web page in angular with keycloak for autorization.

I followed this example
https://github.com/keycloak/keycloak/tree/master/examples/demo-template/angular-product-app
and it works pretty well.

Now I want to secure only part of my application. Is there any way to
achieve this behavior.

Thanks in advance

Jorge A.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150205/145dc2e1/attachment.html 

From mposolda at redhat.com  Fri Feb  6 03:57:30 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 06 Feb 2015 09:57:30 +0100
Subject: [keycloak-dev] Authorization in angular
In-Reply-To: <CAG_H39ieccLLmOoR7OcWgZavM31Zm5yDogxA6VkDHbg9FMtbiA@mail.gmail.com>
References: <CAG_H39ieccLLmOoR7OcWgZavM31Zm5yDogxA6VkDHbg9FMtbiA@mail.gmail.com>
Message-ID: <54D481FA.3050803@redhat.com>

Hi,

In the example, the angular is bootstrapped after the keycloak 
authentication is properly finished. It's also because keycloak 
authentication requires redirection of browser to KC and then 
redirecting back to the app. Theoretically you can combine it that 
keycloak authentication flow is called just when user visits some 
"secured" URL of your app, but still after redirecting from KC login 
screen back to the app, it will be better if angular is bootstrapped 
after keycloak authentication is finished (so in the "success" callback 
from keycloak.init call as it's done in the example).

Also note that there is no authorization in the JS application itself. 
The secured part are rest endpoints, which are secured by Bearer token 
obtained from the authentication of JS application. This is done in 
authInterceptor, which adds the bearer token to REST requests.

Marek

On 5.2.2015 18:39, Jorge Dario Arias Lopez wrote:
> Hi I'm developing a web page in angular with keycloak for autorization.
>
> I followed this example 
> https://github.com/keycloak/keycloak/tree/master/examples/demo-template/angular-product-app 
> and it works pretty well.
>
> Now I want to secure only part of my application. Is there any way to 
> achieve this behavior.
>
> Thanks in advance
>
> Jorge A.
>
>
> _______________________________________________
> 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/20150206/81d83618/attachment-0001.html 

From mposolda at redhat.com  Fri Feb  6 04:03:45 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 06 Feb 2015 10:03:45 +0100
Subject: [keycloak-dev] Facing Issue with Resource Server in Clustered
 Environment
In-Reply-To: <C5AF53298BAB5F4A88B28966E43B40AD0565C4BB@xmb-aln-x12.cisco.com>
References: <C5AF53298BAB5F4A88B28966E43B40AD0565BB00@xmb-aln-x12.cisco.com>	<1743939526.3724664.1422602848465.JavaMail.zimbra@redhat.com>	<C5AF53298BAB5F4A88B28966E43B40AD0565BB18@xmb-aln-x12.cisco.com>	<1683679347.3736800.1422604072720.JavaMail.zimbra@redhat.com>
	<C5AF53298BAB5F4A88B28966E43B40AD0565BB76@xmb-aln-x12.cisco.com>
	<54CF358B.2030308@redhat.com>
	<C5AF53298BAB5F4A88B28966E43B40AD0565C3E0@xmb-aln-x12.cisco.com>
	<54D22E4D.1040800@redhat.com>
	<C5AF53298BAB5F4A88B28966E43B40AD0565C4BB@xmb-aln-x12.cisco.com>
Message-ID: <54D48371.3050708@redhat.com>

It looks there might be issue with session replication in your environment.

When you bootstrap your domain with cluster nodes, are you seeing message in the log similar to:

INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-10,shared=udp)
ISPN000094: Received new cluster view: [node1/web|1] (2) [node1/web, node2/web]


Does it help if you try to switch to

"token-store": "cookie"

in the adapter configuration of your application?


Thanks,
Marek


On 5.2.2015 06:45, Bappaditya Gorai (bgorai) wrote:
> Please find my response inline for your queries.
> Thanks
> Bappaditya Gorai
> *From:* Marek Posolda [mailto:mposolda at redhat.com]
> *Sent:* Wednesday, February 04, 2015 8:06 PM
> *To:* Bappaditya Gorai (bgorai); Stian Thorgersen
> *Cc:* keycloak-dev at lists.jboss.org
> *Subject:* Re: [keycloak-dev] Facing Issue with Resource Server in 
> Clustered Environment
> Hi,
>
> I am not sure about the details of your environment. You mentioned 
> that you're not interested in clustering of keycloak server.
> So am I understand correctly that you have just 1 node as keycloak 
> server and 2 nodes with your application deployed?
> *[[Bappaditya]]* Yes, only one instance of keycloak Server (Running in 
> standalone mode). My Application is deployed in 2 nodes (cluster) and 
> running in domain mode.
> Are you using "distributable" tag in web.xml of your app on both nodes 
> to ensure session replication?
> *[[Bappaditya]]* Yes, Application is using ?distributable? tag in 
> web.xml.
> Are you using loadbalancer?
> *[[Bappaditya]] * We are using mod_cluster & httpd. Sticky sessions 
> disabled.
>
>
> Marek
>
> On 4.2.2015 13:37, Bappaditya Gorai (bgorai) wrote:
> Thanks for the detailed description. Still, It seems in case of 
> Clustered Resource environment (distributable without Sticky sessions) 
> we are relying on session replication to happen immediately between 
> CODE_TO_TOKEN and Resource Hit(302), which may or may not happen. We 
> are now facing the same issue where After CODE_TO_TOKEN client is 
> redirected to Login URL again.
> Are we addressing this scenario with 1.1.0 Final ?
> Thanks
> Bappaditya Gorai
> -----Original Message-----
> From: Marek Posolda [_mailto:mposolda at redhat.com_]
> Sent: Monday, February 02, 2015 2:00 PM
> To: Bappaditya Gorai (bgorai); Stian Thorgersen
> Cc: _keycloak-dev at lists.jboss.org_ <mailto:keycloak-dev at lists.jboss.org>
> Subject: Re: [keycloak-dev] Facing Issue with Resource Server in 
> Clustered Environment
> Hi,
> it's not stateless by default. Data about keycloak authenticated 
> principal are saved in HTTP session by default and can be replicated 
> across cluster nodes (replication works as long as your application is 
> marked as "distributable" in web.xml).
> However we support stateless adapter, which won't save anything in 
> HTTP Session and won't create HTTP session and JSESSIONID cookie at 
> all (unless you're calling httpRequest.getSession() in your own 
> application). Instead all the data are saved in cookie.
> Some more info in docs:
> _http://docs.jboss.org/keycloak/docs/1.1.0.Final/userguide/html/applicationClustering.html#stateless-token-store_ 
> <http://docs.jboss.org/keycloak/docs/1.1.0.Final/userguide/html/applicationClustering.html>
> Marek
> On 30.1.2015 11:26, Bappaditya Gorai (bgorai) wrote:
> > Thanks for clarifying.  So, I think adapter has become stateless in 1.1.0.Final. Is my understanding correct?
> >
> >
> > -----Original Message-----
> > From: Stian Thorgersen [_mailto:stian at redhat.com_]
> > Sent: Friday, January 30, 2015 1:18 PM
> > To: Bappaditya Gorai (bgorai)
> > Cc:_keycloak-dev at lists.jboss.org_ <mailto:keycloak-dev at lists.jboss.org>
> > Subject: Re: [keycloak-dev] Facing Issue with Resource Server in
> > Clustered Environment
> >
> >
> >
> > ----- Original Message -----
> >> From: "Bappaditya Gorai (bgorai)" <_bgorai at cisco.com_ <mailto:bgorai at cisco.com>>
> >> To: "Stian Thorgersen" <_stian at redhat.com_ <mailto:stian at redhat.com>>
> >> Cc:_keycloak-dev at lists.jboss.org_ <mailto:keycloak-dev at lists.jboss.org>
> >> Sent: Friday, 30 January, 2015 8:38:49 AM
> >> Subject: RE: [keycloak-dev] Facing Issue with Resource Server in Clustered   Environment
> >>
> >> We are not talking about clustering for Keycloak server. The setup is
> >> for Resource Server (Keycloak Adapter)  in clustered environment.
> > Same answer
> >
> >> Thanks
> >> Bappaditya Gorai
> >>
> >> -----Original Message-----
> >> From: Stian Thorgersen [_mailto:stian at redhat.com_]
> >> Sent: Friday, January 30, 2015 12:57 PM
> >> To: Bappaditya Gorai (bgorai)
> >> Cc:_keycloak-dev at lists.jboss.org_ <mailto:keycloak-dev at lists.jboss.org>
> >> Subject: Re: [keycloak-dev] Facing Issue with Resource Server in
> >> Clustered Environment
> >>
> >> 1.0.4.Final had very limited support for clustering, please upgrade
> >> to 1.1.0.Final and refer to chapter 24 and 25 in the documentation
> >> (_http://docs.jboss.org/keycloak/docs/1.1.0.Final/userguide/html/clustering.html_).
> >>
> >> ----- Original Message -----
> >>> From: "Bappaditya Gorai (bgorai)" <_bgorai at cisco.com_ <mailto:bgorai at cisco.com>>
> >>> To:_keycloak-dev at lists.jboss.org_ <mailto:keycloak-dev at lists.jboss.org>
> >>> Sent: Friday, 30 January, 2015 8:22:26 AM
> >>> Subject: [keycloak-dev] Facing Issue with Resource Server in Clustered
> >>>      Environment
> >>>
> >>>
> >>>
> >>> Hi Team,
> >>>
> >>> Please find the details on setup and observation below. Please
> >>> provide your suggestion on how to overcome this issue. We are using
> >>> Keycloak 1.0.4.Final (Adapter & Server).
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Setup:
> >>>
> >>> 1. We have brought up Jboss cluster ( Using mod_cluster, httpd )
> >>> with
> >>> 2 nodes in domain mode and enabled session replication between these nodes.
> >>>
> >>> 2. Our Recourse server is deployed in this clustered environment
> >>> with distributable and Sticky session Off.
> >>>
> >>>
> >>>
> >>> Behavior observed :
> >>>
> >>> During the Authorization/Authentication process ,when Initial
> >>> call(Resource
> >>> Access) lands on master and next redirection (post Code To token)
> >>> falls on slave Adapter is treating it as a new session and
> >>> redirecting to login URL again. So we ended up with circular redirection error.
> >>> After further investigation seems like session replication delay is
> >>> causing adapter to behave this way. As the redirection call happens
> >>> very quickly and this results in circular redirection error.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> NOTE: Sticky Session in mod_cluster environment solves the issue but
> >>> it does not provide true load balancing. Therefore we are not
> >>> considering Stick session option.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Thanks
> >>>
> >>> Bappaditya Gorai
> >>>
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>>_keycloak-dev at lists.jboss.org_ <mailto:keycloak-dev at lists.jboss.org>
> >>>_https://lists.jboss.org/mailman/listinfo/keycloak-dev_
> > _______________________________________________
> > keycloak-dev mailing list
> >_keycloak-dev at lists.jboss.org_ <mailto:keycloak-dev at lists.jboss.org>
> >_https://lists.jboss.org/mailman/listinfo/keycloak-dev_

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150206/86ec20f2/attachment.html 

From bgorai at cisco.com  Fri Feb  6 06:00:41 2015
From: bgorai at cisco.com (Bappaditya Gorai (bgorai))
Date: Fri, 6 Feb 2015 11:00:41 +0000
Subject: [keycloak-dev] Facing Issue with Resource Server in Clustered
 Environment
In-Reply-To: <54D48371.3050708@redhat.com>
References: <C5AF53298BAB5F4A88B28966E43B40AD0565BB00@xmb-aln-x12.cisco.com>
	<1743939526.3724664.1422602848465.JavaMail.zimbra@redhat.com>
	<C5AF53298BAB5F4A88B28966E43B40AD0565BB18@xmb-aln-x12.cisco.com>
	<1683679347.3736800.1422604072720.JavaMail.zimbra@redhat.com>
	<C5AF53298BAB5F4A88B28966E43B40AD0565BB76@xmb-aln-x12.cisco.com>
	<54CF358B.2030308@redhat.com>
	<C5AF53298BAB5F4A88B28966E43B40AD0565C3E0@xmb-aln-x12.cisco.com>
	<54D22E4D.1040800@redhat.com>
	<C5AF53298BAB5F4A88B28966E43B40AD0565C4BB@xmb-aln-x12.cisco.com>
	<54D48371.3050708@redhat.com>
Message-ID: <C5AF53298BAB5F4A88B28966E43B40AD0565C689@xmb-aln-x12.cisco.com>

We have verified it, session replication is happening without issue.

We found one JIRA which seems somewhat relevant to our issue.  We are currently using Keycloak 1.0.4.Final release, however this JIRA got fixed in later version. So we will upgrade to 1.1.0.Final and see it that helps.
https://issues.jboss.org/browse/KEYCLOAK-743

Cookie as token-store can definitely help.  Although, wo would like to know whether distributable (replicated http session) without sticky session is supported by adapter.

Thanks
Bappaditya Gorai

From: Marek Posolda [mailto:mposolda at redhat.com]
Sent: Friday, February 06, 2015 2:34 PM
To: Bappaditya Gorai (bgorai); Stian Thorgersen
Cc: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] Facing Issue with Resource Server in Clustered Environment

It looks there might be issue with session replication in your environment.




When you bootstrap your domain with cluster nodes, are you seeing message in the log similar to:



INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-10,shared=udp)

ISPN000094: Received new cluster view: [node1/web|1] (2) [node1/web, node2/web]



Does it help if you try to switch to

"token-store": "cookie"



in the adapter configuration of your application?





Thanks,

Marek

On 5.2.2015 06:45, Bappaditya Gorai (bgorai) wrote:
Please find my response inline for your queries.

Thanks
Bappaditya Gorai

From: Marek Posolda [mailto:mposolda at redhat.com]
Sent: Wednesday, February 04, 2015 8:06 PM
To: Bappaditya Gorai (bgorai); Stian Thorgersen
Cc: keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
Subject: Re: [keycloak-dev] Facing Issue with Resource Server in Clustered Environment

Hi,

I am not sure about the details of your environment. You mentioned that you're not interested in clustering of keycloak server.

So am I understand correctly that you have just 1 node as keycloak server and 2 nodes with your application deployed?
[[Bappaditya]] Yes, only one instance of keycloak Server (Running in standalone mode). My Application is deployed in 2 nodes (cluster) and running in domain mode.

Are you using "distributable" tag in web.xml of your app on both nodes to ensure session replication?
[[Bappaditya]] Yes, Application is using "distributable" tag in web.xml.

Are you using loadbalancer?
[[Bappaditya]] We are using mod_cluster & httpd. Sticky sessions disabled.


Marek

On 4.2.2015 13:37, Bappaditya Gorai (bgorai) wrote:
Thanks for the detailed description. Still, It seems in case of Clustered Resource environment (distributable without Sticky sessions) we are relying on session replication to happen immediately between CODE_TO_TOKEN and Resource Hit(302), which may or may not happen. We are now facing the same issue where After CODE_TO_TOKEN client is redirected to Login URL again.

Are we addressing this scenario with 1.1.0 Final ?


Thanks
Bappaditya Gorai

-----Original Message-----
From: Marek Posolda [mailto:mposolda at redhat.com]
Sent: Monday, February 02, 2015 2:00 PM
To: Bappaditya Gorai (bgorai); Stian Thorgersen
Cc: keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
Subject: Re: [keycloak-dev] Facing Issue with Resource Server in Clustered Environment

Hi,

it's not stateless by default. Data about keycloak authenticated principal are saved in HTTP session by default and can be replicated across cluster nodes (replication works as long as your application is marked as "distributable" in web.xml).

However we support stateless adapter, which won't save anything in HTTP Session and won't create HTTP session and JSESSIONID cookie at all (unless you're calling httpRequest.getSession() in your own application). Instead all the data are saved in cookie.

Some more info in docs:
http://docs.jboss.org/keycloak/docs/1.1.0.Final/userguide/html/applicationClustering.html#stateless-token-store<http://docs.jboss.org/keycloak/docs/1.1.0.Final/userguide/html/applicationClustering.html>

Marek

On 30.1.2015 11:26, Bappaditya Gorai (bgorai) wrote:
> Thanks for clarifying.  So, I think adapter has become stateless in 1.1.0.Final. Is my understanding correct?
>
>
> -----Original Message-----
> From: Stian Thorgersen [mailto:stian at redhat.com]
> Sent: Friday, January 30, 2015 1:18 PM
> To: Bappaditya Gorai (bgorai)
> Cc: keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
> Subject: Re: [keycloak-dev] Facing Issue with Resource Server in
> Clustered Environment
>
>
>
> ----- Original Message -----
>> From: "Bappaditya Gorai (bgorai)" <bgorai at cisco.com<mailto:bgorai at cisco.com>>
>> To: "Stian Thorgersen" <stian at redhat.com<mailto:stian at redhat.com>>
>> Cc: keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
>> Sent: Friday, 30 January, 2015 8:38:49 AM
>> Subject: RE: [keycloak-dev] Facing Issue with Resource Server in Clustered   Environment
>>
>> We are not talking about clustering for Keycloak server. The setup is
>> for Resource Server (Keycloak Adapter)  in clustered environment.
> Same answer
>
>> Thanks
>> Bappaditya Gorai
>>
>> -----Original Message-----
>> From: Stian Thorgersen [mailto:stian at redhat.com]
>> Sent: Friday, January 30, 2015 12:57 PM
>> To: Bappaditya Gorai (bgorai)
>> Cc: keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
>> Subject: Re: [keycloak-dev] Facing Issue with Resource Server in
>> Clustered Environment
>>
>> 1.0.4.Final had very limited support for clustering, please upgrade
>> to 1.1.0.Final and refer to chapter 24 and 25 in the documentation
>> (http://docs.jboss.org/keycloak/docs/1.1.0.Final/userguide/html/clustering.html).
>>
>> ----- Original Message -----
>>> From: "Bappaditya Gorai (bgorai)" <bgorai at cisco.com<mailto:bgorai at cisco.com>>
>>> To: keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
>>> Sent: Friday, 30 January, 2015 8:22:26 AM
>>> Subject: [keycloak-dev] Facing Issue with Resource Server in Clustered
>>>      Environment
>>>
>>>
>>>
>>> Hi Team,
>>>
>>> Please find the details on setup and observation below. Please
>>> provide your suggestion on how to overcome this issue. We are using
>>> Keycloak 1.0.4.Final (Adapter & Server).
>>>
>>>
>>>
>>>
>>>
>>> Setup:
>>>
>>> 1. We have brought up Jboss cluster ( Using mod_cluster, httpd )
>>> with
>>> 2 nodes in domain mode and enabled session replication between these nodes.
>>>
>>> 2. Our Recourse server is deployed in this clustered environment
>>> with distributable and Sticky session Off.
>>>
>>>
>>>
>>> Behavior observed :
>>>
>>> During the Authorization/Authentication process ,when Initial
>>> call(Resource
>>> Access) lands on master and next redirection (post Code To token)
>>> falls on slave Adapter is treating it as a new session and
>>> redirecting to login URL again. So we ended up with circular redirection error.
>>> After further investigation seems like session replication delay is
>>> causing adapter to behave this way. As the redirection call happens
>>> very quickly and this results in circular redirection error.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> NOTE: Sticky Session in mod_cluster environment solves the issue but
>>> it does not provide true load balancing. Therefore we are not
>>> considering Stick session option.
>>>
>>>
>>>
>>>
>>>
>>> Thanks
>>>
>>> Bappaditya Gorai
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150206/516f84d2/attachment-0001.html 

From mposolda at redhat.com  Fri Feb  6 06:09:50 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 06 Feb 2015 12:09:50 +0100
Subject: [keycloak-dev] Facing Issue with Resource Server in Clustered
 Environment
In-Reply-To: <C5AF53298BAB5F4A88B28966E43B40AD0565C689@xmb-aln-x12.cisco.com>
References: <C5AF53298BAB5F4A88B28966E43B40AD0565BB00@xmb-aln-x12.cisco.com>	<1743939526.3724664.1422602848465.JavaMail.zimbra@redhat.com>	<C5AF53298BAB5F4A88B28966E43B40AD0565BB18@xmb-aln-x12.cisco.com>	<1683679347.3736800.1422604072720.JavaMail.zimbra@redhat.com>
	<C5AF53298BAB5F4A88B28966E43B40AD0565BB76@xmb-aln-x12.cisco.com>
	<54CF358B.2030308@redhat.com>
	<C5AF53298BAB5F4A88B28966E43B40AD0565C3E0@xmb-aln-x12.cisco.com>
	<54D22E4D.1040800@redhat.com>
	<C5AF53298BAB5F4A88B28966E43B40AD0565C4BB@xmb-aln-x12.cisco.com>
	<54D48371.3050708@redhat.com>
	<C5AF53298BAB5F4A88B28966E43B40AD0565C689@xmb-aln-x12.cisco.com>
Message-ID: <54D4A0FE.9030505@redhat.com>

Oops, I somehow assumed that you upgraded already :-)

We didn't support cluster for adapters at 1.0.4.Final. You can also see 
that clustering documentations mentioned above are available in our 
reference guide in 1.1.0.Final, but not in In 1.0.4.Final. So I believe 
that upgrading should solve your issues.

Marek

On 6.2.2015 12:00, Bappaditya Gorai (bgorai) wrote:
>
> We have verified it, session replication is happening without issue.
>
> We found one JIRA which seems somewhat relevant to our issue.  We are 
> currently using *Keycloak 1.0.4.Final* release, however this JIRA got 
> fixed in later version. So we will upgrade to *1.1.0.Final* and see it 
> that helps.
>
> _https://issues.jboss.org/browse/KEYCLOAK-743_
>
> Cookie as token-store can definitely help.  Although, wo would like to 
> know whether distributable (replicated http session) without sticky 
> session is supported by adapter.
>
> Thanks
>
> Bappaditya Gorai
>
> *From:*Marek Posolda [mailto:mposolda at redhat.com]
> *Sent:* Friday, February 06, 2015 2:34 PM
> *To:* Bappaditya Gorai (bgorai); Stian Thorgersen
> *Cc:* keycloak-dev at lists.jboss.org
> *Subject:* Re: [keycloak-dev] Facing Issue with Resource Server in 
> Clustered Environment
>
> It looks there might be issue with session replication in your 
> environment.
>
>   
> When you bootstrap your domain with cluster nodes, are you seeing message in the log similar to:
>   
> INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-10,shared=udp)
> ISPN000094: Received new cluster view: [node1/web|1] (2) [node1/web, node2/web]
>   
> Does it help if you try to switch to
> "token-store": "cookie"
>   
> in the adapter configuration of your application?
>   
>   
> Thanks,
> Marek
>
>
> On 5.2.2015 06:45, Bappaditya Gorai (bgorai) wrote:
>
>     Please find my response inline for your queries.
>
>     Thanks
>
>     Bappaditya Gorai
>
>     *From:*Marek Posolda [mailto:mposolda at redhat.com]
>     *Sent:* Wednesday, February 04, 2015 8:06 PM
>     *To:* Bappaditya Gorai (bgorai); Stian Thorgersen
>     *Cc:* keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>
>     *Subject:* Re: [keycloak-dev] Facing Issue with Resource Server in
>     Clustered Environment
>
>     Hi,
>
>     I am not sure about the details of your environment. You mentioned
>     that you're not interested in clustering of keycloak server.
>
>     So am I understand correctly that you have just 1 node as keycloak
>     server and 2 nodes with your application deployed?
>
>     *[[Bappaditya]]*Yes, only one instance of keycloak Server (Running
>     in standalone mode). My Application is deployed in 2 nodes
>     (cluster) and running in domain mode.
>
>     Are you using "distributable" tag in web.xml of your app on both
>     nodes to ensure session replication?
>
>     *[[Bappaditya]]*Yes, Application is using ?distributable? tag in
>     web.xml.
>
>     Are you using loadbalancer?
>
>     *[[Bappaditya]] *We are using mod_cluster & httpd. Sticky sessions
>     disabled.
>
>
>
>     Marek
>
>     On 4.2.2015 13:37, Bappaditya Gorai (bgorai) wrote:
>
>     Thanks for the detailed description. Still, It seems in case of
>     Clustered Resource environment (distributable without Sticky
>     sessions) we are relying on session replication to happen
>     immediately between CODE_TO_TOKEN and Resource Hit(302), which may
>     or may not happen. We are now facing the same issue where After
>     CODE_TO_TOKEN client is redirected to Login URL again.
>
>     Are we addressing this scenario with 1.1.0 Final ?
>
>     Thanks
>
>     Bappaditya Gorai
>
>     -----Original Message-----
>     From: Marek Posolda [mailto:mposolda at redhat.com]
>     Sent: Monday, February 02, 2015 2:00 PM
>     To: Bappaditya Gorai (bgorai); Stian Thorgersen
>     Cc: keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     Subject: Re: [keycloak-dev] Facing Issue with Resource Server in
>     Clustered Environment
>
>     Hi,
>
>     it's not stateless by default. Data about keycloak authenticated
>     principal are saved in HTTP session by default and can be
>     replicated across cluster nodes (replication works as long as your
>     application is marked as "distributable" in web.xml).
>
>     However we support stateless adapter, which won't save anything in
>     HTTP Session and won't create HTTP session and JSESSIONID cookie
>     at all (unless you're calling httpRequest.getSession() in your own
>     application). Instead all the data are saved in cookie.
>
>     Some more info in docs:
>
>     http://docs.jboss.org/keycloak/docs/1.1.0.Final/userguide/html/applicationClustering.html#stateless-token-store
>     <http://docs.jboss.org/keycloak/docs/1.1.0.Final/userguide/html/applicationClustering.html>
>
>     Marek
>
>     On 30.1.2015 11:26, Bappaditya Gorai (bgorai) wrote:
>
>     > Thanks for clarifying.  So, I think adapter has become stateless
>     in 1.1.0.Final. Is my understanding correct?
>
>     >
>
>     >
>
>     > -----Original Message-----
>
>     > From: Stian Thorgersen [mailto:stian at redhat.com]
>
>     > Sent: Friday, January 30, 2015 1:18 PM
>
>     > To: Bappaditya Gorai (bgorai)
>
>     > Cc: keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>
>
>     > Subject: Re: [keycloak-dev] Facing Issue with Resource Server in
>
>     > Clustered Environment
>
>     >
>
>     >
>
>     >
>
>     > ----- Original Message -----
>
>     >> From: "Bappaditya Gorai (bgorai)" <bgorai at cisco.com
>     <mailto:bgorai at cisco.com>>
>
>     >> To: "Stian Thorgersen" <stian at redhat.com <mailto:stian at redhat.com>>
>
>     >> Cc: keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>
>
>     >> Sent: Friday, 30 January, 2015 8:38:49 AM
>
>     >> Subject: RE: [keycloak-dev] Facing Issue with Resource Server in
>     Clustered   Environment
>
>     >>
>
>     >> We are not talking about clustering for Keycloak server. The
>     setup is
>
>     >> for Resource Server (Keycloak Adapter)  in clustered environment.
>
>     > Same answer
>
>     >
>
>     >> Thanks
>
>     >> Bappaditya Gorai
>
>     >>
>
>     >> -----Original Message-----
>
>     >> From: Stian Thorgersen [mailto:stian at redhat.com]
>
>     >> Sent: Friday, January 30, 2015 12:57 PM
>
>     >> To: Bappaditya Gorai (bgorai)
>
>     >> Cc: keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>
>
>     >> Subject: Re: [keycloak-dev] Facing Issue with Resource Server in
>
>     >> Clustered Environment
>
>     >>
>
>     >> 1.0.4.Final had very limited support for clustering, please upgrade
>
>     >> to 1.1.0.Final and refer to chapter 24 and 25 in the documentation
>
>     >> (http://docs.jboss.org/keycloak/docs/1.1.0.Final/userguide/html/clustering.html).
>
>     >>
>
>     >> ----- Original Message -----
>
>     >>> From: "Bappaditya Gorai (bgorai)" <bgorai at cisco.com
>     <mailto:bgorai at cisco.com>>
>
>     >>> To: keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>
>
>     >>> Sent: Friday, 30 January, 2015 8:22:26 AM
>
>     >>> Subject: [keycloak-dev] Facing Issue with Resource Server in
>     Clustered
>
>     >>>Environment
>
>     >>>
>
>     >>>
>
>     >>>
>
>     >>> Hi Team,
>
>     >>>
>
>     >>> Please find the details on setup and observation below. Please
>
>     >>> provide your suggestion on how to overcome this issue. We are using
>
>     >>> Keycloak 1.0.4.Final (Adapter & Server).
>
>     >>>
>
>     >>>
>
>     >>>
>
>     >>>
>
>     >>>
>
>     >>> Setup:
>
>     >>>
>
>     >>> 1. We have brought up Jboss cluster ( Using mod_cluster, httpd )
>
>     >>> with
>
>     >>> 2 nodes in domain mode and enabled session replication between
>     these nodes.
>
>     >>>
>
>     >>> 2. Our Recourse server is deployed in this clustered environment
>
>     >>> with distributable and Sticky session Off.
>
>     >>>
>
>     >>>
>
>     >>>
>
>     >>> Behavior observed :
>
>     >>>
>
>     >>> During the Authorization/Authentication process ,when Initial
>
>     >>> call(Resource
>
>     >>> Access) lands on master and next redirection (post Code To token)
>
>     >>> falls on slave Adapter is treating it as a new session and
>
>     >>> redirecting to login URL again. So we ended up with circular
>     redirection error.
>
>     >>> After further investigation seems like session replication delay is
>
>     >>> causing adapter to behave this way. As the redirection call happens
>
>     >>> very quickly and this results in circular redirection error.
>
>     >>>
>
>     >>>
>
>     >>>
>
>     >>>
>
>     >>>
>
>     >>>
>
>     >>>
>
>     >>> NOTE: Sticky Session in mod_cluster environment solves the issue but
>
>     >>> it does not provide true load balancing. Therefore we are not
>
>     >>> considering Stick session option.
>
>     >>>
>
>     >>>
>
>     >>>
>
>     >>>
>
>     >>>
>
>     >>> Thanks
>
>     >>>
>
>     >>> Bappaditya Gorai
>
>     >>>
>
>     >>> _______________________________________________
>
>     >>> keycloak-dev mailing list
>
>     >>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>
>     >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>     > _______________________________________________
>
>     > keycloak-dev mailing list
>
>     > keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>
>     > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150206/8e75f1b2/attachment-0001.html 

From psilva at redhat.com  Fri Feb  6 08:15:44 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 6 Feb 2015 08:15:44 -0500 (EST)
Subject: [keycloak-dev] Switch to enable token retrieval by apps from
	brokered Idps
In-Reply-To: <2066064727.7617939.1423228321580.JavaMail.zimbra@redhat.com>
Message-ID: <302451741.7618973.1423228544884.JavaMail.zimbra@redhat.com>

Hi,

    Does makes sense to enable an identity provider to an application and *not* allow the same application to retrieve tokens from the identity provider ?

Regards.
Pedro Igor    

From bburke at redhat.com  Fri Feb  6 10:17:26 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 06 Feb 2015 10:17:26 -0500
Subject: [keycloak-dev] Slow Direct Grants API endpoint
In-Reply-To: <1548314231.6086338.1422950340992.JavaMail.zimbra@redhat.com>
References: <152ADF7679FD37488EE24A3FB5CA9AE1D4DA05CA@EXCH-01.CORP.CIRA.CA>	<853465969.10046513.1421243158655.JavaMail.zimbra@redhat.com>	<152ADF7679FD37488EE24A3FB5CA9AE1D4DA11BF@EXCH-01.CORP.CIRA.CA>	<86460392.10074076.1421245169796.JavaMail.zimbra@redhat.com>	<152ADF7679FD37488EE24A3FB5CA9AE1D4DA11F7@EXCH-01.CORP.CIRA.CA>	<1931160200.10779706.1421325416961.JavaMail.zimbra@redhat.com>	<152ADF7679FD37488EE24A3FB5CA9AE1D4DC840E@EXCH-02.CORP.CIRA.CA>
	<1548314231.6086338.1422950340992.JavaMail.zimbra@redhat.com>
Message-ID: <54D4DB06.2030807@redhat.com>

Sorry, just getting caught up...

The default is 1 iteration because I don't want people trying out 
keycloak and saying "You are SLOW!".  The default should be either 1 or 
20k as anything more or less is pointless.  My vote is to keep it at 1 
iteration and let the user decide how safe they want to be.

On 2/3/2015 2:59 AM, Stian Thorgersen wrote:
> Yep, that would do it ;)
>
> The hashing algorithm used by Keycloak is PBKDF2 and we only use 1 iteration by default, but we highly recommend increasing that though. We should probably also considering increasing the default.
>
> It's hard to give a definitive answer to this question as it is all relative, but for increased safety I'd say you should be looking at 5-10K iterations. Obviously the higher the better and you can and should cluster Keycloak for increased scalability and availability.
>
> ----- Original Message -----
>> From: "Daniel Baxter" <daniel.baxter at cira.ca>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Monday, 2 February, 2015 5:03:44 PM
>> Subject: RE: [keycloak-dev] Slow Direct Grants API endpoint
>>
>> Hi,
>>
>> I have just finished some testing on 1.1.0 Final and found that the core
>> problem was that through an abundance of caution we have configured hash
>> iterations to 100,000 (which I of course typoed to 1M on Beta 2 when I
>> configured it). The performance delta between 1.0 and 1.1 is explained by
>> the typo there. However, even with the change to 100K in place I found the
>> end point was still too slow (600~800ms) and discovered that it scaled
>> linearly down as I reduced the iterations.
>>
>> So I guess the question now is how many iterations is the default and how
>> many would be a recommended "overly cautious" amount of iterations. I
>> understand that keycloak defaults to Bcrypt hashing which is designed
>> explicitly to be computationally expensive so I imagine iterations in the
>> scope of 10-50 is probably sufficient to keep the passwords safe.
>>
>> - Daniel
>>
>> -----Original Message-----
>> From: Stian Thorgersen [mailto:stian at redhat.com]
>> Sent: Thursday, January 15, 2015 7:37 AM
>> To: Daniel Baxter
>> Cc: keycloak-dev at lists.jboss.org
>> Subject: Re: [keycloak-dev] Slow Direct Grants API endpoint
>>
>> Just ran some perf tests with default settings, 10 users and 10000 requests:
>>
>>    Version                Average (ms)    Throughput
>>    -------------------------------------------------
>>    1.0.4.Final            18              468
>>    1.1.0.Beta2            19              470
>>    1.1.0.Final-SNAPSHOT   20              426
>>
>>
>> ----- Original Message -----
>>> From: "Daniel Baxter" <daniel.baxter at cira.ca>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Wednesday, 14 January, 2015 3:56:03 PM
>>> Subject: RE: [keycloak-dev] Slow Direct Grants API endpoint
>>>
>>> Honestly I don't know how to check what is being used. I assume it
>>> would be whatever Keycloak Appliance defaults to. I checked with the
>>> guy who configured 1.0.4 for the other application and he doesn't know
>>> what we are using or how to configure it either. Sorry.
>>>
>>> - Daniel
>>>
>>> -----Original Message-----
>>> From: Stian Thorgersen [mailto:stian at redhat.com]
>>> Sent: Wednesday, January 14, 2015 9:19 AM
>>> To: Daniel Baxter
>>> Cc: keycloak-dev at lists.jboss.org
>>> Subject: Re: [keycloak-dev] Slow Direct Grants API endpoint
>>>
>>> What user session provider are you using?
>>>
>>> ----- Original Message -----
>>>> From: "Daniel Baxter" <daniel.baxter at cira.ca>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Wednesday, 14 January, 2015 3:01:17 PM
>>>> Subject: RE: [keycloak-dev] Slow Direct Grants API endpoint
>>>>
>>>> I am working with our ops team to configure 1.1.x with the same
>>>> level of hardware as our development 1.0.4 system (right now it is
>>>> running locally on a XEON workstation with piles of RAM).
>>>>
>>>> Both are connected to postgres databases and I am the only person
>>>> working on this portion of the project so it is just 1 user at a
>>>> time right now for 1.1.x. I have tested the database connection and
>>>> there is no real discernable performance irregularities for anything
>>>> that runs against that database.
>>>>
>>>> For Keycloak itself, it is mostly straight out of the box appliance
>>>> install for both 1.0.4 and 1.1.x and it runs on a single machine for
>>>> development use (I believe our prod deployment is/will be clustered).
>>>> The performance I am seeing is timeable on a stop watch for 1.1 and
>>>> near enough to instant for
>>>> 1.0.4 (under 500 ms). Easily an order of magnitude. Given the
>>>> response I got (regarding the unexpectedness of the slow behaviour)
>>>> I want to make sure I have a completely fair comparison and am
>>>> working to set up
>>>> 1.1 on a dedicated development server to make the comparison
>>>> completely fair.
>>>>
>>>> - Daniel
>>>>
>>>> -----Original Message-----
>>>> From: Stian Thorgersen [mailto:stian at redhat.com]
>>>> Sent: Wednesday, January 14, 2015 8:46 AM
>>>> To: Daniel Baxter
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Subject: Re: [keycloak-dev] Slow Direct Grants API endpoint
>>>>
>>>> Direct grants are expected to be a little bit slower in 1.1.x due to
>>>> the requirement to persist more, but should certainly not be seconds.
>>>>
>>>> Can you give some more details please? Including
>>>>
>>>> * What DB are you using?
>>>> * Are you using mem, infinispan or jpa user session provider?
>>>> * Clustered?
>>>> * How many concurrent requests/users are you testing with?
>>>>
>>>> Any more accurate performance stats would also be helpful
>>>>
>>>> ----- Original Message -----
>>>>> From: "Daniel Baxter" <daniel.baxter at cira.ca>
>>>>> To: keycloak-dev at lists.jboss.org
>>>>> Sent: Monday, 12 January, 2015 9:23:42 PM
>>>>> Subject: [keycloak-dev] Slow Direct Grants API endpoint
>>>>>
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>> I am attempting to integrate Keycloak into an existing application
>>>>> to replace the homegrown user management system in place. We have
>>>>> a new project built from the ground up on Keycloak 1.0.4.Final
>>>>> which is exhibiting good performance. However this app that I am
>>>>> porting has a remoting component that connects to the server with
>>>>> bare username/password credentials over the EJB Remoting
>>>>> framework. I was hoping to use 1.1.0 (currently Beta2) which
>>>>> provides a DirectAccessGrantsLoginModule which does exactly what I
>>>>> want (turns username and password into a KeycloakPrincipal).
>>>>> However, the turn around time from Keycloak is on the order of several
>>>>> seconds.
>>>>>
>>>>>
>>>>>
>>>>> I have used a bare REST client to execute the POSTs to both our
>>>>> 1.0.4 Keycloak and 1.1.0 Keycloak instances and have noted an
>>>>> order of magnitude difference in getting a response. Is this a
>>>>> known issue (I cannot find anything in the public bugs/tasks
>>>>> list)? Or is this due to the Beta status leaving additional
>>>>> performance affecting logging or instrumentation in place?
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>>
>>>>>
>>>>> Daniel
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Fri Feb  6 10:32:16 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 06 Feb 2015 10:32:16 -0500
Subject: [keycloak-dev] advanced claim support
Message-ID: <54D4DE80.1070107@redhat.com>

Wrote this awhile ago.  I'm starting on this now.  Discuss now, or 
forever hold your peace :)

Current UserModel.attributes will be used for internal bookkeeping only.
   Going to add a new "UserProfileType", "UserProfileValue" (name TBD)
type that contains:

UserProfileType:
* id
* name
* .css type
* type (bool, int, date, etc.)
* boolean displayOnRegistrationPage

Question, do I need a .css id to plug in a value too?  How would we
display the german label name for "phone"?


UserProfileValue:
* id
* UserClaimType
* String value


OIDC clients will have a "Claim mapping" tab.  SAML clients will have an
"Assertion Mapping" tab.  These tabs will be able to map from
UserProfileValues to te appropriate claim/assertion and also be able to
set up whether or not a claim should be added to token/assertion list.

ClientModel.claimMask will go away.  ClientModel will gain a list of
ClaimMappingModel

* id
* UserProfileType
* String claimNameMapping

Might want to eventually add a "ClaimTransformerProvider" pluggin
ability that can be attached to ClaimMappingModel...We might also want a
"TokenTransformerProvider" plugin too that can intercept token/saml doc
creation.  We'll see...

Bill
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From gerbermichi at me.com  Fri Feb  6 11:04:36 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Fri, 06 Feb 2015 17:04:36 +0100
Subject: [keycloak-dev] advanced claim support
In-Reply-To: <54D4DE80.1070107@redhat.com>
References: <54D4DE80.1070107@redhat.com>
Message-ID: <FAA206CB-0200-45AD-B868-4A3C73797297@me.com>



> Am 06.02.2015 um 16:32 schrieb Bill Burke <bburke at redhat.com>:
> 
> Wrote this awhile ago.  I'm starting on this now.  Discuss now, or 
> forever hold your peace :)
> 
> Current UserModel.attributes will be used for internal bookkeeping only.
>   Going to add a new "UserProfileType", "UserProfileValue" (name TBD)
> type that contains:
> 
> UserProfileType:
> * id
> * name
> * .css type
> * type (bool, int, date, etc.)
> * boolean displayOnRegistrationPage
> 
> Question, do I need a .css id to plug in a value too?  How would we
> display the german label name for ?phone??

The labels and messages are currently stored in a messages.properties file. 
The best way to internationalize it, would be to create multiple property files (messages_de.properties, messages_fr.properties).
So you should add a ?String label? field to the UserProfileType, to map a label in the properties file.

why do you need a .css type?

> 
> 
> UserProfileValue:
> * id
> * UserClaimType
> * String value
> 
> 
> OIDC clients will have a "Claim mapping" tab.  SAML clients will have an
> "Assertion Mapping" tab.  These tabs will be able to map from
> UserProfileValues to te appropriate claim/assertion and also be able to
> set up whether or not a claim should be added to token/assertion list.
> 
> ClientModel.claimMask will go away.  ClientModel will gain a list of
> ClaimMappingModel
> 
> * id
> * UserProfileType
> * String claimNameMapping
> 
> Might want to eventually add a "ClaimTransformerProvider" pluggin
> ability that can be attached to ClaimMappingModel...We might also want a
> "TokenTransformerProvider" plugin too that can intercept token/saml doc
> creation.  We'll see...
> 
> Bill
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



From nicholas at monstersoftwarellc.com  Fri Feb  6 11:36:12 2015
From: nicholas at monstersoftwarellc.com (Nicholas Padilla)
Date: Fri, 6 Feb 2015 09:36:12 -0700
Subject: [keycloak-dev] Migrate Users to new Realm
Message-ID: <CAKBbQsgWxS86dQ7=9PaXaB9VSGnKtiPNvST4Vb2OF2TkZRSpDA@mail.gmail.com>

Hello All,

I am wondering if there was a way to migrate all or a subset of users from
one Keycloak Realm to another.  At this point in the project we don't want
to complicate the Keycloak maintenance so had the thought that we would
roll out with a single realm and move into supporting many realms later.
Is this something that is doable?

Thanks!

Nicholas Padilla
www.monstersoftwarellc.com

?Problems cannot be solved by the same level of thinking that created them.?
?Learn from yesterday, live for today, hope for tomorrow. The important
thing is not to stop questioning.
<http://thinkexist.com/quotation/learn_from_yesterday-live_for_today-hope_for/222120.html>
?

Albert Einstein <http://thinkexist.com/quotes/albert_einstein/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150206/3f857b6d/attachment.html 

From jaekun.choi at gmail.com  Sat Feb  7 04:38:44 2015
From: jaekun.choi at gmail.com (Jae Choi)
Date: Sat, 7 Feb 2015 20:38:44 +1100
Subject: [keycloak-dev] How to use Nodejs application with Keycloak
Message-ID: <CAPLm6j+sCwuwTsT1Y9WApbLAcv1k1TD3+XYVeJCE9KL=bifsOQ@mail.gmail.com>

Hi all,

I would like to use Nodejs application with Keycloak for dealing with
AngularJS as a auth provider.

How do I do this? Does it mean I need to deploy Node.js application to
Wildfly?

If so, is there any documentation for this process?


Thanks,

-- 
Kind Regards,
Jae Choi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150207/bc09cefe/attachment.html 

From ssilvert at redhat.com  Sat Feb  7 16:23:13 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Sat, 07 Feb 2015 16:23:13 -0500
Subject: [keycloak-dev] Migrate Users to new Realm
In-Reply-To: <CAKBbQsgWxS86dQ7=9PaXaB9VSGnKtiPNvST4Vb2OF2TkZRSpDA@mail.gmail.com>
References: <CAKBbQsgWxS86dQ7=9PaXaB9VSGnKtiPNvST4Vb2OF2TkZRSpDA@mail.gmail.com>
Message-ID: <54D68241.4070702@redhat.com>

How about export to json, edit the file, then import.  That should work.

On 2/6/2015 11:36 AM, Nicholas Padilla wrote:
> Hello All,
>
> I am wondering if there was a way to migrate all or a subset of users 
> from one Keycloak Realm to another.  At this point in the project we 
> don't want to complicate the Keycloak maintenance so had the thought 
> that we would roll out with a single realm and move into supporting 
> many realms later.  Is this something that is doable?
>
> Thanks!
>
> Nicholas Padilla
> www.monstersoftwarellc.com <http://www.monstersoftwarellc.com>
>
>
>   "Problems cannot be solved by the same level of thinking that
>   created them."
>
> "Learn from yesterday, live for today, hope for tomorrow. The 
> important thing is not to stop questioning. 
> <http://thinkexist.com/quotation/learn_from_yesterday-live_for_today-hope_for/222120.html>" 
>
>
> Albert Einstein <http://thinkexist.com/quotes/albert_einstein/>
>
>
> _______________________________________________
> 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/20150207/efc3009c/attachment-0001.html 

From mposolda at redhat.com  Mon Feb  9 04:18:41 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 09 Feb 2015 10:18:41 +0100
Subject: [keycloak-dev] advanced claim support
In-Reply-To: <FAA206CB-0200-45AD-B868-4A3C73797297@me.com>
References: <54D4DE80.1070107@redhat.com>
	<FAA206CB-0200-45AD-B868-4A3C73797297@me.com>
Message-ID: <54D87B71.6050206@redhat.com>

On 6.2.2015 17:04, Michael Gerber wrote:
>
>> Am 06.02.2015 um 16:32 schrieb Bill Burke <bburke at redhat.com>:
>>
>> Wrote this awhile ago.  I'm starting on this now.  Discuss now, or
>> forever hold your peace :)
>>
>> Current UserModel.attributes will be used for internal bookkeeping only.
>>    Going to add a new "UserProfileType", "UserProfileValue" (name TBD)
>> type that contains:
>>
>> UserProfileType:
>> * id
>> * name
>> * .css type
>> * type (bool, int, date, etc.)
>> * boolean displayOnRegistrationPage
>>
>> Question, do I need a .css id to plug in a value too?  How would we
>> display the german label name for ?phone??
> The labels and messages are currently stored in a messages.properties file.
> The best way to internationalize it, would be to create multiple property files (messages_de.properties, messages_fr.properties).
> So you should add a ?String label? field to the UserProfileType, to map a label in the properties file.
IMO it will be good if people are able to localize their claims directly 
in admin console without need to edit some properties files.
So maybe UserProfileType can contain mapping of locales to the "name" in 
particular language. Something like:

Map<String, String> localeMappings;

on UserProfileType. This will allow people to configure labels for their 
claims directly in admin console. So they can specify that "phone" label 
should be available in "English" and "telefon" in "Czech" etc. Maybe we 
can later provide some pre-defined labels for well-known claims (like 
phone) in supported languages when we are going later to add 
localization support.

Marek
>
> why do you need a .css type?
>
>>
>> UserProfileValue:
>> * id
>> * UserClaimType
>> * String value
>>
>>
>> OIDC clients will have a "Claim mapping" tab.  SAML clients will have an
>> "Assertion Mapping" tab.  These tabs will be able to map from
>> UserProfileValues to te appropriate claim/assertion and also be able to
>> set up whether or not a claim should be added to token/assertion list.
>>
>> ClientModel.claimMask will go away.  ClientModel will gain a list of
>> ClaimMappingModel
>>
>> * id
>> * UserProfileType
>> * String claimNameMapping
>>
>> Might want to eventually add a "ClaimTransformerProvider" pluggin
>> ability that can be attached to ClaimMappingModel...We might also want a
>> "TokenTransformerProvider" plugin too that can intercept token/saml doc
>> creation.  We'll see...
>>
>> Bill
>> -- 
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From mposolda at redhat.com  Mon Feb  9 04:30:37 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 09 Feb 2015 10:30:37 +0100
Subject: [keycloak-dev] Migrate Users to new Realm
In-Reply-To: <54D68241.4070702@redhat.com>
References: <CAKBbQsgWxS86dQ7=9PaXaB9VSGnKtiPNvST4Vb2OF2TkZRSpDA@mail.gmail.com>
	<54D68241.4070702@redhat.com>
Message-ID: <54D87E3D.80709@redhat.com>

Yes. There is also possibility to directly edit DB and for specified 
users, edit the field REALM_ID and point to different realms. But both 
approaches could theoretically lead to some issues, especially if you 
are going to enable federation providers or social mappings.

For example:
- Realm "foo" has enable LDAP federation provider. User "john" is linked 
to LDAP federation provider with ID "123"
- Then you want to migrate "john" to realm "bar". But realm "bar" 
doesn't have LDAP provider enabled. Or it has it enabled but with 
different ID then "123" . The federation link on "john" would point to 
original federation provider with ID "123" from realm "foo", which leads 
to broken federation link.

In case you want to enable federation providers or social login, I would 
recomment to start with more realms from the beginning.

Marek

On 7.2.2015 22:23, Stan Silvert wrote:
> How about export to json, edit the file, then import.  That should work.
>
> On 2/6/2015 11:36 AM, Nicholas Padilla wrote:
>> Hello All,
>>
>> I am wondering if there was a way to migrate all or a subset of users 
>> from one Keycloak Realm to another.  At this point in the project we 
>> don't want to complicate the Keycloak maintenance so had the thought 
>> that we would roll out with a single realm and move into supporting 
>> many realms later.  Is this something that is doable?
>>
>> Thanks!
>>
>> Nicholas Padilla
>> www.monstersoftwarellc.com <http://www.monstersoftwarellc.com>
>>
>>
>>   ?Problems cannot be solved by the same level of thinking that
>>   created them.?
>>
>> ?Learn from yesterday, live for today, hope for tomorrow. The 
>> important thing is not to stop questioning. 
>> <http://thinkexist.com/quotation/learn_from_yesterday-live_for_today-hope_for/222120.html>? 
>>
>>
>> Albert Einstein <http://thinkexist.com/quotes/albert_einstein/>
>>
>>
>> _______________________________________________
>> 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/20150209/ff9c563d/attachment.html 

From mposolda at redhat.com  Mon Feb  9 05:35:49 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 09 Feb 2015 11:35:49 +0100
Subject: [keycloak-dev] Switch to enable token retrieval by apps from
 brokered Idps
In-Reply-To: <302451741.7618973.1423228544884.JavaMail.zimbra@redhat.com>
References: <302451741.7618973.1423228544884.JavaMail.zimbra@redhat.com>
Message-ID: <54D88D85.9090709@redhat.com>

Hi,

It makes sense to me to allow application to retrieve the external IDP 
token and configure this per application via custom claim. But I am not 
seeing much point to filter identity providers on login screen based on 
application?

IMO login screen should be same for whole realm. And if I enable 
Facebook login, it should be enabled for all apps in the realm. 
Restriction based on apps still won't work well as Keycloak is SSO 
system. Even if I don't allow Facebook login for application "foo", I 
can still login to Facebook in application "bar" and then I can be 
logged via SSO to application "foo". At least that's my point of view to 
it;-)

Marek

On 6.2.2015 14:15, Pedro Igor Silva wrote:
> Hi,
>
>      Does makes sense to enable an identity provider to an application and *not* allow the same application to retrieve tokens from the identity provider ?
>
> Regards.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From nicholas at monstersoftwarellc.com  Mon Feb  9 12:25:42 2015
From: nicholas at monstersoftwarellc.com (Nicholas Padilla)
Date: Mon, 9 Feb 2015 10:25:42 -0700
Subject: [keycloak-dev] Share Applications from Master Realm to Others
Message-ID: <CAKBbQsiU4iP_ea-4s0waWHTigcJR1SBDGqq+-m-L2VqoMxMsYw@mail.gmail.com>

Hello,

I was wondering if it was possible to share Applications from the Master
realm.  If we wanted to support multiple realms but those realms always
using a subset of the Applications defined in Master, we didn't want to
have to redefine them.  We would just like to allow a Child Realm to be
able to be given access to an Application in Master, at a particular role
level.   Please let me know if you have any questions.

Thanks!

Nicholas Padilla
www.monstersoftwarellc.com

?Problems cannot be solved by the same level of thinking that created them.?
?Learn from yesterday, live for today, hope for tomorrow. The important
thing is not to stop questioning.
<http://thinkexist.com/quotation/learn_from_yesterday-live_for_today-hope_for/222120.html>
?

Albert Einstein <http://thinkexist.com/quotes/albert_einstein/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150209/0f3e5b25/attachment.html 

From bburke at redhat.com  Mon Feb  9 13:12:40 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 09 Feb 2015 13:12:40 -0500
Subject: [keycloak-dev] advanced claim support
In-Reply-To: <54D87B71.6050206@redhat.com>
References: <54D4DE80.1070107@redhat.com>
	<FAA206CB-0200-45AD-B868-4A3C73797297@me.com>
	<54D87B71.6050206@redhat.com>
Message-ID: <54D8F898.4070805@redhat.com>



On 2/9/2015 4:18 AM, Marek Posolda wrote:
> On 6.2.2015 17:04, Michael Gerber wrote:
>>
>>> Am 06.02.2015 um 16:32 schrieb Bill Burke <bburke at redhat.com>:
>>>
>>> Wrote this awhile ago.  I'm starting on this now.  Discuss now, or
>>> forever hold your peace :)
>>>
>>> Current UserModel.attributes will be used for internal bookkeeping only.
>>>    Going to add a new "UserProfileType", "UserProfileValue" (name TBD)
>>> type that contains:
>>>
>>> UserProfileType:
>>> * id
>>> * name
>>> * .css type
>>> * type (bool, int, date, etc.)
>>> * boolean displayOnRegistrationPage
>>>
>>> Question, do I need a .css id to plug in a value too?  How would we
>>> display the german label name for ?phone??
>> The labels and messages are currently stored in a messages.properties
>> file.
>> The best way to internationalize it, would be to create multiple
>> property files (messages_de.properties, messages_fr.properties).
>> So you should add a ?String label? field to the UserProfileType, to
>> map a label in the properties file.
> IMO it will be good if people are able to localize their claims directly
> in admin console without need to edit some properties files.
> So maybe UserProfileType can contain mapping of locales to the "name" in
> particular language. Something like:
>
> Map<String, String> localeMappings;
>
> on UserProfileType. This will allow people to configure labels for their
> claims directly in admin console. So they can specify that "phone" label
> should be available in "English" and "telefon" in "Czech" etc. Maybe we
> can later provide some pre-defined labels for well-known claims (like
> phone) in supported languages when we are going later to add
> localization support.
>

Not sure I agree.  They will need to edit themes to provide 
localization.  Just providing support for claim localization, leaves out 
the entire screen they are painted on.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Mon Feb  9 17:51:04 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 09 Feb 2015 17:51:04 -0500
Subject: [keycloak-dev] Keycloak.js is inefficient and can be improved
Message-ID: <54D939D8.2050407@redhat.com>

I had a good discussion on OAuth list about javascript and implicit flow 
vs. auth-code flow.  It was pointed out that auth-code flow has some 
extra hops that can be avoided if you implement "response_mode=fragment".

See this:

https://issues.jboss.org/browse/KEYCLOAK-1033


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From psilva at redhat.com  Mon Feb  9 19:03:36 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 9 Feb 2015 19:03:36 -0500 (EST)
Subject: [keycloak-dev] Keycloak.js is inefficient and can be improved
In-Reply-To: <54D939D8.2050407@redhat.com>
References: <54D939D8.2050407@redhat.com>
Message-ID: <397023835.9370348.1423526616778.JavaMail.zimbra@redhat.com>

I think Instagram does that [1], right ?

[1] http://instagram.com/developer/authentication/

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: keycloak-dev at lists.jboss.org
Sent: Monday, February 9, 2015 8:51:04 PM
Subject: [keycloak-dev] Keycloak.js is inefficient and can be improved

I had a good discussion on OAuth list about javascript and implicit flow 
vs. auth-code flow.  It was pointed out that auth-code flow has some 
extra hops that can be avoided if you implement "response_mode=fragment".

See this:

https://issues.jboss.org/browse/KEYCLOAK-1033


-- 
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 Feb  9 19:10:25 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 09 Feb 2015 19:10:25 -0500
Subject: [keycloak-dev] Keycloak.js is inefficient and can be improved
In-Reply-To: <397023835.9370348.1423526616778.JavaMail.zimbra@redhat.com>
References: <54D939D8.2050407@redhat.com>
	<397023835.9370348.1423526616778.JavaMail.zimbra@redhat.com>
Message-ID: <54D94C71.7050203@redhat.com>

No, Instagram is describing implicit flow.  Implicit flow has a problem 
in that access tokens can possibly be bookmarked and stored in browser 
history.  That isn't a problem with codes because codes are only active 
for a very short window (milliseconds).

On 2/9/2015 7:03 PM, Pedro Igor Silva wrote:
> I think Instagram does that [1], right ?
>
> [1] http://instagram.com/developer/authentication/
>
> ----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, February 9, 2015 8:51:04 PM
> Subject: [keycloak-dev] Keycloak.js is inefficient and can be improved
>
> I had a good discussion on OAuth list about javascript and implicit flow
> vs. auth-code flow.  It was pointed out that auth-code flow has some
> extra hops that can be avoided if you implement "response_mode=fragment".
>
> See this:
>
> https://issues.jboss.org/browse/KEYCLOAK-1033
>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From psilva at redhat.com  Mon Feb  9 21:34:35 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 9 Feb 2015 21:34:35 -0500 (EST)
Subject: [keycloak-dev] Keycloak.js is inefficient and can be improved
In-Reply-To: <54D94C71.7050203@redhat.com>
References: <54D939D8.2050407@redhat.com>
	<397023835.9370348.1423526616778.JavaMail.zimbra@redhat.com>
	<54D94C71.7050203@redhat.com>
Message-ID: <245861469.9413380.1423535675528.JavaMail.zimbra@redhat.com>

It's a trade-off. Implicit removes some legs and should be avoided by server-side apps, so you don't have the code visible to the server when using fragments.

You are right about bookmarking, however it seems you can avoid that by specifying the response_mode to override the default behavior for a specific response_type. IMO, response_type query still have issues and that spec about form_post looks promising.

What they are trying to achieve with form_post is pretty much what SAML does with HTTP-POST binding. In SAML, the recommendation is to always use POST to send assertions back to SPs. And that is valid for several reasons.

I don't think response_mode itself will reduce round trips as you stated in KEYCLOAK-1033. But a combination of implicit flow + response_type (eg.: token id_token, etc) + response_mode (to avoid exposure). Problem with OAuth 2 is that people end using it to provide delegated-authentication where it is just about authorization. And here is where OIDC plays an important role.

For instance, KeyCloak uses an authorization code grant to authenticate users from public clients. And when not a public client you still use authorization code grant without provide any credential. AFAIK, authorization code grant defines that client *must* authenticate when using this grant type.

IMO, for SSO, we can just use implicit to log in users with the appropriate response_type (eg.: token id_token or even make this configurable) and use an appropriate response_mode like query or form_post. That would remove legs without security penalties.

Regards.
Pedro Igor

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: "Pedro Igor Silva" <psilva at redhat.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Monday, February 9, 2015 10:10:25 PM
Subject: Re: [keycloak-dev] Keycloak.js is inefficient and can be improved

No, Instagram is describing implicit flow.  Implicit flow has a problem 
in that access tokens can possibly be bookmarked and stored in browser 
history.  That isn't a problem with codes because codes are only active 
for a very short window (milliseconds).

On 2/9/2015 7:03 PM, Pedro Igor Silva wrote:
> I think Instagram does that [1], right ?
>
> [1] http://instagram.com/developer/authentication/
>
> ----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, February 9, 2015 8:51:04 PM
> Subject: [keycloak-dev] Keycloak.js is inefficient and can be improved
>
> I had a good discussion on OAuth list about javascript and implicit flow
> vs. auth-code flow.  It was pointed out that auth-code flow has some
> extra hops that can be avoided if you implement "response_mode=fragment".
>
> See this:
>
> https://issues.jboss.org/browse/KEYCLOAK-1033
>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From mposolda at redhat.com  Tue Feb 10 09:27:37 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 10 Feb 2015 15:27:37 +0100
Subject: [keycloak-dev] advanced claim support
In-Reply-To: <54D8F898.4070805@redhat.com>
References: <54D4DE80.1070107@redhat.com>
	<FAA206CB-0200-45AD-B868-4A3C73797297@me.com>
	<54D87B71.6050206@redhat.com> <54D8F898.4070805@redhat.com>
Message-ID: <54DA1559.9050506@redhat.com>

On 9.2.2015 19:12, Bill Burke wrote:
>
>
> On 2/9/2015 4:18 AM, Marek Posolda wrote:
>> On 6.2.2015 17:04, Michael Gerber wrote:
>>>
>>>> Am 06.02.2015 um 16:32 schrieb Bill Burke <bburke at redhat.com>:
>>>>
>>>> Wrote this awhile ago.  I'm starting on this now.  Discuss now, or
>>>> forever hold your peace :)
>>>>
>>>> Current UserModel.attributes will be used for internal bookkeeping 
>>>> only.
>>>>    Going to add a new "UserProfileType", "UserProfileValue" (name TBD)
>>>> type that contains:
>>>>
>>>> UserProfileType:
>>>> * id
>>>> * name
>>>> * .css type
>>>> * type (bool, int, date, etc.)
>>>> * boolean displayOnRegistrationPage
>>>>
>>>> Question, do I need a .css id to plug in a value too?  How would we
>>>> display the german label name for ?phone??
>>> The labels and messages are currently stored in a messages.properties
>>> file.
>>> The best way to internationalize it, would be to create multiple
>>> property files (messages_de.properties, messages_fr.properties).
>>> So you should add a ?String label? field to the UserProfileType, to
>>> map a label in the properties file.
>> IMO it will be good if people are able to localize their claims directly
>> in admin console without need to edit some properties files.
>> So maybe UserProfileType can contain mapping of locales to the "name" in
>> particular language. Something like:
>>
>> Map<String, String> localeMappings;
>>
>> on UserProfileType. This will allow people to configure labels for their
>> claims directly in admin console. So they can specify that "phone" label
>> should be available in "English" and "telefon" in "Czech" etc. Maybe we
>> can later provide some pre-defined labels for well-known claims (like
>> phone) in supported languages when we are going later to add
>> localization support.
>>
>
> Not sure I agree.  They will need to edit themes to provide 
> localization.  Just providing support for claim localization, leaves 
> out the entire screen they are painted on.
>
>
I was suspect that we will provide localization for our screens? And 
hopefully contributors from community will help us too with translations 
:-)

Assuming that Keycloak screens will have localization support for some 
languages, people would need just to provide localization for their 
custom claims. Maybe we can have some "predefined" translations for well 
known claims (phone, firstName, lastName, email, street etc). However 
for custom domain-specific claims, people can translate them manually 
and to me it looks more friendly if they can do it in admin console.

IMO ideal state is that people can localize claims without need to 
update any property files... That would be better OOTB experience.

Marek

From bburke at redhat.com  Tue Feb 10 10:19:03 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 10 Feb 2015 10:19:03 -0500
Subject: [keycloak-dev] Keycloak.js is inefficient and can be improved
In-Reply-To: <245861469.9413380.1423535675528.JavaMail.zimbra@redhat.com>
References: <54D939D8.2050407@redhat.com>
	<397023835.9370348.1423526616778.JavaMail.zimbra@redhat.com>
	<54D94C71.7050203@redhat.com>
	<245861469.9413380.1423535675528.JavaMail.zimbra@redhat.com>
Message-ID: <54DA2167.80704@redhat.com>

* implicit flow requires the token to be sent in the URL via a fragment, 
there's no way around it.  This URL is stored in browser history and can 
be bookmarked.

* passing fragment I believe reduces round trips because page caches 
ignore fragments when indexing pages.  On the other hand, a URL with a 
code query param is always unique, thus can't be cached.  So if you can 
send the code via a fragment parameter, then, you can use the browser cache.

* Auth code grant does not require credentials.  This is called a public 
client.

* Explain how form_post solves anything or removes any legs?  The HTML 
page returned by the server still has to be posted to the application's 
server, no?

Finally, somebody posted a way to do pseudo-confidential public clients:

https://tools.ietf.org/html/draft-ietf-oauth-spop-02

So, we should probably combine response_mode=fragment with the 
code_challenge in our Javascript adapter.

On 2/9/2015 9:34 PM, Pedro Igor Silva wrote:
> It's a trade-off. Implicit removes some legs and should be avoided by server-side apps, so you don't have the code visible to the server when using fragments.
>
> You are right about bookmarking, however it seems you can avoid that by specifying the response_mode to override the default behavior for a specific response_type. IMO, response_type query still have issues and that spec about form_post looks promising.
>
> What they are trying to achieve with form_post is pretty much what SAML does with HTTP-POST binding. In SAML, the recommendation is to always use POST to send assertions back to SPs. And that is valid for several reasons.
>
> I don't think response_mode itself will reduce round trips as you stated in KEYCLOAK-1033. But a combination of implicit flow + response_type (eg.: token id_token, etc) + response_mode (to avoid exposure). Problem with OAuth 2 is that people end using it to provide delegated-authentication where it is just about authorization. And here is where OIDC plays an important role.
>
> For instance, KeyCloak uses an authorization code grant to authenticate users from public clients. And when not a public client you still use authorization code grant without provide any credential. AFAIK, authorization code grant defines that client *must* authenticate when using this grant type.
>
> IMO, for SSO, we can just use implicit to log in users with the appropriate response_type (eg.: token id_token or even make this configurable) and use an appropriate response_mode like query or form_post. That would remove legs without security penalties.
>
> Regards.
> Pedro Igor
>
> ----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, February 9, 2015 10:10:25 PM
> Subject: Re: [keycloak-dev] Keycloak.js is inefficient and can be improved
>
> No, Instagram is describing implicit flow.  Implicit flow has a problem
> in that access tokens can possibly be bookmarked and stored in browser
> history.  That isn't a problem with codes because codes are only active
> for a very short window (milliseconds).
>
> On 2/9/2015 7:03 PM, Pedro Igor Silva wrote:
>> I think Instagram does that [1], right ?
>>
>> [1] http://instagram.com/developer/authentication/
>>
>> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Monday, February 9, 2015 8:51:04 PM
>> Subject: [keycloak-dev] Keycloak.js is inefficient and can be improved
>>
>> I had a good discussion on OAuth list about javascript and implicit flow
>> vs. auth-code flow.  It was pointed out that auth-code flow has some
>> extra hops that can be avoided if you implement "response_mode=fragment".
>>
>> See this:
>>
>> https://issues.jboss.org/browse/KEYCLOAK-1033
>>
>>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From psilva at redhat.com  Tue Feb 10 11:25:10 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Tue, 10 Feb 2015 11:25:10 -0500 (EST)
Subject: [keycloak-dev] Keycloak.js is inefficient and can be improved
In-Reply-To: <54DA2167.80704@redhat.com>
References: <54D939D8.2050407@redhat.com>
	<397023835.9370348.1423526616778.JavaMail.zimbra@redhat.com>
	<54D94C71.7050203@redhat.com>
	<245861469.9413380.1423535675528.JavaMail.zimbra@redhat.com>
	<54DA2167.80704@redhat.com>
Message-ID: <851204659.9799738.1423585510941.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, February 10, 2015 1:19:03 PM
> Subject: Re: [keycloak-dev] Keycloak.js is inefficient and can be improved
> 
> * implicit flow requires the token to be sent in the URL via a fragment,
> there's no way around it.  This URL is stored in browser history and can
> be bookmarked.

What about this [1], Section '3.2.2.5.  Successful Authentication Response'. There is a statement saying "When using the Implicit Flow, all response parameters are added to the fragment component of the Redirection URI, as specified in OAuth 2.0 Multiple Response Type Encoding Practices [OAuth.Responses], unless a different Response Mode was specified."

I think a more important issue to worry about when doing oAuth2 implicit flow is how to validate the audience for a specific access token.

[1] http://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth

> 
> * passing fragment I believe reduces round trips because page caches
> ignore fragments when indexing pages.  On the other hand, a URL with a
> code query param is always unique, thus can't be cached.  So if you can
> send the code via a fragment parameter, then, you can use the browser cache.
> 
> * Auth code grant does not require credentials.  This is called a public
> client.

Yeah, sorry. That is only a requirement for confidential clients.

> 
> * Explain how form_post solves anything or removes any legs?  The HTML
> page returned by the server still has to be posted to the application's
> server, no?

I did not mean form_post would solve legs. But a combination of implicit + response_type + response_mode.

My point is that today KeyCloak always performs authorization code even when you are in a web application, which is a confidential client. Ok, you may have credentials in this case and use authz code to perform the authentication and obtain both access_token and id_token.

However, why not just use an implicit flow where you just need to pass the client_id and right after receive a response with the tokens. In this case, you eliminate the code-to-token flow. That is what I meant.

Actually, you are pretty much doing this if you set an application as public in KeyCloak, right ? The difference here is that you still need to do the code-to-token dance.

IMO, this can be used for pure SSO-based use cases where the app is relying on the KeyCloak Adapters. Eg.: web applications/confidential clients.

Form_post would be just a better way to return tokens back to SPs instead of passing them via query parameters.

> 
> Finally, somebody posted a way to do pseudo-confidential public clients:
> 
> https://tools.ietf.org/html/draft-ietf-oauth-spop-02

Nice, we probably need to consider something like that in KeyCloak when handling public clients.

And also funny, because oAuth 1 is all based on these "verifiers" :). Plus signatures all over the places.

> 
> So, we should probably combine response_mode=fragment with the
> code_challenge in our Javascript adapter.
> 
> On 2/9/2015 9:34 PM, Pedro Igor Silva wrote:
> > It's a trade-off. Implicit removes some legs and should be avoided by
> > server-side apps, so you don't have the code visible to the server when
> > using fragments.
> >
> > You are right about bookmarking, however it seems you can avoid that by
> > specifying the response_mode to override the default behavior for a
> > specific response_type. IMO, response_type query still have issues and
> > that spec about form_post looks promising.
> >
> > What they are trying to achieve with form_post is pretty much what SAML
> > does with HTTP-POST binding. In SAML, the recommendation is to always use
> > POST to send assertions back to SPs. And that is valid for several
> > reasons.
> >
> > I don't think response_mode itself will reduce round trips as you stated in
> > KEYCLOAK-1033. But a combination of implicit flow + response_type (eg.:
> > token id_token, etc) + response_mode (to avoid exposure). Problem with
> > OAuth 2 is that people end using it to provide delegated-authentication
> > where it is just about authorization. And here is where OIDC plays an
> > important role.
> >
> > For instance, KeyCloak uses an authorization code grant to authenticate
> > users from public clients. And when not a public client you still use
> > authorization code grant without provide any credential. AFAIK,
> > authorization code grant defines that client *must* authenticate when
> > using this grant type.
> >
> > IMO, for SSO, we can just use implicit to log in users with the appropriate
> > response_type (eg.: token id_token or even make this configurable) and use
> > an appropriate response_mode like query or form_post. That would remove
> > legs without security penalties.
> >
> > Regards.
> > Pedro Igor
> >
> > ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Monday, February 9, 2015 10:10:25 PM
> > Subject: Re: [keycloak-dev] Keycloak.js is inefficient and can be improved
> >
> > No, Instagram is describing implicit flow.  Implicit flow has a problem
> > in that access tokens can possibly be bookmarked and stored in browser
> > history.  That isn't a problem with codes because codes are only active
> > for a very short window (milliseconds).
> >
> > On 2/9/2015 7:03 PM, Pedro Igor Silva wrote:
> >> I think Instagram does that [1], right ?
> >>
> >> [1] http://instagram.com/developer/authentication/
> >>
> >> ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Monday, February 9, 2015 8:51:04 PM
> >> Subject: [keycloak-dev] Keycloak.js is inefficient and can be improved
> >>
> >> I had a good discussion on OAuth list about javascript and implicit flow
> >> vs. auth-code flow.  It was pointed out that auth-code flow has some
> >> extra hops that can be avoided if you implement "response_mode=fragment".
> >>
> >> See this:
> >>
> >> https://issues.jboss.org/browse/KEYCLOAK-1033
> >>
> >>
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From gerbermichi at me.com  Tue Feb 10 12:34:24 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Tue, 10 Feb 2015 18:34:24 +0100
Subject: [keycloak-dev] advanced claim support
In-Reply-To: <54DA1559.9050506@redhat.com>
References: <54D4DE80.1070107@redhat.com>
	<FAA206CB-0200-45AD-B868-4A3C73797297@me.com>
	<54D87B71.6050206@redhat.com>
	<54D8F898.4070805@redhat.com> <54DA1559.9050506@redhat.com>
Message-ID: <8BB21134-210E-4053-A7B8-8A4D4A74B57B@me.com>


> Am 10.02.2015 um 15:27 schrieb Marek Posolda <mposolda at redhat.com>:
> 
> On 9.2.2015 19:12, Bill Burke wrote:
>> 
>> 
>> On 2/9/2015 4:18 AM, Marek Posolda wrote:
>>> On 6.2.2015 17:04, Michael Gerber wrote:
>>>> 
>>>>> Am 06.02.2015 um 16:32 schrieb Bill Burke <bburke at redhat.com>:
>>>>> 
>>>>> Wrote this awhile ago.  I'm starting on this now.  Discuss now, or
>>>>> forever hold your peace :)
>>>>> 
>>>>> Current UserModel.attributes will be used for internal bookkeeping only.
>>>>>   Going to add a new "UserProfileType", "UserProfileValue" (name TBD)
>>>>> type that contains:
>>>>> 
>>>>> UserProfileType:
>>>>> * id
>>>>> * name
>>>>> * .css type
>>>>> * type (bool, int, date, etc.)
>>>>> * boolean displayOnRegistrationPage
>>>>> 
>>>>> Question, do I need a .css id to plug in a value too?  How would we
>>>>> display the german label name for ?phone??
>>>> The labels and messages are currently stored in a messages.properties
>>>> file.
>>>> The best way to internationalize it, would be to create multiple
>>>> property files (messages_de.properties, messages_fr.properties).
>>>> So you should add a ?String label? field to the UserProfileType, to
>>>> map a label in the properties file.
>>> IMO it will be good if people are able to localize their claims directly
>>> in admin console without need to edit some properties files.
>>> So maybe UserProfileType can contain mapping of locales to the "name" in
>>> particular language. Something like:
>>> 
>>> Map<String, String> localeMappings;
>>> 
>>> on UserProfileType. This will allow people to configure labels for their
>>> claims directly in admin console. So they can specify that "phone" label
>>> should be available in "English" and "telefon" in "Czech" etc. Maybe we
>>> can later provide some pre-defined labels for well-known claims (like
>>> phone) in supported languages when we are going later to add
>>> localization support.
>>> 
>> 
>> Not sure I agree.  They will need to edit themes to provide localization.  Just providing support for claim localization, leaves out the entire screen they are painted on.
>> 
>> 
> I was suspect that we will provide localization for our screens? And hopefully contributors from community will help us too with translations :-)
> 
> Assuming that Keycloak screens will have localization support for some languages, people would need just to provide localization for their custom claims. Maybe we can have some "predefined" translations for well known claims (phone, firstName, lastName, email, street etc). However for custom domain-specific claims, people can translate them manually and to me it looks more friendly if they can do it in admin console.
> 
> IMO ideal state is that people can localize claims without need to update any property files... That would be better OOTB experience.
> 
> Marek

I agree with Marek. It would be much better if an admin can internationalize it in the admin console. 

Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150210/9c482811/attachment-0001.html 

From bburke at redhat.com  Tue Feb 10 17:55:05 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 10 Feb 2015 17:55:05 -0500
Subject: [keycloak-dev] Keycloak.js is inefficient and can be improved
In-Reply-To: <851204659.9799738.1423585510941.JavaMail.zimbra@redhat.com>
References: <54D939D8.2050407@redhat.com>
	<397023835.9370348.1423526616778.JavaMail.zimbra@redhat.com>
	<54D94C71.7050203@redhat.com>
	<245861469.9413380.1423535675528.JavaMail.zimbra@redhat.com>
	<54DA2167.80704@redhat.com>
	<851204659.9799738.1423585510941.JavaMail.zimbra@redhat.com>
Message-ID: <54DA8C49.3000809@redhat.com>



On 2/10/2015 11:25 AM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Pedro Igor Silva" <psilva at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, February 10, 2015 1:19:03 PM
>> Subject: Re: [keycloak-dev] Keycloak.js is inefficient and can be improved
>>
>> * implicit flow requires the token to be sent in the URL via a fragment,
>> there's no way around it.  This URL is stored in browser history and can
>> be bookmarked.
>
> What about this [1], Section '3.2.2.5.  Successful Authentication Response'. There is a statement saying "When using the Implicit Flow, all response parameters are added to the fragment component of the Redirection URI, as specified in OAuth 2.0 Multiple Response Type Encoding Practices [OAuth.Responses], unless a different Response Mode was specified."
>

Not sure what you are getting at.  Token is stored as a parameter in the 
fragment.  So the token is available in the URL (can be bookmarked) and 
is stored in browser history.  In auth-code-flow, only the code is 
stored in the URL.  Token is obtained by a background, out-of-band 
invocation.  Code can be bookmarked or stored in browser history, but it 
doesn't matter because the code is only usable once.

> I think a more important issue to worry about when doing oAuth2 implicit flow is how to validate the audience for a specific access token.
>
> [1] http://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth
>

Not sure what you mean by validating the "audience".  You mean how can 
the IDP validate the client?  It is sort of validated as codes (for 
auth-code flow) and tokens (for implicit flow) can only be forwarded to 
registered client URL patterns.  SSL sort of handles the verification of 
the audience.

>>
>> * passing fragment I believe reduces round trips because page caches
>> ignore fragments when indexing pages.  On the other hand, a URL with a
>> code query param is always unique, thus can't be cached.  So if you can
>> send the code via a fragment parameter, then, you can use the browser cache.
>>
>> * Auth code grant does not require credentials.  This is called a public
>> client.
>
> Yeah, sorry. That is only a requirement for confidential clients.
>
>>
>> * Explain how form_post solves anything or removes any legs?  The HTML
>> page returned by the server still has to be posted to the application's
>> server, no?
>
> I did not mean form_post would solve legs. But a combination of implicit + response_type + response_mode.
>
> My point is that today KeyCloak always performs authorization code even when you are in a web application, which is a confidential client. Ok, you may have credentials in this case and use authz code to perform the authentication and obtain both access_token and id_token.
>
> However, why not just use an implicit flow where you just need to pass the client_id and right after receive a response with the tokens. In this case, you eliminate the code-to-token flow. That is what I meant.
>
> Actually, you are pretty much doing this if you set an application as public in KeyCloak, right ? The difference here is that you still need to do the code-to-token dance.
>
> IMO, this can be used for pure SSO-based use cases where the app is relying on the KeyCloak Adapters. Eg.: web applications/confidential clients.
>
> Form_post would be just a better way to return tokens back to SPs instead of passing them via query parameters.
>

Only implicit flow passes tokens via URL parameters.  Which is one 
reason why we don't support implicit flow.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From mposolda at redhat.com  Wed Feb 11 14:29:54 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 11 Feb 2015 20:29:54 +0100
Subject: [keycloak-dev] Kerberos progress
Message-ID: <54DBADB2.40300@redhat.com>

I've already pushed initial version of Kerberos broker. It uses existing 
brokering mechanism from Pedro and allows to login users to KC with 
SPNEGO/Kerberos token. There are still things I need to address (more 
testing + automated testing, Credentials delegation etc).

I have a question about automatic Kerberos login without displaying 
login form. Browsers support this very well - when server returns 
response with status 401, header "WWW-Authenticate: Negotiate" and HTML 
with login page, browsers are able to handle it and:

* In case that user has Kerberos ticket, browser will send it back in 
additional HTTP request with "Authorization: Negotiate <ticket>" . In 
this case login form is not displayed to user

* In case that user hasn't Kerberos ticket, browser just displays HTML 
with login form

You can try https://saml.redhat.com/idp/ to see what I mean.

JBoss Negotiation supports this, so I believe we should address it too.


I have some ideas how to do it:

1) Configure default broker on server side per-realm. If used, login 
request will automatically redirect to configured broker. It may be also 
possible to override default broker per client?

2) Add on/off switch to broker configuration to specify if it should be 
default or not

3) Leverage existing "k_idp_hint" parameter. I am thinking about adding 
option "idp_hint" into AdapterConfig . In case it's configured, adapter 
will use it for attach "k_idp_hint" parameter to login request. This 
will allow per-application configuration and no changes on auth-server 
side, but all applications will need to use it in their adapter 
configuration.

4) Don't configure anything, but hard-code that Kerberos will be always 
used by default if configured. Basically add new method "boolean 
isDefault()" to IDentityProvider interface. It will return "true" for 
Kerberos impl and "false" for other broker types we currently have.

I like (1) or (2) most. Thoughts?

Marek


From bburke at redhat.com  Wed Feb 11 15:38:42 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 11 Feb 2015 15:38:42 -0500
Subject: [keycloak-dev] Kerberos progress
In-Reply-To: <54DBADB2.40300@redhat.com>
References: <54DBADB2.40300@redhat.com>
Message-ID: <54DBBDD2.3050509@redhat.com>

I am not understanding how you have implemented this.  Wouldn't kerberos 
just be an authentication mechanism that the auth server uses?  I don't 
understand why you would want special configuration at the adapter 
level.  This should all be configured at the auth server so that the 
application doesn't have to know if kerberos is used or not.

Wouldn't it be:

1. App does regular SAML or OIDC redirect to auth server
2. Auth server checks to see if realm supports kerberos
3. Sends 401 + HTML
4. Browser sends back ticket
5. Auth server verifies ticket, creates SAML or OIDC response and 
redirects browser back to application



On 2/11/2015 2:29 PM, Marek Posolda wrote:
> I've already pushed initial version of Kerberos broker. It uses existing
> brokering mechanism from Pedro and allows to login users to KC with
> SPNEGO/Kerberos token. There are still things I need to address (more
> testing + automated testing, Credentials delegation etc).
>
> I have a question about automatic Kerberos login without displaying
> login form. Browsers support this very well - when server returns
> response with status 401, header "WWW-Authenticate: Negotiate" and HTML
> with login page, browsers are able to handle it and:
>
> * In case that user has Kerberos ticket, browser will send it back in
> additional HTTP request with "Authorization: Negotiate <ticket>" . In
> this case login form is not displayed to user
>
> * In case that user hasn't Kerberos ticket, browser just displays HTML
> with login form
>
> You can try https://saml.redhat.com/idp/ to see what I mean.
>
> JBoss Negotiation supports this, so I believe we should address it too.
>
>
> I have some ideas how to do it:
>
> 1) Configure default broker on server side per-realm. If used, login
> request will automatically redirect to configured broker. It may be also
> possible to override default broker per client?
>
> 2) Add on/off switch to broker configuration to specify if it should be
> default or not
>
> 3) Leverage existing "k_idp_hint" parameter. I am thinking about adding
> option "idp_hint" into AdapterConfig . In case it's configured, adapter
> will use it for attach "k_idp_hint" parameter to login request. This
> will allow per-application configuration and no changes on auth-server
> side, but all applications will need to use it in their adapter
> configuration.
>
> 4) Don't configure anything, but hard-code that Kerberos will be always
> used by default if configured. Basically add new method "boolean
> isDefault()" to IDentityProvider interface. It will return "true" for
> Kerberos impl and "false" for other broker types we currently have.
>
> I like (1) or (2) most. Thoughts?
>
> Marek
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Wed Feb 11 15:44:20 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 11 Feb 2015 15:44:20 -0500
Subject: [keycloak-dev] Kerberos progress
In-Reply-To: <54DBBDD2.3050509@redhat.com>
References: <54DBADB2.40300@redhat.com> <54DBBDD2.3050509@redhat.com>
Message-ID: <54DBBF24.1030202@redhat.com>

I guess I don't understand why you would need Pedro's brokering 
mechanism to implement kerberos support.

On 2/11/2015 3:38 PM, Bill Burke wrote:
> I am not understanding how you have implemented this.  Wouldn't kerberos
> just be an authentication mechanism that the auth server uses?  I don't
> understand why you would want special configuration at the adapter
> level.  This should all be configured at the auth server so that the
> application doesn't have to know if kerberos is used or not.
>
> Wouldn't it be:
>
> 1. App does regular SAML or OIDC redirect to auth server
> 2. Auth server checks to see if realm supports kerberos
> 3. Sends 401 + HTML
> 4. Browser sends back ticket
> 5. Auth server verifies ticket, creates SAML or OIDC response and
> redirects browser back to application
>
>
>
> On 2/11/2015 2:29 PM, Marek Posolda wrote:
>> I've already pushed initial version of Kerberos broker. It uses existing
>> brokering mechanism from Pedro and allows to login users to KC with
>> SPNEGO/Kerberos token. There are still things I need to address (more
>> testing + automated testing, Credentials delegation etc).
>>
>> I have a question about automatic Kerberos login without displaying
>> login form. Browsers support this very well - when server returns
>> response with status 401, header "WWW-Authenticate: Negotiate" and HTML
>> with login page, browsers are able to handle it and:
>>
>> * In case that user has Kerberos ticket, browser will send it back in
>> additional HTTP request with "Authorization: Negotiate <ticket>" . In
>> this case login form is not displayed to user
>>
>> * In case that user hasn't Kerberos ticket, browser just displays HTML
>> with login form
>>
>> You can try https://saml.redhat.com/idp/ to see what I mean.
>>
>> JBoss Negotiation supports this, so I believe we should address it too.
>>
>>
>> I have some ideas how to do it:
>>
>> 1) Configure default broker on server side per-realm. If used, login
>> request will automatically redirect to configured broker. It may be also
>> possible to override default broker per client?
>>
>> 2) Add on/off switch to broker configuration to specify if it should be
>> default or not
>>
>> 3) Leverage existing "k_idp_hint" parameter. I am thinking about adding
>> option "idp_hint" into AdapterConfig . In case it's configured, adapter
>> will use it for attach "k_idp_hint" parameter to login request. This
>> will allow per-application configuration and no changes on auth-server
>> side, but all applications will need to use it in their adapter
>> configuration.
>>
>> 4) Don't configure anything, but hard-code that Kerberos will be always
>> used by default if configured. Basically add new method "boolean
>> isDefault()" to IDentityProvider interface. It will return "true" for
>> Kerberos impl and "false" for other broker types we currently have.
>>
>> I like (1) or (2) most. Thoughts?
>>
>> Marek
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From psilva at redhat.com  Wed Feb 11 15:45:56 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 11 Feb 2015 15:45:56 -0500 (EST)
Subject: [keycloak-dev] Kerberos progress
In-Reply-To: <54DBADB2.40300@redhat.com>
References: <54DBADB2.40300@redhat.com>
Message-ID: <830311330.10892784.1423687556576.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, February 11, 2015 5:29:54 PM
> Subject: [keycloak-dev] Kerberos progress
> 
> I've already pushed initial version of Kerberos broker. It uses existing
> brokering mechanism from Pedro and allows to login users to KC with
> SPNEGO/Kerberos token. There are still things I need to address (more
> testing + automated testing, Credentials delegation etc).
> 
> I have a question about automatic Kerberos login without displaying
> login form. Browsers support this very well - when server returns
> response with status 401, header "WWW-Authenticate: Negotiate" and HTML
> with login page, browsers are able to handle it and:
> 
> * In case that user has Kerberos ticket, browser will send it back in
> additional HTTP request with "Authorization: Negotiate <ticket>" . In
> this case login form is not displayed to user
> 
> * In case that user hasn't Kerberos ticket, browser just displays HTML
> with login form
> 
> You can try https://saml.redhat.com/idp/ to see what I mean.
> 
> JBoss Negotiation supports this, so I believe we should address it too.
> 
> 
> I have some ideas how to do it:
> 
> 1) Configure default broker on server side per-realm. If used, login
> request will automatically redirect to configured broker. It may be also
> possible to override default broker per client?
> 
> 2) Add on/off switch to broker configuration to specify if it should be
> default or not
> 
> 3) Leverage existing "k_idp_hint" parameter. I am thinking about adding
> option "idp_hint" into AdapterConfig . In case it's configured, adapter
> will use it for attach "k_idp_hint" parameter to login request. This
> will allow per-application configuration and no changes on auth-server
> side, but all applications will need to use it in their adapter
> configuration.

IMO, all above are valid. #1 and #2 may be useful even if not using Kerberos. And yes, IMO this should be per-client as well. I've added a new tab in Application and OAuth Client to enable/disable providers on a client. Maybe you can put this config there.

I think #3 is also valid if apps want to bypass login form for their users and go straight to an identity provider. 

FYI, currently implementation redirects the user automatically to an identity provider if there is a single one and no credentials are configured for a realm.

> 
> 4) Don't configure anything, but hard-code that Kerberos will be always
> used by default if configured. Basically add new method "boolean
> isDefault()" to IDentityProvider interface. It will return "true" for
> Kerberos impl and "false" for other broker types we currently have.
> 
> I like (1) or (2) most. Thoughts?
> 
> Marek
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From psilva at redhat.com  Wed Feb 11 15:55:57 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 11 Feb 2015 15:55:57 -0500 (EST)
Subject: [keycloak-dev] Keycloak.js is inefficient and can be improved
In-Reply-To: <54DA8C49.3000809@redhat.com>
References: <54D939D8.2050407@redhat.com>
	<397023835.9370348.1423526616778.JavaMail.zimbra@redhat.com>
	<54D94C71.7050203@redhat.com>
	<245861469.9413380.1423535675528.JavaMail.zimbra@redhat.com>
	<54DA2167.80704@redhat.com>
	<851204659.9799738.1423585510941.JavaMail.zimbra@redhat.com>
	<54DA8C49.3000809@redhat.com>
Message-ID: <184127607.10897669.1423688157615.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, February 10, 2015 8:55:05 PM
> Subject: Re: [keycloak-dev] Keycloak.js is inefficient and can be improved
> 
> 
> 
> On 2/10/2015 11:25 AM, Pedro Igor Silva wrote:
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Pedro Igor Silva" <psilva at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, February 10, 2015 1:19:03 PM
> >> Subject: Re: [keycloak-dev] Keycloak.js is inefficient and can be improved
> >>
> >> * implicit flow requires the token to be sent in the URL via a fragment,
> >> there's no way around it.  This URL is stored in browser history and can
> >> be bookmarked.
> >
> > What about this [1], Section '3.2.2.5.  Successful Authentication
> > Response'. There is a statement saying "When using the Implicit Flow, all
> > response parameters are added to the fragment component of the Redirection
> > URI, as specified in OAuth 2.0 Multiple Response Type Encoding Practices
> > [OAuth.Responses], unless a different Response Mode was specified."
> >
> 
> Not sure what you are getting at.  Token is stored as a parameter in the
> fragment.  So the token is available in the URL (can be bookmarked) and
> is stored in browser history.  In auth-code-flow, only the code is
> stored in the URL.  Token is obtained by a background, out-of-band
> invocation.  Code can be bookmarked or stored in browser history, but it
> doesn't matter because the code is only usable once.

What I'm saying is that you can set a response_mode when doing implicit with OIDC in order to avoid token in fragment. That is it.

> 
> > I think a more important issue to worry about when doing oAuth2 implicit
> > flow is how to validate the audience for a specific access token.
> >
> > [1] http://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth
> >
> 
> Not sure what you mean by validating the "audience".  You mean how can
> the IDP validate the client?  It is sort of validated as codes (for
> auth-code flow) and tokens (for implicit flow) can only be forwarded to
> registered client URL patterns.  SSL sort of handles the verification of
> the audience.

There are some known attacks where the attacker uses a token to log into an application by modifying the URI fragment to insert a stolen token into the response. This may happen when supporting social login and using implicit. Here the application should validate the audience because it is supposed to allow access only from a specific audience.

> 
> >>
> >> * passing fragment I believe reduces round trips because page caches
> >> ignore fragments when indexing pages.  On the other hand, a URL with a
> >> code query param is always unique, thus can't be cached.  So if you can
> >> send the code via a fragment parameter, then, you can use the browser
> >> cache.
> >>
> >> * Auth code grant does not require credentials.  This is called a public
> >> client.
> >
> > Yeah, sorry. That is only a requirement for confidential clients.
> >
> >>
> >> * Explain how form_post solves anything or removes any legs?  The HTML
> >> page returned by the server still has to be posted to the application's
> >> server, no?
> >
> > I did not mean form_post would solve legs. But a combination of implicit +
> > response_type + response_mode.
> >
> > My point is that today KeyCloak always performs authorization code even
> > when you are in a web application, which is a confidential client. Ok, you
> > may have credentials in this case and use authz code to perform the
> > authentication and obtain both access_token and id_token.
> >
> > However, why not just use an implicit flow where you just need to pass the
> > client_id and right after receive a response with the tokens. In this
> > case, you eliminate the code-to-token flow. That is what I meant.
> >
> > Actually, you are pretty much doing this if you set an application as
> > public in KeyCloak, right ? The difference here is that you still need to
> > do the code-to-token dance.
> >
> > IMO, this can be used for pure SSO-based use cases where the app is relying
> > on the KeyCloak Adapters. Eg.: web applications/confidential clients.
> >
> > Form_post would be just a better way to return tokens back to SPs instead
> > of passing them via query parameters.
> >
> 
> Only implicit flow passes tokens via URL parameters.  Which is one
> reason why we don't support implicit flow.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From ramtinova at gmail.com  Wed Feb 11 16:03:11 2015
From: ramtinova at gmail.com (Reza Rasouli)
Date: Thu, 12 Feb 2015 00:33:11 +0330
Subject: [keycloak-dev] REST based identity management
Message-ID: <CAO_tTRq9ymKBkwsGVJx04t0sVSKA4O7emjOhkMnfJ9Ozmv7yUQ@mail.gmail.com>

Hi,

regarding multi-tenancy in keycloak, where each tenant maps to a realm, I
wanted to ask for help on clarifying some key concepts in keycloak for aid
in implementing a simple REST based identity management POC.

Imagine there is a requirement for a multi-tenant environment where user
registration (=creation) , user login, user logout and knowing whether a
user is still logged in or not must be done over some wrapper REST service
which exposes the mentioned functionality to outside world.

With KeyCloak being deployed in a private network, I have written some
wrapper REST service which does create users for a desired tenant (=realm),
and this wrapper service itself calls KeyCloak's "*Direct Grant API*" from
an *OAuth* Client with *Super-User* Credentials both defined in the "
*master*" realm having sufficient privileges over all realms (as defined by
the documentation in "Chapter 17. Admin REST API").

Now I want to be able to wrap the logging-in and logging-out process of a
user into a tenant in the same way as user creation, which I don't know how
to work around this scenario exactly

there are some different questions in my head, regarding the situation
explained in my head which I wanted to ask :

   - to be able to log a user in/out, *through  a wrapper rest
service* , *which
   has been passed the user credential to and wants to use KeyCloak REST APIs*,
   should I create an OAuth client per each realm and login/log out the user,
   using the related OAuth client in each realm ?
   - Which REST API provides information on whether a specific user is
   already logged in or not on a specific realm?
   - How "Application" concept in keycloak differs from "OAuth Client" and
   does it make sense to log a user to an application (over REST API), if yes
   how this is  different  from logging a user into a realm with OAuth Client ?

Thanks Alot,
I really appreciate your help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150212/5a55a61c/attachment.html 

From mposolda at redhat.com  Thu Feb 12 03:49:56 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 12 Feb 2015 09:49:56 +0100
Subject: [keycloak-dev] Kerberos progress
In-Reply-To: <54DBBDD2.3050509@redhat.com>
References: <54DBADB2.40300@redhat.com> <54DBBDD2.3050509@redhat.com>
Message-ID: <54DC6934.4070902@redhat.com>

On 11.2.2015 21:38, Bill Burke wrote:
> I am not understanding how you have implemented this.  Wouldn't kerberos
> just be an authentication mechanism that the auth server uses?  I don't
> understand why you would want special configuration at the adapter
> level.  This should all be configured at the auth server so that the
> application doesn't have to know if kerberos is used or not.
Yeah, ok. I've mentioned the option #3 (Adding parameter to adapter 
config) just for case if you guys think that this is a way to go. But I 
don't like much as well ;-)
>
> Wouldn't it be:
>
> 1. App does regular SAML or OIDC redirect to auth server
> 2. Auth server checks to see if realm supports kerberos
> 3. Sends 401 + HTML
> 4. Browser sends back ticket
> 5. Auth server verifies ticket, creates SAML or OIDC response and
> redirects browser back to application
Sure, that's exactly what I am doing. Application uses just SAML or OIDC 
for communication with auth-server. It doesn't know how it is 
authenticated. Existing brokering mechanism handles this very well and 
that's why I am using it.

Only thing in your flow, which I don't yet have, is step 2. Currently 
login screen is always displayed and user needs to click on "Login with 
Kerberos" . Addressing it is what I am asking about.

I can either do it automatically (realm will always use kerberos broker 
when it is available) or allow to configure it (Redirect automatically 
to kerberos just when it's configured as default broker). I think that 
allowing to configure is better way as it allows more flexibility.

Marek
>
>
>
> On 2/11/2015 2:29 PM, Marek Posolda wrote:
>> I've already pushed initial version of Kerberos broker. It uses existing
>> brokering mechanism from Pedro and allows to login users to KC with
>> SPNEGO/Kerberos token. There are still things I need to address (more
>> testing + automated testing, Credentials delegation etc).
>>
>> I have a question about automatic Kerberos login without displaying
>> login form. Browsers support this very well - when server returns
>> response with status 401, header "WWW-Authenticate: Negotiate" and HTML
>> with login page, browsers are able to handle it and:
>>
>> * In case that user has Kerberos ticket, browser will send it back in
>> additional HTTP request with "Authorization: Negotiate <ticket>" . In
>> this case login form is not displayed to user
>>
>> * In case that user hasn't Kerberos ticket, browser just displays HTML
>> with login form
>>
>> You can try https://saml.redhat.com/idp/ to see what I mean.
>>
>> JBoss Negotiation supports this, so I believe we should address it too.
>>
>>
>> I have some ideas how to do it:
>>
>> 1) Configure default broker on server side per-realm. If used, login
>> request will automatically redirect to configured broker. It may be also
>> possible to override default broker per client?
>>
>> 2) Add on/off switch to broker configuration to specify if it should be
>> default or not
>>
>> 3) Leverage existing "k_idp_hint" parameter. I am thinking about adding
>> option "idp_hint" into AdapterConfig . In case it's configured, adapter
>> will use it for attach "k_idp_hint" parameter to login request. This
>> will allow per-application configuration and no changes on auth-server
>> side, but all applications will need to use it in their adapter
>> configuration.
>>
>> 4) Don't configure anything, but hard-code that Kerberos will be always
>> used by default if configured. Basically add new method "boolean
>> isDefault()" to IDentityProvider interface. It will return "true" for
>> Kerberos impl and "false" for other broker types we currently have.
>>
>> I like (1) or (2) most. Thoughts?
>>
>> 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 Feb 12 03:55:43 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 12 Feb 2015 09:55:43 +0100
Subject: [keycloak-dev] Kerberos progress
In-Reply-To: <830311330.10892784.1423687556576.JavaMail.zimbra@redhat.com>
References: <54DBADB2.40300@redhat.com>
	<830311330.10892784.1423687556576.JavaMail.zimbra@redhat.com>
Message-ID: <54DC6A8F.1010407@redhat.com>

On 11.2.2015 21:45, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, February 11, 2015 5:29:54 PM
>> Subject: [keycloak-dev] Kerberos progress
>>
>> I've already pushed initial version of Kerberos broker. It uses existing
>> brokering mechanism from Pedro and allows to login users to KC with
>> SPNEGO/Kerberos token. There are still things I need to address (more
>> testing + automated testing, Credentials delegation etc).
>>
>> I have a question about automatic Kerberos login without displaying
>> login form. Browsers support this very well - when server returns
>> response with status 401, header "WWW-Authenticate: Negotiate" and HTML
>> with login page, browsers are able to handle it and:
>>
>> * In case that user has Kerberos ticket, browser will send it back in
>> additional HTTP request with "Authorization: Negotiate <ticket>" . In
>> this case login form is not displayed to user
>>
>> * In case that user hasn't Kerberos ticket, browser just displays HTML
>> with login form
>>
>> You can try https://saml.redhat.com/idp/ to see what I mean.
>>
>> JBoss Negotiation supports this, so I believe we should address it too.
>>
>>
>> I have some ideas how to do it:
>>
>> 1) Configure default broker on server side per-realm. If used, login
>> request will automatically redirect to configured broker. It may be also
>> possible to override default broker per client?
>>
>> 2) Add on/off switch to broker configuration to specify if it should be
>> default or not
>>
>> 3) Leverage existing "k_idp_hint" parameter. I am thinking about adding
>> option "idp_hint" into AdapterConfig . In case it's configured, adapter
>> will use it for attach "k_idp_hint" parameter to login request. This
>> will allow per-application configuration and no changes on auth-server
>> side, but all applications will need to use it in their adapter
>> configuration.
> IMO, all above are valid. #1 and #2 may be useful even if not using Kerberos. And yes, IMO this should be per-client as well. I've added a new tab in Application and OAuth Client to enable/disable providers on a client. Maybe you can put this config there.
Ok, I can put the on/off switch for the brokering configuration (option 
#2). For Kerberos, it will be "on" by default, for other broker types 
"off" by default. This would be for specifying default brokering 
mechanism for the realm. Then I can take a look for allowing to override 
it per client in your new tab. Sounds good?

Marek
>
> I think #3 is also valid if apps want to bypass login form for their users and go straight to an identity provider.
>
> FYI, currently implementation redirects the user automatically to an identity provider if there is a single one and no credentials are configured for a realm.
>
>> 4) Don't configure anything, but hard-code that Kerberos will be always
>> used by default if configured. Basically add new method "boolean
>> isDefault()" to IDentityProvider interface. It will return "true" for
>> Kerberos impl and "false" for other broker types we currently have.
>>
>> I like (1) or (2) most. Thoughts?
>>
>> 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 Feb 12 08:49:05 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 12 Feb 2015 08:49:05 -0500
Subject: [keycloak-dev] Kerberos progress
In-Reply-To: <54DC6934.4070902@redhat.com>
References: <54DBADB2.40300@redhat.com> <54DBBDD2.3050509@redhat.com>
	<54DC6934.4070902@redhat.com>
Message-ID: <54DCAF51.90509@redhat.com>

I'm just trying to figure out where does the Broker SPI end and the User 
Federation SPI begin?  And wondering if our SPIs can be unified, 
simplified, or refactored.  For example, how would client-cert auth be 
implemented?  Like Kerberos, its a credential that is checked prior to 
displaying a login screen.

Another thing, does the broker SPI allow you to still require extra 
credentials supplied by Keycloak instead of the brokered IDP?

We just have to make these SPIs intuitive enough so that users know what 
they need to do and simple enough to extend Keycloak.

On 2/12/2015 3:49 AM, Marek Posolda wrote:
> On 11.2.2015 21:38, Bill Burke wrote:
>> I am not understanding how you have implemented this.  Wouldn't kerberos
>> just be an authentication mechanism that the auth server uses?  I don't
>> understand why you would want special configuration at the adapter
>> level.  This should all be configured at the auth server so that the
>> application doesn't have to know if kerberos is used or not.
> Yeah, ok. I've mentioned the option #3 (Adding parameter to adapter
> config) just for case if you guys think that this is a way to go. But I
> don't like much as well ;-)
>>
>> Wouldn't it be:
>>
>> 1. App does regular SAML or OIDC redirect to auth server
>> 2. Auth server checks to see if realm supports kerberos
>> 3. Sends 401 + HTML
>> 4. Browser sends back ticket
>> 5. Auth server verifies ticket, creates SAML or OIDC response and
>> redirects browser back to application
> Sure, that's exactly what I am doing. Application uses just SAML or OIDC
> for communication with auth-server. It doesn't know how it is
> authenticated. Existing brokering mechanism handles this very well and
> that's why I am using it.
>
> Only thing in your flow, which I don't yet have, is step 2. Currently
> login screen is always displayed and user needs to click on "Login with
> Kerberos" . Addressing it is what I am asking about.
>
> I can either do it automatically (realm will always use kerberos broker
> when it is available) or allow to configure it (Redirect automatically
> to kerberos just when it's configured as default broker). I think that
> allowing to configure is better way as it allows more flexibility.
>
> Marek
>>
>>
>>
>> On 2/11/2015 2:29 PM, Marek Posolda wrote:
>>> I've already pushed initial version of Kerberos broker. It uses existing
>>> brokering mechanism from Pedro and allows to login users to KC with
>>> SPNEGO/Kerberos token. There are still things I need to address (more
>>> testing + automated testing, Credentials delegation etc).
>>>
>>> I have a question about automatic Kerberos login without displaying
>>> login form. Browsers support this very well - when server returns
>>> response with status 401, header "WWW-Authenticate: Negotiate" and HTML
>>> with login page, browsers are able to handle it and:
>>>
>>> * In case that user has Kerberos ticket, browser will send it back in
>>> additional HTTP request with "Authorization: Negotiate <ticket>" . In
>>> this case login form is not displayed to user
>>>
>>> * In case that user hasn't Kerberos ticket, browser just displays HTML
>>> with login form
>>>
>>> You can try https://saml.redhat.com/idp/ to see what I mean.
>>>
>>> JBoss Negotiation supports this, so I believe we should address it too.
>>>
>>>
>>> I have some ideas how to do it:
>>>
>>> 1) Configure default broker on server side per-realm. If used, login
>>> request will automatically redirect to configured broker. It may be also
>>> possible to override default broker per client?
>>>
>>> 2) Add on/off switch to broker configuration to specify if it should be
>>> default or not
>>>
>>> 3) Leverage existing "k_idp_hint" parameter. I am thinking about adding
>>> option "idp_hint" into AdapterConfig . In case it's configured, adapter
>>> will use it for attach "k_idp_hint" parameter to login request. This
>>> will allow per-application configuration and no changes on auth-server
>>> side, but all applications will need to use it in their adapter
>>> configuration.
>>>
>>> 4) Don't configure anything, but hard-code that Kerberos will be always
>>> used by default if configured. Basically add new method "boolean
>>> isDefault()" to IDentityProvider interface. It will return "true" for
>>> Kerberos impl and "false" for other broker types we currently have.
>>>
>>> I like (1) or (2) most. Thoughts?
>>>
>>> Marek
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From psilva at redhat.com  Thu Feb 12 08:53:32 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 12 Feb 2015 08:53:32 -0500 (EST)
Subject: [keycloak-dev] Kerberos progress
In-Reply-To: <54DCAF51.90509@redhat.com>
References: <54DBADB2.40300@redhat.com> <54DBBDD2.3050509@redhat.com>
	<54DC6934.4070902@redhat.com> <54DCAF51.90509@redhat.com>
Message-ID: <1852990429.11196002.1423749212786.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Marek Posolda" <mposolda at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Thursday, February 12, 2015 11:49:05 AM
> Subject: Re: [keycloak-dev] Kerberos progress
> 
> I'm just trying to figure out where does the Broker SPI end and the User
> Federation SPI begin?  And wondering if our SPIs can be unified,
> simplified, or refactored.  For example, how would client-cert auth be
> implemented?  Like Kerberos, its a credential that is checked prior to
> displaying a login screen.
> 
> Another thing, does the broker SPI allow you to still require extra
> credentials supplied by Keycloak instead of the brokered IDP?

What is the use case ?

> 
> We just have to make these SPIs intuitive enough so that users know what
> they need to do and simple enough to extend Keycloak.
> 
> On 2/12/2015 3:49 AM, Marek Posolda wrote:
> > On 11.2.2015 21:38, Bill Burke wrote:
> >> I am not understanding how you have implemented this.  Wouldn't kerberos
> >> just be an authentication mechanism that the auth server uses?  I don't
> >> understand why you would want special configuration at the adapter
> >> level.  This should all be configured at the auth server so that the
> >> application doesn't have to know if kerberos is used or not.
> > Yeah, ok. I've mentioned the option #3 (Adding parameter to adapter
> > config) just for case if you guys think that this is a way to go. But I
> > don't like much as well ;-)
> >>
> >> Wouldn't it be:
> >>
> >> 1. App does regular SAML or OIDC redirect to auth server
> >> 2. Auth server checks to see if realm supports kerberos
> >> 3. Sends 401 + HTML
> >> 4. Browser sends back ticket
> >> 5. Auth server verifies ticket, creates SAML or OIDC response and
> >> redirects browser back to application
> > Sure, that's exactly what I am doing. Application uses just SAML or OIDC
> > for communication with auth-server. It doesn't know how it is
> > authenticated. Existing brokering mechanism handles this very well and
> > that's why I am using it.
> >
> > Only thing in your flow, which I don't yet have, is step 2. Currently
> > login screen is always displayed and user needs to click on "Login with
> > Kerberos" . Addressing it is what I am asking about.
> >
> > I can either do it automatically (realm will always use kerberos broker
> > when it is available) or allow to configure it (Redirect automatically
> > to kerberos just when it's configured as default broker). I think that
> > allowing to configure is better way as it allows more flexibility.
> >
> > Marek
> >>
> >>
> >>
> >> On 2/11/2015 2:29 PM, Marek Posolda wrote:
> >>> I've already pushed initial version of Kerberos broker. It uses existing
> >>> brokering mechanism from Pedro and allows to login users to KC with
> >>> SPNEGO/Kerberos token. There are still things I need to address (more
> >>> testing + automated testing, Credentials delegation etc).
> >>>
> >>> I have a question about automatic Kerberos login without displaying
> >>> login form. Browsers support this very well - when server returns
> >>> response with status 401, header "WWW-Authenticate: Negotiate" and HTML
> >>> with login page, browsers are able to handle it and:
> >>>
> >>> * In case that user has Kerberos ticket, browser will send it back in
> >>> additional HTTP request with "Authorization: Negotiate <ticket>" . In
> >>> this case login form is not displayed to user
> >>>
> >>> * In case that user hasn't Kerberos ticket, browser just displays HTML
> >>> with login form
> >>>
> >>> You can try https://saml.redhat.com/idp/ to see what I mean.
> >>>
> >>> JBoss Negotiation supports this, so I believe we should address it too.
> >>>
> >>>
> >>> I have some ideas how to do it:
> >>>
> >>> 1) Configure default broker on server side per-realm. If used, login
> >>> request will automatically redirect to configured broker. It may be also
> >>> possible to override default broker per client?
> >>>
> >>> 2) Add on/off switch to broker configuration to specify if it should be
> >>> default or not
> >>>
> >>> 3) Leverage existing "k_idp_hint" parameter. I am thinking about adding
> >>> option "idp_hint" into AdapterConfig . In case it's configured, adapter
> >>> will use it for attach "k_idp_hint" parameter to login request. This
> >>> will allow per-application configuration and no changes on auth-server
> >>> side, but all applications will need to use it in their adapter
> >>> configuration.
> >>>
> >>> 4) Don't configure anything, but hard-code that Kerberos will be always
> >>> used by default if configured. Basically add new method "boolean
> >>> isDefault()" to IDentityProvider interface. It will return "true" for
> >>> Kerberos impl and "false" for other broker types we currently have.
> >>>
> >>> I like (1) or (2) most. Thoughts?
> >>>
> >>> Marek
> >>>
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Thu Feb 12 09:01:20 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 12 Feb 2015 09:01:20 -0500
Subject: [keycloak-dev] Kerberos progress
In-Reply-To: <1852990429.11196002.1423749212786.JavaMail.zimbra@redhat.com>
References: <54DBADB2.40300@redhat.com> <54DBBDD2.3050509@redhat.com>
	<54DC6934.4070902@redhat.com> <54DCAF51.90509@redhat.com>
	<1852990429.11196002.1423749212786.JavaMail.zimbra@redhat.com>
Message-ID: <54DCB230.8090905@redhat.com>



On 2/12/2015 8:53 AM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Marek Posolda" <mposolda at redhat.com>, keycloak-dev at lists.jboss.org
>> Sent: Thursday, February 12, 2015 11:49:05 AM
>> Subject: Re: [keycloak-dev] Kerberos progress
>>
>> I'm just trying to figure out where does the Broker SPI end and the User
>> Federation SPI begin?  And wondering if our SPIs can be unified,
>> simplified, or refactored.  For example, how would client-cert auth be
>> implemented?  Like Kerberos, its a credential that is checked prior to
>> displaying a login screen.
>>
>> Another thing, does the broker SPI allow you to still require extra
>> credentials supplied by Keycloak instead of the brokered IDP?
>
> What is the use case ?
>

You have an IDP that only handles username/password and you want to add 
client-cert/otp for additional protection.  For example a login to 
facebook.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From psilva at redhat.com  Thu Feb 12 09:14:18 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 12 Feb 2015 09:14:18 -0500 (EST)
Subject: [keycloak-dev] Kerberos progress
In-Reply-To: <54DCB230.8090905@redhat.com>
References: <54DBADB2.40300@redhat.com> <54DBBDD2.3050509@redhat.com>
	<54DC6934.4070902@redhat.com> <54DCAF51.90509@redhat.com>
	<1852990429.11196002.1423749212786.JavaMail.zimbra@redhat.com>
	<54DCB230.8090905@redhat.com>
Message-ID: <476506584.11208726.1423750458070.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "Marek Posolda" <mposolda at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Thursday, February 12, 2015 12:01:20 PM
> Subject: Re: [keycloak-dev] Kerberos progress
> 
> 
> 
> On 2/12/2015 8:53 AM, Pedro Igor Silva wrote:
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Marek Posolda" <mposolda at redhat.com>, keycloak-dev at lists.jboss.org
> >> Sent: Thursday, February 12, 2015 11:49:05 AM
> >> Subject: Re: [keycloak-dev] Kerberos progress
> >>
> >> I'm just trying to figure out where does the Broker SPI end and the User
> >> Federation SPI begin?  And wondering if our SPIs can be unified,
> >> simplified, or refactored.  For example, how would client-cert auth be
> >> implemented?  Like Kerberos, its a credential that is checked prior to
> >> displaying a login screen.
> >>
> >> Another thing, does the broker SPI allow you to still require extra
> >> credentials supplied by Keycloak instead of the brokered IDP?
> >
> > What is the use case ?
> >
> 
> You have an IDP that only handles username/password and you want to add
> client-cert/otp for additional protection.  For example a login to
> facebook.

Today, the broker is handling only UPDATE_PROFILE required action. This is an on/off button on the provider's page to force update profile despite if it is defined by a realm or not.

For credentials and other types of required actions, I think if you set that for a realm the user will be presented with the respective page.  I did not test that, but I'll and also write some tests. The broker always invoke your code in org.keycloak.services.managers.AuthenticationManager#nextActionAfterAuthentication after a successful authentication.

> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Thu Feb 12 09:07:09 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 12 Feb 2015 09:07:09 -0500
Subject: [keycloak-dev] REST based identity management
In-Reply-To: <CAO_tTRq9ymKBkwsGVJx04t0sVSKA4O7emjOhkMnfJ9Ozmv7yUQ@mail.gmail.com>
References: <CAO_tTRq9ymKBkwsGVJx04t0sVSKA4O7emjOhkMnfJ9Ozmv7yUQ@mail.gmail.com>
Message-ID: <54DCB38D.7020004@redhat.com>

We will probably eventually merge the concepts of an OAUth client and a 
Application.  Right now, Oauth clients require a consent page and 
applications do not.  OAuth clients also have different default settings 
than applications.  Applications tend to be more trusted entities.  That 
was the idea when Keycloak started.

The Admin REST API can be used to determine anything you want.  Our 
admin console uses this REST API.  WE have javadoc-like REST API docs on 
our website.  Might not be the best documentation, but its all we got 
right now.

Having a different application gather credentials and provide screens is 
really counter to the spirit of Keycloak.  Looks like we will have to 
support this use case though.

On 2/11/2015 4:03 PM, Reza Rasouli wrote:
> Hi,
>
> regarding multi-tenancy in keycloak, where each tenant maps to a realm,
> I wanted to ask for help on clarifying some key concepts in keycloak for
> aid in implementing a simple REST based identity management POC.
>
> Imagine there is a requirement for a multi-tenant environment where user
> registration (=creation) , user login, user logout and knowing whether a
> user is still logged in or not must be done over some wrapper REST
> service which exposes the mentioned functionality to outside world.
>
> With KeyCloak being deployed in a private network, I have written some
> wrapper REST service which does create users for a desired tenant
> (=realm), and this wrapper service itself calls KeyCloak's "*Direct
> Grant API*" from an *OAuth* Client with *Super-User* Credentials both
> defined in the "*master*" realm having sufficient privileges over all
> realms (as defined by the documentation in"Chapter 17. Admin REST API").
>
> Now I want to be able to wrap the logging-in and logging-out process of
> a user into a tenant in the same way as user creation, which I don't
> know how to work around this scenario exactly
>
> there are some different questions in my head, regarding the situation
> explained in my head which I wanted to ask :
>
>   * to be able to log a user in/out, _through  a wrapper rest service_ ,
>     /which has been passed the user credential to and wants to use
>     KeyCloak REST APIs/, should I create an OAuth client per each realm
>     and login/log out the user, using the related OAuth client in each
>     realm ?
>   * Which REST API provides information on whether a specific user is
>     already logged in or not on a specific realm?
>   * How "Application" concept in keycloak differs from "OAuth Client"
>     and does it make sense to log a user to an application (over REST
>     API), if yes how this is  different  from logging a user into a
>     realm with OAuth Client ?
>
> Thanks Alot,
> I really appreciate your help.
>
>
>
>
>
> _______________________________________________
> 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 sblanc at redhat.com  Thu Feb 12 09:35:18 2015
From: sblanc at redhat.com (Sebastien Blanc)
Date: Thu, 12 Feb 2015 15:35:18 +0100
Subject: [keycloak-dev] Liquibase errors on first startup with KC 1.1.0-Final
Message-ID: <54DCBA26.9070408@redhat.com>

Hi,

We discovered recently that deploying Keycloak (the one that comes with 
the AeroGear distro) on a "fresh" Wildfly 8.2  was generating liquibase 
errors ( https://gist.github.com/lholmquist/f031f7a3d88477ba81a7).
Restarting the server removes these errors.
Any idea ? Should I open a ticket ?

It concerns 1.1.0-Final

Sebi


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150212/6c5850c4/attachment.html 

From mposolda at redhat.com  Thu Feb 12 11:35:21 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 12 Feb 2015 17:35:21 +0100
Subject: [keycloak-dev] Kerberos progress
In-Reply-To: <54DCAF51.90509@redhat.com>
References: <54DBADB2.40300@redhat.com> <54DBBDD2.3050509@redhat.com>
	<54DC6934.4070902@redhat.com> <54DCAF51.90509@redhat.com>
Message-ID: <54DCD649.3050107@redhat.com>

I see your point. I still believe that kerberos better suits Broker SPI 
for few reasons.

- Broker SPI allows update profile after first login, which is required 
for Kerberos (Kerberos doesn't have a way to provision firstName, 
lastName or email).

- Also it allows link your account with kerberos in account management.

- Finally broker allows to expose 3rd party token/credential from broker 
authentication to be shared to application and used for further calls. 
For Kerberos, this is achieved through credential delegation and we need 
to support as JBoss Negotiation supported it too (AFAIK Keycloak should 
support all the usecases previously supported by Picketlink+JBoss 
Negotiation).

Only thing is automatic login without displaying login screen, but it 
makes sense to easily extend our broker SPI to allow configuring this. 
Usually people will require automatic login with Kerberos, but maybe not 
always. For example realm can be configured with 2 kerberos servers. In 
this case login page may be displayed and user will need to click on 
"Login with kerberos 1" or "Login with kerberos 2" according to which 
kerberos domain he has ticket.

For handling more protections, maybe we should add something like 
AuthenticationFilter or AuthenticationInterceptor? That will allow 
people to configure chain of more interceptors and configure that user 
is required to login with all of Kerberos ticket, Facebook password and 
TOTP? We can also add flags like PAM (Required, Requisite, Sufficient etc)?

Marek

On 12.2.2015 14:49, Bill Burke wrote:
> I'm just trying to figure out where does the Broker SPI end and the 
> User Federation SPI begin?  And wondering if our SPIs can be unified, 
> simplified, or refactored.  For example, how would client-cert auth be 
> implemented?  Like Kerberos, its a credential that is checked prior to 
> displaying a login screen.
>
> Another thing, does the broker SPI allow you to still require extra 
> credentials supplied by Keycloak instead of the brokered IDP?
>
> We just have to make these SPIs intuitive enough so that users know 
> what they need to do and simple enough to extend Keycloak.
>
> On 2/12/2015 3:49 AM, Marek Posolda wrote:
>> On 11.2.2015 21:38, Bill Burke wrote:
>>> I am not understanding how you have implemented this.  Wouldn't 
>>> kerberos
>>> just be an authentication mechanism that the auth server uses?  I don't
>>> understand why you would want special configuration at the adapter
>>> level.  This should all be configured at the auth server so that the
>>> application doesn't have to know if kerberos is used or not.
>> Yeah, ok. I've mentioned the option #3 (Adding parameter to adapter
>> config) just for case if you guys think that this is a way to go. But I
>> don't like much as well ;-)
>>>
>>> Wouldn't it be:
>>>
>>> 1. App does regular SAML or OIDC redirect to auth server
>>> 2. Auth server checks to see if realm supports kerberos
>>> 3. Sends 401 + HTML
>>> 4. Browser sends back ticket
>>> 5. Auth server verifies ticket, creates SAML or OIDC response and
>>> redirects browser back to application
>> Sure, that's exactly what I am doing. Application uses just SAML or OIDC
>> for communication with auth-server. It doesn't know how it is
>> authenticated. Existing brokering mechanism handles this very well and
>> that's why I am using it.
>>
>> Only thing in your flow, which I don't yet have, is step 2. Currently
>> login screen is always displayed and user needs to click on "Login with
>> Kerberos" . Addressing it is what I am asking about.
>>
>> I can either do it automatically (realm will always use kerberos broker
>> when it is available) or allow to configure it (Redirect automatically
>> to kerberos just when it's configured as default broker). I think that
>> allowing to configure is better way as it allows more flexibility.
>>
>> Marek
>>>
>>>
>>>
>>> On 2/11/2015 2:29 PM, Marek Posolda wrote:
>>>> I've already pushed initial version of Kerberos broker. It uses 
>>>> existing
>>>> brokering mechanism from Pedro and allows to login users to KC with
>>>> SPNEGO/Kerberos token. There are still things I need to address (more
>>>> testing + automated testing, Credentials delegation etc).
>>>>
>>>> I have a question about automatic Kerberos login without displaying
>>>> login form. Browsers support this very well - when server returns
>>>> response with status 401, header "WWW-Authenticate: Negotiate" and 
>>>> HTML
>>>> with login page, browsers are able to handle it and:
>>>>
>>>> * In case that user has Kerberos ticket, browser will send it back in
>>>> additional HTTP request with "Authorization: Negotiate <ticket>" . In
>>>> this case login form is not displayed to user
>>>>
>>>> * In case that user hasn't Kerberos ticket, browser just displays HTML
>>>> with login form
>>>>
>>>> You can try https://saml.redhat.com/idp/ to see what I mean.
>>>>
>>>> JBoss Negotiation supports this, so I believe we should address it 
>>>> too.
>>>>
>>>>
>>>> I have some ideas how to do it:
>>>>
>>>> 1) Configure default broker on server side per-realm. If used, login
>>>> request will automatically redirect to configured broker. It may be 
>>>> also
>>>> possible to override default broker per client?
>>>>
>>>> 2) Add on/off switch to broker configuration to specify if it 
>>>> should be
>>>> default or not
>>>>
>>>> 3) Leverage existing "k_idp_hint" parameter. I am thinking about 
>>>> adding
>>>> option "idp_hint" into AdapterConfig . In case it's configured, 
>>>> adapter
>>>> will use it for attach "k_idp_hint" parameter to login request. This
>>>> will allow per-application configuration and no changes on auth-server
>>>> side, but all applications will need to use it in their adapter
>>>> configuration.
>>>>
>>>> 4) Don't configure anything, but hard-code that Kerberos will be 
>>>> always
>>>> used by default if configured. Basically add new method "boolean
>>>> isDefault()" to IDentityProvider interface. It will return "true" for
>>>> Kerberos impl and "false" for other broker types we currently have.
>>>>
>>>> I like (1) or (2) most. Thoughts?
>>>>
>>>> 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 Feb 12 11:43:10 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 12 Feb 2015 11:43:10 -0500
Subject: [keycloak-dev] Kerberos progress
In-Reply-To: <54DCD649.3050107@redhat.com>
References: <54DBADB2.40300@redhat.com> <54DBBDD2.3050509@redhat.com>
	<54DC6934.4070902@redhat.com> <54DCAF51.90509@redhat.com>
	<54DCD649.3050107@redhat.com>
Message-ID: <54DCD81E.4020800@redhat.com>

Ok, sounds good.  Don't worry about filters and interceptors.  We'll see 
where the community takes us.

On 2/12/2015 11:35 AM, Marek Posolda wrote:
> I see your point. I still believe that kerberos better suits Broker SPI
> for few reasons.
>
> - Broker SPI allows update profile after first login, which is required
> for Kerberos (Kerberos doesn't have a way to provision firstName,
> lastName or email).
>
> - Also it allows link your account with kerberos in account management.
>
> - Finally broker allows to expose 3rd party token/credential from broker
> authentication to be shared to application and used for further calls.
> For Kerberos, this is achieved through credential delegation and we need
> to support as JBoss Negotiation supported it too (AFAIK Keycloak should
> support all the usecases previously supported by Picketlink+JBoss
> Negotiation).
>
> Only thing is automatic login without displaying login screen, but it
> makes sense to easily extend our broker SPI to allow configuring this.
> Usually people will require automatic login with Kerberos, but maybe not
> always. For example realm can be configured with 2 kerberos servers. In
> this case login page may be displayed and user will need to click on
> "Login with kerberos 1" or "Login with kerberos 2" according to which
> kerberos domain he has ticket.
>
> For handling more protections, maybe we should add something like
> AuthenticationFilter or AuthenticationInterceptor? That will allow
> people to configure chain of more interceptors and configure that user
> is required to login with all of Kerberos ticket, Facebook password and
> TOTP? We can also add flags like PAM (Required, Requisite, Sufficient etc)?
>
> Marek
>
> On 12.2.2015 14:49, Bill Burke wrote:
>> I'm just trying to figure out where does the Broker SPI end and the
>> User Federation SPI begin?  And wondering if our SPIs can be unified,
>> simplified, or refactored.  For example, how would client-cert auth be
>> implemented?  Like Kerberos, its a credential that is checked prior to
>> displaying a login screen.
>>
>> Another thing, does the broker SPI allow you to still require extra
>> credentials supplied by Keycloak instead of the brokered IDP?
>>
>> We just have to make these SPIs intuitive enough so that users know
>> what they need to do and simple enough to extend Keycloak.
>>
>> On 2/12/2015 3:49 AM, Marek Posolda wrote:
>>> On 11.2.2015 21:38, Bill Burke wrote:
>>>> I am not understanding how you have implemented this.  Wouldn't
>>>> kerberos
>>>> just be an authentication mechanism that the auth server uses?  I don't
>>>> understand why you would want special configuration at the adapter
>>>> level.  This should all be configured at the auth server so that the
>>>> application doesn't have to know if kerberos is used or not.
>>> Yeah, ok. I've mentioned the option #3 (Adding parameter to adapter
>>> config) just for case if you guys think that this is a way to go. But I
>>> don't like much as well ;-)
>>>>
>>>> Wouldn't it be:
>>>>
>>>> 1. App does regular SAML or OIDC redirect to auth server
>>>> 2. Auth server checks to see if realm supports kerberos
>>>> 3. Sends 401 + HTML
>>>> 4. Browser sends back ticket
>>>> 5. Auth server verifies ticket, creates SAML or OIDC response and
>>>> redirects browser back to application
>>> Sure, that's exactly what I am doing. Application uses just SAML or OIDC
>>> for communication with auth-server. It doesn't know how it is
>>> authenticated. Existing brokering mechanism handles this very well and
>>> that's why I am using it.
>>>
>>> Only thing in your flow, which I don't yet have, is step 2. Currently
>>> login screen is always displayed and user needs to click on "Login with
>>> Kerberos" . Addressing it is what I am asking about.
>>>
>>> I can either do it automatically (realm will always use kerberos broker
>>> when it is available) or allow to configure it (Redirect automatically
>>> to kerberos just when it's configured as default broker). I think that
>>> allowing to configure is better way as it allows more flexibility.
>>>
>>> Marek
>>>>
>>>>
>>>>
>>>> On 2/11/2015 2:29 PM, Marek Posolda wrote:
>>>>> I've already pushed initial version of Kerberos broker. It uses
>>>>> existing
>>>>> brokering mechanism from Pedro and allows to login users to KC with
>>>>> SPNEGO/Kerberos token. There are still things I need to address (more
>>>>> testing + automated testing, Credentials delegation etc).
>>>>>
>>>>> I have a question about automatic Kerberos login without displaying
>>>>> login form. Browsers support this very well - when server returns
>>>>> response with status 401, header "WWW-Authenticate: Negotiate" and
>>>>> HTML
>>>>> with login page, browsers are able to handle it and:
>>>>>
>>>>> * In case that user has Kerberos ticket, browser will send it back in
>>>>> additional HTTP request with "Authorization: Negotiate <ticket>" . In
>>>>> this case login form is not displayed to user
>>>>>
>>>>> * In case that user hasn't Kerberos ticket, browser just displays HTML
>>>>> with login form
>>>>>
>>>>> You can try https://saml.redhat.com/idp/ to see what I mean.
>>>>>
>>>>> JBoss Negotiation supports this, so I believe we should address it
>>>>> too.
>>>>>
>>>>>
>>>>> I have some ideas how to do it:
>>>>>
>>>>> 1) Configure default broker on server side per-realm. If used, login
>>>>> request will automatically redirect to configured broker. It may be
>>>>> also
>>>>> possible to override default broker per client?
>>>>>
>>>>> 2) Add on/off switch to broker configuration to specify if it
>>>>> should be
>>>>> default or not
>>>>>
>>>>> 3) Leverage existing "k_idp_hint" parameter. I am thinking about
>>>>> adding
>>>>> option "idp_hint" into AdapterConfig . In case it's configured,
>>>>> adapter
>>>>> will use it for attach "k_idp_hint" parameter to login request. This
>>>>> will allow per-application configuration and no changes on auth-server
>>>>> side, but all applications will need to use it in their adapter
>>>>> configuration.
>>>>>
>>>>> 4) Don't configure anything, but hard-code that Kerberos will be
>>>>> always
>>>>> used by default if configured. Basically add new method "boolean
>>>>> isDefault()" to IDentityProvider interface. It will return "true" for
>>>>> Kerberos impl and "false" for other broker types we currently have.
>>>>>
>>>>> I like (1) or (2) most. Thoughts?
>>>>>
>>>>> Marek
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>
>>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From mposolda at redhat.com  Thu Feb 12 15:36:45 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 12 Feb 2015 21:36:45 +0100
Subject: [keycloak-dev] Liquibase errors on first startup with KC
	1.1.0-Final
In-Reply-To: <54DCBA26.9070408@redhat.com>
References: <54DCBA26.9070408@redhat.com>
Message-ID: <54DD0EDD.2000007@redhat.com>

Hi,

Is Keycloak DB and Aerogear DB points to same database? Will it help if 
you point keycloak DB to different one (ie. use different H2 directory 
for your datasource and KeycloakDS datasource) ?

Otherwise feel free to create JIRA with steps to reproduce.

Marek

On 12.2.2015 15:35, Sebastien Blanc wrote:
> Hi,
>
> We discovered recently that deploying Keycloak (the one that comes 
> with the AeroGear distro) on a "fresh" Wildfly 8.2  was generating 
> liquibase errors ( 
> https://gist.github.com/lholmquist/f031f7a3d88477ba81a7).
> Restarting the server removes these errors.
> Any idea ? Should I open a ticket ?
>
> It concerns 1.1.0-Final
>
> Sebi
>
>
>
>
> _______________________________________________
> 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/20150212/1b0abcca/attachment.html 

From bburke at redhat.com  Fri Feb 13 10:37:58 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 13 Feb 2015 10:37:58 -0500
Subject: [keycloak-dev] immutable ClaimType name?
Message-ID: <54DE1A56.80901@redhat.com>

I need some advice here.  I'm trying to figure out how to model a 
ClaimType for our persistent store.  I'm thinking that the @Id of the 
ClaimType will be the name of the claim itself (phone, street, etc.). 
The name will be immutable once created.

Why do it this way?

* Simpler to store.  UserModel can just have a Map<String, String> of 
claim values
* More importantly, human readable files (json imports, and our 
FileBased store) will be able to reference the claim type by name rather 
than id.  Users crafting an import file will not have to specify an ID 
anywhere or generate one.   This claim type is going to be referenced in 
a few places:
- protocol claim mapping
- user claim value store

That sound ok?

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Fri Feb 13 10:39:49 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 13 Feb 2015 10:39:49 -0500
Subject: [keycloak-dev] immutable ClaimType name?
In-Reply-To: <54DE1A56.80901@redhat.com>
References: <54DE1A56.80901@redhat.com>
Message-ID: <54DE1AC5.9060909@redhat.com>

Actually I'll take some of that back... at Id won't be a name.  I'll 
generate an ID so that different realms can have different claim types 
of the same name but different characteristics.  Protocol claim mappings 
and user claim value storage will still reference the claim type by name 
and the claim type name will be immutable.

On 2/13/2015 10:37 AM, Bill Burke wrote:
> I need some advice here.  I'm trying to figure out how to model a
> ClaimType for our persistent store.  I'm thinking that the @Id of the
> ClaimType will be the name of the claim itself (phone, street, etc.).
> The name will be immutable once created.
>
> Why do it this way?
>
> * Simpler to store.  UserModel can just have a Map<String, String> of
> claim values
> * More importantly, human readable files (json imports, and our
> FileBased store) will be able to reference the claim type by name rather
> than id.  Users crafting an import file will not have to specify an ID
> anywhere or generate one.   This claim type is going to be referenced in
> a few places:
> - protocol claim mapping
> - user claim value store
>
> That sound ok?
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Fri Feb 13 11:37:17 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 13 Feb 2015 11:37:17 -0500
Subject: [keycloak-dev] Representations values must be Objects
Message-ID: <54DE283D.8030203@redhat.com>

This is very important:

All Representation (json) classes must have Object, nullable attributes 
types.  The reason is for REST updates.  The pattern we use is that if 
the value is null, we don't update, if the value isn't null, we update. 
  So, boolean must be set as Boolean objects.

kthxbye,

Bill

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Sun Feb 15 11:38:08 2015
From: bburke at redhat.com (Bill Burke)
Date: Sun, 15 Feb 2015 11:38:08 -0500
Subject: [keycloak-dev] From 1.2->2.0
Message-ID: <54E0CB70.8040208@redhat.com>

I think we still have a few major features to implement for 1.2 and 
maybe 1.3.  After this I'd like to focus on Keycloak 2.0 things like:

* Improving and nailing down our SPIs
* Splitting up code into private and public models so we can restrict 
what APIs/SPIs we want to commercially support
* Pulling in and refactoring PL Federation
* Consolidating and improving our admin console UI

Really starting improving the core of Keycloak knowing that Keycloak 2.0 
is what we're going to be supporting commercially for years and years 
going forward.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From mposolda at redhat.com  Mon Feb 16 02:25:04 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 16 Feb 2015 08:25:04 +0100
Subject: [keycloak-dev] immutable ClaimType name?
In-Reply-To: <54DE1AC5.9060909@redhat.com>
References: <54DE1A56.80901@redhat.com> <54DE1AC5.9060909@redhat.com>
Message-ID: <54E19B50.1010206@redhat.com>

+1, I am not seeing any issues with having claim type name unique per 
realm and reference claim types by name.

Marek

On 13.2.2015 16:39, Bill Burke wrote:
> Actually I'll take some of that back... at Id won't be a name.  I'll
> generate an ID so that different realms can have different claim types
> of the same name but different characteristics.  Protocol claim mappings
> and user claim value storage will still reference the claim type by name
> and the claim type name will be immutable.
>
> On 2/13/2015 10:37 AM, Bill Burke wrote:
>> I need some advice here.  I'm trying to figure out how to model a
>> ClaimType for our persistent store.  I'm thinking that the @Id of the
>> ClaimType will be the name of the claim itself (phone, street, etc.).
>> The name will be immutable once created.
>>
>> Why do it this way?
>>
>> * Simpler to store.  UserModel can just have a Map<String, String> of
>> claim values
>> * More importantly, human readable files (json imports, and our
>> FileBased store) will be able to reference the claim type by name rather
>> than id.  Users crafting an import file will not have to specify an ID
>> anywhere or generate one.   This claim type is going to be referenced in
>> a few places:
>> - protocol claim mapping
>> - user claim value store
>>
>> That sound ok?
>>


From psilva at redhat.com  Mon Feb 16 06:48:53 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 16 Feb 2015 06:48:53 -0500 (EST)
Subject: [keycloak-dev] From 1.2->2.0
In-Reply-To: <54E0CB70.8040208@redhat.com>
References: <54E0CB70.8040208@redhat.com>
Message-ID: <1287447405.13146075.1424087333088.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Sunday, February 15, 2015 2:38:08 PM
> Subject: [keycloak-dev] From 1.2->2.0
> 
> I think we still have a few major features to implement for 1.2 and
> maybe 1.3.  After this I'd like to focus on Keycloak 2.0 things like:
> 
> * Improving and nailing down our SPIs
> * Splitting up code into private and public models so we can restrict
> what APIs/SPIs we want to commercially support
> * Pulling in and refactoring PL Federation

I've an issue [1] in the SAML parsers that needs a fix. I don't know what are your plans for this, but I think we can start moving PL SAML types and parsers to KC ? Do you want/need a refactoring for them ?

Or the refactoring you always talk about is around the SAML processing logic ? Such as handlers, etc ...

[1] https://issues.jboss.org/browse/KEYCLOAK-883

> * Consolidating and improving our admin console UI
> 
> Really starting improving the core of Keycloak knowing that Keycloak 2.0
> is what we're going to be supporting commercially for years and years
> going forward.
> --
> 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 Feb 16 09:05:54 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 16 Feb 2015 09:05:54 -0500
Subject: [keycloak-dev] From 1.2->2.0
In-Reply-To: <1287447405.13146075.1424087333088.JavaMail.zimbra@redhat.com>
References: <54E0CB70.8040208@redhat.com>
	<1287447405.13146075.1424087333088.JavaMail.zimbra@redhat.com>
Message-ID: <54E1F942.3090600@redhat.com>

I want to refactor the Builders I wrote so they can be user consumable. 
  What I want to have is a SAML SPI in which the SPI interface is passed 
a Builder.  Then the SPI plugin can modify the document however they 
want.  We'll need something similar for OIDC.

On 2/16/2015 6:48 AM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Sunday, February 15, 2015 2:38:08 PM
>> Subject: [keycloak-dev] From 1.2->2.0
>>
>> I think we still have a few major features to implement for 1.2 and
>> maybe 1.3.  After this I'd like to focus on Keycloak 2.0 things like:
>>
>> * Improving and nailing down our SPIs
>> * Splitting up code into private and public models so we can restrict
>> what APIs/SPIs we want to commercially support
>> * Pulling in and refactoring PL Federation
>
> I've an issue [1] in the SAML parsers that needs a fix. I don't know what are your plans for this, but I think we can start moving PL SAML types and parsers to KC ? Do you want/need a refactoring for them ?
>
> Or the refactoring you always talk about is around the SAML processing logic ? Such as handlers, etc ...
>
> [1] https://issues.jboss.org/browse/KEYCLOAK-883
>
>> * Consolidating and improving our admin console UI
>>
>> Really starting improving the core of Keycloak knowing that Keycloak 2.0
>> is what we're going to be supporting commercially for years and years
>> going forward.
>> --
>> 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 aryvlin at morphotrust.com  Mon Feb 16 11:13:37 2015
From: aryvlin at morphotrust.com (Ryvlin, Andrey)
Date: Mon, 16 Feb 2015 16:13:37 +0000
Subject: [keycloak-dev] SOAP security with Keycloak
Message-ID: <3a9d6173d99e4c7dac19324a66cd071e@BLM-MAIL01P.l1id.local>

Hi,
I am evaluating Keycloak server for my project and securing REST APIs and Web applications was very easy.
Now I have a task to secure some SOAP endpoints
Is it possible to do it with Keycloak? If so, what?s the best practice?

Thanks?
-----------------
Andrey Ryvlin
Principal Software Engineer

Phone: 952-979-8492
5705 W Old Shakopee Road, Suite 100
Bloomington, MN 55437 USA
ARyvlin at MorphoTrust.com<mailto:ARyvlin at MorphoTrust.com>
www.MorphoTrust.com<http://www.morphotrust.com/>

[cid:image003.jpg at 01CFF75A.60542BC0]


________________________________

This message is only for the use of the intended recipient and may contain information that is CONFIDENTIAL and PROPRIETARY to MorphoTrust USA, Inc. If you are not the intended recipient, please erase all copies of the message and its attachments and notify the sender immediately.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150216/420947ea/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1778 bytes
Desc: image001.jpg
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150216/420947ea/attachment-0001.jpg 

From bburke at redhat.com  Mon Feb 16 11:24:01 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 16 Feb 2015 11:24:01 -0500
Subject: [keycloak-dev] SOAP security with Keycloak
In-Reply-To: <3a9d6173d99e4c7dac19324a66cd071e@BLM-MAIL01P.l1id.local>
References: <3a9d6173d99e4c7dac19324a66cd071e@BLM-MAIL01P.l1id.local>
Message-ID: <54E219A1.6000408@redhat.com>

We don't have anything yet.  It will probably be awhile unless the 
community helps out.  You might be able to use it like you would any 
other REST service.  SOAP still is sent over HTTP...I guess it depends 
on your SOAP stack.

On 2/16/2015 11:13 AM, Ryvlin, Andrey wrote:
> Hi,
>
> I am evaluating Keycloak server for my project and securing REST APIs
> and Web applications was very easy.
>
> Now I have a task to secure some SOAP endpoints
>
> Is it possible to do it with Keycloak? If so, what?s the best practice?
>
> Thanks?
>
> -----------------
>
> Andrey Ryvlin
>
> Principal Software Engineer
>
> Phone: 952-979-8492
>
> 5705 W Old Shakopee Road, Suite 100
>
> Bloomington, MN 55437 USA
>
> ARyvlin at MorphoTrust.com <mailto:ARyvlin at MorphoTrust.com>
>
> www.MorphoTrust.com <http://www.morphotrust.com/>
>
> cid:image003.jpg at 01CFF75A.60542BC0
>
>
> ------------------------------------------------------------------------
>
> This message is only for the use of the intended recipient and may
> contain information that is CONFIDENTIAL and PROPRIETARY to MorphoTrust
> USA, Inc. If you are not the intended recipient, please erase all copies
> of the message and its attachments and notify the sender immediately.
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From mposolda at redhat.com  Mon Feb 16 16:34:21 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 16 Feb 2015 22:34:21 +0100
Subject: [keycloak-dev] Kerberos progress
In-Reply-To: <54DCD81E.4020800@redhat.com>
References: <54DBADB2.40300@redhat.com> <54DBBDD2.3050509@redhat.com>
	<54DC6934.4070902@redhat.com> <54DCAF51.90509@redhat.com>
	<54DCD649.3050107@redhat.com> <54DCD81E.4020800@redhat.com>
Message-ID: <54E2625D.1020506@redhat.com>

Still thinking whether it's better to use federation SPI or identity 
broker SPI for kerberos integration. I am finally much more inclined to 
Federation SPI ;-)

Identity broker SPI is more flexible and allow to do things like link 
user account to 2 different kerberos servers. But is this real usecase 
in practice? Also is linking of accounts in Account management by user 
himself useful in production? It seems that admins, who integrate with 
Kerberos, will have similar infrastructure like LDAP (predefined set of 
users with hardwired user accounts to kerberos usernames) and there is 
likely no need to allow account linking like with social networks.

It looks that very common usecase for Kerberos will be integration with 
LDAP account. So same user is linked to both Kerberos and LDAP. Using 
Federation SPI means that single federation link is used for both LDAP 
and Kerberos (assuming that LDAPFederationProvider itself has support 
for Kerberos credentials). It makes the whole integration easier.

So today I prototyped Kerberos integration with Federation SPI approach. 
It's not yet pushed to master. What I did is:

* Add new "kerberos" UserCredentialModel type

* Add new method on UserProvider with signature 
"CredentialValidationOutput validCredentials(RealmModel realm, 
UserCredentialModel... input)" . New method is needed as with 
Kerberos/SPNEGO you don't know the user, who is going to authenticate. 
CredentialValidationOutput encapsulates info about authenticated user 
(or responseToken if additional handshake is needed)

* I am going to add support for "kerberos" credential into 
LDAPFederationProvider, so LDAP user can authenticate either with 
username/password (login screen) or with Kerberos ticket. Environments, 
which have Kerberos backed by user data in LDAP (MSAD domains etc) will 
use this one.

* I've added separate KerberosFederationProvider, which is for 
use-cases, when users have standalone Kerberos servers *not* backed by 
LDAP.

* HTTP handshakes are handled from single place in 
OpenIDConnectService.loginPage method. I will need to add it to 
SamlService, but that should be easy. I still think that earlier or 
later, we would need to improve authentication pluggability and do some 
filters/interceptors to handle it...

Anyone has strong feeling about federation vs. broker? If not, I will 
likely continue and push federation based Kerberos integration around 
tomorrow.

Marek


On 12.2.2015 17:43, Bill Burke wrote:
> Ok, sounds good.  Don't worry about filters and interceptors.  We'll 
> see where the community takes us.
>
> On 2/12/2015 11:35 AM, Marek Posolda wrote:
>> I see your point. I still believe that kerberos better suits Broker SPI
>> for few reasons.
>>
>> - Broker SPI allows update profile after first login, which is required
>> for Kerberos (Kerberos doesn't have a way to provision firstName,
>> lastName or email).
>>
>> - Also it allows link your account with kerberos in account management.
>>
>> - Finally broker allows to expose 3rd party token/credential from broker
>> authentication to be shared to application and used for further calls.
>> For Kerberos, this is achieved through credential delegation and we need
>> to support as JBoss Negotiation supported it too (AFAIK Keycloak should
>> support all the usecases previously supported by Picketlink+JBoss
>> Negotiation).
>>
>> Only thing is automatic login without displaying login screen, but it
>> makes sense to easily extend our broker SPI to allow configuring this.
>> Usually people will require automatic login with Kerberos, but maybe not
>> always. For example realm can be configured with 2 kerberos servers. In
>> this case login page may be displayed and user will need to click on
>> "Login with kerberos 1" or "Login with kerberos 2" according to which
>> kerberos domain he has ticket.
>>
>> For handling more protections, maybe we should add something like
>> AuthenticationFilter or AuthenticationInterceptor? That will allow
>> people to configure chain of more interceptors and configure that user
>> is required to login with all of Kerberos ticket, Facebook password and
>> TOTP? We can also add flags like PAM (Required, Requisite, Sufficient 
>> etc)?
>>
>> Marek
>>
>> On 12.2.2015 14:49, Bill Burke wrote:
>>> I'm just trying to figure out where does the Broker SPI end and the
>>> User Federation SPI begin?  And wondering if our SPIs can be unified,
>>> simplified, or refactored.  For example, how would client-cert auth be
>>> implemented?  Like Kerberos, its a credential that is checked prior to
>>> displaying a login screen.
>>>
>>> Another thing, does the broker SPI allow you to still require extra
>>> credentials supplied by Keycloak instead of the brokered IDP?
>>>
>>> We just have to make these SPIs intuitive enough so that users know
>>> what they need to do and simple enough to extend Keycloak.
>>>
>>> On 2/12/2015 3:49 AM, Marek Posolda wrote:
>>>> On 11.2.2015 21:38, Bill Burke wrote:
>>>>> I am not understanding how you have implemented this.  Wouldn't
>>>>> kerberos
>>>>> just be an authentication mechanism that the auth server uses?  I 
>>>>> don't
>>>>> understand why you would want special configuration at the adapter
>>>>> level.  This should all be configured at the auth server so that the
>>>>> application doesn't have to know if kerberos is used or not.
>>>> Yeah, ok. I've mentioned the option #3 (Adding parameter to adapter
>>>> config) just for case if you guys think that this is a way to go. 
>>>> But I
>>>> don't like much as well ;-)
>>>>>
>>>>> Wouldn't it be:
>>>>>
>>>>> 1. App does regular SAML or OIDC redirect to auth server
>>>>> 2. Auth server checks to see if realm supports kerberos
>>>>> 3. Sends 401 + HTML
>>>>> 4. Browser sends back ticket
>>>>> 5. Auth server verifies ticket, creates SAML or OIDC response and
>>>>> redirects browser back to application
>>>> Sure, that's exactly what I am doing. Application uses just SAML or 
>>>> OIDC
>>>> for communication with auth-server. It doesn't know how it is
>>>> authenticated. Existing brokering mechanism handles this very well and
>>>> that's why I am using it.
>>>>
>>>> Only thing in your flow, which I don't yet have, is step 2. Currently
>>>> login screen is always displayed and user needs to click on "Login 
>>>> with
>>>> Kerberos" . Addressing it is what I am asking about.
>>>>
>>>> I can either do it automatically (realm will always use kerberos 
>>>> broker
>>>> when it is available) or allow to configure it (Redirect automatically
>>>> to kerberos just when it's configured as default broker). I think that
>>>> allowing to configure is better way as it allows more flexibility.
>>>>
>>>> Marek
>>>>>
>>>>>
>>>>>
>>>>> On 2/11/2015 2:29 PM, Marek Posolda wrote:
>>>>>> I've already pushed initial version of Kerberos broker. It uses
>>>>>> existing
>>>>>> brokering mechanism from Pedro and allows to login users to KC with
>>>>>> SPNEGO/Kerberos token. There are still things I need to address 
>>>>>> (more
>>>>>> testing + automated testing, Credentials delegation etc).
>>>>>>
>>>>>> I have a question about automatic Kerberos login without displaying
>>>>>> login form. Browsers support this very well - when server returns
>>>>>> response with status 401, header "WWW-Authenticate: Negotiate" and
>>>>>> HTML
>>>>>> with login page, browsers are able to handle it and:
>>>>>>
>>>>>> * In case that user has Kerberos ticket, browser will send it 
>>>>>> back in
>>>>>> additional HTTP request with "Authorization: Negotiate <ticket>" 
>>>>>> . In
>>>>>> this case login form is not displayed to user
>>>>>>
>>>>>> * In case that user hasn't Kerberos ticket, browser just displays 
>>>>>> HTML
>>>>>> with login form
>>>>>>
>>>>>> You can try https://saml.redhat.com/idp/ to see what I mean.
>>>>>>
>>>>>> JBoss Negotiation supports this, so I believe we should address it
>>>>>> too.
>>>>>>
>>>>>>
>>>>>> I have some ideas how to do it:
>>>>>>
>>>>>> 1) Configure default broker on server side per-realm. If used, login
>>>>>> request will automatically redirect to configured broker. It may be
>>>>>> also
>>>>>> possible to override default broker per client?
>>>>>>
>>>>>> 2) Add on/off switch to broker configuration to specify if it
>>>>>> should be
>>>>>> default or not
>>>>>>
>>>>>> 3) Leverage existing "k_idp_hint" parameter. I am thinking about
>>>>>> adding
>>>>>> option "idp_hint" into AdapterConfig . In case it's configured,
>>>>>> adapter
>>>>>> will use it for attach "k_idp_hint" parameter to login request. This
>>>>>> will allow per-application configuration and no changes on 
>>>>>> auth-server
>>>>>> side, but all applications will need to use it in their adapter
>>>>>> configuration.
>>>>>>
>>>>>> 4) Don't configure anything, but hard-code that Kerberos will be
>>>>>> always
>>>>>> used by default if configured. Basically add new method "boolean
>>>>>> isDefault()" to IDentityProvider interface. It will return "true" 
>>>>>> for
>>>>>> Kerberos impl and "false" for other broker types we currently have.
>>>>>>
>>>>>> I like (1) or (2) most. Thoughts?
>>>>>>
>>>>>> Marek
>>>>>>
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>
>>>
>>
>


From bburke at redhat.com  Mon Feb 16 16:52:12 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 16 Feb 2015 16:52:12 -0500
Subject: [keycloak-dev] Kerberos progress
In-Reply-To: <54E2625D.1020506@redhat.com>
References: <54DBADB2.40300@redhat.com> <54DBBDD2.3050509@redhat.com>
	<54DC6934.4070902@redhat.com> <54DCAF51.90509@redhat.com>
	<54DCD649.3050107@redhat.com> <54DCD81E.4020800@redhat.com>
	<54E2625D.1020506@redhat.com>
Message-ID: <54E2668C.5010003@redhat.com>



On 2/16/2015 4:34 PM, Marek Posolda wrote:
> Still thinking whether it's better to use federation SPI or identity
> broker SPI for kerberos integration. I am finally much more inclined to
> Federation SPI ;-)
>

That's why I brought it up before...I wasn't sure what the right SPI to 
use would be, or if our SPIs needed to improve and be refactored.  Maybe 
the answer is use both??? *shrug*

I don't know if this makes sense, but a kerberos broker would import 
users from information from the kerberos ticket.  A Kerberos Federation 
Provider interacts directly with an LDAP server to provide a more 
complete integration point???  I don't know...just thinking.  I don't 
know enough about kerberos or how people want to use it with us to make 
a decision.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From mposolda at redhat.com  Tue Feb 17 03:59:56 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 17 Feb 2015 09:59:56 +0100
Subject: [keycloak-dev] Kerberos progress
In-Reply-To: <54E2668C.5010003@redhat.com>
References: <54DBADB2.40300@redhat.com> <54DBBDD2.3050509@redhat.com>
	<54DC6934.4070902@redhat.com> <54DCAF51.90509@redhat.com>
	<54DCD649.3050107@redhat.com> <54DCD81E.4020800@redhat.com>
	<54E2625D.1020506@redhat.com> <54E2668C.5010003@redhat.com>
Message-ID: <54E3030C.5020100@redhat.com>

On 16.2.2015 22:52, Bill Burke wrote:
>
>
> On 2/16/2015 4:34 PM, Marek Posolda wrote:
>> Still thinking whether it's better to use federation SPI or identity
>> broker SPI for kerberos integration. I am finally much more inclined to
>> Federation SPI ;-)
>>
>
> That's why I brought it up before...I wasn't sure what the right SPI 
> to use would be, or if our SPIs needed to improve and be refactored.  
> Maybe the answer is use both??? *shrug*
Yeah, the fact you pointed it and some feedback from users in JIRA 
https://issues.jboss.org/browse/KEYCLOAK-828 makes me think that 
federation suits better:-) Was also thinking about keep both, but as you 
mentioned few months back, every possibility we offer also adds 
complexity and potential error-proness.

ATM I am more to use federation SPI. And Kerberos identity broker can be 
restored later if there are usecases from community?

>
> I don't know if this makes sense, but a kerberos broker would import 
> users from information from the kerberos ticket.  A Kerberos 
> Federation Provider interacts directly with an LDAP server to provide 
> a more complete integration point???  I don't know...just thinking.  I 
> don't know enough about kerberos or how people want to use it with us 
> to make a decision.

ATM I am thinking about 2 possibilities:

* Integration with Kerberos not backed by LDAP: For this case there will 
be KerberosFederationProvider. Kerberos ticket contains just username, 
so once user authenticated for the first time, he will usually need to 
update a profile (that would be configurable on/off switch). Same 
required action "Update_profile", which is used for social/identity 
brokering, will be used for this too

* Integration with Kerberos backed by LDAP: For this case, 
LDAPFederationProvider will be enhanced. There will be configuration 
possibility on LDAP provider screen "Allow kerberos authentication". 
When user is first authenticated with Kerberos ticket, his profile data 
(firstName, lastName, email ...) are imported from LDAP. There is single 
federation link, so once I authenticate with Kerberos principal or with 
username/password from LDAP, Keycloak knows that it's same user.

Marek

From mposolda at redhat.com  Tue Feb 17 04:11:29 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 17 Feb 2015 10:11:29 +0100
Subject: [keycloak-dev] Kerberos progress
In-Reply-To: <54E2668C.5010003@redhat.com>
References: <54DBADB2.40300@redhat.com> <54DBBDD2.3050509@redhat.com>
	<54DC6934.4070902@redhat.com> <54DCAF51.90509@redhat.com>
	<54DCD649.3050107@redhat.com> <54DCD81E.4020800@redhat.com>
	<54E2625D.1020506@redhat.com> <54E2668C.5010003@redhat.com>
Message-ID: <54E305C1.1000903@redhat.com>

For improving SPIs, I think the point where we need to improve is 
pluggable authentication. People should be able to introduce new 
authentication mechanisms without need to change anything in core code 
inside "services" module. Also with possibility to introduce complex 
authentication flow or simplify existing. For example:

* some admins may want to always authenticate with Kerberos ticket 
(never display login screen).

* Some others allow either kerberos or password.

* Some others may want: (kerberos OR password OR facebook) AND totp.

There might be pluggable authentication interceptor, which has access to 
HTTP request/response and can either redirect to send response back or 
continue to other interceptors in chain. ClientSessionModel will have 
list of required "authentication actions" once it's created and those 
are configurable by user. For example there can be actions configured 
like this:
* kerberos sufficient
* password sufficient
* facebook sufficient
* totp          required

for the last case I mentioned. The 
AuthenticationManager.nextActionAfterAuthentication is triggered only if 
ClientSessionModel contains flags that required authentication 
mechanisms were met. Maybe we would need to improve LoginFormsProvider 
to easily allow people to plug their own login screens.

One example from the usecase mentioned in Kerberos JIRA: Some 
applications authenticate against SecureID. Some applications require 
multi factor authentication. Kerberos + SecureID + OTP that is sent to 
Phone or email address

Marek

On 16.2.2015 22:52, Bill Burke wrote:
>
>
> On 2/16/2015 4:34 PM, Marek Posolda wrote:
>> Still thinking whether it's better to use federation SPI or identity
>> broker SPI for kerberos integration. I am finally much more inclined to
>> Federation SPI ;-)
>>
>
> That's why I brought it up before...I wasn't sure what the right SPI 
> to use would be, or if our SPIs needed to improve and be refactored.  
> Maybe the answer is use both??? *shrug*
>
> I don't know if this makes sense, but a kerberos broker would import 
> users from information from the kerberos ticket.  A Kerberos 
> Federation Provider interacts directly with an LDAP server to provide 
> a more complete integration point???  I don't know...just thinking.  I 
> don't know enough about kerberos or how people want to use it with us 
> to make a decision.
>


From giriraj.sharma27 at gmail.com  Tue Feb 17 04:12:41 2015
From: giriraj.sharma27 at gmail.com (Giriraj Sharma)
Date: Tue, 17 Feb 2015 14:42:41 +0530
Subject: [keycloak-dev] Keycloak realm specific Certificate Management System
Message-ID: <CAB5vuUy8Qw0JXqhbza5ih7zSUWm6FoFZg167pbukPj9=Sum+Xw@mail.gmail.com>

Hi,

To support *first/initial cut of certificate management *for realm users,
we can have  keys and X509 Certificate generation for each individual user
at the time of its creation. This will imply for realm admin too.

While viewing an individual user for any specific realm in administrative
console, we can have Keys View in addition to Attributes, Credentials, Role
Mappings and Sessions. Keys View (UI) will let user retrieve, validate,
revoke, renew(revoke+generate) and delete(optional) his keys/Certificates.

If it makes sense, I shall start working around it.

-- 
Giriraj Sharma,
Department of Computer Science
National Institute of Technology Hamirpur
Himachal Pradesh, India
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150217/0637b787/attachment.html 

From stian at redhat.com  Tue Feb 17 07:24:16 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 17 Feb 2015 07:24:16 -0500 (EST)
Subject: [keycloak-dev] How to use Nodejs application with Keycloak
In-Reply-To: <CAPLm6j+sCwuwTsT1Y9WApbLAcv1k1TD3+XYVeJCE9KL=bifsOQ@mail.gmail.com>
References: <CAPLm6j+sCwuwTsT1Y9WApbLAcv1k1TD3+XYVeJCE9KL=bifsOQ@mail.gmail.com>
Message-ID: <1934044782.8258481.1424175856332.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Jae Choi" <jaekun.choi at gmail.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Saturday, February 7, 2015 10:38:44 AM
> Subject: [keycloak-dev] How to use Nodejs application with Keycloak
> 
> Hi all,
> 
> I would like to use Nodejs application with Keycloak for dealing with
> AngularJS as a auth provider.

For AngularJS application use keycloak.js

For Node.js services use https://github.com/keycloak/keycloak-nodejs

> 
> How do I do this? Does it mean I need to deploy Node.js application to
> Wildfly?

No, deploy your NodeJS app in the usual way. The Keycloak server should be a separate process.

> 
> If so, is there any documentation for this process?
> 
> 
> Thanks,
> 
> --
> Kind Regards,
> Jae Choi
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From stian at redhat.com  Tue Feb 17 07:30:33 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 17 Feb 2015 07:30:33 -0500 (EST)
Subject: [keycloak-dev] Share Applications from Master Realm to Others
In-Reply-To: <CAKBbQsiU4iP_ea-4s0waWHTigcJR1SBDGqq+-m-L2VqoMxMsYw@mail.gmail.com>
References: <CAKBbQsiU4iP_ea-4s0waWHTigcJR1SBDGqq+-m-L2VqoMxMsYw@mail.gmail.com>
Message-ID: <956610647.8261068.1424176233690.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Nicholas Padilla" <nicholas at monstersoftwarellc.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, February 9, 2015 6:25:42 PM
> Subject: [keycloak-dev] Share Applications from Master Realm to Others
> 
> Hello,
> 
> I was wondering if it was possible to share Applications from the Master
> realm. If we wanted to support multiple realms but those realms always using
> a subset of the Applications defined in Master, we didn't want to have to
> redefine them. We would just like to allow a Child Realm to be able to be
> given access to an Application in Master, at a particular role level. Please
> let me know if you have any questions.

No, I'm afraid this is not possible

> 
> Thanks!
> 
> Nicholas Padilla
> www.monstersoftwarellc.com
> 
> ?Problems cannot be solved by the same level of thinking that created them.?
> ? Learn from yesterday, live for today, hope for tomorrow. The important
> thing is not to stop questioning. ?
> 
> Albert Einstein
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Tue Feb 17 08:01:21 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 17 Feb 2015 08:01:21 -0500 (EST)
Subject: [keycloak-dev] Kerberos progress
In-Reply-To: <54E305C1.1000903@redhat.com>
References: <54DBADB2.40300@redhat.com> <54DC6934.4070902@redhat.com>
	<54DCAF51.90509@redhat.com> <54DCD649.3050107@redhat.com>
	<54DCD81E.4020800@redhat.com> <54E2625D.1020506@redhat.com>
	<54E2668C.5010003@redhat.com> <54E305C1.1000903@redhat.com>
Message-ID: <1331160839.8286953.1424178081295.JavaMail.zimbra@redhat.com>

I reckon we'll have to improve SPIs for KC 2.0 in either case, so it's not so important to get it perfect this time around IMO.

Authentication/brokering/federation SPIs will be the most important to get right for KC 2.0. We need them to not to be to complex, but yet flexible and powerful enough.

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Tuesday, February 17, 2015 10:11:29 AM
> Subject: Re: [keycloak-dev] Kerberos progress
> 
> For improving SPIs, I think the point where we need to improve is
> pluggable authentication. People should be able to introduce new
> authentication mechanisms without need to change anything in core code
> inside "services" module. Also with possibility to introduce complex
> authentication flow or simplify existing. For example:
> 
> * some admins may want to always authenticate with Kerberos ticket
> (never display login screen).
> 
> * Some others allow either kerberos or password.
> 
> * Some others may want: (kerberos OR password OR facebook) AND totp.
> 
> There might be pluggable authentication interceptor, which has access to
> HTTP request/response and can either redirect to send response back or
> continue to other interceptors in chain. ClientSessionModel will have
> list of required "authentication actions" once it's created and those
> are configurable by user. For example there can be actions configured
> like this:
> * kerberos sufficient
> * password sufficient
> * facebook sufficient
> * totp          required
> 
> for the last case I mentioned. The
> AuthenticationManager.nextActionAfterAuthentication is triggered only if
> ClientSessionModel contains flags that required authentication
> mechanisms were met. Maybe we would need to improve LoginFormsProvider
> to easily allow people to plug their own login screens.
> 
> One example from the usecase mentioned in Kerberos JIRA: Some
> applications authenticate against SecureID. Some applications require
> multi factor authentication. Kerberos + SecureID + OTP that is sent to
> Phone or email address
> 
> Marek
> 
> On 16.2.2015 22:52, Bill Burke wrote:
> >
> >
> > On 2/16/2015 4:34 PM, Marek Posolda wrote:
> >> Still thinking whether it's better to use federation SPI or identity
> >> broker SPI for kerberos integration. I am finally much more inclined to
> >> Federation SPI ;-)
> >>
> >
> > That's why I brought it up before...I wasn't sure what the right SPI
> > to use would be, or if our SPIs needed to improve and be refactored.
> > Maybe the answer is use both??? *shrug*
> >
> > I don't know if this makes sense, but a kerberos broker would import
> > users from information from the kerberos ticket.  A Kerberos
> > Federation Provider interacts directly with an LDAP server to provide
> > a more complete integration point???  I don't know...just thinking.  I
> > don't know enough about kerberos or how people want to use it with us
> > to make a decision.
> >
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Tue Feb 17 08:15:55 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 17 Feb 2015 08:15:55 -0500 (EST)
Subject: [keycloak-dev] advanced claim support
In-Reply-To: <54D4DE80.1070107@redhat.com>
References: <54D4DE80.1070107@redhat.com>
Message-ID: <909129479.8309547.1424178955069.JavaMail.zimbra@redhat.com>

Forgive my lateness in replying to this, I've been busy playing with kids and drinking cask ales ;)

With regards to internationalization we should support that by using keys in place of values. We'll provide a default set of keys including translations to some languages. Additional keys (and translations) can be supplied through themes. We should also add a mechanism to do the translations through the admin console.

As an example, someone not using internationalization could create a claim:

* id: 'first_name'
* name: 'First name'

While someone using internationalization would create a claim with a key instead:

* id: 'first_name'
* name: 'user.first_name'

We can do a lot in the admin console to make it easier for users to deal with internationalization. For example when internationalization is enabled internationalized fields such as 'name' becomes a button that opens a modal panel that allows selecting an existing key, creating a new key, adding translations, etc.).

A few questions with regards to claim support:

* What's the purpose of the .css type for UserProfileType?
* What about validation?
* Am I the only one that find the term 'claim' a bit to specialist? I prefer custom user profiles and user profile attributes, to claims and claim types.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, February 6, 2015 4:32:16 PM
> Subject: [keycloak-dev] advanced claim support
> 
> Wrote this awhile ago.  I'm starting on this now.  Discuss now, or
> forever hold your peace :)
> 
> Current UserModel.attributes will be used for internal bookkeeping only.
>    Going to add a new "UserProfileType", "UserProfileValue" (name TBD)
> type that contains:
> 
> UserProfileType:
> * id
> * name
> * .css type
> * type (bool, int, date, etc.)
> * boolean displayOnRegistrationPage
> 
> Question, do I need a .css id to plug in a value too?  How would we
> display the german label name for "phone"?
> 
> 
> UserProfileValue:
> * id
> * UserClaimType
> * String value
> 
> 
> OIDC clients will have a "Claim mapping" tab.  SAML clients will have an
> "Assertion Mapping" tab.  These tabs will be able to map from
> UserProfileValues to te appropriate claim/assertion and also be able to
> set up whether or not a claim should be added to token/assertion list.
> 
> ClientModel.claimMask will go away.  ClientModel will gain a list of
> ClaimMappingModel
> 
> * id
> * UserProfileType
> * String claimNameMapping
> 
> Might want to eventually add a "ClaimTransformerProvider" pluggin
> ability that can be attached to ClaimMappingModel...We might also want a
> "TokenTransformerProvider" plugin too that can intercept token/saml doc
> creation.  We'll see...
> 
> Bill
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Tue Feb 17 09:30:20 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 17 Feb 2015 09:30:20 -0500
Subject: [keycloak-dev] advanced claim support
In-Reply-To: <909129479.8309547.1424178955069.JavaMail.zimbra@redhat.com>
References: <54D4DE80.1070107@redhat.com>
	<909129479.8309547.1424178955069.JavaMail.zimbra@redhat.com>
Message-ID: <54E3507C.1000606@redhat.com>

Claims is turning out to be a bit more complicated.  There are a lot of 
standard claims that are not a simple mapping between a user attribute 
and the protocol's claim.  A perfect example is OIDC's "address" which 
is actually a JSON object, not a simple string value.

As far as layout and internationlization goes, IMO, this should all be 
done within themes.  Layouts should be done by extending a theme and 
specifying the attributes you want to manage (within registration and 
user console pages).  All the admin console should offer is editing 
theme property pages.  Why should it be done this way?

Again, a great example is 'address'.  Displaying an address is tricky 
because layout information is required.  You can't just generically 
generate a registration, admin console, or user profile page based on 
defined claim types.  If you did this you'd get something like this:

Country:
Street:
Mobile Phone:
Postal Code:
State or Province:

So, I think themes should be extended to support internationalization. 
Users should be required to extend themes to add the claim layouts they 
want.  Most will want to do this anyways.  Otherwise we'll be 
reinventing HTML inside of a data model.

On 2/17/2015 8:15 AM, Stian Thorgersen wrote:
> Forgive my lateness in replying to this, I've been busy playing with kids and drinking cask ales ;)
>
> With regards to internationalization we should support that by using keys in place of values. We'll provide a default set of keys including translations to some languages. Additional keys (and translations) can be supplied through themes. We should also add a mechanism to do the translations through the admin console.
>
> As an example, someone not using internationalization could create a claim:
>
> * id: 'first_name'
> * name: 'First name'
>
> While someone using internationalization would create a claim with a key instead:
>
> * id: 'first_name'
> * name: 'user.first_name'
>
> We can do a lot in the admin console to make it easier for users to deal with internationalization. For example when internationalization is enabled internationalized fields such as 'name' becomes a button that opens a modal panel that allows selecting an existing key, creating a new key, adding translations, etc.).
>
> A few questions with regards to claim support:
>
> * What's the purpose of the .css type for UserProfileType?
> * What about validation?
> * Am I the only one that find the term 'claim' a bit to specialist? I prefer custom user profiles and user profile attributes, to claims and claim types.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, February 6, 2015 4:32:16 PM
>> Subject: [keycloak-dev] advanced claim support
>>
>> Wrote this awhile ago.  I'm starting on this now.  Discuss now, or
>> forever hold your peace :)
>>
>> Current UserModel.attributes will be used for internal bookkeeping only.
>>     Going to add a new "UserProfileType", "UserProfileValue" (name TBD)
>> type that contains:
>>
>> UserProfileType:
>> * id
>> * name
>> * .css type
>> * type (bool, int, date, etc.)
>> * boolean displayOnRegistrationPage
>>
>> Question, do I need a .css id to plug in a value too?  How would we
>> display the german label name for "phone"?
>>
>>
>> UserProfileValue:
>> * id
>> * UserClaimType
>> * String value
>>
>>
>> OIDC clients will have a "Claim mapping" tab.  SAML clients will have an
>> "Assertion Mapping" tab.  These tabs will be able to map from
>> UserProfileValues to te appropriate claim/assertion and also be able to
>> set up whether or not a claim should be added to token/assertion list.
>>
>> ClientModel.claimMask will go away.  ClientModel will gain a list of
>> ClaimMappingModel
>>
>> * id
>> * UserProfileType
>> * String claimNameMapping
>>
>> Might want to eventually add a "ClaimTransformerProvider" pluggin
>> ability that can be attached to ClaimMappingModel...We might also want a
>> "TokenTransformerProvider" plugin too that can intercept token/saml doc
>> creation.  We'll see...
>>
>> Bill
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Tue Feb 17 09:54:33 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 17 Feb 2015 09:54:33 -0500 (EST)
Subject: [keycloak-dev] advanced claim support
In-Reply-To: <54E3507C.1000606@redhat.com>
References: <54D4DE80.1070107@redhat.com>
	<909129479.8309547.1424178955069.JavaMail.zimbra@redhat.com>
	<54E3507C.1000606@redhat.com>
Message-ID: <1751093789.8408393.1424184873224.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, February 17, 2015 3:30:20 PM
> Subject: Re: [keycloak-dev] advanced claim support
> 
> Claims is turning out to be a bit more complicated.  There are a lot of
> standard claims that are not a simple mapping between a user attribute
> and the protocol's claim.  A perfect example is OIDC's "address" which
> is actually a JSON object, not a simple string value.
> 
> As far as layout and internationlization goes, IMO, this should all be
> done within themes.  Layouts should be done by extending a theme and
> specifying the attributes you want to manage (within registration and
> user console pages).  All the admin console should offer is editing
> theme property pages.  Why should it be done this way?
> 
> Again, a great example is 'address'.  Displaying an address is tricky
> because layout information is required.  You can't just generically
> generate a registration, admin console, or user profile page based on
> defined claim types.  If you did this you'd get something like this:
> 
> Country:
> Street:
> Mobile Phone:
> Postal Code:
> State or Province:
> 
> So, I think themes should be extended to support internationalization.
> Users should be required to extend themes to add the claim layouts they
> want.  Most will want to do this anyways.  Otherwise we'll be
> reinventing HTML inside of a data model.

Themes was always going to be the place to support internationalization. It's been designed with that in mind. We can improve on templates around this though. Currently a user has to override the whole template, but we could introduce the concept of widgets. This means that instead of overriding the whole registration page for an address the user can create an address widget template. However, that's probably something we can look at later. For now we just need to make the claims (including the complex claims such as address) available to the template.

What about the admin console though? We need some way of displaying and editing complex attributes there.

Some remaining questions:

* What's the purpose of the .css type on UserProfileType?
* What about validation?
* Am I the only one that find the term 'claim' a bit to specialist? I prefer custom user profiles and user profile attributes, to claims and claim types.

> 
> On 2/17/2015 8:15 AM, Stian Thorgersen wrote:
> > Forgive my lateness in replying to this, I've been busy playing with kids
> > and drinking cask ales ;)
> >
> > With regards to internationalization we should support that by using keys
> > in place of values. We'll provide a default set of keys including
> > translations to some languages. Additional keys (and translations) can be
> > supplied through themes. We should also add a mechanism to do the
> > translations through the admin console.
> >
> > As an example, someone not using internationalization could create a claim:
> >
> > * id: 'first_name'
> > * name: 'First name'
> >
> > While someone using internationalization would create a claim with a key
> > instead:
> >
> > * id: 'first_name'
> > * name: 'user.first_name'
> >
> > We can do a lot in the admin console to make it easier for users to deal
> > with internationalization. For example when internationalization is
> > enabled internationalized fields such as 'name' becomes a button that
> > opens a modal panel that allows selecting an existing key, creating a new
> > key, adding translations, etc.).
> >
> > A few questions with regards to claim support:
> >
> > * What's the purpose of the .css type for UserProfileType?
> > * What about validation?
> > * Am I the only one that find the term 'claim' a bit to specialist? I
> > prefer custom user profiles and user profile attributes, to claims and
> > claim types.
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, February 6, 2015 4:32:16 PM
> >> Subject: [keycloak-dev] advanced claim support
> >>
> >> Wrote this awhile ago.  I'm starting on this now.  Discuss now, or
> >> forever hold your peace :)
> >>
> >> Current UserModel.attributes will be used for internal bookkeeping only.
> >>     Going to add a new "UserProfileType", "UserProfileValue" (name TBD)
> >> type that contains:
> >>
> >> UserProfileType:
> >> * id
> >> * name
> >> * .css type
> >> * type (bool, int, date, etc.)
> >> * boolean displayOnRegistrationPage
> >>
> >> Question, do I need a .css id to plug in a value too?  How would we
> >> display the german label name for "phone"?
> >>
> >>
> >> UserProfileValue:
> >> * id
> >> * UserClaimType
> >> * String value
> >>
> >>
> >> OIDC clients will have a "Claim mapping" tab.  SAML clients will have an
> >> "Assertion Mapping" tab.  These tabs will be able to map from
> >> UserProfileValues to te appropriate claim/assertion and also be able to
> >> set up whether or not a claim should be added to token/assertion list.
> >>
> >> ClientModel.claimMask will go away.  ClientModel will gain a list of
> >> ClaimMappingModel
> >>
> >> * id
> >> * UserProfileType
> >> * String claimNameMapping
> >>
> >> Might want to eventually add a "ClaimTransformerProvider" pluggin
> >> ability that can be attached to ClaimMappingModel...We might also want a
> >> "TokenTransformerProvider" plugin too that can intercept token/saml doc
> >> creation.  We'll see...
> >>
> >> Bill
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Tue Feb 17 09:58:50 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 17 Feb 2015 09:58:50 -0500
Subject: [keycloak-dev] Keycloak realm specific Certificate Management
 System
In-Reply-To: <CAB5vuUy8Qw0JXqhbza5ih7zSUWm6FoFZg167pbukPj9=Sum+Xw@mail.gmail.com>
References: <CAB5vuUy8Qw0JXqhbza5ih7zSUWm6FoFZg167pbukPj9=Sum+Xw@mail.gmail.com>
Message-ID: <54E3572A.3050701@redhat.com>

I think that many companies will want to manage keypairs/certificates 
themselves.  I'm thinking that we'll want to have an option for users to 
set up client-certs themselves.  For example, think of OTP.  We have a 
switch that requires the user to set up OTP when then log in.  We could 
provide the same for client certs where the user uploads their 
certificate the first time they log in.

On 2/17/2015 4:12 AM, Giriraj Sharma wrote:
> Hi,
>
> To support *first/initial cut of certificate management *for realm
> users, we can have  keys and X509 Certificate generation for each
> individual user at the time of its creation. This will imply for realm
> admin too.
>
> While viewing an individual user for any specific realm in
> administrative console, we can have Keys View in addition to Attributes,
> Credentials, Role Mappings and Sessions. Keys View (UI) will let user
> retrieve, validate, revoke, renew(revoke+generate) and delete(optional)
> his keys/Certificates.
>
> If it makes sense, I shall start working around it.
>
> --
> Giriraj Sharma,
> Department of Computer Science
> National Institute of Technology Hamirpur
> Himachal Pradesh, India
>
>
> _______________________________________________
> 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 Feb 17 10:07:15 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 17 Feb 2015 10:07:15 -0500 (EST)
Subject: [keycloak-dev] Keycloak realm specific Certificate Management
	System
In-Reply-To: <CAB5vuUy8Qw0JXqhbza5ih7zSUWm6FoFZg167pbukPj9=Sum+Xw@mail.gmail.com>
References: <CAB5vuUy8Qw0JXqhbza5ih7zSUWm6FoFZg167pbukPj9=Sum+Xw@mail.gmail.com>
Message-ID: <986312516.8421098.1424185635260.JavaMail.zimbra@redhat.com>

This doesn't sound like what I had in mind for the GSoC project. Also, this is more implementation details than the higher level design document I was expecting initially.

Main requirements I had in mind for GSoC project was:

* Ability to generate/upload CA certificate
* Ability to generate SSL certificates for servers, including automatic certificate management (https://github.com/letsencrypt/acme-spec)
* Ability to download CA certficiate or self-signed certificates. This could be to import into browser, into truststore for clients, etc.
* Ability to revoke certificates
* Ability to view/manage certificates through admin console

What you're proposing sounds more like just what we'd need to authenticating users/clients with certificates.

----- Original Message -----
> From: "Giriraj Sharma" <giriraj.sharma27 at gmail.com>
> To: keycloak-dev at lists.jboss.org
> Cc: "Stian T" <stian at redhat.com>
> Sent: Tuesday, February 17, 2015 10:12:41 AM
> Subject: Keycloak realm specific Certificate Management System
> 
> Hi,
> 
> To support *first/initial cut of certificate management *for realm users,
> we can have  keys and X509 Certificate generation for each individual user
> at the time of its creation. This will imply for realm admin too.
> 
> While viewing an individual user for any specific realm in administrative
> console, we can have Keys View in addition to Attributes, Credentials, Role
> Mappings and Sessions. Keys View (UI) will let user retrieve, validate,
> revoke, renew(revoke+generate) and delete(optional) his keys/Certificates.
> 
> If it makes sense, I shall start working around it.
> 
> --
> Giriraj Sharma,
> Department of Computer Science
> National Institute of Technology Hamirpur
> Himachal Pradesh, India
> 

From stian at redhat.com  Tue Feb 17 10:08:13 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 17 Feb 2015 10:08:13 -0500 (EST)
Subject: [keycloak-dev] Keycloak realm specific Certificate Management
 System
In-Reply-To: <54E3572A.3050701@redhat.com>
References: <CAB5vuUy8Qw0JXqhbza5ih7zSUWm6FoFZg167pbukPj9=Sum+Xw@mail.gmail.com>
	<54E3572A.3050701@redhat.com>
Message-ID: <1598646156.8421916.1424185693077.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, February 17, 2015 3:58:50 PM
> Subject: Re: [keycloak-dev] Keycloak realm specific Certificate Management System
> 
> I think that many companies will want to manage keypairs/certificates
> themselves.  I'm thinking that we'll want to have an option for users to
> set up client-certs themselves.  For example, think of OTP.  We have a
> switch that requires the user to set up OTP when then log in.  We could
> provide the same for client certs where the user uploads their
> certificate the first time they log in.

Aren't certs just for clients, and so wouldn't they upload/generate certs for an app through the admin console?

> 
> On 2/17/2015 4:12 AM, Giriraj Sharma wrote:
> > Hi,
> >
> > To support *first/initial cut of certificate management *for realm
> > users, we can have  keys and X509 Certificate generation for each
> > individual user at the time of its creation. This will imply for realm
> > admin too.
> >
> > While viewing an individual user for any specific realm in
> > administrative console, we can have Keys View in addition to Attributes,
> > Credentials, Role Mappings and Sessions. Keys View (UI) will let user
> > retrieve, validate, revoke, renew(revoke+generate) and delete(optional)
> > his keys/Certificates.
> >
> > If it makes sense, I shall start working around it.
> >
> > --
> > Giriraj Sharma,
> > Department of Computer Science
> > National Institute of Technology Hamirpur
> > Himachal Pradesh, India
> >
> >
> > _______________________________________________
> > 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  Tue Feb 17 10:08:47 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 17 Feb 2015 10:08:47 -0500
Subject: [keycloak-dev] advanced claim support
In-Reply-To: <1751093789.8408393.1424184873224.JavaMail.zimbra@redhat.com>
References: <54D4DE80.1070107@redhat.com>
	<909129479.8309547.1424178955069.JavaMail.zimbra@redhat.com>
	<54E3507C.1000606@redhat.com>
	<1751093789.8408393.1424184873224.JavaMail.zimbra@redhat.com>
Message-ID: <54E3597F.2020103@redhat.com>



On 2/17/2015 9:54 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, February 17, 2015 3:30:20 PM
>> Subject: Re: [keycloak-dev] advanced claim support
>>
>> Claims is turning out to be a bit more complicated.  There are a lot of
>> standard claims that are not a simple mapping between a user attribute
>> and the protocol's claim.  A perfect example is OIDC's "address" which
>> is actually a JSON object, not a simple string value.
>>
>> As far as layout and internationlization goes, IMO, this should all be
>> done within themes.  Layouts should be done by extending a theme and
>> specifying the attributes you want to manage (within registration and
>> user console pages).  All the admin console should offer is editing
>> theme property pages.  Why should it be done this way?
>>
>> Again, a great example is 'address'.  Displaying an address is tricky
>> because layout information is required.  You can't just generically
>> generate a registration, admin console, or user profile page based on
>> defined claim types.  If you did this you'd get something like this:
>>
>> Country:
>> Street:
>> Mobile Phone:
>> Postal Code:
>> State or Province:
>>
>> So, I think themes should be extended to support internationalization.
>> Users should be required to extend themes to add the claim layouts they
>> want.  Most will want to do this anyways.  Otherwise we'll be
>> reinventing HTML inside of a data model.
>
> Themes was always going to be the place to support internationalization. It's been designed with that in mind. We can improve on templates around this though. Currently a user has to override the whole template, but we could introduce the concept of widgets. This means that instead of overriding the whole registration page for an address the user can create an address widget template. However, that's probably something we can look at later. For now we just need to make the claims (including the complex claims such as address) available to the template.
>
> What about the admin console though? We need some way of displaying and editing complex attributes there.
>

So far my thought is that there will be a flag on the custom claim: 
"boolean rendered".  If true, then the admin console will generically 
render the HTML into input the claim.  For complex types, the admin 
console theme will be extended.  I might take the same approach for 
registration and user profile page.


> Some remaining questions:
>
> * What's the purpose of the .css type on UserProfileType?

Not applicable anymore.  It will not exist. :)

> * What about validation?

Only validation I will do is make sure that there is no scripting 
attacks going on.

> * Am I the only one that find the term 'claim' a bit to specialist? I prefer custom user profiles and user profile attributes, to claims and claim types.
>

Pedro seems to think that claim is a well understood term in the 
security community.  My only concern is that claim is more of a protocol 
term that a user attribute term.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Tue Feb 17 10:10:41 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 17 Feb 2015 10:10:41 -0500
Subject: [keycloak-dev] Keycloak realm specific Certificate Management
 System
In-Reply-To: <1598646156.8421916.1424185693077.JavaMail.zimbra@redhat.com>
References: <CAB5vuUy8Qw0JXqhbza5ih7zSUWm6FoFZg167pbukPj9=Sum+Xw@mail.gmail.com>
	<54E3572A.3050701@redhat.com>
	<1598646156.8421916.1424185693077.JavaMail.zimbra@redhat.com>
Message-ID: <54E359F1.8030807@redhat.com>



On 2/17/2015 10:08 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, February 17, 2015 3:58:50 PM
>> Subject: Re: [keycloak-dev] Keycloak realm specific Certificate Management System
>>
>> I think that many companies will want to manage keypairs/certificates
>> themselves.  I'm thinking that we'll want to have an option for users to
>> set up client-certs themselves.  For example, think of OTP.  We have a
>> switch that requires the user to set up OTP when then log in.  We could
>> provide the same for client certs where the user uploads their
>> certificate the first time they log in.
>
> Aren't certs just for clients, and so wouldn't they upload/generate certs for an app through the admin console?
>

I'm not sure.  That's the problem.  I just think that many companies 
might have their own certificate management systems.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Tue Feb 17 10:40:32 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 17 Feb 2015 10:40:32 -0500 (EST)
Subject: [keycloak-dev] advanced claim support
In-Reply-To: <54E3597F.2020103@redhat.com>
References: <54D4DE80.1070107@redhat.com>
	<909129479.8309547.1424178955069.JavaMail.zimbra@redhat.com>
	<54E3507C.1000606@redhat.com>
	<1751093789.8408393.1424184873224.JavaMail.zimbra@redhat.com>
	<54E3597F.2020103@redhat.com>
Message-ID: <10790651.8454053.1424187632076.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, February 17, 2015 4:08:47 PM
> Subject: Re: [keycloak-dev] advanced claim support
> 
> 
> 
> On 2/17/2015 9:54 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, February 17, 2015 3:30:20 PM
> >> Subject: Re: [keycloak-dev] advanced claim support
> >>
> >> Claims is turning out to be a bit more complicated.  There are a lot of
> >> standard claims that are not a simple mapping between a user attribute
> >> and the protocol's claim.  A perfect example is OIDC's "address" which
> >> is actually a JSON object, not a simple string value.
> >>
> >> As far as layout and internationlization goes, IMO, this should all be
> >> done within themes.  Layouts should be done by extending a theme and
> >> specifying the attributes you want to manage (within registration and
> >> user console pages).  All the admin console should offer is editing
> >> theme property pages.  Why should it be done this way?
> >>
> >> Again, a great example is 'address'.  Displaying an address is tricky
> >> because layout information is required.  You can't just generically
> >> generate a registration, admin console, or user profile page based on
> >> defined claim types.  If you did this you'd get something like this:
> >>
> >> Country:
> >> Street:
> >> Mobile Phone:
> >> Postal Code:
> >> State or Province:
> >>
> >> So, I think themes should be extended to support internationalization.
> >> Users should be required to extend themes to add the claim layouts they
> >> want.  Most will want to do this anyways.  Otherwise we'll be
> >> reinventing HTML inside of a data model.
> >
> > Themes was always going to be the place to support internationalization.
> > It's been designed with that in mind. We can improve on templates around
> > this though. Currently a user has to override the whole template, but we
> > could introduce the concept of widgets. This means that instead of
> > overriding the whole registration page for an address the user can create
> > an address widget template. However, that's probably something we can look
> > at later. For now we just need to make the claims (including the complex
> > claims such as address) available to the template.
> >
> > What about the admin console though? We need some way of displaying and
> > editing complex attributes there.
> >
> 
> So far my thought is that there will be a flag on the custom claim:
> "boolean rendered".  If true, then the admin console will generically
> render the HTML into input the claim.  For complex types, the admin
> console theme will be extended.  I might take the same approach for
> registration and user profile page.
> 
> 
> > Some remaining questions:
> >
> > * What's the purpose of the .css type on UserProfileType?
> 
> Not applicable anymore.  It will not exist. :)
> 
> > * What about validation?
> 
> Only validation I will do is make sure that there is no scripting
> attacks going on.

I guess we can add validation once you've finished this. We do need to add support for proper validation though (including custom validation), there's quite a lot of people that's asked for it.

> 
> > * Am I the only one that find the term 'claim' a bit to specialist? I
> > prefer custom user profiles and user profile attributes, to claims and
> > claim types.
> >
> 
> Pedro seems to think that claim is a well understood term in the
> security community.  My only concern is that claim is more of a protocol
> term that a user attribute term.

Are we not creating a OOTB security solution for the average developer rather than for security experts?

I agree claim is more a protocol/token term. IMO we should call it custom user profile and attributes. Of course when it comes to mapping user profiles to tokens it should be mapping attributes to claims.

> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From giriraj.sharma27 at gmail.com  Tue Feb 17 10:48:12 2015
From: giriraj.sharma27 at gmail.com (Giriraj Sharma)
Date: Tue, 17 Feb 2015 21:18:12 +0530
Subject: [keycloak-dev] Keycloak realm specific Certificate Management
	System
In-Reply-To: <54E359F1.8030807@redhat.com>
References: <CAB5vuUy8Qw0JXqhbza5ih7zSUWm6FoFZg167pbukPj9=Sum+Xw@mail.gmail.com>
	<54E3572A.3050701@redhat.com>
	<1598646156.8421916.1424185693077.JavaMail.zimbra@redhat.com>
	<54E359F1.8030807@redhat.com>
Message-ID: <CAB5vuUy5ByZUr2f4GJQkwYK-RAT04vsuNs5==mEA0bEtFBGwGA@mail.gmail.com>

Stian,

I more or less meant the same :)

*For the first/initial implementation:*

Consider a use case :-
*Company X uploads his keycloak-server.json to KC auth server.*
*As the user will upload/create a new realm, the realm will be initialized
by auto-generated keys/certificates.*

We do have keys tab in admin console for a realm. When admin will click
upon keys, he will be shown his auto-generated keys/certificates.
Now, *admin will have an option to either keep those keys/certs or else
delete them and upload his own*. It will provide upload/download
functionality. These keys/certs will represent CA key/certs.

Talking about users, each user will be initialized with auto-generated
keys/certs at the time of its creation.
While viewing an individual user for any specific realm in administrative
console, we can have Keys View in addition to Attributes, Credentials, Role
Mappings and Sessions.

*Keys View (UI) will initially show auto generated keys/cert to the user
where he can perform all CA operations.*
*Keys View (UI) will let user upload, download, retrieve, validate, revoke,
renew(revoke+generate) and delete(optional) his keys/Certificates*.

*Once first class requirements are done, we can look forward to*
* Ability to generate SSL certificates for servers, including automatic
certificate management (https://github.com/letsencrypt/acme-spec)




On Tue, Feb 17, 2015 at 8:40 PM, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 2/17/2015 10:08 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, February 17, 2015 3:58:50 PM
> >> Subject: Re: [keycloak-dev] Keycloak realm specific Certificate
> Management System
> >>
> >> I think that many companies will want to manage keypairs/certificates
> >> themselves.  I'm thinking that we'll want to have an option for users to
> >> set up client-certs themselves.  For example, think of OTP.  We have a
> >> switch that requires the user to set up OTP when then log in.  We could
> >> provide the same for client certs where the user uploads their
> >> certificate the first time they log in.
> >
> > Aren't certs just for clients, and so wouldn't they upload/generate
> certs for an app through the admin console?
> >
>
> I'm not sure.  That's the problem.  I just think that many companies
> might have their own certificate management systems.
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



-- 
Giriraj Sharma,
Department of Computer Science
National Institute of Technology Hamirpur
Himachal Pradesh, India
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150217/e2850d9f/attachment-0001.html 

From giriraj.sharma27 at gmail.com  Tue Feb 17 10:56:33 2015
From: giriraj.sharma27 at gmail.com (Giriraj Sharma)
Date: Tue, 17 Feb 2015 21:26:33 +0530
Subject: [keycloak-dev] Keycloak realm specific Certificate Management
	System
In-Reply-To: <CAB5vuUy5ByZUr2f4GJQkwYK-RAT04vsuNs5==mEA0bEtFBGwGA@mail.gmail.com>
References: <CAB5vuUy8Qw0JXqhbza5ih7zSUWm6FoFZg167pbukPj9=Sum+Xw@mail.gmail.com>
	<54E3572A.3050701@redhat.com>
	<1598646156.8421916.1424185693077.JavaMail.zimbra@redhat.com>
	<54E359F1.8030807@redhat.com>
	<CAB5vuUy5ByZUr2f4GJQkwYK-RAT04vsuNs5==mEA0bEtFBGwGA@mail.gmail.com>
Message-ID: <CAB5vuUwWdg2NXJ2aDjyGwk8uHX5ALzYhEZGDeTcxUo7ME+gZMA@mail.gmail.com>

*Once first class requirements are done, we can look forward to*
* Ability to generate SSL certificates for servers, including automatic
certificate management (https://github.com/letsencrypt/acme-spec)

On Tue, Feb 17, 2015 at 9:18 PM, Giriraj Sharma <giriraj.sharma27 at gmail.com>
wrote:

> Stian,
>
> I more or less meant the same :)
>
> *For the first/initial implementation:*
>
> Consider a use case :-
> *Company X uploads his keycloak-server.json to KC auth server.*
> *As the user will upload/create a new realm, the realm will be initialized
> by auto-generated keys/certificates.*
>
> We do have keys tab in admin console for a realm. When admin will click
> upon keys, he will be shown his auto-generated keys/certificates.
> Now, *admin will have an option to either keep those keys/certs or else
> delete them and upload his own*. It will provide upload/download
> functionality. These keys/certs will represent CA key/certs.
>
> Talking about users, each user will be initialized with auto-generated
> keys/certs at the time of its creation.
> While viewing an individual user for any specific realm in administrative
> console, we can have Keys View in addition to Attributes, Credentials, Role
> Mappings and Sessions.
>
> *Keys View (UI) will initially show auto generated keys/cert to the user
> where he can perform all CA operations.*
> *Keys View (UI) will let user upload, download, retrieve, validate,
> revoke, renew(revoke+generate) and delete(optional) his keys/Certificates*
> .
>
> *Once first class requirements are done, we can look forward to*
> * Ability to generate SSL certificates for servers, including automatic
> certificate management (https://github.com/letsencrypt/acme-spec)
>
>
>
>
> On Tue, Feb 17, 2015 at 8:40 PM, Bill Burke <bburke at redhat.com> wrote:
>
>>
>>
>> On 2/17/2015 10:08 AM, Stian Thorgersen wrote:
>> >
>> >
>> > ----- Original Message -----
>> >> From: "Bill Burke" <bburke at redhat.com>
>> >> To: keycloak-dev at lists.jboss.org
>> >> Sent: Tuesday, February 17, 2015 3:58:50 PM
>> >> Subject: Re: [keycloak-dev] Keycloak realm specific Certificate
>> Management System
>> >>
>> >> I think that many companies will want to manage keypairs/certificates
>> >> themselves.  I'm thinking that we'll want to have an option for users
>> to
>> >> set up client-certs themselves.  For example, think of OTP.  We have a
>> >> switch that requires the user to set up OTP when then log in.  We could
>> >> provide the same for client certs where the user uploads their
>> >> certificate the first time they log in.
>> >
>> > Aren't certs just for clients, and so wouldn't they upload/generate
>> certs for an app through the admin console?
>> >
>>
>> I'm not sure.  That's the problem.  I just think that many companies
>> might have their own certificate management systems.
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
> --
> Giriraj Sharma,
> Department of Computer Science
> National Institute of Technology Hamirpur
> Himachal Pradesh, India
>



-- 
Giriraj Sharma,
Department of Computer Science
National Institute of Technology Hamirpur
Himachal Pradesh, India
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150217/7cc9f688/attachment.html 

From gerbermichi at me.com  Tue Feb 17 14:54:03 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Tue, 17 Feb 2015 20:54:03 +0100
Subject: [keycloak-dev] denial-of-service (DoS)
Message-ID: <C9910E03-FFEB-4FEE-BA04-7ED40AC4F94B@me.com>

Hi all,

It?s very easy to produce an out of memory. Just make thousand of requests to the login page with a huge state parameter. 
Keycloak allocates a new ClientSessionEntity for each request and stores it with the given state parameter in a ConcurrentHashMap (if the MemUserSessionProvider is used).

Do you think it is necessary to create a new ClientSessionEntity before the user is authenticated?
Wouldn?t it be possible to pass all necessary information via URL parameters? Create a LoginToken similar to the IDToken, encrypt it with the realm private key, and add it to the url as parameter.

Best
Michael

From bburke at redhat.com  Tue Feb 17 19:16:41 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 17 Feb 2015 19:16:41 -0500
Subject: [keycloak-dev] denial-of-service (DoS)
In-Reply-To: <C9910E03-FFEB-4FEE-BA04-7ED40AC4F94B@me.com>
References: <C9910E03-FFEB-4FEE-BA04-7ED40AC4F94B@me.com>
Message-ID: <54E3D9E9.2000502@redhat.com>



On 2/17/2015 2:54 PM, Michael Gerber wrote:
> Hi all,
>
> It?s very easy to produce an out of memory. Just make thousand of requests to the login page with a huge state parameter.
> Keycloak allocates a new ClientSessionEntity for each request and stores it with the given state parameter in a ConcurrentHashMap (if the MemUserSessionProvider is used).
>
> Do you think it is necessary to create a new ClientSessionEntity before the user is authenticated?

Yes, the ClientSession stores information about the protocol used and 
information passed with the protocol.  State parameter and redirect URI 
has to be saved as it is revalidated when the client makes an access 
token request.

BTW, there's a lot of other things that are worse for DoS.  Specifically 
if you put in recommended password hashing iterations (20K), you could 
eat up the CPU quite easily too.

> Wouldn?t it be possible to pass all necessary information via URL parameters? Create a LoginToken similar to the IDToken, encrypt it with the realm private key, and add it to the url as parameter.
>

A better approach would be to limit the amount of concurrent login 
requests from a specific IP.



-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Tue Feb 17 19:50:17 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 17 Feb 2015 19:50:17 -0500
Subject: [keycloak-dev] denial-of-service (DoS)
In-Reply-To: <54E3D9E9.2000502@redhat.com>
References: <C9910E03-FFEB-4FEE-BA04-7ED40AC4F94B@me.com>
	<54E3D9E9.2000502@redhat.com>
Message-ID: <54E3E1C9.3060102@redhat.com>

I'll add this to the conversation:

Any Internet based application is vulnerable to DoS and there are a lot 
of existing solutions to help, i.e. Fail2Ban or any mature firewall or 
loadbalancing technology.  I'm not convinced we need to implement 
anything for DoS as IMO, organizations will already have something in 
place for this kind of stuff.

I kind of feel the same way with Brute force password hacking detection. 
  There's existing mature solutions out there that can read logs for 
failures and update firewall and load balancer rules dynamically.

On 2/17/2015 7:16 PM, Bill Burke wrote:
>
>
> On 2/17/2015 2:54 PM, Michael Gerber wrote:
>> Hi all,
>>
>> It?s very easy to produce an out of memory. Just make thousand of requests to the login page with a huge state parameter.
>> Keycloak allocates a new ClientSessionEntity for each request and stores it with the given state parameter in a ConcurrentHashMap (if the MemUserSessionProvider is used).
>>
>> Do you think it is necessary to create a new ClientSessionEntity before the user is authenticated?
>
> Yes, the ClientSession stores information about the protocol used and
> information passed with the protocol.  State parameter and redirect URI
> has to be saved as it is revalidated when the client makes an access
> token request.
>
> BTW, there's a lot of other things that are worse for DoS.  Specifically
> if you put in recommended password hashing iterations (20K), you could
> eat up the CPU quite easily too.
>
>> Wouldn?t it be possible to pass all necessary information via URL parameters? Create a LoginToken similar to the IDToken, encrypt it with the realm private key, and add it to the url as parameter.
>>
>
> A better approach would be to limit the amount of concurrent login
> requests from a specific IP.
>
>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Tue Feb 17 19:57:32 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 17 Feb 2015 19:57:32 -0500
Subject: [keycloak-dev] denial-of-service (DoS)
In-Reply-To: <C9910E03-FFEB-4FEE-BA04-7ED40AC4F94B@me.com>
References: <C9910E03-FFEB-4FEE-BA04-7ED40AC4F94B@me.com>
Message-ID: <54E3E37C.30902@redhat.com>



On 2/17/2015 2:54 PM, Michael Gerber wrote:
> Hi all,
>
> It?s very easy to produce an out of memory. Just make thousand of requests to the login page with a huge state parameter.
> Keycloak allocates a new ClientSessionEntity for each request and stores it with the given state parameter in a ConcurrentHashMap (if the MemUserSessionProvider is used).
>
> Do you think it is necessary to create a new ClientSessionEntity before the user is authenticated?
> Wouldn?t it be possible to pass all necessary information via URL parameters? Create a LoginToken similar to the IDToken, encrypt it with the realm private key, and add it to the url as parameter.
>

Err...one last thing.  ClientSession is just a glorified HttpSession. 
We used to create the client session later and pass everything by URL 
parameters.  That was when we only supported OIDC.  Now that Keycloak 
can support multiple login protocols within the same SSO session we need 
a way to store protocol information in a generic way.  We also need to 
remember the state the login is in as there may be multiple actions the 
user has to perform (verify email, update password, register an OTP 
generator, etc...) before they can finally go back to the application.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Tue Feb 17 22:46:29 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 17 Feb 2015 22:46:29 -0500
Subject: [keycloak-dev] denial-of-service (DoS)
In-Reply-To: <54E3E37C.30902@redhat.com>
References: <C9910E03-FFEB-4FEE-BA04-7ED40AC4F94B@me.com>
	<54E3E37C.30902@redhat.com>
Message-ID: <54E40B15.70005@redhat.com>

In summary....

Keycloak is not a firewall. DoS is just not something it should be 
dealing with.  Mature firewalls allow you to set a limit on the number 
of concurrent requests from a IP address.

On 2/17/2015 7:57 PM, Bill Burke wrote:
>
>
> On 2/17/2015 2:54 PM, Michael Gerber wrote:
>> Hi all,
>>
>> It?s very easy to produce an out of memory. Just make thousand of requests to the login page with a huge state parameter.
>> Keycloak allocates a new ClientSessionEntity for each request and stores it with the given state parameter in a ConcurrentHashMap (if the MemUserSessionProvider is used).
>>
>> Do you think it is necessary to create a new ClientSessionEntity before the user is authenticated?
>> Wouldn?t it be possible to pass all necessary information via URL parameters? Create a LoginToken similar to the IDToken, encrypt it with the realm private key, and add it to the url as parameter.
>>
>
> Err...one last thing.  ClientSession is just a glorified HttpSession.
> We used to create the client session later and pass everything by URL
> parameters.  That was when we only supported OIDC.  Now that Keycloak
> can support multiple login protocols within the same SSO session we need
> a way to store protocol information in a generic way.  We also need to
> remember the state the login is in as there may be multiple actions the
> user has to perform (verify email, update password, register an OTP
> generator, etc...) before they can finally go back to the application.
>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From sblanc at redhat.com  Wed Feb 18 02:03:11 2015
From: sblanc at redhat.com (Sebastien Blanc)
Date: Wed, 18 Feb 2015 08:03:11 +0100
Subject: [keycloak-dev] Liquibase errors on first startup with KC
	1.1.0-Final
In-Reply-To: <54DCBA26.9070408@redhat.com>
References: <54DCBA26.9070408@redhat.com>
Message-ID: <54E4392F.80102@redhat.com>

Hi !
Any ideas for this ?
Should I open a ticket ?
On 02/12/2015 03:35 PM, Sebastien Blanc wrote:
> Hi,
>
> We discovered recently that deploying Keycloak (the one that comes 
> with the AeroGear distro) on a "fresh" Wildfly 8.2  was generating 
> liquibase errors ( 
> https://gist.github.com/lholmquist/f031f7a3d88477ba81a7).
> Restarting the server removes these errors.
> Any idea ? Should I open a ticket ?
>
> It concerns 1.1.0-Final
>
> Sebi
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150218/42cd9f0c/attachment-0001.html 

From mposolda at redhat.com  Wed Feb 18 02:05:58 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 18 Feb 2015 08:05:58 +0100
Subject: [keycloak-dev] Liquibase errors on first startup with KC
	1.1.0-Final
In-Reply-To: <54E4392F.80102@redhat.com>
References: <54DCBA26.9070408@redhat.com> <54E4392F.80102@redhat.com>
Message-ID: <54E439D6.9070504@redhat.com>

Hi,

Is Keycloak DB and Aerogear DB points to same database? Will it help if 
you point keycloak DB to different one (ie. use different H2 directory 
for your datasource and KeycloakDS datasource) ?

Otherwise feel free to create JIRA with steps to reproduce.

Marek

On 18.2.2015 08:03, Sebastien Blanc wrote:
> Hi !
> Any ideas for this ?
> Should I open a ticket ?
> On 02/12/2015 03:35 PM, Sebastien Blanc wrote:
>> Hi,
>>
>> We discovered recently that deploying Keycloak (the one that comes 
>> with the AeroGear distro) on a "fresh" Wildfly 8.2  was generating 
>> liquibase errors ( 
>> https://gist.github.com/lholmquist/f031f7a3d88477ba81a7).
>> Restarting the server removes these errors.
>> Any idea ? Should I open a ticket ?
>>
>> It concerns 1.1.0-Final
>>
>> Sebi
>>
>>
>
>
>
> _______________________________________________
> 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/20150218/9378730c/attachment.html 

From bruno at abstractj.org  Wed Feb 18 03:43:22 2015
From: bruno at abstractj.org (Bruno Oliveira)
Date: Wed, 18 Feb 2015 00:43:22 -0800 (PST)
Subject: [keycloak-dev] Liquibase errors on first startup with KC
 1.1.0-Final
In-Reply-To: <54E439D6.9070504@redhat.com>
References: <54E439D6.9070504@redhat.com>
Message-ID: <1424249002486.b2dde26e@Nodemailer>

Hi Marek, answering you question, yes. I think what you suggested is the best approach, if that does not work we let you know.

Thanks a lot



?

abstractj
PGP: 0x84DC9914

On Wed, Feb 18, 2015 at 5:06 AM, Marek Posolda <mposolda at redhat.com>
wrote:

> Hi,
> Is Keycloak DB and Aerogear DB points to same database? Will it help if 
> you point keycloak DB to different one (ie. use different H2 directory 
> for your datasource and KeycloakDS datasource) ?
> Otherwise feel free to create JIRA with steps to reproduce.
> Marek
> On 18.2.2015 08:03, Sebastien Blanc wrote:
>> Hi !
>> Any ideas for this ?
>> Should I open a ticket ?
>> On 02/12/2015 03:35 PM, Sebastien Blanc wrote:
>>> Hi,
>>>
>>> We discovered recently that deploying Keycloak (the one that comes 
>>> with the AeroGear distro) on a "fresh" Wildfly 8.2  was generating 
>>> liquibase errors ( 
>>> https://gist.github.com/lholmquist/f031f7a3d88477ba81a7).
>>> Restarting the server removes these errors.
>>> Any idea ? Should I open a ticket ?
>>>
>>> It concerns 1.1.0-Final
>>>
>>> Sebi
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> 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/20150218/747b7c5d/attachment.html 

From mposolda at redhat.com  Wed Feb 18 05:00:33 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 18 Feb 2015 11:00:33 +0100
Subject: [keycloak-dev] Liquibase errors on first startup with KC
	1.1.0-Final
In-Reply-To: <1424249002486.b2dde26e@Nodemailer>
References: <54E439D6.9070504@redhat.com> <1424249002486.b2dde26e@Nodemailer>
Message-ID: <54E462C1.8030800@redhat.com>

Thanks Bruno,

Are you seeing this issue just for H2 or also for other databases? I 
mean it's probably ok if we have a requirement for H2 to use separate 
database (directory) as H2 is more like testing database.

However for MySQL and PostgreSQL is probably not nice, if Keycloak has 
requirement to have separate DB dedicated to Keycloak data and separate 
DB to other data. In this case, we would likely need to improve things IMO.

Marek


On 18.2.2015 09:43, Bruno Oliveira wrote:
> Hi Marek, answering you question, yes. I think what you suggested is 
> the best approach, if that does not work we let you know.
>
> Thanks a lot
>
> ?
>
> abstractj
> PGP: 0x84DC9914
>
>
> On Wed, Feb 18, 2015 at 5:06 AM, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     Hi,
>
>     Is Keycloak DB and Aerogear DB points to same database? Will it
>     help if you point keycloak DB to different one (ie. use different
>     H2 directory for your datasource and KeycloakDS datasource) ?
>
>     Otherwise feel free to create JIRA with steps to reproduce.
>
>     Marek
>
>     On 18.2.2015 08:03, Sebastien Blanc wrote:
>>     Hi !
>>     Any ideas for this ?
>>     Should I open a ticket ?
>>     On 02/12/2015 03:35 PM, Sebastien Blanc wrote:
>>>     Hi,
>>>
>>>     We discovered recently that deploying Keycloak (the one that
>>>     comes with the AeroGear distro) on a "fresh" Wildfly 8.2  was
>>>     generating liquibase errors (
>>>     https://gist.github.com/lholmquist/f031f7a3d88477ba81a7).
>>>     Restarting the server removes these errors.
>>>     Any idea ? Should I open a ticket ?
>>>
>>>     It concerns 1.1.0-Final
>>>
>>>     Sebi
>>>
>>>
>>
>>
>>
>>     _______________________________________________
>>     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/20150218/9d57952e/attachment.html 

From psilva at redhat.com  Wed Feb 18 07:09:25 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 18 Feb 2015 07:09:25 -0500 (EST)
Subject: [keycloak-dev] SOAP security with Keycloak
In-Reply-To: <54E219A1.6000408@redhat.com>
References: <3a9d6173d99e4c7dac19324a66cd071e@BLM-MAIL01P.l1id.local>
	<54E219A1.6000408@redhat.com>
Message-ID: <417000979.15133849.1424261365681.JavaMail.zimbra@redhat.com>

As Bill said, there is no OOTB support for SOAP security.

However, I think you can use WS-Security to communicate tokens to your services and have some JAX-WS handler or something that knows how to validate this token and create a security context for the user before actually invoking your services.

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: keycloak-dev at lists.jboss.org
Sent: Monday, February 16, 2015 2:24:01 PM
Subject: Re: [keycloak-dev] SOAP security with Keycloak

We don't have anything yet.  It will probably be awhile unless the 
community helps out.  You might be able to use it like you would any 
other REST service.  SOAP still is sent over HTTP...I guess it depends 
on your SOAP stack.

On 2/16/2015 11:13 AM, Ryvlin, Andrey wrote:
> Hi,
>
> I am evaluating Keycloak server for my project and securing REST APIs
> and Web applications was very easy.
>
> Now I have a task to secure some SOAP endpoints
>
> Is it possible to do it with Keycloak? If so, what?s the best practice?
>
> Thanks?
>
> -----------------
>
> Andrey Ryvlin
>
> Principal Software Engineer
>
> Phone: 952-979-8492
>
> 5705 W Old Shakopee Road, Suite 100
>
> Bloomington, MN 55437 USA
>
> ARyvlin at MorphoTrust.com <mailto:ARyvlin at MorphoTrust.com>
>
> www.MorphoTrust.com <http://www.morphotrust.com/>
>
> cid:image003.jpg at 01CFF75A.60542BC0
>
>
> ------------------------------------------------------------------------
>
> This message is only for the use of the intended recipient and may
> contain information that is CONFIDENTIAL and PROPRIETARY to MorphoTrust
> USA, Inc. If you are not the intended recipient, please erase all copies
> of the message and its attachments and notify the sender immediately.
>
>
> _______________________________________________
> 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 psilva at redhat.com  Wed Feb 18 08:35:15 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 18 Feb 2015 08:35:15 -0500 (EST)
Subject: [keycloak-dev] From 1.2->2.0
In-Reply-To: <54E1F942.3090600@redhat.com>
References: <54E0CB70.8040208@redhat.com>
	<1287447405.13146075.1424087333088.JavaMail.zimbra@redhat.com>
	<54E1F942.3090600@redhat.com>
Message-ID: <821525547.15171226.1424266515819.JavaMail.zimbra@redhat.com>

When are you planning to move PL SAML code to KC (at least types and parsers) ? The issue I mentioned will require a release and update of PL dependency in KC. Want to avoid that every time we find a similar issue.

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: "Pedro Igor Silva" <psilva at redhat.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Monday, February 16, 2015 12:05:54 PM
Subject: Re: [keycloak-dev] From 1.2->2.0

I want to refactor the Builders I wrote so they can be user consumable. 
  What I want to have is a SAML SPI in which the SPI interface is passed 
a Builder.  Then the SPI plugin can modify the document however they 
want.  We'll need something similar for OIDC.

On 2/16/2015 6:48 AM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Sunday, February 15, 2015 2:38:08 PM
>> Subject: [keycloak-dev] From 1.2->2.0
>>
>> I think we still have a few major features to implement for 1.2 and
>> maybe 1.3.  After this I'd like to focus on Keycloak 2.0 things like:
>>
>> * Improving and nailing down our SPIs
>> * Splitting up code into private and public models so we can restrict
>> what APIs/SPIs we want to commercially support
>> * Pulling in and refactoring PL Federation
>
> I've an issue [1] in the SAML parsers that needs a fix. I don't know what are your plans for this, but I think we can start moving PL SAML types and parsers to KC ? Do you want/need a refactoring for them ?
>
> Or the refactoring you always talk about is around the SAML processing logic ? Such as handlers, etc ...
>
> [1] https://issues.jboss.org/browse/KEYCLOAK-883
>
>> * Consolidating and improving our admin console UI
>>
>> Really starting improving the core of Keycloak knowing that Keycloak 2.0
>> is what we're going to be supporting commercially for years and years
>> going forward.
>> --
>> 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 aryvlin at morphotrust.com  Wed Feb 18 09:24:32 2015
From: aryvlin at morphotrust.com (Ryvlin, Andrey)
Date: Wed, 18 Feb 2015 14:24:32 +0000
Subject: [keycloak-dev] SOAP security with Keycloak
In-Reply-To: <417000979.15133849.1424261365681.JavaMail.zimbra@redhat.com>
References: <3a9d6173d99e4c7dac19324a66cd071e@BLM-MAIL01P.l1id.local>
	<54E219A1.6000408@redhat.com>
	<417000979.15133849.1424261365681.JavaMail.zimbra@redhat.com>
Message-ID: <8540601e64b0458da5d850fd465a7692@BLM-MAIL01P.l1id.local>

What Keycloak API can use to do login programmatically  and validate token? Do you have any examples?

Thanks?
-----------------


-----Original Message-----
From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Pedro Igor Silva
Sent: Wednesday, February 18, 2015 6:09 AM
To: Bill Burke
Cc: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] SOAP security with Keycloak

As Bill said, there is no OOTB support for SOAP security.

However, I think you can use WS-Security to communicate tokens to your services and have some JAX-WS handler or something that knows how to validate this token and create a security context for the user before actually invoking your services.

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: keycloak-dev at lists.jboss.org
Sent: Monday, February 16, 2015 2:24:01 PM
Subject: Re: [keycloak-dev] SOAP security with Keycloak

We don't have anything yet.  It will probably be awhile unless the community helps out.  You might be able to use it like you would any other REST service.  SOAP still is sent over HTTP...I guess it depends on your SOAP stack.

On 2/16/2015 11:13 AM, Ryvlin, Andrey wrote:
> Hi,
>
> I am evaluating Keycloak server for my project and securing REST APIs
> and Web applications was very easy.
>
> Now I have a task to secure some SOAP endpoints
>
> Is it possible to do it with Keycloak? If so, what?s the best practice?
>
> Thanks?
>
> -----------------
>
> Andrey Ryvlin
>
> Principal Software Engineer
>
> Phone: 952-979-8492
>
> 5705 W Old Shakopee Road, Suite 100
>
> Bloomington, MN 55437 USA
>
> ARyvlin at MorphoTrust.com <mailto:ARyvlin at MorphoTrust.com>
>
> www.MorphoTrust.com <http://www.morphotrust.com/>
>
> cid:image003.jpg at 01CFF75A.60542BC0
>
>
> ----------------------------------------------------------------------
> --
>
> This message is only for the use of the intended recipient and may
> contain information that is CONFIDENTIAL and PROPRIETARY to
> MorphoTrust USA, Inc. If you are not the intended recipient, please
> erase all copies of the message and its attachments and notify the sender immediately.
>
>
> _______________________________________________
> 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

________________________________

This message is only for the use of the intended recipient and may contain information that is CONFIDENTIAL and PROPRIETARY to MorphoTrust USA, Inc. If you are not the intended recipient, please erase all copies of the message and its attachments and notify the sender immediately.


From psilva at redhat.com  Wed Feb 18 09:41:30 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 18 Feb 2015 09:41:30 -0500 (EST)
Subject: [keycloak-dev] SOAP security with Keycloak
In-Reply-To: <8540601e64b0458da5d850fd465a7692@BLM-MAIL01P.l1id.local>
References: <3a9d6173d99e4c7dac19324a66cd071e@BLM-MAIL01P.l1id.local>
	<54E219A1.6000408@redhat.com>
	<417000979.15133849.1424261365681.JavaMail.zimbra@redhat.com>
	<8540601e64b0458da5d850fd465a7692@BLM-MAIL01P.l1id.local>
Message-ID: <846554397.15222207.1424270490653.JavaMail.zimbra@redhat.com>

There is a 

/auth/realms/{realm}/protocol/openid-connect/validate?access_token={your_token}

endpoint. You can try it out.

However, I can not see it in Admin Client. I think we should add this endpoint there.

----- Original Message -----
From: "Andrey Ryvlin" <aryvlin at morphotrust.com>
To: "Pedro Igor Silva" <psilva at redhat.com>, "Bill Burke" <bburke at redhat.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Wednesday, February 18, 2015 12:24:32 PM
Subject: RE: SOAP security with Keycloak

What Keycloak API can use to do login programmatically  and validate token? Do you have any examples?

Thanks?
-----------------


-----Original Message-----
From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Pedro Igor Silva
Sent: Wednesday, February 18, 2015 6:09 AM
To: Bill Burke
Cc: keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] SOAP security with Keycloak

As Bill said, there is no OOTB support for SOAP security.

However, I think you can use WS-Security to communicate tokens to your services and have some JAX-WS handler or something that knows how to validate this token and create a security context for the user before actually invoking your services.

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: keycloak-dev at lists.jboss.org
Sent: Monday, February 16, 2015 2:24:01 PM
Subject: Re: [keycloak-dev] SOAP security with Keycloak

We don't have anything yet.  It will probably be awhile unless the community helps out.  You might be able to use it like you would any other REST service.  SOAP still is sent over HTTP...I guess it depends on your SOAP stack.

On 2/16/2015 11:13 AM, Ryvlin, Andrey wrote:
> Hi,
>
> I am evaluating Keycloak server for my project and securing REST APIs
> and Web applications was very easy.
>
> Now I have a task to secure some SOAP endpoints
>
> Is it possible to do it with Keycloak? If so, what?s the best practice?
>
> Thanks?
>
> -----------------
>
> Andrey Ryvlin
>
> Principal Software Engineer
>
> Phone: 952-979-8492
>
> 5705 W Old Shakopee Road, Suite 100
>
> Bloomington, MN 55437 USA
>
> ARyvlin at MorphoTrust.com <mailto:ARyvlin at MorphoTrust.com>
>
> www.MorphoTrust.com <http://www.morphotrust.com/>
>
> cid:image003.jpg at 01CFF75A.60542BC0
>
>
> ----------------------------------------------------------------------
> --
>
> This message is only for the use of the intended recipient and may
> contain information that is CONFIDENTIAL and PROPRIETARY to
> MorphoTrust USA, Inc. If you are not the intended recipient, please
> erase all copies of the message and its attachments and notify the sender immediately.
>
>
> _______________________________________________
> 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

________________________________

This message is only for the use of the intended recipient and may contain information that is CONFIDENTIAL and PROPRIETARY to MorphoTrust USA, Inc. If you are not the intended recipient, please erase all copies of the message and its attachments and notify the sender immediately.


From bburke at redhat.com  Wed Feb 18 10:03:08 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 18 Feb 2015 10:03:08 -0500
Subject: [keycloak-dev] SOAP security with Keycloak
In-Reply-To: <846554397.15222207.1424270490653.JavaMail.zimbra@redhat.com>
References: <3a9d6173d99e4c7dac19324a66cd071e@BLM-MAIL01P.l1id.local>
	<54E219A1.6000408@redhat.com>
	<417000979.15133849.1424261365681.JavaMail.zimbra@redhat.com>
	<8540601e64b0458da5d850fd465a7692@BLM-MAIL01P.l1id.local>
	<846554397.15222207.1424270490653.JavaMail.zimbra@redhat.com>
Message-ID: <54E4A9AC.3030505@redhat.com>

For plain Java org.keycloak.RSATokenVerifier.verifyToken API works too.

On 2/18/2015 9:41 AM, Pedro Igor Silva wrote:
> There is a
>
> /auth/realms/{realm}/protocol/openid-connect/validate?access_token={your_token}
>
> endpoint. You can try it out.
>
> However, I can not see it in Admin Client. I think we should add this endpoint there.
>
> ----- Original Message -----
> From: "Andrey Ryvlin" <aryvlin at morphotrust.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>, "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, February 18, 2015 12:24:32 PM
> Subject: RE: SOAP security with Keycloak
>
> What Keycloak API can use to do login programmatically  and validate token? Do you have any examples?
>
> Thanks?
> -----------------
>
>
> -----Original Message-----
> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Pedro Igor Silva
> Sent: Wednesday, February 18, 2015 6:09 AM
> To: Bill Burke
> Cc: keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] SOAP security with Keycloak
>
> As Bill said, there is no OOTB support for SOAP security.
>
> However, I think you can use WS-Security to communicate tokens to your services and have some JAX-WS handler or something that knows how to validate this token and create a security context for the user before actually invoking your services.
>
> ----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, February 16, 2015 2:24:01 PM
> Subject: Re: [keycloak-dev] SOAP security with Keycloak
>
> We don't have anything yet.  It will probably be awhile unless the community helps out.  You might be able to use it like you would any other REST service.  SOAP still is sent over HTTP...I guess it depends on your SOAP stack.
>
> On 2/16/2015 11:13 AM, Ryvlin, Andrey wrote:
>> Hi,
>>
>> I am evaluating Keycloak server for my project and securing REST APIs
>> and Web applications was very easy.
>>
>> Now I have a task to secure some SOAP endpoints
>>
>> Is it possible to do it with Keycloak? If so, what?s the best practice?
>>
>> Thanks?
>>
>> -----------------
>>
>> Andrey Ryvlin
>>
>> Principal Software Engineer
>>
>> Phone: 952-979-8492
>>
>> 5705 W Old Shakopee Road, Suite 100
>>
>> Bloomington, MN 55437 USA
>>
>> ARyvlin at MorphoTrust.com <mailto:ARyvlin at MorphoTrust.com>
>>
>> www.MorphoTrust.com <http://www.morphotrust.com/>
>>
>> cid:image003.jpg at 01CFF75A.60542BC0
>>
>>
>> ----------------------------------------------------------------------
>> --
>>
>> This message is only for the use of the intended recipient and may
>> contain information that is CONFIDENTIAL and PROPRIETARY to
>> MorphoTrust USA, Inc. If you are not the intended recipient, please
>> erase all copies of the message and its attachments and notify the sender immediately.
>>
>>
>> _______________________________________________
>> 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
>
> ________________________________
>
> This message is only for the use of the intended recipient and may contain information that is CONFIDENTIAL and PROPRIETARY to MorphoTrust USA, Inc. If you are not the intended recipient, please erase all copies of the message and its attachments and notify the sender immediately.
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From aryvlin at morphotrust.com  Wed Feb 18 10:06:23 2015
From: aryvlin at morphotrust.com (Ryvlin, Andrey)
Date: Wed, 18 Feb 2015 15:06:23 +0000
Subject: [keycloak-dev] SOAP security with Keycloak
In-Reply-To: <54E4A9AC.3030505@redhat.com>
References: <3a9d6173d99e4c7dac19324a66cd071e@BLM-MAIL01P.l1id.local>
	<54E219A1.6000408@redhat.com>
	<417000979.15133849.1424261365681.JavaMail.zimbra@redhat.com>
	<8540601e64b0458da5d850fd465a7692@BLM-MAIL01P.l1id.local>
	<846554397.15222207.1424270490653.JavaMail.zimbra@redhat.com>
	<54E4A9AC.3030505@redhat.com>
Message-ID: <96b57c720a7d4a03a617da0450a26ba5@BLM-MAIL01P.l1id.local>

That'll work,
 and what's endpoint to obtain token?

Thanks!!



-----Original Message-----
From: Bill Burke [mailto:bburke at redhat.com] 
Sent: Wednesday, February 18, 2015 9:03 AM
To: Pedro Igor Silva; Ryvlin, Andrey
Cc: keycloak-dev at lists.jboss.org
Subject: Re: SOAP security with Keycloak

For plain Java org.keycloak.RSATokenVerifier.verifyToken API works too.

On 2/18/2015 9:41 AM, Pedro Igor Silva wrote:
> There is a
>
> /auth/realms/{realm}/protocol/openid-connect/validate?access_token={yo
> ur_token}
>
> endpoint. You can try it out.
>
> However, I can not see it in Admin Client. I think we should add this endpoint there.
>
> ----- Original Message -----
> From: "Andrey Ryvlin" <aryvlin at morphotrust.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>, "Bill Burke" 
> <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, February 18, 2015 12:24:32 PM
> Subject: RE: SOAP security with Keycloak
>
> What Keycloak API can use to do login programmatically  and validate token? Do you have any examples?
>
> Thanks?
> -----------------
>
>
> -----Original Message-----
> From: keycloak-dev-bounces at lists.jboss.org 
> [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Pedro Igor 
> Silva
> Sent: Wednesday, February 18, 2015 6:09 AM
> To: Bill Burke
> Cc: keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] SOAP security with Keycloak
>
> As Bill said, there is no OOTB support for SOAP security.
>
> However, I think you can use WS-Security to communicate tokens to your services and have some JAX-WS handler or something that knows how to validate this token and create a security context for the user before actually invoking your services.
>
> ----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, February 16, 2015 2:24:01 PM
> Subject: Re: [keycloak-dev] SOAP security with Keycloak
>
> We don't have anything yet.  It will probably be awhile unless the community helps out.  You might be able to use it like you would any other REST service.  SOAP still is sent over HTTP...I guess it depends on your SOAP stack.
>
> On 2/16/2015 11:13 AM, Ryvlin, Andrey wrote:
>> Hi,
>>
>> I am evaluating Keycloak server for my project and securing REST APIs 
>> and Web applications was very easy.
>>
>> Now I have a task to secure some SOAP endpoints
>>
>> Is it possible to do it with Keycloak? If so, what?s the best practice?
>>
>> Thanks?
>>
>> -----------------
>>
>> Andrey Ryvlin
>>
>> Principal Software Engineer
>>
>> Phone: 952-979-8492
>>
>> 5705 W Old Shakopee Road, Suite 100
>>
>> Bloomington, MN 55437 USA
>>
>> ARyvlin at MorphoTrust.com <mailto:ARyvlin at MorphoTrust.com>
>>
>> www.MorphoTrust.com <http://www.morphotrust.com/>
>>
>> cid:image003.jpg at 01CFF75A.60542BC0
>>
>>
>> ---------------------------------------------------------------------
>> -
>> --
>>
>> This message is only for the use of the intended recipient and may 
>> contain information that is CONFIDENTIAL and PROPRIETARY to 
>> MorphoTrust USA, Inc. If you are not the intended recipient, please 
>> erase all copies of the message and its attachments and notify the sender immediately.
>>
>>
>> _______________________________________________
>> 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
>
> ________________________________
>
> This message is only for the use of the intended recipient and may contain information that is CONFIDENTIAL and PROPRIETARY to MorphoTrust USA, Inc. If you are not the intended recipient, please erase all copies of the message and its attachments and notify the sender immediately.
>

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


From psilva at redhat.com  Wed Feb 18 10:35:31 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 18 Feb 2015 10:35:31 -0500 (EST)
Subject: [keycloak-dev] SOAP security with Keycloak
In-Reply-To: <96b57c720a7d4a03a617da0450a26ba5@BLM-MAIL01P.l1id.local>
References: <3a9d6173d99e4c7dac19324a66cd071e@BLM-MAIL01P.l1id.local>
	<54E219A1.6000408@redhat.com>
	<417000979.15133849.1424261365681.JavaMail.zimbra@redhat.com>
	<8540601e64b0458da5d850fd465a7692@BLM-MAIL01P.l1id.local>
	<846554397.15222207.1424270490653.JavaMail.zimbra@redhat.com>
	<54E4A9AC.3030505@redhat.com>
	<96b57c720a7d4a03a617da0450a26ba5@BLM-MAIL01P.l1id.local>
Message-ID: <961169964.15263108.1424273731801.JavaMail.zimbra@redhat.com>

If your application (eg.: client consuming your SOAP layer) is using our adapters, you can obtain the 
token from either typecasting the user Principal to KeycloakPrincipal 
and navigating to the KeycloakSecurityContext interface.  The 
KeycloakSecurityContext interface is also available within the 
HttpServletRequest attribute

     KeycloakSecurityContext session = (KeycloakSecurityContext) 
request.getAttribute(KeycloakSecurityContext.class.getName());

----- Original Message -----
From: "Andrey Ryvlin" <aryvlin at morphotrust.com>
To: "Bill Burke" <bburke at redhat.com>, "Pedro Igor Silva" <psilva at redhat.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Wednesday, February 18, 2015 1:06:23 PM
Subject: RE: SOAP security with Keycloak

That'll work,
 and what's endpoint to obtain token?

Thanks!!



-----Original Message-----
From: Bill Burke [mailto:bburke at redhat.com] 
Sent: Wednesday, February 18, 2015 9:03 AM
To: Pedro Igor Silva; Ryvlin, Andrey
Cc: keycloak-dev at lists.jboss.org
Subject: Re: SOAP security with Keycloak

For plain Java org.keycloak.RSATokenVerifier.verifyToken API works too.

On 2/18/2015 9:41 AM, Pedro Igor Silva wrote:
> There is a
>
> /auth/realms/{realm}/protocol/openid-connect/validate?access_token={yo
> ur_token}
>
> endpoint. You can try it out.
>
> However, I can not see it in Admin Client. I think we should add this endpoint there.
>
> ----- Original Message -----
> From: "Andrey Ryvlin" <aryvlin at morphotrust.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>, "Bill Burke" 
> <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, February 18, 2015 12:24:32 PM
> Subject: RE: SOAP security with Keycloak
>
> What Keycloak API can use to do login programmatically  and validate token? Do you have any examples?
>
> Thanks?
> -----------------
>
>
> -----Original Message-----
> From: keycloak-dev-bounces at lists.jboss.org 
> [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Pedro Igor 
> Silva
> Sent: Wednesday, February 18, 2015 6:09 AM
> To: Bill Burke
> Cc: keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] SOAP security with Keycloak
>
> As Bill said, there is no OOTB support for SOAP security.
>
> However, I think you can use WS-Security to communicate tokens to your services and have some JAX-WS handler or something that knows how to validate this token and create a security context for the user before actually invoking your services.
>
> ----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, February 16, 2015 2:24:01 PM
> Subject: Re: [keycloak-dev] SOAP security with Keycloak
>
> We don't have anything yet.  It will probably be awhile unless the community helps out.  You might be able to use it like you would any other REST service.  SOAP still is sent over HTTP...I guess it depends on your SOAP stack.
>
> On 2/16/2015 11:13 AM, Ryvlin, Andrey wrote:
>> Hi,
>>
>> I am evaluating Keycloak server for my project and securing REST APIs 
>> and Web applications was very easy.
>>
>> Now I have a task to secure some SOAP endpoints
>>
>> Is it possible to do it with Keycloak? If so, what?s the best practice?
>>
>> Thanks?
>>
>> -----------------
>>
>> Andrey Ryvlin
>>
>> Principal Software Engineer
>>
>> Phone: 952-979-8492
>>
>> 5705 W Old Shakopee Road, Suite 100
>>
>> Bloomington, MN 55437 USA
>>
>> ARyvlin at MorphoTrust.com <mailto:ARyvlin at MorphoTrust.com>
>>
>> www.MorphoTrust.com <http://www.morphotrust.com/>
>>
>> cid:image003.jpg at 01CFF75A.60542BC0
>>
>>
>> ---------------------------------------------------------------------
>> -
>> --
>>
>> This message is only for the use of the intended recipient and may 
>> contain information that is CONFIDENTIAL and PROPRIETARY to 
>> MorphoTrust USA, Inc. If you are not the intended recipient, please 
>> erase all copies of the message and its attachments and notify the sender immediately.
>>
>>
>> _______________________________________________
>> 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
>
> ________________________________
>
> This message is only for the use of the intended recipient and may contain information that is CONFIDENTIAL and PROPRIETARY to MorphoTrust USA, Inc. If you are not the intended recipient, please erase all copies of the message and its attachments and notify the sender immediately.
>

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


From aryvlin at morphotrust.com  Wed Feb 18 10:49:45 2015
From: aryvlin at morphotrust.com (Ryvlin, Andrey)
Date: Wed, 18 Feb 2015 15:49:45 +0000
Subject: [keycloak-dev] SOAP security with Keycloak
In-Reply-To: <961169964.15263108.1424273731801.JavaMail.zimbra@redhat.com>
References: <3a9d6173d99e4c7dac19324a66cd071e@BLM-MAIL01P.l1id.local>
	<54E219A1.6000408@redhat.com>
	<417000979.15133849.1424261365681.JavaMail.zimbra@redhat.com>
	<8540601e64b0458da5d850fd465a7692@BLM-MAIL01P.l1id.local>
	<846554397.15222207.1424270490653.JavaMail.zimbra@redhat.com>
	<54E4A9AC.3030505@redhat.com>
	<96b57c720a7d4a03a617da0450a26ba5@BLM-MAIL01P.l1id.local>
	<961169964.15263108.1424273731801.JavaMail.zimbra@redhat.com>
Message-ID: <a6c56a491a7348e1ada93c372f9f2db7@BLM-MAIL01P.l1id.local>

I don't know what the SOAP consumer will be. What I was thinking is to create a request interceptor where I can get user credentials from SOAP Header.
Then I need access to the realm to authenticate user, get roles and do authorization. 

Thanks?
-----------------




-----Original Message-----
From: Pedro Igor Silva [mailto:psilva at redhat.com] 
Sent: Wednesday, February 18, 2015 9:36 AM
To: Ryvlin, Andrey
Cc: Bill Burke; keycloak-dev at lists.jboss.org
Subject: Re: SOAP security with Keycloak

If your application (eg.: client consuming your SOAP layer) is using our adapters, you can obtain the token from either typecasting the user Principal to KeycloakPrincipal and navigating to the KeycloakSecurityContext interface.  The KeycloakSecurityContext interface is also available within the HttpServletRequest attribute

     KeycloakSecurityContext session = (KeycloakSecurityContext) request.getAttribute(KeycloakSecurityContext.class.getName());

----- Original Message -----
From: "Andrey Ryvlin" <aryvlin at morphotrust.com>
To: "Bill Burke" <bburke at redhat.com>, "Pedro Igor Silva" <psilva at redhat.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Wednesday, February 18, 2015 1:06:23 PM
Subject: RE: SOAP security with Keycloak

That'll work,
 and what's endpoint to obtain token?

Thanks!!



-----Original Message-----
From: Bill Burke [mailto:bburke at redhat.com]
Sent: Wednesday, February 18, 2015 9:03 AM
To: Pedro Igor Silva; Ryvlin, Andrey
Cc: keycloak-dev at lists.jboss.org
Subject: Re: SOAP security with Keycloak

For plain Java org.keycloak.RSATokenVerifier.verifyToken API works too.

On 2/18/2015 9:41 AM, Pedro Igor Silva wrote:
> There is a
>
> /auth/realms/{realm}/protocol/openid-connect/validate?access_token={yo
> ur_token}
>
> endpoint. You can try it out.
>
> However, I can not see it in Admin Client. I think we should add this endpoint there.
>
> ----- Original Message -----
> From: "Andrey Ryvlin" <aryvlin at morphotrust.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>, "Bill Burke" 
> <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, February 18, 2015 12:24:32 PM
> Subject: RE: SOAP security with Keycloak
>
> What Keycloak API can use to do login programmatically  and validate token? Do you have any examples?
>
> Thanks?
> -----------------
>
>
> -----Original Message-----
> From: keycloak-dev-bounces at lists.jboss.org
> [mailto:keycloak-dev-bounces at lists.jboss.org] On Behalf Of Pedro Igor 
> Silva
> Sent: Wednesday, February 18, 2015 6:09 AM
> To: Bill Burke
> Cc: keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] SOAP security with Keycloak
>
> As Bill said, there is no OOTB support for SOAP security.
>
> However, I think you can use WS-Security to communicate tokens to your services and have some JAX-WS handler or something that knows how to validate this token and create a security context for the user before actually invoking your services.
>
> ----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, February 16, 2015 2:24:01 PM
> Subject: Re: [keycloak-dev] SOAP security with Keycloak
>
> We don't have anything yet.  It will probably be awhile unless the community helps out.  You might be able to use it like you would any other REST service.  SOAP still is sent over HTTP...I guess it depends on your SOAP stack.
>
> On 2/16/2015 11:13 AM, Ryvlin, Andrey wrote:
>> Hi,
>>
>> I am evaluating Keycloak server for my project and securing REST APIs 
>> and Web applications was very easy.
>>
>> Now I have a task to secure some SOAP endpoints
>>
>> Is it possible to do it with Keycloak? If so, what?s the best practice?
>>
>> Thanks?
>>
>> -----------------
>>
>> Andrey Ryvlin
>>
>> Principal Software Engineer
>>
>> Phone: 952-979-8492
>>
>> 5705 W Old Shakopee Road, Suite 100
>>
>> Bloomington, MN 55437 USA
>>
>> ARyvlin at MorphoTrust.com <mailto:ARyvlin at MorphoTrust.com>
>>
>> www.MorphoTrust.com <http://www.morphotrust.com/>
>>
>> cid:image003.jpg at 01CFF75A.60542BC0
>>
>>
>> ---------------------------------------------------------------------
>> -
>> --
>>
>> This message is only for the use of the intended recipient and may 
>> contain information that is CONFIDENTIAL and PROPRIETARY to 
>> MorphoTrust USA, Inc. If you are not the intended recipient, please 
>> erase all copies of the message and its attachments and notify the sender immediately.
>>
>>
>> _______________________________________________
>> 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
>
> ________________________________
>
> This message is only for the use of the intended recipient and may contain information that is CONFIDENTIAL and PROPRIETARY to MorphoTrust USA, Inc. If you are not the intended recipient, please erase all copies of the message and its attachments and notify the sender immediately.
>

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


From bburke at redhat.com  Wed Feb 18 15:41:29 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 18 Feb 2015 15:41:29 -0500
Subject: [keycloak-dev] From 1.2->2.0
In-Reply-To: <821525547.15171226.1424266515819.JavaMail.zimbra@redhat.com>
References: <54E0CB70.8040208@redhat.com>
	<1287447405.13146075.1424087333088.JavaMail.zimbra@redhat.com>
	<54E1F942.3090600@redhat.com>
	<821525547.15171226.1424266515819.JavaMail.zimbra@redhat.com>
Message-ID: <54E4F8F9.5030507@redhat.com>

That will be my next task.  Currently I'm focused on claims which will 
be done this week or next.

I want to bring in PL SAML code soon, because it effects claim mapping. 
  I'm writing an SPI so that the admin can write a protocol mapper that 
can change the SAML document however they like.

On 2/18/2015 8:35 AM, Pedro Igor Silva wrote:
> When are you planning to move PL SAML code to KC (at least types and parsers) ? The issue I mentioned will require a release and update of PL dependency in KC. Want to avoid that every time we find a similar issue.
>
> ----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, February 16, 2015 12:05:54 PM
> Subject: Re: [keycloak-dev] From 1.2->2.0
>
> I want to refactor the Builders I wrote so they can be user consumable.
>    What I want to have is a SAML SPI in which the SPI interface is passed
> a Builder.  Then the SPI plugin can modify the document however they
> want.  We'll need something similar for OIDC.
>
> On 2/16/2015 6:48 AM, Pedro Igor Silva wrote:
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Sunday, February 15, 2015 2:38:08 PM
>>> Subject: [keycloak-dev] From 1.2->2.0
>>>
>>> I think we still have a few major features to implement for 1.2 and
>>> maybe 1.3.  After this I'd like to focus on Keycloak 2.0 things like:
>>>
>>> * Improving and nailing down our SPIs
>>> * Splitting up code into private and public models so we can restrict
>>> what APIs/SPIs we want to commercially support
>>> * Pulling in and refactoring PL Federation
>>
>> I've an issue [1] in the SAML parsers that needs a fix. I don't know what are your plans for this, but I think we can start moving PL SAML types and parsers to KC ? Do you want/need a refactoring for them ?
>>
>> Or the refactoring you always talk about is around the SAML processing logic ? Such as handlers, etc ...
>>
>> [1] https://issues.jboss.org/browse/KEYCLOAK-883
>>
>>> * Consolidating and improving our admin console UI
>>>
>>> Really starting improving the core of Keycloak knowing that Keycloak 2.0
>>> is what we're going to be supporting commercially for years and years
>>> going forward.
>>> --
>>> 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 hector.bustillos at crowdint.com  Wed Feb 18 20:38:10 2015
From: hector.bustillos at crowdint.com (Hector Bustillos)
Date: Wed, 18 Feb 2015 19:38:10 -0600
Subject: [keycloak-dev] Keycloak in a VPS
Message-ID: <etPan.54e53e82.3d1b58ba.d64b@Hectors-MacBook-Pro.local>

HI I?m new in the stack and I?m trying to install keycloak in a digital ocean instance for testing, so far I?m able to make it run, everything is ok BUT I can?t access from outside the box. If I curl http://localhost:8080?it works but if I try to access from my browser with the http:/the-ip:8080 it doesn?t work neither this route?auth/admin/index.html I get nothing.

So I went to the code to?configuration/standalone.xml file and I added ?this:
?<interface name="management">
? ? ? ? ? ? <inet-address value="${jboss.bind.address.management:the-ip}"/>
? ? ? ? </interface>
? ? ? ? <interface name="public">
? ? ? ? ? ? <inet-address value="${jboss.bind.address:the-ip}"/>
? ? ? ? </interface>

Now I get a?404 - Not Found

Can you help me to configure this in a correct way?
--
-----------------------------------------------
Hector Bustillos, Software Engineer
Crowd Interactive
@hecbuma?
-----------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150218/181f9cd9/attachment.html 

From bburke at redhat.com  Wed Feb 18 22:10:49 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 18 Feb 2015 22:10:49 -0500
Subject: [keycloak-dev] Keycloak in a VPS
In-Reply-To: <etPan.54e53e82.3d1b58ba.d64b@Hectors-MacBook-Pro.local>
References: <etPan.54e53e82.3d1b58ba.d64b@Hectors-MacBook-Pro.local>
Message-ID: <54E55439.20707@redhat.com>

Not sure...

Try using <any-address/> instead of <inet-address>


On 2/18/2015 8:38 PM, Hector Bustillos wrote:
> HI I?m new in the stack and I?m trying to install keycloak in a digital
> ocean instance for testing, so far I?m able to make it run, everything
> is ok BUT I can?t access from outside the box. If I curl
> http://localhost:8080 it works but if I try to access from my browser
> with the http:/the-ip:8080 it doesn?t work neither this
> route auth/admin/index.html I get nothing.
>
> So I went to the code to configuration/standalone.xml file and I added
>   this:
>   <interface name="management">
>              <inet-address value="${jboss.bind.address.management:the-ip}"/>
>          </interface>
>          <interface name="public">
>              <inet-address value="${jboss.bind.address:the-ip}"/>
>          </interface>
>
> Now I get a 404 - Not Found
>
> Can you help me to configure this in a correct way?
> --
> -----------------------------------------------
> Hector Bustillos, Software Engineer
> Crowd Interactive
> @hecbuma
> -----------------------------------------------
>
>
> _______________________________________________
> 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 Feb 18 22:21:12 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 18 Feb 2015 22:21:12 -0500
Subject: [keycloak-dev] don't look good on ipad
Message-ID: <54E556A8.6020306@redhat.com>

Any way we can get some designer to do some quick work to make things 
look right on ipad?
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Wed Feb 18 22:25:48 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 18 Feb 2015 22:25:48 -0500
Subject: [keycloak-dev] session_state changed to ClientSession id?
Message-ID: <54E557BC.5020308@redhat.com>

Can I change the session_state in the access token (and refresh token) 
to point to ClientSession id instead?  Right now it points to the user 
session id.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Thu Feb 19 01:07:45 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 19 Feb 2015 01:07:45 -0500 (EST)
Subject: [keycloak-dev] don't look good on ipad
In-Reply-To: <54E556A8.6020306@redhat.com>
References: <54E556A8.6020306@redhat.com>
Message-ID: <1579412596.10002453.1424326065520.JavaMail.zimbra@redhat.com>

What doesn't look good? 

Login form should work well, if it doesn't let me know and I'll look into it. Admin console and account management needs some love, especially with regards to mobile. PatternFly/RCUE does this better than we do atm, so re-aligning with them should do the trick, which we need to do any ways.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, February 19, 2015 4:21:12 AM
> Subject: [keycloak-dev] don't look good on ipad
> 
> Any way we can get some designer to do some quick work to make things
> look right on ipad?
> --
> 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  Thu Feb 19 01:10:27 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 19 Feb 2015 01:10:27 -0500 (EST)
Subject: [keycloak-dev] session_state changed to ClientSession id?
In-Reply-To: <54E557BC.5020308@redhat.com>
References: <54E557BC.5020308@redhat.com>
Message-ID: <730112168.10005544.1424326227949.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, February 19, 2015 4:25:48 AM
> Subject: [keycloak-dev] session_state changed to ClientSession id?
> 
> Can I change the session_state in the access token (and refresh token)
> to point to ClientSession id instead?  Right now it points to the user
> session id.

What's the benefits of doing that?

It might have some impact on the Infinispan provider. For best performance user sessions should be retrieved by id, which we won't be able to do if we don't have it.

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

From stian at redhat.com  Thu Feb 19 03:14:11 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 19 Feb 2015 03:14:11 -0500 (EST)
Subject: [keycloak-dev] Looking for a workaround...
In-Reply-To: <3e5b29d6-633d-49b6-881a-3424a086bf2a@me.com>
References: <3e5b29d6-633d-49b6-881a-3424a086bf2a@me.com>
Message-ID: <654610268.10311508.1424333651430.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Tuesday, February 3, 2015 10:16:57 AM
> Subject: Re: [keycloak-dev] Looking for a workaround...
> 
> Hi All,
> 
> I've seen that both bugs have the Fix Version 1.1.1.Final, that's great.
> Do you already know the release date for this version?

They'll either be fixed in a 1.1.1.Final release, which would be in a couple weeks, or in 1.2.0.Beta1 if that's ready in a few weeks.

> 
> Best
> Michael
> 
> Am 02. Februar 2015 um 09:32 schrieb Michael Gerber <gerbermichi at me.com>:
> 
> 
> 
> Am 02. Februar 2015 um 09:07 schrieb Stian Thorgersen <stian at redhat.com>:
> 
> 
> 
> ----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Sunday, 1 February, 2015 4:09:35 PM
> Subject: Re: [keycloak-dev] Looking for a workaround...
> I would look at the following scenario:
> A user starts with the login process and then takes a long break (15 mins or
> more) without locking his computer.
> 
> Is this not a relatively uncommon use-case? Would a error message with a link
> back to the application be a good enough solution?
> ?
> Unfortunately, it isn't. We have got customers which use one computer for
> multiple users. And this users are used to logout from the application
> without closing the browser.
> The new user then uses the same browser to login. And this action would lead
> to an error, which is for the user not understandable.
> 
> 
> 
> There are critical processes like password changes, which should definitely
> expires after a view minutes and others like authentication which does not
> matter if they don?t expire during this break.
> 
> As above we need to improve the error page in this case. With a way back to
> the application as well.
> 
> critical actions:
> - OAUTH_GRANT
> - CODE_TO_TOKEN (already seperate)
> - VERIFY_EMAIL
> - RECOVER_PASSWORD
> - UPDATE_PROFILE
> - CONFIGURE_TOTP
> - UPDATE_PASSWORD
> non-critical actions:
> - AUTHENTICATE
> - SOCIAL_CALLBACK
> > Am 30.01.2015 um 14:25 schrieb Stian Thorgersen <stian at redhat.com>:
> >
> > What groups would you propose?
> >
> > ----- Original Message -----
> >> From: "Michael Gerber" <gerbermichi at me.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >> Sent: Monday, 26 January, 2015 4:23:49 PM
> >> Subject: Re: [keycloak-dev] Looking for a workaround...
> >>
> >>> ----- Original Message -----
> >>>> From: "Michael Gerber" <gerbermichi at me.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>> Sent: Monday, January 26, 2015 2:10:59 PM
> >>>> Subject: Re: [keycloak-dev] Looking for a workaround...
> >>>> ----- Original Message -----
> >>>> From: "Michael Gerber" <gerbermichi at me.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>>
> >>>> Sent: Monday, January 26, 2015 1:37:53 PM
> >>>> Subject: [keycloak-dev] Looking for a workaround...
> >>>> Hi all,
> >>>> I receive a lot of bug reports from our test team because of the
> >>>> following
> >>>> two issues:
> >>>> - Reset password leads to 400 Bad Request (
> >>>> https://issues.jboss.org/browse/KEYCLOAK-1014 )
> >>>> This is a tricky one - we can't ignore the state variable as that would
> >>>> make
> >>>> it vulnerable.
> >>>> We could probably come up with an alternative way to generate and verify
> >>>> state variable though. Could be a HMAC for example.
> >>>> So you would remove the state cookie?
> >>>
> >>> It could potentially be a solution - I started a separate thread on
> >>> keycloak-dev to discuss this.
> >>>
> >>>> - Login attempt after "Login user action lifespan" leads to "Invalid
> >>>> username
> >>>> or password." ( https://issues.jboss.org/browse/KEYCLOAK-1015 )
> >>>> I agree that the error message is not very good, but I disagree with
> >>>> removing
> >>>> the expiration. Why not increase it to say 30 min? That's probably a
> >>>> more
> >>>> sensible timeout for reset password as well.
> >>>> I prefer an expiration of 5 min for the password update process, but
> >>>> thats
> >>>> a
> >>>> bit short for the authentication or password reset process.
> >>>> I think the best solution would be different expiration times for the
> >>>> different processes, wouldn't it?
> >>>
> >>> Maybe - we do try to keep configuration options to a minimum as these
> >>> introduce complexity as well as potentials for bug/security issues.
> >>
> >> I totaly understand that.
> >> You have currently the following actions:
> >> OAUTH_GRANT,
> >> CODE_TO_TOKEN,
> >> VERIFY_EMAIL,
> >> UPDATE_PROFILE,
> >> CONFIGURE_TOTP,
> >> UPDATE_PASSWORD,
> >> RECOVER_PASSWORD,
> >> AUTHENTICATE,
> >> SOCIAL_CALLBACK
> >>
> >> And it doesn't make sense to have a different conffiguration for every
> >> one...
> >> But maybe we can group it into different groups?
> >>
> >>>
> >>>
> >>>> Do you have any good ideas for a workaround?
> >>>> Best
> >>>> Michael
> >>>> _______________________________________________
> >>>> keycloak-dev mailing list
> >>>> keycloak-dev at lists.jboss.org
> >>>>
> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>


From stian at redhat.com  Thu Feb 19 03:29:04 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 19 Feb 2015 03:29:04 -0500 (EST)
Subject: [keycloak-dev] How to refresh and update token
In-Reply-To: <CAPLm6jJO3tVftxyXL3dF3PxSEQ0X86dAY5hW7CRKb752=G_Exw@mail.gmail.com>
References: <CAPLm6jJO3tVftxyXL3dF3PxSEQ0X86dAY5hW7CRKb752=G_Exw@mail.gmail.com>
Message-ID: <275771925.10344195.1424334544780.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Jae Choi" <jaekun.choi at gmail.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, February 3, 2015 8:42:56 AM
> Subject: [keycloak-dev] How to refresh and update token
> 
> Is there a way to refresh token with Javascript Angular adaptor so that
> Custom User Federator is updated again?
> 
> I'm actually storing token retrieved from another service provider as user
> attribute. It is stored first time when the user logs in (and saves the user
> data into the Keycloak database) but there isn't easy way to update the
> attribute with the adaptor?

I don't quite understand your use-case, but it sounds like what you're doing with your custom user federator is better done in the new identity brokering feature Pedro is working on which will be available in 1.2.0.Beta1.

The JS adapter provides the updateToken method to refresh the token, see http://docs.jboss.org/keycloak/docs/1.1.0.Final/userguide/html/ch08.html#d4e1058

> 
> Thanks,
> 
> --
> Kind Regards,
> Jae Choi
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From stian at redhat.com  Thu Feb 19 03:32:33 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 19 Feb 2015 03:32:33 -0500 (EST)
Subject: [keycloak-dev] WildFly integration (READ ME!)
In-Reply-To: <969708031.6108771.1422954530044.JavaMail.zimbra@redhat.com>
References: <969708031.6108771.1422954530044.JavaMail.zimbra@redhat.com>
Message-ID: <1360543918.10348397.1424334753943.JavaMail.zimbra@redhat.com>

No comments?!

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Tuesday, February 3, 2015 10:08:50 AM
> Subject: [keycloak-dev] WildFly integration (READ ME!)
> 
> All,
> 
> We have a few decisions to make in the not so far future. I'm away from
> Thursday, so let's have a hangout when I get back on the 17th February if
> that works for everyone.
> 
> The list of things to discuss includes:
> 
> * Drop keycloak-server.json - Should we drop our own configuration file and
> use DMR (standalone.xml)
> 
> * Keycloak CLI - Should we create our own or use WildFly CLI
> 
> * Admin operations exposed over DMR - Should we expose none, some or all
> admin operations over DMR? If we expose all should we deprecate the current
> REST endpoints?
> 
> * Packaging/distribution - How do we distribute Keycloak? Options:
>   - Full WildFly
>   - Core/web WildFly
>   - Overlay/installer/feature-pack to install to existing WF and EAP
>   - WAR bundle
> 
> * How should we deal with providers, themes and keycloak-server.json in
> domain-mode
> 
> * MSC all the way - We can deploy directly through the Undertow sub-system
> instead of deploying a WAR from the sub-system
> 
> * Split sub-systems - Should we split the sub-system in two? One for the
> auth-server and another for the adapter
> 
> * Deployable to other containers - Should it be possible to deploy Keycloak
> to Tomcat, Jetty, Fuse, etc..? One option could be to have reduced features
> in other containers (for example no client-cert)
> 
> Please add any other relevant topics.
> 
> Next big discussion I want to have is about distribution of adapters, but
> let's do one at a time ;)
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Thu Feb 19 07:14:38 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 19 Feb 2015 07:14:38 -0500 (EST)
Subject: [keycloak-dev] 1.2.0.Beta1 release
In-Reply-To: <1666013047.10511613.1424347995503.JavaMail.zimbra@redhat.com>
Message-ID: <219667017.10512611.1424348078721.JavaMail.zimbra@redhat.com>

For 1.2.0.Beta1 we should at least include:

* Custom claims
* Identity brokering
* Kerberos federation

What's the ETA on those?

From psilva at redhat.com  Thu Feb 19 07:35:31 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 19 Feb 2015 07:35:31 -0500 (EST)
Subject: [keycloak-dev] 1.2.0.Beta1 release
In-Reply-To: <219667017.10512611.1424348078721.JavaMail.zimbra@redhat.com>
References: <219667017.10512611.1424348078721.JavaMail.zimbra@redhat.com>
Message-ID: <1534924968.15869108.1424349331291.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Thursday, February 19, 2015 10:14:38 AM
> Subject: [keycloak-dev] 1.2.0.Beta1 release
> 
> For 1.2.0.Beta1 we should at least include:
> 
> * Custom claims
> * Identity brokering

The identity broker is pretty much done. However, to deliver something really useful we need at least role mapping. Which I'm not sure is being considered in the "Custom claims" or not.

Right now I'm writing the documentation. I've already added some useful examples and going to add one more for OIDC brokering.

> * Kerberos federation
> 
> What's the ETA on those?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Thu Feb 19 07:40:38 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 19 Feb 2015 07:40:38 -0500 (EST)
Subject: [keycloak-dev] 1.2.0.Beta1 release
In-Reply-To: <1534924968.15869108.1424349331291.JavaMail.zimbra@redhat.com>
References: <219667017.10512611.1424348078721.JavaMail.zimbra@redhat.com>
	<1534924968.15869108.1424349331291.JavaMail.zimbra@redhat.com>
Message-ID: <84925046.10531478.1424349638383.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Thursday, February 19, 2015 1:35:31 PM
> Subject: Re: [keycloak-dev] 1.2.0.Beta1 release
> 
> ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Thursday, February 19, 2015 10:14:38 AM
> > Subject: [keycloak-dev] 1.2.0.Beta1 release
> > 
> > For 1.2.0.Beta1 we should at least include:
> > 
> > * Custom claims
> > * Identity brokering
> 
> The identity broker is pretty much done. However, to deliver something really
> useful we need at least role mapping. Which I'm not sure is being considered
> in the "Custom claims" or not.

Would be great to have role mapping in Beta1, although it would be nice to release something soon (1-2 weeks from now) so it could be done for Beta2 as well.

> 
> Right now I'm writing the documentation. I've already added some useful
> examples and going to add one more for OIDC brokering.

How about once 1.2.0.Beta1 is released you write a blog with how to use Keycloak to login with Google and invoke some Google API after obtaining the token from KC?

> 
> > * Kerberos federation
> > 
> > What's the ETA on those?
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> 

From psilva at redhat.com  Thu Feb 19 07:52:09 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 19 Feb 2015 07:52:09 -0500 (EST)
Subject: [keycloak-dev] 1.2.0.Beta1 release
In-Reply-To: <84925046.10531478.1424349638383.JavaMail.zimbra@redhat.com>
References: <219667017.10512611.1424348078721.JavaMail.zimbra@redhat.com>
	<1534924968.15869108.1424349331291.JavaMail.zimbra@redhat.com>
	<84925046.10531478.1424349638383.JavaMail.zimbra@redhat.com>
Message-ID: <1259238120.15876808.1424350329376.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Thursday, February 19, 2015 10:40:38 AM
> Subject: Re: [keycloak-dev] 1.2.0.Beta1 release
> 
> 
> 
> ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > Sent: Thursday, February 19, 2015 1:35:31 PM
> > Subject: Re: [keycloak-dev] 1.2.0.Beta1 release
> > 
> > ----- Original Message -----
> > > From: "Stian Thorgersen" <stian at redhat.com>
> > > To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> > > Sent: Thursday, February 19, 2015 10:14:38 AM
> > > Subject: [keycloak-dev] 1.2.0.Beta1 release
> > > 
> > > For 1.2.0.Beta1 we should at least include:
> > > 
> > > * Custom claims
> > > * Identity brokering
> > 
> > The identity broker is pretty much done. However, to deliver something
> > really
> > useful we need at least role mapping. Which I'm not sure is being
> > considered
> > in the "Custom claims" or not.
> 
> Would be great to have role mapping in Beta1, although it would be nice to
> release something soon (1-2 weeks from now) so it could be done for Beta2 as
> well.

For social we are cool. Problem is enterprise use cases (like the one we had recently in the mailing list) that usually demands such thing. But I agree, better is to deliver something ASAP.

> 
> > 
> > Right now I'm writing the documentation. I've already added some useful
> > examples and going to add one more for OIDC brokering.
> 
> How about once 1.2.0.Beta1 is released you write a blog with how to use
> Keycloak to login with Google and invoke some Google API after obtaining the
> token from KC?

Sure. Beside that, we have now examples to demonstrate all that using twitter, google and facebook.

> 
> > 
> > > * Kerberos federation
> > > 
> > > What's the ETA on those?
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > 
> > 
> 

From psilva at redhat.com  Thu Feb 19 07:55:04 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 19 Feb 2015 07:55:04 -0500 (EST)
Subject: [keycloak-dev] 1.2.0.Beta1 release
In-Reply-To: <219667017.10512611.1424348078721.JavaMail.zimbra@redhat.com>
References: <219667017.10512611.1424348078721.JavaMail.zimbra@redhat.com>
Message-ID: <44019229.15877965.1424350504296.JavaMail.zimbra@redhat.com>

Btw, I think we should have a meeting 1 or 2 weeks before the release in order to sync important features being delivered. So we can demonstrate these features, collect feedback and fill gaps that may pass unnoticed during development.

----- Original Message -----
From: "Stian Thorgersen" <stian at redhat.com>
To: "keycloak dev" <keycloak-dev at lists.jboss.org>
Sent: Thursday, February 19, 2015 10:14:38 AM
Subject: [keycloak-dev] 1.2.0.Beta1 release

For 1.2.0.Beta1 we should at least include:

* Custom claims
* Identity brokering
* Kerberos federation

What's the ETA on those?
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev

From stian at redhat.com  Thu Feb 19 08:41:29 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 19 Feb 2015 08:41:29 -0500 (EST)
Subject: [keycloak-dev] 1.2.0.Beta1 release
In-Reply-To: <44019229.15877965.1424350504296.JavaMail.zimbra@redhat.com>
References: <219667017.10512611.1424348078721.JavaMail.zimbra@redhat.com>
	<44019229.15877965.1424350504296.JavaMail.zimbra@redhat.com>
Message-ID: <1631577407.10585740.1424353289245.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Thursday, February 19, 2015 1:55:04 PM
> Subject: Re: [keycloak-dev] 1.2.0.Beta1 release
> 
> Btw, I think we should have a meeting 1 or 2 weeks before the release in
> order to sync important features being delivered. So we can demonstrate
> these features, collect feedback and fill gaps that may pass unnoticed
> during development.

Demonstrating features is a great idea. We should do it when it's ready though and not everything at once 1-2 weeks before release.

End of Thursdays meetings are great for that!

> 
> ----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Thursday, February 19, 2015 10:14:38 AM
> Subject: [keycloak-dev] 1.2.0.Beta1 release
> 
> For 1.2.0.Beta1 we should at least include:
> 
> * Custom claims
> * Identity brokering
> * Kerberos federation
> 
> What's the ETA on those?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From ssilvert at redhat.com  Thu Feb 19 08:50:03 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 19 Feb 2015 08:50:03 -0500
Subject: [keycloak-dev] WildFly integration (READ ME!)
In-Reply-To: <1360543918.10348397.1424334753943.JavaMail.zimbra@redhat.com>
References: <969708031.6108771.1422954530044.JavaMail.zimbra@redhat.com>
	<1360543918.10348397.1424334753943.JavaMail.zimbra@redhat.com>
Message-ID: <54E5EA0B.8040605@redhat.com>

I think most of the answers to Stian's questions depend on what Keycloak 
is going to be.  In other words, what is our strategy?

If we decide that the auth server is a strictly WildFly-based product 
then the answer will always be "Do it the WildFly way". If we want the 
auth server to run on other containers then we need to be a lot more 
careful about cross-platform compatibility in everything we do.

I don't think the answer is to have a scaled-down version of the auth 
server for other platforms.  It's just too hard to constantly be 
thinking about what is essentially two flavors of our product.

There definitely are advantages to being container agnostic.  But I 
think we need to decide this question and put a stake in the ground as 
soon as possible.  Then the answers will  become clear.


On 2/19/2015 3:32 AM, Stian Thorgersen wrote:
> No comments?!
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Tuesday, February 3, 2015 10:08:50 AM
>> Subject: [keycloak-dev] WildFly integration (READ ME!)
>>
>> All,
>>
>> We have a few decisions to make in the not so far future. I'm away from
>> Thursday, so let's have a hangout when I get back on the 17th February if
>> that works for everyone.
>>
>> The list of things to discuss includes:
>>
>> * Drop keycloak-server.json - Should we drop our own configuration file and
>> use DMR (standalone.xml)
>>
>> * Keycloak CLI - Should we create our own or use WildFly CLI
>>
>> * Admin operations exposed over DMR - Should we expose none, some or all
>> admin operations over DMR? If we expose all should we deprecate the current
>> REST endpoints?
>>
>> * Packaging/distribution - How do we distribute Keycloak? Options:
>>    - Full WildFly
>>    - Core/web WildFly
>>    - Overlay/installer/feature-pack to install to existing WF and EAP
>>    - WAR bundle
>>
>> * How should we deal with providers, themes and keycloak-server.json in
>> domain-mode
>>
>> * MSC all the way - We can deploy directly through the Undertow sub-system
>> instead of deploying a WAR from the sub-system
>>
>> * Split sub-systems - Should we split the sub-system in two? One for the
>> auth-server and another for the adapter
>>
>> * Deployable to other containers - Should it be possible to deploy Keycloak
>> to Tomcat, Jetty, Fuse, etc..? One option could be to have reduced features
>> in other containers (for example no client-cert)
>>
>> Please add any other relevant topics.
>>
>> Next big discussion I want to have is about distribution of adapters, but
>> let's do one at a time ;)
>> _______________________________________________
>> 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 hector.bustillos at crowdint.com  Thu Feb 19 10:31:53 2015
From: hector.bustillos at crowdint.com (Hector Bustillos)
Date: Thu, 19 Feb 2015 09:31:53 -0600
Subject: [keycloak-dev] Keycloak in a VPS
In-Reply-To: <54E55439.20707@redhat.com>
References: <etPan.54e53e82.3d1b58ba.d64b@Hectors-MacBook-Pro.local>
	<54E55439.20707@redhat.com>
Message-ID: <etPan.54e601e9.2eb141f2.d64b@Hectors-MacBook-Pro.local>

Thanks that worked

--
-----------------------------------------------
Hector Bustillos, Software Engineer
Crowd Interactive
@hecbuma?
-----------------------------------------------

On February 18, 2015 at 9:10:56 PM, Bill Burke (bburke at redhat.com) wrote:

Not sure...  

Try using <any-address/> instead of <inet-address>  


On 2/18/2015 8:38 PM, Hector Bustillos wrote:  
> HI I?m new in the stack and I?m trying to install keycloak in a digital  
> ocean instance for testing, so far I?m able to make it run, everything  
> is ok BUT I can?t access from outside the box. If I curl  
> http://localhost:8080 it works but if I try to access from my browser  
> with the http:/the-ip:8080 it doesn?t work neither this  
> route auth/admin/index.html I get nothing.  
>  
> So I went to the code to configuration/standalone.xml file and I added  
> this:  
> <interface name="management">  
> <inet-address value="${jboss.bind.address.management:the-ip}"/>  
> </interface>  
> <interface name="public">  
> <inet-address value="${jboss.bind.address:the-ip}"/>  
> </interface>  
>  
> Now I get a 404 - Not Found  
>  
> Can you help me to configure this in a correct way?  
> --  
> -----------------------------------------------  
> Hector Bustillos, Software Engineer  
> Crowd Interactive  
> @hecbuma  
> -----------------------------------------------  
>  
>  
> _______________________________________________  
> 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/20150219/1c32cda7/attachment-0001.html 

From hector.bustillos at crowdint.com  Thu Feb 19 10:37:04 2015
From: hector.bustillos at crowdint.com (Hector Bustillos)
Date: Thu, 19 Feb 2015 09:37:04 -0600
Subject: [keycloak-dev] Migrating to keycloak
Message-ID: <etPan.54e60320.5bd062c2.d64b@Hectors-MacBook-Pro.local>

Hi,

We?re running web app and want to move authentication to keycloak but keep the same db that we have right now. of course there are a couple of questions that I want to clarify since I?m new in keycloak

- I know we can use a custom db source, but is this db source can be our existing mysql db?
- how can we migrate all users to keycloak?


Thanks

--
-----------------------------------------------
Hector Bustillos, Software Engineer
Crowd Interactive
@hecbuma?
-----------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150219/d2cef6dc/attachment.html 

From bburke at redhat.com  Thu Feb 19 11:56:21 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 19 Feb 2015 11:56:21 -0500
Subject: [keycloak-dev] WildFly integration (READ ME!)
In-Reply-To: <969708031.6108771.1422954530044.JavaMail.zimbra@redhat.com>
References: <969708031.6108771.1422954530044.JavaMail.zimbra@redhat.com>
Message-ID: <54E615B5.5070402@redhat.com>



On 2/3/2015 4:08 AM, Stian Thorgersen wrote:
> All,
>
> We have a few decisions to make in the not so far future. I'm away from Thursday, so let's have a hangout when I get back on the 17th February if that works for everyone.
>

Dropping and deprecating things all depends on if we want Keycloak 
usable outside of Wildfly/EAP.

> The list of things to discuss includes:
>
> * Drop keycloak-server.json - Should we drop our own configuration file and use DMR (standalone.xml)
>

For adapters we support both a .json config and DMR.  We should do the 
same for keycloak-server.json.  Our testsuite depends on 
keycloak-server.json anyways.


> * Keycloak CLI - Should we create our own or use WildFly CLI
>
> * Admin operations exposed over DMR - Should we expose none, some or all admin operations over DMR? If we expose all should we deprecate the current REST endpoints?
>

IMO, DMR sux.  It is a lot of boilerplate code to support.  Remember 
also the admin console uses the REST interface.

> * Packaging/distribution - How do we distribute Keycloak? Options:
>    - Full WildFly
>    - Core/web WildFly
>    - Overlay/installer/feature-pack to install to existing WF and EAP
>    - WAR bundle
>

As per our discussions today.  IMO Community should be this:
* Wildfly appliance
* EAP zip and/or installer to install Keycloak on top of EAP 6.x and 
7.x.  We can't distribute EAP, but customers may want to use community 
on EAP to use newer features.
* private WAR bundle Quickstart repo
* Individual adapter downloads.  This is great because we can see what 
people are using.

> * How should we deal with providers, themes and keycloak-server.json in domain-mode
>

There's some other requirements coming down the pipe.  For example, RHT 
IT needs to add a "Terms and Conditions" click through when logging in. 
  We'll want to support custom workflows.  This may all fall under 
deployable themes though.

> * MSC all the way - We can deploy directly through the Undertow sub-system instead of deploying a WAR from the sub-system
>

Definitely doable.

> * Split sub-systems - Should we split the sub-system in two? One for the auth-server and another for the adapter
>

YES!

> * Deployable to other containers - Should it be possible to deploy Keycloak to Tomcat, Jetty, Fuse, etc..? One option could be to have reduced features in other containers (for example no client-cert)
>

As discussed earlier we have a private WAR bundle Quickstart repo.




-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Thu Feb 19 12:03:56 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 19 Feb 2015 12:03:56 -0500
Subject: [keycloak-dev] distribution of adapters
Message-ID: <54E6177C.3060803@redhat.com>

I think there is a different here between community and product.

In community:
* Adapters should each have a separate download.  This has a side effect 
of showing us which adapters are popular (not to mention increasing our 
download numers ;)
* All adapters are released simultaneously with a server release
* Adapters can have individual patch releases.
* If we want to release a patched adapter, use a micro version scheme. 
First 3 numbers correspond to the keycloak version the adapter was built 
against.  Last number is the patch number of the adapter:

We release Keycloak 1.1.0:
- keycloak-jetty-1.1.0.0
Werelease a patch of jetty adapter for keycloak 1.1.0
- keycloak-jetty-1.1.0.1

I'm not sure how all that effects product and git branches.  Ideally 
you'd have matching branches for major keycloak server release for the 
adapter.

i.e.

Keycloak_server_branch_1.1.x
Keycloak_adapters_branch_1.1.x


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Thu Feb 19 12:06:56 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 19 Feb 2015 12:06:56 -0500
Subject: [keycloak-dev] Migrating to keycloak
In-Reply-To: <etPan.54e60320.5bd062c2.d64b@Hectors-MacBook-Pro.local>
References: <etPan.54e60320.5bd062c2.d64b@Hectors-MacBook-Pro.local>
Message-ID: <54E61830.1030205@redhat.com>

You'll have to write a User Federation Provider.  There is a simple 
properties file example within:

examples/providers/federation-provider

On 2/19/2015 10:37 AM, Hector Bustillos wrote:
> Hi,
>
> We?re running web app and want to move authentication to keycloak but
> keep the same db that we have right now. of course there are a couple of
> questions that I want to clarify since I?m new in keycloak
>
> - I know we can use a custom db source, but is this db source can be our
> existing mysql db?
> - how can we migrate all users to keycloak?
>
>
> Thanks
>
> --
> -----------------------------------------------
> Hector Bustillos, Software Engineer
> Crowd Interactive
> @hecbuma
> -----------------------------------------------
>
>
> _______________________________________________
> 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 hector.bustillos at crowdint.com  Thu Feb 19 12:15:43 2015
From: hector.bustillos at crowdint.com (Hector Bustillos)
Date: Thu, 19 Feb 2015 11:15:43 -0600
Subject: [keycloak-dev] Migrating to keycloak
In-Reply-To: <54E61830.1030205@redhat.com>
References: <etPan.54e60320.5bd062c2.d64b@Hectors-MacBook-Pro.local>
	<54E61830.1030205@redhat.com>
Message-ID: <etPan.54e61a3f.4db127f8.d64b@Hectors-MacBook-Pro.local>

Thanks let me check that out and see how far can I get.?

--
-----------------------------------------------
Hector Bustillos, Software Engineer
Crowd Interactive
@hecbuma?
-----------------------------------------------

On February 19, 2015 at 11:07:05 AM, Bill Burke (bburke at redhat.com) wrote:

You'll have to write a User Federation Provider. There is a simple  
properties file example within:  

examples/providers/federation-provider  

On 2/19/2015 10:37 AM, Hector Bustillos wrote:  
> Hi,  
>  
> We?re running web app and want to move authentication to keycloak but  
> keep the same db that we have right now. of course there are a couple of  
> questions that I want to clarify since I?m new in keycloak  
>  
> - I know we can use a custom db source, but is this db source can be our  
> existing mysql db?  
> - how can we migrate all users to keycloak?  
>  
>  
> Thanks  
>  
> --  
> -----------------------------------------------  
> Hector Bustillos, Software Engineer  
> Crowd Interactive  
> @hecbuma  
> -----------------------------------------------  
>  
>  
> _______________________________________________  
> 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/20150219/ba423184/attachment.html 

From psilva at redhat.com  Thu Feb 19 12:28:22 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 19 Feb 2015 12:28:22 -0500 (EST)
Subject: [keycloak-dev] distribution of adapters
In-Reply-To: <54E6177C.3060803@redhat.com>
References: <54E6177C.3060803@redhat.com>
Message-ID: <782646647.16199282.1424366902002.JavaMail.zimbra@redhat.com>

Each adapter in its own repository, right ? And probably an additional one with common stuff ....

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: keycloak-dev at lists.jboss.org
Sent: Thursday, February 19, 2015 3:03:56 PM
Subject: [keycloak-dev] distribution of adapters

I think there is a different here between community and product.

In community:
* Adapters should each have a separate download.  This has a side effect 
of showing us which adapters are popular (not to mention increasing our 
download numers ;)
* All adapters are released simultaneously with a server release
* Adapters can have individual patch releases.
* If we want to release a patched adapter, use a micro version scheme. 
First 3 numbers correspond to the keycloak version the adapter was built 
against.  Last number is the patch number of the adapter:

We release Keycloak 1.1.0:
- keycloak-jetty-1.1.0.0
Werelease a patch of jetty adapter for keycloak 1.1.0
- keycloak-jetty-1.1.0.1

I'm not sure how all that effects product and git branches.  Ideally 
you'd have matching branches for major keycloak server release for the 
adapter.

i.e.

Keycloak_server_branch_1.1.x
Keycloak_adapters_branch_1.1.x


-- 
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 Feb 19 12:59:09 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 19 Feb 2015 18:59:09 +0100
Subject: [keycloak-dev] distribution of adapters
In-Reply-To: <782646647.16199282.1424366902002.JavaMail.zimbra@redhat.com>
References: <54E6177C.3060803@redhat.com>
	<782646647.16199282.1424366902002.JavaMail.zimbra@redhat.com>
Message-ID: <54E6246D.4060507@redhat.com>

I think I agree with Bolek that many separate adapter repos and releases 
is unecessary overhead. Especially if we're going to have even more 
adapter types than we have now...

I can understand for non-maven non-java project, but why have separate 
adapter repo and releases for jetty, tomcat, eap etc? Only advantage is 
possibility to do separate release in case of adapter bug, but not sure 
if it would help much, because there is lot of common code in "core" and 
"adapter-core" . And:

* in case of blocker bug in "core", you need to release whole keycloak 
anyway as this code is shared for both server and adapters
* in case of blocker bug in "adapter-core", you need to release all java 
adapters anyway.

Marek


On 19.2.2015 18:28, Pedro Igor Silva wrote:
> Each adapter in its own repository, right ? And probably an additional one with common stuff ....
>
> ----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, February 19, 2015 3:03:56 PM
> Subject: [keycloak-dev] distribution of adapters
>
> I think there is a different here between community and product.
>
> In community:
> * Adapters should each have a separate download.  This has a side effect
> of showing us which adapters are popular (not to mention increasing our
> download numers ;)
> * All adapters are released simultaneously with a server release
> * Adapters can have individual patch releases.
> * If we want to release a patched adapter, use a micro version scheme.
> First 3 numbers correspond to the keycloak version the adapter was built
> against.  Last number is the patch number of the adapter:
>
> We release Keycloak 1.1.0:
> - keycloak-jetty-1.1.0.0
> Werelease a patch of jetty adapter for keycloak 1.1.0
> - keycloak-jetty-1.1.0.1
>
> I'm not sure how all that effects product and git branches.  Ideally
> you'd have matching branches for major keycloak server release for the
> adapter.
>
> i.e.
>
> Keycloak_server_branch_1.1.x
> Keycloak_adapters_branch_1.1.x
>
>


From psilva at redhat.com  Thu Feb 19 13:15:27 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 19 Feb 2015 13:15:27 -0500 (EST)
Subject: [keycloak-dev] distribution of adapters
In-Reply-To: <54E6246D.4060507@redhat.com>
References: <54E6177C.3060803@redhat.com>
	<782646647.16199282.1424366902002.JavaMail.zimbra@redhat.com>
	<54E6246D.4060507@redhat.com>
Message-ID: <1806736460.16229368.1424369727130.JavaMail.zimbra@redhat.com>

I also agree.

I don't know deeply how adapters are designed, specially how much core is being used to avoid code duplication across different adapters. From what I saw, it seems that most of
the code is provided by core which is a good smell. And only very specific code resides within each adapter, only the necessary bits to get the integration done.

That said, I think most issues will be related with core than with a specific adapter.

----- Original Message -----
From: "Marek Posolda" <mposolda at redhat.com>
To: "Pedro Igor Silva" <psilva at redhat.com>, "Bill Burke" <bburke at redhat.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Thursday, February 19, 2015 3:59:09 PM
Subject: Re: [keycloak-dev] distribution of adapters

I think I agree with Bolek that many separate adapter repos and releases 
is unecessary overhead. Especially if we're going to have even more 
adapter types than we have now...

I can understand for non-maven non-java project, but why have separate 
adapter repo and releases for jetty, tomcat, eap etc? Only advantage is 
possibility to do separate release in case of adapter bug, but not sure 
if it would help much, because there is lot of common code in "core" and 
"adapter-core" . And:

* in case of blocker bug in "core", you need to release whole keycloak 
anyway as this code is shared for both server and adapters
* in case of blocker bug in "adapter-core", you need to release all java 
adapters anyway.

Marek


On 19.2.2015 18:28, Pedro Igor Silva wrote:
> Each adapter in its own repository, right ? And probably an additional one with common stuff ....
>
> ----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, February 19, 2015 3:03:56 PM
> Subject: [keycloak-dev] distribution of adapters
>
> I think there is a different here between community and product.
>
> In community:
> * Adapters should each have a separate download.  This has a side effect
> of showing us which adapters are popular (not to mention increasing our
> download numers ;)
> * All adapters are released simultaneously with a server release
> * Adapters can have individual patch releases.
> * If we want to release a patched adapter, use a micro version scheme.
> First 3 numbers correspond to the keycloak version the adapter was built
> against.  Last number is the patch number of the adapter:
>
> We release Keycloak 1.1.0:
> - keycloak-jetty-1.1.0.0
> Werelease a patch of jetty adapter for keycloak 1.1.0
> - keycloak-jetty-1.1.0.1
>
> I'm not sure how all that effects product and git branches.  Ideally
> you'd have matching branches for major keycloak server release for the
> adapter.
>
> i.e.
>
> Keycloak_server_branch_1.1.x
> Keycloak_adapters_branch_1.1.x
>
>


From psilva at redhat.com  Thu Feb 19 13:48:09 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 19 Feb 2015 13:48:09 -0500 (EST)
Subject: [keycloak-dev] WildFly integration (READ ME!)
In-Reply-To: <54E5EA0B.8040605@redhat.com>
References: <969708031.6108771.1422954530044.JavaMail.zimbra@redhat.com>
	<1360543918.10348397.1424334753943.JavaMail.zimbra@redhat.com>
	<54E5EA0B.8040605@redhat.com>
Message-ID: <1761073856.16252071.1424371689732.JavaMail.zimbra@redhat.com>

>From a product perspective, I think we should focus on WildFly and push for using it as a standalone server.

However, for community I believe we need to be flexible and support different containers. That will allow us to reach a wider audience and collect important feedbacks that will help to improve the project as whole. Here is where innovation really happens ...

----- Original Message -----
From: "Stan Silvert" <ssilvert at redhat.com>
To: keycloak-dev at lists.jboss.org
Sent: Thursday, February 19, 2015 11:50:03 AM
Subject: Re: [keycloak-dev] WildFly integration (READ ME!)

I think most of the answers to Stian's questions depend on what Keycloak 
is going to be.  In other words, what is our strategy?

If we decide that the auth server is a strictly WildFly-based product 
then the answer will always be "Do it the WildFly way". If we want the 
auth server to run on other containers then we need to be a lot more 
careful about cross-platform compatibility in everything we do.

I don't think the answer is to have a scaled-down version of the auth 
server for other platforms.  It's just too hard to constantly be 
thinking about what is essentially two flavors of our product.

There definitely are advantages to being container agnostic.  But I 
think we need to decide this question and put a stake in the ground as 
soon as possible.  Then the answers will  become clear.


On 2/19/2015 3:32 AM, Stian Thorgersen wrote:
> No comments?!
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Tuesday, February 3, 2015 10:08:50 AM
>> Subject: [keycloak-dev] WildFly integration (READ ME!)
>>
>> All,
>>
>> We have a few decisions to make in the not so far future. I'm away from
>> Thursday, so let's have a hangout when I get back on the 17th February if
>> that works for everyone.
>>
>> The list of things to discuss includes:
>>
>> * Drop keycloak-server.json - Should we drop our own configuration file and
>> use DMR (standalone.xml)
>>
>> * Keycloak CLI - Should we create our own or use WildFly CLI
>>
>> * Admin operations exposed over DMR - Should we expose none, some or all
>> admin operations over DMR? If we expose all should we deprecate the current
>> REST endpoints?
>>
>> * Packaging/distribution - How do we distribute Keycloak? Options:
>>    - Full WildFly
>>    - Core/web WildFly
>>    - Overlay/installer/feature-pack to install to existing WF and EAP
>>    - WAR bundle
>>
>> * How should we deal with providers, themes and keycloak-server.json in
>> domain-mode
>>
>> * MSC all the way - We can deploy directly through the Undertow sub-system
>> instead of deploying a WAR from the sub-system
>>
>> * Split sub-systems - Should we split the sub-system in two? One for the
>> auth-server and another for the adapter
>>
>> * Deployable to other containers - Should it be possible to deploy Keycloak
>> to Tomcat, Jetty, Fuse, etc..? One option could be to have reduced features
>> in other containers (for example no client-cert)
>>
>> Please add any other relevant topics.
>>
>> Next big discussion I want to have is about distribution of adapters, but
>> let's do one at a time ;)
>> _______________________________________________
>> 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 mposolda at redhat.com  Thu Feb 19 13:57:43 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Thu, 19 Feb 2015 19:57:43 +0100
Subject: [keycloak-dev] 1.2.0.Beta1 release
In-Reply-To: <219667017.10512611.1424348078721.JavaMail.zimbra@redhat.com>
References: <219667017.10512611.1424348078721.JavaMail.zimbra@redhat.com>
Message-ID: <54E63227.7060108@redhat.com>

For Kerberos, the remaining needed stuff is:
- Automated tests (looks ApacheDS can be used for that. We are already 
using it for LDAP test)
- More interoperability testing (want to look at FreeIPA at least)
- Docs

This is "must have" for Beta1 and should be next week.

I will need to take a look at credentials delegation, which can be 
likely postponed to Beta2 if I can't finish it next week.

Marek

On 19.2.2015 13:14, Stian Thorgersen wrote:
> For 1.2.0.Beta1 we should at least include:
>
> * Custom claims
> * Identity brokering
> * Kerberos federation
>
> What's the ETA on those?
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Thu Feb 19 14:49:10 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 19 Feb 2015 14:49:10 -0500
Subject: [keycloak-dev] 1.2.0.Beta1 release
In-Reply-To: <219667017.10512611.1424348078721.JavaMail.zimbra@redhat.com>
References: <219667017.10512611.1424348078721.JavaMail.zimbra@redhat.com>
Message-ID: <54E63E36.9020605@redhat.com>



On 2/19/2015 7:14 AM, Stian Thorgersen wrote:
> For 1.2.0.Beta1 we should at least include:
>
> * Custom claims

Still awhile aways.  Keep get interrupted by emails, phone, kids (they 
have winter vacation), meetings, etc...


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Thu Feb 19 14:50:41 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 19 Feb 2015 14:50:41 -0500
Subject: [keycloak-dev] don't look good on ipad
In-Reply-To: <1579412596.10002453.1424326065520.JavaMail.zimbra@redhat.com>
References: <54E556A8.6020306@redhat.com>
	<1579412596.10002453.1424326065520.JavaMail.zimbra@redhat.com>
Message-ID: <54E63E91.8000109@redhat.com>

To know what it looks like on ipad, got to applications screen and 
shorten the width of the browser until you see the left menu on top of 
the application list.

On 2/19/2015 1:07 AM, Stian Thorgersen wrote:
> What doesn't look good?
>
> Login form should work well, if it doesn't let me know and I'll look into it. Admin console and account management needs some love, especially with regards to mobile. PatternFly/RCUE does this better than we do atm, so re-aligning with them should do the trick, which we need to do any ways.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, February 19, 2015 4:21:12 AM
>> Subject: [keycloak-dev] don't look good on ipad
>>
>> Any way we can get some designer to do some quick work to make things
>> look right on ipad?
>> --
>> 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 Feb 19 14:54:48 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 19 Feb 2015 14:54:48 -0500
Subject: [keycloak-dev] session_state changed to ClientSession id?
In-Reply-To: <730112168.10005544.1424326227949.JavaMail.zimbra@redhat.com>
References: <54E557BC.5020308@redhat.com>
	<730112168.10005544.1424326227949.JavaMail.zimbra@redhat.com>
Message-ID: <54E63F88.8010809@redhat.com>



On 2/19/2015 1:10 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, February 19, 2015 4:25:48 AM
>> Subject: [keycloak-dev] session_state changed to ClientSession id?
>>
>> Can I change the session_state in the access token (and refresh token)
>> to point to ClientSession id instead?  Right now it points to the user
>> session id.
>
> What's the benefits of doing that?
>
> It might have some impact on the Infinispan provider. For best performance user sessions should be retrieved by id, which we won't be able to do if we don't have it.
>

Access and refresh tokens should be associated with a client session so 
that we can track back an audit.  For claim mapping, I'm also allowing 
admins to map client session notes into the token.  There might be 
temporary protocol specific information stored there.

I can just add a new client_session claim if needed.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Thu Feb 19 21:15:19 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 19 Feb 2015 21:15:19 -0500
Subject: [keycloak-dev] How to render claim data entry and display?
Message-ID: <54E698B7.9070301@redhat.com>

I'm not sure how to render claims within the admin console, registration 
page, and in the user self service pages.  The thing is that generically 
rendering user metadata can look quite ugly.  Address is one example 
where the grouping and ordering of each attribute is important to look 
nice.  There are other instances where you need to group types of data 
together (home phone, fax, work phone, mobile).  Then there is the 
problem of what claim data do you show on what pages which is harder 
than it seems, for example, registration page might only require a 
mobile number, but admin console and user profile page might want to 
show home, fax, work too.  You would end up having to define a data 
model that captured metadata for each page type (registration, user 
profile, and admin console).  Finally, if you have generically rendered 
claims, what happens when the user wants to override this rendering and 
put their own formatting, .css types, etc. in?

This leads me to think that we should just punt to the developer.  In 
this case, there would be no data model for claim types and everything 
would be driven simply off of UserModel.attributes.  Develoeprs would 
have to extend the admin console and account themes and we would provide 
a template for referencing UserModel.attribute data within Angular HTML 
(admin console) or Framemaker (account service, registration page).

I know Stian talked about validation, but I think this could be added on 
after the fact via an AttributeValidator and again tied to a specific 
UserModel.attribute.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bastian.ike at aoe.com  Fri Feb 20 02:22:23 2015
From: bastian.ike at aoe.com (Bastian Ike)
Date: Fri, 20 Feb 2015 08:22:23 +0100
Subject: [keycloak-dev] Multiple XSS vulnerabilities in Keycloak
Message-ID: <D10C9F3F.456F%bastian.ike@aoe.com>

Hi together,

Yesterday I found two XSS vulnerabilities in Keycloak (after a quick view, there might be more).
I was wondering who I should contact about details so we can work together to resolve these issues.


Thanks,
Bastian
[cid:BF075044-5F71-4F12-AE62-AB2296BF7131]

Bastian Ike
Magento Developer


AOE GmbH
Kirchgasse 6
65185 Wiesbaden
Germany

Tel. +49 6122 70 70 7 -0
Fax. +49 6122 70 70 7 -399


e-Mail: bastian.ike at aoe.com
Web: http://www.aoe.com<http://www.aoe.com/>



Pflichtangaben laut Handelsgesetz ?37a / Aktiengesetz ?35a

USt-ID Nr.: DE250247455
Handelsregister: Wiesbaden B
Handelsregister Nr.: 22567

Stammsitz: Wiesbaden
Creditreform: 625.0209354
Gesch?ftsf?hrer: Kian Toyouri Gould


Diese E-Mail Nachricht enth?lt vertrauliche und/oder rechtlich gesch?tzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt?mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail.
This e-mail message may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150220/786294a5/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 79FD24C9-5B11-4B19-B23C-A41C892D877F[1].png
Type: image/png
Size: 24139 bytes
Desc: 79FD24C9-5B11-4B19-B23C-A41C892D877F[1].png
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150220/786294a5/attachment-0001.png 

From stian at redhat.com  Fri Feb 20 03:18:30 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 20 Feb 2015 03:18:30 -0500 (EST)
Subject: [keycloak-dev] don't look good on ipad
In-Reply-To: <54E63E91.8000109@redhat.com>
References: <54E556A8.6020306@redhat.com>
	<1579412596.10002453.1424326065520.JavaMail.zimbra@redhat.com>
	<54E63E91.8000109@redhat.com>
Message-ID: <1436769841.11344938.1424420310638.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, February 19, 2015 8:50:41 PM
> Subject: Re: [keycloak-dev] don't look good on ipad
> 
> To know what it looks like on ipad, got to applications screen and
> shorten the width of the browser until you see the left menu on top of
> the application list.

Yeah, the admin console doesn't work well at all on mobiles. I had a play with aligning with PatternFly a while back, it makes much better use of space and scales better on mobiles:

  https://issues.jboss.org/browse/KEYCLOAK-887

Also, have a look at PatternFly example layouts:

  https://www.patternfly.org/wp-content/uploads/patternfly/tests/basic.html



> 
> On 2/19/2015 1:07 AM, Stian Thorgersen wrote:
> > What doesn't look good?
> >
> > Login form should work well, if it doesn't let me know and I'll look into
> > it. Admin console and account management needs some love, especially with
> > regards to mobile. PatternFly/RCUE does this better than we do atm, so
> > re-aligning with them should do the trick, which we need to do any ways.
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, February 19, 2015 4:21:12 AM
> >> Subject: [keycloak-dev] don't look good on ipad
> >>
> >> Any way we can get some designer to do some quick work to make things
> >> look right on ipad?
> >> --
> >> 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 mposolda at redhat.com  Fri Feb 20 03:19:49 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 20 Feb 2015 09:19:49 +0100
Subject: [keycloak-dev] 1.2.0.Beta1 release
In-Reply-To: <54E63E36.9020605@redhat.com>
References: <219667017.10512611.1424348078721.JavaMail.zimbra@redhat.com>
	<54E63E36.9020605@redhat.com>
Message-ID: <54E6EE25.5050909@redhat.com>

I see what you mean. Tomorrow I had two 2,5 hours meetings and some 
other errands, so it was kind of "no real work" day for me ;-)

The second one was with jboss.org team. Good thing is that they're happy 
with Keycloak and would prefer it instead of cas. Few things will be 
needed to add/fix in Keycloak, but looks there is no major missing 
feature, which they need and we don't have.

Marek

On 19.2.2015 20:49, Bill Burke wrote:
>
> On 2/19/2015 7:14 AM, Stian Thorgersen wrote:
>> For 1.2.0.Beta1 we should at least include:
>>
>> * Custom claims
> Still awhile aways.  Keep get interrupted by emails, phone, kids (they
> have winter vacation), meetings, etc...
>
>


From mposolda at redhat.com  Fri Feb 20 03:20:46 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 20 Feb 2015 09:20:46 +0100
Subject: [keycloak-dev] 1.2.0.Beta1 release
In-Reply-To: <54E6EE25.5050909@redhat.com>
References: <219667017.10512611.1424348078721.JavaMail.zimbra@redhat.com>	<54E63E36.9020605@redhat.com>
	<54E6EE25.5050909@redhat.com>
Message-ID: <54E6EE5E.1030900@redhat.com>

Oops, I meant "yesterday" :-)


On 20.2.2015 09:19, Marek Posolda wrote:
> I see what you mean. Tomorrow I had two 2,5 hours meetings and some
> other errands, so it was kind of "no real work" day for me ;-)
>
> The second one was with jboss.org team. Good thing is that they're happy
> with Keycloak and would prefer it instead of cas. Few things will be
> needed to add/fix in Keycloak, but looks there is no major missing
> feature, which they need and we don't have.
>
> Marek
>
> On 19.2.2015 20:49, Bill Burke wrote:
>> On 2/19/2015 7:14 AM, Stian Thorgersen wrote:
>>> For 1.2.0.Beta1 we should at least include:
>>>
>>> * Custom claims
>> Still awhile aways.  Keep get interrupted by emails, phone, kids (they
>> have winter vacation), meetings, etc...
>>
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Fri Feb 20 03:22:00 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 20 Feb 2015 03:22:00 -0500 (EST)
Subject: [keycloak-dev] session_state changed to ClientSession id?
In-Reply-To: <54E63F88.8010809@redhat.com>
References: <54E557BC.5020308@redhat.com>
	<730112168.10005544.1424326227949.JavaMail.zimbra@redhat.com>
	<54E63F88.8010809@redhat.com>
Message-ID: <254655186.11347444.1424420520250.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, February 19, 2015 8:54:48 PM
> Subject: Re: [keycloak-dev] session_state changed to ClientSession id?
> 
> 
> 
> On 2/19/2015 1:10 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, February 19, 2015 4:25:48 AM
> >> Subject: [keycloak-dev] session_state changed to ClientSession id?
> >>
> >> Can I change the session_state in the access token (and refresh token)
> >> to point to ClientSession id instead?  Right now it points to the user
> >> session id.
> >
> > What's the benefits of doing that?
> >
> > It might have some impact on the Infinispan provider. For best performance
> > user sessions should be retrieved by id, which we won't be able to do if
> > we don't have it.
> >
> 
> Access and refresh tokens should be associated with a client session so
> that we can track back an audit.  For claim mapping, I'm also allowing
> admins to map client session notes into the token.  There might be
> temporary protocol specific information stored there.
> 
> I can just add a new client_session claim if needed.

If everything changes to lookup by client session id it should work fine. It would require a bit of tinkering though.

On a related note would it make sense to create a single client session per client per user session? For example as the admin console doesn't store tokens (and any client using keycloak.js is the same) a new client session is created if a user refreshes the page.

> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From mposolda at redhat.com  Fri Feb 20 03:38:15 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 20 Feb 2015 09:38:15 +0100
Subject: [keycloak-dev] session_state changed to ClientSession id?
In-Reply-To: <254655186.11347444.1424420520250.JavaMail.zimbra@redhat.com>
References: <54E557BC.5020308@redhat.com>	<730112168.10005544.1424326227949.JavaMail.zimbra@redhat.com>	<54E63F88.8010809@redhat.com>
	<254655186.11347444.1424420520250.JavaMail.zimbra@redhat.com>
Message-ID: <54E6F277.2020701@redhat.com>

On 20.2.2015 09:22, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Thursday, February 19, 2015 8:54:48 PM
>> Subject: Re: [keycloak-dev] session_state changed to ClientSession id?
>>
>>
>>
>> On 2/19/2015 1:10 AM, Stian Thorgersen wrote:
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Thursday, February 19, 2015 4:25:48 AM
>>>> Subject: [keycloak-dev] session_state changed to ClientSession id?
>>>>
>>>> Can I change the session_state in the access token (and refresh token)
>>>> to point to ClientSession id instead?  Right now it points to the user
>>>> session id.
>>> What's the benefits of doing that?
>>>
>>> It might have some impact on the Infinispan provider. For best performance
>>> user sessions should be retrieved by id, which we won't be able to do if
>>> we don't have it.
>>>
>> Access and refresh tokens should be associated with a client session so
>> that we can track back an audit.  For claim mapping, I'm also allowing
>> admins to map client session notes into the token.  There might be
>> temporary protocol specific information stored there.
>>
>> I can just add a new client_session claim if needed.
> If everything changes to lookup by client session id it should work fine. It would require a bit of tinkering though.
It looks to me that we may need new client_session claim? For example 
KEYCLOAK_IDENTITY cookie is not associated with any Client, but it needs 
to store id of UserSessionModel to verify if user session associated 
with cookie is still valid.
>
> On a related note would it make sense to create a single client session per client per user session? For example as the admin console doesn't store tokens (and any client using keycloak.js is the same) a new client session is created if a user refreshes the page.
+1

Marek

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


From stian at redhat.com  Fri Feb 20 04:59:26 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 20 Feb 2015 04:59:26 -0500 (EST)
Subject: [keycloak-dev] session_state changed to ClientSession id?
In-Reply-To: <54E6F277.2020701@redhat.com>
References: <54E557BC.5020308@redhat.com>
	<730112168.10005544.1424326227949.JavaMail.zimbra@redhat.com>
	<54E63F88.8010809@redhat.com>
	<254655186.11347444.1424420520250.JavaMail.zimbra@redhat.com>
	<54E6F277.2020701@redhat.com>
Message-ID: <1192660591.11423661.1424426366513.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, February 20, 2015 9:38:15 AM
> Subject: Re: [keycloak-dev] session_state changed to ClientSession id?
> 
> On 20.2.2015 09:22, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, February 19, 2015 8:54:48 PM
> >> Subject: Re: [keycloak-dev] session_state changed to ClientSession id?
> >>
> >>
> >>
> >> On 2/19/2015 1:10 AM, Stian Thorgersen wrote:
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Thursday, February 19, 2015 4:25:48 AM
> >>>> Subject: [keycloak-dev] session_state changed to ClientSession id?
> >>>>
> >>>> Can I change the session_state in the access token (and refresh token)
> >>>> to point to ClientSession id instead?  Right now it points to the user
> >>>> session id.
> >>> What's the benefits of doing that?
> >>>
> >>> It might have some impact on the Infinispan provider. For best
> >>> performance
> >>> user sessions should be retrieved by id, which we won't be able to do if
> >>> we don't have it.
> >>>
> >> Access and refresh tokens should be associated with a client session so
> >> that we can track back an audit.  For claim mapping, I'm also allowing
> >> admins to map client session notes into the token.  There might be
> >> temporary protocol specific information stored there.
> >>
> >> I can just add a new client_session claim if needed.
> > If everything changes to lookup by client session id it should work fine.
> > It would require a bit of tinkering though.
> It looks to me that we may need new client_session claim? For example
> KEYCLOAK_IDENTITY cookie is not associated with any Client, but it needs
> to store id of UserSessionModel to verify if user session associated
> with cookie is still valid.

True, same goes for the iframe and if we add a session status endpoint. Basically, we'll need to be able to lookup by user id, but maybe if we split into two caches we can do both and still keep good performance?

> >
> > On a related note would it make sense to create a single client session per
> > client per user session? For example as the admin console doesn't store
> > tokens (and any client using keycloak.js is the same) a new client session
> > is created if a user refreshes the page.
> +1
> 
> Marek
> 
> >
> >> --
> >> 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 Feb 20 07:42:18 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 20 Feb 2015 13:42:18 +0100
Subject: [keycloak-dev] session_state changed to ClientSession id?
In-Reply-To: <1192660591.11423661.1424426366513.JavaMail.zimbra@redhat.com>
References: <54E557BC.5020308@redhat.com>
	<730112168.10005544.1424326227949.JavaMail.zimbra@redhat.com>
	<54E63F88.8010809@redhat.com>
	<254655186.11347444.1424420520250.JavaMail.zimbra@redhat.com>
	<54E6F277.2020701@redhat.com>
	<1192660591.11423661.1424426366513.JavaMail.zimbra@redhat.com>
Message-ID: <54E72BAA.8090108@redhat.com>

On 20.2.2015 10:59, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Friday, February 20, 2015 9:38:15 AM
>> Subject: Re: [keycloak-dev] session_state changed to ClientSession id?
>>
>> On 20.2.2015 09:22, Stian Thorgersen wrote:
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Thursday, February 19, 2015 8:54:48 PM
>>>> Subject: Re: [keycloak-dev] session_state changed to ClientSession id?
>>>>
>>>>
>>>>
>>>> On 2/19/2015 1:10 AM, Stian Thorgersen wrote:
>>>>> ----- Original Message -----
>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>> Sent: Thursday, February 19, 2015 4:25:48 AM
>>>>>> Subject: [keycloak-dev] session_state changed to ClientSession id?
>>>>>>
>>>>>> Can I change the session_state in the access token (and refresh token)
>>>>>> to point to ClientSession id instead?  Right now it points to the user
>>>>>> session id.
>>>>> What's the benefits of doing that?
>>>>>
>>>>> It might have some impact on the Infinispan provider. For best
>>>>> performance
>>>>> user sessions should be retrieved by id, which we won't be able to do if
>>>>> we don't have it.
>>>>>
>>>> Access and refresh tokens should be associated with a client session so
>>>> that we can track back an audit.  For claim mapping, I'm also allowing
>>>> admins to map client session notes into the token.  There might be
>>>> temporary protocol specific information stored there.
>>>>
>>>> I can just add a new client_session claim if needed.
>>> If everything changes to lookup by client session id it should work fine.
>>> It would require a bit of tinkering though.
>> It looks to me that we may need new client_session claim? For example
>> KEYCLOAK_IDENTITY cookie is not associated with any Client, but it needs
>> to store id of UserSessionModel to verify if user session associated
>> with cookie is still valid.
> True, same goes for the iframe and if we add a session status endpoint. Basically, we'll need to be able to lookup by user id, but maybe if we split into two caches we can do both and still keep good performance?
You mean split sessionCache in InfinispanUserSessionProvider into two 
caches for userSessions and clientSessions? I am not seeing any issue 
with that.

It will probably improve the performance anyway as map-reduce tasks 
won't need to iterate over all sessions and filter by type like this: 
https://github.com/keycloak/keycloak/blob/master/model/sessions-infinispan/src/main/java/org/keycloak/models/sessions/infinispan/mapreduce/UserSessionMapper.java#L55

Marek
>
>>> On a related note would it make sense to create a single client session per
>>> client per user session? For example as the admin console doesn't store
>>> tokens (and any client using keycloak.js is the same) a new client session
>>> is created if a user refreshes the page.
>> +1
>>
>> Marek
>>
>>>> --
>>>> 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 Feb 20 07:48:09 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 20 Feb 2015 07:48:09 -0500
Subject: [keycloak-dev] session_state changed to ClientSession id?
In-Reply-To: <254655186.11347444.1424420520250.JavaMail.zimbra@redhat.com>
References: <54E557BC.5020308@redhat.com>
	<730112168.10005544.1424326227949.JavaMail.zimbra@redhat.com>
	<54E63F88.8010809@redhat.com>
	<254655186.11347444.1424420520250.JavaMail.zimbra@redhat.com>
Message-ID: <54E72D09.1000903@redhat.com>



On 2/20/2015 3:22 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Thursday, February 19, 2015 8:54:48 PM
>> Subject: Re: [keycloak-dev] session_state changed to ClientSession id?
>>
>>
>>
>> On 2/19/2015 1:10 AM, Stian Thorgersen wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Thursday, February 19, 2015 4:25:48 AM
>>>> Subject: [keycloak-dev] session_state changed to ClientSession id?
>>>>
>>>> Can I change the session_state in the access token (and refresh token)
>>>> to point to ClientSession id instead?  Right now it points to the user
>>>> session id.
>>>
>>> What's the benefits of doing that?
>>>
>>> It might have some impact on the Infinispan provider. For best performance
>>> user sessions should be retrieved by id, which we won't be able to do if
>>> we don't have it.
>>>
>>
>> Access and refresh tokens should be associated with a client session so
>> that we can track back an audit.  For claim mapping, I'm also allowing
>> admins to map client session notes into the token.  There might be
>> temporary protocol specific information stored there.
>>
>> I can just add a new client_session claim if needed.
>
> If everything changes to lookup by client session id it should work fine. It would require a bit of tinkering though.
>
> On a related note would it make sense to create a single client session per client per user session? For example as the admin console doesn't store tokens (and any client using keycloak.js is the same) a new client session is created if a user refreshes the page.
>

Refreshing the page nor refresh token causes a new client session to be 
submitted.  If a completely different browser is used to visit the app, 
then yes, there is a different client session.  In that case, you still 
want a new client session to be created because it would be a totally 
different HttpSession for the client.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Fri Feb 20 07:50:12 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 20 Feb 2015 07:50:12 -0500
Subject: [keycloak-dev] don't look good on ipad
In-Reply-To: <1436769841.11344938.1424420310638.JavaMail.zimbra@redhat.com>
References: <54E556A8.6020306@redhat.com>
	<1579412596.10002453.1424326065520.JavaMail.zimbra@redhat.com>
	<54E63E91.8000109@redhat.com>
	<1436769841.11344938.1424420310638.JavaMail.zimbra@redhat.com>
Message-ID: <54E72D84.9060907@redhat.com>

I don't see iOS on that page.

On 2/20/2015 3:18 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Thursday, February 19, 2015 8:50:41 PM
>> Subject: Re: [keycloak-dev] don't look good on ipad
>>
>> To know what it looks like on ipad, got to applications screen and
>> shorten the width of the browser until you see the left menu on top of
>> the application list.
>
> Yeah, the admin console doesn't work well at all on mobiles. I had a play with aligning with PatternFly a while back, it makes much better use of space and scales better on mobiles:
>
>    https://issues.jboss.org/browse/KEYCLOAK-887
>
> Also, have a look at PatternFly example layouts:
>
>    https://www.patternfly.org/wp-content/uploads/patternfly/tests/basic.html
>
>
>
>>
>> On 2/19/2015 1:07 AM, Stian Thorgersen wrote:
>>> What doesn't look good?
>>>
>>> Login form should work well, if it doesn't let me know and I'll look into
>>> it. Admin console and account management needs some love, especially with
>>> regards to mobile. PatternFly/RCUE does this better than we do atm, so
>>> re-aligning with them should do the trick, which we need to do any ways.
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Thursday, February 19, 2015 4:21:12 AM
>>>> Subject: [keycloak-dev] don't look good on ipad
>>>>
>>>> Any way we can get some designer to do some quick work to make things
>>>> look right on ipad?
>>>> --
>>>> 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  Fri Feb 20 07:51:00 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 20 Feb 2015 07:51:00 -0500 (EST)
Subject: [keycloak-dev] distribution of adapters
In-Reply-To: <54E6177C.3060803@redhat.com>
References: <54E6177C.3060803@redhat.com>
Message-ID: <465601616.11594828.1424436660541.JavaMail.zimbra@redhat.com>

My concerns with releasing all adapters simultaneously as the server are:

* We need to release all adapters, even those that haven't changed
* Users will believe they have to update all their applications, even those where the adapter has no changes

I believe we should have separate repo, documentation and examples for adapters. However, I have no issue with grouping related adapters into one (for example all Java adapters in one repo). Reasoning behind this is that there are different build tools, expected documentation formats, example formats, etc. depending on the programming language.

We already have Java, NodeJS, JavaScript and Jenkins adapters. They are all released differently (Java in Maven, JS in Bower, NodeJS in god knows where!) so we already have an overhead of doing releases, IMO having independent releases would actually simplify things. 

With regards to users I believe it's a pretty demanding requirement to expect a user to upgrade the server and all applications in one go. They may not even have control over this, for example one company provides the KC server, while another provides applications. We need to make sure there is backwards compatibility with adapters and that they can be updated independently and also it should be clear what a user is expected to upgrade when. 

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, February 19, 2015 6:03:56 PM
> Subject: [keycloak-dev] distribution of adapters
> 
> I think there is a different here between community and product.
> 
> In community:
> * Adapters should each have a separate download.  This has a side effect
> of showing us which adapters are popular (not to mention increasing our
> download numers ;)
> * All adapters are released simultaneously with a server release
> * Adapters can have individual patch releases.
> * If we want to release a patched adapter, use a micro version scheme.
> First 3 numbers correspond to the keycloak version the adapter was built
> against.  Last number is the patch number of the adapter:
> 
> We release Keycloak 1.1.0:
> - keycloak-jetty-1.1.0.0
> Werelease a patch of jetty adapter for keycloak 1.1.0
> - keycloak-jetty-1.1.0.1
> 
> I'm not sure how all that effects product and git branches.  Ideally
> you'd have matching branches for major keycloak server release for the
> adapter.
> 
> i.e.
> 
> Keycloak_server_branch_1.1.x
> Keycloak_adapters_branch_1.1.x
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Fri Feb 20 07:53:10 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 20 Feb 2015 07:53:10 -0500 (EST)
Subject: [keycloak-dev] don't look good on ipad
In-Reply-To: <54E72D84.9060907@redhat.com>
References: <54E556A8.6020306@redhat.com>
	<1579412596.10002453.1424326065520.JavaMail.zimbra@redhat.com>
	<54E63E91.8000109@redhat.com>
	<1436769841.11344938.1424420310638.JavaMail.zimbra@redhat.com>
	<54E72D84.9060907@redhat.com>
Message-ID: <467743960.11595765.1424436790045.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, February 20, 2015 1:50:12 PM
> Subject: Re: [keycloak-dev] don't look good on ipad
> 
> I don't see iOS on that page.

Try the different templates and scaling the page. It's all responsive so it's designed to work well on all resolutions ranging from phones to high-dpi monitors. It even hides the menu with a single button when you go small enough.

> 
> On 2/20/2015 3:18 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, February 19, 2015 8:50:41 PM
> >> Subject: Re: [keycloak-dev] don't look good on ipad
> >>
> >> To know what it looks like on ipad, got to applications screen and
> >> shorten the width of the browser until you see the left menu on top of
> >> the application list.
> >
> > Yeah, the admin console doesn't work well at all on mobiles. I had a play
> > with aligning with PatternFly a while back, it makes much better use of
> > space and scales better on mobiles:
> >
> >    https://issues.jboss.org/browse/KEYCLOAK-887
> >
> > Also, have a look at PatternFly example layouts:
> >
> >    https://www.patternfly.org/wp-content/uploads/patternfly/tests/basic.html
> >
> >
> >
> >>
> >> On 2/19/2015 1:07 AM, Stian Thorgersen wrote:
> >>> What doesn't look good?
> >>>
> >>> Login form should work well, if it doesn't let me know and I'll look into
> >>> it. Admin console and account management needs some love, especially with
> >>> regards to mobile. PatternFly/RCUE does this better than we do atm, so
> >>> re-aligning with them should do the trick, which we need to do any ways.
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Thursday, February 19, 2015 4:21:12 AM
> >>>> Subject: [keycloak-dev] don't look good on ipad
> >>>>
> >>>> Any way we can get some designer to do some quick work to make things
> >>>> look right on ipad?
> >>>> --
> >>>> 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  Fri Feb 20 08:01:36 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 20 Feb 2015 08:01:36 -0500 (EST)
Subject: [keycloak-dev] session_state changed to ClientSession id?
In-Reply-To: <54E72D09.1000903@redhat.com>
References: <54E557BC.5020308@redhat.com>
	<730112168.10005544.1424326227949.JavaMail.zimbra@redhat.com>
	<54E63F88.8010809@redhat.com>
	<254655186.11347444.1424420520250.JavaMail.zimbra@redhat.com>
	<54E72D09.1000903@redhat.com>
Message-ID: <146343627.11603803.1424437296549.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, February 20, 2015 1:48:09 PM
> Subject: Re: [keycloak-dev] session_state changed to ClientSession id?
> 
> 
> 
> On 2/20/2015 3:22 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, February 19, 2015 8:54:48 PM
> >> Subject: Re: [keycloak-dev] session_state changed to ClientSession id?
> >>
> >>
> >>
> >> On 2/19/2015 1:10 AM, Stian Thorgersen wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Thursday, February 19, 2015 4:25:48 AM
> >>>> Subject: [keycloak-dev] session_state changed to ClientSession id?
> >>>>
> >>>> Can I change the session_state in the access token (and refresh token)
> >>>> to point to ClientSession id instead?  Right now it points to the user
> >>>> session id.
> >>>
> >>> What's the benefits of doing that?
> >>>
> >>> It might have some impact on the Infinispan provider. For best
> >>> performance
> >>> user sessions should be retrieved by id, which we won't be able to do if
> >>> we don't have it.
> >>>
> >>
> >> Access and refresh tokens should be associated with a client session so
> >> that we can track back an audit.  For claim mapping, I'm also allowing
> >> admins to map client session notes into the token.  There might be
> >> temporary protocol specific information stored there.
> >>
> >> I can just add a new client_session claim if needed.
> >
> > If everything changes to lookup by client session id it should work fine.
> > It would require a bit of tinkering though.
> >
> > On a related note would it make sense to create a single client session per
> > client per user session? For example as the admin console doesn't store
> > tokens (and any client using keycloak.js is the same) a new client session
> > is created if a user refreshes the page.
> >
> 
> Refreshing the page nor refresh token causes a new client session to be
> submitted.  If a completely different browser is used to visit the app,
> then yes, there is a different client session.  In that case, you still
> want a new client session to be created because it would be a totally
> different HttpSession for the client.

I'm pretty sure it does. keycloak.js only keeps the token in memory and if you refresh the page it's lost. Then it'll redirect to the login page, get a new code, swap for token, etc.. We could potentially store the refresh token in local storage, but not sure if that's a good idea.

> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From mposolda at redhat.com  Fri Feb 20 09:13:32 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 20 Feb 2015 15:13:32 +0100
Subject: [keycloak-dev] session_state changed to ClientSession id?
In-Reply-To: <54E72D09.1000903@redhat.com>
References: <54E557BC.5020308@redhat.com>	<730112168.10005544.1424326227949.JavaMail.zimbra@redhat.com>	<54E63F88.8010809@redhat.com>	<254655186.11347444.1424420520250.JavaMail.zimbra@redhat.com>
	<54E72D09.1000903@redhat.com>
Message-ID: <54E7410C.1050002@redhat.com>

On 20.2.2015 13:48, Bill Burke wrote:
>
> On 2/20/2015 3:22 AM, Stian Thorgersen wrote:
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Thursday, February 19, 2015 8:54:48 PM
>>> Subject: Re: [keycloak-dev] session_state changed to ClientSession id?
>>>
>>>
>>>
>>> On 2/19/2015 1:10 AM, Stian Thorgersen wrote:
>>>>
>>>> ----- Original Message -----
>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>> To: keycloak-dev at lists.jboss.org
>>>>> Sent: Thursday, February 19, 2015 4:25:48 AM
>>>>> Subject: [keycloak-dev] session_state changed to ClientSession id?
>>>>>
>>>>> Can I change the session_state in the access token (and refresh token)
>>>>> to point to ClientSession id instead?  Right now it points to the user
>>>>> session id.
>>>> What's the benefits of doing that?
>>>>
>>>> It might have some impact on the Infinispan provider. For best performance
>>>> user sessions should be retrieved by id, which we won't be able to do if
>>>> we don't have it.
>>>>
>>> Access and refresh tokens should be associated with a client session so
>>> that we can track back an audit.  For claim mapping, I'm also allowing
>>> admins to map client session notes into the token.  There might be
>>> temporary protocol specific information stored there.
>>>
>>> I can just add a new client_session claim if needed.
>> If everything changes to lookup by client session id it should work fine. It would require a bit of tinkering though.
>>
>> On a related note would it make sense to create a single client session per client per user session? For example as the admin console doesn't store tokens (and any client using keycloak.js is the same) a new client session is created if a user refreshes the page.
>>
> Refreshing the page nor refresh token causes a new client session to be
> submitted.  If a completely different browser is used to visit the app,
> then yes, there is a different client session.  In that case, you still
> want a new client session to be created because it would be a totally
> different HttpSession for the client.
>
>
Yes, but with different browser it's also completely different 
UserSession. It makes sense to me to have single ClientSession per: 
Client + UserSession.

But not per: Client + User

So if same user visits admin console from 2 different browsers, it 
should be 2 client sessions. If he just refresh admin console from the 
same browser, it's same UserSession and hence 1 client session.

Marek

From mposolda at redhat.com  Fri Feb 20 09:14:54 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 20 Feb 2015 15:14:54 +0100
Subject: [keycloak-dev] session_state changed to ClientSession id?
In-Reply-To: <146343627.11603803.1424437296549.JavaMail.zimbra@redhat.com>
References: <54E557BC.5020308@redhat.com>	<730112168.10005544.1424326227949.JavaMail.zimbra@redhat.com>	<54E63F88.8010809@redhat.com>	<254655186.11347444.1424420520250.JavaMail.zimbra@redhat.com>	<54E72D09.1000903@redhat.com>
	<146343627.11603803.1424437296549.JavaMail.zimbra@redhat.com>
Message-ID: <54E7415E.8090006@redhat.com>

On 20.2.2015 14:01, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Friday, February 20, 2015 1:48:09 PM
>> Subject: Re: [keycloak-dev] session_state changed to ClientSession id?
>>
>>
>>
>> On 2/20/2015 3:22 AM, Stian Thorgersen wrote:
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Thursday, February 19, 2015 8:54:48 PM
>>>> Subject: Re: [keycloak-dev] session_state changed to ClientSession id?
>>>>
>>>>
>>>>
>>>> On 2/19/2015 1:10 AM, Stian Thorgersen wrote:
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>> Sent: Thursday, February 19, 2015 4:25:48 AM
>>>>>> Subject: [keycloak-dev] session_state changed to ClientSession id?
>>>>>>
>>>>>> Can I change the session_state in the access token (and refresh token)
>>>>>> to point to ClientSession id instead?  Right now it points to the user
>>>>>> session id.
>>>>> What's the benefits of doing that?
>>>>>
>>>>> It might have some impact on the Infinispan provider. For best
>>>>> performance
>>>>> user sessions should be retrieved by id, which we won't be able to do if
>>>>> we don't have it.
>>>>>
>>>> Access and refresh tokens should be associated with a client session so
>>>> that we can track back an audit.  For claim mapping, I'm also allowing
>>>> admins to map client session notes into the token.  There might be
>>>> temporary protocol specific information stored there.
>>>>
>>>> I can just add a new client_session claim if needed.
>>> If everything changes to lookup by client session id it should work fine.
>>> It would require a bit of tinkering though.
>>>
>>> On a related note would it make sense to create a single client session per
>>> client per user session? For example as the admin console doesn't store
>>> tokens (and any client using keycloak.js is the same) a new client session
>>> is created if a user refreshes the page.
>>>
>> Refreshing the page nor refresh token causes a new client session to be
>> submitted.  If a completely different browser is used to visit the app,
>> then yes, there is a different client session.  In that case, you still
>> want a new client session to be created because it would be a totally
>> different HttpSession for the client.
> I'm pretty sure it does. keycloak.js only keeps the token in memory and if you refresh the page it's lost. Then it'll redirect to the login page, get a new code, swap for token, etc.. We could potentially store the refresh token in local storage, but not sure if that's a good idea.
Isn't this vulnerability to some attacks? Can't some "evil" application 
executed from different browser tab read the token from the local storage?

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


From stian at redhat.com  Fri Feb 20 09:19:32 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 20 Feb 2015 09:19:32 -0500 (EST)
Subject: [keycloak-dev] session_state changed to ClientSession id?
In-Reply-To: <54E7415E.8090006@redhat.com>
References: <54E557BC.5020308@redhat.com>
	<730112168.10005544.1424326227949.JavaMail.zimbra@redhat.com>
	<54E63F88.8010809@redhat.com>
	<254655186.11347444.1424420520250.JavaMail.zimbra@redhat.com>
	<54E72D09.1000903@redhat.com>
	<146343627.11603803.1424437296549.JavaMail.zimbra@redhat.com>
	<54E7415E.8090006@redhat.com>
Message-ID: <946855223.11669572.1424441972253.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, February 20, 2015 3:14:54 PM
> Subject: Re: [keycloak-dev] session_state changed to ClientSession id?
> 
> On 20.2.2015 14:01, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Friday, February 20, 2015 1:48:09 PM
> >> Subject: Re: [keycloak-dev] session_state changed to ClientSession id?
> >>
> >>
> >>
> >> On 2/20/2015 3:22 AM, Stian Thorgersen wrote:
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>> Cc: keycloak-dev at lists.jboss.org
> >>>> Sent: Thursday, February 19, 2015 8:54:48 PM
> >>>> Subject: Re: [keycloak-dev] session_state changed to ClientSession id?
> >>>>
> >>>>
> >>>>
> >>>> On 2/19/2015 1:10 AM, Stian Thorgersen wrote:
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>> Sent: Thursday, February 19, 2015 4:25:48 AM
> >>>>>> Subject: [keycloak-dev] session_state changed to ClientSession id?
> >>>>>>
> >>>>>> Can I change the session_state in the access token (and refresh token)
> >>>>>> to point to ClientSession id instead?  Right now it points to the user
> >>>>>> session id.
> >>>>> What's the benefits of doing that?
> >>>>>
> >>>>> It might have some impact on the Infinispan provider. For best
> >>>>> performance
> >>>>> user sessions should be retrieved by id, which we won't be able to do
> >>>>> if
> >>>>> we don't have it.
> >>>>>
> >>>> Access and refresh tokens should be associated with a client session so
> >>>> that we can track back an audit.  For claim mapping, I'm also allowing
> >>>> admins to map client session notes into the token.  There might be
> >>>> temporary protocol specific information stored there.
> >>>>
> >>>> I can just add a new client_session claim if needed.
> >>> If everything changes to lookup by client session id it should work fine.
> >>> It would require a bit of tinkering though.
> >>>
> >>> On a related note would it make sense to create a single client session
> >>> per
> >>> client per user session? For example as the admin console doesn't store
> >>> tokens (and any client using keycloak.js is the same) a new client
> >>> session
> >>> is created if a user refreshes the page.
> >>>
> >> Refreshing the page nor refresh token causes a new client session to be
> >> submitted.  If a completely different browser is used to visit the app,
> >> then yes, there is a different client session.  In that case, you still
> >> want a new client session to be created because it would be a totally
> >> different HttpSession for the client.
> > I'm pretty sure it does. keycloak.js only keeps the token in memory and if
> > you refresh the page it's lost. Then it'll redirect to the login page, get
> > a new code, swap for token, etc.. We could potentially store the refresh
> > token in local storage, but not sure if that's a good idea.
> Isn't this vulnerability to some attacks? Can't some "evil" application
> executed from different browser tab read the token from the local storage?

In theory, no. Local storage is only visible to js from the same domain. In reality, not sure as there could be vulnerabilities in browser implementations, although the same would apply to cookies as they are protected by browser in the same way as local storage. 

> 
> Marek
> >
> >>
> >> --
> >> 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 Feb 20 09:30:51 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 20 Feb 2015 09:30:51 -0500
Subject: [keycloak-dev] session_state changed to ClientSession id?
In-Reply-To: <946855223.11669572.1424441972253.JavaMail.zimbra@redhat.com>
References: <54E557BC.5020308@redhat.com>
	<730112168.10005544.1424326227949.JavaMail.zimbra@redhat.com>
	<54E63F88.8010809@redhat.com>
	<254655186.11347444.1424420520250.JavaMail.zimbra@redhat.com>
	<54E72D09.1000903@redhat.com>
	<146343627.11603803.1424437296549.JavaMail.zimbra@redhat.com>
	<54E7415E.8090006@redhat.com>
	<946855223.11669572.1424441972253.JavaMail.zimbra@redhat.com>
Message-ID: <54E7451B.7040508@redhat.com>



On 2/20/2015 9:19 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Friday, February 20, 2015 3:14:54 PM
>> Subject: Re: [keycloak-dev] session_state changed to ClientSession id?
>>
>> On 20.2.2015 14:01, Stian Thorgersen wrote:
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Friday, February 20, 2015 1:48:09 PM
>>>> Subject: Re: [keycloak-dev] session_state changed to ClientSession id?
>>>>
>>>>
>>>>
>>>> On 2/20/2015 3:22 AM, Stian Thorgersen wrote:
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>> Sent: Thursday, February 19, 2015 8:54:48 PM
>>>>>> Subject: Re: [keycloak-dev] session_state changed to ClientSession id?
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2/19/2015 1:10 AM, Stian Thorgersen wrote:
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>>> Sent: Thursday, February 19, 2015 4:25:48 AM
>>>>>>>> Subject: [keycloak-dev] session_state changed to ClientSession id?
>>>>>>>>
>>>>>>>> Can I change the session_state in the access token (and refresh token)
>>>>>>>> to point to ClientSession id instead?  Right now it points to the user
>>>>>>>> session id.
>>>>>>> What's the benefits of doing that?
>>>>>>>
>>>>>>> It might have some impact on the Infinispan provider. For best
>>>>>>> performance
>>>>>>> user sessions should be retrieved by id, which we won't be able to do
>>>>>>> if
>>>>>>> we don't have it.
>>>>>>>
>>>>>> Access and refresh tokens should be associated with a client session so
>>>>>> that we can track back an audit.  For claim mapping, I'm also allowing
>>>>>> admins to map client session notes into the token.  There might be
>>>>>> temporary protocol specific information stored there.
>>>>>>
>>>>>> I can just add a new client_session claim if needed.
>>>>> If everything changes to lookup by client session id it should work fine.
>>>>> It would require a bit of tinkering though.
>>>>>
>>>>> On a related note would it make sense to create a single client session
>>>>> per
>>>>> client per user session? For example as the admin console doesn't store
>>>>> tokens (and any client using keycloak.js is the same) a new client
>>>>> session
>>>>> is created if a user refreshes the page.
>>>>>
>>>> Refreshing the page nor refresh token causes a new client session to be
>>>> submitted.  If a completely different browser is used to visit the app,
>>>> then yes, there is a different client session.  In that case, you still
>>>> want a new client session to be created because it would be a totally
>>>> different HttpSession for the client.
>>> I'm pretty sure it does. keycloak.js only keeps the token in memory and if
>>> you refresh the page it's lost. Then it'll redirect to the login page, get
>>> a new code, swap for token, etc.. We could potentially store the refresh
>>> token in local storage, but not sure if that's a good idea.
>> Isn't this vulnerability to some attacks? Can't some "evil" application
>> executed from different browser tab read the token from the local storage?
>
> In theory, no. Local storage is only visible to js from the same domain. In reality, not sure as there could be vulnerabilities in browser implementations, although the same would apply to cookies as they are protected by browser in the same way as local storage.
>

Another possibility:

client crashes.  User doesn't notice, refreshes or visits a new page, 
login happens again, user doesn't know anything.  Same user session, 
different client session.

Bill

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From supittma at redhat.com  Fri Feb 20 10:05:00 2015
From: supittma at redhat.com (Summers Pittman)
Date: Fri, 20 Feb 2015 10:05:00 -0500
Subject: [keycloak-dev] WildFly integration (READ ME!)
In-Reply-To: <1360543918.10348397.1424334753943.JavaMail.zimbra@redhat.com>
References: <969708031.6108771.1422954530044.JavaMail.zimbra@redhat.com>
	<1360543918.10348397.1424334753943.JavaMail.zimbra@redhat.com>
Message-ID: <54E74D1C.4030600@redhat.com>

On 02/19/2015 03:32 AM, Stian Thorgersen wrote:
> No comments?!
Peanut gallery chiming in; you asked for it ;)

I am not a WildFly developer or administrator.  So read this email as 
the opinions of a talented developer who loves the hell out of using 
KeyCloak and WildFly and sings its praises from the roof tops but has no 
idea what you are talking about.
>
> ----- Original Message -----
>> From: "Stian Thorgersen" <stian at redhat.com>
>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Tuesday, February 3, 2015 10:08:50 AM
>> Subject: [keycloak-dev] WildFly integration (READ ME!)
>>
>> All,
>>
>> We have a few decisions to make in the not so far future. I'm away from
>> Thursday, so let's have a hangout when I get back on the 17th February if
>> that works for everyone.
>>
>> The list of things to discuss includes:
>>
>> * Drop keycloak-server.json - Should we drop our own configuration file and
>> use DMR (standalone.xml)
If on day one enabling KeyCloak in my project was any more complicated 
than dropping a pregenerated file into my WEB-INF directory I would have 
closed the project and never looked back.  -1

>>
>> * Keycloak CLI - Should we create our own or use WildFly CLI
On the one hand the wildfly CLI is black magic.  On the other hand it is 
really well done black magic.  It is very hard to do CLIs well so I 
would like to see the wildfly CLI be used.
>>
>> * Admin operations exposed over DMR - Should we expose none, some or all
>> admin operations over DMR? If we expose all should we deprecate the current
>> REST endpoints?
Is DMR the thing that puts stuff in the WildFly admin UI (I tried to 
read the google result for "wildfly DMR" but it quickly turned into 
turtles all the way down)?

In my experience I don't LIKE using the WildFly admin UI, I would rather 
use the CLI, scripts, etc.  I haven't used the KeyCloak REST endpoints 
and keeping them just increases the attack surface.
>>
>> * Packaging/distribution - How do we distribute Keycloak? Options:
>>    - Full WildFly
>>    - Core/web WildFly
>>    - Overlay/installer/feature-pack to install to existing WF and EAP
>>    - WAR bundle
How about a shell script that examines a WF install directory and does 
all the magic for me or aDocker container?

In general I have not liked the experience of having wildfly bundled 
with a product.  It tends to mess with other servers I have installed 
and be a general PITA to maintain for anything more than the most 
trivial of demos.
>>
>> * How should we deal with providers, themes and keycloak-server.json in
>> domain-mode
>>
>> * MSC all the way - We can deploy directly through the Undertow sub-system
>> instead of deploying a WAR from the sub-system
What is MSC?
>>
>> * Split sub-systems - Should we split the sub-system in two? One for the
>> auth-server and another for the adapter
What are the trade offs?  What will using KeyCloak look like from my POV 
if we split?
>>
>> * Deployable to other containers - Should it be possible to deploy Keycloak
>> to Tomcat, Jetty, Fuse, etc..? One option could be to have reduced features
>> in other containers (for example no client-cert)
The awesomeness of WildFly has forever made web containers look 
insignificant to me.  If Glassfish still had a community edition worth a 
damn I would say target it as well.  I don't know how TomEE is but that 
may be good to support just for a "first one's free" to get people into 
WildFly land.

I don't think Websphere or WebLogic support has ever gotten anyone 
excited about a project.  Honestly they are the technology equivalent of 
taking a cold shower with grandma.
>>
>> Please add any other relevant topics.
>>
>> Next big discussion I want to have is about distribution of adapters, but
>> let's do one at a time ;)
>> _______________________________________________
>> 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


-- 
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.


From psilva at redhat.com  Fri Feb 20 10:18:39 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 20 Feb 2015 10:18:39 -0500 (EST)
Subject: [keycloak-dev] Claims Mapping and Identity Federation
In-Reply-To: <789683904.16770501.1424445162557.JavaMail.zimbra@redhat.com>
Message-ID: <1145060295.16774022.1424445519986.JavaMail.zimbra@redhat.com>

When brokering an identity provider, we also need to map claims in order to properly federate the users identities in Keycloak.

When doing identity federation, we may have different claims from different providers. We may also need to update those claims when re-authenticating with a specific provider. 

Another possible situation is that we may have the same claim (eg.: same name) across different providers. So we need some way to identify this conflict and fix. Or just update the claim specific for a provider.

How that is being considered by the claim mapping that is being developed ?

Regards.
Pedro Igor


From bburke at redhat.com  Fri Feb 20 10:36:31 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 20 Feb 2015 10:36:31 -0500
Subject: [keycloak-dev] Claims Mapping and Identity Federation
In-Reply-To: <1145060295.16774022.1424445519986.JavaMail.zimbra@redhat.com>
References: <1145060295.16774022.1424445519986.JavaMail.zimbra@redhat.com>
Message-ID: <54E7547F.1000405@redhat.com>

I'm still working things out.  Right now I have a realm set of 
ProtocolMappers.  The data model is

protocol (saml or oidc)
protocolMapper (this references a provider)

These 3 are for simple one to one attribute mappings.

protocolClaim
sourceAttributeType
sourceAttribute

For OIDC there will be just one protocolMapper for simple one to one 
claim/attribute mappings.  For SAML there will be a "Friendly 
AttributeStatement" and "URI AttributeStatement" for attribute mappings.

For more complex OIDC stuff, there will be you'll be able to write a 
provider that implements an AccessTokenTransformer interface so that you 
can modify the access token however you want.

For more complex SAML stuff you'll haven multiple transformation points. 
  You'll be able to get access to the SamlBuilder for each saml document 
type.  You also be able to get access to the document model after the 
Builder has created it.

The idea is that we want to have full extension points for use cases we 
haven't seen.

As for Identity Brokering, we'll have something very similar.  For 
OIDC/SAML brokering, we'll have ProtocolMappers that implement a 
SamlImporter or TokenImporter interface and we'll have simple 
claim/assertion to UserModel.attribute mappings, and a more extension 
transformation interface.



On 2/20/2015 10:18 AM, Pedro Igor Silva wrote:
> When brokering an identity provider, we also need to map claims in order to properly federate the users identities in Keycloak.
>
> When doing identity federation, we may have different claims from different providers. We may also need to update those claims when re-authenticating with a specific provider.
>
> Another possible situation is that we may have the same claim (eg.: same name) across different providers. So we need some way to identify this conflict and fix. Or just update the claim specific for a provider.
>
> How that is being considered by the claim mapping that is being developed ?
>
> Regards.
> Pedro Igor
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From psilva at redhat.com  Fri Feb 20 10:46:17 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 20 Feb 2015 10:46:17 -0500 (EST)
Subject: [keycloak-dev] Claims Mapping and Identity Federation
In-Reply-To: <54E7547F.1000405@redhat.com>
References: <1145060295.16774022.1424445519986.JavaMail.zimbra@redhat.com>
	<54E7547F.1000405@redhat.com>
Message-ID: <658865994.16800174.1424447177631.JavaMail.zimbra@redhat.com>

Regarding what you said about claims, going to think on what you said during the weekend. Get back to you on Monday :)

I'm glad that you are already considering making internal code more flexible so we can deal with access tokens, id tokens, saml assertions or whatever is issued by KC prior to return them to service providers. This is also one of the things in my requirements list.

Some comments in line.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, February 20, 2015 1:36:31 PM
> Subject: Re: [keycloak-dev] Claims Mapping and Identity Federation
> 
> I'm still working things out.  Right now I have a realm set of
> ProtocolMappers.  The data model is
> 
> protocol (saml or oidc)
> protocolMapper (this references a provider)
> 
> These 3 are for simple one to one attribute mappings.
> 
> protocolClaim
> sourceAttributeType
> sourceAttribute
> 
> For OIDC there will be just one protocolMapper for simple one to one
> claim/attribute mappings.  For SAML there will be a "Friendly
> AttributeStatement" and "URI AttributeStatement" for attribute mappings.
> 
> For more complex OIDC stuff, there will be you'll be able to write a
> provider that implements an AccessTokenTransformer interface so that you
> can modify the access token however you want.

What about the ID token. I think this guy is the most important in this context.

> 
> For more complex SAML stuff you'll haven multiple transformation points.
>   You'll be able to get access to the SamlBuilder for each saml document
> type.  You also be able to get access to the document model after the
> Builder has created it.
> 
> The idea is that we want to have full extension points for use cases we
> haven't seen.
> 
> As for Identity Brokering, we'll have something very similar.  For
> OIDC/SAML brokering, we'll have ProtocolMappers that implement a
> SamlImporter or TokenImporter interface and we'll have simple
> claim/assertion to UserModel.attribute mappings, and a more extension
> transformation interface.
> 
> 
> 
> On 2/20/2015 10:18 AM, Pedro Igor Silva wrote:
> > When brokering an identity provider, we also need to map claims in order to
> > properly federate the users identities in Keycloak.
> >
> > When doing identity federation, we may have different claims from different
> > providers. We may also need to update those claims when re-authenticating
> > with a specific provider.
> >
> > Another possible situation is that we may have the same claim (eg.: same
> > name) across different providers. So we need some way to identify this
> > conflict and fix. Or just update the claim specific for a provider.
> >
> > How that is being considered by the claim mapping that is being developed ?
> >
> > Regards.
> > Pedro Igor
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From bburke at redhat.com  Fri Feb 20 10:47:39 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 20 Feb 2015 10:47:39 -0500
Subject: [keycloak-dev] How to do default claim mappings?
Message-ID: <54E7571B.6080007@redhat.com>

Per realm and per protocol (saml or OIDC), I'm going to need to register 
a set of default claim mappers into storage.  ProviderFactorys are 
loaded at boot time and each of their init() methods is invoked.  I'm 
thinking of adding a new method to ProviderFactory

void preprocess(KeycloakSessionFactory sessionFactory);

This would be called after all providers have been loaded.  This would 
allow the OIDC and SAML providers to browser every realm to make sure 
the appropriate built in claim mappers have been registered.

I'm also thinking of adding a RealmCreationListener registration method 
on RealmProvider.  Within ProviderFactory.preprocess() components could 
register themselves with the RealmProvider for realm creation events so 
that they could add additional metadata specific to their plugin.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Fri Feb 20 10:50:41 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 20 Feb 2015 10:50:41 -0500
Subject: [keycloak-dev] Claims Mapping and Identity Federation
In-Reply-To: <658865994.16800174.1424447177631.JavaMail.zimbra@redhat.com>
References: <1145060295.16774022.1424445519986.JavaMail.zimbra@redhat.com>
	<54E7547F.1000405@redhat.com>
	<658865994.16800174.1424447177631.JavaMail.zimbra@redhat.com>
Message-ID: <54E757D1.7060409@redhat.com>



On 2/20/2015 10:46 AM, Pedro Igor Silva wrote:
> Regarding what you said about claims, going to think on what you said during the weekend. Get back to you on Monday :)
>
> I'm glad that you are already considering making internal code more flexible so we can deal with access tokens, id tokens, saml assertions or whatever is issued by KC prior to return them to service providers. This is also one of the things in my requirements list.
>

I'm a bit nervous about this as we end up having to expose the entire 
SAML document model to users.  I don't see any way around it though. 
There are so many esoteric SAML features that we won't be able to 
support due to time constraints, yet I want to be able to allow users to 
apply their own extensions to support them.

> Some comments in line.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, February 20, 2015 1:36:31 PM
>> Subject: Re: [keycloak-dev] Claims Mapping and Identity Federation
>
> What about the ID token. I think this guy is the most important in this context.
>

AccessToken extends ID Token. ID Token is created from the access token.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From psilva at redhat.com  Fri Feb 20 11:02:48 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 20 Feb 2015 11:02:48 -0500 (EST)
Subject: [keycloak-dev] Claims Mapping and Identity Federation
In-Reply-To: <54E757D1.7060409@redhat.com>
References: <1145060295.16774022.1424445519986.JavaMail.zimbra@redhat.com>
	<54E7547F.1000405@redhat.com>
	<658865994.16800174.1424447177631.JavaMail.zimbra@redhat.com>
	<54E757D1.7060409@redhat.com>
Message-ID: <1490157627.16811620.1424448168710.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, February 20, 2015 1:50:41 PM
> Subject: Re: [keycloak-dev] Claims Mapping and Identity Federation
> 
> 
> 
> On 2/20/2015 10:46 AM, Pedro Igor Silva wrote:
> > Regarding what you said about claims, going to think on what you said
> > during the weekend. Get back to you on Monday :)
> >
> > I'm glad that you are already considering making internal code more
> > flexible so we can deal with access tokens, id tokens, saml assertions or
> > whatever is issued by KC prior to return them to service providers. This
> > is also one of the things in my requirements list.
> >
> 
> I'm a bit nervous about this as we end up having to expose the entire
> SAML document model to users.  I don't see any way around it though.
> There are so many esoteric SAML features that we won't be able to
> support due to time constraints, yet I want to be able to allow users to
> apply their own extensions to support them.

Don't be. Only in extreme cases users should deal with that. Most of things we can support in OOTB fashion.

And yes, that would bring a lot more flexibility, with a cost. IMO we just need to highlight the consequences to users as they can end up introducing security gaps if they don't know exactly what they are doing.

> 
> > Some comments in line.
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, February 20, 2015 1:36:31 PM
> >> Subject: Re: [keycloak-dev] Claims Mapping and Identity Federation
> >
> > What about the ID token. I think this guy is the most important in this
> > context.
> >
> 
> AccessToken extends ID Token. ID Token is created from the access token.

Yeah, but at the end they are different tokens. Exposed separately to clients. That is why I asked. But I understood what you meant.

> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From psilva at redhat.com  Fri Feb 20 11:07:33 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 20 Feb 2015 11:07:33 -0500 (EST)
Subject: [keycloak-dev] Claims Mapping and Identity Federation
In-Reply-To: <54E7547F.1000405@redhat.com>
References: <1145060295.16774022.1424445519986.JavaMail.zimbra@redhat.com>
	<54E7547F.1000405@redhat.com>
Message-ID: <531418134.16814686.1424448453169.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, February 20, 2015 1:36:31 PM
> Subject: Re: [keycloak-dev] Claims Mapping and Identity Federation
> 
> I'm still working things out.  Right now I have a realm set of
> ProtocolMappers.  The data model is
> 
> protocol (saml or oidc)
> protocolMapper (this references a provider)
> 
> These 3 are for simple one to one attribute mappings.
> 
> protocolClaim
> sourceAttributeType
> sourceAttribute
> 
> For OIDC there will be just one protocolMapper for simple one to one
> claim/attribute mappings.  For SAML there will be a "Friendly
> AttributeStatement" and "URI AttributeStatement" for attribute mappings.

I'm not sure if you really need something different for SAML. The reason is that we can just ask users if what they want to use 'Name' or 'Friendly Name'.

At that end, that is what really matter, right ? Just know the name of the attribute to map to an internal one.

> 
> For more complex OIDC stuff, there will be you'll be able to write a
> provider that implements an AccessTokenTransformer interface so that you
> can modify the access token however you want.
> 
> For more complex SAML stuff you'll haven multiple transformation points.
>   You'll be able to get access to the SamlBuilder for each saml document
> type.  You also be able to get access to the document model after the
> Builder has created it.
> 
> The idea is that we want to have full extension points for use cases we
> haven't seen.
> 
> As for Identity Brokering, we'll have something very similar.  For
> OIDC/SAML brokering, we'll have ProtocolMappers that implement a
> SamlImporter or TokenImporter interface and we'll have simple
> claim/assertion to UserModel.attribute mappings, and a more extension
> transformation interface.
> 
> 
> 
> On 2/20/2015 10:18 AM, Pedro Igor Silva wrote:
> > When brokering an identity provider, we also need to map claims in order to
> > properly federate the users identities in Keycloak.
> >
> > When doing identity federation, we may have different claims from different
> > providers. We may also need to update those claims when re-authenticating
> > with a specific provider.
> >
> > Another possible situation is that we may have the same claim (eg.: same
> > name) across different providers. So we need some way to identify this
> > conflict and fix. Or just update the claim specific for a provider.
> >
> > How that is being considered by the claim mapping that is being developed ?
> >
> > Regards.
> > Pedro Igor
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From ssilvert at redhat.com  Fri Feb 20 12:52:36 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Fri, 20 Feb 2015 12:52:36 -0500
Subject: [keycloak-dev] WildFly integration (READ ME!)
In-Reply-To: <54E74D1C.4030600@redhat.com>
References: <969708031.6108771.1422954530044.JavaMail.zimbra@redhat.com>
	<1360543918.10348397.1424334753943.JavaMail.zimbra@redhat.com>
	<54E74D1C.4030600@redhat.com>
Message-ID: <54E77464.2050400@redhat.com>

On 2/20/2015 10:05 AM, Summers Pittman wrote:
> On 02/19/2015 03:32 AM, Stian Thorgersen wrote:
>> No comments?!
> Peanut gallery chiming in; you asked for it ;)
>
> I am not a WildFly developer or administrator.  So read this email as
> the opinions of a talented developer who loves the hell out of using
> KeyCloak and WildFly and sings its praises from the roof tops but has no
> idea what you are talking about.
Thanks Summers.  Very valuable feedback.
>> ----- Original Message -----
>>> From: "Stian Thorgersen" <stian at redhat.com>
>>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>> Sent: Tuesday, February 3, 2015 10:08:50 AM
>>> Subject: [keycloak-dev] WildFly integration (READ ME!)
>>>
>>> All,
>>>
>>> We have a few decisions to make in the not so far future. I'm away from
>>> Thursday, so let's have a hangout when I get back on the 17th February if
>>> that works for everyone.
>>>
>>> The list of things to discuss includes:
>>>
>>> * Drop keycloak-server.json - Should we drop our own configuration file and
>>> use DMR (standalone.xml)
> If on day one enabling KeyCloak in my project was any more complicated
> than dropping a pregenerated file into my WEB-INF directory I would have
> closed the project and never looked back.  -1
We're talking about the auth server's config rather than the config for 
your project.   For projects, we want to make it even easier to the 
point where you don't even need the json file to get a default 
configuration.
>
>>> * Keycloak CLI - Should we create our own or use WildFly CLI
> On the one hand the wildfly CLI is black magic.  On the other hand it is
> really well done black magic.  It is very hard to do CLIs well so I
> would like to see the wildfly CLI be used.
That's the general feedback we often get from the WildFly community.  I 
agree.
>>> * Admin operations exposed over DMR - Should we expose none, some or all
>>> admin operations over DMR? If we expose all should we deprecate the current
>>> REST endpoints?
> Is DMR the thing that puts stuff in the WildFly admin UI (I tried to
> read the google result for "wildfly DMR" but it quickly turned into
> turtles all the way down)?
At its core, DMR is really just a tiny single-package library where the 
API is just 3 or 4 classes.  Those classes are the "language" spoken to 
make changes to the WildFly management model 
(standalone.xml/domain.xml).  So the question is whether we should hook 
into the management model infrastructure to make Keycloak changes.
>
> In my experience I don't LIKE using the WildFly admin UI, I would rather
> use the CLI, scripts, etc.
Also a typical response.  Again, I agree.  Thankfully, the Keycloak 
admin UI doesn't suffer from the same deficiencies as the WildFly admin UI.

But with Keycloak, we don't yet have a CLI, so there are lots of 
questions around whether we piggyback on WildFly CLI, which means 
adopting DMR in some way.
> I haven't used the KeyCloak REST endpoints
> and keeping them just increases the attack surface.
Do you mean that keeping the REST endpoints would be a good thing or a 
bad thing?  Can we hear more from you on this topic?
>>> * Packaging/distribution - How do we distribute Keycloak? Options:
>>>     - Full WildFly
>>>     - Core/web WildFly
>>>     - Overlay/installer/feature-pack to install to existing WF and EAP
>>>     - WAR bundle
> How about a shell script that examines a WF install directory and does
> all the magic for me or aDocker container?
>
> In general I have not liked the experience of having wildfly bundled
> with a product.  It tends to mess with other servers I have installed
> and be a general PITA to maintain for anything more than the most
> trivial of demos.
Good feedback.
>>> * How should we deal with providers, themes and keycloak-server.json in
>>> domain-mode
>>>
>>> * MSC all the way - We can deploy directly through the Undertow sub-system
>>> instead of deploying a WAR from the sub-system
> What is MSC?
Modular Service Container.  It's the thing that lets you declare and 
register services in WildFly.  But I'm not completely sure what Stian is 
proposing here.
>>> * Split sub-systems - Should we split the sub-system in two? One for the
>>> auth-server and another for the adapter
> What are the trade offs?  What will using KeyCloak look like from my POV
> if we split?
Instead of

subsystem=keycloak/auth-server=main-auth-server
subsystem=keycloak/secure-deployment=foo

you would have

subsystem=keycloak-server/auth-server=main-auth-server
subsystem=keycloak-deployments/secure-deployment=foo

Another option would be to just leave it as it is today and just hide 
the "auth-server" resource for installations where you don't expect the 
auth server to run.

The answer will probably be more a function of how we want to organize 
the code rather than how it will look to the end user.
>>> * Deployable to other containers - Should it be possible to deploy Keycloak
>>> to Tomcat, Jetty, Fuse, etc..? One option could be to have reduced features
>>> in other containers (for example no client-cert)
> The awesomeness of WildFly has forever made web containers look
> insignificant to me.  If Glassfish still had a community edition worth a
> damn I would say target it as well.  I don't know how TomEE is but that
> may be good to support just for a "first one's free" to get people into
> WildFly land.
>
> I don't think Websphere or WebLogic support has ever gotten anyone
> excited about a project.  Honestly they are the technology equivalent of
> taking a cold shower with grandma.
I could have done without that image. :-|

But thanks again!
>>> Please add any other relevant topics.
>>>
>>> Next big discussion I want to have is about distribution of adapters, but
>>> let's do one at a time ;)
>>> _______________________________________________
>>> 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 supittma at redhat.com  Fri Feb 20 13:10:12 2015
From: supittma at redhat.com (Summers Pittman)
Date: Fri, 20 Feb 2015 13:10:12 -0500
Subject: [keycloak-dev] WildFly integration (READ ME!)
In-Reply-To: <54E77464.2050400@redhat.com>
References: <969708031.6108771.1422954530044.JavaMail.zimbra@redhat.com>	<1360543918.10348397.1424334753943.JavaMail.zimbra@redhat.com>	<54E74D1C.4030600@redhat.com>
	<54E77464.2050400@redhat.com>
Message-ID: <54E77884.7050003@redhat.com>

On 02/20/2015 12:52 PM, Stan Silvert wrote:
> On 2/20/2015 10:05 AM, Summers Pittman wrote:
>> On 02/19/2015 03:32 AM, Stian Thorgersen wrote:
>>> No comments?!
>> Peanut gallery chiming in; you asked for it ;)
>>
>> I am not a WildFly developer or administrator.  So read this email as
>> the opinions of a talented developer who loves the hell out of using
>> KeyCloak and WildFly and sings its praises from the roof tops but has no
>> idea what you are talking about.
> Thanks Summers.  Very valuable feedback.
Thanks for taking the time to explain some things I know more than I did 
this morning.
>>> ----- Original Message -----
>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>> Sent: Tuesday, February 3, 2015 10:08:50 AM
>>>> Subject: [keycloak-dev] WildFly integration (READ ME!)
>>>>
>>>> All,
>>>>
>>>> We have a few decisions to make in the not so far future. I'm away from
>>>> Thursday, so let's have a hangout when I get back on the 17th February if
>>>> that works for everyone.
>>>>
>>>> The list of things to discuss includes:
>>>>
>>>> * Drop keycloak-server.json - Should we drop our own configuration file and
>>>> use DMR (standalone.xml)
>> If on day one enabling KeyCloak in my project was any more complicated
>> than dropping a pregenerated file into my WEB-INF directory I would have
>> closed the project and never looked back.  -1
> We're talking about the auth server's config rather than the config for
> your project.   For projects, we want to make it even easier to the
> point where you don't even need the json file to get a default
> configuration.
Ah, that makes more sense.
>>>> * Keycloak CLI - Should we create our own or use WildFly CLI
>> On the one hand the wildfly CLI is black magic.  On the other hand it is
>> really well done black magic.  It is very hard to do CLIs well so I
>> would like to see the wildfly CLI be used.
> That's the general feedback we often get from the WildFly community.  I
> agree.
>>>> * Admin operations exposed over DMR - Should we expose none, some or all
>>>> admin operations over DMR? If we expose all should we deprecate the current
>>>> REST endpoints?
>> Is DMR the thing that puts stuff in the WildFly admin UI (I tried to
>> read the google result for "wildfly DMR" but it quickly turned into
>> turtles all the way down)?
> At its core, DMR is really just a tiny single-package library where the
> API is just 3 or 4 classes.  Those classes are the "language" spoken to
> make changes to the WildFly management model
> (standalone.xml/domain.xml).  So the question is whether we should hook
> into the management model infrastructure to make Keycloak changes.
>> In my experience I don't LIKE using the WildFly admin UI, I would rather
>> use the CLI, scripts, etc.
> Also a typical response.  Again, I agree.  Thankfully, the Keycloak
> admin UI doesn't suffer from the same deficiencies as the WildFly admin UI.
>
> But with Keycloak, we don't yet have a CLI, so there are lots of
> questions around whether we piggyback on WildFly CLI, which means
> adopting DMR in some way.
>> I haven't used the KeyCloak REST endpoints
>> and keeping them just increases the attack surface.
> Do you mean that keeping the REST endpoints would be a good thing or a
> bad thing?  Can we hear more from you on this topic?
I think that if there were a WildFly way to do all of the admin tasks 
that the RESTful endpoints do now it would be good to remove the RESTful 
API to decrease the API surface to just WildFly.  IE fewer things to 
worry about getting hacked and to watch for for vulnerabilities.
>>>> * Packaging/distribution - How do we distribute Keycloak? Options:
>>>>      - Full WildFly
>>>>      - Core/web WildFly
>>>>      - Overlay/installer/feature-pack to install to existing WF and EAP
>>>>      - WAR bundle
>> How about a shell script that examines a WF install directory and does
>> all the magic for me or aDocker container?
>>
>> In general I have not liked the experience of having wildfly bundled
>> with a product.  It tends to mess with other servers I have installed
>> and be a general PITA to maintain for anything more than the most
>> trivial of demos.
> Good feedback.
>>>> * How should we deal with providers, themes and keycloak-server.json in
>>>> domain-mode
>>>>
>>>> * MSC all the way - We can deploy directly through the Undertow sub-system
>>>> instead of deploying a WAR from the sub-system
>> What is MSC?
> Modular Service Container.  It's the thing that lets you declare and
> register services in WildFly.  But I'm not completely sure what Stian is
> proposing here.
>>>> * Split sub-systems - Should we split the sub-system in two? One for the
>>>> auth-server and another for the adapter
>> What are the trade offs?  What will using KeyCloak look like from my POV
>> if we split?
> Instead of
>
> subsystem=keycloak/auth-server=main-auth-server
> subsystem=keycloak/secure-deployment=foo
>
> you would have
>
> subsystem=keycloak-server/auth-server=main-auth-server
> subsystem=keycloak-deployments/secure-deployment=foo
>
> Another option would be to just leave it as it is today and just hide
> the "auth-server" resource for installations where you don't expect the
> auth server to run.
>
> The answer will probably be more a function of how we want to organize
> the code rather than how it will look to the end user.
As a end user it sounds like both work for me.
>>>> * Deployable to other containers - Should it be possible to deploy Keycloak
>>>> to Tomcat, Jetty, Fuse, etc..? One option could be to have reduced features
>>>> in other containers (for example no client-cert)
>> The awesomeness of WildFly has forever made web containers look
>> insignificant to me.  If Glassfish still had a community edition worth a
>> damn I would say target it as well.  I don't know how TomEE is but that
>> may be good to support just for a "first one's free" to get people into
>> WildFly land.
>>
>> I don't think Websphere or WebLogic support has ever gotten anyone
>> excited about a project.  Honestly they are the technology equivalent of
>> taking a cold shower with grandma.
> I could have done without that image. :-|
>
> But thanks again!
YW.
>>>> Please add any other relevant topics.
>>>>
>>>> Next big discussion I want to have is about distribution of adapters, but
>>>> let's do one at a time ;)
>>>> _______________________________________________
>>>> 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


-- 
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.


From bburke at redhat.com  Fri Feb 20 17:48:53 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 20 Feb 2015 17:48:53 -0500
Subject: [keycloak-dev] Claims Mapping and Identity Federation
In-Reply-To: <531418134.16814686.1424448453169.JavaMail.zimbra@redhat.com>
References: <1145060295.16774022.1424445519986.JavaMail.zimbra@redhat.com>
	<54E7547F.1000405@redhat.com>
	<531418134.16814686.1424448453169.JavaMail.zimbra@redhat.com>
Message-ID: <54E7B9D5.3080103@redhat.com>



On 2/20/2015 11:07 AM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, February 20, 2015 1:36:31 PM
>> Subject: Re: [keycloak-dev] Claims Mapping and Identity Federation
>>
>> I'm still working things out.  Right now I have a realm set of
>> ProtocolMappers.  The data model is
>>
>> protocol (saml or oidc)
>> protocolMapper (this references a provider)
>>
>> These 3 are for simple one to one attribute mappings.
>>
>> protocolClaim
>> sourceAttributeType
>> sourceAttribute
>>
>> For OIDC there will be just one protocolMapper for simple one to one
>> claim/attribute mappings.  For SAML there will be a "Friendly
>> AttributeStatement" and "URI AttributeStatement" for attribute mappings.
>
> I'm not sure if you really need something different for SAML. The reason is that we can just ask users if what they want to use 'Name' or 'Friendly Name'.
>
> At that end, that is what really matter, right ? Just know the name of the attribute to map to an internal one.
>

 From looking at SAML document it looks like you can have a attribute 
name types (uri, basic, and unspecified).  I'm not sure of the 
difference between basic and unspecified.  Do you?

Then "Friendly Name" is optional.

Looks like I'll need to add a config map to each 
ProtocolMapper...ugh...wanted to avoid that.

Bill

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From psilva at redhat.com  Fri Feb 20 18:20:15 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 20 Feb 2015 18:20:15 -0500 (EST)
Subject: [keycloak-dev] Claims Mapping and Identity Federation
In-Reply-To: <54E7B9D5.3080103@redhat.com>
References: <1145060295.16774022.1424445519986.JavaMail.zimbra@redhat.com>
	<54E7547F.1000405@redhat.com>
	<531418134.16814686.1424448453169.JavaMail.zimbra@redhat.com>
	<54E7B9D5.3080103@redhat.com>
Message-ID: <1241774320.17157344.1424474415725.JavaMail.zimbra@redhat.com>


----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, February 20, 2015 8:48:53 PM
> Subject: Re: [keycloak-dev] Claims Mapping and Identity Federation
> 
> 
> 
> On 2/20/2015 11:07 AM, Pedro Igor Silva wrote:
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, February 20, 2015 1:36:31 PM
> >> Subject: Re: [keycloak-dev] Claims Mapping and Identity Federation
> >>
> >
> > I'm not sure if you really need something different for SAML. The reason is
> > that we can just ask users if what they want to use 'Name' or 'Friendly
> > Name'.
> >
> > At that end, that is what really matter, right ? Just know the name of the
> > attribute to map to an internal one.
> >
> 
>  From looking at SAML document it looks like you can have a attribute
> name types (uri, basic, and unspecified).  I'm not sure of the
> difference between basic and unspecified.  Do you?

AFAIK these are about how you interpret attributes. I think you can just ignore that in this case. You are more interested in map names than deal on how they should be interpreted. Users will probably know what they are mapping.

> 
> Then "Friendly Name" is optional.

Yeah it is optional, but you can have something like that:

  <saml:Attribute
          NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
          Name="urn:oid:1.3.6.1.4.1.1466.115.121.1.26"
          FriendlyName="mail">

In this case, it is much easier to use FriendlyName when mapping than what is in Name. See, here there is an usage of NameFormat, in this case uri. We can just ignore ...

If I'm correct about what you are doing, users will just say:

Get "mail" from SAML Assertion and create a "email" claim in Keycloak. 

> 
> Looks like I'll need to add a config map to each
> ProtocolMapper...ugh...wanted to avoid that.
> 
> Bill
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Fri Feb 20 18:55:38 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 20 Feb 2015 18:55:38 -0500
Subject: [keycloak-dev] Claims Mapping and Identity Federation
In-Reply-To: <1241774320.17157344.1424474415725.JavaMail.zimbra@redhat.com>
References: <1145060295.16774022.1424445519986.JavaMail.zimbra@redhat.com>
	<54E7547F.1000405@redhat.com>
	<531418134.16814686.1424448453169.JavaMail.zimbra@redhat.com>
	<54E7B9D5.3080103@redhat.com>
	<1241774320.17157344.1424474415725.JavaMail.zimbra@redhat.com>
Message-ID: <54E7C97A.9070702@redhat.com>



On 2/20/2015 6:20 PM, Pedro Igor Silva wrote:
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Pedro Igor Silva" <psilva at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Friday, February 20, 2015 8:48:53 PM
>> Subject: Re: [keycloak-dev] Claims Mapping and Identity Federation
>>
>>
>>
>> On 2/20/2015 11:07 AM, Pedro Igor Silva wrote:
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Friday, February 20, 2015 1:36:31 PM
>>>> Subject: Re: [keycloak-dev] Claims Mapping and Identity Federation
>>>>
>>>
>>> I'm not sure if you really need something different for SAML. The reason is
>>> that we can just ask users if what they want to use 'Name' or 'Friendly
>>> Name'.
>>>
>>> At that end, that is what really matter, right ? Just know the name of the
>>> attribute to map to an internal one.
>>>
>>
>>   From looking at SAML document it looks like you can have a attribute
>> name types (uri, basic, and unspecified).  I'm not sure of the
>> difference between basic and unspecified.  Do you?
>
> AFAIK these are about how you interpret attributes. I think you can just ignore that in this case. You are more interested in map names than deal on how they should be interpreted. Users will probably know what they are mapping.
>
>>
>> Then "Friendly Name" is optional.
>
> Yeah it is optional, but you can have something like that:
>
>    <saml:Attribute
>            NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
>            Name="urn:oid:1.3.6.1.4.1.1466.115.121.1.26"
>            FriendlyName="mail">
>
> In this case, it is much easier to use FriendlyName when mapping than what is in Name. See, here there is an usage of NameFormat, in this case uri. We can just ignore ...
>
> If I'm correct about what you are doing, users will just say:
>
> Get "mail" from SAML Assertion and create a "email" claim in Keycloak.
>

The way it is going to work is that there will be a realm level page 
that shows a set of mappers.   You can remove and add mappers there. 
There will be built in mappers like:

"email"
"phone"
"address"
etc.

Then, per application, you attach or detach these mappers to the 
application.  Basically what is happening is you are attaching/detaching 
transformers to the application that it will be used to create tokens 
and documents.  Something similar will be done for brokers.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Mon Feb 23 02:27:16 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 23 Feb 2015 02:27:16 -0500 (EST)
Subject: [keycloak-dev] session_state changed to ClientSession id?
In-Reply-To: <54E7451B.7040508@redhat.com>
References: <54E557BC.5020308@redhat.com> <54E63F88.8010809@redhat.com>
	<254655186.11347444.1424420520250.JavaMail.zimbra@redhat.com>
	<54E72D09.1000903@redhat.com>
	<146343627.11603803.1424437296549.JavaMail.zimbra@redhat.com>
	<54E7415E.8090006@redhat.com>
	<946855223.11669572.1424441972253.JavaMail.zimbra@redhat.com>
	<54E7451B.7040508@redhat.com>
Message-ID: <1264748902.12984642.1424676436076.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Marek Posolda" <mposolda at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, February 20, 2015 3:30:51 PM
> Subject: Re: [keycloak-dev] session_state changed to ClientSession id?
> 
> 
> 
> On 2/20/2015 9:19 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Marek Posolda" <mposolda at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>, "Bill Burke"
> >> <bburke at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Friday, February 20, 2015 3:14:54 PM
> >> Subject: Re: [keycloak-dev] session_state changed to ClientSession id?
> >>
> >> On 20.2.2015 14:01, Stian Thorgersen wrote:
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>> Cc: keycloak-dev at lists.jboss.org
> >>>> Sent: Friday, February 20, 2015 1:48:09 PM
> >>>> Subject: Re: [keycloak-dev] session_state changed to ClientSession id?
> >>>>
> >>>>
> >>>>
> >>>> On 2/20/2015 3:22 AM, Stian Thorgersen wrote:
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>>> Sent: Thursday, February 19, 2015 8:54:48 PM
> >>>>>> Subject: Re: [keycloak-dev] session_state changed to ClientSession id?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 2/19/2015 1:10 AM, Stian Thorgersen wrote:
> >>>>>>>
> >>>>>>> ----- Original Message -----
> >>>>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>>>> Sent: Thursday, February 19, 2015 4:25:48 AM
> >>>>>>>> Subject: [keycloak-dev] session_state changed to ClientSession id?
> >>>>>>>>
> >>>>>>>> Can I change the session_state in the access token (and refresh
> >>>>>>>> token)
> >>>>>>>> to point to ClientSession id instead?  Right now it points to the
> >>>>>>>> user
> >>>>>>>> session id.
> >>>>>>> What's the benefits of doing that?
> >>>>>>>
> >>>>>>> It might have some impact on the Infinispan provider. For best
> >>>>>>> performance
> >>>>>>> user sessions should be retrieved by id, which we won't be able to do
> >>>>>>> if
> >>>>>>> we don't have it.
> >>>>>>>
> >>>>>> Access and refresh tokens should be associated with a client session
> >>>>>> so
> >>>>>> that we can track back an audit.  For claim mapping, I'm also allowing
> >>>>>> admins to map client session notes into the token.  There might be
> >>>>>> temporary protocol specific information stored there.
> >>>>>>
> >>>>>> I can just add a new client_session claim if needed.
> >>>>> If everything changes to lookup by client session id it should work
> >>>>> fine.
> >>>>> It would require a bit of tinkering though.
> >>>>>
> >>>>> On a related note would it make sense to create a single client session
> >>>>> per
> >>>>> client per user session? For example as the admin console doesn't store
> >>>>> tokens (and any client using keycloak.js is the same) a new client
> >>>>> session
> >>>>> is created if a user refreshes the page.
> >>>>>
> >>>> Refreshing the page nor refresh token causes a new client session to be
> >>>> submitted.  If a completely different browser is used to visit the app,
> >>>> then yes, there is a different client session.  In that case, you still
> >>>> want a new client session to be created because it would be a totally
> >>>> different HttpSession for the client.
> >>> I'm pretty sure it does. keycloak.js only keeps the token in memory and
> >>> if
> >>> you refresh the page it's lost. Then it'll redirect to the login page,
> >>> get
> >>> a new code, swap for token, etc.. We could potentially store the refresh
> >>> token in local storage, but not sure if that's a good idea.
> >> Isn't this vulnerability to some attacks? Can't some "evil" application
> >> executed from different browser tab read the token from the local storage?
> >
> > In theory, no. Local storage is only visible to js from the same domain. In
> > reality, not sure as there could be vulnerabilities in browser
> > implementations, although the same would apply to cookies as they are
> > protected by browser in the same way as local storage.
> >
> 
> Another possibility:
> 
> client crashes.  User doesn't notice, refreshes or visits a new page,
> login happens again, user doesn't know anything.  Same user session,
> different client session.

I guess we can discuss whether or not attaching so existing client session makes sense, not so sure any more. However, it would require some significant changes to do so, as we store a lot of state in the session.

So let's keep it the way it is with regards to creating a new client session for each "login". Should we store the refresh token in local storage for keycloak.js though? I think we should. I can't see that being any worse than storing it in a cookie. Browsers should protect both right and if there's an exploit either could be a problem.

> 
> Bill
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Mon Feb 23 03:07:32 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 23 Feb 2015 03:07:32 -0500 (EST)
Subject: [keycloak-dev] How to do default claim mappings?
In-Reply-To: <54E7571B.6080007@redhat.com>
References: <54E7571B.6080007@redhat.com>
Message-ID: <204784861.12997302.1424678852848.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, February 20, 2015 4:47:39 PM
> Subject: [keycloak-dev] How to do default claim mappings?
> 
> Per realm and per protocol (saml or OIDC), I'm going to need to register
> a set of default claim mappers into storage.  ProviderFactorys are
> loaded at boot time and each of their init() methods is invoked.  I'm
> thinking of adding a new method to ProviderFactory
> 
> void preprocess(KeycloakSessionFactory sessionFactory);
> 
> This would be called after all providers have been loaded.  This would
> allow the OIDC and SAML providers to browser every realm to make sure
> the appropriate built in claim mappers have been registered.
> 
> I'm also thinking of adding a RealmCreationListener registration method
> on RealmProvider.  Within ProviderFactory.preprocess() components could
> register themselves with the RealmProvider for realm creation events so
> that they could add additional metadata specific to their plugin.

preprocess is fine, except it adds a method that most providers won't use and also the name is a bit confusing.

RealmCreationListener is fine, but what if we add more and more "events" providers can listen to. We'll get a lot of methods and listener types.

What about adding a general purpose event listener framework for providers? We can add 

* ProviderEventListener ProviderFactory.getProviderEventListener()

The bootstrapping process would after calling init on all ProviderFactory, call getProviderEventListener. If it returns null it won't register it, but otherwise it'll add it to the list of listeners.

ProviderEventListener would have the following method:

* void onEvent(ProviderEvent event)

ProviderEvent would have:

* EventType type
* Map<String, String> details

We can add events for:

* Providers initialized - replaces preprocess, is invoked when all ProviderFactory init is called (and all ProviderEventListener are registered)
* Realm created
* Realm deleted
* Application created
* Application deleted
* User created
* User deleted
* Others?


> 
> --
> 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 bgorai at cisco.com  Mon Feb 23 04:16:29 2015
From: bgorai at cisco.com (Bappaditya Gorai (bgorai))
Date: Mon, 23 Feb 2015 09:16:29 +0000
Subject: [keycloak-dev] Keycloak Clustering 1.1.0.Final - Getting infinispan
 type casting error (DefaultCacheContainer to EmbeddedCacheManager) in
 DefaultInfinispanConnectionProviderFactory
Message-ID: <C5AF53298BAB5F4A88B28966E43B40AD0568A76B@xmb-aln-x12.cisco.com>

Hi Team,

I am trying  configure  Keycloak in clustered environment (EAP 6.3), however getting following error (stack trace is provided below) . I have followed instructions provided in "Chapter 24. Clustering" in Keycloak Guide (http://docs.jboss.org/keycloak/docs/1.1.0.Final/userguide/html/clustering.html). Let me know if I am missing something.


13:23:25,681 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth]] (ServerService Thread Pool -- 62) JBWEB000289: Servlet Keycloak REST Interface threw load() exception: java.lang.ClassCastException: org.jboss.as.clustering.infinispan.DefaultCacheContainer cannot be cast to org.infinispan.manager.EmbeddedCacheManager
        at org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory.initContainerManaged(DefaultInfinispanConnectionProviderFactory.java:70) [keycloak-connections-infinispan-1.1.0.Final.jar:1.1.0.Final]
        at org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory.lazyInit(DefaultInfinispanConnectionProviderFactory.java:59) [keycloak-connections-infinispan-1.1.0.Final.jar:1.1.0.Final]
        at org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory.create(DefaultInfinispanConnectionProviderFactory.java:30) [keycloak-connections-infinispan-1.1.0.Final.jar:1.1.0.Final]
        at org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory.create(DefaultInfinispanConnectionProviderFactory.java:18) [keycloak-connections-infinispan-1.1.0.Final.jar:1.1.0.Final]



Thanks
Bappaditya Gorai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150223/887e15f9/attachment.html 

From gerbermichi at me.com  Mon Feb 23 05:47:53 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Mon, 23 Feb 2015 11:47:53 +0100
Subject: [keycloak-dev] HttpRequest, UriInfo, HttpHeader
Message-ID: <8A0792B5-4F17-473D-BEC1-DD45B6768049@me.com>

Hi all,

I need the following information:
- query parameter
- cookie
- http header (Accept-Language)

I thought I can access all this information through the HttpRequest (getUri, getHttpHeaders).
Unfortunatly, the getUri on the HttpRequest throws an error:
java.lang.NoSuchMethodError: org.jboss.resteasy.spi.HttpRequest.getUri()Ljavax/ws/rs/core/UriInfo;

Do you know how I can get the URI from an org.jboss.resteasy.spi.HttpRequest ?

Best
Michael



From stian at redhat.com  Mon Feb 23 06:59:43 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 23 Feb 2015 06:59:43 -0500 (EST)
Subject: [keycloak-dev] HttpRequest, UriInfo, HttpHeader
In-Reply-To: <8A0792B5-4F17-473D-BEC1-DD45B6768049@me.com>
References: <8A0792B5-4F17-473D-BEC1-DD45B6768049@me.com>
Message-ID: <1137343714.13278459.1424692783968.JavaMail.zimbra@redhat.com>

Where do you need it?

----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, February 23, 2015 11:47:53 AM
> Subject: [keycloak-dev] HttpRequest, UriInfo, HttpHeader
> 
> Hi all,
> 
> I need the following information:
> - query parameter
> - cookie
> - http header (Accept-Language)
> 
> I thought I can access all this information through the HttpRequest (getUri,
> getHttpHeaders).
> Unfortunatly, the getUri on the HttpRequest throws an error:
> java.lang.NoSuchMethodError:
> org.jboss.resteasy.spi.HttpRequest.getUri()Ljavax/ws/rs/core/UriInfo;
> 
> Do you know how I can get the URI from an org.jboss.resteasy.spi.HttpRequest
> ?
> 
> Best
> Michael
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From psilva at redhat.com  Mon Feb 23 08:17:32 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Mon, 23 Feb 2015 08:17:32 -0500 (EST)
Subject: [keycloak-dev] How to do default claim mappings?
In-Reply-To: <204784861.12997302.1424678852848.JavaMail.zimbra@redhat.com>
References: <54E7571B.6080007@redhat.com>
	<204784861.12997302.1424678852848.JavaMail.zimbra@redhat.com>
Message-ID: <117151428.17604287.1424697452253.JavaMail.zimbra@redhat.com>

Isn't better review the EventBuilder to provide a more robust event handling mech ?


----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, February 23, 2015 5:07:32 AM
> Subject: Re: [keycloak-dev] How to do default claim mappings?
> 
> 
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: keycloak-dev at lists.jboss.org
> > Sent: Friday, February 20, 2015 4:47:39 PM
> > Subject: [keycloak-dev] How to do default claim mappings?
> > 
> > Per realm and per protocol (saml or OIDC), I'm going to need to register
> > a set of default claim mappers into storage.  ProviderFactorys are
> > loaded at boot time and each of their init() methods is invoked.  I'm
> > thinking of adding a new method to ProviderFactory
> > 
> > void preprocess(KeycloakSessionFactory sessionFactory);
> > 
> > This would be called after all providers have been loaded.  This would
> > allow the OIDC and SAML providers to browser every realm to make sure
> > the appropriate built in claim mappers have been registered.
> > 
> > I'm also thinking of adding a RealmCreationListener registration method
> > on RealmProvider.  Within ProviderFactory.preprocess() components could
> > register themselves with the RealmProvider for realm creation events so
> > that they could add additional metadata specific to their plugin.
> 
> preprocess is fine, except it adds a method that most providers won't use and
> also the name is a bit confusing.
> 
> RealmCreationListener is fine, but what if we add more and more "events"
> providers can listen to. We'll get a lot of methods and listener types.
> 
> What about adding a general purpose event listener framework for providers?
> We can add
> 
> * ProviderEventListener ProviderFactory.getProviderEventListener()
> 
> The bootstrapping process would after calling init on all ProviderFactory,
> call getProviderEventListener. If it returns null it won't register it, but
> otherwise it'll add it to the list of listeners.
> 
> ProviderEventListener would have the following method:
> 
> * void onEvent(ProviderEvent event)
> 
> ProviderEvent would have:
> 
> * EventType type
> * Map<String, String> details
> 
> We can add events for:
> 
> * Providers initialized - replaces preprocess, is invoked when all
> ProviderFactory init is called (and all ProviderEventListener are
> registered)
> * Realm created
> * Realm deleted
> * Application created
> * Application deleted
> * User created
> * User deleted
> * Others?
> 
> 
> > 
> > --
> > 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 Feb 23 08:21:56 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 23 Feb 2015 08:21:56 -0500 (EST)
Subject: [keycloak-dev] How to render claim data entry and display?
In-Reply-To: <54E698B7.9070301@redhat.com>
References: <54E698B7.9070301@redhat.com>
Message-ID: <1308263357.13371167.1424697716848.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, February 20, 2015 3:15:19 AM
> Subject: [keycloak-dev] How to render claim data entry and display?
> 
> I'm not sure how to render claims within the admin console, registration
> page, and in the user self service pages.  The thing is that generically
> rendering user metadata can look quite ugly.  Address is one example
> where the grouping and ordering of each attribute is important to look
> nice.  There are other instances where you need to group types of data
> together (home phone, fax, work phone, mobile).  Then there is the
> problem of what claim data do you show on what pages which is harder
> than it seems, for example, registration page might only require a
> mobile number, but admin console and user profile page might want to
> show home, fax, work too.  You would end up having to define a data
> model that captured metadata for each page type (registration, user
> profile, and admin console).  Finally, if you have generically rendered
> claims, what happens when the user wants to override this rendering and
> put their own formatting, .css types, etc. in?
> 
> This leads me to think that we should just punt to the developer.  In
> this case, there would be no data model for claim types and everything
> would be driven simply off of UserModel.attributes.  Develoeprs would
> have to extend the admin console and account themes and we would provide
> a template for referencing UserModel.attribute data within Angular HTML
> (admin console) or Framemaker (account service, registration page).

For registration page and account management I think supporting simple attributes in the default template would be good enough. Users can then extend the templates if they need something more. In the future we can look into creating widgets that can display certain things so users don't have to extend the whole template, but just parts of it.

For the admin console it would be best not to require users to extend IMO. We should be able to allow users to view and edit complex attributes (at least a complex attribute that is a list of simple, rather than complex of complex). Initially we could just display the JSON for the complex attribute directly, then create an view/editor for it later.

> 
> I know Stian talked about validation, but I think this could be added on
> after the fact via an AttributeValidator and again tied to a specific
> UserModel.attribute.
> 
> --
> 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 Feb 23 08:24:37 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 23 Feb 2015 08:24:37 -0500 (EST)
Subject: [keycloak-dev] How to do default claim mappings?
In-Reply-To: <117151428.17604287.1424697452253.JavaMail.zimbra@redhat.com>
References: <54E7571B.6080007@redhat.com>
	<204784861.12997302.1424678852848.JavaMail.zimbra@redhat.com>
	<117151428.17604287.1424697452253.JavaMail.zimbra@redhat.com>
Message-ID: <96969867.13373726.1424697877949.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Monday, February 23, 2015 2:17:32 PM
> Subject: Re: [keycloak-dev] How to do default claim mappings?
> 
> Isn't better review the EventBuilder to provide a more robust event handling
> mech ?

That could be an option, but there needs to at least be two different types of listeners, one for providers to listen to "framework" related events and another for listening to "user/admin" events.

> 
> 
> ----- Original Message -----
> > From: "Stian Thorgersen" <stian at redhat.com>
> > To: "Bill Burke" <bburke at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Monday, February 23, 2015 5:07:32 AM
> > Subject: Re: [keycloak-dev] How to do default claim mappings?
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Bill Burke" <bburke at redhat.com>
> > > To: keycloak-dev at lists.jboss.org
> > > Sent: Friday, February 20, 2015 4:47:39 PM
> > > Subject: [keycloak-dev] How to do default claim mappings?
> > > 
> > > Per realm and per protocol (saml or OIDC), I'm going to need to register
> > > a set of default claim mappers into storage.  ProviderFactorys are
> > > loaded at boot time and each of their init() methods is invoked.  I'm
> > > thinking of adding a new method to ProviderFactory
> > > 
> > > void preprocess(KeycloakSessionFactory sessionFactory);
> > > 
> > > This would be called after all providers have been loaded.  This would
> > > allow the OIDC and SAML providers to browser every realm to make sure
> > > the appropriate built in claim mappers have been registered.
> > > 
> > > I'm also thinking of adding a RealmCreationListener registration method
> > > on RealmProvider.  Within ProviderFactory.preprocess() components could
> > > register themselves with the RealmProvider for realm creation events so
> > > that they could add additional metadata specific to their plugin.
> > 
> > preprocess is fine, except it adds a method that most providers won't use
> > and
> > also the name is a bit confusing.
> > 
> > RealmCreationListener is fine, but what if we add more and more "events"
> > providers can listen to. We'll get a lot of methods and listener types.
> > 
> > What about adding a general purpose event listener framework for providers?
> > We can add
> > 
> > * ProviderEventListener ProviderFactory.getProviderEventListener()
> > 
> > The bootstrapping process would after calling init on all ProviderFactory,
> > call getProviderEventListener. If it returns null it won't register it, but
> > otherwise it'll add it to the list of listeners.
> > 
> > ProviderEventListener would have the following method:
> > 
> > * void onEvent(ProviderEvent event)
> > 
> > ProviderEvent would have:
> > 
> > * EventType type
> > * Map<String, String> details
> > 
> > We can add events for:
> > 
> > * Providers initialized - replaces preprocess, is invoked when all
> > ProviderFactory init is called (and all ProviderEventListener are
> > registered)
> > * Realm created
> > * Realm deleted
> > * Application created
> > * Application deleted
> > * User created
> > * User deleted
> > * Others?
> > 
> > 
> > > 
> > > --
> > > Bill Burke
> > > JBoss, a division of Red Hat
> > > http://bill.burkecentral.com
> > > _______________________________________________
> > > keycloak-dev mailing list
> > > keycloak-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > 
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> 

From bburke at redhat.com  Mon Feb 23 08:59:13 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 23 Feb 2015 08:59:13 -0500
Subject: [keycloak-dev] How to render claim data entry and display?
In-Reply-To: <1308263357.13371167.1424697716848.JavaMail.zimbra@redhat.com>
References: <54E698B7.9070301@redhat.com>
	<1308263357.13371167.1424697716848.JavaMail.zimbra@redhat.com>
Message-ID: <54EB3231.4010801@redhat.com>



On 2/23/2015 8:21 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, February 20, 2015 3:15:19 AM
>> Subject: [keycloak-dev] How to render claim data entry and display?
>>
>> I'm not sure how to render claims within the admin console, registration
>> page, and in the user self service pages.  The thing is that generically
>> rendering user metadata can look quite ugly.  Address is one example
>> where the grouping and ordering of each attribute is important to look
>> nice.  There are other instances where you need to group types of data
>> together (home phone, fax, work phone, mobile).  Then there is the
>> problem of what claim data do you show on what pages which is harder
>> than it seems, for example, registration page might only require a
>> mobile number, but admin console and user profile page might want to
>> show home, fax, work too.  You would end up having to define a data
>> model that captured metadata for each page type (registration, user
>> profile, and admin console).  Finally, if you have generically rendered
>> claims, what happens when the user wants to override this rendering and
>> put their own formatting, .css types, etc. in?
>>
>> This leads me to think that we should just punt to the developer.  In
>> this case, there would be no data model for claim types and everything
>> would be driven simply off of UserModel.attributes.  Develoeprs would
>> have to extend the admin console and account themes and we would provide
>> a template for referencing UserModel.attribute data within Angular HTML
>> (admin console) or Framemaker (account service, registration page).
>
> For registration page and account management I think supporting simple attributes in the default template would be good enough. Users can then extend the templates if they need something more. In the future we can look into creating widgets that can display certain things so users don't have to extend the whole template, but just parts of it.
>
> For the admin console it would be best not to require users to extend IMO. We should be able to allow users to view and edit complex attributes (at least a complex attribute that is a list of simple, rather than complex of complex). Initially we could just display the JSON for the complex attribute directly, then create an view/editor for it later.
>

I just don't want us spending time implementing and maintaining an HTML 
editor for something the user will usually be extending a theme for anyways.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bruno at abstractj.org  Mon Feb 23 09:04:11 2015
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 23 Feb 2015 11:04:11 -0300
Subject: [keycloak-dev] Liquibase errors on first startup with KC
	1.1.0-Final
In-Reply-To: <54E462C1.8030800@redhat.com>
References: <54E439D6.9070504@redhat.com> <1424249002486.b2dde26e@Nodemailer>
	<54E462C1.8030800@redhat.com>
Message-ID: <CAM5SUC7J8o+j09xHbmNjsUq4eVMhTm-NW5B22Z8myJdfvWjHsA@mail.gmail.com>

I'm sorry for the late response Marek, somehow your reply got lost in my
inbox. From the feedback I got, seems like an intermittent issue, some
people faced with it while others not.

Anyway I've already separated the datasources (
https://github.com/aerogear/aerogear-unifiedpush-server/pull/500). I think
isolating the problem will make it easy to identify where/when the issue
happens.

I will let you know if we find out.



On Wed, Feb 18, 2015 at 8:00 AM, Marek Posolda <mposolda at redhat.com> wrote:

>  Thanks Bruno,
>
> Are you seeing this issue just for H2 or also for other databases? I mean
> it's probably ok if we have a requirement for H2 to use separate database
> (directory) as H2 is more like testing database.
>
> However for MySQL and PostgreSQL is probably not nice, if Keycloak has
> requirement to have separate DB dedicated to Keycloak data and separate DB
> to other data. In this case, we would likely need to improve things IMO.
>
> Marek
>
>
>
> On 18.2.2015 09:43, Bruno Oliveira wrote:
>
> Hi Marek, answering you question, yes. I think what you suggested is the
> best approach, if that does not work we let you know.
>
> Thanks a lot
>
> ?
>
> abstractj
> PGP: 0x84DC9914
>
>
>  On Wed, Feb 18, 2015 at 5:06 AM, Marek Posolda <mposolda at redhat.com>
> wrote:
>
>>  Hi,
>>
>> Is Keycloak DB and Aerogear DB points to same database? Will it help if
>> you point keycloak DB to different one (ie. use different H2 directory for
>> your datasource and KeycloakDS datasource) ?
>>
>> Otherwise feel free to create JIRA with steps to reproduce.
>>
>> Marek
>>
>> On 18.2.2015 08:03, Sebastien Blanc wrote:
>>
>> Hi !
>> Any ideas for this ?
>> Should I open a ticket ?
>> On 02/12/2015 03:35 PM, Sebastien Blanc wrote:
>>
>> Hi,
>>
>> We discovered recently that deploying Keycloak (the one that comes with
>> the AeroGear distro) on a "fresh" Wildfly 8.2  was generating liquibase
>> errors ( https://gist.github.com/lholmquist/f031f7a3d88477ba81a7).
>> Restarting the server removes these errors.
>> Any idea ? Should I open a ticket ?
>>
>> It concerns 1.1.0-Final
>>
>> Sebi
>>
>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>
>


-- 

-- 
"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/20150223/282d25d2/attachment.html 

From stian at redhat.com  Mon Feb 23 09:13:49 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 23 Feb 2015 09:13:49 -0500 (EST)
Subject: [keycloak-dev] How to render claim data entry and display?
In-Reply-To: <54EB3231.4010801@redhat.com>
References: <54E698B7.9070301@redhat.com>
	<1308263357.13371167.1424697716848.JavaMail.zimbra@redhat.com>
	<54EB3231.4010801@redhat.com>
Message-ID: <1173260015.13425581.1424700829009.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, February 23, 2015 2:59:13 PM
> Subject: Re: [keycloak-dev] How to render claim data entry and display?
> 
> 
> 
> On 2/23/2015 8:21 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, February 20, 2015 3:15:19 AM
> >> Subject: [keycloak-dev] How to render claim data entry and display?
> >>
> >> I'm not sure how to render claims within the admin console, registration
> >> page, and in the user self service pages.  The thing is that generically
> >> rendering user metadata can look quite ugly.  Address is one example
> >> where the grouping and ordering of each attribute is important to look
> >> nice.  There are other instances where you need to group types of data
> >> together (home phone, fax, work phone, mobile).  Then there is the
> >> problem of what claim data do you show on what pages which is harder
> >> than it seems, for example, registration page might only require a
> >> mobile number, but admin console and user profile page might want to
> >> show home, fax, work too.  You would end up having to define a data
> >> model that captured metadata for each page type (registration, user
> >> profile, and admin console).  Finally, if you have generically rendered
> >> claims, what happens when the user wants to override this rendering and
> >> put their own formatting, .css types, etc. in?
> >>
> >> This leads me to think that we should just punt to the developer.  In
> >> this case, there would be no data model for claim types and everything
> >> would be driven simply off of UserModel.attributes.  Develoeprs would
> >> have to extend the admin console and account themes and we would provide
> >> a template for referencing UserModel.attribute data within Angular HTML
> >> (admin console) or Framemaker (account service, registration page).
> >
> > For registration page and account management I think supporting simple
> > attributes in the default template would be good enough. Users can then
> > extend the templates if they need something more. In the future we can
> > look into creating widgets that can display certain things so users don't
> > have to extend the whole template, but just parts of it.
> >
> > For the admin console it would be best not to require users to extend IMO.
> > We should be able to allow users to view and edit complex attributes (at
> > least a complex attribute that is a list of simple, rather than complex of
> > complex). Initially we could just display the JSON for the complex
> > attribute directly, then create an view/editor for it later.
> >
> 
> I just don't want us spending time implementing and maintaining an HTML
> editor for something the user will usually be extending a theme for anyways.

Yes, I totally agree, but that wasn't what I proposed though. What I'd propose we do is:

* Admin console - just list claims, sorted by name. For simple types we display the value and allow editing with input text. For complex we display json and allow editing in textarea. In the future we can add a feature that allows view/edit complex attributes directly.
* Registration and account management - only display simple types. We should provide some mechanism for choosing which are displayed and order. For complex types or better control on how it's displayed (other than a simple list of label, input) users are expected to extend the template. In the future we can add a feature that allows extending parts of a template, which would make it easier to edit and also maintain in the long run. For example instead of overriding the whole registration page a user could override just the form part, or even just how a specific claim is displayed.

> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Mon Feb 23 09:26:57 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 23 Feb 2015 09:26:57 -0500 (EST)
Subject: [keycloak-dev] Keycloak.js is inefficient and can be improved
In-Reply-To: <54D939D8.2050407@redhat.com>
References: <54D939D8.2050407@redhat.com>
Message-ID: <1378179913.13437209.1424701617889.JavaMail.zimbra@redhat.com>

Looks pretty cool.

I was wondering if we should verify the token in keycloak.js, not sure if it's necessary, but if someone could pass an invalid token to keycloak.js somehow they could potentially fool it into using it

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, February 9, 2015 11:51:04 PM
> Subject: [keycloak-dev] Keycloak.js is inefficient and can be improved
> 
> I had a good discussion on OAuth list about javascript and implicit flow
> vs. auth-code flow.  It was pointed out that auth-code flow has some
> extra hops that can be avoided if you implement "response_mode=fragment".
> 
> See this:
> 
> https://issues.jboss.org/browse/KEYCLOAK-1033
> 
> 
> --
> 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 Feb 23 09:27:54 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 23 Feb 2015 09:27:54 -0500 (EST)
Subject: [keycloak-dev] keycloak-oauth-plugin hosting request
In-Reply-To: <CAM7bvCQKQykFP-c3p0bEYp6Kq1Oh+nW=ep_y1WPHkjnwE7EEUQ@mail.gmail.com>
References: <CAM7bvCQBnAabSyOPTB=F3-LhhPe1jpvNgmsezAGv4QaaNfTXQw@mail.gmail.com>
	<977292214.7534857.1421048407668.JavaMail.zimbra@redhat.com>
	<CAM7bvCSzTupgYmh3uYxkGKe-KXcLc-v_k4cckuEND0YHPws24Q@mail.gmail.com>
	<1091169952.2994208.1422538171584.JavaMail.zimbra@redhat.com>
	<CAM7bvCRhJjC8jXdQpsk_nmLpJkHwHOikE9g_D6G5LXheLsQt2Q@mail.gmail.com>
	<CAM7bvCQKQykFP-c3p0bEYp6Kq1Oh+nW=ep_y1WPHkjnwE7EEUQ@mail.gmail.com>
Message-ID: <1427873614.13439766.1424701674893.JavaMail.zimbra@redhat.com>

Nice write-up, thanks for sharing

----- Original Message -----
> From: "coolmind182006 ." <coolmind182006 at gmail.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, February 5, 2015 5:43:26 PM
> Subject: Re: [keycloak-dev] keycloak-oauth-plugin hosting request
> 
> Further I have documented the design approach followed in keycloak here :
> 
> https://www.prokarma.com/blog/2015/02/03/lightweight-application-development
> 
> On Fri, Jan 30, 2015 at 10:59 PM, coolmind182006 . <coolmind182006 at gmail.com
> > wrote:
> 
> > Thanks Stian,
> >
> > I am planning to provide Authorization for Jenkins, which is not yet
> > implemented, After I am done with that, How that would be merged with
> > keycloak repo ?, since I don't have write access to keycloak some manual
> > work would be required to merge the code back to keycloak repo from my
> > personal repo
> >
> > Further I written a blog on deploying keycloak on Tomcat
> > <https://reachmnadeem.wordpress.com/2015/01/14/deploying-keycloak-in-tomcat/>and
> > Tomee
> > <https://reachmnadeem.wordpress.com/2015/01/14/deploying-keycloak-in-tomee/>
> >
> > And Finally Sonarqube is also integrated with Keycloak
> > <https://reachmnadeem.wordpress.com/2015/01/22/integrating-keycloak-with-sonarqube/>
> >
> > I will provide authorization soon for sonarqube as well
> >
> >
> >
> >
> >
> > On Thu, Jan 29, 2015 at 6:59 PM, Stian Thorgersen <stian at redhat.com>
> > wrote:
> >
> >> Finally got a chance to move and look at your video.
> >>
> >> I imported your repo to:
> >> https://github.com/keycloak/jenkins-keycloak-plugin
> >>
> >> I also updated
> >> https://wiki.jenkins-ci.org/display/JENKINS/keycloak-plugin to link to
> >> the above repo.
> >>
> >> Really cool stuff, thanks for contributing this to us :)
> >>
> >> ----- Original Message -----
> >> > From: "coolmind182006 ." <coolmind182006 at gmail.com>
> >> > To: "Stian Thorgersen" <stian at redhat.com>
> >> > Cc: keycloak-dev at lists.jboss.org
> >> > Sent: Monday, January 12, 2015 7:20:24 PM
> >> > Subject: Re: [keycloak-dev] keycloak-oauth-plugin hosting request
> >> >
> >> > Thanks a bundle, Let me know if I have to do anything..
> >> >
> >> >
> >> >
> >> > On Mon, Jan 12, 2015 at 1:10 PM, Stian Thorgersen <stian at redhat.com>
> >> wrote:
> >> >
> >> > > Awesome, we'd love to pull this in to our GitHub
> >> > >
> >> > > ----- Original Message -----
> >> > > > From: "coolmind182006 ." <coolmind182006 at gmail.com>
> >> > > > To: keycloak-dev at lists.jboss.org
> >> > > > Sent: Sunday, 11 January, 2015 12:22:03 PM
> >> > > > Subject: [keycloak-dev] keycloak-oauth-plugin hosting request
> >> > > >
> >> > > >
> >> > > > plugin name : keycloak-oauth
> >> > > > github account : mnadeem
> >> > > > existing repository :
> >> https://github.com/mnadeem/jenkins-keycloak-plugin
> >> > > > wiki :
> >> https://wiki.jenkins-ci.org/display/JENKINS/keycloak-oauth-plugin
> >> > > >
> >> > > > _______________________________________________
> >> > > > keycloak-dev mailing list
> >> > > > keycloak-dev at lists.jboss.org
> >> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >> > >
> >> >
> >>
> >
> >
> 

From bburke at redhat.com  Mon Feb 23 09:34:12 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 23 Feb 2015 09:34:12 -0500
Subject: [keycloak-dev] Keycloak.js is inefficient and can be improved
In-Reply-To: <1378179913.13437209.1424701617889.JavaMail.zimbra@redhat.com>
References: <54D939D8.2050407@redhat.com>
	<1378179913.13437209.1424701617889.JavaMail.zimbra@redhat.com>
Message-ID: <54EB3A64.5030007@redhat.com>

Verifying the token would be a must for implicit flow, IMO.  Not so much 
for access code flow though.

For access code flow it is not really possible to fool the javascript 
provider because of the "state" parameter, and obtaining an access token 
happens out of band.

On 2/23/2015 9:26 AM, Stian Thorgersen wrote:
> Looks pretty cool.
>
> I was wondering if we should verify the token in keycloak.js, not sure if it's necessary, but if someone could pass an invalid token to keycloak.js somehow they could potentially fool it into using it
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Monday, February 9, 2015 11:51:04 PM
>> Subject: [keycloak-dev] Keycloak.js is inefficient and can be improved
>>
>> I had a good discussion on OAuth list about javascript and implicit flow
>> vs. auth-code flow.  It was pointed out that auth-code flow has some
>> extra hops that can be avoided if you implement "response_mode=fragment".
>>
>> See this:
>>
>> https://issues.jboss.org/browse/KEYCLOAK-1033
>>
>>
>> --
>> 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 Feb 23 09:38:22 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 23 Feb 2015 09:38:22 -0500 (EST)
Subject: [keycloak-dev] Keycloak.js is inefficient and can be improved
In-Reply-To: <54EB3A64.5030007@redhat.com>
References: <54D939D8.2050407@redhat.com>
	<1378179913.13437209.1424701617889.JavaMail.zimbra@redhat.com>
	<54EB3A64.5030007@redhat.com>
Message-ID: <54200941.13466086.1424702302431.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, February 23, 2015 3:34:12 PM
> Subject: Re: [keycloak-dev] Keycloak.js is inefficient and can be improved
> 
> Verifying the token would be a must for implicit flow, IMO.  Not so much
> for access code flow though.

Should we add support for implicit flow?

> 
> For access code flow it is not really possible to fool the javascript
> provider because of the "state" parameter, and obtaining an access token
> happens out of band.

We support passing tokens to keycloak.js to initialize it, but not sure if that could be exploited

> 
> On 2/23/2015 9:26 AM, Stian Thorgersen wrote:
> > Looks pretty cool.
> >
> > I was wondering if we should verify the token in keycloak.js, not sure if
> > it's necessary, but if someone could pass an invalid token to keycloak.js
> > somehow they could potentially fool it into using it
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Monday, February 9, 2015 11:51:04 PM
> >> Subject: [keycloak-dev] Keycloak.js is inefficient and can be improved
> >>
> >> I had a good discussion on OAuth list about javascript and implicit flow
> >> vs. auth-code flow.  It was pointed out that auth-code flow has some
> >> extra hops that can be avoided if you implement "response_mode=fragment".
> >>
> >> See this:
> >>
> >> https://issues.jboss.org/browse/KEYCLOAK-1033
> >>
> >>
> >> --
> >> 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 Feb 23 09:41:31 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 23 Feb 2015 09:41:31 -0500 (EST)
Subject: [keycloak-dev] How to do default claim mappings?
In-Reply-To: <54EB399D.7040208@redhat.com>
References: <54E7571B.6080007@redhat.com>
	<204784861.12997302.1424678852848.JavaMail.zimbra@redhat.com>
	<54EB399D.7040208@redhat.com>
Message-ID: <185284900.13469474.1424702491363.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, February 23, 2015 3:30:53 PM
> Subject: Re: [keycloak-dev] How to do default claim mappings?
> 
> 
> 
> On 2/23/2015 3:07 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, February 20, 2015 4:47:39 PM
> >> Subject: [keycloak-dev] How to do default claim mappings?
> >>
> >> Per realm and per protocol (saml or OIDC), I'm going to need to register
> >> a set of default claim mappers into storage.  ProviderFactorys are
> >> loaded at boot time and each of their init() methods is invoked.  I'm
> >> thinking of adding a new method to ProviderFactory
> >>
> >> void preprocess(KeycloakSessionFactory sessionFactory);
> >>
> >> This would be called after all providers have been loaded.  This would
> >> allow the OIDC and SAML providers to browser every realm to make sure
> >> the appropriate built in claim mappers have been registered.
> >>
> >> I'm also thinking of adding a RealmCreationListener registration method
> >> on RealmProvider.  Within ProviderFactory.preprocess() components could
> >> register themselves with the RealmProvider for realm creation events so
> >> that they could add additional metadata specific to their plugin.
> >
> > preprocess is fine, except it adds a method that most providers won't use
> > and also the name is a bit confusing.
> >
> > RealmCreationListener is fine, but what if we add more and more "events"
> > providers can listen to. We'll get a lot of methods and listener types.
> >
> > What about adding a general purpose event listener framework for providers?
> > We can add
> >
> > * ProviderEventListener ProviderFactory.getProviderEventListener()
> >
> > The bootstrapping process would after calling init on all ProviderFactory,
> > call getProviderEventListener. If it returns null it won't register it,
> > but otherwise it'll add it to the list of listeners.
> >
> > ProviderEventListener would have the following method:
> >
> > * void onEvent(ProviderEvent event)
> >
> > ProviderEvent would have:
> >
> > * EventType type
> > * Map<String, String> details
> >
> 
> You're right.  Probably shouldn't be so specific and should leave some
> room for more event types.
> 
> But...
> 
> You can't really have KeycloakSessionFactory control a generic listener
> framework.  Otherwise the KeycloakSessionFactory is going to have to
> know about every event type and which provider they must be registered
> with.  Also, you don't need an EventType or Map of details.  Just do
> instanceof/typecast to the specific event type.

I was thinking all events would be passed to all listeners, they would have to filter themselves. Event types should probably be part of core, rather than something that's introduced by providers themselves.

> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Mon Feb 23 09:43:11 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 23 Feb 2015 09:43:11 -0500
Subject: [keycloak-dev] How to render claim data entry and display?
In-Reply-To: <1173260015.13425581.1424700829009.JavaMail.zimbra@redhat.com>
References: <54E698B7.9070301@redhat.com>
	<1308263357.13371167.1424697716848.JavaMail.zimbra@redhat.com>
	<54EB3231.4010801@redhat.com>
	<1173260015.13425581.1424700829009.JavaMail.zimbra@redhat.com>
Message-ID: <54EB3C7F.8030005@redhat.com>



On 2/23/2015 9:13 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Monday, February 23, 2015 2:59:13 PM
>> Subject: Re: [keycloak-dev] How to render claim data entry and display?
>>
>>
>>
>> On 2/23/2015 8:21 AM, Stian Thorgersen wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Friday, February 20, 2015 3:15:19 AM
>>>> Subject: [keycloak-dev] How to render claim data entry and display?
>>>>
>>>> I'm not sure how to render claims within the admin console, registration
>>>> page, and in the user self service pages.  The thing is that generically
>>>> rendering user metadata can look quite ugly.  Address is one example
>>>> where the grouping and ordering of each attribute is important to look
>>>> nice.  There are other instances where you need to group types of data
>>>> together (home phone, fax, work phone, mobile).  Then there is the
>>>> problem of what claim data do you show on what pages which is harder
>>>> than it seems, for example, registration page might only require a
>>>> mobile number, but admin console and user profile page might want to
>>>> show home, fax, work too.  You would end up having to define a data
>>>> model that captured metadata for each page type (registration, user
>>>> profile, and admin console).  Finally, if you have generically rendered
>>>> claims, what happens when the user wants to override this rendering and
>>>> put their own formatting, .css types, etc. in?
>>>>
>>>> This leads me to think that we should just punt to the developer.  In
>>>> this case, there would be no data model for claim types and everything
>>>> would be driven simply off of UserModel.attributes.  Develoeprs would
>>>> have to extend the admin console and account themes and we would provide
>>>> a template for referencing UserModel.attribute data within Angular HTML
>>>> (admin console) or Framemaker (account service, registration page).
>>>
>>> For registration page and account management I think supporting simple
>>> attributes in the default template would be good enough. Users can then
>>> extend the templates if they need something more. In the future we can
>>> look into creating widgets that can display certain things so users don't
>>> have to extend the whole template, but just parts of it.
>>>
>>> For the admin console it would be best not to require users to extend IMO.
>>> We should be able to allow users to view and edit complex attributes (at
>>> least a complex attribute that is a list of simple, rather than complex of
>>> complex). Initially we could just display the JSON for the complex
>>> attribute directly, then create an view/editor for it later.
>>>
>>
>> I just don't want us spending time implementing and maintaining an HTML
>> editor for something the user will usually be extending a theme for anyways.
>
> Yes, I totally agree, but that wasn't what I proposed though. What I'd propose we do is:
>
> * Admin console - just list claims, sorted by name. For simple types we display the value and allow editing with input text. For complex we display json and allow editing in textarea. In the future we can add a feature that allows view/edit complex attributes directly.
> * Registration and account management - only display simple types. We should provide some mechanism for choosing which are displayed and order. For complex types or better control on how it's displayed (other than a simple list of label, input) users are expected to extend the template. In the future we can add a feature that allows extending parts of a template, which would make it easier to edit and also maintain in the long run. For example instead of overriding the whole registration page a user could override just the form part, or even just how a specific claim is displayed.
>

I think users will be extending our themes anyways almost every time 
(except the admin console).  As, again, anything generically rendered 
will look ugly and unprofessional.  I started off implementing it the 
way you are saying...but then I was like, "This is dumb and will look 
like shit".


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Mon Feb 23 09:50:42 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 23 Feb 2015 09:50:42 -0500 (EST)
Subject: [keycloak-dev] WildFly integration (READ ME!)
In-Reply-To: <54E77884.7050003@redhat.com>
References: <969708031.6108771.1422954530044.JavaMail.zimbra@redhat.com>
	<1360543918.10348397.1424334753943.JavaMail.zimbra@redhat.com>
	<54E74D1C.4030600@redhat.com> <54E77464.2050400@redhat.com>
	<54E77884.7050003@redhat.com>
Message-ID: <704793002.13480640.1424703042016.JavaMail.zimbra@redhat.com>

Just to clarify we're only talking about the server, not adapters.

For the best and most friction free experience it would be best to have a dedicated Keycloak server, not to co-locate it with your JEE apps by deploying a WAR. With that regards we are considering dropping support for deploying Keycloak as a WAR.

That being said we still need to support embedding Keycloak in other projects. We plan to continue to support this through the mechanism UPS does, basically build-your-own auth-server.war.

----- Original Message -----
> From: "Summers Pittman" <supittma at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, February 20, 2015 7:10:12 PM
> Subject: Re: [keycloak-dev] WildFly integration (READ ME!)
> 
> On 02/20/2015 12:52 PM, Stan Silvert wrote:
> > On 2/20/2015 10:05 AM, Summers Pittman wrote:
> >> On 02/19/2015 03:32 AM, Stian Thorgersen wrote:
> >>> No comments?!
> >> Peanut gallery chiming in; you asked for it ;)
> >>
> >> I am not a WildFly developer or administrator.  So read this email as
> >> the opinions of a talented developer who loves the hell out of using
> >> KeyCloak and WildFly and sings its praises from the roof tops but has no
> >> idea what you are talking about.
> > Thanks Summers.  Very valuable feedback.
> Thanks for taking the time to explain some things I know more than I did
> this morning.
> >>> ----- Original Message -----
> >>>> From: "Stian Thorgersen" <stian at redhat.com>
> >>>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >>>> Sent: Tuesday, February 3, 2015 10:08:50 AM
> >>>> Subject: [keycloak-dev] WildFly integration (READ ME!)
> >>>>
> >>>> All,
> >>>>
> >>>> We have a few decisions to make in the not so far future. I'm away from
> >>>> Thursday, so let's have a hangout when I get back on the 17th February
> >>>> if
> >>>> that works for everyone.
> >>>>
> >>>> The list of things to discuss includes:
> >>>>
> >>>> * Drop keycloak-server.json - Should we drop our own configuration file
> >>>> and
> >>>> use DMR (standalone.xml)
> >> If on day one enabling KeyCloak in my project was any more complicated
> >> than dropping a pregenerated file into my WEB-INF directory I would have
> >> closed the project and never looked back.  -1
> > We're talking about the auth server's config rather than the config for
> > your project.   For projects, we want to make it even easier to the
> > point where you don't even need the json file to get a default
> > configuration.
> Ah, that makes more sense.
> >>>> * Keycloak CLI - Should we create our own or use WildFly CLI
> >> On the one hand the wildfly CLI is black magic.  On the other hand it is
> >> really well done black magic.  It is very hard to do CLIs well so I
> >> would like to see the wildfly CLI be used.
> > That's the general feedback we often get from the WildFly community.  I
> > agree.
> >>>> * Admin operations exposed over DMR - Should we expose none, some or all
> >>>> admin operations over DMR? If we expose all should we deprecate the
> >>>> current
> >>>> REST endpoints?
> >> Is DMR the thing that puts stuff in the WildFly admin UI (I tried to
> >> read the google result for "wildfly DMR" but it quickly turned into
> >> turtles all the way down)?
> > At its core, DMR is really just a tiny single-package library where the
> > API is just 3 or 4 classes.  Those classes are the "language" spoken to
> > make changes to the WildFly management model
> > (standalone.xml/domain.xml).  So the question is whether we should hook
> > into the management model infrastructure to make Keycloak changes.
> >> In my experience I don't LIKE using the WildFly admin UI, I would rather
> >> use the CLI, scripts, etc.
> > Also a typical response.  Again, I agree.  Thankfully, the Keycloak
> > admin UI doesn't suffer from the same deficiencies as the WildFly admin UI.
> >
> > But with Keycloak, we don't yet have a CLI, so there are lots of
> > questions around whether we piggyback on WildFly CLI, which means
> > adopting DMR in some way.
> >> I haven't used the KeyCloak REST endpoints
> >> and keeping them just increases the attack surface.
> > Do you mean that keeping the REST endpoints would be a good thing or a
> > bad thing?  Can we hear more from you on this topic?
> I think that if there were a WildFly way to do all of the admin tasks
> that the RESTful endpoints do now it would be good to remove the RESTful
> API to decrease the API surface to just WildFly.  IE fewer things to
> worry about getting hacked and to watch for for vulnerabilities.
> >>>> * Packaging/distribution - How do we distribute Keycloak? Options:
> >>>>      - Full WildFly
> >>>>      - Core/web WildFly
> >>>>      - Overlay/installer/feature-pack to install to existing WF and EAP
> >>>>      - WAR bundle
> >> How about a shell script that examines a WF install directory and does
> >> all the magic for me or aDocker container?
> >>
> >> In general I have not liked the experience of having wildfly bundled
> >> with a product.  It tends to mess with other servers I have installed
> >> and be a general PITA to maintain for anything more than the most
> >> trivial of demos.
> > Good feedback.
> >>>> * How should we deal with providers, themes and keycloak-server.json in
> >>>> domain-mode
> >>>>
> >>>> * MSC all the way - We can deploy directly through the Undertow
> >>>> sub-system
> >>>> instead of deploying a WAR from the sub-system
> >> What is MSC?
> > Modular Service Container.  It's the thing that lets you declare and
> > register services in WildFly.  But I'm not completely sure what Stian is
> > proposing here.
> >>>> * Split sub-systems - Should we split the sub-system in two? One for the
> >>>> auth-server and another for the adapter
> >> What are the trade offs?  What will using KeyCloak look like from my POV
> >> if we split?
> > Instead of
> >
> > subsystem=keycloak/auth-server=main-auth-server
> > subsystem=keycloak/secure-deployment=foo
> >
> > you would have
> >
> > subsystem=keycloak-server/auth-server=main-auth-server
> > subsystem=keycloak-deployments/secure-deployment=foo
> >
> > Another option would be to just leave it as it is today and just hide
> > the "auth-server" resource for installations where you don't expect the
> > auth server to run.
> >
> > The answer will probably be more a function of how we want to organize
> > the code rather than how it will look to the end user.
> As a end user it sounds like both work for me.
> >>>> * Deployable to other containers - Should it be possible to deploy
> >>>> Keycloak
> >>>> to Tomcat, Jetty, Fuse, etc..? One option could be to have reduced
> >>>> features
> >>>> in other containers (for example no client-cert)
> >> The awesomeness of WildFly has forever made web containers look
> >> insignificant to me.  If Glassfish still had a community edition worth a
> >> damn I would say target it as well.  I don't know how TomEE is but that
> >> may be good to support just for a "first one's free" to get people into
> >> WildFly land.
> >>
> >> I don't think Websphere or WebLogic support has ever gotten anyone
> >> excited about a project.  Honestly they are the technology equivalent of
> >> taking a cold shower with grandma.
> > I could have done without that image. :-|
> >
> > But thanks again!
> YW.
> >>>> Please add any other relevant topics.
> >>>>
> >>>> Next big discussion I want to have is about distribution of adapters,
> >>>> but
> >>>> let's do one at a time ;)
> >>>> _______________________________________________
> >>>> 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
> 
> 
> --
> Summers Pittman
> >>Phone:404 941 4698
> >>Java is my crack.
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Mon Feb 23 09:54:49 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 23 Feb 2015 09:54:49 -0500 (EST)
Subject: [keycloak-dev] How to render claim data entry and display?
In-Reply-To: <54EB3C7F.8030005@redhat.com>
References: <54E698B7.9070301@redhat.com>
	<1308263357.13371167.1424697716848.JavaMail.zimbra@redhat.com>
	<54EB3231.4010801@redhat.com>
	<1173260015.13425581.1424700829009.JavaMail.zimbra@redhat.com>
	<54EB3C7F.8030005@redhat.com>
Message-ID: <1931847651.13487138.1424703289301.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, February 23, 2015 3:43:11 PM
> Subject: Re: [keycloak-dev] How to render claim data entry and display?
> 
> 
> 
> On 2/23/2015 9:13 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Monday, February 23, 2015 2:59:13 PM
> >> Subject: Re: [keycloak-dev] How to render claim data entry and display?
> >>
> >>
> >>
> >> On 2/23/2015 8:21 AM, Stian Thorgersen wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Friday, February 20, 2015 3:15:19 AM
> >>>> Subject: [keycloak-dev] How to render claim data entry and display?
> >>>>
> >>>> I'm not sure how to render claims within the admin console, registration
> >>>> page, and in the user self service pages.  The thing is that generically
> >>>> rendering user metadata can look quite ugly.  Address is one example
> >>>> where the grouping and ordering of each attribute is important to look
> >>>> nice.  There are other instances where you need to group types of data
> >>>> together (home phone, fax, work phone, mobile).  Then there is the
> >>>> problem of what claim data do you show on what pages which is harder
> >>>> than it seems, for example, registration page might only require a
> >>>> mobile number, but admin console and user profile page might want to
> >>>> show home, fax, work too.  You would end up having to define a data
> >>>> model that captured metadata for each page type (registration, user
> >>>> profile, and admin console).  Finally, if you have generically rendered
> >>>> claims, what happens when the user wants to override this rendering and
> >>>> put their own formatting, .css types, etc. in?
> >>>>
> >>>> This leads me to think that we should just punt to the developer.  In
> >>>> this case, there would be no data model for claim types and everything
> >>>> would be driven simply off of UserModel.attributes.  Develoeprs would
> >>>> have to extend the admin console and account themes and we would provide
> >>>> a template for referencing UserModel.attribute data within Angular HTML
> >>>> (admin console) or Framemaker (account service, registration page).
> >>>
> >>> For registration page and account management I think supporting simple
> >>> attributes in the default template would be good enough. Users can then
> >>> extend the templates if they need something more. In the future we can
> >>> look into creating widgets that can display certain things so users don't
> >>> have to extend the whole template, but just parts of it.
> >>>
> >>> For the admin console it would be best not to require users to extend
> >>> IMO.
> >>> We should be able to allow users to view and edit complex attributes (at
> >>> least a complex attribute that is a list of simple, rather than complex
> >>> of
> >>> complex). Initially we could just display the JSON for the complex
> >>> attribute directly, then create an view/editor for it later.
> >>>
> >>
> >> I just don't want us spending time implementing and maintaining an HTML
> >> editor for something the user will usually be extending a theme for
> >> anyways.
> >
> > Yes, I totally agree, but that wasn't what I proposed though. What I'd
> > propose we do is:
> >
> > * Admin console - just list claims, sorted by name. For simple types we
> > display the value and allow editing with input text. For complex we
> > display json and allow editing in textarea. In the future we can add a
> > feature that allows view/edit complex attributes directly.
> > * Registration and account management - only display simple types. We
> > should provide some mechanism for choosing which are displayed and order.
> > For complex types or better control on how it's displayed (other than a
> > simple list of label, input) users are expected to extend the template. In
> > the future we can add a feature that allows extending parts of a template,
> > which would make it easier to edit and also maintain in the long run. For
> > example instead of overriding the whole registration page a user could
> > override just the form part, or even just how a specific claim is
> > displayed.
> >
> 
> I think users will be extending our themes anyways almost every time
> (except the admin console).  As, again, anything generically rendered
> will look ugly and unprofessional.  I started off implementing it the
> way you are saying...but then I was like, "This is dumb and will look
> like shit".

I disagree. A lot customization can be done through pure-CSS (have a look at http://www.csszengarden.com/ if you don't believe me) and in the event they need to modify the HTML they most likely only want to change a small part of it. Requiring users to override the registration page just to display a dob field for example is not good usability IMO.

> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Mon Feb 23 09:30:53 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 23 Feb 2015 09:30:53 -0500
Subject: [keycloak-dev] How to do default claim mappings?
In-Reply-To: <204784861.12997302.1424678852848.JavaMail.zimbra@redhat.com>
References: <54E7571B.6080007@redhat.com>
	<204784861.12997302.1424678852848.JavaMail.zimbra@redhat.com>
Message-ID: <54EB399D.7040208@redhat.com>



On 2/23/2015 3:07 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, February 20, 2015 4:47:39 PM
>> Subject: [keycloak-dev] How to do default claim mappings?
>>
>> Per realm and per protocol (saml or OIDC), I'm going to need to register
>> a set of default claim mappers into storage.  ProviderFactorys are
>> loaded at boot time and each of their init() methods is invoked.  I'm
>> thinking of adding a new method to ProviderFactory
>>
>> void preprocess(KeycloakSessionFactory sessionFactory);
>>
>> This would be called after all providers have been loaded.  This would
>> allow the OIDC and SAML providers to browser every realm to make sure
>> the appropriate built in claim mappers have been registered.
>>
>> I'm also thinking of adding a RealmCreationListener registration method
>> on RealmProvider.  Within ProviderFactory.preprocess() components could
>> register themselves with the RealmProvider for realm creation events so
>> that they could add additional metadata specific to their plugin.
>
> preprocess is fine, except it adds a method that most providers won't use and also the name is a bit confusing.
>
> RealmCreationListener is fine, but what if we add more and more "events" providers can listen to. We'll get a lot of methods and listener types.
>
> What about adding a general purpose event listener framework for providers? We can add
>
> * ProviderEventListener ProviderFactory.getProviderEventListener()
>
> The bootstrapping process would after calling init on all ProviderFactory, call getProviderEventListener. If it returns null it won't register it, but otherwise it'll add it to the list of listeners.
>
> ProviderEventListener would have the following method:
>
> * void onEvent(ProviderEvent event)
>
> ProviderEvent would have:
>
> * EventType type
> * Map<String, String> details
>

You're right.  Probably shouldn't be so specific and should leave some 
room for more event types.

But...

You can't really have KeycloakSessionFactory control a generic listener 
framework.  Otherwise the KeycloakSessionFactory is going to have to 
know about every event type and which provider they must be registered 
with.  Also, you don't need an EventType or Map of details.  Just do 
instanceof/typecast to the specific event type.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Mon Feb 23 10:20:17 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 23 Feb 2015 10:20:17 -0500
Subject: [keycloak-dev] How to render claim data entry and display?
In-Reply-To: <1931847651.13487138.1424703289301.JavaMail.zimbra@redhat.com>
References: <54E698B7.9070301@redhat.com>
	<1308263357.13371167.1424697716848.JavaMail.zimbra@redhat.com>
	<54EB3231.4010801@redhat.com>
	<1173260015.13425581.1424700829009.JavaMail.zimbra@redhat.com>
	<54EB3C7F.8030005@redhat.com>
	<1931847651.13487138.1424703289301.JavaMail.zimbra@redhat.com>
Message-ID: <54EB4531.1000502@redhat.com>



On 2/23/2015 9:54 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Monday, February 23, 2015 3:43:11 PM
>> Subject: Re: [keycloak-dev] How to render claim data entry and display?
>>
>>
>>
>> On 2/23/2015 9:13 AM, Stian Thorgersen wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Monday, February 23, 2015 2:59:13 PM
>>>> Subject: Re: [keycloak-dev] How to render claim data entry and display?
>>>>
>>>>
>>>>
>>>> On 2/23/2015 8:21 AM, Stian Thorgersen wrote:
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>> Sent: Friday, February 20, 2015 3:15:19 AM
>>>>>> Subject: [keycloak-dev] How to render claim data entry and display?
>>>>>>
>>>>>> I'm not sure how to render claims within the admin console, registration
>>>>>> page, and in the user self service pages.  The thing is that generically
>>>>>> rendering user metadata can look quite ugly.  Address is one example
>>>>>> where the grouping and ordering of each attribute is important to look
>>>>>> nice.  There are other instances where you need to group types of data
>>>>>> together (home phone, fax, work phone, mobile).  Then there is the
>>>>>> problem of what claim data do you show on what pages which is harder
>>>>>> than it seems, for example, registration page might only require a
>>>>>> mobile number, but admin console and user profile page might want to
>>>>>> show home, fax, work too.  You would end up having to define a data
>>>>>> model that captured metadata for each page type (registration, user
>>>>>> profile, and admin console).  Finally, if you have generically rendered
>>>>>> claims, what happens when the user wants to override this rendering and
>>>>>> put their own formatting, .css types, etc. in?
>>>>>>
>>>>>> This leads me to think that we should just punt to the developer.  In
>>>>>> this case, there would be no data model for claim types and everything
>>>>>> would be driven simply off of UserModel.attributes.  Develoeprs would
>>>>>> have to extend the admin console and account themes and we would provide
>>>>>> a template for referencing UserModel.attribute data within Angular HTML
>>>>>> (admin console) or Framemaker (account service, registration page).
>>>>>
>>>>> For registration page and account management I think supporting simple
>>>>> attributes in the default template would be good enough. Users can then
>>>>> extend the templates if they need something more. In the future we can
>>>>> look into creating widgets that can display certain things so users don't
>>>>> have to extend the whole template, but just parts of it.
>>>>>
>>>>> For the admin console it would be best not to require users to extend
>>>>> IMO.
>>>>> We should be able to allow users to view and edit complex attributes (at
>>>>> least a complex attribute that is a list of simple, rather than complex
>>>>> of
>>>>> complex). Initially we could just display the JSON for the complex
>>>>> attribute directly, then create an view/editor for it later.
>>>>>
>>>>
>>>> I just don't want us spending time implementing and maintaining an HTML
>>>> editor for something the user will usually be extending a theme for
>>>> anyways.
>>>
>>> Yes, I totally agree, but that wasn't what I proposed though. What I'd
>>> propose we do is:
>>>
>>> * Admin console - just list claims, sorted by name. For simple types we
>>> display the value and allow editing with input text. For complex we
>>> display json and allow editing in textarea. In the future we can add a
>>> feature that allows view/edit complex attributes directly.
>>> * Registration and account management - only display simple types. We
>>> should provide some mechanism for choosing which are displayed and order.
>>> For complex types or better control on how it's displayed (other than a
>>> simple list of label, input) users are expected to extend the template. In
>>> the future we can add a feature that allows extending parts of a template,
>>> which would make it easier to edit and also maintain in the long run. For
>>> example instead of overriding the whole registration page a user could
>>> override just the form part, or even just how a specific claim is
>>> displayed.
>>>
>>
>> I think users will be extending our themes anyways almost every time
>> (except the admin console).  As, again, anything generically rendered
>> will look ugly and unprofessional.  I started off implementing it the
>> way you are saying...but then I was like, "This is dumb and will look
>> like shit".
>
> I disagree. A lot customization can be done through pure-CSS (have a look at http://www.csszengarden.com/ if you don't believe me) and in the event they need to modify the HTML they most likely only want to change a small part of it. Requiring users to override the registration page just to display a dob field for example is not good usability IMO.
>

Would be nice if you are right, but I don't agree yet.  I don't know 
enough about .css.  Don't you still have to have some semblance of 
structure in your HTML document (field sets and order.  And all this per 
page)?



-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Mon Feb 23 10:24:04 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 23 Feb 2015 10:24:04 -0500
Subject: [keycloak-dev] Keycloak.js is inefficient and can be improved
In-Reply-To: <54200941.13466086.1424702302431.JavaMail.zimbra@redhat.com>
References: <54D939D8.2050407@redhat.com>
	<1378179913.13437209.1424701617889.JavaMail.zimbra@redhat.com>
	<54EB3A64.5030007@redhat.com>
	<54200941.13466086.1424702302431.JavaMail.zimbra@redhat.com>
Message-ID: <54EB4614.90505@redhat.com>



On 2/23/2015 9:38 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Monday, February 23, 2015 3:34:12 PM
>> Subject: Re: [keycloak-dev] Keycloak.js is inefficient and can be improved
>>
>> Verifying the token would be a must for implicit flow, IMO.  Not so much
>> for access code flow though.
>
> Should we add support for implicit flow?
>

No, as it looks like implicit flow can leak access tokens into the 
browser history which could lead to accidental bookmarks or rogue 
scripts looking at browser history.  Code is protected as the code can 
only be used once, so if it leaks there's not much you can do about it. 
  Especially if you enforce CORS origin validation (which I don't think 
we do right now).

>>
>> For access code flow it is not really possible to fool the javascript
>> provider because of the "state" parameter, and obtaining an access token
>> happens out of band.
>
> We support passing tokens to keycloak.js to initialize it, but not sure if that could be exploited
>

Not sure what that feature is or if it should even be supported.  Sounds 
close to what the implicit flow is.



-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Mon Feb 23 10:29:24 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 23 Feb 2015 10:29:24 -0500 (EST)
Subject: [keycloak-dev] How to render claim data entry and display?
In-Reply-To: <54EB4531.1000502@redhat.com>
References: <54E698B7.9070301@redhat.com>
	<1308263357.13371167.1424697716848.JavaMail.zimbra@redhat.com>
	<54EB3231.4010801@redhat.com>
	<1173260015.13425581.1424700829009.JavaMail.zimbra@redhat.com>
	<54EB3C7F.8030005@redhat.com>
	<1931847651.13487138.1424703289301.JavaMail.zimbra@redhat.com>
	<54EB4531.1000502@redhat.com>
Message-ID: <29496803.13535625.1424705364105.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, February 23, 2015 4:20:17 PM
> Subject: Re: [keycloak-dev] How to render claim data entry and display?
> 
> 
> 
> On 2/23/2015 9:54 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Monday, February 23, 2015 3:43:11 PM
> >> Subject: Re: [keycloak-dev] How to render claim data entry and display?
> >>
> >>
> >>
> >> On 2/23/2015 9:13 AM, Stian Thorgersen wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: "Stian Thorgersen" <stian at redhat.com>
> >>>> Cc: keycloak-dev at lists.jboss.org
> >>>> Sent: Monday, February 23, 2015 2:59:13 PM
> >>>> Subject: Re: [keycloak-dev] How to render claim data entry and display?
> >>>>
> >>>>
> >>>>
> >>>> On 2/23/2015 8:21 AM, Stian Thorgersen wrote:
> >>>>>
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>> Sent: Friday, February 20, 2015 3:15:19 AM
> >>>>>> Subject: [keycloak-dev] How to render claim data entry and display?
> >>>>>>
> >>>>>> I'm not sure how to render claims within the admin console,
> >>>>>> registration
> >>>>>> page, and in the user self service pages.  The thing is that
> >>>>>> generically
> >>>>>> rendering user metadata can look quite ugly.  Address is one example
> >>>>>> where the grouping and ordering of each attribute is important to look
> >>>>>> nice.  There are other instances where you need to group types of data
> >>>>>> together (home phone, fax, work phone, mobile).  Then there is the
> >>>>>> problem of what claim data do you show on what pages which is harder
> >>>>>> than it seems, for example, registration page might only require a
> >>>>>> mobile number, but admin console and user profile page might want to
> >>>>>> show home, fax, work too.  You would end up having to define a data
> >>>>>> model that captured metadata for each page type (registration, user
> >>>>>> profile, and admin console).  Finally, if you have generically
> >>>>>> rendered
> >>>>>> claims, what happens when the user wants to override this rendering
> >>>>>> and
> >>>>>> put their own formatting, .css types, etc. in?
> >>>>>>
> >>>>>> This leads me to think that we should just punt to the developer.  In
> >>>>>> this case, there would be no data model for claim types and everything
> >>>>>> would be driven simply off of UserModel.attributes.  Develoeprs would
> >>>>>> have to extend the admin console and account themes and we would
> >>>>>> provide
> >>>>>> a template for referencing UserModel.attribute data within Angular
> >>>>>> HTML
> >>>>>> (admin console) or Framemaker (account service, registration page).
> >>>>>
> >>>>> For registration page and account management I think supporting simple
> >>>>> attributes in the default template would be good enough. Users can then
> >>>>> extend the templates if they need something more. In the future we can
> >>>>> look into creating widgets that can display certain things so users
> >>>>> don't
> >>>>> have to extend the whole template, but just parts of it.
> >>>>>
> >>>>> For the admin console it would be best not to require users to extend
> >>>>> IMO.
> >>>>> We should be able to allow users to view and edit complex attributes
> >>>>> (at
> >>>>> least a complex attribute that is a list of simple, rather than complex
> >>>>> of
> >>>>> complex). Initially we could just display the JSON for the complex
> >>>>> attribute directly, then create an view/editor for it later.
> >>>>>
> >>>>
> >>>> I just don't want us spending time implementing and maintaining an HTML
> >>>> editor for something the user will usually be extending a theme for
> >>>> anyways.
> >>>
> >>> Yes, I totally agree, but that wasn't what I proposed though. What I'd
> >>> propose we do is:
> >>>
> >>> * Admin console - just list claims, sorted by name. For simple types we
> >>> display the value and allow editing with input text. For complex we
> >>> display json and allow editing in textarea. In the future we can add a
> >>> feature that allows view/edit complex attributes directly.
> >>> * Registration and account management - only display simple types. We
> >>> should provide some mechanism for choosing which are displayed and order.
> >>> For complex types or better control on how it's displayed (other than a
> >>> simple list of label, input) users are expected to extend the template.
> >>> In
> >>> the future we can add a feature that allows extending parts of a
> >>> template,
> >>> which would make it easier to edit and also maintain in the long run. For
> >>> example instead of overriding the whole registration page a user could
> >>> override just the form part, or even just how a specific claim is
> >>> displayed.
> >>>
> >>
> >> I think users will be extending our themes anyways almost every time
> >> (except the admin console).  As, again, anything generically rendered
> >> will look ugly and unprofessional.  I started off implementing it the
> >> way you are saying...but then I was like, "This is dumb and will look
> >> like shit".
> >
> > I disagree. A lot customization can be done through pure-CSS (have a look
> > at http://www.csszengarden.com/ if you don't believe me) and in the event
> > they need to modify the HTML they most likely only want to change a small
> > part of it. Requiring users to override the registration page just to
> > display a dob field for example is not good usability IMO.
> >
> 
> Would be nice if you are right, but I don't agree yet.  I don't know
> enough about .css.  Don't you still have to have some semblance of
> structure in your HTML document (field sets and order.  And all this per
> page)?

Of course I'm right ;)

You do have to have some structure that's correct, but it's more about content than layout if that makes sense. 

We can add this iteratively though. First add support for custom claims and a way to obtain them from a custom template. Then we can look into a way of not requiring custom templates, at least for the simpler use cases.

> 
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From stian at redhat.com  Mon Feb 23 10:36:26 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 23 Feb 2015 10:36:26 -0500 (EST)
Subject: [keycloak-dev] Keycloak.js is inefficient and can be improved
In-Reply-To: <54EB4614.90505@redhat.com>
References: <54D939D8.2050407@redhat.com>
	<1378179913.13437209.1424701617889.JavaMail.zimbra@redhat.com>
	<54EB3A64.5030007@redhat.com>
	<54200941.13466086.1424702302431.JavaMail.zimbra@redhat.com>
	<54EB4614.90505@redhat.com>
Message-ID: <480017372.13545758.1424705786222.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, February 23, 2015 4:24:04 PM
> Subject: Re: [keycloak-dev] Keycloak.js is inefficient and can be improved
> 
> 
> 
> On 2/23/2015 9:38 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Monday, February 23, 2015 3:34:12 PM
> >> Subject: Re: [keycloak-dev] Keycloak.js is inefficient and can be improved
> >>
> >> Verifying the token would be a must for implicit flow, IMO.  Not so much
> >> for access code flow though.
> >
> > Should we add support for implicit flow?
> >
> 
> No, as it looks like implicit flow can leak access tokens into the
> browser history which could lead to accidental bookmarks or rogue
> scripts looking at browser history.  Code is protected as the code can
> only be used once, so if it leaks there's not much you can do about it.
>   Especially if you enforce CORS origin validation (which I don't think
> we do right now).

I agree, but we often get requests for it, so I was wondering if we should make an option on the realm to enable. 

We only allow CORS origins that have been explicitly configured for the application.

> 
> >>
> >> For access code flow it is not really possible to fool the javascript
> >> provider because of the "state" parameter, and obtaining an access token
> >> happens out of band.
> >
> > We support passing tokens to keycloak.js to initialize it, but not sure if
> > that could be exploited
> >
> 
> Not sure what that feature is or if it should even be supported.  Sounds
> close to what the implicit flow is.

Nothing like implicit. Basically the idea was that someone could store the refresh token in HTML5 local or session storage and then use it to re-initialize keycloak.js when the page is refreshed. 

One issue with keycloak.js is that every time you refresh the page the app is re-logged-in (creating a new client session), same if you have multiple tabs open. I was thinking we should introduce an option to allow storing the refresh token in html5 storage to prevent this. We could also store the token, which would be useful to prevent refreshing the token multiple times if there's multiple tabs open to the same app.

> 
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From supittma at redhat.com  Mon Feb 23 10:42:19 2015
From: supittma at redhat.com (Summers Pittman)
Date: Mon, 23 Feb 2015 10:42:19 -0500
Subject: [keycloak-dev] WildFly integration (READ ME!)
In-Reply-To: <704793002.13480640.1424703042016.JavaMail.zimbra@redhat.com>
References: <969708031.6108771.1422954530044.JavaMail.zimbra@redhat.com>
	<1360543918.10348397.1424334753943.JavaMail.zimbra@redhat.com>
	<54E74D1C.4030600@redhat.com> <54E77464.2050400@redhat.com>
	<54E77884.7050003@redhat.com>
	<704793002.13480640.1424703042016.JavaMail.zimbra@redhat.com>
Message-ID: <54EB4A5B.6040201@redhat.com>

On 02/23/2015 09:50 AM, Stian Thorgersen wrote:
> Just to clarify we're only talking about the server, not adapters.
>
> For the best and most friction free experience it would be best to have a dedicated Keycloak server, not to co-locate it with your JEE apps by deploying a WAR. With that regards we are considering dropping support for deploying Keycloak as a WAR.
If I'm reading you correctly instead of

    ~/WILDFLY_HOME/bin/startup.sh
    code


it will be


    $WILDFLY_HOME/bin/startup.sh
    code
    #^@%! what broke in my auth
    waste 10 minutes
    $KEYCLOAK_HOME/bin/startup.sh

By keeping it a separate war 1) I can download the thing faster and 2) I 
don't have to decide who to kick off of port 8080.

Again, IF I'm reading your message correctly

>
> That being said we still need to support embedding Keycloak in other projects. We plan to continue to support this through the mechanism UPS does, basically build-your-own auth-server.war.
>
> ----- Original Message -----
>> From: "Summers Pittman" <supittma at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Friday, February 20, 2015 7:10:12 PM
>> Subject: Re: [keycloak-dev] WildFly integration (READ ME!)
>>
>> On 02/20/2015 12:52 PM, Stan Silvert wrote:
>>> On 2/20/2015 10:05 AM, Summers Pittman wrote:
>>>> On 02/19/2015 03:32 AM, Stian Thorgersen wrote:
>>>>> No comments?!
>>>> Peanut gallery chiming in; you asked for it ;)
>>>>
>>>> I am not a WildFly developer or administrator.  So read this email as
>>>> the opinions of a talented developer who loves the hell out of using
>>>> KeyCloak and WildFly and sings its praises from the roof tops but has no
>>>> idea what you are talking about.
>>> Thanks Summers.  Very valuable feedback.
>> Thanks for taking the time to explain some things I know more than I did
>> this morning.
>>>>> ----- Original Message -----
>>>>>> From: "Stian Thorgersen" <stian at redhat.com>
>>>>>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>>>>>> Sent: Tuesday, February 3, 2015 10:08:50 AM
>>>>>> Subject: [keycloak-dev] WildFly integration (READ ME!)
>>>>>>
>>>>>> All,
>>>>>>
>>>>>> We have a few decisions to make in the not so far future. I'm away from
>>>>>> Thursday, so let's have a hangout when I get back on the 17th February
>>>>>> if
>>>>>> that works for everyone.
>>>>>>
>>>>>> The list of things to discuss includes:
>>>>>>
>>>>>> * Drop keycloak-server.json - Should we drop our own configuration file
>>>>>> and
>>>>>> use DMR (standalone.xml)
>>>> If on day one enabling KeyCloak in my project was any more complicated
>>>> than dropping a pregenerated file into my WEB-INF directory I would have
>>>> closed the project and never looked back.  -1
>>> We're talking about the auth server's config rather than the config for
>>> your project.   For projects, we want to make it even easier to the
>>> point where you don't even need the json file to get a default
>>> configuration.
>> Ah, that makes more sense.
>>>>>> * Keycloak CLI - Should we create our own or use WildFly CLI
>>>> On the one hand the wildfly CLI is black magic.  On the other hand it is
>>>> really well done black magic.  It is very hard to do CLIs well so I
>>>> would like to see the wildfly CLI be used.
>>> That's the general feedback we often get from the WildFly community.  I
>>> agree.
>>>>>> * Admin operations exposed over DMR - Should we expose none, some or all
>>>>>> admin operations over DMR? If we expose all should we deprecate the
>>>>>> current
>>>>>> REST endpoints?
>>>> Is DMR the thing that puts stuff in the WildFly admin UI (I tried to
>>>> read the google result for "wildfly DMR" but it quickly turned into
>>>> turtles all the way down)?
>>> At its core, DMR is really just a tiny single-package library where the
>>> API is just 3 or 4 classes.  Those classes are the "language" spoken to
>>> make changes to the WildFly management model
>>> (standalone.xml/domain.xml).  So the question is whether we should hook
>>> into the management model infrastructure to make Keycloak changes.
>>>> In my experience I don't LIKE using the WildFly admin UI, I would rather
>>>> use the CLI, scripts, etc.
>>> Also a typical response.  Again, I agree.  Thankfully, the Keycloak
>>> admin UI doesn't suffer from the same deficiencies as the WildFly admin UI.
>>>
>>> But with Keycloak, we don't yet have a CLI, so there are lots of
>>> questions around whether we piggyback on WildFly CLI, which means
>>> adopting DMR in some way.
>>>> I haven't used the KeyCloak REST endpoints
>>>> and keeping them just increases the attack surface.
>>> Do you mean that keeping the REST endpoints would be a good thing or a
>>> bad thing?  Can we hear more from you on this topic?
>> I think that if there were a WildFly way to do all of the admin tasks
>> that the RESTful endpoints do now it would be good to remove the RESTful
>> API to decrease the API surface to just WildFly.  IE fewer things to
>> worry about getting hacked and to watch for for vulnerabilities.
>>>>>> * Packaging/distribution - How do we distribute Keycloak? Options:
>>>>>>       - Full WildFly
>>>>>>       - Core/web WildFly
>>>>>>       - Overlay/installer/feature-pack to install to existing WF and EAP
>>>>>>       - WAR bundle
>>>> How about a shell script that examines a WF install directory and does
>>>> all the magic for me or aDocker container?
>>>>
>>>> In general I have not liked the experience of having wildfly bundled
>>>> with a product.  It tends to mess with other servers I have installed
>>>> and be a general PITA to maintain for anything more than the most
>>>> trivial of demos.
>>> Good feedback.
>>>>>> * How should we deal with providers, themes and keycloak-server.json in
>>>>>> domain-mode
>>>>>>
>>>>>> * MSC all the way - We can deploy directly through the Undertow
>>>>>> sub-system
>>>>>> instead of deploying a WAR from the sub-system
>>>> What is MSC?
>>> Modular Service Container.  It's the thing that lets you declare and
>>> register services in WildFly.  But I'm not completely sure what Stian is
>>> proposing here.
>>>>>> * Split sub-systems - Should we split the sub-system in two? One for the
>>>>>> auth-server and another for the adapter
>>>> What are the trade offs?  What will using KeyCloak look like from my POV
>>>> if we split?
>>> Instead of
>>>
>>> subsystem=keycloak/auth-server=main-auth-server
>>> subsystem=keycloak/secure-deployment=foo
>>>
>>> you would have
>>>
>>> subsystem=keycloak-server/auth-server=main-auth-server
>>> subsystem=keycloak-deployments/secure-deployment=foo
>>>
>>> Another option would be to just leave it as it is today and just hide
>>> the "auth-server" resource for installations where you don't expect the
>>> auth server to run.
>>>
>>> The answer will probably be more a function of how we want to organize
>>> the code rather than how it will look to the end user.
>> As a end user it sounds like both work for me.
>>>>>> * Deployable to other containers - Should it be possible to deploy
>>>>>> Keycloak
>>>>>> to Tomcat, Jetty, Fuse, etc..? One option could be to have reduced
>>>>>> features
>>>>>> in other containers (for example no client-cert)
>>>> The awesomeness of WildFly has forever made web containers look
>>>> insignificant to me.  If Glassfish still had a community edition worth a
>>>> damn I would say target it as well.  I don't know how TomEE is but that
>>>> may be good to support just for a "first one's free" to get people into
>>>> WildFly land.
>>>>
>>>> I don't think Websphere or WebLogic support has ever gotten anyone
>>>> excited about a project.  Honestly they are the technology equivalent of
>>>> taking a cold shower with grandma.
>>> I could have done without that image. :-|
>>>
>>> But thanks again!
>> YW.
>>>>>> Please add any other relevant topics.
>>>>>>
>>>>>> Next big discussion I want to have is about distribution of adapters,
>>>>>> but
>>>>>> let's do one at a time ;)
>>>>>> _______________________________________________
>>>>>> 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
>>
>> --
>> Summers Pittman
>>>> Phone:404 941 4698
>>>> Java is my crack.
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>



-- 
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150223/ff68e48f/attachment.html 

From ssilvert at redhat.com  Mon Feb 23 11:09:12 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 23 Feb 2015 11:09:12 -0500
Subject: [keycloak-dev] WildFly integration (READ ME!)
In-Reply-To: <54EB4A5B.6040201@redhat.com>
References: <969708031.6108771.1422954530044.JavaMail.zimbra@redhat.com>
	<1360543918.10348397.1424334753943.JavaMail.zimbra@redhat.com>
	<54E74D1C.4030600@redhat.com> <54E77464.2050400@redhat.com>
	<54E77884.7050003@redhat.com>
	<704793002.13480640.1424703042016.JavaMail.zimbra@redhat.com>
	<54EB4A5B.6040201@redhat.com>
Message-ID: <54EB50A8.6050702@redhat.com>

On 2/23/2015 10:42 AM, Summers Pittman wrote:
> On 02/23/2015 09:50 AM, Stian Thorgersen wrote:
>> Just to clarify we're only talking about the server, not adapters.
>>
>> For the best and most friction free experience it would be best to have a dedicated Keycloak server, not to co-locate it with your JEE apps by deploying a WAR. With that regards we are considering dropping support for deploying Keycloak as a WAR.
> If I'm reading you correctly instead of
>
>     ~/WILDFLY_HOME/bin/startup.sh
>     code
>
>
> it will be
>
>
>     $WILDFLY_HOME/bin/startup.sh
>     code
>     #^@%! what broke in my auth
>     waste 10 minutes
>     $KEYCLOAK_HOME/bin/startup.sh
>
I don't understand.  What would break?
>
> By keeping it a separate war 1) I can download the thing faster and 2) 
> I don't have to decide who to kick off of port 8080.
I don't think we would do anything to ban you from deploying your apps 
in the same WildFly instance as Keycloak.   Can you explain your 
concerns in more detail?
>
> Again, IF I'm reading your message correctly
>
>> That being said we still need to support embedding Keycloak in other projects. We plan to continue to support this through the mechanism UPS does, basically build-your-own auth-server.war.
>>
>> ----- Original Message -----
>>> From: "Summers Pittman"<supittma at redhat.com>
>>> To:keycloak-dev at lists.jboss.org
>>> Sent: Friday, February 20, 2015 7:10:12 PM
>>> Subject: Re: [keycloak-dev] WildFly integration (READ ME!)
>>>
>>> On 02/20/2015 12:52 PM, Stan Silvert wrote:
>>>> On 2/20/2015 10:05 AM, Summers Pittman wrote:
>>>>> On 02/19/2015 03:32 AM, Stian Thorgersen wrote:
>>>>>> No comments?!
>>>>> Peanut gallery chiming in; you asked for it ;)
>>>>>
>>>>> I am not a WildFly developer or administrator.  So read this email as
>>>>> the opinions of a talented developer who loves the hell out of using
>>>>> KeyCloak and WildFly and sings its praises from the roof tops but has no
>>>>> idea what you are talking about.
>>>> Thanks Summers.  Very valuable feedback.
>>> Thanks for taking the time to explain some things I know more than I did
>>> this morning.
>>>>>> ----- Original Message -----
>>>>>>> From: "Stian Thorgersen"<stian at redhat.com>
>>>>>>> To: "keycloak dev"<keycloak-dev at lists.jboss.org>
>>>>>>> Sent: Tuesday, February 3, 2015 10:08:50 AM
>>>>>>> Subject: [keycloak-dev] WildFly integration (READ ME!)
>>>>>>>
>>>>>>> All,
>>>>>>>
>>>>>>> We have a few decisions to make in the not so far future. I'm away from
>>>>>>> Thursday, so let's have a hangout when I get back on the 17th February
>>>>>>> if
>>>>>>> that works for everyone.
>>>>>>>
>>>>>>> The list of things to discuss includes:
>>>>>>>
>>>>>>> * Drop keycloak-server.json - Should we drop our own configuration file
>>>>>>> and
>>>>>>> use DMR (standalone.xml)
>>>>> If on day one enabling KeyCloak in my project was any more complicated
>>>>> than dropping a pregenerated file into my WEB-INF directory I would have
>>>>> closed the project and never looked back.  -1
>>>> We're talking about the auth server's config rather than the config for
>>>> your project.   For projects, we want to make it even easier to the
>>>> point where you don't even need the json file to get a default
>>>> configuration.
>>> Ah, that makes more sense.
>>>>>>> * Keycloak CLI - Should we create our own or use WildFly CLI
>>>>> On the one hand the wildfly CLI is black magic.  On the other hand it is
>>>>> really well done black magic.  It is very hard to do CLIs well so I
>>>>> would like to see the wildfly CLI be used.
>>>> That's the general feedback we often get from the WildFly community.  I
>>>> agree.
>>>>>>> * Admin operations exposed over DMR - Should we expose none, some or all
>>>>>>> admin operations over DMR? If we expose all should we deprecate the
>>>>>>> current
>>>>>>> REST endpoints?
>>>>> Is DMR the thing that puts stuff in the WildFly admin UI (I tried to
>>>>> read the google result for "wildfly DMR" but it quickly turned into
>>>>> turtles all the way down)?
>>>> At its core, DMR is really just a tiny single-package library where the
>>>> API is just 3 or 4 classes.  Those classes are the "language" spoken to
>>>> make changes to the WildFly management model
>>>> (standalone.xml/domain.xml).  So the question is whether we should hook
>>>> into the management model infrastructure to make Keycloak changes.
>>>>> In my experience I don't LIKE using the WildFly admin UI, I would rather
>>>>> use the CLI, scripts, etc.
>>>> Also a typical response.  Again, I agree.  Thankfully, the Keycloak
>>>> admin UI doesn't suffer from the same deficiencies as the WildFly admin UI.
>>>>
>>>> But with Keycloak, we don't yet have a CLI, so there are lots of
>>>> questions around whether we piggyback on WildFly CLI, which means
>>>> adopting DMR in some way.
>>>>> I haven't used the KeyCloak REST endpoints
>>>>> and keeping them just increases the attack surface.
>>>> Do you mean that keeping the REST endpoints would be a good thing or a
>>>> bad thing?  Can we hear more from you on this topic?
>>> I think that if there were a WildFly way to do all of the admin tasks
>>> that the RESTful endpoints do now it would be good to remove the RESTful
>>> API to decrease the API surface to just WildFly.  IE fewer things to
>>> worry about getting hacked and to watch for for vulnerabilities.
>>>>>>> * Packaging/distribution - How do we distribute Keycloak? Options:
>>>>>>>       - Full WildFly
>>>>>>>       - Core/web WildFly
>>>>>>>       - Overlay/installer/feature-pack to install to existing WF and EAP
>>>>>>>       - WAR bundle
>>>>> How about a shell script that examines a WF install directory and does
>>>>> all the magic for me or aDocker container?
>>>>>
>>>>> In general I have not liked the experience of having wildfly bundled
>>>>> with a product.  It tends to mess with other servers I have installed
>>>>> and be a general PITA to maintain for anything more than the most
>>>>> trivial of demos.
>>>> Good feedback.
>>>>>>> * How should we deal with providers, themes and keycloak-server.json in
>>>>>>> domain-mode
>>>>>>>
>>>>>>> * MSC all the way - We can deploy directly through the Undertow
>>>>>>> sub-system
>>>>>>> instead of deploying a WAR from the sub-system
>>>>> What is MSC?
>>>> Modular Service Container.  It's the thing that lets you declare and
>>>> register services in WildFly.  But I'm not completely sure what Stian is
>>>> proposing here.
>>>>>>> * Split sub-systems - Should we split the sub-system in two? One for the
>>>>>>> auth-server and another for the adapter
>>>>> What are the trade offs?  What will using KeyCloak look like from my POV
>>>>> if we split?
>>>> Instead of
>>>>
>>>> subsystem=keycloak/auth-server=main-auth-server
>>>> subsystem=keycloak/secure-deployment=foo
>>>>
>>>> you would have
>>>>
>>>> subsystem=keycloak-server/auth-server=main-auth-server
>>>> subsystem=keycloak-deployments/secure-deployment=foo
>>>>
>>>> Another option would be to just leave it as it is today and just hide
>>>> the "auth-server" resource for installations where you don't expect the
>>>> auth server to run.
>>>>
>>>> The answer will probably be more a function of how we want to organize
>>>> the code rather than how it will look to the end user.
>>> As a end user it sounds like both work for me.
>>>>>>> * Deployable to other containers - Should it be possible to deploy
>>>>>>> Keycloak
>>>>>>> to Tomcat, Jetty, Fuse, etc..? One option could be to have reduced
>>>>>>> features
>>>>>>> in other containers (for example no client-cert)
>>>>> The awesomeness of WildFly has forever made web containers look
>>>>> insignificant to me.  If Glassfish still had a community edition worth a
>>>>> damn I would say target it as well.  I don't know how TomEE is but that
>>>>> may be good to support just for a "first one's free" to get people into
>>>>> WildFly land.
>>>>>
>>>>> I don't think Websphere or WebLogic support has ever gotten anyone
>>>>> excited about a project.  Honestly they are the technology equivalent of
>>>>> taking a cold shower with grandma.
>>>> I could have done without that image. :-|
>>>>
>>>> But thanks again!
>>> YW.
>>>>>>> Please add any other relevant topics.
>>>>>>>
>>>>>>> Next big discussion I want to have is about distribution of adapters,
>>>>>>> but
>>>>>>> let's do one at a time ;)
>>>>>>> _______________________________________________
>>>>>>> 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
>>> --
>>> Summers Pittman
>>>>> Phone:404 941 4698
>>>>> Java is my crack.
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>>
>
>
>
> -- 
> Summers Pittman
> >>Phone:404 941 4698
> >>Java is my crack.
>
>
> _______________________________________________
> 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/20150223/59ddb8f5/attachment-0001.html 

From bburke at redhat.com  Mon Feb 23 11:28:10 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 23 Feb 2015 11:28:10 -0500
Subject: [keycloak-dev] Simple mode?
Message-ID: <54EB551A.4010004@redhat.com>

Conversations with jboss.org guys got me thinking.  Should we have a 
"simple mode" for Keycloak where there is no concept of a client, 
application, or roles?  In this case,

* applications don't need session mgmt or single log out
* All applications are hosted under the same domain i.e  *.jboss.org 
(issues.jboss.org, forums.jboss.org, etc...)
* applications just need to know if 1) the user is logged in, 2) the 
username/id

So, "simple mode" would be:

* No applications/client panel
* No role pages anywhere
* Realm would have a global javascript referable cookie that contained 
basic information (userid, username, full name).  The domain and path 
would be configurable from admin console
* Realm would have a list of valid redirect URI patterns.
* Realm would have a default redirect page for unsolicited logins.




-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From gerbermichi at me.com  Mon Feb 23 11:53:39 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Mon, 23 Feb 2015 17:53:39 +0100
Subject: [keycloak-dev] Internationalization support (KEYCLOAK-301)
Message-ID: <D51883D0-3842-4376-B727-EF335EFAF2BC@me.com>

Hi all,

I started to work on the internationalization support (https://issues.jboss.org/browse/KEYCLOAK-301 <https://issues.jboss.org/browse/KEYCLOAK-301>).

I?ve already implemented the realm config in the admin console. I?ve put it into the ?Theme Setting? (see screenshot)
I added the possibility to enable internationalization, add supported locales and a select a default locale. 

Now I?d like to implement the logic which choose the correct locale. Therefore I need the http header, cookie, query parameter, realm and user.
The LoginFormsProvider and AccountProvider have all this information apart from the http header and the cookie. 
So I thought I could replace the UriInfo with the HttpRequest, but that doesn?t work, because I can not access the UriInfo through the HttpRequest (java.lang.NoSuchMethodError: org.jboss.resteasy.spi.HttpRequest.getUri()Ljavax/ws/rs/core/UriInfo;). So, I will add the HttpHeader to the LoginFormsProvider and AccountProvider, or does anyone have a better idea?

@Bill
How do you plan to store the claim ?locale? on a user? Will it be accessible through the UserModel interface?

Best
Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150223/3d59c545/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-6.png
Type: image/png
Size: 169359 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150223/3d59c545/attachment-0001.png 

From bburke at redhat.com  Mon Feb 23 12:00:24 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 23 Feb 2015 12:00:24 -0500
Subject: [keycloak-dev] Internationalization support (KEYCLOAK-301)
In-Reply-To: <D51883D0-3842-4376-B727-EF335EFAF2BC@me.com>
References: <D51883D0-3842-4376-B727-EF335EFAF2BC@me.com>
Message-ID: <54EB5CA8.7050506@redhat.com>

What's the best practice for choosing local?

* User-Agent header?
* From a login hint?  I think OIDC has something like this (but what 
about SAML)?
* Should we store this information somewhere (cookie, 
UserModel.attribute, etc..)


On 2/23/2015 11:53 AM, Michael Gerber wrote:
> Hi all,
>
> I started to work on the internationalization support
> (https://issues.jboss.org/browse/KEYCLOAK-301).
>
> I?ve already implemented the realm config in the admin console. I?ve put
> it into the ?Theme Setting? (see screenshot)
> I added the possibility to enable internationalization, add supported
> locales and a select a default locale.
>
> Now I?d like to implement the logic which choose the correct locale.
> Therefore I need the http header, cookie, query parameter, realm and user.
> The LoginFormsProvider and AccountProvider have all this information
> apart from the http header and the cookie.
> So I thought I could replace the UriInfo with the HttpRequest, but that
> doesn?t work, because I can not access the UriInfo through the
> HttpRequest (java.lang.NoSuchMethodError:
> org.jboss.resteasy.spi.HttpRequest.getUri()Ljavax/ws/rs/core/UriInfo;).
> So, I will add the HttpHeader to the LoginFormsProvider
> and AccountProvider, or does anyone have a better idea?
>
> @Bill
> How do you plan to store the claim ?locale? on a user? Will it be
> accessible through the UserModel interface?
>
> Best
> 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 ssilvert at redhat.com  Mon Feb 23 12:05:47 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 23 Feb 2015 12:05:47 -0500
Subject: [keycloak-dev] Simple mode?
In-Reply-To: <54EB551A.4010004@redhat.com>
References: <54EB551A.4010004@redhat.com>
Message-ID: <54EB5DEB.6000102@redhat.com>

So SSO would still work but not single log out?  That's probably fine 
for simple apps.

I think most apps would need some concept of roles.  But if you limited 
the roles to two hard-coded roles of "user" and "admin" then that would 
cover the requirements of a lot of simple applications.

On 2/23/2015 11:28 AM, Bill Burke wrote:
> Conversations with jboss.org guys got me thinking.  Should we have a
> "simple mode" for Keycloak where there is no concept of a client,
> application, or roles?  In this case,
>
> * applications don't need session mgmt or single log out
> * All applications are hosted under the same domain i.e  *.jboss.org
> (issues.jboss.org, forums.jboss.org, etc...)
> * applications just need to know if 1) the user is logged in, 2) the
> username/id
>
> So, "simple mode" would be:
>
> * No applications/client panel
> * No role pages anywhere
> * Realm would have a global javascript referable cookie that contained
> basic information (userid, username, full name).  The domain and path
> would be configurable from admin console
> * Realm would have a list of valid redirect URI patterns.
> * Realm would have a default redirect page for unsolicited logins.
>
>
>
>


From ssilvert at redhat.com  Mon Feb 23 12:14:57 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 23 Feb 2015 12:14:57 -0500
Subject: [keycloak-dev] Internationalization support (KEYCLOAK-301)
In-Reply-To: <54EB5CA8.7050506@redhat.com>
References: <D51883D0-3842-4376-B727-EF335EFAF2BC@me.com>
	<54EB5CA8.7050506@redhat.com>
Message-ID: <54EB6011.9080707@redhat.com>

On 2/23/2015 12:00 PM, Bill Burke wrote:
> What's the best practice for choosing local?
As I understand it, the thing to do is to use the accept-language header 
as a starting point.  If it's the only thing you have to go on then use it.

But I think we should definitely have a UserModel.attribute that is 
settable by the user.

Also, we have talked about building an "application switcher" component 
that developers can include in their apps.  That app switcher should 
include a dropdown to switch locale as well as one for switching the 
application.
>
> * User-Agent header?
> * From a login hint?  I think OIDC has something like this (but what
> about SAML)?
> * Should we store this information somewhere (cookie,
> UserModel.attribute, etc..)
>
>
> On 2/23/2015 11:53 AM, Michael Gerber wrote:
>> Hi all,
>>
>> I started to work on the internationalization support
>> (https://issues.jboss.org/browse/KEYCLOAK-301).
>>
>> I?ve already implemented the realm config in the admin console. I?ve put
>> it into the ?Theme Setting? (see screenshot)
>> I added the possibility to enable internationalization, add supported
>> locales and a select a default locale.
>>
>> Now I?d like to implement the logic which choose the correct locale.
>> Therefore I need the http header, cookie, query parameter, realm and user.
>> The LoginFormsProvider and AccountProvider have all this information
>> apart from the http header and the cookie.
>> So I thought I could replace the UriInfo with the HttpRequest, but that
>> doesn?t work, because I can not access the UriInfo through the
>> HttpRequest (java.lang.NoSuchMethodError:
>> org.jboss.resteasy.spi.HttpRequest.getUri()Ljavax/ws/rs/core/UriInfo;).
>> So, I will add the HttpHeader to the LoginFormsProvider
>> and AccountProvider, or does anyone have a better idea?
>>
>> @Bill
>> How do you plan to store the claim ?locale? on a user? Will it be
>> accessible through the UserModel interface?
>>
>> Best
>> Michael
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>


From ssilvert at redhat.com  Mon Feb 23 12:23:29 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 23 Feb 2015 12:23:29 -0500
Subject: [keycloak-dev] WildFly integration (READ ME!)
In-Reply-To: <54EB5E2D.2070508@redhat.com>
References: <969708031.6108771.1422954530044.JavaMail.zimbra@redhat.com>	<1360543918.10348397.1424334753943.JavaMail.zimbra@redhat.com>	<54E74D1C.4030600@redhat.com>
	<54E77464.2050400@redhat.com>	<54E77884.7050003@redhat.com>	<704793002.13480640.1424703042016.JavaMail.zimbra@redhat.com>	<54EB4A5B.6040201@redhat.com>
	<54EB50A8.6050702@redhat.com> <54EB5E2D.2070508@redhat.com>
Message-ID: <54EB6211.4070306@redhat.com>

On 2/23/2015 12:06 PM, Summers Pittman wrote:
> On 02/23/2015 11:09 AM, Stan Silvert wrote:
>> On 2/23/2015 10:42 AM, Summers Pittman wrote:
>>> On 02/23/2015 09:50 AM, Stian Thorgersen wrote:
>>>> Just to clarify we're only talking about the server, not adapters.
>>>>
>>>> For the best and most friction free experience it would be best to have a dedicated Keycloak server, not to co-locate it with your JEE apps by deploying a WAR. With that regards we are considering dropping support for deploying Keycloak as a WAR.
>>> If I'm reading you correctly instead of
>>>
>>>     ~/WILDFLY_HOME/bin/startup.sh
>>>     code
>>>
>>>
>>> it will be
>>>
>>>
>>>     $WILDFLY_HOME/bin/startup.sh
>>>     code
>>>     #^@%! what broke in my auth
>>>     waste 10 minutes
>>>     $KEYCLOAK_HOME/bin/startup.sh
>>>
>> I don't understand.  What would break?
> I start developing after a reboot and KeyCloak's server isn't 
> running.  The auth is broken because the server isn't running because 
> I forgot to start it.
>>>
>>> By keeping it a separate war 1) I can download the thing faster and 
>>> 2) I don't have to decide who to kick off of port 8080.
>> I don't think we would do anything to ban you from deploying your 
>> apps in the same WildFly instance as Keycloak.   Can you explain your 
>> concerns in more detail?
> My reading of the original email was that the standalone server would 
> be the only distribution.  IE there would be no more warfile distribution.
Right.  But it would be a distribution that has two modes.  The modes 
would be standalone mode and a mode that would allow it to join a 
WildFly domain.

You could still deploy your applications to the Keycloak distribution.  
But for production, that's probably not what you want.

What I don't understand is what problems it would cause.  Can you 
elaborate on that?
>>>
>>> Again, IF I'm reading your message correctly
>>>
>>>> That being said we still need to support embedding Keycloak in other projects. We plan to continue to support this through the mechanism UPS does, basically build-your-own auth-server.war.
>>>>
>>>> ----- Original Message -----
>>>>> From: "Summers Pittman"<supittma at redhat.com>
>>>>> To:keycloak-dev at lists.jboss.org
>>>>> Sent: Friday, February 20, 2015 7:10:12 PM
>>>>> Subject: Re: [keycloak-dev] WildFly integration (READ ME!)
>>>>>
>>>>> On 02/20/2015 12:52 PM, Stan Silvert wrote:
>>>>>> On 2/20/2015 10:05 AM, Summers Pittman wrote:
>>>>>>> On 02/19/2015 03:32 AM, Stian Thorgersen wrote:
>>>>>>>> No comments?!
>>>>>>> Peanut gallery chiming in; you asked for it ;)
>>>>>>>
>>>>>>> I am not a WildFly developer or administrator.  So read this email as
>>>>>>> the opinions of a talented developer who loves the hell out of using
>>>>>>> KeyCloak and WildFly and sings its praises from the roof tops but has no
>>>>>>> idea what you are talking about.
>>>>>> Thanks Summers.  Very valuable feedback.
>>>>> Thanks for taking the time to explain some things I know more than I did
>>>>> this morning.
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Stian Thorgersen"<stian at redhat.com>
>>>>>>>>> To: "keycloak dev"<keycloak-dev at lists.jboss.org>
>>>>>>>>> Sent: Tuesday, February 3, 2015 10:08:50 AM
>>>>>>>>> Subject: [keycloak-dev] WildFly integration (READ ME!)
>>>>>>>>>
>>>>>>>>> All,
>>>>>>>>>
>>>>>>>>> We have a few decisions to make in the not so far future. I'm away from
>>>>>>>>> Thursday, so let's have a hangout when I get back on the 17th February
>>>>>>>>> if
>>>>>>>>> that works for everyone.
>>>>>>>>>
>>>>>>>>> The list of things to discuss includes:
>>>>>>>>>
>>>>>>>>> * Drop keycloak-server.json - Should we drop our own configuration file
>>>>>>>>> and
>>>>>>>>> use DMR (standalone.xml)
>>>>>>> If on day one enabling KeyCloak in my project was any more complicated
>>>>>>> than dropping a pregenerated file into my WEB-INF directory I would have
>>>>>>> closed the project and never looked back.  -1
>>>>>> We're talking about the auth server's config rather than the config for
>>>>>> your project.   For projects, we want to make it even easier to the
>>>>>> point where you don't even need the json file to get a default
>>>>>> configuration.
>>>>> Ah, that makes more sense.
>>>>>>>>> * Keycloak CLI - Should we create our own or use WildFly CLI
>>>>>>> On the one hand the wildfly CLI is black magic.  On the other hand it is
>>>>>>> really well done black magic.  It is very hard to do CLIs well so I
>>>>>>> would like to see the wildfly CLI be used.
>>>>>> That's the general feedback we often get from the WildFly community.  I
>>>>>> agree.
>>>>>>>>> * Admin operations exposed over DMR - Should we expose none, some or all
>>>>>>>>> admin operations over DMR? If we expose all should we deprecate the
>>>>>>>>> current
>>>>>>>>> REST endpoints?
>>>>>>> Is DMR the thing that puts stuff in the WildFly admin UI (I tried to
>>>>>>> read the google result for "wildfly DMR" but it quickly turned into
>>>>>>> turtles all the way down)?
>>>>>> At its core, DMR is really just a tiny single-package library where the
>>>>>> API is just 3 or 4 classes.  Those classes are the "language" spoken to
>>>>>> make changes to the WildFly management model
>>>>>> (standalone.xml/domain.xml).  So the question is whether we should hook
>>>>>> into the management model infrastructure to make Keycloak changes.
>>>>>>> In my experience I don't LIKE using the WildFly admin UI, I would rather
>>>>>>> use the CLI, scripts, etc.
>>>>>> Also a typical response.  Again, I agree.  Thankfully, the Keycloak
>>>>>> admin UI doesn't suffer from the same deficiencies as the WildFly admin UI.
>>>>>>
>>>>>> But with Keycloak, we don't yet have a CLI, so there are lots of
>>>>>> questions around whether we piggyback on WildFly CLI, which means
>>>>>> adopting DMR in some way.
>>>>>>> I haven't used the KeyCloak REST endpoints
>>>>>>> and keeping them just increases the attack surface.
>>>>>> Do you mean that keeping the REST endpoints would be a good thing or a
>>>>>> bad thing?  Can we hear more from you on this topic?
>>>>> I think that if there were a WildFly way to do all of the admin tasks
>>>>> that the RESTful endpoints do now it would be good to remove the RESTful
>>>>> API to decrease the API surface to just WildFly.  IE fewer things to
>>>>> worry about getting hacked and to watch for for vulnerabilities.
>>>>>>>>> * Packaging/distribution - How do we distribute Keycloak? Options:
>>>>>>>>>       - Full WildFly
>>>>>>>>>       - Core/web WildFly
>>>>>>>>>       - Overlay/installer/feature-pack to install to existing WF and EAP
>>>>>>>>>       - WAR bundle
>>>>>>> How about a shell script that examines a WF install directory and does
>>>>>>> all the magic for me or aDocker container?
>>>>>>>
>>>>>>> In general I have not liked the experience of having wildfly bundled
>>>>>>> with a product.  It tends to mess with other servers I have installed
>>>>>>> and be a general PITA to maintain for anything more than the most
>>>>>>> trivial of demos.
>>>>>> Good feedback.
>>>>>>>>> * How should we deal with providers, themes and keycloak-server.json in
>>>>>>>>> domain-mode
>>>>>>>>>
>>>>>>>>> * MSC all the way - We can deploy directly through the Undertow
>>>>>>>>> sub-system
>>>>>>>>> instead of deploying a WAR from the sub-system
>>>>>>> What is MSC?
>>>>>> Modular Service Container.  It's the thing that lets you declare and
>>>>>> register services in WildFly.  But I'm not completely sure what Stian is
>>>>>> proposing here.
>>>>>>>>> * Split sub-systems - Should we split the sub-system in two? One for the
>>>>>>>>> auth-server and another for the adapter
>>>>>>> What are the trade offs?  What will using KeyCloak look like from my POV
>>>>>>> if we split?
>>>>>> Instead of
>>>>>>
>>>>>> subsystem=keycloak/auth-server=main-auth-server
>>>>>> subsystem=keycloak/secure-deployment=foo
>>>>>>
>>>>>> you would have
>>>>>>
>>>>>> subsystem=keycloak-server/auth-server=main-auth-server
>>>>>> subsystem=keycloak-deployments/secure-deployment=foo
>>>>>>
>>>>>> Another option would be to just leave it as it is today and just hide
>>>>>> the "auth-server" resource for installations where you don't expect the
>>>>>> auth server to run.
>>>>>>
>>>>>> The answer will probably be more a function of how we want to organize
>>>>>> the code rather than how it will look to the end user.
>>>>> As a end user it sounds like both work for me.
>>>>>>>>> * Deployable to other containers - Should it be possible to deploy
>>>>>>>>> Keycloak
>>>>>>>>> to Tomcat, Jetty, Fuse, etc..? One option could be to have reduced
>>>>>>>>> features
>>>>>>>>> in other containers (for example no client-cert)
>>>>>>> The awesomeness of WildFly has forever made web containers look
>>>>>>> insignificant to me.  If Glassfish still had a community edition worth a
>>>>>>> damn I would say target it as well.  I don't know how TomEE is but that
>>>>>>> may be good to support just for a "first one's free" to get people into
>>>>>>> WildFly land.
>>>>>>>
>>>>>>> I don't think Websphere or WebLogic support has ever gotten anyone
>>>>>>> excited about a project.  Honestly they are the technology equivalent of
>>>>>>> taking a cold shower with grandma.
>>>>>> I could have done without that image. :-|
>>>>>>
>>>>>> But thanks again!
>>>>> YW.
>>>>>>>>> Please add any other relevant topics.
>>>>>>>>>
>>>>>>>>> Next big discussion I want to have is about distribution of adapters,
>>>>>>>>> but
>>>>>>>>> let's do one at a time ;)
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>> --
>>>>> Summers Pittman
>>>>>>> Phone:404 941 4698
>>>>>>> Java is my crack.
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>> -- 
>>> Summers Pittman
>>> >>Phone:404 941 4698
>>> >>Java is my crack.
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
> -- 
> Summers Pittman
> >>Phone:404 941 4698
> >>Java is my crack.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150223/6fa9b9b6/attachment-0001.html 

From ssilvert at redhat.com  Mon Feb 23 12:26:36 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Mon, 23 Feb 2015 12:26:36 -0500
Subject: [keycloak-dev] WildFly integration (READ ME!)
In-Reply-To: <54EB6211.4070306@redhat.com>
References: <969708031.6108771.1422954530044.JavaMail.zimbra@redhat.com>	<1360543918.10348397.1424334753943.JavaMail.zimbra@redhat.com>	<54E74D1C.4030600@redhat.com>
	<54E77464.2050400@redhat.com>	<54E77884.7050003@redhat.com>	<704793002.13480640.1424703042016.JavaMail.zimbra@redhat.com>	<54EB4A5B.6040201@redhat.com>
	<54EB50A8.6050702@redhat.com> <54EB5E2D.2070508@redhat.com>
	<54EB6211.4070306@redhat.com>
Message-ID: <54EB62CC.1030305@redhat.com>

On 2/23/2015 12:23 PM, Stan Silvert wrote:
> On 2/23/2015 12:06 PM, Summers Pittman wrote:
>> On 02/23/2015 11:09 AM, Stan Silvert wrote:
>>> On 2/23/2015 10:42 AM, Summers Pittman wrote:
>>>> On 02/23/2015 09:50 AM, Stian Thorgersen wrote:
>>>>> Just to clarify we're only talking about the server, not adapters.
>>>>>
>>>>> For the best and most friction free experience it would be best to have a dedicated Keycloak server, not to co-locate it with your JEE apps by deploying a WAR. With that regards we are considering dropping support for deploying Keycloak as a WAR.
>>>> If I'm reading you correctly instead of
>>>>
>>>>     ~/WILDFLY_HOME/bin/startup.sh
>>>>     code
>>>>
>>>>
>>>> it will be
>>>>
>>>>
>>>>     $WILDFLY_HOME/bin/startup.sh
>>>>     code
>>>>     #^@%! what broke in my auth
>>>>     waste 10 minutes
>>>>     $KEYCLOAK_HOME/bin/startup.sh
>>>>
>>> I don't understand.  What would break?
>> I start developing after a reboot and KeyCloak's server isn't 
>> running.  The auth is broken because the server isn't running because 
>> I forgot to start it.
Sorry.  Missed this response.  My question to you is would having the 
ability to deploy your app on the Keycloak distribution be sufficient?
>>>>
>>>> By keeping it a separate war 1) I can download the thing faster and 
>>>> 2) I don't have to decide who to kick off of port 8080.
>>> I don't think we would do anything to ban you from deploying your 
>>> apps in the same WildFly instance as Keycloak.   Can you explain 
>>> your concerns in more detail?
>> My reading of the original email was that the standalone server would 
>> be the only distribution.  IE there would be no more warfile 
>> distribution.
> Right.  But it would be a distribution that has two modes.  The modes 
> would be standalone mode and a mode that would allow it to join a 
> WildFly domain.
>
> You could still deploy your applications to the Keycloak 
> distribution.  But for production, that's probably not what you want.
>
> What I don't understand is what problems it would cause.  Can you 
> elaborate on that?
>>>>
>>>> Again, IF I'm reading your message correctly
>>>>
>>>>> That being said we still need to support embedding Keycloak in other projects. We plan to continue to support this through the mechanism UPS does, basically build-your-own auth-server.war.
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Summers Pittman"<supittma at redhat.com>
>>>>>> To:keycloak-dev at lists.jboss.org
>>>>>> Sent: Friday, February 20, 2015 7:10:12 PM
>>>>>> Subject: Re: [keycloak-dev] WildFly integration (READ ME!)
>>>>>>
>>>>>> On 02/20/2015 12:52 PM, Stan Silvert wrote:
>>>>>>> On 2/20/2015 10:05 AM, Summers Pittman wrote:
>>>>>>>> On 02/19/2015 03:32 AM, Stian Thorgersen wrote:
>>>>>>>>> No comments?!
>>>>>>>> Peanut gallery chiming in; you asked for it ;)
>>>>>>>>
>>>>>>>> I am not a WildFly developer or administrator.  So read this email as
>>>>>>>> the opinions of a talented developer who loves the hell out of using
>>>>>>>> KeyCloak and WildFly and sings its praises from the roof tops but has no
>>>>>>>> idea what you are talking about.
>>>>>>> Thanks Summers.  Very valuable feedback.
>>>>>> Thanks for taking the time to explain some things I know more than I did
>>>>>> this morning.
>>>>>>>>> ----- Original Message -----
>>>>>>>>>> From: "Stian Thorgersen"<stian at redhat.com>
>>>>>>>>>> To: "keycloak dev"<keycloak-dev at lists.jboss.org>
>>>>>>>>>> Sent: Tuesday, February 3, 2015 10:08:50 AM
>>>>>>>>>> Subject: [keycloak-dev] WildFly integration (READ ME!)
>>>>>>>>>>
>>>>>>>>>> All,
>>>>>>>>>>
>>>>>>>>>> We have a few decisions to make in the not so far future. I'm away from
>>>>>>>>>> Thursday, so let's have a hangout when I get back on the 17th February
>>>>>>>>>> if
>>>>>>>>>> that works for everyone.
>>>>>>>>>>
>>>>>>>>>> The list of things to discuss includes:
>>>>>>>>>>
>>>>>>>>>> * Drop keycloak-server.json - Should we drop our own configuration file
>>>>>>>>>> and
>>>>>>>>>> use DMR (standalone.xml)
>>>>>>>> If on day one enabling KeyCloak in my project was any more complicated
>>>>>>>> than dropping a pregenerated file into my WEB-INF directory I would have
>>>>>>>> closed the project and never looked back.  -1
>>>>>>> We're talking about the auth server's config rather than the config for
>>>>>>> your project.   For projects, we want to make it even easier to the
>>>>>>> point where you don't even need the json file to get a default
>>>>>>> configuration.
>>>>>> Ah, that makes more sense.
>>>>>>>>>> * Keycloak CLI - Should we create our own or use WildFly CLI
>>>>>>>> On the one hand the wildfly CLI is black magic.  On the other hand it is
>>>>>>>> really well done black magic.  It is very hard to do CLIs well so I
>>>>>>>> would like to see the wildfly CLI be used.
>>>>>>> That's the general feedback we often get from the WildFly community.  I
>>>>>>> agree.
>>>>>>>>>> * Admin operations exposed over DMR - Should we expose none, some or all
>>>>>>>>>> admin operations over DMR? If we expose all should we deprecate the
>>>>>>>>>> current
>>>>>>>>>> REST endpoints?
>>>>>>>> Is DMR the thing that puts stuff in the WildFly admin UI (I tried to
>>>>>>>> read the google result for "wildfly DMR" but it quickly turned into
>>>>>>>> turtles all the way down)?
>>>>>>> At its core, DMR is really just a tiny single-package library where the
>>>>>>> API is just 3 or 4 classes.  Those classes are the "language" spoken to
>>>>>>> make changes to the WildFly management model
>>>>>>> (standalone.xml/domain.xml).  So the question is whether we should hook
>>>>>>> into the management model infrastructure to make Keycloak changes.
>>>>>>>> In my experience I don't LIKE using the WildFly admin UI, I would rather
>>>>>>>> use the CLI, scripts, etc.
>>>>>>> Also a typical response.  Again, I agree.  Thankfully, the Keycloak
>>>>>>> admin UI doesn't suffer from the same deficiencies as the WildFly admin UI.
>>>>>>>
>>>>>>> But with Keycloak, we don't yet have a CLI, so there are lots of
>>>>>>> questions around whether we piggyback on WildFly CLI, which means
>>>>>>> adopting DMR in some way.
>>>>>>>> I haven't used the KeyCloak REST endpoints
>>>>>>>> and keeping them just increases the attack surface.
>>>>>>> Do you mean that keeping the REST endpoints would be a good thing or a
>>>>>>> bad thing?  Can we hear more from you on this topic?
>>>>>> I think that if there were a WildFly way to do all of the admin tasks
>>>>>> that the RESTful endpoints do now it would be good to remove the RESTful
>>>>>> API to decrease the API surface to just WildFly.  IE fewer things to
>>>>>> worry about getting hacked and to watch for for vulnerabilities.
>>>>>>>>>> * Packaging/distribution - How do we distribute Keycloak? Options:
>>>>>>>>>>       - Full WildFly
>>>>>>>>>>       - Core/web WildFly
>>>>>>>>>>       - Overlay/installer/feature-pack to install to existing WF and EAP
>>>>>>>>>>       - WAR bundle
>>>>>>>> How about a shell script that examines a WF install directory and does
>>>>>>>> all the magic for me or aDocker container?
>>>>>>>>
>>>>>>>> In general I have not liked the experience of having wildfly bundled
>>>>>>>> with a product.  It tends to mess with other servers I have installed
>>>>>>>> and be a general PITA to maintain for anything more than the most
>>>>>>>> trivial of demos.
>>>>>>> Good feedback.
>>>>>>>>>> * How should we deal with providers, themes and keycloak-server.json in
>>>>>>>>>> domain-mode
>>>>>>>>>>
>>>>>>>>>> * MSC all the way - We can deploy directly through the Undertow
>>>>>>>>>> sub-system
>>>>>>>>>> instead of deploying a WAR from the sub-system
>>>>>>>> What is MSC?
>>>>>>> Modular Service Container.  It's the thing that lets you declare and
>>>>>>> register services in WildFly.  But I'm not completely sure what Stian is
>>>>>>> proposing here.
>>>>>>>>>> * Split sub-systems - Should we split the sub-system in two? One for the
>>>>>>>>>> auth-server and another for the adapter
>>>>>>>> What are the trade offs?  What will using KeyCloak look like from my POV
>>>>>>>> if we split?
>>>>>>> Instead of
>>>>>>>
>>>>>>> subsystem=keycloak/auth-server=main-auth-server
>>>>>>> subsystem=keycloak/secure-deployment=foo
>>>>>>>
>>>>>>> you would have
>>>>>>>
>>>>>>> subsystem=keycloak-server/auth-server=main-auth-server
>>>>>>> subsystem=keycloak-deployments/secure-deployment=foo
>>>>>>>
>>>>>>> Another option would be to just leave it as it is today and just hide
>>>>>>> the "auth-server" resource for installations where you don't expect the
>>>>>>> auth server to run.
>>>>>>>
>>>>>>> The answer will probably be more a function of how we want to organize
>>>>>>> the code rather than how it will look to the end user.
>>>>>> As a end user it sounds like both work for me.
>>>>>>>>>> * Deployable to other containers - Should it be possible to deploy
>>>>>>>>>> Keycloak
>>>>>>>>>> to Tomcat, Jetty, Fuse, etc..? One option could be to have reduced
>>>>>>>>>> features
>>>>>>>>>> in other containers (for example no client-cert)
>>>>>>>> The awesomeness of WildFly has forever made web containers look
>>>>>>>> insignificant to me.  If Glassfish still had a community edition worth a
>>>>>>>> damn I would say target it as well.  I don't know how TomEE is but that
>>>>>>>> may be good to support just for a "first one's free" to get people into
>>>>>>>> WildFly land.
>>>>>>>>
>>>>>>>> I don't think Websphere or WebLogic support has ever gotten anyone
>>>>>>>> excited about a project.  Honestly they are the technology equivalent of
>>>>>>>> taking a cold shower with grandma.
>>>>>>> I could have done without that image. :-|
>>>>>>>
>>>>>>> But thanks again!
>>>>>> YW.
>>>>>>>>>> Please add any other relevant topics.
>>>>>>>>>>
>>>>>>>>>> Next big discussion I want to have is about distribution of adapters,
>>>>>>>>>> but
>>>>>>>>>> let's do one at a time ;)
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>>>>> --
>>>>>> Summers Pittman
>>>>>>>> Phone:404 941 4698
>>>>>>>> Java is my crack.
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>> -- 
>>>> Summers Pittman
>>>> >>Phone:404 941 4698
>>>> >>Java is my crack.
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>> -- 
>> Summers Pittman
>> >>Phone:404 941 4698
>> >>Java is my crack.
>
>
>
> _______________________________________________
> 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/20150223/dbec4d8b/attachment-0001.html 

From gerbermichi at me.com  Mon Feb 23 12:40:35 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Mon, 23 Feb 2015 18:40:35 +0100
Subject: [keycloak-dev] Internationalization support (KEYCLOAK-301)
In-Reply-To: <54EB6011.9080707@redhat.com>
References: <D51883D0-3842-4376-B727-EF335EFAF2BC@me.com>
	<54EB5CA8.7050506@redhat.com> <54EB6011.9080707@redhat.com>
Message-ID: <F56B9E04-A0C4-4368-A117-F7E93CA01182@me.com>

The algorithm to determine the correct locale is like that:
1. Locale cookie
2. User profile (UserModel.attribute)
3. ui_locales query parameter
4. Accept-Language http header
5. Default realm locale

The login page has also a dropdown with all available locales. The selected value will be stored in the locale cookie.
> Am 23.02.2015 um 18:14 schrieb Stan Silvert <ssilvert at redhat.com>:
> 
> On 2/23/2015 12:00 PM, Bill Burke wrote:
>> What's the best practice for choosing local?
> As I understand it, the thing to do is to use the accept-language header 
> as a starting point.  If it's the only thing you have to go on then use it.
> 
> But I think we should definitely have a UserModel.attribute that is 
> settable by the user.
> 
> Also, we have talked about building an "application switcher" component 
> that developers can include in their apps.  That app switcher should 
> include a dropdown to switch locale as well as one for switching the 
> application.
>> 
>> * User-Agent header?
>> * From a login hint?  I think OIDC has something like this (but what
>> about SAML)?
>> * Should we store this information somewhere (cookie,
>> UserModel.attribute, etc..)
>> 
>> 
>> On 2/23/2015 11:53 AM, Michael Gerber wrote:
>>> Hi all,
>>> 
>>> I started to work on the internationalization support
>>> (https://issues.jboss.org/browse/KEYCLOAK-301).
>>> 
>>> I?ve already implemented the realm config in the admin console. I?ve put
>>> it into the ?Theme Setting? (see screenshot)
>>> I added the possibility to enable internationalization, add supported
>>> locales and a select a default locale.
>>> 
>>> Now I?d like to implement the logic which choose the correct locale.
>>> Therefore I need the http header, cookie, query parameter, realm and user.
>>> The LoginFormsProvider and AccountProvider have all this information
>>> apart from the http header and the cookie.
>>> So I thought I could replace the UriInfo with the HttpRequest, but that
>>> doesn?t work, because I can not access the UriInfo through the
>>> HttpRequest (java.lang.NoSuchMethodError:
>>> org.jboss.resteasy.spi.HttpRequest.getUri()Ljavax/ws/rs/core/UriInfo;).
>>> So, I will add the HttpHeader to the LoginFormsProvider
>>> and AccountProvider, or does anyone have a better idea?
>>> 
>>> @Bill
>>> How do you plan to store the claim ?locale? on a user? Will it be
>>> accessible through the UserModel interface?
>>> 
>>> Best
>>> 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



From mposolda at redhat.com  Mon Feb 23 12:48:00 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 23 Feb 2015 18:48:00 +0100
Subject: [keycloak-dev] Internationalization support (KEYCLOAK-301)
In-Reply-To: <F56B9E04-A0C4-4368-A117-F7E93CA01182@me.com>
References: <D51883D0-3842-4376-B727-EF335EFAF2BC@me.com>	<54EB5CA8.7050506@redhat.com>
	<54EB6011.9080707@redhat.com>
	<F56B9E04-A0C4-4368-A117-F7E93CA01182@me.com>
Message-ID: <54EB67D0.8010404@redhat.com>

Will the order be configurable? For example admin may want to configure 
realm locale (5) and wants users to use this one instead of 
Accept-Language header (4) ?

Marek

On 23.2.2015 18:40, Michael Gerber wrote:
> The algorithm to determine the correct locale is like that:
> 1. Locale cookie
> 2. User profile (UserModel.attribute)
> 3. ui_locales query parameter
> 4. Accept-Language http header
> 5. Default realm locale
>
> The login page has also a dropdown with all available locales. The selected value will be stored in the locale cookie.
>> Am 23.02.2015 um 18:14 schrieb Stan Silvert <ssilvert at redhat.com>:
>>
>> On 2/23/2015 12:00 PM, Bill Burke wrote:
>>> What's the best practice for choosing local?
>> As I understand it, the thing to do is to use the accept-language header
>> as a starting point.  If it's the only thing you have to go on then use it.
>>
>> But I think we should definitely have a UserModel.attribute that is
>> settable by the user.
>>
>> Also, we have talked about building an "application switcher" component
>> that developers can include in their apps.  That app switcher should
>> include a dropdown to switch locale as well as one for switching the
>> application.
>>> * User-Agent header?
>>> * From a login hint?  I think OIDC has something like this (but what
>>> about SAML)?
>>> * Should we store this information somewhere (cookie,
>>> UserModel.attribute, etc..)
>>>
>>>
>>> On 2/23/2015 11:53 AM, Michael Gerber wrote:
>>>> Hi all,
>>>>
>>>> I started to work on the internationalization support
>>>> (https://issues.jboss.org/browse/KEYCLOAK-301).
>>>>
>>>> I?ve already implemented the realm config in the admin console. I?ve put
>>>> it into the ?Theme Setting? (see screenshot)
>>>> I added the possibility to enable internationalization, add supported
>>>> locales and a select a default locale.
>>>>
>>>> Now I?d like to implement the logic which choose the correct locale.
>>>> Therefore I need the http header, cookie, query parameter, realm and user.
>>>> The LoginFormsProvider and AccountProvider have all this information
>>>> apart from the http header and the cookie.
>>>> So I thought I could replace the UriInfo with the HttpRequest, but that
>>>> doesn?t work, because I can not access the UriInfo through the
>>>> HttpRequest (java.lang.NoSuchMethodError:
>>>> org.jboss.resteasy.spi.HttpRequest.getUri()Ljavax/ws/rs/core/UriInfo;).
>>>> So, I will add the HttpHeader to the LoginFormsProvider
>>>> and AccountProvider, or does anyone have a better idea?
>>>>
>>>> @Bill
>>>> How do you plan to store the claim ?locale? on a user? Will it be
>>>> accessible through the UserModel interface?
>>>>
>>>> Best
>>>> 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
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From bburke at redhat.com  Mon Feb 23 13:04:32 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 23 Feb 2015 13:04:32 -0500
Subject: [keycloak-dev] How to do default claim mappings?
In-Reply-To: <204784861.12997302.1424678852848.JavaMail.zimbra@redhat.com>
References: <54E7571B.6080007@redhat.com>
	<204784861.12997302.1424678852848.JavaMail.zimbra@redhat.com>
Message-ID: <54EB6BB0.6010509@redhat.com>



On 2/23/2015 3:07 AM, Stian Thorgersen wrote:
> What about adding a general purpose event listener framework for providers? We can add
>
> * ProviderEventListener ProviderFactory.getProviderEventListener()
>
> The bootstrapping process would after calling init on all ProviderFactory, call getProviderEventListener. If it returns null it won't register it, but otherwise it'll add it to the list of listeners.
>
> ProviderEventListener would have the following method:
>
> * void onEvent(ProviderEvent event)
>

Ok, general purpose provider event listeners added.  Also 
ProviderFactory.preprocess() is named postInit().


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bruno at abstractj.org  Mon Feb 23 15:49:27 2015
From: bruno at abstractj.org (Bruno Oliveira)
Date: Mon, 23 Feb 2015 17:49:27 -0300
Subject: [keycloak-dev] Alternatives to sourceforge
Message-ID: <20150223204927.GA9369@abstractj.org>

Good morning guys, I know is pretty much possible to build/run KC with
no need to download to sourceforge. But today, do we have any
alternative to download KC when sourceforge is down? [1]

Not the end of the world, but would be nice to have a backup site.

[1] - http://photon.abstractj.org/Page_not_found_-_SourceForge.net_2015-02-23_17-47-40.jpg

--

abstractj
PGP: 0x84DC9914

From bburke at redhat.com  Mon Feb 23 19:26:07 2015
From: bburke at redhat.com (Bill Burke)
Date: Mon, 23 Feb 2015 19:26:07 -0500
Subject: [keycloak-dev] Alternatives to sourceforge
In-Reply-To: <20150223204927.GA9369@abstractj.org>
References: <20150223204927.GA9369@abstractj.org>
Message-ID: <54EBC51F.5090902@redhat.com>

Usually sf.net is more reliable than anything RHT hosts.

On 2/23/2015 3:49 PM, Bruno Oliveira wrote:
> Good morning guys, I know is pretty much possible to build/run KC with
> no need to download to sourceforge. But today, do we have any
> alternative to download KC when sourceforge is down? [1]
>
> Not the end of the world, but would be nice to have a backup site.
>
> [1] - http://photon.abstractj.org/Page_not_found_-_SourceForge.net_2015-02-23_17-47-40.jpg
>
> --
>
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> 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 Feb 24 01:23:48 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 24 Feb 2015 01:23:48 -0500 (EST)
Subject: [keycloak-dev] Simple mode?
In-Reply-To: <54EB551A.4010004@redhat.com>
References: <54EB551A.4010004@redhat.com>
Message-ID: <866459802.13978034.1424759028211.JavaMail.zimbra@redhat.com>

-1000

I can't see how this would help jboss.org guys? They have most complex deployment out there.

As fair as other JBoss projects go and allowing them to embed Keycloak into their projects, this is along the lines of what I proposed. Although this is proposing to change the behaviour of Keycloak not just remove features.

For other users I don't see the use-case. We should instead focus on making sure Keycloak has the required features and is easy to use.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, February 23, 2015 5:28:10 PM
> Subject: [keycloak-dev] Simple mode?
> 
> Conversations with jboss.org guys got me thinking.  Should we have a
> "simple mode" for Keycloak where there is no concept of a client,
> application, or roles?  In this case,
> 
> * applications don't need session mgmt or single log out
> * All applications are hosted under the same domain i.e  *.jboss.org
> (issues.jboss.org, forums.jboss.org, etc...)
> * applications just need to know if 1) the user is logged in, 2) the
> username/id
> 
> So, "simple mode" would be:
> 
> * No applications/client panel
> * No role pages anywhere
> * Realm would have a global javascript referable cookie that contained
> basic information (userid, username, full name).  The domain and path
> would be configurable from admin console
> * Realm would have a list of valid redirect URI patterns.
> * Realm would have a default redirect page for unsolicited logins.
> 
> 
> 
> 
> --
> 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 Feb 24 01:26:49 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 24 Feb 2015 01:26:49 -0500 (EST)
Subject: [keycloak-dev] Internationalization support (KEYCLOAK-301)
In-Reply-To: <54EB67D0.8010404@redhat.com>
References: <D51883D0-3842-4376-B727-EF335EFAF2BC@me.com>
	<54EB5CA8.7050506@redhat.com> <54EB6011.9080707@redhat.com>
	<F56B9E04-A0C4-4368-A117-F7E93CA01182@me.com>
	<54EB67D0.8010404@redhat.com>
Message-ID: <1535309517.13979063.1424759209658.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Michael Gerber" <gerbermichi at me.com>, "Stan Silvert" <ssilvert at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, February 23, 2015 6:48:00 PM
> Subject: Re: [keycloak-dev] Internationalization support (KEYCLOAK-301)
> 
> Will the order be configurable? For example admin may want to configure
> realm locale (5) and wants users to use this one instead of
> Accept-Language header (4) ?

Is that really required?

> 
> Marek
> 
> On 23.2.2015 18:40, Michael Gerber wrote:
> > The algorithm to determine the correct locale is like that:
> > 1. Locale cookie
> > 2. User profile (UserModel.attribute)
> > 3. ui_locales query parameter
> > 4. Accept-Language http header
> > 5. Default realm locale
> >
> > The login page has also a dropdown with all available locales. The selected
> > value will be stored in the locale cookie.
> >> Am 23.02.2015 um 18:14 schrieb Stan Silvert <ssilvert at redhat.com>:
> >>
> >> On 2/23/2015 12:00 PM, Bill Burke wrote:
> >>> What's the best practice for choosing local?
> >> As I understand it, the thing to do is to use the accept-language header
> >> as a starting point.  If it's the only thing you have to go on then use
> >> it.
> >>
> >> But I think we should definitely have a UserModel.attribute that is
> >> settable by the user.
> >>
> >> Also, we have talked about building an "application switcher" component
> >> that developers can include in their apps.  That app switcher should
> >> include a dropdown to switch locale as well as one for switching the
> >> application.
> >>> * User-Agent header?
> >>> * From a login hint?  I think OIDC has something like this (but what
> >>> about SAML)?
> >>> * Should we store this information somewhere (cookie,
> >>> UserModel.attribute, etc..)
> >>>
> >>>
> >>> On 2/23/2015 11:53 AM, Michael Gerber wrote:
> >>>> Hi all,
> >>>>
> >>>> I started to work on the internationalization support
> >>>> (https://issues.jboss.org/browse/KEYCLOAK-301).
> >>>>
> >>>> I?ve already implemented the realm config in the admin console. I?ve put
> >>>> it into the ?Theme Setting? (see screenshot)
> >>>> I added the possibility to enable internationalization, add supported
> >>>> locales and a select a default locale.
> >>>>
> >>>> Now I?d like to implement the logic which choose the correct locale.
> >>>> Therefore I need the http header, cookie, query parameter, realm and
> >>>> user.
> >>>> The LoginFormsProvider and AccountProvider have all this information
> >>>> apart from the http header and the cookie.
> >>>> So I thought I could replace the UriInfo with the HttpRequest, but that
> >>>> doesn?t work, because I can not access the UriInfo through the
> >>>> HttpRequest (java.lang.NoSuchMethodError:
> >>>> org.jboss.resteasy.spi.HttpRequest.getUri()Ljavax/ws/rs/core/UriInfo;).
> >>>> So, I will add the HttpHeader to the LoginFormsProvider
> >>>> and AccountProvider, or does anyone have a better idea?
> >>>>
> >>>> @Bill
> >>>> How do you plan to store the claim ?locale? on a user? Will it be
> >>>> accessible through the UserModel interface?
> >>>>
> >>>> Best
> >>>> 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
> >
> > _______________________________________________
> > 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 Feb 24 01:28:29 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 24 Feb 2015 01:28:29 -0500 (EST)
Subject: [keycloak-dev] Alternatives to sourceforge
In-Reply-To: <20150223204927.GA9369@abstractj.org>
References: <20150223204927.GA9369@abstractj.org>
Message-ID: <172308977.13979303.1424759309566.JavaMail.zimbra@redhat.com>

It's in Maven Central as well:

http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22keycloak-appliance-dist-all%22

Personally, I've never seen sourceforge unavailable, but I have seen jboss.org slow and unavailable frequently.

----- Original Message -----
> From: "Bruno Oliveira" <bruno at abstractj.org>
> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> Sent: Monday, February 23, 2015 9:49:27 PM
> Subject: [keycloak-dev] Alternatives to sourceforge
> 
> Good morning guys, I know is pretty much possible to build/run KC with
> no need to download to sourceforge. But today, do we have any
> alternative to download KC when sourceforge is down? [1]
> 
> Not the end of the world, but would be nice to have a backup site.
> 
> [1] -
> http://photon.abstractj.org/Page_not_found_-_SourceForge.net_2015-02-23_17-47-40.jpg
> 
> --
> 
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From gerbermichi at me.com  Tue Feb 24 01:37:10 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Tue, 24 Feb 2015 06:37:10 +0000 (GMT)
Subject: [keycloak-dev] =?utf-8?q?_Re=3A__Internationalization_support_=28?=
 =?utf-8?q?KEYCLOAK-301=29?=
Message-ID: <6eb5b50f-5058-4ef3-8fe5-96bf625107a2@me.com>



Am 24. Februar 2015 um 07:26 schrieb Stian Thorgersen <stian at redhat.com>:



----- Original Message -----
From: "Marek Posolda" <mposolda at redhat.com>
To: "Michael Gerber" <gerbermichi at me.com>, "Stan Silvert" <ssilvert at redhat.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Monday, February 23, 2015 6:48:00 PM
Subject: Re: [keycloak-dev] Internationalization support (KEYCLOAK-301)
Will the order be configurable? For example admin may want to configure
realm locale (5) and wants users to use this one instead of
Accept-Language header (4) ?

Is that really required?
?
A configurable order doesn't make sense for me, because you shouldn't change step 1, 2, 3 and 5.?
The only possible solution would be to make step 4 (Accept-Language) optional. So, the admin can disable it in the admin console.


Marek
On 23.2.2015 18:40, Michael Gerber wrote:
> The algorithm to determine the correct locale is like that:
> 1. Locale cookie
> 2. User profile (UserModel.attribute)
> 3. ui_locales query parameter
> 4. Accept-Language http header
> 5. Default realm locale
>
> The login page has also a dropdown with all available locales. The selected
> value will be stored in the locale cookie.
>> Am 23.02.2015 um 18:14 schrieb Stan Silvert <ssilvert at redhat.com>:
>>
>> On 2/23/2015 12:00 PM, Bill Burke wrote:
>>> What's the best practice for choosing local?
>> As I understand it, the thing to do is to use the accept-language header
>> as a starting point. If it's the only thing you have to go on then use
>> it.
>>
>> But I think we should definitely have a UserModel.attribute that is
>> settable by the user.
>>
>> Also, we have talked about building an "application switcher" component
>> that developers can include in their apps. That app switcher should
>> include a dropdown to switch locale as well as one for switching the
>> application.
>>> * User-Agent header?
>>> * From a login hint? I think OIDC has something like this (but what
>>> about SAML)?
>>> * Should we store this information somewhere (cookie,
>>> UserModel.attribute, etc..)
>>>
>>>
>>> On 2/23/2015 11:53 AM, Michael Gerber wrote:
>>>> Hi all,
>>>>
>>>> I started to work on the internationalization support
>>>> (https://issues.jboss.org/browse/KEYCLOAK-301).
>>>>
>>>> I?ve already implemented the realm config in the admin console. I?ve put
>>>> it into the ?Theme Setting? (see screenshot)
>>>> I added the possibility to enable internationalization, add supported
>>>> locales and a select a default locale.
>>>>
>>>> Now I?d like to implement the logic which choose the correct locale.
>>>> Therefore I need the http header, cookie, query parameter, realm and
>>>> user.
>>>> The LoginFormsProvider and AccountProvider have all this information
>>>> apart from the http header and the cookie.
>>>> So I thought I could replace the UriInfo with the HttpRequest, but that
>>>> doesn?t work, because I can not access the UriInfo through the
>>>> HttpRequest (java.lang.NoSuchMethodError:
>>>> org.jboss.resteasy.spi.HttpRequest.getUri()Ljavax/ws/rs/core/UriInfo;).
>>>> So, I will add the HttpHeader to the LoginFormsProvider
>>>> and AccountProvider, or does anyone have a better idea?
>>>>
>>>> @Bill
>>>> How do you plan to store the claim ?locale? on a user? Will it be
>>>> accessible through the UserModel interface?
>>>>
>>>> Best
>>>> 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
>
> _______________________________________________
> 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/20150224/f2ed0421/attachment.html 

From stian at redhat.com  Tue Feb 24 01:40:10 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 24 Feb 2015 01:40:10 -0500 (EST)
Subject: [keycloak-dev] Internationalization support (KEYCLOAK-301)
In-Reply-To: <6eb5b50f-5058-4ef3-8fe5-96bf625107a2@me.com>
References: <6eb5b50f-5058-4ef3-8fe5-96bf625107a2@me.com>
Message-ID: <1484794383.13984421.1424760010354.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Marek Posolda" <mposolda at redhat.com>, "Stan Silvert" <ssilvert at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Tuesday, February 24, 2015 7:37:10 AM
> Subject: Re: [keycloak-dev] Internationalization support (KEYCLOAK-301)
> 
> 
> 
> Am 24. Februar 2015 um 07:26 schrieb Stian Thorgersen <stian at redhat.com>:
> 
> 
> 
> ----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Michael Gerber" <gerbermichi at me.com>, "Stan Silvert"
> <ssilvert at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, February 23, 2015 6:48:00 PM
> Subject: Re: [keycloak-dev] Internationalization support (KEYCLOAK-301)
> Will the order be configurable? For example admin may want to configure
> realm locale (5) and wants users to use this one instead of
> Accept-Language header (4) ?
> 
> Is that really required?
> ?
> A configurable order doesn't make sense for me, because you shouldn't change
> step 1, 2, 3 and 5.
> The only possible solution would be to make step 4 (Accept-Language)
> optional. So, the admin can disable it in the admin console.

Yes, that was what I was thinking, swapping 4 and 5 is the same as disabling Accept-Language. I can't see why anyone would want to do that though.

> 
> 
> Marek
> On 23.2.2015 18:40, Michael Gerber wrote:
> > The algorithm to determine the correct locale is like that:
> > 1. Locale cookie
> > 2. User profile (UserModel.attribute)
> > 3. ui_locales query parameter
> > 4. Accept-Language http header
> > 5. Default realm locale
> >
> > The login page has also a dropdown with all available locales. The selected
> > value will be stored in the locale cookie.
> >> Am 23.02.2015 um 18:14 schrieb Stan Silvert <ssilvert at redhat.com>:
> >>
> >> On 2/23/2015 12:00 PM, Bill Burke wrote:
> >>> What's the best practice for choosing local?
> >> As I understand it, the thing to do is to use the accept-language header
> >> as a starting point. If it's the only thing you have to go on then use
> >> it.
> >>
> >> But I think we should definitely have a UserModel.attribute that is
> >> settable by the user.
> >>
> >> Also, we have talked about building an "application switcher" component
> >> that developers can include in their apps. That app switcher should
> >> include a dropdown to switch locale as well as one for switching the
> >> application.
> >>> * User-Agent header?
> >>> * From a login hint? I think OIDC has something like this (but what
> >>> about SAML)?
> >>> * Should we store this information somewhere (cookie,
> >>> UserModel.attribute, etc..)
> >>>
> >>>
> >>> On 2/23/2015 11:53 AM, Michael Gerber wrote:
> >>>> Hi all,
> >>>>
> >>>> I started to work on the internationalization support
> >>>> (https://issues.jboss.org/browse/KEYCLOAK-301).
> >>>>
> >>>> I?ve already implemented the realm config in the admin console. I?ve put
> >>>> it into the ?Theme Setting? (see screenshot)
> >>>> I added the possibility to enable internationalization, add supported
> >>>> locales and a select a default locale.
> >>>>
> >>>> Now I?d like to implement the logic which choose the correct locale.
> >>>> Therefore I need the http header, cookie, query parameter, realm and
> >>>> user.
> >>>> The LoginFormsProvider and AccountProvider have all this information
> >>>> apart from the http header and the cookie.
> >>>> So I thought I could replace the UriInfo with the HttpRequest, but that
> >>>> doesn?t work, because I can not access the UriInfo through the
> >>>> HttpRequest (java.lang.NoSuchMethodError:
> >>>> org.jboss.resteasy.spi.HttpRequest.getUri()Ljavax/ws/rs/core/UriInfo;).
> >>>> So, I will add the HttpHeader to the LoginFormsProvider
> >>>> and AccountProvider, or does anyone have a better idea?
> >>>>
> >>>> @Bill
> >>>> How do you plan to store the claim ?locale? on a user? Will it be
> >>>> accessible through the UserModel interface?
> >>>>
> >>>> Best
> >>>> 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
> >
> > _______________________________________________
> > 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  Tue Feb 24 03:47:17 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 24 Feb 2015 09:47:17 +0100
Subject: [keycloak-dev] Internationalization support (KEYCLOAK-301)
In-Reply-To: <1484794383.13984421.1424760010354.JavaMail.zimbra@redhat.com>
References: <6eb5b50f-5058-4ef3-8fe5-96bf625107a2@me.com>
	<1484794383.13984421.1424760010354.JavaMail.zimbra@redhat.com>
Message-ID: <54EC3A95.3000006@redhat.com>

On 24.2.2015 07:40, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Michael Gerber" <gerbermichi at me.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: "Marek Posolda" <mposolda at redhat.com>, "Stan Silvert" <ssilvert at redhat.com>, keycloak-dev at lists.jboss.org
>> Sent: Tuesday, February 24, 2015 7:37:10 AM
>> Subject: Re: [keycloak-dev] Internationalization support (KEYCLOAK-301)
>>
>>
>>
>> Am 24. Februar 2015 um 07:26 schrieb Stian Thorgersen <stian at redhat.com>:
>>
>>
>>
>> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Michael Gerber" <gerbermichi at me.com>, "Stan Silvert"
>> <ssilvert at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Monday, February 23, 2015 6:48:00 PM
>> Subject: Re: [keycloak-dev] Internationalization support (KEYCLOAK-301)
>> Will the order be configurable? For example admin may want to configure
>> realm locale (5) and wants users to use this one instead of
>> Accept-Language header (4) ?
>>
>> Is that really required?
>>   
>> A configurable order doesn't make sense for me, because you shouldn't change
>> step 1, 2, 3 and 5.
>> The only possible solution would be to make step 4 (Accept-Language)
>> optional. So, the admin can disable it in the admin console.
> Yes, that was what I was thinking, swapping 4 and 5 is the same as disabling Accept-Language. I can't see why anyone would want to do that though.
Maybe just because he wants to enforce showing login page in "tested" 
language like English ? Accept-Language can contain anything in it, so 
it may contain language, which is "partially" supported by Keycloak (not 
all labels and messages properly translated) and it may lead to the 
unproper login page with some labels in english and some in the second 
language, which may not look good.

But I don't know, maybe the use-case is really just theoretic. I agree 
that other changes in order instead of removing Accept-Language are 
likely not needed.

Marek
>
>>
>> Marek
>> On 23.2.2015 18:40, Michael Gerber wrote:
>>> The algorithm to determine the correct locale is like that:
>>> 1. Locale cookie
>>> 2. User profile (UserModel.attribute)
>>> 3. ui_locales query parameter
>>> 4. Accept-Language http header
>>> 5. Default realm locale
>>>
>>> The login page has also a dropdown with all available locales. The selected
>>> value will be stored in the locale cookie.
>>>> Am 23.02.2015 um 18:14 schrieb Stan Silvert <ssilvert at redhat.com>:
>>>>
>>>> On 2/23/2015 12:00 PM, Bill Burke wrote:
>>>>> What's the best practice for choosing local?
>>>> As I understand it, the thing to do is to use the accept-language header
>>>> as a starting point. If it's the only thing you have to go on then use
>>>> it.
>>>>
>>>> But I think we should definitely have a UserModel.attribute that is
>>>> settable by the user.
>>>>
>>>> Also, we have talked about building an "application switcher" component
>>>> that developers can include in their apps. That app switcher should
>>>> include a dropdown to switch locale as well as one for switching the
>>>> application.
>>>>> * User-Agent header?
>>>>> * From a login hint? I think OIDC has something like this (but what
>>>>> about SAML)?
>>>>> * Should we store this information somewhere (cookie,
>>>>> UserModel.attribute, etc..)
>>>>>
>>>>>
>>>>> On 2/23/2015 11:53 AM, Michael Gerber wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> I started to work on the internationalization support
>>>>>> (https://issues.jboss.org/browse/KEYCLOAK-301).
>>>>>>
>>>>>> I?ve already implemented the realm config in the admin console. I?ve put
>>>>>> it into the ?Theme Setting? (see screenshot)
>>>>>> I added the possibility to enable internationalization, add supported
>>>>>> locales and a select a default locale.
>>>>>>
>>>>>> Now I?d like to implement the logic which choose the correct locale.
>>>>>> Therefore I need the http header, cookie, query parameter, realm and
>>>>>> user.
>>>>>> The LoginFormsProvider and AccountProvider have all this information
>>>>>> apart from the http header and the cookie.
>>>>>> So I thought I could replace the UriInfo with the HttpRequest, but that
>>>>>> doesn?t work, because I can not access the UriInfo through the
>>>>>> HttpRequest (java.lang.NoSuchMethodError:
>>>>>> org.jboss.resteasy.spi.HttpRequest.getUri()Ljavax/ws/rs/core/UriInfo;).
>>>>>> So, I will add the HttpHeader to the LoginFormsProvider
>>>>>> and AccountProvider, or does anyone have a better idea?
>>>>>>
>>>>>> @Bill
>>>>>> How do you plan to store the claim ?locale? on a user? Will it be
>>>>>> accessible through the UserModel interface?
>>>>>>
>>>>>> Best
>>>>>> 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
>>> _______________________________________________
>>> 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 gerbermichi at me.com  Tue Feb 24 04:03:25 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Tue, 24 Feb 2015 09:03:25 +0000 (GMT)
Subject: [keycloak-dev] =?utf-8?q?_Re=3A__Internationalization_support_=28?=
 =?utf-8?q?KEYCLOAK-301=29?=
Message-ID: <eeacec6a-d534-40ca-8c54-86a9a09be93b@me.com>



Am 24. Februar 2015 um 09:47 schrieb Marek Posolda <mposolda at redhat.com>:

On 24.2.2015 07:40, Stian Thorgersen wrote:
----- Original Message -----
From: "Michael Gerber" <gerbermichi at me.com>
To: "Stian Thorgersen" <stian at redhat.com>
Cc: "Marek Posolda" <mposolda at redhat.com>, "Stan Silvert" <ssilvert at redhat.com>, keycloak-dev at lists.jboss.org
Sent: Tuesday, February 24, 2015 7:37:10 AM
Subject: Re: [keycloak-dev] Internationalization support (KEYCLOAK-301)
Am 24. Februar 2015 um 07:26 schrieb Stian Thorgersen <stian at redhat.com>:
----- Original Message -----
From: "Marek Posolda" <mposolda at redhat.com>
To: "Michael Gerber" <gerbermichi at me.com>, "Stan Silvert"
<ssilvert at redhat.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Monday, February 23, 2015 6:48:00 PM
Subject: Re: [keycloak-dev] Internationalization support (KEYCLOAK-301)
Will the order be configurable? For example admin may want to configure
realm locale (5) and wants users to use this one instead of
Accept-Language header (4) ?
Is that really required?
A configurable order doesn't make sense for me, because you shouldn't change
step 1, 2, 3 and 5.
The only possible solution would be to make step 4 (Accept-Language)
optional. So, the admin can disable it in the admin console.
Yes, that was what I was thinking, swapping 4 and 5 is the same as disabling Accept-Language. I can't see why anyone would want to do that though.
Maybe just because he wants to enforce showing login page in "tested" 
language like English ? Accept-Language can contain anything in it, so 
it may contain language, which is "partially" supported by Keycloak (not 
all labels and messages properly translated) and it may lead to the 
unproper login page with some labels in english and some in the second 
language, which may not look good.

But I don't know, maybe the use-case is really just theoretic. I agree 
that other changes in order instead of removing Accept-Language are 
likely not needed.

Marek
?
The admin can configure the supported locales, so he can add only english, if he wants to support only english.


Marek
On 23.2.2015 18:40, Michael Gerber wrote:
The algorithm to determine the correct locale is like that:
1. Locale cookie
2. User profile (UserModel.attribute)
3. ui_locales query parameter
4. Accept-Language http header
5. Default realm locale
The login page has also a dropdown with all available locales. The selected
value will be stored in the locale cookie.
Am 23.02.2015 um 18:14 schrieb Stan Silvert <ssilvert at redhat.com>:
On 2/23/2015 12:00 PM, Bill Burke wrote:
What's the best practice for choosing local?
As I understand it, the thing to do is to use the accept-language header
as a starting point. If it's the only thing you have to go on then use
it.
But I think we should definitely have a UserModel.attribute that is
settable by the user.
Also, we have talked about building an "application switcher" component
that developers can include in their apps. That app switcher should
include a dropdown to switch locale as well as one for switching the
application.
* User-Agent header?
* From a login hint? I think OIDC has something like this (but what
about SAML)?
* Should we store this information somewhere (cookie,
UserModel.attribute, etc..)
On 2/23/2015 11:53 AM, Michael Gerber wrote:
Hi all,
I started to work on the internationalization support
(https://issues.jboss.org/browse/KEYCLOAK-301).
I?ve already implemented the realm config in the admin console. I?ve put
it into the ?Theme Setting? (see screenshot)
I added the possibility to enable internationalization, add supported
locales and a select a default locale.
Now I?d like to implement the logic which choose the correct locale.
Therefore I need the http header, cookie, query parameter, realm and
user.
The LoginFormsProvider and AccountProvider have all this information
apart from the http header and the cookie.
So I thought I could replace the UriInfo with the HttpRequest, but that
doesn?t work, because I can not access the UriInfo through the
HttpRequest (java.lang.NoSuchMethodError:
org.jboss.resteasy.spi.HttpRequest.getUri()Ljavax/ws/rs/core/UriInfo;).
So, I will add the HttpHeader to the LoginFormsProvider
and AccountProvider, or does anyone have a better idea?
@Bill
How do you plan to store the claim ?locale? on a user? Will it be
accessible through the UserModel interface?
Best
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
_______________________________________________
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/20150224/d17121d4/attachment-0001.html 

From bruno at abstractj.org  Tue Feb 24 04:18:45 2015
From: bruno at abstractj.org (Bruno Oliveira)
Date: Tue, 24 Feb 2015 01:18:45 -0800 (PST)
Subject: [keycloak-dev] Alternatives to sourceforge
In-Reply-To: <172308977.13979303.1424759309566.JavaMail.zimbra@redhat.com>
References: <172308977.13979303.1424759309566.JavaMail.zimbra@redhat.com>
Message-ID: <1424769524259.0a7f5b46@Nodemailer>

Oh damn, I missed the appliance dist on maven central, I'm sorry



?

abstractj
PGP: 0x84DC9914

On Tue, Feb 24, 2015 at 3:28 AM, Stian Thorgersen <stian at redhat.com>
wrote:

> It's in Maven Central as well:
> http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22keycloak-appliance-dist-all%22
> Personally, I've never seen sourceforge unavailable, but I have seen jboss.org slow and unavailable frequently.
> ----- Original Message -----
>> From: "Bruno Oliveira" <bruno at abstractj.org>
>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
>> Sent: Monday, February 23, 2015 9:49:27 PM
>> Subject: [keycloak-dev] Alternatives to sourceforge
>> 
>> Good morning guys, I know is pretty much possible to build/run KC with
>> no need to download to sourceforge. But today, do we have any
>> alternative to download KC when sourceforge is down? [1]
>> 
>> Not the end of the world, but would be nice to have a backup site.
>> 
>> [1] -
>> http://photon.abstractj.org/Page_not_found_-_SourceForge.net_2015-02-23_17-47-40.jpg
>> 
>> --
>> 
>> abstractj
>> PGP: 0x84DC9914
>> _______________________________________________
>> 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/20150224/0c49a544/attachment.html 

From bburke at redhat.com  Tue Feb 24 07:58:59 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 24 Feb 2015 07:58:59 -0500
Subject: [keycloak-dev] Simple mode?
In-Reply-To: <866459802.13978034.1424759028211.JavaMail.zimbra@redhat.com>
References: <54EB551A.4010004@redhat.com>
	<866459802.13978034.1424759028211.JavaMail.zimbra@redhat.com>
Message-ID: <54EC7593.1010803@redhat.com>



On 2/24/2015 1:23 AM, Stian Thorgersen wrote:
> -1000
>
> I can't see how this would help jboss.org guys? They have most complex deployment out there.
>

Not RHT IT!  They have a complex setup.  jboss.org guys are different.

> As fair as other JBoss projects go and allowing them to embed Keycloak into their projects, this is along the lines of what I proposed. Although this is proposing to change the behaviour of Keycloak not just remove features.
>
> For other users I don't see the use-case. We should instead focus on making sure Keycloak has the required features and is easy to use.
>

They have a performance issue.  The redirects and processing required 
just to login (or to check a login) is pretty large for them for pages 
where a login really isn't important and all these pages are interested 
in is 1) is the user logged in 2) what is their userid/full name so they 
can link to a profile page.  These pages have zero need for a token or 
session management.

Bill


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Tue Feb 24 08:02:00 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 24 Feb 2015 08:02:00 -0500 (EST)
Subject: [keycloak-dev] Simple mode?
In-Reply-To: <54EC7593.1010803@redhat.com>
References: <54EB551A.4010004@redhat.com>
	<866459802.13978034.1424759028211.JavaMail.zimbra@redhat.com>
	<54EC7593.1010803@redhat.com>
Message-ID: <274866400.14146740.1424782920477.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, February 24, 2015 1:58:59 PM
> Subject: Re: [keycloak-dev] Simple mode?
> 
> 
> 
> On 2/24/2015 1:23 AM, Stian Thorgersen wrote:
> > -1000
> >
> > I can't see how this would help jboss.org guys? They have most complex
> > deployment out there.
> >
> 
> Not RHT IT!  They have a complex setup.  jboss.org guys are different.
> 
> > As fair as other JBoss projects go and allowing them to embed Keycloak into
> > their projects, this is along the lines of what I proposed. Although this
> > is proposing to change the behaviour of Keycloak not just remove features.
> >
> > For other users I don't see the use-case. We should instead focus on making
> > sure Keycloak has the required features and is easy to use.
> >
> 
> They have a performance issue.  The redirects and processing required
> just to login (or to check a login) is pretty large for them for pages
> where a login really isn't important and all these pages are interested
> in is 1) is the user logged in 2) what is their userid/full name so they
> can link to a profile page.  These pages have zero need for a token or
> session management.

The simple case there is just for the static web pages though. They still have SSO to issues.jboss.org for example, which will need proper tokens.

> 
> Bill
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bgorai at cisco.com  Tue Feb 24 08:07:57 2015
From: bgorai at cisco.com (Bappaditya Gorai (bgorai))
Date: Tue, 24 Feb 2015 13:07:57 +0000
Subject: [keycloak-dev] Keycloak Clustering 1.1.0.Final - Getting
 infinispan type casting error (DefaultCacheContainer to
 EmbeddedCacheManager) in DefaultInfinispanConnectionProviderFactory
Message-ID: <C5AF53298BAB5F4A88B28966E43B40AD0568A97A@xmb-aln-x12.cisco.com>

In my standalone configuration file I am using following subsystem version for infinispan, not sure whether it has any relevance to my issue.

<subsystem xmlns="urn:jboss:domain:infinispan:1.5">

Thanks
Bappaditya Gorai

From: Bappaditya Gorai (bgorai)
Sent: Monday, February 23, 2015 2:46 PM
To: keycloak-dev at lists.jboss.org
Subject: Keycloak Clustering 1.1.0.Final - Getting infinispan type casting error (DefaultCacheContainer to EmbeddedCacheManager) in DefaultInfinispanConnectionProviderFactory

Hi Team,

I am trying  configure  Keycloak in clustered environment (EAP 6.3), however getting following error (stack trace is provided below) . I have followed instructions provided in "Chapter 24. Clustering" in Keycloak Guide (http://docs.jboss.org/keycloak/docs/1.1.0.Final/userguide/html/clustering.html). Let me know if I am missing something.


13:23:25,681 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth]] (ServerService Thread Pool -- 62) JBWEB000289: Servlet Keycloak REST Interface threw load() exception: java.lang.ClassCastException: org.jboss.as.clustering.infinispan.DefaultCacheContainer cannot be cast to org.infinispan.manager.EmbeddedCacheManager
        at org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory.initContainerManaged(DefaultInfinispanConnectionProviderFactory.java:70) [keycloak-connections-infinispan-1.1.0.Final.jar:1.1.0.Final]
        at org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory.lazyInit(DefaultInfinispanConnectionProviderFactory.java:59) [keycloak-connections-infinispan-1.1.0.Final.jar:1.1.0.Final]
        at org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory.create(DefaultInfinispanConnectionProviderFactory.java:30) [keycloak-connections-infinispan-1.1.0.Final.jar:1.1.0.Final]
        at org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory.create(DefaultInfinispanConnectionProviderFactory.java:18) [keycloak-connections-infinispan-1.1.0.Final.jar:1.1.0.Final]



Thanks
Bappaditya Gorai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150224/587297e3/attachment.html 

From lholmqui at redhat.com  Tue Feb 24 08:10:16 2015
From: lholmqui at redhat.com (Lucas Holmquist)
Date: Tue, 24 Feb 2015 08:10:16 -0500
Subject: [keycloak-dev] Alternatives to sourceforge
In-Reply-To: <1424769524259.0a7f5b46@Nodemailer>
References: <172308977.13979303.1424759309566.JavaMail.zimbra@redhat.com>
	<1424769524259.0a7f5b46@Nodemailer>
Message-ID: <7412AF2C-6655-47DD-9094-F08C15EFD5C4@redhat.com>

why not also use GitHub Releases.  You can upload a binary.  it is a manual process, however
> On Feb 24, 2015, at 4:18 AM, Bruno Oliveira <bruno at abstractj.org> wrote:
> 
> Oh damn, I missed the appliance dist on maven central, I'm sorry
> 
> ?
> 
> abstractj
> PGP: 0x84DC9914
> 
> 
> On Tue, Feb 24, 2015 at 3:28 AM, Stian Thorgersen <stian at redhat.com <mailto:stian at redhat.com>> wrote:
> 
> It's in Maven Central as well: 
> 
> http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22keycloak-appliance-dist-all%22 
> 
> Personally, I've never seen sourceforge unavailable, but I have seen jboss.org slow and unavailable frequently. 
> 
> ----- Original Message ----- 
> > From: "Bruno Oliveira" <bruno at abstractj.org> 
> > To: "keycloak dev" <keycloak-dev at lists.jboss.org> 
> > Sent: Monday, February 23, 2015 9:49:27 PM 
> > Subject: [keycloak-dev] Alternatives to sourceforge 
> > 
> > Good morning guys, I know is pretty much possible to build/run KC with 
> > no need to download to sourceforge. But today, do we have any 
> > alternative to download KC when sourceforge is down? [1] 
> > 
> > Not the end of the world, but would be nice to have a backup site. 
> > 
> > [1] - 
> > http://photon.abstractj.org/Page_not_found_-_SourceForge.net_2015-02-23_17-47-40.jpg 
> > 
> > -- 
> > 
> > abstractj 
> > PGP: 0x84DC9914 
> > _______________________________________________ 
> > 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/20150224/bad8cbde/attachment-0001.html 

From mposolda at redhat.com  Tue Feb 24 08:32:39 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 24 Feb 2015 14:32:39 +0100
Subject: [keycloak-dev] Internationalization support (KEYCLOAK-301)
In-Reply-To: <eeacec6a-d534-40ca-8c54-86a9a09be93b@me.com>
References: <eeacec6a-d534-40ca-8c54-86a9a09be93b@me.com>
Message-ID: <54EC7D77.1030907@redhat.com>

On 24.2.2015 10:03, Michael Gerber wrote:
>
>
> Am 24. Februar 2015 um 09:47 schrieb Marek Posolda <mposolda at redhat.com>:
>
>> On 24.2.2015 07:40, Stian Thorgersen wrote:
>>> ----- Original Message -----
>>>> From: "Michael Gerber" <gerbermichi at me.com <mailto:gerbermichi at me.com>>
>>>> To: "Stian Thorgersen" <stian at redhat.com <mailto:stian at redhat.com>>
>>>> Cc: "Marek Posolda" <mposolda at redhat.com 
>>>> <mailto:mposolda at redhat.com>>, "Stan Silvert" <ssilvert at redhat.com 
>>>> <mailto:ssilvert at redhat.com>>, keycloak-dev at lists.jboss.org 
>>>> <mailto:keycloak-dev at lists.jboss.org>
>>>> Sent: Tuesday, February 24, 2015 7:37:10 AM
>>>> Subject: Re: [keycloak-dev] Internationalization support (KEYCLOAK-301)
>>>> Am 24. Februar 2015 um 07:26 schrieb Stian Thorgersen 
>>>> <stian at redhat.com <mailto:stian at redhat.com>>:
>>>> ----- Original Message -----
>>>> From: "Marek Posolda" <mposolda at redhat.com 
>>>> <mailto:mposolda at redhat.com>>
>>>> To: "Michael Gerber" <gerbermichi at me.com 
>>>> <mailto:gerbermichi at me.com>>, "Stan Silvert"
>>>> <ssilvert at redhat.com <mailto:ssilvert at redhat.com>>
>>>> Cc: keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>> Sent: Monday, February 23, 2015 6:48:00 PM
>>>> Subject: Re: [keycloak-dev] Internationalization support (KEYCLOAK-301)
>>>> Will the order be configurable? For example admin may want to configure
>>>> realm locale (5) and wants users to use this one instead of
>>>> Accept-Language header (4) ?
>>>> Is that really required?
>>>> A configurable order doesn't make sense for me, because you 
>>>> shouldn't change
>>>> step 1, 2, 3 and 5.
>>>> The only possible solution would be to make step 4 (Accept-Language)
>>>> optional. So, the admin can disable it in the admin console.
>>> Yes, that was what I was thinking, swapping 4 and 5 is the same as 
>>> disabling Accept-Language. I can't see why anyone would want to do 
>>> that though.
>> Maybe just because he wants to enforce showing login page in "tested"
>> language like English ? Accept-Language can contain anything in it, so
>> it may contain language, which is "partially" supported by Keycloak (not
>> all labels and messages properly translated) and it may lead to the
>> unproper login page with some labels in english and some in the second
>> language, which may not look good.
>>
>> But I don't know, maybe the use-case is really just theoretic. I agree
>> that other changes in order instead of removing Accept-Language are
>> likely not needed.
>>
>> Marek
> The admin can configure the supported locales, so he can add only 
> english, if he wants to support only english.
Ok, looks that might be sufficient. I have just "theoretical" usecase. 
Maybe it's not needed and if later there is request for "disable 
Accept-Language" it can be added sometime later.

Marek

>
>>
>>>> Marek
>>>> On 23.2.2015 18:40, Michael Gerber wrote:
>>>>> The algorithm to determine the correct locale is like that:
>>>>> 1. Locale cookie
>>>>> 2. User profile (UserModel.attribute)
>>>>> 3. ui_locales query parameter
>>>>> 4. Accept-Language http header
>>>>> 5. Default realm locale
>>>>> The login page has also a dropdown with all available locales. The 
>>>>> selected
>>>>> value will be stored in the locale cookie.
>>>>>> Am 23.02.2015 um 18:14 schrieb Stan Silvert <ssilvert at redhat.com 
>>>>>> <mailto:ssilvert at redhat.com>>:
>>>>>> On 2/23/2015 12:00 PM, Bill Burke wrote:
>>>>>>> What's the best practice for choosing local?
>>>>>> As I understand it, the thing to do is to use the accept-language 
>>>>>> header
>>>>>> as a starting point. If it's the only thing you have to go on 
>>>>>> then use
>>>>>> it.
>>>>>> But I think we should definitely have a UserModel.attribute that is
>>>>>> settable by the user.
>>>>>> Also, we have talked about building an "application switcher" 
>>>>>> component
>>>>>> that developers can include in their apps. That app switcher should
>>>>>> include a dropdown to switch locale as well as one for switching the
>>>>>> application.
>>>>>>> * User-Agent header?
>>>>>>> * From a login hint? I think OIDC has something like this (but what
>>>>>>> about SAML)?
>>>>>>> * Should we store this information somewhere (cookie,
>>>>>>> UserModel.attribute, etc..)
>>>>>>> On 2/23/2015 11:53 AM, Michael Gerber wrote:
>>>>>>>> Hi all,
>>>>>>>> I started to work on the internationalization support
>>>>>>>> (https://issues.jboss.org/browse/KEYCLOAK-301).
>>>>>>>> I?ve already implemented the realm config in the admin console. 
>>>>>>>> I?ve put
>>>>>>>> it into the ?Theme Setting? (see screenshot)
>>>>>>>> I added the possibility to enable internationalization, add 
>>>>>>>> supported
>>>>>>>> locales and a select a default locale.
>>>>>>>> Now I?d like to implement the logic which choose the correct 
>>>>>>>> locale.
>>>>>>>> Therefore I need the http header, cookie, query parameter, 
>>>>>>>> realm and
>>>>>>>> user.
>>>>>>>> The LoginFormsProvider and AccountProvider have all this 
>>>>>>>> information
>>>>>>>> apart from the http header and the cookie.
>>>>>>>> So I thought I could replace the UriInfo with the HttpRequest, 
>>>>>>>> but that
>>>>>>>> doesn?t work, because I can not access the UriInfo through the
>>>>>>>> HttpRequest (java.lang.NoSuchMethodError:
>>>>>>>> org.jboss.resteasy.spi.HttpRequest.getUri()Ljavax/ws/rs/core/UriInfo;).
>>>>>>>> So, I will add the HttpHeader to the LoginFormsProvider
>>>>>>>> and AccountProvider, or does anyone have a better idea?
>>>>>>>> @Bill
>>>>>>>> How do you plan to store the claim ?locale? on a user? Will it be
>>>>>>>> accessible through the UserModel interface?
>>>>>>>> Best
>>>>>>>> Michael
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-dev mailing list
>>>>>>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>> _______________________________________________
>>>>>> keycloak-dev mailing list
>>>>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150224/579b1322/attachment-0001.html 

From bburke at redhat.com  Tue Feb 24 08:44:14 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 24 Feb 2015 08:44:14 -0500
Subject: [keycloak-dev] Internationalization for model data
Message-ID: <54EC802E.3000008@redhat.com>

There's data stored in a bunch of places that should be 
internationalized.  i.e. Role descriptions.  I was thinking for this 
type of stuff, for both simplicity and ease of migration, we still 
continue to input this type of metadata through one field.  Then if the 
user wants to internationalize a piece of data, they just replace the 
text with a property variable.

Role Description: "Admin access to main application"

could be replaced with

Role Description: "${role.admin.description}"

Then the variable 'role.admin.description' is just replaced with a 
theme-based property.

This way, users dont' have to learn about internationalization until 
when and if the need it, existing deployments will still just work, and 
we don't have to expand our data model.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Tue Feb 24 08:53:20 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 24 Feb 2015 08:53:20 -0500 (EST)
Subject: [keycloak-dev] Internationalization for model data
In-Reply-To: <54EC802E.3000008@redhat.com>
References: <54EC802E.3000008@redhat.com>
Message-ID: <925240469.14198291.1424786000238.JavaMail.zimbra@redhat.com>

+1000

Exactly what I've proposed about 10 times already ;)

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, February 24, 2015 2:44:14 PM
> Subject: [keycloak-dev] Internationalization for model data
> 
> There's data stored in a bunch of places that should be
> internationalized.  i.e. Role descriptions.  I was thinking for this
> type of stuff, for both simplicity and ease of migration, we still
> continue to input this type of metadata through one field.  Then if the
> user wants to internationalize a piece of data, they just replace the
> text with a property variable.
> 
> Role Description: "Admin access to main application"
> 
> could be replaced with
> 
> Role Description: "${role.admin.description}"
> 
> Then the variable 'role.admin.description' is just replaced with a
> theme-based property.
> 
> This way, users dont' have to learn about internationalization until
> when and if the need it, existing deployments will still just work, and
> we don't have to expand our data model.
> 
> --
> 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  Tue Feb 24 09:16:01 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 24 Feb 2015 15:16:01 +0100
Subject: [keycloak-dev] Keycloak Clustering 1.1.0.Final - Getting
 infinispan type casting error (DefaultCacheContainer to
 EmbeddedCacheManager) in DefaultInfinispanConnectionProviderFactory
In-Reply-To: <C5AF53298BAB5F4A88B28966E43B40AD0568A97A@xmb-aln-x12.cisco.com>
References: <C5AF53298BAB5F4A88B28966E43B40AD0568A97A@xmb-aln-x12.cisco.com>
Message-ID: <54EC87A1.7080104@redhat.com>

Hi,

I can't reproduce the issue. It's strange as 
org.jboss.as.clustering.infinispan.DefaultCacheContainer is subclass of 
org.infinispan.manager.EmbeddedCacheManager. Didn't you do some 
packaging changes like adding infinispan jars to 
auth-server.war/WEB-INF/lib or something like that?

What I did for clustered Keycloak on EAP 6.3:

1) Unpack keycloak-war-dist 1.1.0.Final to my jboss-eap 6.3
2) Configured standalone/configuration/standalone-ha.xml and add this 
under infinispan subsystem:

  <cache-container name="keycloak" jndi-name="infinispan/Keycloak" 
start="EAGER">
   <transport lock-timeout="60000"/>
   <distributed-cache name="sessions" mode="SYNC" owners="2" 
segments="60"/>
   <distributed-cache name="loginFailures" mode="SYNC" owners="2" 
segments="60"/>
   <invalidation-cache name="realms" mode="SYNC"/>
   <invalidation-cache name="users"  mode="SYNC"/>
  </cache-container>

3) Configured standalone/configuration/keycloak-server.json and add this:

"connectionsInfinispan": {
     "default" : {
         "cacheContainer" : "java:jboss/infinispan/Keycloak"
     }
}

and also switch realmCache, userCache and userSessions to use: 
"provider": "infinispan"

4) Then run server with command:
./standalone.sh -c standalone-ha.xml

Let me know if these steps work for you.

Marek

On 24.2.2015 14:07, Bappaditya Gorai (bgorai) wrote:
>
> In my standalone configuration file I am using following subsystem 
> version for infinispan, not sure whether it has any relevance to my issue.
>
> <subsystem xmlns="urn:jboss:domain:infinispan:1.5">
>
> Thanks
>
> Bappaditya Gorai
>
> *From:*Bappaditya Gorai (bgorai)
> *Sent:* Monday, February 23, 2015 2:46 PM
> *To:* keycloak-dev at lists.jboss.org
> *Subject:* Keycloak Clustering 1.1.0.Final - Getting infinispan type 
> casting error (DefaultCacheContainer to EmbeddedCacheManager) in 
> DefaultInfinispanConnectionProviderFactory
>
> Hi Team,
>
> I am trying  configure  Keycloak in clustered environment (EAP 6.3), 
> however getting following error (stack trace is provided below) . I 
> have followed instructions provided in ?*Chapter 24. Clustering*? in 
> Keycloak Guide 
> (http://docs.jboss.org/keycloak/docs/1.1.0.Final/userguide/html/clustering.html). 
> Let me know if I am missing something.
>
> 13:23:25,681 ERROR 
> [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth]] 
> (ServerService Thread Pool -- 62) JBWEB000289: Servlet Keycloak REST 
> Interface threw load() exception: *java.lang.ClassCastException: 
> org.jboss.as.clustering.infinispan.DefaultCacheContainer cannot be 
> cast to org.infinispan.manager.EmbeddedCacheManager*
>
>         at 
> org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory.initContainerManaged(*DefaultInfinispanConnectionProviderFactory.java:70*) 
> [keycloak-connections-infinispan-1.1.0.Final.jar:1.1.0.Final]
>
>         at 
> org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory.lazyInit(DefaultInfinispanConnectionProviderFactory.java:59) 
> [keycloak-connections-infinispan-1.1.0.Final.jar:1.1.0.Final]
>
>         at 
> org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory.create(DefaultInfinispanConnectionProviderFactory.java:30) 
> [keycloak-connections-infinispan-1.1.0.Final.jar:1.1.0.Final]
>
>         at 
> org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory.create(DefaultInfinispanConnectionProviderFactory.java:18) 
> [keycloak-connections-infinispan-1.1.0.Final.jar:1.1.0.Final]
>
> Thanks
>
> Bappaditya Gorai
>
>
>
> _______________________________________________
> 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/20150224/5c20933e/attachment.html 

From bburke at redhat.com  Tue Feb 24 09:28:28 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 24 Feb 2015 09:28:28 -0500
Subject: [keycloak-dev] Internationalization for model data
In-Reply-To: <925240469.14198291.1424786000238.JavaMail.zimbra@redhat.com>
References: <54EC802E.3000008@redhat.com>
	<925240469.14198291.1424786000238.JavaMail.zimbra@redhat.com>
Message-ID: <54EC8A8C.9080603@redhat.com>

As usual, i'm a few steps behind.

On 2/24/2015 8:53 AM, Stian Thorgersen wrote:
> +1000
>
> Exactly what I've proposed about 10 times already ;)
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, February 24, 2015 2:44:14 PM
>> Subject: [keycloak-dev] Internationalization for model data
>>
>> There's data stored in a bunch of places that should be
>> internationalized.  i.e. Role descriptions.  I was thinking for this
>> type of stuff, for both simplicity and ease of migration, we still
>> continue to input this type of metadata through one field.  Then if the
>> user wants to internationalize a piece of data, they just replace the
>> text with a property variable.
>>
>> Role Description: "Admin access to main application"
>>
>> could be replaced with
>>
>> Role Description: "${role.admin.description}"
>>
>> Then the variable 'role.admin.description' is just replaced with a
>> theme-based property.
>>
>> This way, users dont' have to learn about internationalization until
>> when and if the need it, existing deployments will still just work, and
>> we don't have to expand our data model.
>>
>> --
>> 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 gerbermichi at me.com  Tue Feb 24 09:50:19 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Tue, 24 Feb 2015 15:50:19 +0100
Subject: [keycloak-dev] Internationalization for model data
In-Reply-To: <54EC8A8C.9080603@redhat.com>
References: <54EC802E.3000008@redhat.com>
	<925240469.14198291.1424786000238.JavaMail.zimbra@redhat.com>
	<54EC8A8C.9080603@redhat.com>
Message-ID: <16AA14D6-F875-4342-B45C-BF004AD73D3B@me.com>

Sounds good.

But can the end user in any screen see the role description? (apart from the admin console which is not internationalized?)

> Am 24.02.2015 um 15:28 schrieb Bill Burke <bburke at redhat.com>:
> 
> As usual, i'm a few steps behind.
> 
> On 2/24/2015 8:53 AM, Stian Thorgersen wrote:
>> +1000
>> 
>> Exactly what I've proposed about 10 times already ;)
>> 
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> Sent: Tuesday, February 24, 2015 2:44:14 PM
>>> Subject: [keycloak-dev] Internationalization for model data
>>> 
>>> There's data stored in a bunch of places that should be
>>> internationalized.  i.e. Role descriptions.  I was thinking for this
>>> type of stuff, for both simplicity and ease of migration, we still
>>> continue to input this type of metadata through one field.  Then if the
>>> user wants to internationalize a piece of data, they just replace the
>>> text with a property variable.
>>> 
>>> Role Description: "Admin access to main application"
>>> 
>>> could be replaced with
>>> 
>>> Role Description: "${role.admin.description}"
>>> 
>>> Then the variable 'role.admin.description' is just replaced with a
>>> theme-based property.
>>> 
>>> This way, users dont' have to learn about internationalization until
>>> when and if the need it, existing deployments will still just work, and
>>> we don't have to expand our data model.
>>> 
>>> --
>>> 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 <http://bill.burkecentral.com/>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150224/8206cdaa/attachment-0001.html 

From stian at redhat.com  Tue Feb 24 09:56:08 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 24 Feb 2015 09:56:08 -0500 (EST)
Subject: [keycloak-dev] Internationalization for model data
In-Reply-To: <16AA14D6-F875-4342-B45C-BF004AD73D3B@me.com>
References: <54EC802E.3000008@redhat.com>
	<925240469.14198291.1424786000238.JavaMail.zimbra@redhat.com>
	<54EC8A8C.9080603@redhat.com>
	<16AA14D6-F875-4342-B45C-BF004AD73D3B@me.com>
Message-ID: <746036361.14250017.1424789768992.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: "Stian Thorgersen" <stian at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Tuesday, February 24, 2015 3:50:19 PM
> Subject: Re: [keycloak-dev] Internationalization for model data
> 
> Sounds good.
> 
> But can the end user in any screen see the role description? (apart from the
> admin console which is not internationalized?)

Yes, on the oauth grant page, which is displayed for oauth clients on log-in

> 
> > Am 24.02.2015 um 15:28 schrieb Bill Burke <bburke at redhat.com>:
> > 
> > As usual, i'm a few steps behind.
> > 
> > On 2/24/2015 8:53 AM, Stian Thorgersen wrote:
> >> +1000
> >> 
> >> Exactly what I've proposed about 10 times already ;)
> >> 
> >> ----- Original Message -----
> >>> From: "Bill Burke" <bburke at redhat.com>
> >>> To: keycloak-dev at lists.jboss.org
> >>> Sent: Tuesday, February 24, 2015 2:44:14 PM
> >>> Subject: [keycloak-dev] Internationalization for model data
> >>> 
> >>> There's data stored in a bunch of places that should be
> >>> internationalized.  i.e. Role descriptions.  I was thinking for this
> >>> type of stuff, for both simplicity and ease of migration, we still
> >>> continue to input this type of metadata through one field.  Then if the
> >>> user wants to internationalize a piece of data, they just replace the
> >>> text with a property variable.
> >>> 
> >>> Role Description: "Admin access to main application"
> >>> 
> >>> could be replaced with
> >>> 
> >>> Role Description: "${role.admin.description}"
> >>> 
> >>> Then the variable 'role.admin.description' is just replaced with a
> >>> theme-based property.
> >>> 
> >>> This way, users dont' have to learn about internationalization until
> >>> when and if the need it, existing deployments will still just work, and
> >>> we don't have to expand our data model.
> >>> 
> >>> --
> >>> 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 <http://bill.burkecentral.com/>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
> 


From supittma at redhat.com  Tue Feb 24 10:45:17 2015
From: supittma at redhat.com (Summers Pittman)
Date: Tue, 24 Feb 2015 10:45:17 -0500
Subject: [keycloak-dev] WildFly integration (READ ME!)
In-Reply-To: <54EB62CC.1030305@redhat.com>
References: <969708031.6108771.1422954530044.JavaMail.zimbra@redhat.com>
	<1360543918.10348397.1424334753943.JavaMail.zimbra@redhat.com>
	<54E74D1C.4030600@redhat.com> <54E77464.2050400@redhat.com>
	<54E77884.7050003@redhat.com>
	<704793002.13480640.1424703042016.JavaMail.zimbra@redhat.com>
	<54EB4A5B.6040201@redhat.com> <54EB50A8.6050702@redhat.com>
	<54EB5E2D.2070508@redhat.com> <54EB6211.4070306@redhat.com>
	<54EB62CC.1030305@redhat.com>
Message-ID: <54EC9C8D.3060502@redhat.com>

On 02/23/2015 12:26 PM, Stan Silvert wrote:
> On 2/23/2015 12:23 PM, Stan Silvert wrote:
>> On 2/23/2015 12:06 PM, Summers Pittman wrote:
>>> On 02/23/2015 11:09 AM, Stan Silvert wrote:
>>>> On 2/23/2015 10:42 AM, Summers Pittman wrote:
>>>>> On 02/23/2015 09:50 AM, Stian Thorgersen wrote:
>>>>>> Just to clarify we're only talking about the server, not adapters.
>>>>>>
>>>>>> For the best and most friction free experience it would be best to have a dedicated Keycloak server, not to co-locate it with your JEE apps by deploying a WAR. With that regards we are considering dropping support for deploying Keycloak as a WAR.
>>>>> If I'm reading you correctly instead of
>>>>>
>>>>>     ~/WILDFLY_HOME/bin/startup.sh
>>>>>     code
>>>>>
>>>>>
>>>>> it will be
>>>>>
>>>>>
>>>>>     $WILDFLY_HOME/bin/startup.sh
>>>>>     code
>>>>>     #^@%! what broke in my auth
>>>>>     waste 10 minutes
>>>>>     $KEYCLOAK_HOME/bin/startup.sh
>>>>>
>>>> I don't understand.  What would break?
>>> I start developing after a reboot and KeyCloak's server isn't 
>>> running.  The auth is broken because the server isn't running 
>>> because I forgot to start it.
> Sorry.  Missed this response.  My question to you is would having the 
> ability to deploy your app on the Keycloak distribution be sufficient?
No.  I already have a Wildfly server which is part of my development 
process that I know how to deploy things to.  I don't want to set up a 
second one.

If getting a deployable package is not an option and the only solution 
that is being entertained is a stand alone app server I will just 
containerize the thing, give it a host name alias and forget about it.
>>>>>
>>>>> By keeping it a separate war 1) I can download the thing faster 
>>>>> and 2) I don't have to decide who to kick off of port 8080.
>>>> I don't think we would do anything to ban you from deploying your 
>>>> apps in the same WildFly instance as Keycloak.   Can you explain 
>>>> your concerns in more detail?
>>> My reading of the original email was that the standalone server 
>>> would be the only distribution.  IE there would be no more warfile 
>>> distribution.
>> Right.  But it would be a distribution that has two modes.  The modes 
>> would be standalone mode and a mode that would allow it to join a 
>> WildFly domain.
>>
>> You could still deploy your applications to the Keycloak 
>> distribution.  But for production, that's probably not what you want.
>>
>> What I don't understand is what problems it would cause.  Can you 
>> elaborate on that?
>>>>>
>>>>> Again, IF I'm reading your message correctly
>>>>>
>>>>>> That being said we still need to support embedding Keycloak in other projects. We plan to continue to support this through the mechanism UPS does, basically build-your-own auth-server.war.
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Summers Pittman"<supittma at redhat.com>
>>>>>>> To:keycloak-dev at lists.jboss.org
>>>>>>> Sent: Friday, February 20, 2015 7:10:12 PM
>>>>>>> Subject: Re: [keycloak-dev] WildFly integration (READ ME!)
>>>>>>>
>>>>>>> On 02/20/2015 12:52 PM, Stan Silvert wrote:
>>>>>>>> On 2/20/2015 10:05 AM, Summers Pittman wrote:
>>>>>>>>> On 02/19/2015 03:32 AM, Stian Thorgersen wrote:
>>>>>>>>>> No comments?!
>>>>>>>>> Peanut gallery chiming in; you asked for it ;)
>>>>>>>>>
>>>>>>>>> I am not a WildFly developer or administrator.  So read this email as
>>>>>>>>> the opinions of a talented developer who loves the hell out of using
>>>>>>>>> KeyCloak and WildFly and sings its praises from the roof tops but has no
>>>>>>>>> idea what you are talking about.
>>>>>>>> Thanks Summers.  Very valuable feedback.
>>>>>>> Thanks for taking the time to explain some things I know more than I did
>>>>>>> this morning.
>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>> From: "Stian Thorgersen"<stian at redhat.com>
>>>>>>>>>>> To: "keycloak dev"<keycloak-dev at lists.jboss.org>
>>>>>>>>>>> Sent: Tuesday, February 3, 2015 10:08:50 AM
>>>>>>>>>>> Subject: [keycloak-dev] WildFly integration (READ ME!)
>>>>>>>>>>>
>>>>>>>>>>> All,
>>>>>>>>>>>
>>>>>>>>>>> We have a few decisions to make in the not so far future. I'm away from
>>>>>>>>>>> Thursday, so let's have a hangout when I get back on the 17th February
>>>>>>>>>>> if
>>>>>>>>>>> that works for everyone.
>>>>>>>>>>>
>>>>>>>>>>> The list of things to discuss includes:
>>>>>>>>>>>
>>>>>>>>>>> * Drop keycloak-server.json - Should we drop our own configuration file
>>>>>>>>>>> and
>>>>>>>>>>> use DMR (standalone.xml)
>>>>>>>>> If on day one enabling KeyCloak in my project was any more complicated
>>>>>>>>> than dropping a pregenerated file into my WEB-INF directory I would have
>>>>>>>>> closed the project and never looked back.  -1
>>>>>>>> We're talking about the auth server's config rather than the config for
>>>>>>>> your project.   For projects, we want to make it even easier to the
>>>>>>>> point where you don't even need the json file to get a default
>>>>>>>> configuration.
>>>>>>> Ah, that makes more sense.
>>>>>>>>>>> * Keycloak CLI - Should we create our own or use WildFly CLI
>>>>>>>>> On the one hand the wildfly CLI is black magic.  On the other hand it is
>>>>>>>>> really well done black magic.  It is very hard to do CLIs well so I
>>>>>>>>> would like to see the wildfly CLI be used.
>>>>>>>> That's the general feedback we often get from the WildFly community.  I
>>>>>>>> agree.
>>>>>>>>>>> * Admin operations exposed over DMR - Should we expose none, some or all
>>>>>>>>>>> admin operations over DMR? If we expose all should we deprecate the
>>>>>>>>>>> current
>>>>>>>>>>> REST endpoints?
>>>>>>>>> Is DMR the thing that puts stuff in the WildFly admin UI (I tried to
>>>>>>>>> read the google result for "wildfly DMR" but it quickly turned into
>>>>>>>>> turtles all the way down)?
>>>>>>>> At its core, DMR is really just a tiny single-package library where the
>>>>>>>> API is just 3 or 4 classes.  Those classes are the "language" spoken to
>>>>>>>> make changes to the WildFly management model
>>>>>>>> (standalone.xml/domain.xml).  So the question is whether we should hook
>>>>>>>> into the management model infrastructure to make Keycloak changes.
>>>>>>>>> In my experience I don't LIKE using the WildFly admin UI, I would rather
>>>>>>>>> use the CLI, scripts, etc.
>>>>>>>> Also a typical response.  Again, I agree.  Thankfully, the Keycloak
>>>>>>>> admin UI doesn't suffer from the same deficiencies as the WildFly admin UI.
>>>>>>>>
>>>>>>>> But with Keycloak, we don't yet have a CLI, so there are lots of
>>>>>>>> questions around whether we piggyback on WildFly CLI, which means
>>>>>>>> adopting DMR in some way.
>>>>>>>>> I haven't used the KeyCloak REST endpoints
>>>>>>>>> and keeping them just increases the attack surface.
>>>>>>>> Do you mean that keeping the REST endpoints would be a good thing or a
>>>>>>>> bad thing?  Can we hear more from you on this topic?
>>>>>>> I think that if there were a WildFly way to do all of the admin tasks
>>>>>>> that the RESTful endpoints do now it would be good to remove the RESTful
>>>>>>> API to decrease the API surface to just WildFly.  IE fewer things to
>>>>>>> worry about getting hacked and to watch for for vulnerabilities.
>>>>>>>>>>> * Packaging/distribution - How do we distribute Keycloak? Options:
>>>>>>>>>>>       - Full WildFly
>>>>>>>>>>>       - Core/web WildFly
>>>>>>>>>>>       - Overlay/installer/feature-pack to install to existing WF and EAP
>>>>>>>>>>>       - WAR bundle
>>>>>>>>> How about a shell script that examines a WF install directory and does
>>>>>>>>> all the magic for me or aDocker container?
>>>>>>>>>
>>>>>>>>> In general I have not liked the experience of having wildfly bundled
>>>>>>>>> with a product.  It tends to mess with other servers I have installed
>>>>>>>>> and be a general PITA to maintain for anything more than the most
>>>>>>>>> trivial of demos.
>>>>>>>> Good feedback.
>>>>>>>>>>> * How should we deal with providers, themes and keycloak-server.json in
>>>>>>>>>>> domain-mode
>>>>>>>>>>>
>>>>>>>>>>> * MSC all the way - We can deploy directly through the Undertow
>>>>>>>>>>> sub-system
>>>>>>>>>>> instead of deploying a WAR from the sub-system
>>>>>>>>> What is MSC?
>>>>>>>> Modular Service Container.  It's the thing that lets you declare and
>>>>>>>> register services in WildFly.  But I'm not completely sure what Stian is
>>>>>>>> proposing here.
>>>>>>>>>>> * Split sub-systems - Should we split the sub-system in two? One for the
>>>>>>>>>>> auth-server and another for the adapter
>>>>>>>>> What are the trade offs?  What will using KeyCloak look like from my POV
>>>>>>>>> if we split?
>>>>>>>> Instead of
>>>>>>>>
>>>>>>>> subsystem=keycloak/auth-server=main-auth-server
>>>>>>>> subsystem=keycloak/secure-deployment=foo
>>>>>>>>
>>>>>>>> you would have
>>>>>>>>
>>>>>>>> subsystem=keycloak-server/auth-server=main-auth-server
>>>>>>>> subsystem=keycloak-deployments/secure-deployment=foo
>>>>>>>>
>>>>>>>> Another option would be to just leave it as it is today and just hide
>>>>>>>> the "auth-server" resource for installations where you don't expect the
>>>>>>>> auth server to run.
>>>>>>>>
>>>>>>>> The answer will probably be more a function of how we want to organize
>>>>>>>> the code rather than how it will look to the end user.
>>>>>>> As a end user it sounds like both work for me.
>>>>>>>>>>> * Deployable to other containers - Should it be possible to deploy
>>>>>>>>>>> Keycloak
>>>>>>>>>>> to Tomcat, Jetty, Fuse, etc..? One option could be to have reduced
>>>>>>>>>>> features
>>>>>>>>>>> in other containers (for example no client-cert)
>>>>>>>>> The awesomeness of WildFly has forever made web containers look
>>>>>>>>> insignificant to me.  If Glassfish still had a community edition worth a
>>>>>>>>> damn I would say target it as well.  I don't know how TomEE is but that
>>>>>>>>> may be good to support just for a "first one's free" to get people into
>>>>>>>>> WildFly land.
>>>>>>>>>
>>>>>>>>> I don't think Websphere or WebLogic support has ever gotten anyone
>>>>>>>>> excited about a project.  Honestly they are the technology equivalent of
>>>>>>>>> taking a cold shower with grandma.
>>>>>>>> I could have done without that image. :-|
>>>>>>>>
>>>>>>>> But thanks again!
>>>>>>> YW.
>>>>>>>>>>> Please add any other relevant topics.
>>>>>>>>>>>
>>>>>>>>>>> Next big discussion I want to have is about distribution of adapters,
>>>>>>>>>>> but
>>>>>>>>>>> let's do one at a time ;)
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 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
>>>>>>> --
>>>>>>> Summers Pittman
>>>>>>>>> Phone:404 941 4698
>>>>>>>>> Java is my crack.
>>>>>>> _______________________________________________
>>>>>>> keycloak-dev mailing list
>>>>>>> keycloak-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Summers Pittman
>>>>> >>Phone:404 941 4698
>>>>> >>Java is my crack.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>>
>>> -- 
>>> Summers Pittman
>>> >>Phone:404 941 4698
>>> >>Java is my crack.
>>
>>
>>
>> _______________________________________________
>> 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


-- 
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150224/12b40437/attachment-0001.html 

From bburke at redhat.com  Tue Feb 24 11:24:41 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 24 Feb 2015 11:24:41 -0500
Subject: [keycloak-dev] Internationalization for model data
In-Reply-To: <16AA14D6-F875-4342-B45C-BF004AD73D3B@me.com>
References: <54EC802E.3000008@redhat.com>
	<925240469.14198291.1424786000238.JavaMail.zimbra@redhat.com>
	<54EC8A8C.9080603@redhat.com>
	<16AA14D6-F875-4342-B45C-BF004AD73D3B@me.com>
Message-ID: <54ECA5C9.8000102@redhat.com>



On 2/24/2015 9:50 AM, Michael Gerber wrote:
> Sounds good.
>
> But can the end user in any screen see the role description? (apart from
> the admin console which is not internationalized?)
>

Right now this description is used on the consent screen.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From gerbermichi at me.com  Tue Feb 24 13:12:06 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Tue, 24 Feb 2015 19:12:06 +0100
Subject: [keycloak-dev] Email Internationalization
Message-ID: <A44322F3-19DA-423C-B161-D99307BB87CF@me.com>

Hi all,

How would you internationalize the emails?

I suggest that we create different templates (*.ftl) for each locale, what do you think about that?

Best
Michael

From bburke at redhat.com  Tue Feb 24 13:33:50 2015
From: bburke at redhat.com (Bill Burke)
Date: Tue, 24 Feb 2015 13:33:50 -0500
Subject: [keycloak-dev] Email Internationalization
In-Reply-To: <A44322F3-19DA-423C-B161-D99307BB87CF@me.com>
References: <A44322F3-19DA-423C-B161-D99307BB87CF@me.com>
Message-ID: <54ECC40E.9010503@redhat.com>

I agree but can you point to the original design discussion?  My thought 
was that properties, .ftl, .html, really any resource could be overriden 
by a locale.

On 2/24/2015 1:12 PM, Michael Gerber wrote:
> Hi all,
>
> How would you internationalize the emails?
>
> I suggest that we create different templates (*.ftl) for each locale, what do you think about that?
>
> Best
> 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  Tue Feb 24 13:48:56 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Tue, 24 Feb 2015 19:48:56 +0100
Subject: [keycloak-dev] Email Internationalization
In-Reply-To: <54ECC40E.9010503@redhat.com>
References: <A44322F3-19DA-423C-B161-D99307BB87CF@me.com>
	<54ECC40E.9010503@redhat.com>
Message-ID: <61CC27BF-6FF7-4DAB-B575-E3093A20D6CA@me.com>

Thats written in the jira:

Our built-in themes should strive to only require internationalized message bundles and when absolutely required stylesheet overrides (for example for right-to-left languages). However, themes should support internationalized:
	? Message bundles
	? Stylesheets
	? Templates
If internationalization is required for images this should by specifying different images either through stylesheets or templates.

So you suggest that every file is overridable by a locale?

> Am 24.02.2015 um 19:33 schrieb Bill Burke <bburke at redhat.com>:
> 
> I agree but can you point to the original design discussion?  My thought 
> was that properties, .ftl, .html, really any resource could be overriden 
> by a locale.
> 
> On 2/24/2015 1:12 PM, Michael Gerber wrote:
>> Hi all,
>> 
>> How would you internationalize the emails?
>> 
>> I suggest that we create different templates (*.ftl) for each locale, what do you think about that?
>> 
>> Best
>> 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



From stian at redhat.com  Wed Feb 25 00:31:21 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 25 Feb 2015 00:31:21 -0500 (EST)
Subject: [keycloak-dev] Email Internationalization
In-Reply-To: <61CC27BF-6FF7-4DAB-B575-E3093A20D6CA@me.com>
References: <A44322F3-19DA-423C-B161-D99307BB87CF@me.com>
	<54ECC40E.9010503@redhat.com>
	<61CC27BF-6FF7-4DAB-B575-E3093A20D6CA@me.com>
Message-ID: <982598952.14757064.1424842281051.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, February 24, 2015 7:48:56 PM
> Subject: Re: [keycloak-dev] Email Internationalization
> 
> Thats written in the jira:
> 
> Our built-in themes should strive to only require internationalized message
> bundles and when absolutely required stylesheet overrides (for example for
> right-to-left languages). However, themes should support internationalized:
> 	? Message bundles
> 	? Stylesheets
> 	? Templates
> If internationalization is required for images this should by specifying
> different images either through stylesheets or templates.
> 
> So you suggest that every file is overridable by a locale?

I'm not sure we need to support this for templates, stylesheets and images. It could actually be quite bad practice. There's a lot of logic in templates, so maintaining multiple versions of the same template would be annoying and could easily introduce bugs and exploits. Another approach is to avoid text in images and do all translations in messages. If the locale is made available to the template itself anyone that needs to do some locale specific things in the template can do that within a single template with conditions. We should definitively not use multiple templates ourselves. We may need to support it for others, but I suggest we don't initially and see if anyone really needs it.

With regards to emails they are simpler now, but we also want to support multi-part (text and html), where the html template would contain other things than just the text. I suggest we extract the text into a single message. We should then add support to resolve variables within messages (for example "resetPasswordEmail=Hello ${user.firstName} ..."). 

Makes it a lot simpler to deal with translations if it's all done within messages. Usually devs are not language experts and this would make it easy for non-devs to provide translations.

> 
> > Am 24.02.2015 um 19:33 schrieb Bill Burke <bburke at redhat.com>:
> > 
> > I agree but can you point to the original design discussion?  My thought
> > was that properties, .ftl, .html, really any resource could be overriden
> > by a locale.
> > 
> > On 2/24/2015 1:12 PM, Michael Gerber wrote:
> >> Hi all,
> >> 
> >> How would you internationalize the emails?
> >> 
> >> I suggest that we create different templates (*.ftl) for each locale, what
> >> do you think about that?
> >> 
> >> Best
> >> 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
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Wed Feb 25 00:38:19 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 25 Feb 2015 00:38:19 -0500 (EST)
Subject: [keycloak-dev] WildFly integration (READ ME!)
In-Reply-To: <54EC9C8D.3060502@redhat.com>
References: <969708031.6108771.1422954530044.JavaMail.zimbra@redhat.com>
	<704793002.13480640.1424703042016.JavaMail.zimbra@redhat.com>
	<54EB4A5B.6040201@redhat.com> <54EB50A8.6050702@redhat.com>
	<54EB5E2D.2070508@redhat.com> <54EB6211.4070306@redhat.com>
	<54EB62CC.1030305@redhat.com> <54EC9C8D.3060502@redhat.com>
Message-ID: <1707952867.14758524.1424842699877.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Summers Pittman" <supittma at redhat.com>
> To: "Stan Silvert" <ssilvert at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, February 24, 2015 4:45:17 PM
> Subject: Re: [keycloak-dev] WildFly integration (READ ME!)
> 
> On 02/23/2015 12:26 PM, Stan Silvert wrote:
> 
> 
> 
> On 2/23/2015 12:23 PM, Stan Silvert wrote:
> 
> 
> 
> On 2/23/2015 12:06 PM, Summers Pittman wrote:
> 
> 
> 
> On 02/23/2015 11:09 AM, Stan Silvert wrote:
> 
> 
> 
> On 2/23/2015 10:42 AM, Summers Pittman wrote:
> 
> 
> 
> On 02/23/2015 09:50 AM, Stian Thorgersen wrote:
> 
> 
> 
> Just to clarify we're only talking about the server, not adapters.
> 
> For the best and most friction free experience it would be best to have a
> dedicated Keycloak server, not to co-locate it with your JEE apps by
> deploying a WAR. With that regards we are considering dropping support for
> deploying Keycloak as a WAR.
> If I'm reading you correctly instead of
> 
> 
> 
> ~/WILDFLY_HOME/bin/startup.sh
> code
> 
> it will be
> 
> 
> 
> 
> 
> $WILDFLY_HOME/bin/startup.sh
> code
> #^@%! what broke in my auth
> waste 10 minutes
> $KEYCLOAK_HOME/bin/startup.sh
> I don't understand. What would break?
> I start developing after a reboot and KeyCloak's server isn't running. The
> auth is broken because the server isn't running because I forgot to start
> it.
> Sorry. Missed this response. My question to you is would having the ability
> to deploy your app on the Keycloak distribution be sufficient?
> No. I already have a Wildfly server which is part of my development process
> that I know how to deploy things to. I don't want to set up a second one.
> 
> If getting a deployable package is not an option and the only solution that
> is being entertained is a stand alone app server I will just containerize
> the thing, give it a host name alias and forget about it.

# docker run jboss/keycloak

That being said we may provide the option to install Keycloak into an existing WildFly (we'll probably only support the last version available at the time we release).

> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> By keeping it a separate war 1) I can download the thing faster and 2) I
> don't have to decide who to kick off of port 8080.
> I don't think we would do anything to ban you from deploying your apps in the
> same WildFly instance as Keycloak. Can you explain your concerns in more
> detail?
> My reading of the original email was that the standalone server would be the
> only distribution. IE there would be no more warfile distribution.
> Right. But it would be a distribution that has two modes. The modes would be
> standalone mode and a mode that would allow it to join a WildFly domain.
> 
> You could still deploy your applications to the Keycloak distribution. But
> for production, that's probably not what you want.
> 
> What I don't understand is what problems it would cause. Can you elaborate on
> that?
> 
> 
> 
> 
> 
> 
> 
> Again, IF I'm reading your message correctly
> 
> 
> 
> 
> That being said we still need to support embedding Keycloak in other
> projects. We plan to continue to support this through the mechanism UPS
> does, basically build-your-own auth-server.war.
> 
> ----- Original Message -----
> 
> 
> 
> From: "Summers Pittman" <supittma at redhat.com> To:
> keycloak-dev at lists.jboss.org Sent: Friday, February 20, 2015 7:10:12 PM
> Subject: Re: [keycloak-dev] WildFly integration (READ ME!)
> 
> On 02/20/2015 12:52 PM, Stan Silvert wrote:
> 
> 
> 
> On 2/20/2015 10:05 AM, Summers Pittman wrote:
> 
> 
> 
> On 02/19/2015 03:32 AM, Stian Thorgersen wrote:
> 
> 
> 
> No comments?!
> Peanut gallery chiming in; you asked for it ;)
> 
> I am not a WildFly developer or administrator.  So read this email as
> the opinions of a talented developer who loves the hell out of using
> KeyCloak and WildFly and sings its praises from the roof tops but has no
> idea what you are talking about.
> Thanks Summers.  Very valuable feedback.
> Thanks for taking the time to explain some things I know more than I did
> this morning.
> 
> 
> 
> 
> 
> 
> 
> ----- Original Message -----
> 
> 
> 
> From: "Stian Thorgersen" <stian at redhat.com> To: "keycloak dev"
> <keycloak-dev at lists.jboss.org> Sent: Tuesday, February 3, 2015 10:08:50 AM
> Subject: [keycloak-dev] WildFly integration (READ ME!)
> 
> All,
> 
> We have a few decisions to make in the not so far future. I'm away from
> Thursday, so let's have a hangout when I get back on the 17th February
> if
> that works for everyone.
> 
> The list of things to discuss includes:
> 
> * Drop keycloak-server.json - Should we drop our own configuration file
> and
> use DMR (standalone.xml)
> If on day one enabling KeyCloak in my project was any more complicated
> than dropping a pregenerated file into my WEB-INF directory I would have
> closed the project and never looked back.  -1
> We're talking about the auth server's config rather than the config for
> your project.   For projects, we want to make it even easier to the
> point where you don't even need the json file to get a default
> configuration.
> Ah, that makes more sense.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> * Keycloak CLI - Should we create our own or use WildFly CLI
> On the one hand the wildfly CLI is black magic.  On the other hand it is
> really well done black magic.  It is very hard to do CLIs well so I
> would like to see the wildfly CLI be used.
> That's the general feedback we often get from the WildFly community.  I
> agree.
> 
> 
> 
> 
> 
> 
> 
> * Admin operations exposed over DMR - Should we expose none, some or all
> admin operations over DMR? If we expose all should we deprecate the
> current
> REST endpoints?
> Is DMR the thing that puts stuff in the WildFly admin UI (I tried to
> read the google result for "wildfly DMR" but it quickly turned into
> turtles all the way down)?
> At its core, DMR is really just a tiny single-package library where the
> API is just 3 or 4 classes.  Those classes are the "language" spoken to
> make changes to the WildFly management model
> (standalone.xml/domain.xml).  So the question is whether we should hook
> into the management model infrastructure to make Keycloak changes.
> 
> 
> 
> In my experience I don't LIKE using the WildFly admin UI, I would rather
> use the CLI, scripts, etc.
> Also a typical response.  Again, I agree.  Thankfully, the Keycloak
> admin UI doesn't suffer from the same deficiencies as the WildFly admin UI.
> 
> But with Keycloak, we don't yet have a CLI, so there are lots of
> questions around whether we piggyback on WildFly CLI, which means
> adopting DMR in some way.
> 
> 
> 
> I haven't used the KeyCloak REST endpoints
> and keeping them just increases the attack surface.
> Do you mean that keeping the REST endpoints would be a good thing or a
> bad thing?  Can we hear more from you on this topic?
> I think that if there were a WildFly way to do all of the admin tasks
> that the RESTful endpoints do now it would be good to remove the RESTful
> API to decrease the API surface to just WildFly.  IE fewer things to
> worry about getting hacked and to watch for for vulnerabilities.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> * Packaging/distribution - How do we distribute Keycloak? Options:
>      - Full WildFly
>      - Core/web WildFly
>      - Overlay/installer/feature-pack to install to existing WF and EAP
>      - WAR bundle
> How about a shell script that examines a WF install directory and does
> all the magic for me or aDocker container?
> 
> In general I have not liked the experience of having wildfly bundled
> with a product.  It tends to mess with other servers I have installed
> and be a general PITA to maintain for anything more than the most
> trivial of demos.
> Good feedback.
> 
> 
> 
> 
> 
> 
> 
> * How should we deal with providers, themes and keycloak-server.json in
> domain-mode
> 
> * MSC all the way - We can deploy directly through the Undertow
> sub-system
> instead of deploying a WAR from the sub-system
> What is MSC?
> Modular Service Container.  It's the thing that lets you declare and
> register services in WildFly.  But I'm not completely sure what Stian is
> proposing here.
> 
> 
> 
> 
> 
> 
> 
> * Split sub-systems - Should we split the sub-system in two? One for the
> auth-server and another for the adapter
> What are the trade offs?  What will using KeyCloak look like from my POV
> if we split?
> Instead of
> 
> subsystem=keycloak/auth-server=main-auth-server
> subsystem=keycloak/secure-deployment=foo
> 
> you would have
> 
> subsystem=keycloak-server/auth-server=main-auth-server
> subsystem=keycloak-deployments/secure-deployment=foo
> 
> Another option would be to just leave it as it is today and just hide
> the "auth-server" resource for installations where you don't expect the
> auth server to run.
> 
> The answer will probably be more a function of how we want to organize
> the code rather than how it will look to the end user.
> As a end user it sounds like both work for me.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> * Deployable to other containers - Should it be possible to deploy
> Keycloak
> to Tomcat, Jetty, Fuse, etc..? One option could be to have reduced
> features
> in other containers (for example no client-cert)
> The awesomeness of WildFly has forever made web containers look
> insignificant to me.  If Glassfish still had a community edition worth a
> damn I would say target it as well.  I don't know how TomEE is but that
> may be good to support just for a "first one's free" to get people into
> WildFly land.
> 
> I don't think Websphere or WebLogic support has ever gotten anyone
> excited about a project.  Honestly they are the technology equivalent of
> taking a cold shower with grandma.
> I could have done without that image. :-|
> 
> But thanks again!
> YW.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Please add any other relevant topics.
> 
> Next big discussion I want to have is about distribution of adapters,
> but
> let's do one at a time ;)
> _______________________________________________
> 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
> --
> Summers Pittman
> 
> 
> 
> 
> 
> Phone:404 941 4698
> Java is my crack.
> _______________________________________________
> keycloak-dev mailing list keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 
> 
> 
> 
> --
> Summers Pittman
> >>Phone:404 941 4698
> >>Java is my crack.
> 
> 
> _______________________________________________
> 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
> 
> 
> --
> Summers Pittman
> >>Phone:404 941 4698
> >>Java is my crack.
> 
> 
> 
> _______________________________________________
> 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
> 
> 
> --
> Summers Pittman
> >>Phone:404 941 4698
> >>Java is my crack.
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev

From stian at redhat.com  Wed Feb 25 07:00:49 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 25 Feb 2015 07:00:49 -0500 (EST)
Subject: [keycloak-dev] Modules work
In-Reply-To: <1759658146.14922992.1424865545307.JavaMail.zimbra@redhat.com>
Message-ID: <2137478223.14924200.1424865649764.JavaMail.zimbra@redhat.com>

All dependencies are now loaded from modules. I've done some testing, but there may be issues remaining. 

If you get a ClassNotFound you'll know why ;)

From bgorai at cisco.com  Wed Feb 25 07:21:33 2015
From: bgorai at cisco.com (Bappaditya Gorai (bgorai))
Date: Wed, 25 Feb 2015 12:21:33 +0000
Subject: [keycloak-dev] Keycloak Clustering 1.1.0.Final - Getting
 infinispan type casting error (DefaultCacheContainer to
 EmbeddedCacheManager) in DefaultInfinispanConnectionProviderFactory
In-Reply-To: <54EC87A1.7080104@redhat.com>
References: <C5AF53298BAB5F4A88B28966E43B40AD0568A97A@xmb-aln-x12.cisco.com>
	<54EC87A1.7080104@redhat.com>
Message-ID: <C5AF53298BAB5F4A88B28966E43B40AD0568AA96@xmb-aln-x12.cisco.com>

Hi ,
Thanks for your response.

keycloak-war-dist 1.1.0.Final works for me too.

Actually I have custom application similar to "ups-auth-server" . In pom.xml I am using  "keycloak-dependencies-server-min" artifact  and added necessary infinispan related dependencies (keycloak-connections-infinispan, keycloak-model-sessions-infinispan, keycloak-invalidation-cache-infinispan).


Yes, I have added additional "infinispan-core" dependency in my pom.xml as jboss class loader was unable to find EmbeddedCacheManager.class .


I see in your pom.xml you are using "keycloak-dependencies-server-all" , do I need to use the same ( although I may not need all the dependencies)?

Thanks
Bappaditya Gorai

From: Marek Posolda [mailto:mposolda at redhat.com]
Sent: Tuesday, February 24, 2015 7:46 PM
To: Bappaditya Gorai (bgorai); keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] Keycloak Clustering 1.1.0.Final - Getting infinispan type casting error (DefaultCacheContainer to EmbeddedCacheManager) in DefaultInfinispanConnectionProviderFactory

Hi,

I can't reproduce the issue. It's strange as org.jboss.as.clustering.infinispan.DefaultCacheContainer is subclass of org.infinispan.manager.EmbeddedCacheManager. Didn't you do some packaging changes like adding infinispan jars to auth-server.war/WEB-INF/lib or something like that?

What I did for clustered Keycloak on EAP 6.3:

1) Unpack keycloak-war-dist 1.1.0.Final to my jboss-eap 6.3
2) Configured standalone/configuration/standalone-ha.xml and add this under infinispan subsystem:

 <cache-container name="keycloak" jndi-name="infinispan/Keycloak" start="EAGER">
  <transport lock-timeout="60000"/>
  <distributed-cache name="sessions" mode="SYNC" owners="2" segments="60"/>
  <distributed-cache name="loginFailures" mode="SYNC" owners="2" segments="60"/>
  <invalidation-cache name="realms" mode="SYNC"/>
  <invalidation-cache name="users"  mode="SYNC"/>
 </cache-container>

3) Configured standalone/configuration/keycloak-server.json and add this:

"connectionsInfinispan": {
    "default" : {
        "cacheContainer" : "java:jboss/infinispan/Keycloak"
    }
}

and also switch realmCache, userCache and userSessions to use: "provider": "infinispan"

4) Then run server with command:
./standalone.sh -c standalone-ha.xml

Let me know if these steps work for you.

Marek

On 24.2.2015 14:07, Bappaditya Gorai (bgorai) wrote:
In my standalone configuration file I am using following subsystem version for infinispan, not sure whether it has any relevance to my issue.

<subsystem xmlns="urn:jboss:domain:infinispan:1.5">

Thanks
Bappaditya Gorai

From: Bappaditya Gorai (bgorai)
Sent: Monday, February 23, 2015 2:46 PM
To: keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
Subject: Keycloak Clustering 1.1.0.Final - Getting infinispan type casting error (DefaultCacheContainer to EmbeddedCacheManager) in DefaultInfinispanConnectionProviderFactory

Hi Team,

I am trying  configure  Keycloak in clustered environment (EAP 6.3), however getting following error (stack trace is provided below) . I have followed instructions provided in "Chapter 24. Clustering" in Keycloak Guide (http://docs.jboss.org/keycloak/docs/1.1.0.Final/userguide/html/clustering.html). Let me know if I am missing something.


13:23:25,681 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth]] (ServerService Thread Pool -- 62) JBWEB000289: Servlet Keycloak REST Interface threw load() exception: java.lang.ClassCastException: org.jboss.as.clustering.infinispan.DefaultCacheContainer cannot be cast to org.infinispan.manager.EmbeddedCacheManager
        at org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory.initContainerManaged(DefaultInfinispanConnectionProviderFactory.java:70) [keycloak-connections-infinispan-1.1.0.Final.jar:1.1.0.Final]
        at org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory.lazyInit(DefaultInfinispanConnectionProviderFactory.java:59) [keycloak-connections-infinispan-1.1.0.Final.jar:1.1.0.Final]
        at org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory.create(DefaultInfinispanConnectionProviderFactory.java:30) [keycloak-connections-infinispan-1.1.0.Final.jar:1.1.0.Final]
        at org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory.create(DefaultInfinispanConnectionProviderFactory.java:18) [keycloak-connections-infinispan-1.1.0.Final.jar:1.1.0.Final]



Thanks
Bappaditya Gorai




_______________________________________________

keycloak-dev mailing list

keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>

https://lists.jboss.org/mailman/listinfo/keycloak-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150225/f8f47afb/attachment.html 

From supittma at redhat.com  Wed Feb 25 07:52:50 2015
From: supittma at redhat.com (Summers Pittman)
Date: Wed, 25 Feb 2015 07:52:50 -0500
Subject: [keycloak-dev] WildFly integration (READ ME!)
In-Reply-To: <1707952867.14758524.1424842699877.JavaMail.zimbra@redhat.com>
References: <969708031.6108771.1422954530044.JavaMail.zimbra@redhat.com>
	<704793002.13480640.1424703042016.JavaMail.zimbra@redhat.com>
	<54EB4A5B.6040201@redhat.com> <54EB50A8.6050702@redhat.com>
	<54EB5E2D.2070508@redhat.com> <54EB6211.4070306@redhat.com>
	<54EB62CC.1030305@redhat.com> <54EC9C8D.3060502@redhat.com>
	<1707952867.14758524.1424842699877.JavaMail.zimbra@redhat.com>
Message-ID: <54EDC5A2.3080200@redhat.com>

On 02/25/2015 12:38 AM, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Summers Pittman" <supittma at redhat.com>
>> To: "Stan Silvert" <ssilvert at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, February 24, 2015 4:45:17 PM
>> Subject: Re: [keycloak-dev] WildFly integration (READ ME!)
>>
>> On 02/23/2015 12:26 PM, Stan Silvert wrote:
>>
>>
>>
>> On 2/23/2015 12:23 PM, Stan Silvert wrote:
>>
>>
>>
>> On 2/23/2015 12:06 PM, Summers Pittman wrote:
>>
>>
>>
>> On 02/23/2015 11:09 AM, Stan Silvert wrote:
>>
>>
>>
>> On 2/23/2015 10:42 AM, Summers Pittman wrote:
>>
>>
>>
>> On 02/23/2015 09:50 AM, Stian Thorgersen wrote:
>>
>>
>>
>> Just to clarify we're only talking about the server, not adapters.
>>
>> For the best and most friction free experience it would be best to have a
>> dedicated Keycloak server, not to co-locate it with your JEE apps by
>> deploying a WAR. With that regards we are considering dropping support for
>> deploying Keycloak as a WAR.
>> If I'm reading you correctly instead of
>>
>>
>>
>> ~/WILDFLY_HOME/bin/startup.sh
>> code
>>
>> it will be
>>
>>
>>
>>
>>
>> $WILDFLY_HOME/bin/startup.sh
>> code
>> #^@%! what broke in my auth
>> waste 10 minutes
>> $KEYCLOAK_HOME/bin/startup.sh
>> I don't understand. What would break?
>> I start developing after a reboot and KeyCloak's server isn't running. The
>> auth is broken because the server isn't running because I forgot to start
>> it.
>> Sorry. Missed this response. My question to you is would having the ability
>> to deploy your app on the Keycloak distribution be sufficient?
>> No. I already have a Wildfly server which is part of my development process
>> that I know how to deploy things to. I don't want to set up a second one.
>>
>> If getting a deployable package is not an option and the only solution that
>> is being entertained is a stand alone app server I will just containerize
>> the thing, give it a host name alias and forget about it.
> # docker run jboss/keycloak
>
> That being said we may provide the option to install Keycloak into an existing WildFly (we'll probably only support the last version available at the time we release).
I understand you are trying to be glib, but there ARE issues with this.  
First off getting a realm.json file OUT of a docker container is nigh 
impossible, secondly the default configuration will lose all of your 
data when it is restarted, and third on non Linux systems docker support 
is pretty terrible.  Data volumes do not work on Mac OS X out of the box 
for example.
>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> By keeping it a separate war 1) I can download the thing faster and 2) I
>> don't have to decide who to kick off of port 8080.
>> I don't think we would do anything to ban you from deploying your apps in the
>> same WildFly instance as Keycloak. Can you explain your concerns in more
>> detail?
>> My reading of the original email was that the standalone server would be the
>> only distribution. IE there would be no more warfile distribution.
>> Right. But it would be a distribution that has two modes. The modes would be
>> standalone mode and a mode that would allow it to join a WildFly domain.
>>
>> You could still deploy your applications to the Keycloak distribution. But
>> for production, that's probably not what you want.
>>
>> What I don't understand is what problems it would cause. Can you elaborate on
>> that?
>>
>>
>>
>>
>>
>>
>>
>> Again, IF I'm reading your message correctly
>>
>>
>>
>>
>> That being said we still need to support embedding Keycloak in other
>> projects. We plan to continue to support this through the mechanism UPS
>> does, basically build-your-own auth-server.war.
>>
>> ----- Original Message -----
>>
>>
>>
>> From: "Summers Pittman" <supittma at redhat.com> To:
>> keycloak-dev at lists.jboss.org Sent: Friday, February 20, 2015 7:10:12 PM
>> Subject: Re: [keycloak-dev] WildFly integration (READ ME!)
>>
>> On 02/20/2015 12:52 PM, Stan Silvert wrote:
>>
>>
>>
>> On 2/20/2015 10:05 AM, Summers Pittman wrote:
>>
>>
>>
>> On 02/19/2015 03:32 AM, Stian Thorgersen wrote:
>>
>>
>>
>> No comments?!
>> Peanut gallery chiming in; you asked for it ;)
>>
>> I am not a WildFly developer or administrator.  So read this email as
>> the opinions of a talented developer who loves the hell out of using
>> KeyCloak and WildFly and sings its praises from the roof tops but has no
>> idea what you are talking about.
>> Thanks Summers.  Very valuable feedback.
>> Thanks for taking the time to explain some things I know more than I did
>> this morning.
>>
>>
>>
>>
>>
>>
>>
>> ----- Original Message -----
>>
>>
>>
>> From: "Stian Thorgersen" <stian at redhat.com> To: "keycloak dev"
>> <keycloak-dev at lists.jboss.org> Sent: Tuesday, February 3, 2015 10:08:50 AM
>> Subject: [keycloak-dev] WildFly integration (READ ME!)
>>
>> All,
>>
>> We have a few decisions to make in the not so far future. I'm away from
>> Thursday, so let's have a hangout when I get back on the 17th February
>> if
>> that works for everyone.
>>
>> The list of things to discuss includes:
>>
>> * Drop keycloak-server.json - Should we drop our own configuration file
>> and
>> use DMR (standalone.xml)
>> If on day one enabling KeyCloak in my project was any more complicated
>> than dropping a pregenerated file into my WEB-INF directory I would have
>> closed the project and never looked back.  -1
>> We're talking about the auth server's config rather than the config for
>> your project.   For projects, we want to make it even easier to the
>> point where you don't even need the json file to get a default
>> configuration.
>> Ah, that makes more sense.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> * Keycloak CLI - Should we create our own or use WildFly CLI
>> On the one hand the wildfly CLI is black magic.  On the other hand it is
>> really well done black magic.  It is very hard to do CLIs well so I
>> would like to see the wildfly CLI be used.
>> That's the general feedback we often get from the WildFly community.  I
>> agree.
>>
>>
>>
>>
>>
>>
>>
>> * Admin operations exposed over DMR - Should we expose none, some or all
>> admin operations over DMR? If we expose all should we deprecate the
>> current
>> REST endpoints?
>> Is DMR the thing that puts stuff in the WildFly admin UI (I tried to
>> read the google result for "wildfly DMR" but it quickly turned into
>> turtles all the way down)?
>> At its core, DMR is really just a tiny single-package library where the
>> API is just 3 or 4 classes.  Those classes are the "language" spoken to
>> make changes to the WildFly management model
>> (standalone.xml/domain.xml).  So the question is whether we should hook
>> into the management model infrastructure to make Keycloak changes.
>>
>>
>>
>> In my experience I don't LIKE using the WildFly admin UI, I would rather
>> use the CLI, scripts, etc.
>> Also a typical response.  Again, I agree.  Thankfully, the Keycloak
>> admin UI doesn't suffer from the same deficiencies as the WildFly admin UI.
>>
>> But with Keycloak, we don't yet have a CLI, so there are lots of
>> questions around whether we piggyback on WildFly CLI, which means
>> adopting DMR in some way.
>>
>>
>>
>> I haven't used the KeyCloak REST endpoints
>> and keeping them just increases the attack surface.
>> Do you mean that keeping the REST endpoints would be a good thing or a
>> bad thing?  Can we hear more from you on this topic?
>> I think that if there were a WildFly way to do all of the admin tasks
>> that the RESTful endpoints do now it would be good to remove the RESTful
>> API to decrease the API surface to just WildFly.  IE fewer things to
>> worry about getting hacked and to watch for for vulnerabilities.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> * Packaging/distribution - How do we distribute Keycloak? Options:
>>       - Full WildFly
>>       - Core/web WildFly
>>       - Overlay/installer/feature-pack to install to existing WF and EAP
>>       - WAR bundle
>> How about a shell script that examines a WF install directory and does
>> all the magic for me or aDocker container?
>>
>> In general I have not liked the experience of having wildfly bundled
>> with a product.  It tends to mess with other servers I have installed
>> and be a general PITA to maintain for anything more than the most
>> trivial of demos.
>> Good feedback.
>>
>>
>>
>>
>>
>>
>>
>> * How should we deal with providers, themes and keycloak-server.json in
>> domain-mode
>>
>> * MSC all the way - We can deploy directly through the Undertow
>> sub-system
>> instead of deploying a WAR from the sub-system
>> What is MSC?
>> Modular Service Container.  It's the thing that lets you declare and
>> register services in WildFly.  But I'm not completely sure what Stian is
>> proposing here.
>>
>>
>>
>>
>>
>>
>>
>> * Split sub-systems - Should we split the sub-system in two? One for the
>> auth-server and another for the adapter
>> What are the trade offs?  What will using KeyCloak look like from my POV
>> if we split?
>> Instead of
>>
>> subsystem=keycloak/auth-server=main-auth-server
>> subsystem=keycloak/secure-deployment=foo
>>
>> you would have
>>
>> subsystem=keycloak-server/auth-server=main-auth-server
>> subsystem=keycloak-deployments/secure-deployment=foo
>>
>> Another option would be to just leave it as it is today and just hide
>> the "auth-server" resource for installations where you don't expect the
>> auth server to run.
>>
>> The answer will probably be more a function of how we want to organize
>> the code rather than how it will look to the end user.
>> As a end user it sounds like both work for me.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> * Deployable to other containers - Should it be possible to deploy
>> Keycloak
>> to Tomcat, Jetty, Fuse, etc..? One option could be to have reduced
>> features
>> in other containers (for example no client-cert)
>> The awesomeness of WildFly has forever made web containers look
>> insignificant to me.  If Glassfish still had a community edition worth a
>> damn I would say target it as well.  I don't know how TomEE is but that
>> may be good to support just for a "first one's free" to get people into
>> WildFly land.
>>
>> I don't think Websphere or WebLogic support has ever gotten anyone
>> excited about a project.  Honestly they are the technology equivalent of
>> taking a cold shower with grandma.
>> I could have done without that image. :-|
>>
>> But thanks again!
>> YW.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Please add any other relevant topics.
>>
>> Next big discussion I want to have is about distribution of adapters,
>> but
>> let's do one at a time ;)
>> _______________________________________________
>> 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
>> --
>> Summers Pittman
>>
>>
>>
>>
>>
>> Phone:404 941 4698
>> Java is my crack.
>> _______________________________________________
>> keycloak-dev mailing list keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>>
>>
>> --
>> Summers Pittman
>>>> Phone:404 941 4698
>>>> Java is my crack.
>>
>> _______________________________________________
>> 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
>>
>>
>> --
>> Summers Pittman
>>>> Phone:404 941 4698
>>>> Java is my crack.
>>
>>
>> _______________________________________________
>> 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
>>
>>
>> --
>> Summers Pittman
>>>> Phone:404 941 4698
>>>> Java is my crack.
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev


-- 
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.


From stian at redhat.com  Wed Feb 25 08:08:21 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 25 Feb 2015 08:08:21 -0500 (EST)
Subject: [keycloak-dev] WildFly integration (READ ME!)
In-Reply-To: <54EDC5A2.3080200@redhat.com>
References: <969708031.6108771.1422954530044.JavaMail.zimbra@redhat.com>
	<54EB50A8.6050702@redhat.com> <54EB5E2D.2070508@redhat.com>
	<54EB6211.4070306@redhat.com> <54EB62CC.1030305@redhat.com>
	<54EC9C8D.3060502@redhat.com>
	<1707952867.14758524.1424842699877.JavaMail.zimbra@redhat.com>
	<54EDC5A2.3080200@redhat.com>
Message-ID: <1733576361.14974701.1424869701637.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Summers Pittman" <supittma at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Stan Silvert" <ssilvert at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Wednesday, February 25, 2015 1:52:50 PM
> Subject: Re: [keycloak-dev] WildFly integration (READ ME!)
> 
> On 02/25/2015 12:38 AM, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Summers Pittman" <supittma at redhat.com>
> >> To: "Stan Silvert" <ssilvert at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, February 24, 2015 4:45:17 PM
> >> Subject: Re: [keycloak-dev] WildFly integration (READ ME!)
> >>
> >> On 02/23/2015 12:26 PM, Stan Silvert wrote:
> >>
> >>
> >>
> >> On 2/23/2015 12:23 PM, Stan Silvert wrote:
> >>
> >>
> >>
> >> On 2/23/2015 12:06 PM, Summers Pittman wrote:
> >>
> >>
> >>
> >> On 02/23/2015 11:09 AM, Stan Silvert wrote:
> >>
> >>
> >>
> >> On 2/23/2015 10:42 AM, Summers Pittman wrote:
> >>
> >>
> >>
> >> On 02/23/2015 09:50 AM, Stian Thorgersen wrote:
> >>
> >>
> >>
> >> Just to clarify we're only talking about the server, not adapters.
> >>
> >> For the best and most friction free experience it would be best to have a
> >> dedicated Keycloak server, not to co-locate it with your JEE apps by
> >> deploying a WAR. With that regards we are considering dropping support for
> >> deploying Keycloak as a WAR.
> >> If I'm reading you correctly instead of
> >>
> >>
> >>
> >> ~/WILDFLY_HOME/bin/startup.sh
> >> code
> >>
> >> it will be
> >>
> >>
> >>
> >>
> >>
> >> $WILDFLY_HOME/bin/startup.sh
> >> code
> >> #^@%! what broke in my auth
> >> waste 10 minutes
> >> $KEYCLOAK_HOME/bin/startup.sh
> >> I don't understand. What would break?
> >> I start developing after a reboot and KeyCloak's server isn't running. The
> >> auth is broken because the server isn't running because I forgot to start
> >> it.
> >> Sorry. Missed this response. My question to you is would having the
> >> ability
> >> to deploy your app on the Keycloak distribution be sufficient?
> >> No. I already have a Wildfly server which is part of my development
> >> process
> >> that I know how to deploy things to. I don't want to set up a second one.
> >>
> >> If getting a deployable package is not an option and the only solution
> >> that
> >> is being entertained is a stand alone app server I will just containerize
> >> the thing, give it a host name alias and forget about it.
> > # docker run jboss/keycloak
> >
> > That being said we may provide the option to install Keycloak into an
> > existing WildFly (we'll probably only support the last version available
> > at the time we release).
> I understand you are trying to be glib, but there ARE issues with this.
> First off getting a realm.json file OUT of a docker container is nigh
> impossible, secondly the default configuration will lose all of your
> data when it is restarted, and third on non Linux systems docker support
> is pretty terrible.  Data volumes do not work on Mac OS X out of the box
> for example.

I forgot irony doesn't translate well on email, sorry!

The real answer was that we're probably going to provide an option to easily install Keycloak into an existing WildFly ;)

> >
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> By keeping it a separate war 1) I can download the thing faster and 2) I
> >> don't have to decide who to kick off of port 8080.
> >> I don't think we would do anything to ban you from deploying your apps in
> >> the
> >> same WildFly instance as Keycloak. Can you explain your concerns in more
> >> detail?
> >> My reading of the original email was that the standalone server would be
> >> the
> >> only distribution. IE there would be no more warfile distribution.
> >> Right. But it would be a distribution that has two modes. The modes would
> >> be
> >> standalone mode and a mode that would allow it to join a WildFly domain.
> >>
> >> You could still deploy your applications to the Keycloak distribution. But
> >> for production, that's probably not what you want.
> >>
> >> What I don't understand is what problems it would cause. Can you elaborate
> >> on
> >> that?
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> Again, IF I'm reading your message correctly
> >>
> >>
> >>
> >>
> >> That being said we still need to support embedding Keycloak in other
> >> projects. We plan to continue to support this through the mechanism UPS
> >> does, basically build-your-own auth-server.war.
> >>
> >> ----- Original Message -----
> >>
> >>
> >>
> >> From: "Summers Pittman" <supittma at redhat.com> To:
> >> keycloak-dev at lists.jboss.org Sent: Friday, February 20, 2015 7:10:12 PM
> >> Subject: Re: [keycloak-dev] WildFly integration (READ ME!)
> >>
> >> On 02/20/2015 12:52 PM, Stan Silvert wrote:
> >>
> >>
> >>
> >> On 2/20/2015 10:05 AM, Summers Pittman wrote:
> >>
> >>
> >>
> >> On 02/19/2015 03:32 AM, Stian Thorgersen wrote:
> >>
> >>
> >>
> >> No comments?!
> >> Peanut gallery chiming in; you asked for it ;)
> >>
> >> I am not a WildFly developer or administrator.  So read this email as
> >> the opinions of a talented developer who loves the hell out of using
> >> KeyCloak and WildFly and sings its praises from the roof tops but has no
> >> idea what you are talking about.
> >> Thanks Summers.  Very valuable feedback.
> >> Thanks for taking the time to explain some things I know more than I did
> >> this morning.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> ----- Original Message -----
> >>
> >>
> >>
> >> From: "Stian Thorgersen" <stian at redhat.com> To: "keycloak dev"
> >> <keycloak-dev at lists.jboss.org> Sent: Tuesday, February 3, 2015 10:08:50 AM
> >> Subject: [keycloak-dev] WildFly integration (READ ME!)
> >>
> >> All,
> >>
> >> We have a few decisions to make in the not so far future. I'm away from
> >> Thursday, so let's have a hangout when I get back on the 17th February
> >> if
> >> that works for everyone.
> >>
> >> The list of things to discuss includes:
> >>
> >> * Drop keycloak-server.json - Should we drop our own configuration file
> >> and
> >> use DMR (standalone.xml)
> >> If on day one enabling KeyCloak in my project was any more complicated
> >> than dropping a pregenerated file into my WEB-INF directory I would have
> >> closed the project and never looked back.  -1
> >> We're talking about the auth server's config rather than the config for
> >> your project.   For projects, we want to make it even easier to the
> >> point where you don't even need the json file to get a default
> >> configuration.
> >> Ah, that makes more sense.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> * Keycloak CLI - Should we create our own or use WildFly CLI
> >> On the one hand the wildfly CLI is black magic.  On the other hand it is
> >> really well done black magic.  It is very hard to do CLIs well so I
> >> would like to see the wildfly CLI be used.
> >> That's the general feedback we often get from the WildFly community.  I
> >> agree.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> * Admin operations exposed over DMR - Should we expose none, some or all
> >> admin operations over DMR? If we expose all should we deprecate the
> >> current
> >> REST endpoints?
> >> Is DMR the thing that puts stuff in the WildFly admin UI (I tried to
> >> read the google result for "wildfly DMR" but it quickly turned into
> >> turtles all the way down)?
> >> At its core, DMR is really just a tiny single-package library where the
> >> API is just 3 or 4 classes.  Those classes are the "language" spoken to
> >> make changes to the WildFly management model
> >> (standalone.xml/domain.xml).  So the question is whether we should hook
> >> into the management model infrastructure to make Keycloak changes.
> >>
> >>
> >>
> >> In my experience I don't LIKE using the WildFly admin UI, I would rather
> >> use the CLI, scripts, etc.
> >> Also a typical response.  Again, I agree.  Thankfully, the Keycloak
> >> admin UI doesn't suffer from the same deficiencies as the WildFly admin
> >> UI.
> >>
> >> But with Keycloak, we don't yet have a CLI, so there are lots of
> >> questions around whether we piggyback on WildFly CLI, which means
> >> adopting DMR in some way.
> >>
> >>
> >>
> >> I haven't used the KeyCloak REST endpoints
> >> and keeping them just increases the attack surface.
> >> Do you mean that keeping the REST endpoints would be a good thing or a
> >> bad thing?  Can we hear more from you on this topic?
> >> I think that if there were a WildFly way to do all of the admin tasks
> >> that the RESTful endpoints do now it would be good to remove the RESTful
> >> API to decrease the API surface to just WildFly.  IE fewer things to
> >> worry about getting hacked and to watch for for vulnerabilities.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> * Packaging/distribution - How do we distribute Keycloak? Options:
> >>       - Full WildFly
> >>       - Core/web WildFly
> >>       - Overlay/installer/feature-pack to install to existing WF and EAP
> >>       - WAR bundle
> >> How about a shell script that examines a WF install directory and does
> >> all the magic for me or aDocker container?
> >>
> >> In general I have not liked the experience of having wildfly bundled
> >> with a product.  It tends to mess with other servers I have installed
> >> and be a general PITA to maintain for anything more than the most
> >> trivial of demos.
> >> Good feedback.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> * How should we deal with providers, themes and keycloak-server.json in
> >> domain-mode
> >>
> >> * MSC all the way - We can deploy directly through the Undertow
> >> sub-system
> >> instead of deploying a WAR from the sub-system
> >> What is MSC?
> >> Modular Service Container.  It's the thing that lets you declare and
> >> register services in WildFly.  But I'm not completely sure what Stian is
> >> proposing here.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> * Split sub-systems - Should we split the sub-system in two? One for the
> >> auth-server and another for the adapter
> >> What are the trade offs?  What will using KeyCloak look like from my POV
> >> if we split?
> >> Instead of
> >>
> >> subsystem=keycloak/auth-server=main-auth-server
> >> subsystem=keycloak/secure-deployment=foo
> >>
> >> you would have
> >>
> >> subsystem=keycloak-server/auth-server=main-auth-server
> >> subsystem=keycloak-deployments/secure-deployment=foo
> >>
> >> Another option would be to just leave it as it is today and just hide
> >> the "auth-server" resource for installations where you don't expect the
> >> auth server to run.
> >>
> >> The answer will probably be more a function of how we want to organize
> >> the code rather than how it will look to the end user.
> >> As a end user it sounds like both work for me.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> * Deployable to other containers - Should it be possible to deploy
> >> Keycloak
> >> to Tomcat, Jetty, Fuse, etc..? One option could be to have reduced
> >> features
> >> in other containers (for example no client-cert)
> >> The awesomeness of WildFly has forever made web containers look
> >> insignificant to me.  If Glassfish still had a community edition worth a
> >> damn I would say target it as well.  I don't know how TomEE is but that
> >> may be good to support just for a "first one's free" to get people into
> >> WildFly land.
> >>
> >> I don't think Websphere or WebLogic support has ever gotten anyone
> >> excited about a project.  Honestly they are the technology equivalent of
> >> taking a cold shower with grandma.
> >> I could have done without that image. :-|
> >>
> >> But thanks again!
> >> YW.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> Please add any other relevant topics.
> >>
> >> Next big discussion I want to have is about distribution of adapters,
> >> but
> >> let's do one at a time ;)
> >> _______________________________________________
> >> 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
> >> --
> >> Summers Pittman
> >>
> >>
> >>
> >>
> >>
> >> Phone:404 941 4698
> >> Java is my crack.
> >> _______________________________________________
> >> keycloak-dev mailing list keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> >>
> >>
> >>
> >>
> >> --
> >> Summers Pittman
> >>>> Phone:404 941 4698
> >>>> Java is my crack.
> >>
> >> _______________________________________________
> >> 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
> >>
> >>
> >> --
> >> Summers Pittman
> >>>> Phone:404 941 4698
> >>>> Java is my crack.
> >>
> >>
> >> _______________________________________________
> >> 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
> >>
> >>
> >> --
> >> Summers Pittman
> >>>> Phone:404 941 4698
> >>>> Java is my crack.
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 
> --
> Summers Pittman
> >>Phone:404 941 4698
> >>Java is my crack.
> 
> 

From supittma at redhat.com  Wed Feb 25 08:08:56 2015
From: supittma at redhat.com (Summers Pittman)
Date: Wed, 25 Feb 2015 08:08:56 -0500
Subject: [keycloak-dev] WildFly integration (READ ME!)
In-Reply-To: <1733576361.14974701.1424869701637.JavaMail.zimbra@redhat.com>
References: <969708031.6108771.1422954530044.JavaMail.zimbra@redhat.com>
	<54EB50A8.6050702@redhat.com> <54EB5E2D.2070508@redhat.com>
	<54EB6211.4070306@redhat.com> <54EB62CC.1030305@redhat.com>
	<54EC9C8D.3060502@redhat.com>
	<1707952867.14758524.1424842699877.JavaMail.zimbra@redhat.com>
	<54EDC5A2.3080200@redhat.com>
	<1733576361.14974701.1424869701637.JavaMail.zimbra@redhat.com>
Message-ID: <54EDC968.3040600@redhat.com>

On 02/25/2015 08:08 AM, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Summers Pittman" <supittma at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: "Stan Silvert" <ssilvert at redhat.com>, keycloak-dev at lists.jboss.org
>> Sent: Wednesday, February 25, 2015 1:52:50 PM
>> Subject: Re: [keycloak-dev] WildFly integration (READ ME!)
>>
>> On 02/25/2015 12:38 AM, Stian Thorgersen wrote:
>>> ----- Original Message -----
>>>> From: "Summers Pittman" <supittma at redhat.com>
>>>> To: "Stan Silvert" <ssilvert at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Tuesday, February 24, 2015 4:45:17 PM
>>>> Subject: Re: [keycloak-dev] WildFly integration (READ ME!)
>>>>
>>>> On 02/23/2015 12:26 PM, Stan Silvert wrote:
>>>>
>>>>
>>>>
>>>> On 2/23/2015 12:23 PM, Stan Silvert wrote:
>>>>
>>>>
>>>>
>>>> On 2/23/2015 12:06 PM, Summers Pittman wrote:
>>>>
>>>>
>>>>
>>>> On 02/23/2015 11:09 AM, Stan Silvert wrote:
>>>>
>>>>
>>>>
>>>> On 2/23/2015 10:42 AM, Summers Pittman wrote:
>>>>
>>>>
>>>>
>>>> On 02/23/2015 09:50 AM, Stian Thorgersen wrote:
>>>>
>>>>
>>>>
>>>> Just to clarify we're only talking about the server, not adapters.
>>>>
>>>> For the best and most friction free experience it would be best to have a
>>>> dedicated Keycloak server, not to co-locate it with your JEE apps by
>>>> deploying a WAR. With that regards we are considering dropping support for
>>>> deploying Keycloak as a WAR.
>>>> If I'm reading you correctly instead of
>>>>
>>>>
>>>>
>>>> ~/WILDFLY_HOME/bin/startup.sh
>>>> code
>>>>
>>>> it will be
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> $WILDFLY_HOME/bin/startup.sh
>>>> code
>>>> #^@%! what broke in my auth
>>>> waste 10 minutes
>>>> $KEYCLOAK_HOME/bin/startup.sh
>>>> I don't understand. What would break?
>>>> I start developing after a reboot and KeyCloak's server isn't running. The
>>>> auth is broken because the server isn't running because I forgot to start
>>>> it.
>>>> Sorry. Missed this response. My question to you is would having the
>>>> ability
>>>> to deploy your app on the Keycloak distribution be sufficient?
>>>> No. I already have a Wildfly server which is part of my development
>>>> process
>>>> that I know how to deploy things to. I don't want to set up a second one.
>>>>
>>>> If getting a deployable package is not an option and the only solution
>>>> that
>>>> is being entertained is a stand alone app server I will just containerize
>>>> the thing, give it a host name alias and forget about it.
>>> # docker run jboss/keycloak
>>>
>>> That being said we may provide the option to install Keycloak into an
>>> existing WildFly (we'll probably only support the last version available
>>> at the time we release).
>> I understand you are trying to be glib, but there ARE issues with this.
>> First off getting a realm.json file OUT of a docker container is nigh
>> impossible, secondly the default configuration will lose all of your
>> data when it is restarted, and third on non Linux systems docker support
>> is pretty terrible.  Data volumes do not work on Mac OS X out of the box
>> for example.
> I forgot irony doesn't translate well on email, sorry!
>
> The real answer was that we're probably going to provide an option to easily install Keycloak into an existing WildFly ;)
+1
>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> By keeping it a separate war 1) I can download the thing faster and 2) I
>>>> don't have to decide who to kick off of port 8080.
>>>> I don't think we would do anything to ban you from deploying your apps in
>>>> the
>>>> same WildFly instance as Keycloak. Can you explain your concerns in more
>>>> detail?
>>>> My reading of the original email was that the standalone server would be
>>>> the
>>>> only distribution. IE there would be no more warfile distribution.
>>>> Right. But it would be a distribution that has two modes. The modes would
>>>> be
>>>> standalone mode and a mode that would allow it to join a WildFly domain.
>>>>
>>>> You could still deploy your applications to the Keycloak distribution. But
>>>> for production, that's probably not what you want.
>>>>
>>>> What I don't understand is what problems it would cause. Can you elaborate
>>>> on
>>>> that?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Again, IF I'm reading your message correctly
>>>>
>>>>
>>>>
>>>>
>>>> That being said we still need to support embedding Keycloak in other
>>>> projects. We plan to continue to support this through the mechanism UPS
>>>> does, basically build-your-own auth-server.war.
>>>>
>>>> ----- Original Message -----
>>>>
>>>>
>>>>
>>>> From: "Summers Pittman" <supittma at redhat.com> To:
>>>> keycloak-dev at lists.jboss.org Sent: Friday, February 20, 2015 7:10:12 PM
>>>> Subject: Re: [keycloak-dev] WildFly integration (READ ME!)
>>>>
>>>> On 02/20/2015 12:52 PM, Stan Silvert wrote:
>>>>
>>>>
>>>>
>>>> On 2/20/2015 10:05 AM, Summers Pittman wrote:
>>>>
>>>>
>>>>
>>>> On 02/19/2015 03:32 AM, Stian Thorgersen wrote:
>>>>
>>>>
>>>>
>>>> No comments?!
>>>> Peanut gallery chiming in; you asked for it ;)
>>>>
>>>> I am not a WildFly developer or administrator.  So read this email as
>>>> the opinions of a talented developer who loves the hell out of using
>>>> KeyCloak and WildFly and sings its praises from the roof tops but has no
>>>> idea what you are talking about.
>>>> Thanks Summers.  Very valuable feedback.
>>>> Thanks for taking the time to explain some things I know more than I did
>>>> this morning.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>
>>>>
>>>>
>>>> From: "Stian Thorgersen" <stian at redhat.com> To: "keycloak dev"
>>>> <keycloak-dev at lists.jboss.org> Sent: Tuesday, February 3, 2015 10:08:50 AM
>>>> Subject: [keycloak-dev] WildFly integration (READ ME!)
>>>>
>>>> All,
>>>>
>>>> We have a few decisions to make in the not so far future. I'm away from
>>>> Thursday, so let's have a hangout when I get back on the 17th February
>>>> if
>>>> that works for everyone.
>>>>
>>>> The list of things to discuss includes:
>>>>
>>>> * Drop keycloak-server.json - Should we drop our own configuration file
>>>> and
>>>> use DMR (standalone.xml)
>>>> If on day one enabling KeyCloak in my project was any more complicated
>>>> than dropping a pregenerated file into my WEB-INF directory I would have
>>>> closed the project and never looked back.  -1
>>>> We're talking about the auth server's config rather than the config for
>>>> your project.   For projects, we want to make it even easier to the
>>>> point where you don't even need the json file to get a default
>>>> configuration.
>>>> Ah, that makes more sense.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> * Keycloak CLI - Should we create our own or use WildFly CLI
>>>> On the one hand the wildfly CLI is black magic.  On the other hand it is
>>>> really well done black magic.  It is very hard to do CLIs well so I
>>>> would like to see the wildfly CLI be used.
>>>> That's the general feedback we often get from the WildFly community.  I
>>>> agree.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> * Admin operations exposed over DMR - Should we expose none, some or all
>>>> admin operations over DMR? If we expose all should we deprecate the
>>>> current
>>>> REST endpoints?
>>>> Is DMR the thing that puts stuff in the WildFly admin UI (I tried to
>>>> read the google result for "wildfly DMR" but it quickly turned into
>>>> turtles all the way down)?
>>>> At its core, DMR is really just a tiny single-package library where the
>>>> API is just 3 or 4 classes.  Those classes are the "language" spoken to
>>>> make changes to the WildFly management model
>>>> (standalone.xml/domain.xml).  So the question is whether we should hook
>>>> into the management model infrastructure to make Keycloak changes.
>>>>
>>>>
>>>>
>>>> In my experience I don't LIKE using the WildFly admin UI, I would rather
>>>> use the CLI, scripts, etc.
>>>> Also a typical response.  Again, I agree.  Thankfully, the Keycloak
>>>> admin UI doesn't suffer from the same deficiencies as the WildFly admin
>>>> UI.
>>>>
>>>> But with Keycloak, we don't yet have a CLI, so there are lots of
>>>> questions around whether we piggyback on WildFly CLI, which means
>>>> adopting DMR in some way.
>>>>
>>>>
>>>>
>>>> I haven't used the KeyCloak REST endpoints
>>>> and keeping them just increases the attack surface.
>>>> Do you mean that keeping the REST endpoints would be a good thing or a
>>>> bad thing?  Can we hear more from you on this topic?
>>>> I think that if there were a WildFly way to do all of the admin tasks
>>>> that the RESTful endpoints do now it would be good to remove the RESTful
>>>> API to decrease the API surface to just WildFly.  IE fewer things to
>>>> worry about getting hacked and to watch for for vulnerabilities.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> * Packaging/distribution - How do we distribute Keycloak? Options:
>>>>        - Full WildFly
>>>>        - Core/web WildFly
>>>>        - Overlay/installer/feature-pack to install to existing WF and EAP
>>>>        - WAR bundle
>>>> How about a shell script that examines a WF install directory and does
>>>> all the magic for me or aDocker container?
>>>>
>>>> In general I have not liked the experience of having wildfly bundled
>>>> with a product.  It tends to mess with other servers I have installed
>>>> and be a general PITA to maintain for anything more than the most
>>>> trivial of demos.
>>>> Good feedback.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> * How should we deal with providers, themes and keycloak-server.json in
>>>> domain-mode
>>>>
>>>> * MSC all the way - We can deploy directly through the Undertow
>>>> sub-system
>>>> instead of deploying a WAR from the sub-system
>>>> What is MSC?
>>>> Modular Service Container.  It's the thing that lets you declare and
>>>> register services in WildFly.  But I'm not completely sure what Stian is
>>>> proposing here.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> * Split sub-systems - Should we split the sub-system in two? One for the
>>>> auth-server and another for the adapter
>>>> What are the trade offs?  What will using KeyCloak look like from my POV
>>>> if we split?
>>>> Instead of
>>>>
>>>> subsystem=keycloak/auth-server=main-auth-server
>>>> subsystem=keycloak/secure-deployment=foo
>>>>
>>>> you would have
>>>>
>>>> subsystem=keycloak-server/auth-server=main-auth-server
>>>> subsystem=keycloak-deployments/secure-deployment=foo
>>>>
>>>> Another option would be to just leave it as it is today and just hide
>>>> the "auth-server" resource for installations where you don't expect the
>>>> auth server to run.
>>>>
>>>> The answer will probably be more a function of how we want to organize
>>>> the code rather than how it will look to the end user.
>>>> As a end user it sounds like both work for me.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> * Deployable to other containers - Should it be possible to deploy
>>>> Keycloak
>>>> to Tomcat, Jetty, Fuse, etc..? One option could be to have reduced
>>>> features
>>>> in other containers (for example no client-cert)
>>>> The awesomeness of WildFly has forever made web containers look
>>>> insignificant to me.  If Glassfish still had a community edition worth a
>>>> damn I would say target it as well.  I don't know how TomEE is but that
>>>> may be good to support just for a "first one's free" to get people into
>>>> WildFly land.
>>>>
>>>> I don't think Websphere or WebLogic support has ever gotten anyone
>>>> excited about a project.  Honestly they are the technology equivalent of
>>>> taking a cold shower with grandma.
>>>> I could have done without that image. :-|
>>>>
>>>> But thanks again!
>>>> YW.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Please add any other relevant topics.
>>>>
>>>> Next big discussion I want to have is about distribution of adapters,
>>>> but
>>>> let's do one at a time ;)
>>>> _______________________________________________
>>>> 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
>>>> --
>>>> Summers Pittman
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Phone:404 941 4698
>>>> Java is my crack.
>>>> _______________________________________________
>>>> keycloak-dev mailing list keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Summers Pittman
>>>>>> Phone:404 941 4698
>>>>>> Java is my crack.
>>>> _______________________________________________
>>>> 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
>>>>
>>>>
>>>> --
>>>> Summers Pittman
>>>>>> Phone:404 941 4698
>>>>>> Java is my crack.
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>>
>>>> --
>>>> Summers Pittman
>>>>>> Phone:404 941 4698
>>>>>> Java is my crack.
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> --
>> Summers Pittman
>>>> Phone:404 941 4698
>>>> Java is my crack.
>>


-- 
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.


From bburke at redhat.com  Wed Feb 25 08:37:30 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 25 Feb 2015 08:37:30 -0500
Subject: [keycloak-dev] Modules work
In-Reply-To: <2137478223.14924200.1424865649764.JavaMail.zimbra@redhat.com>
References: <2137478223.14924200.1424865649764.JavaMail.zimbra@redhat.com>
Message-ID: <54EDD01A.6020904@redhat.com>

BTW:

http://java.dzone.com/articles/jboss-modules-suck-it%E2%80%99s


On 2/25/2015 7:00 AM, Stian Thorgersen wrote:
> All dependencies are now loaded from modules. I've done some testing, but there may be issues remaining.
>
> If you get a ClassNotFound you'll know why ;)
> _______________________________________________
> 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 Feb 25 08:56:36 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 25 Feb 2015 08:56:36 -0500
Subject: [keycloak-dev] Email Internationalization
In-Reply-To: <982598952.14757064.1424842281051.JavaMail.zimbra@redhat.com>
References: <A44322F3-19DA-423C-B161-D99307BB87CF@me.com>
	<54ECC40E.9010503@redhat.com>
	<61CC27BF-6FF7-4DAB-B575-E3093A20D6CA@me.com>
	<982598952.14757064.1424842281051.JavaMail.zimbra@redhat.com>
Message-ID: <54EDD494.6000400@redhat.com>



On 2/25/2015 12:31 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Michael Gerber" <gerbermichi at me.com>
>> To: "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, February 24, 2015 7:48:56 PM
>> Subject: Re: [keycloak-dev] Email Internationalization
>>
>> Thats written in the jira:
>>
>> Our built-in themes should strive to only require internationalized message
>> bundles and when absolutely required stylesheet overrides (for example for
>> right-to-left languages). However, themes should support internationalized:
>> 	? Message bundles
>> 	? Stylesheets
>> 	? Templates
>> If internationalization is required for images this should by specifying
>> different images either through stylesheets or templates.
>>
>> So you suggest that every file is overridable by a locale?
>
> I'm not sure we need to support this for templates, stylesheets and images. It could actually be quite bad practice. There's a lot of logic in templates, so maintaining multiple versions of the same template would be annoying and could easily introduce bugs and exploits. Another approach is to avoid text in images and do all translations in messages. If the locale is made available to the template itself anyone that needs to do some locale specific things in the template can do that within a single template with conditions. We should definitively not use multiple templates ourselves. We may need to support it for others, but I suggest we don't initially and see if anyone really needs it.
>
> With regards to emails they are simpler now, but we also want to support multi-part (text and html), where the html template would contain other things than just the text. I suggest we extract the text into a single message. We should then add support to resolve variables within messages (for example "resetPasswordEmail=Hello ${user.firstName} ...").
>
> Makes it a lot simpler to deal with translations if it's all done within messages. Usually devs are not language experts and this would make it easy for non-devs to provide translations.
>

Support overriding anything in locales.  Make each locale a nested theme 
or something like that.  IMO, that the additional flexibility will prove 
useful to us and users when something unforeseen comes up in the future.

A perfect example of wanting to extend a template is if you wanted to 
add data that is specific only to the locale.  For example, 
sso.company.com profile page might have a "favorite baseball team", 
while sso.company.com.uk might have "favorite cricket team".


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From stian at redhat.com  Wed Feb 25 09:09:56 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 25 Feb 2015 09:09:56 -0500 (EST)
Subject: [keycloak-dev] Added server version to cached resource urls
In-Reply-To: <2035729981.15027164.1424873245201.JavaMail.zimbra@redhat.com>
Message-ID: <2000243880.15030048.1424873396138.JavaMail.zimbra@redhat.com>

Every time we release a new version we get a lot of people having problems with the admin console. Usually these are due to the browser caches old Angular templates.

I've made a change to themes so instead of a resource being loaded from:

  /auth/theme/<type>/<theme name>/<resource>

It's now retrieved from:

  /auth/resources/<server version>/<type>/<theme name>/<resource>

Also, I've changed index.html for the admin console to index.ftl so that I could add the resource path (including server version, admin theme name, etc.).

From stian at redhat.com  Wed Feb 25 09:20:20 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 25 Feb 2015 09:20:20 -0500 (EST)
Subject: [keycloak-dev] Email Internationalization
In-Reply-To: <54EDD494.6000400@redhat.com>
References: <A44322F3-19DA-423C-B161-D99307BB87CF@me.com>
	<54ECC40E.9010503@redhat.com>
	<61CC27BF-6FF7-4DAB-B575-E3093A20D6CA@me.com>
	<982598952.14757064.1424842281051.JavaMail.zimbra@redhat.com>
	<54EDD494.6000400@redhat.com>
Message-ID: <481393771.15040629.1424874020179.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Michael Gerber" <gerbermichi at me.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, February 25, 2015 2:56:36 PM
> Subject: Re: [keycloak-dev] Email Internationalization
> 
> 
> 
> On 2/25/2015 12:31 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Michael Gerber" <gerbermichi at me.com>
> >> To: "Bill Burke" <bburke at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, February 24, 2015 7:48:56 PM
> >> Subject: Re: [keycloak-dev] Email Internationalization
> >>
> >> Thats written in the jira:
> >>
> >> Our built-in themes should strive to only require internationalized
> >> message
> >> bundles and when absolutely required stylesheet overrides (for example for
> >> right-to-left languages). However, themes should support
> >> internationalized:
> >> 	? Message bundles
> >> 	? Stylesheets
> >> 	? Templates
> >> If internationalization is required for images this should by specifying
> >> different images either through stylesheets or templates.
> >>
> >> So you suggest that every file is overridable by a locale?
> >
> > I'm not sure we need to support this for templates, stylesheets and images.
> > It could actually be quite bad practice. There's a lot of logic in
> > templates, so maintaining multiple versions of the same template would be
> > annoying and could easily introduce bugs and exploits. Another approach is
> > to avoid text in images and do all translations in messages. If the locale
> > is made available to the template itself anyone that needs to do some
> > locale specific things in the template can do that within a single
> > template with conditions. We should definitively not use multiple
> > templates ourselves. We may need to support it for others, but I suggest
> > we don't initially and see if anyone really needs it.
> >
> > With regards to emails they are simpler now, but we also want to support
> > multi-part (text and html), where the html template would contain other
> > things than just the text. I suggest we extract the text into a single
> > message. We should then add support to resolve variables within messages
> > (for example "resetPasswordEmail=Hello ${user.firstName} ...").
> >
> > Makes it a lot simpler to deal with translations if it's all done within
> > messages. Usually devs are not language experts and this would make it
> > easy for non-devs to provide translations.
> >
> 
> Support overriding anything in locales.  Make each locale a nested theme
> or something like that.  IMO, that the additional flexibility will prove
> useful to us and users when something unforeseen comes up in the future.
> 
> A perfect example of wanting to extend a template is if you wanted to
> add data that is specific only to the locale.  For example,
> sso.company.com profile page might have a "favorite baseball team",
> while sso.company.com.uk might have "favorite cricket team".

We don't need to add anything for that. All we need to do is to make sure the locale is available to the template then anyone can add conditions to do that. For example:

<#if locale.country = "US">
  <h1>Soccer time</h1>
<#else>
  <h1>Football time</h1>  
</#if>

> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>


From mposolda at redhat.com  Wed Feb 25 09:46:34 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Wed, 25 Feb 2015 15:46:34 +0100
Subject: [keycloak-dev] Keycloak Clustering 1.1.0.Final - Getting
 infinispan type casting error (DefaultCacheContainer to
 EmbeddedCacheManager) in DefaultInfinispanConnectionProviderFactory
In-Reply-To: <C5AF53298BAB5F4A88B28966E43B40AD0568AA96@xmb-aln-x12.cisco.com>
References: <C5AF53298BAB5F4A88B28966E43B40AD0568A97A@xmb-aln-x12.cisco.com>
	<54EC87A1.7080104@redhat.com>
	<C5AF53298BAB5F4A88B28966E43B40AD0568AA96@xmb-aln-x12.cisco.com>
Message-ID: <54EDE04A.4010901@redhat.com>

You should ensure that infinispan jars are not in your.war/WEB-INF/lib . 
Instead you should add file 
your.war/WEB-INF/jboss-deployment-structure.xml and put dependencies on 
all necessary modules there. See 
auth-server.war/WEB-INF/jboss-deployment-structure.xml and especially 
this line: 
https://github.com/keycloak/keycloak/blob/master/server/src/main/webapp/WEB-INF/jboss-deployment-structure.xml#L8

Marek

On 25.2.2015 13:21, Bappaditya Gorai (bgorai) wrote:
>
> Hi ,
>
> Thanks for your response.
>
> keycloak-war-dist 1.1.0.Final works for me too.
>
> Actually I have custom application similar to ?ups-auth-server? . In 
> pom.xml I am using  ?*keycloak-dependencies-server-min*? artifact  and 
> added necessary infinispan related dependencies 
> (keycloak-connections-infinispan, keycloak-model-sessions-infinispan, 
> keycloak-invalidation-cache-infinispan).
>
> Yes, I have added additional *?infinispan-core?* dependency in my 
> pom.xml as jboss class loader was unable to find 
> EmbeddedCacheManager.class .
>
> I see in your pom.xml you are using 
> ?*keycloak-dependencies-server-all? *, do I need to use the same ( 
> although I may not need all the dependencies)?
>
> Thanks
>
> Bappaditya Gorai
>
> *From:*Marek Posolda [mailto:mposolda at redhat.com]
> *Sent:* Tuesday, February 24, 2015 7:46 PM
> *To:* Bappaditya Gorai (bgorai); keycloak-dev at lists.jboss.org
> *Subject:* Re: [keycloak-dev] Keycloak Clustering 1.1.0.Final - 
> Getting infinispan type casting error (DefaultCacheContainer to 
> EmbeddedCacheManager) in DefaultInfinispanConnectionProviderFactory
>
> Hi,
>
> I can't reproduce the issue. It's strange as 
> org.jboss.as.clustering.infinispan.DefaultCacheContainer is subclass 
> of org.infinispan.manager.EmbeddedCacheManager. Didn't you do some 
> packaging changes like adding infinispan jars to 
> auth-server.war/WEB-INF/lib or something like that?
>
> What I did for clustered Keycloak on EAP 6.3:
>
> 1) Unpack keycloak-war-dist 1.1.0.Final to my jboss-eap 6.3
> 2) Configured standalone/configuration/standalone-ha.xml and add this 
> under infinispan subsystem:
>
>  <cache-container name="keycloak" jndi-name="infinispan/Keycloak" 
> start="EAGER">
>   <transport lock-timeout="60000"/>
>   <distributed-cache name="sessions" mode="SYNC" owners="2" 
> segments="60"/>
>   <distributed-cache name="loginFailures" mode="SYNC" owners="2" 
> segments="60"/>
>   <invalidation-cache name="realms" mode="SYNC"/>
>   <invalidation-cache name="users"  mode="SYNC"/>
>  </cache-container>
>
> 3) Configured standalone/configuration/keycloak-server.json and add this:
>
> "connectionsInfinispan": {
>     "default" : {
>         "cacheContainer" : "java:jboss/infinispan/Keycloak"
>     }
> }
>
> and also switch realmCache, userCache and userSessions to use: 
> "provider": "infinispan"
>
> 4) Then run server with command:
> ./standalone.sh -c standalone-ha.xml
>
> Let me know if these steps work for you.
>
> Marek
>
> On 24.2.2015 14:07, Bappaditya Gorai (bgorai) wrote:
>
>     In my standalone configuration file I am using following subsystem
>     version for infinispan, not sure whether it has any relevance to
>     my issue.
>
>     <subsystem xmlns="urn:jboss:domain:infinispan:1.5">
>
>     Thanks
>
>     Bappaditya Gorai
>
>     *From:*Bappaditya Gorai (bgorai)
>     *Sent:* Monday, February 23, 2015 2:46 PM
>     *To:* keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>
>     *Subject:* Keycloak Clustering 1.1.0.Final - Getting infinispan
>     type casting error (DefaultCacheContainer to EmbeddedCacheManager)
>     in DefaultInfinispanConnectionProviderFactory
>
>     Hi Team,
>
>     I am trying  configure  Keycloak in clustered environment (EAP
>     6.3), however getting following error (stack trace is provided
>     below) . I have followed instructions provided in ?*Chapter 24.
>     Clustering*? in Keycloak Guide
>     (http://docs.jboss.org/keycloak/docs/1.1.0.Final/userguide/html/clustering.html).
>     Let me know if I am missing something.
>
>     13:23:25,681 ERROR
>     [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth]]
>     (ServerService Thread Pool -- 62) JBWEB000289: Servlet Keycloak
>     REST Interface threw load() exception:
>     *java.lang.ClassCastException:
>     org.jboss.as.clustering.infinispan.DefaultCacheContainer cannot be
>     cast to org.infinispan.manager.EmbeddedCacheManager*
>
>             at
>     org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory.initContainerManaged(*DefaultInfinispanConnectionProviderFactory.java:70*)
>     [keycloak-connections-infinispan-1.1.0.Final.jar:1.1.0.Final]
>
>             at
>     org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory.lazyInit(DefaultInfinispanConnectionProviderFactory.java:59)
>     [keycloak-connections-infinispan-1.1.0.Final.jar:1.1.0.Final]
>
>             at
>     org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory.create(DefaultInfinispanConnectionProviderFactory.java:30)
>     [keycloak-connections-infinispan-1.1.0.Final.jar:1.1.0.Final]
>
>             at
>     org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory.create(DefaultInfinispanConnectionProviderFactory.java:18)
>     [keycloak-connections-infinispan-1.1.0.Final.jar:1.1.0.Final]
>
>     Thanks
>
>     Bappaditya Gorai
>
>
>
>
>     _______________________________________________
>
>     keycloak-dev mailing list
>
>     keycloak-dev at lists.jboss.org  <mailto:keycloak-dev at lists.jboss.org>
>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150225/d8e18a35/attachment-0001.html 

From bburke at redhat.com  Wed Feb 25 11:45:16 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 25 Feb 2015 11:45:16 -0500
Subject: [keycloak-dev] travis gone?
Message-ID: <54EDFC1C.80506@redhat.com>

Not seeing travis pop up anymore with my commit.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From psilva at redhat.com  Wed Feb 25 13:09:32 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 25 Feb 2015 13:09:32 -0500 (EST)
Subject: [keycloak-dev] travis gone?
In-Reply-To: <54EDFC1C.80506@redhat.com>
References: <54EDFC1C.80506@redhat.com>
Message-ID: <1359671829.19535287.1424887772028.JavaMail.zimbra@redhat.com>

The Travis is Gone [1].

[1] https://www.youtube.com/watch?v=BXsusJ787sU

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: keycloak-dev at lists.jboss.org
Sent: Wednesday, February 25, 2015 1:45:16 PM
Subject: [keycloak-dev] travis gone?

Not seeing travis pop up anymore with my commit.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev

From bburke at redhat.com  Wed Feb 25 13:15:33 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 25 Feb 2015 13:15:33 -0500
Subject: [keycloak-dev] travis gone?
In-Reply-To: <1359671829.19535287.1424887772028.JavaMail.zimbra@redhat.com>
References: <54EDFC1C.80506@redhat.com>
	<1359671829.19535287.1424887772028.JavaMail.zimbra@redhat.com>
Message-ID: <54EE1145.5050803@redhat.com>

lol....

On 2/25/2015 1:09 PM, Pedro Igor Silva wrote:
> The Travis is Gone [1].
>
> [1] https://www.youtube.com/watch?v=BXsusJ787sU
>
> ----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, February 25, 2015 1:45:16 PM
> Subject: [keycloak-dev] travis gone?
>
> Not seeing travis pop up anymore with my commit.
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From ssilvert at redhat.com  Wed Feb 25 13:16:23 2015
From: ssilvert at redhat.com (Stan Silvert)
Date: Wed, 25 Feb 2015 13:16:23 -0500
Subject: [keycloak-dev] travis gone?
In-Reply-To: <1359671829.19535287.1424887772028.JavaMail.zimbra@redhat.com>
References: <54EDFC1C.80506@redhat.com>
	<1359671829.19535287.1424887772028.JavaMail.zimbra@redhat.com>
Message-ID: <54EE1177.2030402@redhat.com>

On 2/25/2015 1:09 PM, Pedro Igor Silva wrote:
> The Travis is Gone [1].
>
> [1] https://www.youtube.com/watch?v=BXsusJ787sU
>
> ----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, February 25, 2015 1:45:16 PM
> Subject: [keycloak-dev] travis gone?
>
> Not seeing travis pop up anymore with my commit.
I don't know what the Travis is, but I used to be big blues fan. Seen 
B.B. King live three times.

From psilva at redhat.com  Wed Feb 25 13:22:18 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 25 Feb 2015 13:22:18 -0500 (EST)
Subject: [keycloak-dev] travis gone?
In-Reply-To: <54EE1177.2030402@redhat.com>
References: <54EDFC1C.80506@redhat.com>
	<1359671829.19535287.1424887772028.JavaMail.zimbra@redhat.com>
	<54EE1177.2030402@redhat.com>
Message-ID: <1522925224.19545673.1424888538364.JavaMail.zimbra@redhat.com>

Me too. Seen him one time. He and his beloved Lucille are magical.

----- Original Message -----
From: "Stan Silvert" <ssilvert at redhat.com>
To: keycloak-dev at lists.jboss.org
Sent: Wednesday, February 25, 2015 3:16:23 PM
Subject: Re: [keycloak-dev] travis gone?

On 2/25/2015 1:09 PM, Pedro Igor Silva wrote:
> The Travis is Gone [1].
>
> [1] https://www.youtube.com/watch?v=BXsusJ787sU
>
> ----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, February 25, 2015 1:45:16 PM
> Subject: [keycloak-dev] travis gone?
>
> Not seeing travis pop up anymore with my commit.
I don't know what the Travis is, but I used to be big blues fan. Seen 
B.B. King live three times.
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev

From gerbermichi at me.com  Wed Feb 25 13:58:11 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Wed, 25 Feb 2015 19:58:11 +0100
Subject: [keycloak-dev] messages properties file encoding
Message-ID: <49B75819-B023-4399-BCE6-42837E67B04C@me.com>

Hi,

Which encoding do you prefer for message files?
- iso-8859-1
- UTF-8
- UTF-16
- ?

Best
Michael

From gerbermichi at me.com  Wed Feb 25 14:21:53 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Wed, 25 Feb 2015 20:21:53 +0100
Subject: [keycloak-dev] Internationalization for model data
In-Reply-To: <54EC802E.3000008@redhat.com>
References: <54EC802E.3000008@redhat.com>
Message-ID: <53E98DF2-8700-4383-96A5-50B9DB2ACBAB@me.com>

How do we want to internationalize messages which contains variables like:
?Invalid password: must contain at least ? + min + " upper case characters"

${invalidPassword.minLength} This doesn?t work. 


> Am 24.02.2015 um 14:44 schrieb Bill Burke <bburke at redhat.com>:
> 
> There's data stored in a bunch of places that should be 
> internationalized.  i.e. Role descriptions.  I was thinking for this 
> type of stuff, for both simplicity and ease of migration, we still 
> continue to input this type of metadata through one field.  Then if the 
> user wants to internationalize a piece of data, they just replace the 
> text with a property variable.
> 
> Role Description: "Admin access to main application"
> 
> could be replaced with
> 
> Role Description: "${role.admin.description}"
> 
> Then the variable 'role.admin.description' is just replaced with a 
> theme-based property.
> 
> This way, users dont' have to learn about internationalization until 
> when and if the need it, existing deployments will still just work, and 
> we don't have to expand our data model.
> 
> -- 
> 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 psilva at redhat.com  Wed Feb 25 15:15:05 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 25 Feb 2015 15:15:05 -0500 (EST)
Subject: [keycloak-dev] Application and OAuthClient Representation types
In-Reply-To: <1848942025.19642097.1424895268672.JavaMail.zimbra@redhat.com>
Message-ID: <181975060.19642983.1424895305048.JavaMail.zimbra@redhat.com>

Can we have a abstract class for Application and OAuthClient representations ? 

Regards.
Pedro Igor

From bburke at redhat.com  Wed Feb 25 15:21:00 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 25 Feb 2015 15:21:00 -0500
Subject: [keycloak-dev] Application and OAuthClient Representation types
In-Reply-To: <181975060.19642983.1424895305048.JavaMail.zimbra@redhat.com>
References: <181975060.19642983.1424895305048.JavaMail.zimbra@redhat.com>
Message-ID: <54EE2EAC.8080406@redhat.com>

Don't bother right now.  In the next few months we are going to merge 
applications and clients: screens, representations, and data model.

On 2/25/2015 3:15 PM, Pedro Igor Silva wrote:
> Can we have a abstract class for Application and OAuthClient representations ?
>
> Regards.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Wed Feb 25 15:27:23 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 25 Feb 2015 15:27:23 -0500
Subject: [keycloak-dev] protocol settings menu item
Message-ID: <54EE302B.70601@redhat.com>

FYI:

I'm creating a protocol settings menu item where you can manage saml and 
oidc settings.  I need it right now so that I can view and manage claim 
mapping types.  As suggested by Pedro this will expand to define default 
application settings for specific protocols as well.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Wed Feb 25 15:30:45 2015
From: bburke at redhat.com (Bill Burke)
Date: Wed, 25 Feb 2015 15:30:45 -0500
Subject: [keycloak-dev] Internationalization for model data
In-Reply-To: <53E98DF2-8700-4383-96A5-50B9DB2ACBAB@me.com>
References: <54EC802E.3000008@redhat.com>
	<53E98DF2-8700-4383-96A5-50B9DB2ACBAB@me.com>
Message-ID: <54EE30F5.4030509@redhat.com>

invalidPassword.minlength.message=Invalid password: must contain at 
least ${realm.passwordpolicy.minLength}

Would need a way to resolve non message property properties.

On 2/25/2015 2:21 PM, Michael Gerber wrote:
> How do we want to internationalize messages which contains variables like:
> ?Invalid password: must contain at least ? + min + " upper case characters"
>
> ${invalidPassword.minLength} This doesn?t work.
>
>
>> Am 24.02.2015 um 14:44 schrieb Bill Burke <bburke at redhat.com>:
>>
>> There's data stored in a bunch of places that should be
>> internationalized.  i.e. Role descriptions.  I was thinking for this
>> type of stuff, for both simplicity and ease of migration, we still
>> continue to input this type of metadata through one field.  Then if the
>> user wants to internationalize a piece of data, they just replace the
>> text with a property variable.
>>
>> Role Description: "Admin access to main application"
>>
>> could be replaced with
>>
>> Role Description: "${role.admin.description}"
>>
>> Then the variable 'role.admin.description' is just replaced with a
>> theme-based property.
>>
>> This way, users dont' have to learn about internationalization until
>> when and if the need it, existing deployments will still just work, and
>> we don't have to expand our data model.
>>
>> --
>> 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 psilva at redhat.com  Wed Feb 25 15:39:00 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Wed, 25 Feb 2015 15:39:00 -0500 (EST)
Subject: [keycloak-dev] Application and OAuthClient Representation types
In-Reply-To: <54EE2EAC.8080406@redhat.com>
References: <181975060.19642983.1424895305048.JavaMail.zimbra@redhat.com>
	<54EE2EAC.8080406@redhat.com>
Message-ID: <1435465788.19656716.1424896740526.JavaMail.zimbra@redhat.com>

Nice.

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: keycloak-dev at lists.jboss.org
Sent: Wednesday, February 25, 2015 5:21:00 PM
Subject: Re: [keycloak-dev] Application and OAuthClient Representation types

Don't bother right now.  In the next few months we are going to merge 
applications and clients: screens, representations, and data model.

On 2/25/2015 3:15 PM, Pedro Igor Silva wrote:
> Can we have a abstract class for Application and OAuthClient representations ?
>
> Regards.
> Pedro Igor
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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

From stian at redhat.com  Thu Feb 26 01:08:47 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 26 Feb 2015 01:08:47 -0500 (EST)
Subject: [keycloak-dev] travis gone?
In-Reply-To: <54EDFC1C.80506@redhat.com>
References: <54EDFC1C.80506@redhat.com>
Message-ID: <446228689.15947974.1424930927292.JavaMail.zimbra@redhat.com>

Shouldn't be, he was around for my commits yesterday at least

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, February 25, 2015 5:45:16 PM
> Subject: [keycloak-dev] travis gone?
> 
> Not seeing travis pop up anymore with my commit.
> --
> 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  Thu Feb 26 01:11:30 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 26 Feb 2015 01:11:30 -0500 (EST)
Subject: [keycloak-dev] messages properties file encoding
In-Reply-To: <49B75819-B023-4399-BCE6-42837E67B04C@me.com>
References: <49B75819-B023-4399-BCE6-42837E67B04C@me.com>
Message-ID: <1496533014.15948859.1424931090819.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Wednesday, February 25, 2015 7:58:11 PM
> Subject: [keycloak-dev] messages properties file encoding
> 
> Hi,
> 
> Which encoding do you prefer for message files?
> - iso-8859-1

+1 As this is the default for Java property files

> - UTF-8
> - UTF-16
> - ?
> 
> Best
> Michael
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From stian at redhat.com  Thu Feb 26 01:17:01 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 26 Feb 2015 01:17:01 -0500 (EST)
Subject: [keycloak-dev] Internationalization for model data
In-Reply-To: <54EE30F5.4030509@redhat.com>
References: <54EC802E.3000008@redhat.com>
	<53E98DF2-8700-4383-96A5-50B9DB2ACBAB@me.com>
	<54EE30F5.4030509@redhat.com>
Message-ID: <820138412.15950557.1424931421319.JavaMail.zimbra@redhat.com>

I'm concerned that allowing any variable in any message would result in horrible performance. We'd have to use FreeMarker or something else to template each individual message, and it couldn't be cached either as the variables change. Would doing it on a case-by-case basic be enough?

For example:

  invalidPassword.minlength.message=Invalid password: must contain at least {0}

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Michael Gerber" <gerbermichi at me.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, February 25, 2015 9:30:45 PM
> Subject: Re: [keycloak-dev] Internationalization for model data
> 
> invalidPassword.minlength.message=Invalid password: must contain at
> least ${realm.passwordpolicy.minLength}
> 
> Would need a way to resolve non message property properties.
> 
> On 2/25/2015 2:21 PM, Michael Gerber wrote:
> > How do we want to internationalize messages which contains variables like:
> > ?Invalid password: must contain at least ? + min + " upper case characters"
> >
> > ${invalidPassword.minLength} This doesn?t work.
> >
> >
> >> Am 24.02.2015 um 14:44 schrieb Bill Burke <bburke at redhat.com>:
> >>
> >> There's data stored in a bunch of places that should be
> >> internationalized.  i.e. Role descriptions.  I was thinking for this
> >> type of stuff, for both simplicity and ease of migration, we still
> >> continue to input this type of metadata through one field.  Then if the
> >> user wants to internationalize a piece of data, they just replace the
> >> text with a property variable.
> >>
> >> Role Description: "Admin access to main application"
> >>
> >> could be replaced with
> >>
> >> Role Description: "${role.admin.description}"
> >>
> >> Then the variable 'role.admin.description' is just replaced with a
> >> theme-based property.
> >>
> >> This way, users dont' have to learn about internationalization until
> >> when and if the need it, existing deployments will still just work, and
> >> we don't have to expand our data model.
> >>
> >> --
> >> Bill Burke
> >> JBoss, a division of Red Hat
> >> http://bill.burkecentral.com
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


From gerbermichi at me.com  Thu Feb 26 02:42:02 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Thu, 26 Feb 2015 07:42:02 +0000 (GMT)
Subject: [keycloak-dev] Internationalization for model data
Message-ID: <ac9e7755-513a-45fc-8228-33af1a9bec31@me.com>

The definition in the message property file should be like this.
invalidPassword.minlength.message=Invalid password: must contain at least {0}

The current password validation for example returns messages like this:
return count < min ? "Invalid password: must contain at least " + min + " numerical digits" : null;

I can't replace this with a single key, because of the variable min.

However, I can replace the return type with an object which contains the message key and their parameters or a string lilke ${invalidPassword.minlength.message:min} or something similar.
I think there are other places where we need a possibility to internationalize a message with variables.

Am 26. Februar 2015 um 07:17 schrieb Stian Thorgersen <stian at redhat.com>:

I'm concerned that allowing any variable in any message would result in horrible performance. We'd have to use FreeMarker or something else to template each individual message, and it couldn't be cached either as the variables change. Would doing it on a case-by-case basic be enough?

For example:

invalidPassword.minlength.message=Invalid password: must contain at least {0}

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: "Michael Gerber" <gerbermichi at me.com>
Cc: keycloak-dev at lists.jboss.org
Sent: Wednesday, February 25, 2015 9:30:45 PM
Subject: Re: [keycloak-dev] Internationalization for model data
invalidPassword.minlength.message=Invalid password: must contain at
least ${realm.passwordpolicy.minLength}
Would need a way to resolve non message property properties.
On 2/25/2015 2:21 PM, Michael Gerber wrote:
> How do we want to internationalize messages which contains variables like:
> ?Invalid password: must contain at least ? + min + " upper case characters"
>
> ${invalidPassword.minLength} This doesn?t work.
>
>
>> Am 24.02.2015 um 14:44 schrieb Bill Burke <bburke at redhat.com>:
>>
>> There's data stored in a bunch of places that should be
>> internationalized. i.e. Role descriptions. I was thinking for this
>> type of stuff, for both simplicity and ease of migration, we still
>> continue to input this type of metadata through one field. Then if the
>> user wants to internationalize a piece of data, they just replace the
>> text with a property variable.
>>
>> Role Description: "Admin access to main application"
>>
>> could be replaced with
>>
>> Role Description: "${role.admin.description}"
>>
>> Then the variable 'role.admin.description' is just replaced with a
>> theme-based property.
>>
>> This way, users dont' have to learn about internationalization until
>> when and if the need it, existing deployments will still just work, and
>> we don't have to expand our data model.
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150226/c7a57324/attachment.html 

From jaekun.choi at gmail.com  Thu Feb 26 05:55:44 2015
From: jaekun.choi at gmail.com (Jae Choi)
Date: Thu, 26 Feb 2015 21:55:44 +1100
Subject: [keycloak-dev] Json Web Encrpytion
Message-ID: <CAPLm6jJMxBTAOqc_kM+2Ox38J6HJRaZ1b5bEGdM2Sz8yqxeN9A@mail.gmail.com>

Is there going to be some JSON web encryption support for Keycloak JWT?

-- 
Kind Regards,
Jae Choi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150226/204667ca/attachment.html 

From psilva at redhat.com  Thu Feb 26 07:27:31 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 26 Feb 2015 07:27:31 -0500 (EST)
Subject: [keycloak-dev] Json Web Encrpytion
In-Reply-To: <CAPLm6jJMxBTAOqc_kM+2Ox38J6HJRaZ1b5bEGdM2Sz8yqxeN9A@mail.gmail.com>
References: <CAPLm6jJMxBTAOqc_kM+2Ox38J6HJRaZ1b5bEGdM2Sz8yqxeN9A@mail.gmail.com>
Message-ID: <537683152.19992107.1424953651846.JavaMail.zimbra@redhat.com>

I think we also need to think about JWK. So we can carry on key/cert info along the token and a JWK Set endpoint to retrieve them.

Google provides that and it is really useful for clients.

----- Original Message -----
From: "Jae Choi" <jaekun.choi at gmail.com>
To: keycloak-dev at lists.jboss.org
Sent: Thursday, February 26, 2015 7:55:44 AM
Subject: [keycloak-dev] Json Web Encrpytion

Is there going to be some JSON web encryption support for Keycloak JWT? 

-- 
Kind Regards, 
Jae Choi 

_______________________________________________
keycloak-dev mailing list
keycloak-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev

From bburke at redhat.com  Thu Feb 26 07:53:04 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 26 Feb 2015 07:53:04 -0500
Subject: [keycloak-dev] Internationalization for model data
In-Reply-To: <820138412.15950557.1424931421319.JavaMail.zimbra@redhat.com>
References: <54EC802E.3000008@redhat.com>
	<53E98DF2-8700-4383-96A5-50B9DB2ACBAB@me.com>
	<54EE30F5.4030509@redhat.com>
	<820138412.15950557.1424931421319.JavaMail.zimbra@redhat.com>
Message-ID: <54EF1730.5080507@redhat.com>

You'll have to have printv like statements available in freemarker.

On 2/26/2015 1:17 AM, Stian Thorgersen wrote:
> I'm concerned that allowing any variable in any message would result in horrible performance. We'd have to use FreeMarker or something else to template each individual message, and it couldn't be cached either as the variables change. Would doing it on a case-by-case basic be enough?
>
> For example:
>
>    invalidPassword.minlength.message=Invalid password: must contain at least {0}
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Michael Gerber" <gerbermichi at me.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Wednesday, February 25, 2015 9:30:45 PM
>> Subject: Re: [keycloak-dev] Internationalization for model data
>>
>> invalidPassword.minlength.message=Invalid password: must contain at
>> least ${realm.passwordpolicy.minLength}
>>
>> Would need a way to resolve non message property properties.
>>
>> On 2/25/2015 2:21 PM, Michael Gerber wrote:
>>> How do we want to internationalize messages which contains variables like:
>>> ?Invalid password: must contain at least ? + min + " upper case characters"
>>>
>>> ${invalidPassword.minLength} This doesn?t work.
>>>
>>>
>>>> Am 24.02.2015 um 14:44 schrieb Bill Burke <bburke at redhat.com>:
>>>>
>>>> There's data stored in a bunch of places that should be
>>>> internationalized.  i.e. Role descriptions.  I was thinking for this
>>>> type of stuff, for both simplicity and ease of migration, we still
>>>> continue to input this type of metadata through one field.  Then if the
>>>> user wants to internationalize a piece of data, they just replace the
>>>> text with a property variable.
>>>>
>>>> Role Description: "Admin access to main application"
>>>>
>>>> could be replaced with
>>>>
>>>> Role Description: "${role.admin.description}"
>>>>
>>>> Then the variable 'role.admin.description' is just replaced with a
>>>> theme-based property.
>>>>
>>>> This way, users dont' have to learn about internationalization until
>>>> when and if the need it, existing deployments will still just work, and
>>>> we don't have to expand our data model.
>>>>
>>>> --
>>>> Bill Burke
>>>> JBoss, a division of Red Hat
>>>> http://bill.burkecentral.com
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bgorai at cisco.com  Thu Feb 26 08:06:59 2015
From: bgorai at cisco.com (Bappaditya Gorai (bgorai))
Date: Thu, 26 Feb 2015 13:06:59 +0000
Subject: [keycloak-dev] Keycloak Clustering 1.1.0.Final - Getting
 infinispan type casting error (DefaultCacheContainer to
 EmbeddedCacheManager) in DefaultInfinispanConnectionProviderFactory
In-Reply-To: <54EDE04A.4010901@redhat.com>
References: <C5AF53298BAB5F4A88B28966E43B40AD0568A97A@xmb-aln-x12.cisco.com>
	<54EC87A1.7080104@redhat.com>
	<C5AF53298BAB5F4A88B28966E43B40AD0568AA96@xmb-aln-x12.cisco.com>
	<54EDE04A.4010901@redhat.com>
Message-ID: <C5AF53298BAB5F4A88B28966E43B40AD0568AC5B@xmb-aln-x12.cisco.com>

Thanks , With the changes you suggested  it's working fine.

Thanks
Bappaditya Gorai

From: Marek Posolda [mailto:mposolda at redhat.com]
Sent: Wednesday, February 25, 2015 8:17 PM
To: Bappaditya Gorai (bgorai); keycloak-dev at lists.jboss.org
Subject: Re: [keycloak-dev] Keycloak Clustering 1.1.0.Final - Getting infinispan type casting error (DefaultCacheContainer to EmbeddedCacheManager) in DefaultInfinispanConnectionProviderFactory

You should ensure that infinispan jars are not in your.war/WEB-INF/lib . Instead you should add file your.war/WEB-INF/jboss-deployment-structure.xml and put dependencies on all necessary modules there. See auth-server.war/WEB-INF/jboss-deployment-structure.xml and especially this line: https://github.com/keycloak/keycloak/blob/master/server/src/main/webapp/WEB-INF/jboss-deployment-structure.xml#L8

Marek

On 25.2.2015 13:21, Bappaditya Gorai (bgorai) wrote:
Hi ,
Thanks for your response.

keycloak-war-dist 1.1.0.Final works for me too.

Actually I have custom application similar to "ups-auth-server" . In pom.xml I am using  "keycloak-dependencies-server-min" artifact  and added necessary infinispan related dependencies (keycloak-connections-infinispan, keycloak-model-sessions-infinispan, keycloak-invalidation-cache-infinispan).


Yes, I have added additional "infinispan-core" dependency in my pom.xml as jboss class loader was unable to find EmbeddedCacheManager.class .


I see in your pom.xml you are using "keycloak-dependencies-server-all" , do I need to use the same ( although I may not need all the dependencies)?

Thanks
Bappaditya Gorai

From: Marek Posolda [mailto:mposolda at redhat.com]
Sent: Tuesday, February 24, 2015 7:46 PM
To: Bappaditya Gorai (bgorai); keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
Subject: Re: [keycloak-dev] Keycloak Clustering 1.1.0.Final - Getting infinispan type casting error (DefaultCacheContainer to EmbeddedCacheManager) in DefaultInfinispanConnectionProviderFactory

Hi,

I can't reproduce the issue. It's strange as org.jboss.as.clustering.infinispan.DefaultCacheContainer is subclass of org.infinispan.manager.EmbeddedCacheManager. Didn't you do some packaging changes like adding infinispan jars to auth-server.war/WEB-INF/lib or something like that?

What I did for clustered Keycloak on EAP 6.3:

1) Unpack keycloak-war-dist 1.1.0.Final to my jboss-eap 6.3
2) Configured standalone/configuration/standalone-ha.xml and add this under infinispan subsystem:

 <cache-container name="keycloak" jndi-name="infinispan/Keycloak" start="EAGER">
  <transport lock-timeout="60000"/>
  <distributed-cache name="sessions" mode="SYNC" owners="2" segments="60"/>
  <distributed-cache name="loginFailures" mode="SYNC" owners="2" segments="60"/>
  <invalidation-cache name="realms" mode="SYNC"/>
  <invalidation-cache name="users"  mode="SYNC"/>
 </cache-container>

3) Configured standalone/configuration/keycloak-server.json and add this:

"connectionsInfinispan": {
    "default" : {
        "cacheContainer" : "java:jboss/infinispan/Keycloak"
    }
}

and also switch realmCache, userCache and userSessions to use: "provider": "infinispan"

4) Then run server with command:
./standalone.sh -c standalone-ha.xml

Let me know if these steps work for you.

Marek

On 24.2.2015 14:07, Bappaditya Gorai (bgorai) wrote:
In my standalone configuration file I am using following subsystem version for infinispan, not sure whether it has any relevance to my issue.

<subsystem xmlns="urn:jboss:domain:infinispan:1.5">

Thanks
Bappaditya Gorai

From: Bappaditya Gorai (bgorai)
Sent: Monday, February 23, 2015 2:46 PM
To: keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>
Subject: Keycloak Clustering 1.1.0.Final - Getting infinispan type casting error (DefaultCacheContainer to EmbeddedCacheManager) in DefaultInfinispanConnectionProviderFactory

Hi Team,

I am trying  configure  Keycloak in clustered environment (EAP 6.3), however getting following error (stack trace is provided below) . I have followed instructions provided in "Chapter 24. Clustering" in Keycloak Guide (http://docs.jboss.org/keycloak/docs/1.1.0.Final/userguide/html/clustering.html). Let me know if I am missing something.


13:23:25,681 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth]] (ServerService Thread Pool -- 62) JBWEB000289: Servlet Keycloak REST Interface threw load() exception: java.lang.ClassCastException: org.jboss.as.clustering.infinispan.DefaultCacheContainer cannot be cast to org.infinispan.manager.EmbeddedCacheManager
        at org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory.initContainerManaged(DefaultInfinispanConnectionProviderFactory.java:70) [keycloak-connections-infinispan-1.1.0.Final.jar:1.1.0.Final]
        at org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory.lazyInit(DefaultInfinispanConnectionProviderFactory.java:59) [keycloak-connections-infinispan-1.1.0.Final.jar:1.1.0.Final]
        at org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory.create(DefaultInfinispanConnectionProviderFactory.java:30) [keycloak-connections-infinispan-1.1.0.Final.jar:1.1.0.Final]
        at org.keycloak.connections.infinispan.DefaultInfinispanConnectionProviderFactory.create(DefaultInfinispanConnectionProviderFactory.java:18) [keycloak-connections-infinispan-1.1.0.Final.jar:1.1.0.Final]



Thanks
Bappaditya Gorai





_______________________________________________

keycloak-dev mailing list

keycloak-dev at lists.jboss.org<mailto:keycloak-dev at lists.jboss.org>

https://lists.jboss.org/mailman/listinfo/keycloak-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150226/54a5fa7e/attachment.html 

From bburke at redhat.com  Thu Feb 26 08:23:38 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 26 Feb 2015 08:23:38 -0500
Subject: [keycloak-dev] Json Web Encrpytion
In-Reply-To: <537683152.19992107.1424953651846.JavaMail.zimbra@redhat.com>
References: <CAPLm6jJMxBTAOqc_kM+2Ox38J6HJRaZ1b5bEGdM2Sz8yqxeN9A@mail.gmail.com>
	<537683152.19992107.1424953651846.JavaMail.zimbra@redhat.com>
Message-ID: <54EF1E5A.70304@redhat.com>

Encryption is redundant in most cases.  You are already communicating 
JWTs over SSL.   Well, you should be, or your deployment is completely 
insecure.  Where I could see it being interesting is for semi-trusted 
third-parties.  These parties get a JWE as their "access token" so that 
they can't read the information in the token.  Services that consume the 
token would have to have some shared secret/key with the server in order 
to decrypt and then validate the token.

Transmitting JWK sets (or kid or x5u or x5c) is only useful to determine 
to match up the signer or encrypter with a key or shared secret to use 
to validate or decrypt the JWS or JWE.  Not really very important for us 
right now because adapters have all the information they need (the 
realm's public key) to validate.  This would be useful in cases for 
bearer-only services that can process tokens from different keycloak realms.


On 2/26/2015 7:27 AM, Pedro Igor Silva wrote:
> I think we also need to think about JWK. So we can carry on key/cert info along the token and a JWK Set endpoint to retrieve them.
>
> Google provides that and it is really useful for clients.
>
> ----- Original Message -----
> From: "Jae Choi" <jaekun.choi at gmail.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, February 26, 2015 7:55:44 AM
> Subject: [keycloak-dev] Json Web Encrpytion
>
> Is there going to be some JSON web encryption support for Keycloak JWT?
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Thu Feb 26 10:42:19 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 26 Feb 2015 10:42:19 -0500
Subject: [keycloak-dev] apps access to and refresh of facebook tokens
Message-ID: <54EF3EDB.4060903@redhat.com>

At least for openid connect, I think we hashed this through on our dev 
call today.

* There will be a Protocol Claim Mapper that can add a facebook token 
and expiration claim to the application's access token.
* the refreshToken endpoint will accept a "scope" parameter.  The 
application can then request the refresh of any external token by 
specifying this token in the "scope parameter.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From psilva at redhat.com  Thu Feb 26 11:09:18 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 26 Feb 2015 11:09:18 -0500 (EST)
Subject: [keycloak-dev] apps access to and refresh of facebook tokens
In-Reply-To: <54EF3EDB.4060903@redhat.com>
References: <54EF3EDB.4060903@redhat.com>
Message-ID: <1946967211.20445048.1424966958888.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Thursday, February 26, 2015 12:42:19 PM
> Subject: [keycloak-dev] apps access to and refresh of facebook tokens
> 
> At least for openid connect, I think we hashed this through on our dev
> call today.
> 
> * There will be a Protocol Claim Mapper that can add a facebook token
> and expiration claim to the application's access token.

I would create a specific claim set for that instead of individual claims. Something like:

"k_act" : {
    "identity-provider": {
        "id" : "facebook",
        "access_token": "12312312",
        "expires": "12312321"
    }
}

(k_act : keycloak authentication context)

That way we can use this k_act for exchange information regarding the authentication context when issuing access tokens or even id tokens.

> * the refreshToken endpoint will accept a "scope" parameter.  The
> application can then request the refresh of any external token by
> specifying this token in the "scope parameter.

I was thinking about adding a refreshToken endpoint to the identity broker. Isn't better ?

> 
> 
> --
> 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 Feb 26 12:09:09 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 26 Feb 2015 12:09:09 -0500
Subject: [keycloak-dev] apps access to and refresh of facebook tokens
In-Reply-To: <1946967211.20445048.1424966958888.JavaMail.zimbra@redhat.com>
References: <54EF3EDB.4060903@redhat.com>
	<1946967211.20445048.1424966958888.JavaMail.zimbra@redhat.com>
Message-ID: <54EF5335.6010501@redhat.com>



On 2/26/2015 11:09 AM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Thursday, February 26, 2015 12:42:19 PM
>> Subject: [keycloak-dev] apps access to and refresh of facebook tokens
>>
>> At least for openid connect, I think we hashed this through on our dev
>> call today.
>>
>> * There will be a Protocol Claim Mapper that can add a facebook token
>> and expiration claim to the application's access token.
>
> I would create a specific claim set for that instead of individual claims. Something like:
>
> "k_act" : {
>      "identity-provider": {
>          "id" : "facebook",
>          "access_token": "12312312",
>          "expires": "12312321"
>      }
> }
>
> (k_act : keycloak authentication context)
>
> That way we can use this k_act for exchange information regarding the authentication context when issuing access tokens or even id tokens.
>

Yeah, token mapping be able to generate any json you want.

>> * the refreshToken endpoint will accept a "scope" parameter.  The
>> application can then request the refresh of any external token by
>> specifying this token in the "scope parameter.
>
> I was thinking about adding a refreshToken endpoint to the identity broker. Isn't better ?
>

A different endpoint would require the identity broker to know if the 
app has permission to request it. Also, with my idea, you can refresh 
multiple things with one request.

 From an application perspective we can provide a 
KeycloakSecurityContext.refreshToken(String... scope) method, then the 
app has one place to request the refresh of one or more claims.

i.e.

token = context.refreshToken("facebook", "google");

String facebookToken = token.getClaim("broker.facebook.token");


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From psilva at redhat.com  Thu Feb 26 13:16:34 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 26 Feb 2015 13:16:34 -0500 (EST)
Subject: [keycloak-dev] apps access to and refresh of facebook tokens
In-Reply-To: <54EF5335.6010501@redhat.com>
References: <54EF3EDB.4060903@redhat.com>
	<1946967211.20445048.1424966958888.JavaMail.zimbra@redhat.com>
	<54EF5335.6010501@redhat.com>
Message-ID: <1952677297.20565895.1424974594063.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, February 26, 2015 2:09:09 PM
> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
> 
> 
> 
> On 2/26/2015 11:09 AM, Pedro Igor Silva wrote:
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, February 26, 2015 12:42:19 PM
> >> Subject: [keycloak-dev] apps access to and refresh of facebook tokens
> >>
> >> At least for openid connect, I think we hashed this through on our dev
> >> call today.
> >>
> >> * There will be a Protocol Claim Mapper that can add a facebook token
> >> and expiration claim to the application's access token.
> >
> > I would create a specific claim set for that instead of individual claims.
> > Something like:
> >
> > "k_act" : {
> >      "identity-provider": {
> >          "id" : "facebook",
> >          "access_token": "12312312",
> >          "expires": "12312321"
> >      }
> > }
> >
> > (k_act : keycloak authentication context)
> >
> > That way we can use this k_act for exchange information regarding the
> > authentication context when issuing access tokens or even id tokens.
> >
> 
> Yeah, token mapping be able to generate any json you want.
> 
> >> * the refreshToken endpoint will accept a "scope" parameter.  The
> >> application can then request the refresh of any external token by
> >> specifying this token in the "scope parameter.
> >
> > I was thinking about adding a refreshToken endpoint to the identity broker.
> > Isn't better ?
> >
> 
> A different endpoint would require the identity broker to know if the
> app has permission to request it. Also, with my idea, you can refresh
> multiple things with one request.
> 
>  From an application perspective we can provide a
> KeycloakSecurityContext.refreshToken(String... scope) method, then the
> app has one place to request the refresh of one or more claims.
> 
> i.e.
> 
> token = context.refreshToken("facebook", "google");
> 
> String facebookToken = token.getClaim("broker.facebook.token");

I'm still not sure if this is right. Specially when using scopes for that.

Regarding app permissions, know if an app has an identity provider enabled and has access to retrieve its tokens is not enough ?

And we can also provide a single place to request refresh for multiple claims.

> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Thu Feb 26 13:41:21 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 26 Feb 2015 13:41:21 -0500
Subject: [keycloak-dev] apps access to and refresh of facebook tokens
In-Reply-To: <1952677297.20565895.1424974594063.JavaMail.zimbra@redhat.com>
References: <54EF3EDB.4060903@redhat.com>
	<1946967211.20445048.1424966958888.JavaMail.zimbra@redhat.com>
	<54EF5335.6010501@redhat.com>
	<1952677297.20565895.1424974594063.JavaMail.zimbra@redhat.com>
Message-ID: <54EF68D1.5020504@redhat.com>



On 2/26/2015 1:16 PM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Pedro Igor Silva" <psilva at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Thursday, February 26, 2015 2:09:09 PM
>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
>>
>>
>>
>> On 2/26/2015 11:09 AM, Pedro Igor Silva wrote:
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: keycloak-dev at lists.jboss.org
>>>> Sent: Thursday, February 26, 2015 12:42:19 PM
>>>> Subject: [keycloak-dev] apps access to and refresh of facebook tokens
>>>>
>>>> At least for openid connect, I think we hashed this through on our dev
>>>> call today.
>>>>
>>>> * There will be a Protocol Claim Mapper that can add a facebook token
>>>> and expiration claim to the application's access token.
>>>
>>> I would create a specific claim set for that instead of individual claims.
>>> Something like:
>>>
>>> "k_act" : {
>>>       "identity-provider": {
>>>           "id" : "facebook",
>>>           "access_token": "12312312",
>>>           "expires": "12312321"
>>>       }
>>> }
>>>
>>> (k_act : keycloak authentication context)
>>>
>>> That way we can use this k_act for exchange information regarding the
>>> authentication context when issuing access tokens or even id tokens.
>>>
>>
>> Yeah, token mapping be able to generate any json you want.
>>
>>>> * the refreshToken endpoint will accept a "scope" parameter.  The
>>>> application can then request the refresh of any external token by
>>>> specifying this token in the "scope parameter.
>>>
>>> I was thinking about adding a refreshToken endpoint to the identity broker.
>>> Isn't better ?
>>>
>>
>> A different endpoint would require the identity broker to know if the
>> app has permission to request it. Also, with my idea, you can refresh
>> multiple things with one request.
>>
>>   From an application perspective we can provide a
>> KeycloakSecurityContext.refreshToken(String... scope) method, then the
>> app has one place to request the refresh of one or more claims.
>>
>> i.e.
>>
>> token = context.refreshToken("facebook", "google");
>>
>> String facebookToken = token.getClaim("broker.facebook.token");
>
> I'm still not sure if this is right. Specially when using scopes for that.
>
> Regarding app permissions, know if an app has an identity provider enabled and has access to retrieve its tokens is not enough ?
>

What does "app has an identity provider enabled" mean again?

> And we can also provide a single place to request refresh for multiple claims.
>

Err...that's the same thing I was suggesting.  IMO, most apps won't have 
to manually do a refresh, they can just rely on the adapter to do it for 
them.  The way I'm proposing requires no changes to adapter code and the 
user can let the adapter refresh things as appropriate.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From psilva at redhat.com  Thu Feb 26 14:04:12 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 26 Feb 2015 14:04:12 -0500 (EST)
Subject: [keycloak-dev] apps access to and refresh of facebook tokens
In-Reply-To: <54EF68D1.5020504@redhat.com>
References: <54EF3EDB.4060903@redhat.com>
	<1946967211.20445048.1424966958888.JavaMail.zimbra@redhat.com>
	<54EF5335.6010501@redhat.com>
	<1952677297.20565895.1424974594063.JavaMail.zimbra@redhat.com>
	<54EF68D1.5020504@redhat.com>
Message-ID: <999442242.20609060.1424977452320.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, February 26, 2015 3:41:21 PM
> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
> 
> 
> 
> On 2/26/2015 1:16 PM, Pedro Igor Silva wrote:
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Pedro Igor Silva" <psilva at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, February 26, 2015 2:09:09 PM
> >> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
> >>
> >>
> >>
> >> On 2/26/2015 11:09 AM, Pedro Igor Silva wrote:
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Thursday, February 26, 2015 12:42:19 PM
> >>>> Subject: [keycloak-dev] apps access to and refresh of facebook tokens
> >>>>
> >>>> At least for openid connect, I think we hashed this through on our dev
> >>>> call today.
> >>>>
> >>>> * There will be a Protocol Claim Mapper that can add a facebook token
> >>>> and expiration claim to the application's access token.
> >>>
> >>> I would create a specific claim set for that instead of individual
> >>> claims.
> >>> Something like:
> >>>
> >>> "k_act" : {
> >>>       "identity-provider": {
> >>>           "id" : "facebook",
> >>>           "access_token": "12312312",
> >>>           "expires": "12312321"
> >>>       }
> >>> }
> >>>
> >>> (k_act : keycloak authentication context)
> >>>
> >>> That way we can use this k_act for exchange information regarding the
> >>> authentication context when issuing access tokens or even id tokens.
> >>>
> >>
> >> Yeah, token mapping be able to generate any json you want.
> >>
> >>>> * the refreshToken endpoint will accept a "scope" parameter.  The
> >>>> application can then request the refresh of any external token by
> >>>> specifying this token in the "scope parameter.
> >>>
> >>> I was thinking about adding a refreshToken endpoint to the identity
> >>> broker.
> >>> Isn't better ?
> >>>
> >>
> >> A different endpoint would require the identity broker to know if the
> >> app has permission to request it. Also, with my idea, you can refresh
> >> multiple things with one request.
> >>
> >>   From an application perspective we can provide a
> >> KeycloakSecurityContext.refreshToken(String... scope) method, then the
> >> app has one place to request the refresh of one or more claims.
> >>
> >> i.e.
> >>
> >> token = context.refreshToken("facebook", "google");
> >>
> >> String facebookToken = token.getClaim("broker.facebook.token");
> >
> > I'm still not sure if this is right. Specially when using scopes for that.
> >
> > Regarding app permissions, know if an app has an identity provider enabled
> > and has access to retrieve its tokens is not enough ?
> >
> 
> What does "app has an identity provider enabled" mean again?

Currently, you can enable/disable identity providers for each application. I'm also going to add another option to enable/disable token retrieval, as Stian suggested.

> 
> > And we can also provide a single place to request refresh for multiple
> > claims.
> >
> 
> Err...that's the same thing I was suggesting.  IMO, most apps won't have
> to manually do a refresh, they can just rely on the adapter to do it for
> them.  The way I'm proposing requires no changes to adapter code and the
> user can let the adapter refresh things as appropriate.

Sorry, what I meant is the broker being the single place to refresh tokens. And not some where else.

How are you going to specify which providers the user wants to automatically refresh tokens ? keycloak.json ?

> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From bburke at redhat.com  Thu Feb 26 14:45:02 2015
From: bburke at redhat.com (Bill Burke)
Date: Thu, 26 Feb 2015 14:45:02 -0500
Subject: [keycloak-dev] apps access to and refresh of facebook tokens
In-Reply-To: <999442242.20609060.1424977452320.JavaMail.zimbra@redhat.com>
References: <54EF3EDB.4060903@redhat.com>
	<1946967211.20445048.1424966958888.JavaMail.zimbra@redhat.com>
	<54EF5335.6010501@redhat.com>
	<1952677297.20565895.1424974594063.JavaMail.zimbra@redhat.com>
	<54EF68D1.5020504@redhat.com>
	<999442242.20609060.1424977452320.JavaMail.zimbra@redhat.com>
Message-ID: <54EF77BE.3020901@redhat.com>



On 2/26/2015 2:04 PM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Pedro Igor Silva" <psilva at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Thursday, February 26, 2015 3:41:21 PM
>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
>>
>>
>>
>> On 2/26/2015 1:16 PM, Pedro Igor Silva wrote:
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Thursday, February 26, 2015 2:09:09 PM
>>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
>>>>
>>>>
>>>>
>>>> On 2/26/2015 11:09 AM, Pedro Igor Silva wrote:
>>>>> ----- Original Message -----
>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>> Sent: Thursday, February 26, 2015 12:42:19 PM
>>>>>> Subject: [keycloak-dev] apps access to and refresh of facebook tokens
>>>>>>
>>>>>> At least for openid connect, I think we hashed this through on our dev
>>>>>> call today.
>>>>>>
>>>>>> * There will be a Protocol Claim Mapper that can add a facebook token
>>>>>> and expiration claim to the application's access token.
>>>>>
>>>>> I would create a specific claim set for that instead of individual
>>>>> claims.
>>>>> Something like:
>>>>>
>>>>> "k_act" : {
>>>>>        "identity-provider": {
>>>>>            "id" : "facebook",
>>>>>            "access_token": "12312312",
>>>>>            "expires": "12312321"
>>>>>        }
>>>>> }
>>>>>
>>>>> (k_act : keycloak authentication context)
>>>>>
>>>>> That way we can use this k_act for exchange information regarding the
>>>>> authentication context when issuing access tokens or even id tokens.
>>>>>
>>>>
>>>> Yeah, token mapping be able to generate any json you want.
>>>>
>>>>>> * the refreshToken endpoint will accept a "scope" parameter.  The
>>>>>> application can then request the refresh of any external token by
>>>>>> specifying this token in the "scope parameter.
>>>>>
>>>>> I was thinking about adding a refreshToken endpoint to the identity
>>>>> broker.
>>>>> Isn't better ?
>>>>>
>>>>
>>>> A different endpoint would require the identity broker to know if the
>>>> app has permission to request it. Also, with my idea, you can refresh
>>>> multiple things with one request.
>>>>
>>>>    From an application perspective we can provide a
>>>> KeycloakSecurityContext.refreshToken(String... scope) method, then the
>>>> app has one place to request the refresh of one or more claims.
>>>>
>>>> i.e.
>>>>
>>>> token = context.refreshToken("facebook", "google");
>>>>
>>>> String facebookToken = token.getClaim("broker.facebook.token");
>>>
>>> I'm still not sure if this is right. Specially when using scopes for that.
>>>
>>> Regarding app permissions, know if an app has an identity provider enabled
>>> and has access to retrieve its tokens is not enough ?
>>>
>>
>> What does "app has an identity provider enabled" mean again?
>
> Currently, you can enable/disable identity providers for each application. I'm also going to add another option to enable/disable token retrieval, as Stian suggested.
>

What does enable/disable entity provider per application mean?  A 
disabled "facebook" would mean that a "facebook" user couldn't visit the 
app?

>>
>>> And we can also provide a single place to request refresh for multiple
>>> claims.
>>>
>>
>> Err...that's the same thing I was suggesting.  IMO, most apps won't have
>> to manually do a refresh, they can just rely on the adapter to do it for
>> them.  The way I'm proposing requires no changes to adapter code and the
>> user can let the adapter refresh things as appropriate.
>
> Sorry, what I meant is the broker being the single place to refresh tokens. And not some where else.
>
> How are you going to specify which providers the user wants to automatically refresh tokens ? keycloak.json ?

In admin consonle, admin would configure the app to add the facebook 
token claim to the JWT access token.  When the application invokes 
refreshToken, this claim will be updated if needed.  It will all be a 
callback through the ProtocolMapper SPI I'm creating.

If the application wants to refresh only one claim, then it would 
specify a "scope" with the refreshToken request.

All this refreshing would happen between one API.  Then there is nothing 
broker specific for the application, only one URL to refresh everything.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From psilva at redhat.com  Thu Feb 26 14:48:43 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Thu, 26 Feb 2015 14:48:43 -0500 (EST)
Subject: [keycloak-dev] apps access to and refresh of facebook tokens
In-Reply-To: <54EF77BE.3020901@redhat.com>
References: <54EF3EDB.4060903@redhat.com>
	<1946967211.20445048.1424966958888.JavaMail.zimbra@redhat.com>
	<54EF5335.6010501@redhat.com>
	<1952677297.20565895.1424974594063.JavaMail.zimbra@redhat.com>
	<54EF68D1.5020504@redhat.com>
	<999442242.20609060.1424977452320.JavaMail.zimbra@redhat.com>
	<54EF77BE.3020901@redhat.com>
Message-ID: <764234478.20641140.1424980123285.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, February 26, 2015 4:45:02 PM
> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
> 
> 
> 
> On 2/26/2015 2:04 PM, Pedro Igor Silva wrote:
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: "Pedro Igor Silva" <psilva at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, February 26, 2015 3:41:21 PM
> >> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
> >>
> >>
> >>
> >> On 2/26/2015 1:16 PM, Pedro Igor Silva wrote:
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>> Cc: keycloak-dev at lists.jboss.org
> >>>> Sent: Thursday, February 26, 2015 2:09:09 PM
> >>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook
> >>>> tokens
> >>>>
> >>>>
> >>>>
> >>>> On 2/26/2015 11:09 AM, Pedro Igor Silva wrote:
> >>>>> ----- Original Message -----
> >>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>> Sent: Thursday, February 26, 2015 12:42:19 PM
> >>>>>> Subject: [keycloak-dev] apps access to and refresh of facebook tokens
> >>>>>>
> >>>>>> At least for openid connect, I think we hashed this through on our dev
> >>>>>> call today.
> >>>>>>
> >>>>>> * There will be a Protocol Claim Mapper that can add a facebook token
> >>>>>> and expiration claim to the application's access token.
> >>>>>
> >>>>> I would create a specific claim set for that instead of individual
> >>>>> claims.
> >>>>> Something like:
> >>>>>
> >>>>> "k_act" : {
> >>>>>        "identity-provider": {
> >>>>>            "id" : "facebook",
> >>>>>            "access_token": "12312312",
> >>>>>            "expires": "12312321"
> >>>>>        }
> >>>>> }
> >>>>>
> >>>>> (k_act : keycloak authentication context)
> >>>>>
> >>>>> That way we can use this k_act for exchange information regarding the
> >>>>> authentication context when issuing access tokens or even id tokens.
> >>>>>
> >>>>
> >>>> Yeah, token mapping be able to generate any json you want.
> >>>>
> >>>>>> * the refreshToken endpoint will accept a "scope" parameter.  The
> >>>>>> application can then request the refresh of any external token by
> >>>>>> specifying this token in the "scope parameter.
> >>>>>
> >>>>> I was thinking about adding a refreshToken endpoint to the identity
> >>>>> broker.
> >>>>> Isn't better ?
> >>>>>
> >>>>
> >>>> A different endpoint would require the identity broker to know if the
> >>>> app has permission to request it. Also, with my idea, you can refresh
> >>>> multiple things with one request.
> >>>>
> >>>>    From an application perspective we can provide a
> >>>> KeycloakSecurityContext.refreshToken(String... scope) method, then the
> >>>> app has one place to request the refresh of one or more claims.
> >>>>
> >>>> i.e.
> >>>>
> >>>> token = context.refreshToken("facebook", "google");
> >>>>
> >>>> String facebookToken = token.getClaim("broker.facebook.token");
> >>>
> >>> I'm still not sure if this is right. Specially when using scopes for
> >>> that.
> >>>
> >>> Regarding app permissions, know if an app has an identity provider
> >>> enabled
> >>> and has access to retrieve its tokens is not enough ?
> >>>
> >>
> >> What does "app has an identity provider enabled" mean again?
> >
> > Currently, you can enable/disable identity providers for each application.
> > I'm also going to add another option to enable/disable token retrieval, as
> > Stian suggested.
> >
> 
> What does enable/disable entity provider per application mean?  A
> disabled "facebook" would mean that a "facebook" user couldn't visit the
> app?

It means that an application does not supports Facebook login. We just hide the Facebook button from the login page for a particular application.

> 
> >>
> >>> And we can also provide a single place to request refresh for multiple
> >>> claims.
> >>>
> >>
> >> Err...that's the same thing I was suggesting.  IMO, most apps won't have
> >> to manually do a refresh, they can just rely on the adapter to do it for
> >> them.  The way I'm proposing requires no changes to adapter code and the
> >> user can let the adapter refresh things as appropriate.
> >
> > Sorry, what I meant is the broker being the single place to refresh tokens.
> > And not some where else.
> >
> > How are you going to specify which providers the user wants to
> > automatically refresh tokens ? keycloak.json ?
> 
> In admin consonle, admin would configure the app to add the facebook
> token claim to the JWT access token.  When the application invokes
> refreshToken, this claim will be updated if needed.  It will all be a
> callback through the ProtocolMapper SPI I'm creating.
> 
> If the application wants to refresh only one claim, then it would
> specify a "scope" with the refreshToken request.
> 
> All this refreshing would happen between one API.  Then there is nothing
> broker specific for the application, only one URL to refresh everything.

Ok.

> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> 

From gerbermichi at me.com  Thu Feb 26 16:44:33 2015
From: gerbermichi at me.com (Michael Gerber)
Date: Thu, 26 Feb 2015 22:44:33 +0100
Subject: [keycloak-dev] Internationalization for model data
In-Reply-To: <54EF1730.5080507@redhat.com>
References: <54EC802E.3000008@redhat.com>
	<53E98DF2-8700-4383-96A5-50B9DB2ACBAB@me.com>
	<54EE30F5.4030509@redhat.com>
	<820138412.15950557.1424931421319.JavaMail.zimbra@redhat.com>
	<54EF1730.5080507@redhat.com>
Message-ID: <94D06EFA-D7AA-4E44-916B-7693C3F12DB6@me.com>

I think there is a miss understanding?

messages_en.properties contains:
invalidPassword.minlength.message=Invalid password: must contain at least {0}

PasswordPolicy contains:
public String validate(String password) {
    ?
    return count < min ? "Invalid password: must contain at least " + min + " numerical digits" : null;
}
    
Validation contains:
String error = realm.getPasswordPolicy().validate(credential.getValue());
if (error != null) throw new ModelException(error);

This error messages is displayed to the end user and should be internationalized.
There are two possible solutions for that, create a string which contains the message key and the variables or create an object which contains both. 

A string construct like ${invalidPassword.minlength.message:min} can be used easily without a lot of changes. 

Which method do you prefer?

Michael

> Am 26.02.2015 um 13:53 schrieb Bill Burke <bburke at redhat.com>:
> 
> You'll have to have printv like statements available in freemarker.
> 
> On 2/26/2015 1:17 AM, Stian Thorgersen wrote:
>> I'm concerned that allowing any variable in any message would result in horrible performance. We'd have to use FreeMarker or something else to template each individual message, and it couldn't be cached either as the variables change. Would doing it on a case-by-case basic be enough?
>> 
>> For example:
>> 
>>   invalidPassword.minlength.message=Invalid password: must contain at least {0}
>> 
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: "Michael Gerber" <gerbermichi at me.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Wednesday, February 25, 2015 9:30:45 PM
>>> Subject: Re: [keycloak-dev] Internationalization for model data
>>> 
>>> invalidPassword.minlength.message=Invalid password: must contain at
>>> least ${realm.passwordpolicy.minLength}
>>> 
>>> Would need a way to resolve non message property properties.
>>> 
>>> On 2/25/2015 2:21 PM, Michael Gerber wrote:
>>>> How do we want to internationalize messages which contains variables like:
>>>> ?Invalid password: must contain at least ? + min + " upper case characters"
>>>> 
>>>> ${invalidPassword.minLength} This doesn?t work.
>>>> 
>>>> 
>>>>> Am 24.02.2015 um 14:44 schrieb Bill Burke <bburke at redhat.com>:
>>>>> 
>>>>> There's data stored in a bunch of places that should be
>>>>> internationalized.  i.e. Role descriptions.  I was thinking for this
>>>>> type of stuff, for both simplicity and ease of migration, we still
>>>>> continue to input this type of metadata through one field.  Then if the
>>>>> user wants to internationalize a piece of data, they just replace the
>>>>> text with a property variable.
>>>>> 
>>>>> Role Description: "Admin access to main application"
>>>>> 
>>>>> could be replaced with
>>>>> 
>>>>> Role Description: "${role.admin.description}"
>>>>> 
>>>>> Then the variable 'role.admin.description' is just replaced with a
>>>>> theme-based property.
>>>>> 
>>>>> This way, users dont' have to learn about internationalization until
>>>>> when and if the need it, existing deployments will still just work, and
>>>>> we don't have to expand our data model.
>>>>> 
>>>>> --
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hat
>>>>> http://bill.burkecentral.com
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>> 
>>> 
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com



From stian at redhat.com  Fri Feb 27 00:50:22 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 27 Feb 2015 00:50:22 -0500 (EST)
Subject: [keycloak-dev] Internationalization for model data
In-Reply-To: <94D06EFA-D7AA-4E44-916B-7693C3F12DB6@me.com>
References: <54EC802E.3000008@redhat.com>
	<53E98DF2-8700-4383-96A5-50B9DB2ACBAB@me.com>
	<54EE30F5.4030509@redhat.com>
	<820138412.15950557.1424931421319.JavaMail.zimbra@redhat.com>
	<54EF1730.5080507@redhat.com>
	<94D06EFA-D7AA-4E44-916B-7693C3F12DB6@me.com>
Message-ID: <87705589.16928828.1425016222688.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: "Stian Thorgersen" <stian at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Thursday, February 26, 2015 10:44:33 PM
> Subject: Re: [keycloak-dev] Internationalization for model data
> 
> I think there is a miss understanding?
> 
> messages_en.properties contains:
> invalidPassword.minlength.message=Invalid password: must contain at least {0}
> 
> PasswordPolicy contains:
> public String validate(String password) {
>     ?
>     return count < min ? "Invalid password: must contain at least " + min + "
>     numerical digits" : null;
> }
>     
> Validation contains:
> String error = realm.getPasswordPolicy().validate(credential.getValue());
> if (error != null) throw new ModelException(error);
> 
> This error messages is displayed to the end user and should be
> internationalized.
> There are two possible solutions for that, create a string which contains the
> message key and the variables or create an object which contains both.
> 
> A string construct like ${invalidPassword.minlength.message:min} can be used
> easily without a lot of changes.
> 
> Which method do you prefer?

+1 To object. The other option is more expensive (concatenating the string and parsing it again) and is just a work-around, not a proper solution IMO

> 
> Michael
> 
> > Am 26.02.2015 um 13:53 schrieb Bill Burke <bburke at redhat.com>:
> > 
> > You'll have to have printv like statements available in freemarker.
> > 
> > On 2/26/2015 1:17 AM, Stian Thorgersen wrote:
> >> I'm concerned that allowing any variable in any message would result in
> >> horrible performance. We'd have to use FreeMarker or something else to
> >> template each individual message, and it couldn't be cached either as the
> >> variables change. Would doing it on a case-by-case basic be enough?
> >> 
> >> For example:
> >> 
> >>   invalidPassword.minlength.message=Invalid password: must contain at
> >>   least {0}
> >> 
> >> ----- Original Message -----
> >>> From: "Bill Burke" <bburke at redhat.com>
> >>> To: "Michael Gerber" <gerbermichi at me.com>
> >>> Cc: keycloak-dev at lists.jboss.org
> >>> Sent: Wednesday, February 25, 2015 9:30:45 PM
> >>> Subject: Re: [keycloak-dev] Internationalization for model data
> >>> 
> >>> invalidPassword.minlength.message=Invalid password: must contain at
> >>> least ${realm.passwordpolicy.minLength}
> >>> 
> >>> Would need a way to resolve non message property properties.
> >>> 
> >>> On 2/25/2015 2:21 PM, Michael Gerber wrote:
> >>>> How do we want to internationalize messages which contains variables
> >>>> like:
> >>>> ?Invalid password: must contain at least ? + min + " upper case
> >>>> characters"
> >>>> 
> >>>> ${invalidPassword.minLength} This doesn?t work.
> >>>> 
> >>>> 
> >>>>> Am 24.02.2015 um 14:44 schrieb Bill Burke <bburke at redhat.com>:
> >>>>> 
> >>>>> There's data stored in a bunch of places that should be
> >>>>> internationalized.  i.e. Role descriptions.  I was thinking for this
> >>>>> type of stuff, for both simplicity and ease of migration, we still
> >>>>> continue to input this type of metadata through one field.  Then if the
> >>>>> user wants to internationalize a piece of data, they just replace the
> >>>>> text with a property variable.
> >>>>> 
> >>>>> Role Description: "Admin access to main application"
> >>>>> 
> >>>>> could be replaced with
> >>>>> 
> >>>>> Role Description: "${role.admin.description}"
> >>>>> 
> >>>>> Then the variable 'role.admin.description' is just replaced with a
> >>>>> theme-based property.
> >>>>> 
> >>>>> This way, users dont' have to learn about internationalization until
> >>>>> when and if the need it, existing deployments will still just work, and
> >>>>> we don't have to expand our data model.
> >>>>> 
> >>>>> --
> >>>>> Bill Burke
> >>>>> JBoss, a division of Red Hat
> >>>>> http://bill.burkecentral.com
> >>>>> _______________________________________________
> >>>>> keycloak-dev mailing list
> >>>>> keycloak-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>> 
> >>> 
> >>> --
> >>> Bill Burke
> >>> JBoss, a division of Red Hat
> >>> http://bill.burkecentral.com
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > 
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> 
> 


From stian at redhat.com  Fri Feb 27 01:08:18 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 27 Feb 2015 01:08:18 -0500 (EST)
Subject: [keycloak-dev] apps access to and refresh of facebook tokens
In-Reply-To: <764234478.20641140.1424980123285.JavaMail.zimbra@redhat.com>
References: <54EF3EDB.4060903@redhat.com>
	<1946967211.20445048.1424966958888.JavaMail.zimbra@redhat.com>
	<54EF5335.6010501@redhat.com>
	<1952677297.20565895.1424974594063.JavaMail.zimbra@redhat.com>
	<54EF68D1.5020504@redhat.com>
	<999442242.20609060.1424977452320.JavaMail.zimbra@redhat.com>
	<54EF77BE.3020901@redhat.com>
	<764234478.20641140.1424980123285.JavaMail.zimbra@redhat.com>
Message-ID: <1162494918.16931566.1425017298440.JavaMail.zimbra@redhat.com>

I don't see the need to include the facebook token into the Keycloak token. IMO the way an application would use it is (pseudo code not real code):

function callInternalEndpoint() {
  var internalToken = kc.getToken();
  if (internalToken.isExpired()) {
    internalToken = kc.updateToken()
  }
  invokeRestEndpointSecuredByKc(internalToken, someData);

}

function callExternalEndpoint() {
  var facebookToken = kc.getToken("facebook");
  if (facebookToken.isExpired()) {
    facebookToken = kc.updateToken("facebook")
  }
  invokeFacebook(facebookToken, someData);
}

I just don't see the need to refresh all these tokens at the same time. In the first function the internal token is required, in the second the facebook token is required. If you have more linked identities to the same user it could get even worse. For example to call Facebook you'd end up refreshing Keycloak, Facebook, Google, Twitter, etc tokens. That's a lot of unnecessary calls.

Also, it would be pretty complex to do. When does for example the internal token expire? I assume that would have to be the shortest amount of time for any of the included tokens to expire.

I just think we're making something quite simple into something a lot more complex for no benefit.


----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, February 26, 2015 8:48:43 PM
> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Thursday, February 26, 2015 4:45:02 PM
> > Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
> > 
> > 
> > 
> > On 2/26/2015 2:04 PM, Pedro Igor Silva wrote:
> > > ----- Original Message -----
> > >> From: "Bill Burke" <bburke at redhat.com>
> > >> To: "Pedro Igor Silva" <psilva at redhat.com>
> > >> Cc: keycloak-dev at lists.jboss.org
> > >> Sent: Thursday, February 26, 2015 3:41:21 PM
> > >> Subject: Re: [keycloak-dev] apps access to and refresh of facebook
> > >> tokens
> > >>
> > >>
> > >>
> > >> On 2/26/2015 1:16 PM, Pedro Igor Silva wrote:
> > >>> ----- Original Message -----
> > >>>> From: "Bill Burke" <bburke at redhat.com>
> > >>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> > >>>> Cc: keycloak-dev at lists.jboss.org
> > >>>> Sent: Thursday, February 26, 2015 2:09:09 PM
> > >>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook
> > >>>> tokens
> > >>>>
> > >>>>
> > >>>>
> > >>>> On 2/26/2015 11:09 AM, Pedro Igor Silva wrote:
> > >>>>> ----- Original Message -----
> > >>>>>> From: "Bill Burke" <bburke at redhat.com>
> > >>>>>> To: keycloak-dev at lists.jboss.org
> > >>>>>> Sent: Thursday, February 26, 2015 12:42:19 PM
> > >>>>>> Subject: [keycloak-dev] apps access to and refresh of facebook
> > >>>>>> tokens
> > >>>>>>
> > >>>>>> At least for openid connect, I think we hashed this through on our
> > >>>>>> dev
> > >>>>>> call today.
> > >>>>>>
> > >>>>>> * There will be a Protocol Claim Mapper that can add a facebook
> > >>>>>> token
> > >>>>>> and expiration claim to the application's access token.
> > >>>>>
> > >>>>> I would create a specific claim set for that instead of individual
> > >>>>> claims.
> > >>>>> Something like:
> > >>>>>
> > >>>>> "k_act" : {
> > >>>>>        "identity-provider": {
> > >>>>>            "id" : "facebook",
> > >>>>>            "access_token": "12312312",
> > >>>>>            "expires": "12312321"
> > >>>>>        }
> > >>>>> }
> > >>>>>
> > >>>>> (k_act : keycloak authentication context)
> > >>>>>
> > >>>>> That way we can use this k_act for exchange information regarding the
> > >>>>> authentication context when issuing access tokens or even id tokens.
> > >>>>>
> > >>>>
> > >>>> Yeah, token mapping be able to generate any json you want.
> > >>>>
> > >>>>>> * the refreshToken endpoint will accept a "scope" parameter.  The
> > >>>>>> application can then request the refresh of any external token by
> > >>>>>> specifying this token in the "scope parameter.
> > >>>>>
> > >>>>> I was thinking about adding a refreshToken endpoint to the identity
> > >>>>> broker.
> > >>>>> Isn't better ?
> > >>>>>
> > >>>>
> > >>>> A different endpoint would require the identity broker to know if the
> > >>>> app has permission to request it. Also, with my idea, you can refresh
> > >>>> multiple things with one request.
> > >>>>
> > >>>>    From an application perspective we can provide a
> > >>>> KeycloakSecurityContext.refreshToken(String... scope) method, then the
> > >>>> app has one place to request the refresh of one or more claims.
> > >>>>
> > >>>> i.e.
> > >>>>
> > >>>> token = context.refreshToken("facebook", "google");
> > >>>>
> > >>>> String facebookToken = token.getClaim("broker.facebook.token");
> > >>>
> > >>> I'm still not sure if this is right. Specially when using scopes for
> > >>> that.
> > >>>
> > >>> Regarding app permissions, know if an app has an identity provider
> > >>> enabled
> > >>> and has access to retrieve its tokens is not enough ?
> > >>>
> > >>
> > >> What does "app has an identity provider enabled" mean again?
> > >
> > > Currently, you can enable/disable identity providers for each
> > > application.
> > > I'm also going to add another option to enable/disable token retrieval,
> > > as
> > > Stian suggested.
> > >
> > 
> > What does enable/disable entity provider per application mean?  A
> > disabled "facebook" would mean that a "facebook" user couldn't visit the
> > app?
> 
> It means that an application does not supports Facebook login. We just hide
> the Facebook button from the login page for a particular application.
> 
> > 
> > >>
> > >>> And we can also provide a single place to request refresh for multiple
> > >>> claims.
> > >>>
> > >>
> > >> Err...that's the same thing I was suggesting.  IMO, most apps won't have
> > >> to manually do a refresh, they can just rely on the adapter to do it for
> > >> them.  The way I'm proposing requires no changes to adapter code and the
> > >> user can let the adapter refresh things as appropriate.
> > >
> > > Sorry, what I meant is the broker being the single place to refresh
> > > tokens.
> > > And not some where else.
> > >
> > > How are you going to specify which providers the user wants to
> > > automatically refresh tokens ? keycloak.json ?
> > 
> > In admin consonle, admin would configure the app to add the facebook
> > token claim to the JWT access token.  When the application invokes
> > refreshToken, this claim will be updated if needed.  It will all be a
> > callback through the ProtocolMapper SPI I'm creating.
> > 
> > If the application wants to refresh only one claim, then it would
> > specify a "scope" with the refreshToken request.
> > 
> > All this refreshing would happen between one API.  Then there is nothing
> > broker specific for the application, only one URL to refresh everything.
> 
> Ok.
> 
> > 
> > 
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 

From stian at redhat.com  Fri Feb 27 01:09:35 2015
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 27 Feb 2015 01:09:35 -0500 (EST)
Subject: [keycloak-dev] apps access to and refresh of facebook tokens
In-Reply-To: <764234478.20641140.1424980123285.JavaMail.zimbra@redhat.com>
References: <54EF3EDB.4060903@redhat.com>
	<1946967211.20445048.1424966958888.JavaMail.zimbra@redhat.com>
	<54EF5335.6010501@redhat.com>
	<1952677297.20565895.1424974594063.JavaMail.zimbra@redhat.com>
	<54EF68D1.5020504@redhat.com>
	<999442242.20609060.1424977452320.JavaMail.zimbra@redhat.com>
	<54EF77BE.3020901@redhat.com>
	<764234478.20641140.1424980123285.JavaMail.zimbra@redhat.com>
Message-ID: <1222183699.16932084.1425017375921.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Pedro Igor Silva" <psilva at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, February 26, 2015 8:48:43 PM
> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: "Pedro Igor Silva" <psilva at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Thursday, February 26, 2015 4:45:02 PM
> > Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
> > 
> > 
> > 
> > On 2/26/2015 2:04 PM, Pedro Igor Silva wrote:
> > > ----- Original Message -----
> > >> From: "Bill Burke" <bburke at redhat.com>
> > >> To: "Pedro Igor Silva" <psilva at redhat.com>
> > >> Cc: keycloak-dev at lists.jboss.org
> > >> Sent: Thursday, February 26, 2015 3:41:21 PM
> > >> Subject: Re: [keycloak-dev] apps access to and refresh of facebook
> > >> tokens
> > >>
> > >>
> > >>
> > >> On 2/26/2015 1:16 PM, Pedro Igor Silva wrote:
> > >>> ----- Original Message -----
> > >>>> From: "Bill Burke" <bburke at redhat.com>
> > >>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> > >>>> Cc: keycloak-dev at lists.jboss.org
> > >>>> Sent: Thursday, February 26, 2015 2:09:09 PM
> > >>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook
> > >>>> tokens
> > >>>>
> > >>>>
> > >>>>
> > >>>> On 2/26/2015 11:09 AM, Pedro Igor Silva wrote:
> > >>>>> ----- Original Message -----
> > >>>>>> From: "Bill Burke" <bburke at redhat.com>
> > >>>>>> To: keycloak-dev at lists.jboss.org
> > >>>>>> Sent: Thursday, February 26, 2015 12:42:19 PM
> > >>>>>> Subject: [keycloak-dev] apps access to and refresh of facebook
> > >>>>>> tokens
> > >>>>>>
> > >>>>>> At least for openid connect, I think we hashed this through on our
> > >>>>>> dev
> > >>>>>> call today.
> > >>>>>>
> > >>>>>> * There will be a Protocol Claim Mapper that can add a facebook
> > >>>>>> token
> > >>>>>> and expiration claim to the application's access token.
> > >>>>>
> > >>>>> I would create a specific claim set for that instead of individual
> > >>>>> claims.
> > >>>>> Something like:
> > >>>>>
> > >>>>> "k_act" : {
> > >>>>>        "identity-provider": {
> > >>>>>            "id" : "facebook",
> > >>>>>            "access_token": "12312312",
> > >>>>>            "expires": "12312321"
> > >>>>>        }
> > >>>>> }
> > >>>>>
> > >>>>> (k_act : keycloak authentication context)
> > >>>>>
> > >>>>> That way we can use this k_act for exchange information regarding the
> > >>>>> authentication context when issuing access tokens or even id tokens.
> > >>>>>
> > >>>>
> > >>>> Yeah, token mapping be able to generate any json you want.
> > >>>>
> > >>>>>> * the refreshToken endpoint will accept a "scope" parameter.  The
> > >>>>>> application can then request the refresh of any external token by
> > >>>>>> specifying this token in the "scope parameter.
> > >>>>>
> > >>>>> I was thinking about adding a refreshToken endpoint to the identity
> > >>>>> broker.
> > >>>>> Isn't better ?
> > >>>>>
> > >>>>
> > >>>> A different endpoint would require the identity broker to know if the
> > >>>> app has permission to request it. Also, with my idea, you can refresh
> > >>>> multiple things with one request.
> > >>>>
> > >>>>    From an application perspective we can provide a
> > >>>> KeycloakSecurityContext.refreshToken(String... scope) method, then the
> > >>>> app has one place to request the refresh of one or more claims.
> > >>>>
> > >>>> i.e.
> > >>>>
> > >>>> token = context.refreshToken("facebook", "google");
> > >>>>
> > >>>> String facebookToken = token.getClaim("broker.facebook.token");
> > >>>
> > >>> I'm still not sure if this is right. Specially when using scopes for
> > >>> that.
> > >>>
> > >>> Regarding app permissions, know if an app has an identity provider
> > >>> enabled
> > >>> and has access to retrieve its tokens is not enough ?
> > >>>
> > >>
> > >> What does "app has an identity provider enabled" mean again?
> > >
> > > Currently, you can enable/disable identity providers for each
> > > application.
> > > I'm also going to add another option to enable/disable token retrieval,
> > > as
> > > Stian suggested.
> > >
> > 
> > What does enable/disable entity provider per application mean?  A
> > disabled "facebook" would mean that a "facebook" user couldn't visit the
> > app?
> 
> It means that an application does not supports Facebook login. We just hide
> the Facebook button from the login page for a particular application.

As we agreed on the call we need to remove that.

We also need to add support to selecting what apps can retrieve the token.

> 
> > 
> > >>
> > >>> And we can also provide a single place to request refresh for multiple
> > >>> claims.
> > >>>
> > >>
> > >> Err...that's the same thing I was suggesting.  IMO, most apps won't have
> > >> to manually do a refresh, they can just rely on the adapter to do it for
> > >> them.  The way I'm proposing requires no changes to adapter code and the
> > >> user can let the adapter refresh things as appropriate.
> > >
> > > Sorry, what I meant is the broker being the single place to refresh
> > > tokens.
> > > And not some where else.
> > >
> > > How are you going to specify which providers the user wants to
> > > automatically refresh tokens ? keycloak.json ?
> > 
> > In admin consonle, admin would configure the app to add the facebook
> > token claim to the JWT access token.  When the application invokes
> > refreshToken, this claim will be updated if needed.  It will all be a
> > callback through the ProtocolMapper SPI I'm creating.
> > 
> > If the application wants to refresh only one claim, then it would
> > specify a "scope" with the refreshToken request.
> > 
> > All this refreshing would happen between one API.  Then there is nothing
> > broker specific for the application, only one URL to refresh everything.
> 
> Ok.
> 
> > 
> > 
> > --
> > 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 ramtinova at gmail.com  Fri Feb 27 04:24:29 2015
From: ramtinova at gmail.com (Reza Rasouli)
Date: Fri, 27 Feb 2015 12:54:29 +0330
Subject: [keycloak-dev] Updating user through Admin rest api
Message-ID: <CAO_tTRqeU4J4TXUuaCK=0U7AucteOp5FiJtK7i7MV9bV2kn1AQ@mail.gmail.com>

hi,

when I attemp to update user through the following api call :
PUT /admin/realms/{realm}/users/{username}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150227/e336b285/attachment.html 

From ramtinova at gmail.com  Fri Feb 27 04:28:05 2015
From: ramtinova at gmail.com (Reza Rasouli)
Date: Fri, 27 Feb 2015 12:58:05 +0330
Subject: [keycloak-dev] Updating user through Admin rest api
In-Reply-To: <CAO_tTRqeU4J4TXUuaCK=0U7AucteOp5FiJtK7i7MV9bV2kn1AQ@mail.gmail.com>
References: <CAO_tTRqeU4J4TXUuaCK=0U7AucteOp5FiJtK7i7MV9bV2kn1AQ@mail.gmail.com>
Message-ID: <CAO_tTRoM5acUq-5CD1byTw6-cDxhDKJSN-uCGdcNp+aSD8Y4kg@mail.gmail.com>

( I am sorry I hit Tab+Enter on mistake)

hi all,

when I attemp to update user through the following api call :

> PUT /admin/realms/{realm}/users/{username}


with the following request body :
 it seems other user information such as email, firstname and lastname gets
wiped :

{"enabled":true}


shoud the request body on updating the user provide all necessary user
field
such as username , email , first and last name ?


Thanks.

On Fri, Feb 27, 2015 at 12:54 PM, Reza Rasouli <ramtinova at gmail.com> wrote:

> hi,
>
> when I attemp to update user through the following api call :
> PUT /admin/realms/{realm}/users/{username}
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150227/9efa2fe3/attachment.html 

From mposolda at redhat.com  Fri Feb 27 07:17:57 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 27 Feb 2015 13:17:57 +0100
Subject: [keycloak-dev] apps access to and refresh of facebook tokens
In-Reply-To: <1162494918.16931566.1425017298440.JavaMail.zimbra@redhat.com>
References: <54EF3EDB.4060903@redhat.com>	<1946967211.20445048.1424966958888.JavaMail.zimbra@redhat.com>	<54EF5335.6010501@redhat.com>	<1952677297.20565895.1424974594063.JavaMail.zimbra@redhat.com>	<54EF68D1.5020504@redhat.com>	<999442242.20609060.1424977452320.JavaMail.zimbra@redhat.com>	<54EF77BE.3020901@redhat.com>	<764234478.20641140.1424980123285.JavaMail.zimbra@redhat.com>
	<1162494918.16931566.1425017298440.JavaMail.zimbra@redhat.com>
Message-ID: <54F06075.5090300@redhat.com>

One thing to consider: Does all identity brokers support refreshing of 
tokens? For example it seems that Facebook doesn't (not 100% sure) and 
instead they have long-lived access tokens. So when application wants to 
refresh expired Facebook access token, it would need to browser redirect 
to Keycloak with "k_idp_hint=facebook" and KC will need to redirect to 
Facebook and then back to app with refreshed token.

For minimum of HTTP requests needed, but good usability I would do it 
like this:

* Access token sent from KC to the application embeds all 3rd party 
access tokens accessible by configured claims. There is risk application 
doesn't need them all for particular request, but IMO it is better to 
have 1 HTTP request with bigger JSON accessToken response then another 
separate request from application to KC just to retrieve Facebook access 
token.

* Adapter has method on RefreshableKeycloakSecurityContext like this:

updateThirdpartyToken("facebook", 10, httpFacade)

which will update facebook access token just if it's going to expire in 
next 10 seconds. Otherwise no network calls needed. Adapter should know 
when is Facebook access token going to expire from the KC accessToken 
(It should have all needed info). If token is going to expire, 
HttpFacade may be needed to perform redirect to KC with idp_hint.

Maybe identity broker should allow to specify if provider supports 
refreshing tokens (in this case backend refresh from app to KC could 
happen), but otherwise it would really need to go through browser 
redirects IMO.

Marek

On 27.2.2015 07:08, Stian Thorgersen wrote:
> I don't see the need to include the facebook token into the Keycloak token. IMO the way an application would use it is (pseudo code not real code):
>
> function callInternalEndpoint() {
>    var internalToken = kc.getToken();
>    if (internalToken.isExpired()) {
>      internalToken = kc.updateToken()
>    }
>    invokeRestEndpointSecuredByKc(internalToken, someData);
>
> }
>
> function callExternalEndpoint() {
>    var facebookToken = kc.getToken("facebook");
>    if (facebookToken.isExpired()) {
>      facebookToken = kc.updateToken("facebook")
>    }
>    invokeFacebook(facebookToken, someData);
> }
>
> I just don't see the need to refresh all these tokens at the same time. In the first function the internal token is required, in the second the facebook token is required. If you have more linked identities to the same user it could get even worse. For example to call Facebook you'd end up refreshing Keycloak, Facebook, Google, Twitter, etc tokens. That's a lot of unnecessary calls.
>
> Also, it would be pretty complex to do. When does for example the internal token expire? I assume that would have to be the shortest amount of time for any of the included tokens to expire.
>
> I just think we're making something quite simple into something a lot more complex for no benefit.
>
>
> ----- Original Message -----
>> From: "Pedro Igor Silva" <psilva at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Thursday, February 26, 2015 8:48:43 PM
>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Thursday, February 26, 2015 4:45:02 PM
>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
>>>
>>>
>>>
>>> On 2/26/2015 2:04 PM, Pedro Igor Silva wrote:
>>>> ----- Original Message -----
>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>> Sent: Thursday, February 26, 2015 3:41:21 PM
>>>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook
>>>>> tokens
>>>>>
>>>>>
>>>>>
>>>>> On 2/26/2015 1:16 PM, Pedro Igor Silva wrote:
>>>>>> ----- Original Message -----
>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>> Sent: Thursday, February 26, 2015 2:09:09 PM
>>>>>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook
>>>>>>> tokens
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2/26/2015 11:09 AM, Pedro Igor Silva wrote:
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>>>> Sent: Thursday, February 26, 2015 12:42:19 PM
>>>>>>>>> Subject: [keycloak-dev] apps access to and refresh of facebook
>>>>>>>>> tokens
>>>>>>>>>
>>>>>>>>> At least for openid connect, I think we hashed this through on our
>>>>>>>>> dev
>>>>>>>>> call today.
>>>>>>>>>
>>>>>>>>> * There will be a Protocol Claim Mapper that can add a facebook
>>>>>>>>> token
>>>>>>>>> and expiration claim to the application's access token.
>>>>>>>> I would create a specific claim set for that instead of individual
>>>>>>>> claims.
>>>>>>>> Something like:
>>>>>>>>
>>>>>>>> "k_act" : {
>>>>>>>>         "identity-provider": {
>>>>>>>>             "id" : "facebook",
>>>>>>>>             "access_token": "12312312",
>>>>>>>>             "expires": "12312321"
>>>>>>>>         }
>>>>>>>> }
>>>>>>>>
>>>>>>>> (k_act : keycloak authentication context)
>>>>>>>>
>>>>>>>> That way we can use this k_act for exchange information regarding the
>>>>>>>> authentication context when issuing access tokens or even id tokens.
>>>>>>>>
>>>>>>> Yeah, token mapping be able to generate any json you want.
>>>>>>>
>>>>>>>>> * the refreshToken endpoint will accept a "scope" parameter.  The
>>>>>>>>> application can then request the refresh of any external token by
>>>>>>>>> specifying this token in the "scope parameter.
>>>>>>>> I was thinking about adding a refreshToken endpoint to the identity
>>>>>>>> broker.
>>>>>>>> Isn't better ?
>>>>>>>>
>>>>>>> A different endpoint would require the identity broker to know if the
>>>>>>> app has permission to request it. Also, with my idea, you can refresh
>>>>>>> multiple things with one request.
>>>>>>>
>>>>>>>     From an application perspective we can provide a
>>>>>>> KeycloakSecurityContext.refreshToken(String... scope) method, then the
>>>>>>> app has one place to request the refresh of one or more claims.
>>>>>>>
>>>>>>> i.e.
>>>>>>>
>>>>>>> token = context.refreshToken("facebook", "google");
>>>>>>>
>>>>>>> String facebookToken = token.getClaim("broker.facebook.token");
>>>>>> I'm still not sure if this is right. Specially when using scopes for
>>>>>> that.
>>>>>>
>>>>>> Regarding app permissions, know if an app has an identity provider
>>>>>> enabled
>>>>>> and has access to retrieve its tokens is not enough ?
>>>>>>
>>>>> What does "app has an identity provider enabled" mean again?
>>>> Currently, you can enable/disable identity providers for each
>>>> application.
>>>> I'm also going to add another option to enable/disable token retrieval,
>>>> as
>>>> Stian suggested.
>>>>
>>> What does enable/disable entity provider per application mean?  A
>>> disabled "facebook" would mean that a "facebook" user couldn't visit the
>>> app?
>> It means that an application does not supports Facebook login. We just hide
>> the Facebook button from the login page for a particular application.
>>
>>>>>> And we can also provide a single place to request refresh for multiple
>>>>>> claims.
>>>>>>
>>>>> Err...that's the same thing I was suggesting.  IMO, most apps won't have
>>>>> to manually do a refresh, they can just rely on the adapter to do it for
>>>>> them.  The way I'm proposing requires no changes to adapter code and the
>>>>> user can let the adapter refresh things as appropriate.
>>>> Sorry, what I meant is the broker being the single place to refresh
>>>> tokens.
>>>> And not some where else.
>>>>
>>>> How are you going to specify which providers the user wants to
>>>> automatically refresh tokens ? keycloak.json ?
>>> In admin consonle, admin would configure the app to add the facebook
>>> token claim to the JWT access token.  When the application invokes
>>> refreshToken, this claim will be updated if needed.  It will all be a
>>> callback through the ProtocolMapper SPI I'm creating.
>>>
>>> If the application wants to refresh only one claim, then it would
>>> specify a "scope" with the refreshToken request.
>>>
>>> All this refreshing would happen between one API.  Then there is nothing
>>> broker specific for the application, only one URL to refresh everything.
>> Ok.
>>
>>>
>>> --
>>> 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 mposolda at redhat.com  Fri Feb 27 07:22:13 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 27 Feb 2015 13:22:13 +0100
Subject: [keycloak-dev] apps access to and refresh of facebook tokens
In-Reply-To: <1222183699.16932084.1425017375921.JavaMail.zimbra@redhat.com>
References: <54EF3EDB.4060903@redhat.com>	<1946967211.20445048.1424966958888.JavaMail.zimbra@redhat.com>	<54EF5335.6010501@redhat.com>	<1952677297.20565895.1424974594063.JavaMail.zimbra@redhat.com>	<54EF68D1.5020504@redhat.com>	<999442242.20609060.1424977452320.JavaMail.zimbra@redhat.com>	<54EF77BE.3020901@redhat.com>	<764234478.20641140.1424980123285.JavaMail.zimbra@redhat.com>
	<1222183699.16932084.1425017375921.JavaMail.zimbra@redhat.com>
Message-ID: <54F06175.1050600@redhat.com>

On 27.2.2015 07:09, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Pedro Igor Silva" <psilva at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Thursday, February 26, 2015 8:48:43 PM
>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Thursday, February 26, 2015 4:45:02 PM
>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
>>>
>>>
>>>
>>> On 2/26/2015 2:04 PM, Pedro Igor Silva wrote:
>>>> ----- Original Message -----
>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>> Sent: Thursday, February 26, 2015 3:41:21 PM
>>>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook
>>>>> tokens
>>>>>
>>>>>
>>>>>
>>>>> On 2/26/2015 1:16 PM, Pedro Igor Silva wrote:
>>>>>> ----- Original Message -----
>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>> Sent: Thursday, February 26, 2015 2:09:09 PM
>>>>>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook
>>>>>>> tokens
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2/26/2015 11:09 AM, Pedro Igor Silva wrote:
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>>>> Sent: Thursday, February 26, 2015 12:42:19 PM
>>>>>>>>> Subject: [keycloak-dev] apps access to and refresh of facebook
>>>>>>>>> tokens
>>>>>>>>>
>>>>>>>>> At least for openid connect, I think we hashed this through on our
>>>>>>>>> dev
>>>>>>>>> call today.
>>>>>>>>>
>>>>>>>>> * There will be a Protocol Claim Mapper that can add a facebook
>>>>>>>>> token
>>>>>>>>> and expiration claim to the application's access token.
>>>>>>>> I would create a specific claim set for that instead of individual
>>>>>>>> claims.
>>>>>>>> Something like:
>>>>>>>>
>>>>>>>> "k_act" : {
>>>>>>>>         "identity-provider": {
>>>>>>>>             "id" : "facebook",
>>>>>>>>             "access_token": "12312312",
>>>>>>>>             "expires": "12312321"
>>>>>>>>         }
>>>>>>>> }
>>>>>>>>
>>>>>>>> (k_act : keycloak authentication context)
>>>>>>>>
>>>>>>>> That way we can use this k_act for exchange information regarding the
>>>>>>>> authentication context when issuing access tokens or even id tokens.
>>>>>>>>
>>>>>>> Yeah, token mapping be able to generate any json you want.
>>>>>>>
>>>>>>>>> * the refreshToken endpoint will accept a "scope" parameter.  The
>>>>>>>>> application can then request the refresh of any external token by
>>>>>>>>> specifying this token in the "scope parameter.
>>>>>>>> I was thinking about adding a refreshToken endpoint to the identity
>>>>>>>> broker.
>>>>>>>> Isn't better ?
>>>>>>>>
>>>>>>> A different endpoint would require the identity broker to know if the
>>>>>>> app has permission to request it. Also, with my idea, you can refresh
>>>>>>> multiple things with one request.
>>>>>>>
>>>>>>>     From an application perspective we can provide a
>>>>>>> KeycloakSecurityContext.refreshToken(String... scope) method, then the
>>>>>>> app has one place to request the refresh of one or more claims.
>>>>>>>
>>>>>>> i.e.
>>>>>>>
>>>>>>> token = context.refreshToken("facebook", "google");
>>>>>>>
>>>>>>> String facebookToken = token.getClaim("broker.facebook.token");
>>>>>> I'm still not sure if this is right. Specially when using scopes for
>>>>>> that.
>>>>>>
>>>>>> Regarding app permissions, know if an app has an identity provider
>>>>>> enabled
>>>>>> and has access to retrieve its tokens is not enough ?
>>>>>>
>>>>> What does "app has an identity provider enabled" mean again?
>>>> Currently, you can enable/disable identity providers for each
>>>> application.
>>>> I'm also going to add another option to enable/disable token retrieval,
>>>> as
>>>> Stian suggested.
>>>>
>>> What does enable/disable entity provider per application mean?  A
>>> disabled "facebook" would mean that a "facebook" user couldn't visit the
>>> app?
>> It means that an application does not supports Facebook login. We just hide
>> the Facebook button from the login page for a particular application.
> As we agreed on the call we need to remove that.
+1, Keycloak is SSO. Even if "application1" doesn't support Facebook 
button on login screen, user can still login via Facebook with 
"application2" and then go back to "application1", which will 
authenticate him automatically due to SSO. So disabling Facebook button 
on login screen really doesn't prevent user from login into Keycloak 
through Facebook.

Marek
>
> We also need to add support to selecting what apps can retrieve the token.
>
>>>>>> And we can also provide a single place to request refresh for multiple
>>>>>> claims.
>>>>>>
>>>>> Err...that's the same thing I was suggesting.  IMO, most apps won't have
>>>>> to manually do a refresh, they can just rely on the adapter to do it for
>>>>> them.  The way I'm proposing requires no changes to adapter code and the
>>>>> user can let the adapter refresh things as appropriate.
>>>> Sorry, what I meant is the broker being the single place to refresh
>>>> tokens.
>>>> And not some where else.
>>>>
>>>> How are you going to specify which providers the user wants to
>>>> automatically refresh tokens ? keycloak.json ?
>>> In admin consonle, admin would configure the app to add the facebook
>>> token claim to the JWT access token.  When the application invokes
>>> refreshToken, this claim will be updated if needed.  It will all be a
>>> callback through the ProtocolMapper SPI I'm creating.
>>>
>>> If the application wants to refresh only one claim, then it would
>>> specify a "scope" with the refreshToken request.
>>>
>>> All this refreshing would happen between one API.  Then there is nothing
>>> broker specific for the application, only one URL to refresh everything.
>> Ok.
>>
>>>
>>> --
>>> 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 psilva at redhat.com  Fri Feb 27 07:42:14 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 27 Feb 2015 07:42:14 -0500 (EST)
Subject: [keycloak-dev] apps access to and refresh of facebook tokens
In-Reply-To: <1222183699.16932084.1425017375921.JavaMail.zimbra@redhat.com>
References: <54EF3EDB.4060903@redhat.com> <54EF5335.6010501@redhat.com>
	<1952677297.20565895.1424974594063.JavaMail.zimbra@redhat.com>
	<54EF68D1.5020504@redhat.com>
	<999442242.20609060.1424977452320.JavaMail.zimbra@redhat.com>
	<54EF77BE.3020901@redhat.com>
	<764234478.20641140.1424980123285.JavaMail.zimbra@redhat.com>
	<1222183699.16932084.1425017375921.JavaMail.zimbra@redhat.com>
Message-ID: <477781109.21098066.1425040934766.JavaMail.zimbra@redhat.com>


----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Friday, February 27, 2015 3:09:35 AM
> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
> 
> 
> 
> ----- Original Message -----
> > From: "Pedro Igor Silva" <psilva at redhat.com>
> > To: "Bill Burke" <bburke at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Thursday, February 26, 2015 8:48:43 PM
> > Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
> > 
> > ----- Original Message -----
> > > From: "Bill Burke" <bburke at redhat.com>
> > > To: "Pedro Igor Silva" <psilva at redhat.com>
> > > Cc: keycloak-dev at lists.jboss.org
> > > Sent: Thursday, February 26, 2015 4:45:02 PM
> > > Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
> > > 
> > > 
> > > 
> > > On 2/26/2015 2:04 PM, Pedro Igor Silva wrote:
> > > > ----- Original Message -----
> > > >> From: "Bill Burke" <bburke at redhat.com>
> > > >> To: "Pedro Igor Silva" <psilva at redhat.com>
> > > >> Cc: keycloak-dev at lists.jboss.org
> > > >> Sent: Thursday, February 26, 2015 3:41:21 PM
> > > >> Subject: Re: [keycloak-dev] apps access to and refresh of facebook
> > > >> tokens
> > > >>
> > > >>
> > > >>
> > > >> On 2/26/2015 1:16 PM, Pedro Igor Silva wrote:
> > > >>> ----- Original Message -----
> > > >>>> From: "Bill Burke" <bburke at redhat.com>
> > > >>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> > > >>>> Cc: keycloak-dev at lists.jboss.org
> > > >>>> Sent: Thursday, February 26, 2015 2:09:09 PM
> > > >>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook
> > > >>>> tokens
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> On 2/26/2015 11:09 AM, Pedro Igor Silva wrote:
> > > >>>>> ----- Original Message -----
> > > >>>>>> From: "Bill Burke" <bburke at redhat.com>
> > > >>>>>> To: keycloak-dev at lists.jboss.org
> > > >>>>>> Sent: Thursday, February 26, 2015 12:42:19 PM
> > > >>>>>> Subject: [keycloak-dev] apps access to and refresh of facebook
> > > >>>>>> tokens
> > > >>>>>>
> > > >>>>>> At least for openid connect, I think we hashed this through on our
> > > >>>>>> dev
> > > >>>>>> call today.
> > > >>>>>>
> > > >>>>>> * There will be a Protocol Claim Mapper that can add a facebook
> > > >>>>>> token
> > > >>>>>> and expiration claim to the application's access token.
> > > >>>>>
> > > >>>>> I would create a specific claim set for that instead of individual
> > > >>>>> claims.
> > > >>>>> Something like:
> > > >>>>>
> > > >>>>> "k_act" : {
> > > >>>>>        "identity-provider": {
> > > >>>>>            "id" : "facebook",
> > > >>>>>            "access_token": "12312312",
> > > >>>>>            "expires": "12312321"
> > > >>>>>        }
> > > >>>>> }
> > > >>>>>
> > > >>>>> (k_act : keycloak authentication context)
> > > >>>>>
> > > >>>>> That way we can use this k_act for exchange information regarding
> > > >>>>> the
> > > >>>>> authentication context when issuing access tokens or even id
> > > >>>>> tokens.
> > > >>>>>
> > > >>>>
> > > >>>> Yeah, token mapping be able to generate any json you want.
> > > >>>>
> > > >>>>>> * the refreshToken endpoint will accept a "scope" parameter.  The
> > > >>>>>> application can then request the refresh of any external token by
> > > >>>>>> specifying this token in the "scope parameter.
> > > >>>>>
> > > >>>>> I was thinking about adding a refreshToken endpoint to the identity
> > > >>>>> broker.
> > > >>>>> Isn't better ?
> > > >>>>>
> > > >>>>
> > > >>>> A different endpoint would require the identity broker to know if
> > > >>>> the
> > > >>>> app has permission to request it. Also, with my idea, you can
> > > >>>> refresh
> > > >>>> multiple things with one request.
> > > >>>>
> > > >>>>    From an application perspective we can provide a
> > > >>>> KeycloakSecurityContext.refreshToken(String... scope) method, then
> > > >>>> the
> > > >>>> app has one place to request the refresh of one or more claims.
> > > >>>>
> > > >>>> i.e.
> > > >>>>
> > > >>>> token = context.refreshToken("facebook", "google");
> > > >>>>
> > > >>>> String facebookToken = token.getClaim("broker.facebook.token");
> > > >>>
> > > >>> I'm still not sure if this is right. Specially when using scopes for
> > > >>> that.
> > > >>>
> > > >>> Regarding app permissions, know if an app has an identity provider
> > > >>> enabled
> > > >>> and has access to retrieve its tokens is not enough ?
> > > >>>
> > > >>
> > > >> What does "app has an identity provider enabled" mean again?
> > > >
> > > > Currently, you can enable/disable identity providers for each
> > > > application.
> > > > I'm also going to add another option to enable/disable token retrieval,
> > > > as
> > > > Stian suggested.
> > > >
> > > 
> > > What does enable/disable entity provider per application mean?  A
> > > disabled "facebook" would mean that a "facebook" user couldn't visit the
> > > app?
> > 
> > It means that an application does not supports Facebook login. We just hide
> > the Facebook button from the login page for a particular application.
> 
> As we agreed on the call we need to remove that.
> 
> We also need to add support to selecting what apps can retrieve the token.

I've already added support to enable/disable token retrieval by apps.

> 
> > 
> > > 
> > > >>
> > > >>> And we can also provide a single place to request refresh for
> > > >>> multiple
> > > >>> claims.
> > > >>>
> > > >>
> > > >> Err...that's the same thing I was suggesting.  IMO, most apps won't
> > > >> have
> > > >> to manually do a refresh, they can just rely on the adapter to do it
> > > >> for
> > > >> them.  The way I'm proposing requires no changes to adapter code and
> > > >> the
> > > >> user can let the adapter refresh things as appropriate.
> > > >
> > > > Sorry, what I meant is the broker being the single place to refresh
> > > > tokens.
> > > > And not some where else.
> > > >
> > > > How are you going to specify which providers the user wants to
> > > > automatically refresh tokens ? keycloak.json ?
> > > 
> > > In admin consonle, admin would configure the app to add the facebook
> > > token claim to the JWT access token.  When the application invokes
> > > refreshToken, this claim will be updated if needed.  It will all be a
> > > callback through the ProtocolMapper SPI I'm creating.
> > > 
> > > If the application wants to refresh only one claim, then it would
> > > specify a "scope" with the refreshToken request.
> > > 
> > > All this refreshing would happen between one API.  Then there is nothing
> > > broker specific for the application, only one URL to refresh everything.
> > 
> > Ok.
> > 
> > > 
> > > 
> > > --
> > > 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 psilva at redhat.com  Fri Feb 27 08:09:53 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 27 Feb 2015 08:09:53 -0500 (EST)
Subject: [keycloak-dev] apps access to and refresh of facebook tokens
In-Reply-To: <54F06075.5090300@redhat.com>
References: <54EF3EDB.4060903@redhat.com>
	<1952677297.20565895.1424974594063.JavaMail.zimbra@redhat.com>
	<54EF68D1.5020504@redhat.com>
	<999442242.20609060.1424977452320.JavaMail.zimbra@redhat.com>
	<54EF77BE.3020901@redhat.com>
	<764234478.20641140.1424980123285.JavaMail.zimbra@redhat.com>
	<1162494918.16931566.1425017298440.JavaMail.zimbra@redhat.com>
	<54F06075.5090300@redhat.com>
Message-ID: <441046235.21111280.1425042593519.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, February 27, 2015 9:17:57 AM
> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
> 
> One thing to consider: Does all identity brokers support refreshing of
> tokens? For example it seems that Facebook doesn't (not 100% sure) and
> instead they have long-lived access tokens. So when application wants to
> refresh expired Facebook access token, it would need to browser redirect
> to Keycloak with "k_idp_hint=facebook" and KC will need to redirect to
> Facebook and then back to app with refreshed token.
> 
> For minimum of HTTP requests needed, but good usability I would do it
> like this:
> 
> * Access token sent from KC to the application embeds all 3rd party
> access tokens accessible by configured claims. There is risk application
> doesn't need them all for particular request, but IMO it is better to
> have 1 HTTP request with bigger JSON accessToken response then another
> separate request from application to KC just to retrieve Facebook access
> token.
> 
> * Adapter has method on RefreshableKeycloakSecurityContext like this:
> 
> updateThirdpartyToken("facebook", 10, httpFacade)
> 
> which will update facebook access token just if it's going to expire in
> next 10 seconds. Otherwise no network calls needed. Adapter should know
> when is Facebook access token going to expire from the KC accessToken
> (It should have all needed info). If token is going to expire,
> HttpFacade may be needed to perform redirect to KC with idp_hint.

Like I said during our meeting, different providers may have different strategies to refresh tokens even when using standard protocols. This is the case of Facebook. I think you are right, Facebook does not provides a refresh token. So we always need a redirect in order to get a fresh one if token expires or was invalidated. But I think Bill is considering that some how with his solution.

I understand the usability arguments for embedding tokens in KC access token and also the new method to refresh them. But I still think that we don't need that. 

IMO, each provide should implement how its tokens are refreshed. We would just need a new endpoint in broker. And just let apps invoke this endpoint in order to refresh tokens. The code for doing that is very simple and minimal without bring complexity to apps. 

> 
> Maybe identity broker should allow to specify if provider supports
> refreshing tokens (in this case backend refresh from app to KC could
> happen), but otherwise it would really need to go through browser
> redirects IMO.
> 
> Marek
> 
> On 27.2.2015 07:08, Stian Thorgersen wrote:
> > I don't see the need to include the facebook token into the Keycloak token.
> > IMO the way an application would use it is (pseudo code not real code):
> >
> > function callInternalEndpoint() {
> >    var internalToken = kc.getToken();
> >    if (internalToken.isExpired()) {
> >      internalToken = kc.updateToken()
> >    }
> >    invokeRestEndpointSecuredByKc(internalToken, someData);
> >
> > }
> >
> > function callExternalEndpoint() {
> >    var facebookToken = kc.getToken("facebook");
> >    if (facebookToken.isExpired()) {
> >      facebookToken = kc.updateToken("facebook")
> >    }
> >    invokeFacebook(facebookToken, someData);
> > }
> >
> > I just don't see the need to refresh all these tokens at the same time. In
> > the first function the internal token is required, in the second the
> > facebook token is required. If you have more linked identities to the same
> > user it could get even worse. For example to call Facebook you'd end up
> > refreshing Keycloak, Facebook, Google, Twitter, etc tokens. That's a lot
> > of unnecessary calls.
> >
> > Also, it would be pretty complex to do. When does for example the internal
> > token expire? I assume that would have to be the shortest amount of time
> > for any of the included tokens to expire.
> >
> > I just think we're making something quite simple into something a lot more
> > complex for no benefit.
> >
> >
> > ----- Original Message -----
> >> From: "Pedro Igor Silva" <psilva at redhat.com>
> >> To: "Bill Burke" <bburke at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, February 26, 2015 8:48:43 PM
> >> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
> >>
> >> ----- Original Message -----
> >>> From: "Bill Burke" <bburke at redhat.com>
> >>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>> Cc: keycloak-dev at lists.jboss.org
> >>> Sent: Thursday, February 26, 2015 4:45:02 PM
> >>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
> >>>
> >>>
> >>>
> >>> On 2/26/2015 2:04 PM, Pedro Igor Silva wrote:
> >>>> ----- Original Message -----
> >>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>> Sent: Thursday, February 26, 2015 3:41:21 PM
> >>>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook
> >>>>> tokens
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 2/26/2015 1:16 PM, Pedro Igor Silva wrote:
> >>>>>> ----- Original Message -----
> >>>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>>>> Sent: Thursday, February 26, 2015 2:09:09 PM
> >>>>>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook
> >>>>>>> tokens
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On 2/26/2015 11:09 AM, Pedro Igor Silva wrote:
> >>>>>>>> ----- Original Message -----
> >>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>>>>> Sent: Thursday, February 26, 2015 12:42:19 PM
> >>>>>>>>> Subject: [keycloak-dev] apps access to and refresh of facebook
> >>>>>>>>> tokens
> >>>>>>>>>
> >>>>>>>>> At least for openid connect, I think we hashed this through on our
> >>>>>>>>> dev
> >>>>>>>>> call today.
> >>>>>>>>>
> >>>>>>>>> * There will be a Protocol Claim Mapper that can add a facebook
> >>>>>>>>> token
> >>>>>>>>> and expiration claim to the application's access token.
> >>>>>>>> I would create a specific claim set for that instead of individual
> >>>>>>>> claims.
> >>>>>>>> Something like:
> >>>>>>>>
> >>>>>>>> "k_act" : {
> >>>>>>>>         "identity-provider": {
> >>>>>>>>             "id" : "facebook",
> >>>>>>>>             "access_token": "12312312",
> >>>>>>>>             "expires": "12312321"
> >>>>>>>>         }
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> (k_act : keycloak authentication context)
> >>>>>>>>
> >>>>>>>> That way we can use this k_act for exchange information regarding
> >>>>>>>> the
> >>>>>>>> authentication context when issuing access tokens or even id tokens.
> >>>>>>>>
> >>>>>>> Yeah, token mapping be able to generate any json you want.
> >>>>>>>
> >>>>>>>>> * the refreshToken endpoint will accept a "scope" parameter.  The
> >>>>>>>>> application can then request the refresh of any external token by
> >>>>>>>>> specifying this token in the "scope parameter.
> >>>>>>>> I was thinking about adding a refreshToken endpoint to the identity
> >>>>>>>> broker.
> >>>>>>>> Isn't better ?
> >>>>>>>>
> >>>>>>> A different endpoint would require the identity broker to know if the
> >>>>>>> app has permission to request it. Also, with my idea, you can refresh
> >>>>>>> multiple things with one request.
> >>>>>>>
> >>>>>>>     From an application perspective we can provide a
> >>>>>>> KeycloakSecurityContext.refreshToken(String... scope) method, then
> >>>>>>> the
> >>>>>>> app has one place to request the refresh of one or more claims.
> >>>>>>>
> >>>>>>> i.e.
> >>>>>>>
> >>>>>>> token = context.refreshToken("facebook", "google");
> >>>>>>>
> >>>>>>> String facebookToken = token.getClaim("broker.facebook.token");
> >>>>>> I'm still not sure if this is right. Specially when using scopes for
> >>>>>> that.
> >>>>>>
> >>>>>> Regarding app permissions, know if an app has an identity provider
> >>>>>> enabled
> >>>>>> and has access to retrieve its tokens is not enough ?
> >>>>>>
> >>>>> What does "app has an identity provider enabled" mean again?
> >>>> Currently, you can enable/disable identity providers for each
> >>>> application.
> >>>> I'm also going to add another option to enable/disable token retrieval,
> >>>> as
> >>>> Stian suggested.
> >>>>
> >>> What does enable/disable entity provider per application mean?  A
> >>> disabled "facebook" would mean that a "facebook" user couldn't visit the
> >>> app?
> >> It means that an application does not supports Facebook login. We just
> >> hide
> >> the Facebook button from the login page for a particular application.
> >>
> >>>>>> And we can also provide a single place to request refresh for multiple
> >>>>>> claims.
> >>>>>>
> >>>>> Err...that's the same thing I was suggesting.  IMO, most apps won't
> >>>>> have
> >>>>> to manually do a refresh, they can just rely on the adapter to do it
> >>>>> for
> >>>>> them.  The way I'm proposing requires no changes to adapter code and
> >>>>> the
> >>>>> user can let the adapter refresh things as appropriate.
> >>>> Sorry, what I meant is the broker being the single place to refresh
> >>>> tokens.
> >>>> And not some where else.
> >>>>
> >>>> How are you going to specify which providers the user wants to
> >>>> automatically refresh tokens ? keycloak.json ?
> >>> In admin consonle, admin would configure the app to add the facebook
> >>> token claim to the JWT access token.  When the application invokes
> >>> refreshToken, this claim will be updated if needed.  It will all be a
> >>> callback through the ProtocolMapper SPI I'm creating.
> >>>
> >>> If the application wants to refresh only one claim, then it would
> >>> specify a "scope" with the refreshToken request.
> >>>
> >>> All this refreshing would happen between one API.  Then there is nothing
> >>> broker specific for the application, only one URL to refresh everything.
> >> Ok.
> >>
> >>>
> >>> --
> >>> 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 psilva at redhat.com  Fri Feb 27 08:21:14 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 27 Feb 2015 08:21:14 -0500 (EST)
Subject: [keycloak-dev] apps access to and refresh of facebook tokens
In-Reply-To: <54F06175.1050600@redhat.com>
References: <54EF3EDB.4060903@redhat.com>
	<1952677297.20565895.1424974594063.JavaMail.zimbra@redhat.com>
	<54EF68D1.5020504@redhat.com>
	<999442242.20609060.1424977452320.JavaMail.zimbra@redhat.com>
	<54EF77BE.3020901@redhat.com>
	<764234478.20641140.1424980123285.JavaMail.zimbra@redhat.com>
	<1222183699.16932084.1425017375921.JavaMail.zimbra@redhat.com>
	<54F06175.1050600@redhat.com>
Message-ID: <614412750.21116073.1425043274164.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, "Pedro Igor Silva" <psilva at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Friday, February 27, 2015 9:22:13 AM
> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
> 
> On 27.2.2015 07:09, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Pedro Igor Silva" <psilva at redhat.com>
> >> To: "Bill Burke" <bburke at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, February 26, 2015 8:48:43 PM
> >> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
> >>
> >> ----- Original Message -----
> >>> From: "Bill Burke" <bburke at redhat.com>
> >>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>> Cc: keycloak-dev at lists.jboss.org
> >>> Sent: Thursday, February 26, 2015 4:45:02 PM
> >>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
> >>>
> >>>
> >>>
> >>> On 2/26/2015 2:04 PM, Pedro Igor Silva wrote:
> >>>> ----- Original Message -----
> >>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>> Sent: Thursday, February 26, 2015 3:41:21 PM
> >>>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook
> >>>>> tokens
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 2/26/2015 1:16 PM, Pedro Igor Silva wrote:
> >>>>>> ----- Original Message -----
> >>>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>>>> Sent: Thursday, February 26, 2015 2:09:09 PM
> >>>>>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook
> >>>>>>> tokens
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On 2/26/2015 11:09 AM, Pedro Igor Silva wrote:
> >>>>>>>> ----- Original Message -----
> >>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>>>>> Sent: Thursday, February 26, 2015 12:42:19 PM
> >>>>>>>>> Subject: [keycloak-dev] apps access to and refresh of facebook
> >>>>>>>>> tokens
> >>>>>>>>>
> >>>>>>>>> At least for openid connect, I think we hashed this through on our
> >>>>>>>>> dev
> >>>>>>>>> call today.
> >>>>>>>>>
> >>>>>>>>> * There will be a Protocol Claim Mapper that can add a facebook
> >>>>>>>>> token
> >>>>>>>>> and expiration claim to the application's access token.
> >>>>>>>> I would create a specific claim set for that instead of individual
> >>>>>>>> claims.
> >>>>>>>> Something like:
> >>>>>>>>
> >>>>>>>> "k_act" : {
> >>>>>>>>         "identity-provider": {
> >>>>>>>>             "id" : "facebook",
> >>>>>>>>             "access_token": "12312312",
> >>>>>>>>             "expires": "12312321"
> >>>>>>>>         }
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> (k_act : keycloak authentication context)
> >>>>>>>>
> >>>>>>>> That way we can use this k_act for exchange information regarding
> >>>>>>>> the
> >>>>>>>> authentication context when issuing access tokens or even id tokens.
> >>>>>>>>
> >>>>>>> Yeah, token mapping be able to generate any json you want.
> >>>>>>>
> >>>>>>>>> * the refreshToken endpoint will accept a "scope" parameter.  The
> >>>>>>>>> application can then request the refresh of any external token by
> >>>>>>>>> specifying this token in the "scope parameter.
> >>>>>>>> I was thinking about adding a refreshToken endpoint to the identity
> >>>>>>>> broker.
> >>>>>>>> Isn't better ?
> >>>>>>>>
> >>>>>>> A different endpoint would require the identity broker to know if the
> >>>>>>> app has permission to request it. Also, with my idea, you can refresh
> >>>>>>> multiple things with one request.
> >>>>>>>
> >>>>>>>     From an application perspective we can provide a
> >>>>>>> KeycloakSecurityContext.refreshToken(String... scope) method, then
> >>>>>>> the
> >>>>>>> app has one place to request the refresh of one or more claims.
> >>>>>>>
> >>>>>>> i.e.
> >>>>>>>
> >>>>>>> token = context.refreshToken("facebook", "google");
> >>>>>>>
> >>>>>>> String facebookToken = token.getClaim("broker.facebook.token");
> >>>>>> I'm still not sure if this is right. Specially when using scopes for
> >>>>>> that.
> >>>>>>
> >>>>>> Regarding app permissions, know if an app has an identity provider
> >>>>>> enabled
> >>>>>> and has access to retrieve its tokens is not enough ?
> >>>>>>
> >>>>> What does "app has an identity provider enabled" mean again?
> >>>> Currently, you can enable/disable identity providers for each
> >>>> application.
> >>>> I'm also going to add another option to enable/disable token retrieval,
> >>>> as
> >>>> Stian suggested.
> >>>>
> >>> What does enable/disable entity provider per application mean?  A
> >>> disabled "facebook" would mean that a "facebook" user couldn't visit the
> >>> app?
> >> It means that an application does not supports Facebook login. We just
> >> hide
> >> the Facebook button from the login page for a particular application.
> > As we agreed on the call we need to remove that.
> +1, Keycloak is SSO. Even if "application1" doesn't support Facebook
> button on login screen, user can still login via Facebook with
> "application2" and then go back to "application1", which will
> authenticate him automatically due to SSO. So disabling Facebook button
> on login screen really doesn't prevent user from login into Keycloak
> through Facebook.

I was thinking a little bit more about that.

The user is able to login because his identity was *federated*. So, from a SSO perspective this is fine even if "application1" does not provide facebook login.

However, only users authenticating in "application2" will be able to *federate* users from facebook. This might be useful if you want to perform additional logic in "application2" right after the user is federated. For instance, show a terms & conditions page, populate an internal database with data from facebook or make "application2" to act as a portal for other apps.

> 
> Marek
> >
> > We also need to add support to selecting what apps can retrieve the token.
> >
> >>>>>> And we can also provide a single place to request refresh for multiple
> >>>>>> claims.
> >>>>>>
> >>>>> Err...that's the same thing I was suggesting.  IMO, most apps won't
> >>>>> have
> >>>>> to manually do a refresh, they can just rely on the adapter to do it
> >>>>> for
> >>>>> them.  The way I'm proposing requires no changes to adapter code and
> >>>>> the
> >>>>> user can let the adapter refresh things as appropriate.
> >>>> Sorry, what I meant is the broker being the single place to refresh
> >>>> tokens.
> >>>> And not some where else.
> >>>>
> >>>> How are you going to specify which providers the user wants to
> >>>> automatically refresh tokens ? keycloak.json ?
> >>> In admin consonle, admin would configure the app to add the facebook
> >>> token claim to the JWT access token.  When the application invokes
> >>> refreshToken, this claim will be updated if needed.  It will all be a
> >>> callback through the ProtocolMapper SPI I'm creating.
> >>>
> >>> If the application wants to refresh only one claim, then it would
> >>> specify a "scope" with the refreshToken request.
> >>>
> >>> All this refreshing would happen between one API.  Then there is nothing
> >>> broker specific for the application, only one URL to refresh everything.
> >> Ok.
> >>
> >>>
> >>> --
> >>> Bill Burke
> >>> JBoss, a division of Red Hat
> >>> http://bill.burkecentral.com
> >>>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 

From bburke at redhat.com  Fri Feb 27 10:57:16 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 27 Feb 2015 10:57:16 -0500
Subject: [keycloak-dev] apps access to and refresh of facebook tokens
In-Reply-To: <1162494918.16931566.1425017298440.JavaMail.zimbra@redhat.com>
References: <54EF3EDB.4060903@redhat.com>
	<1946967211.20445048.1424966958888.JavaMail.zimbra@redhat.com>
	<54EF5335.6010501@redhat.com>
	<1952677297.20565895.1424974594063.JavaMail.zimbra@redhat.com>
	<54EF68D1.5020504@redhat.com>
	<999442242.20609060.1424977452320.JavaMail.zimbra@redhat.com>
	<54EF77BE.3020901@redhat.com>
	<764234478.20641140.1424980123285.JavaMail.zimbra@redhat.com>
	<1162494918.16931566.1425017298440.JavaMail.zimbra@redhat.com>
Message-ID: <54F093DC.3070702@redhat.com>

On 2/27/2015 1:08 AM, Stian Thorgersen wrote:
>
> I just think we're making something quite simple into something a lot more complex for no benefit.
>

I think you are making our design more complex or less performant than 
it needs to be.  I don't want a specific endpoint just to refresh a 
token for a specific broker.  We're also going to want to embed nested 
access tokens for specific keycloak nested application invocations.  I 
don't want a separate REST service just for that too.

I also want nested REST invocations to work without having to invoke on 
the auth server for every request.  The access token should have 
everything the application needs so that it can reduce traffic with the 
server.  What if a stateless, bearer-only REST services needs the 
facebook token?  If we're talking Javascript apps, then the backend will 
be entirely bearer-only stateless REST services.

I don't want to require adapter specific configuration.

I the vast majority of cases, I think facebook token refreshing can be 
handled automatically by the adapter and the auth-server-side configured 
token policies.  We can make the facebook token policy have different 
configuration options to:

* never to refresh the token
* modify the access token's expiration to sync with the facebook one.

We could add a "scope" parameter to refreshToken endpoint to give a hint 
to the facebook token policy on whether it needs to refresh or not.

Finally, every refreshAccessToken invocation gives the auth-server the 
opportunity to recheck revocation policies and upgrade/downgrade the 
user's and application's permissions.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From mposolda at redhat.com  Fri Feb 27 11:12:52 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 27 Feb 2015 17:12:52 +0100
Subject: [keycloak-dev] apps access to and refresh of facebook tokens
In-Reply-To: <441046235.21111280.1425042593519.JavaMail.zimbra@redhat.com>
References: <54EF3EDB.4060903@redhat.com>
	<1952677297.20565895.1424974594063.JavaMail.zimbra@redhat.com>
	<54EF68D1.5020504@redhat.com>
	<999442242.20609060.1424977452320.JavaMail.zimbra@redhat.com>
	<54EF77BE.3020901@redhat.com>
	<764234478.20641140.1424980123285.JavaMail.zimbra@redhat.com>
	<1162494918.16931566.1425017298440.JavaMail.zimbra@redhat.com>
	<54F06075.5090300@redhat.com>
	<441046235.21111280.1425042593519.JavaMail.zimbra@redhat.com>
Message-ID: <54F09784.9020604@redhat.com>

On 27.2.2015 14:09, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>, "Pedro Igor Silva" <psilva at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Friday, February 27, 2015 9:17:57 AM
>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
>>
>> One thing to consider: Does all identity brokers support refreshing of
>> tokens? For example it seems that Facebook doesn't (not 100% sure) and
>> instead they have long-lived access tokens. So when application wants to
>> refresh expired Facebook access token, it would need to browser redirect
>> to Keycloak with "k_idp_hint=facebook" and KC will need to redirect to
>> Facebook and then back to app with refreshed token.
>>
>> For minimum of HTTP requests needed, but good usability I would do it
>> like this:
>>
>> * Access token sent from KC to the application embeds all 3rd party
>> access tokens accessible by configured claims. There is risk application
>> doesn't need them all for particular request, but IMO it is better to
>> have 1 HTTP request with bigger JSON accessToken response then another
>> separate request from application to KC just to retrieve Facebook access
>> token.
>>
>> * Adapter has method on RefreshableKeycloakSecurityContext like this:
>>
>> updateThirdpartyToken("facebook", 10, httpFacade)
>>
>> which will update facebook access token just if it's going to expire in
>> next 10 seconds. Otherwise no network calls needed. Adapter should know
>> when is Facebook access token going to expire from the KC accessToken
>> (It should have all needed info). If token is going to expire,
>> HttpFacade may be needed to perform redirect to KC with idp_hint.
> Like I said during our meeting, different providers may have different strategies to refresh tokens even when using standard protocols. This is the case of Facebook. I think you are right, Facebook does not provides a refresh token. So we always need a redirect in order to get a fresh one if token expires or was invalidated. But I think Bill is considering that some how with his solution.
Actually not sure unless I understand it bad? In first mail, Bill 
mentioned adding "scope" parameter to refreshToken endpoint to specify 
which 3rd party tokens to refresh. But refreshing tokens from adapter is 
done through backend request. So if refreshing Facebook token requires 
browser redirect, this approach won't work.

>
> I understand the usability arguments for embedding tokens in KC access token and also the new method to refresh them. But I still think that we don't need that.
>
> IMO, each provide should implement how its tokens are refreshed. We would just need a new endpoint in broker. And just let apps invoke this endpoint in order to refresh tokens. The code for doing that is very simple and minimal without bring complexity to apps.
Yeah, I agree that endpoint in broker should be fine for most cases. 
However how will endpoint help with refreshing Facebook access token if 
they require browser redirect? Should there be config option on adapter 
to specify if provider supports refreshing token through broker endpoint 
or if it requires full browser redirect with "idpHint" ?

Also adapter may need to specify: "Give me current facebook accessToken 
if it's not going to expire in next 10 seconds. Otherwise refresh 
facebook token". Something similar to method "updateToken" we have in 
keycloak.js. I was thinking that method "updateThirdpartyToken" will 
handle this for you.

Marek

>
>> Maybe identity broker should allow to specify if provider supports
>> refreshing tokens (in this case backend refresh from app to KC could
>> happen), but otherwise it would really need to go through browser
>> redirects IMO.
>>
>> Marek
>>
>> On 27.2.2015 07:08, Stian Thorgersen wrote:
>>> I don't see the need to include the facebook token into the Keycloak token.
>>> IMO the way an application would use it is (pseudo code not real code):
>>>
>>> function callInternalEndpoint() {
>>>     var internalToken = kc.getToken();
>>>     if (internalToken.isExpired()) {
>>>       internalToken = kc.updateToken()
>>>     }
>>>     invokeRestEndpointSecuredByKc(internalToken, someData);
>>>
>>> }
>>>
>>> function callExternalEndpoint() {
>>>     var facebookToken = kc.getToken("facebook");
>>>     if (facebookToken.isExpired()) {
>>>       facebookToken = kc.updateToken("facebook")
>>>     }
>>>     invokeFacebook(facebookToken, someData);
>>> }
>>>
>>> I just don't see the need to refresh all these tokens at the same time. In
>>> the first function the internal token is required, in the second the
>>> facebook token is required. If you have more linked identities to the same
>>> user it could get even worse. For example to call Facebook you'd end up
>>> refreshing Keycloak, Facebook, Google, Twitter, etc tokens. That's a lot
>>> of unnecessary calls.
>>>
>>> Also, it would be pretty complex to do. When does for example the internal
>>> token expire? I assume that would have to be the shortest amount of time
>>> for any of the included tokens to expire.
>>>
>>> I just think we're making something quite simple into something a lot more
>>> complex for no benefit.
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
>>>> To: "Bill Burke" <bburke at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Thursday, February 26, 2015 8:48:43 PM
>>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
>>>>
>>>> ----- Original Message -----
>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>> Sent: Thursday, February 26, 2015 4:45:02 PM
>>>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
>>>>>
>>>>>
>>>>>
>>>>> On 2/26/2015 2:04 PM, Pedro Igor Silva wrote:
>>>>>> ----- Original Message -----
>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>> Sent: Thursday, February 26, 2015 3:41:21 PM
>>>>>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook
>>>>>>> tokens
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2/26/2015 1:16 PM, Pedro Igor Silva wrote:
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>>>> Sent: Thursday, February 26, 2015 2:09:09 PM
>>>>>>>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook
>>>>>>>>> tokens
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2/26/2015 11:09 AM, Pedro Igor Silva wrote:
>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>>>>>> Sent: Thursday, February 26, 2015 12:42:19 PM
>>>>>>>>>>> Subject: [keycloak-dev] apps access to and refresh of facebook
>>>>>>>>>>> tokens
>>>>>>>>>>>
>>>>>>>>>>> At least for openid connect, I think we hashed this through on our
>>>>>>>>>>> dev
>>>>>>>>>>> call today.
>>>>>>>>>>>
>>>>>>>>>>> * There will be a Protocol Claim Mapper that can add a facebook
>>>>>>>>>>> token
>>>>>>>>>>> and expiration claim to the application's access token.
>>>>>>>>>> I would create a specific claim set for that instead of individual
>>>>>>>>>> claims.
>>>>>>>>>> Something like:
>>>>>>>>>>
>>>>>>>>>> "k_act" : {
>>>>>>>>>>          "identity-provider": {
>>>>>>>>>>              "id" : "facebook",
>>>>>>>>>>              "access_token": "12312312",
>>>>>>>>>>              "expires": "12312321"
>>>>>>>>>>          }
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> (k_act : keycloak authentication context)
>>>>>>>>>>
>>>>>>>>>> That way we can use this k_act for exchange information regarding
>>>>>>>>>> the
>>>>>>>>>> authentication context when issuing access tokens or even id tokens.
>>>>>>>>>>
>>>>>>>>> Yeah, token mapping be able to generate any json you want.
>>>>>>>>>
>>>>>>>>>>> * the refreshToken endpoint will accept a "scope" parameter.  The
>>>>>>>>>>> application can then request the refresh of any external token by
>>>>>>>>>>> specifying this token in the "scope parameter.
>>>>>>>>>> I was thinking about adding a refreshToken endpoint to the identity
>>>>>>>>>> broker.
>>>>>>>>>> Isn't better ?
>>>>>>>>>>
>>>>>>>>> A different endpoint would require the identity broker to know if the
>>>>>>>>> app has permission to request it. Also, with my idea, you can refresh
>>>>>>>>> multiple things with one request.
>>>>>>>>>
>>>>>>>>>      From an application perspective we can provide a
>>>>>>>>> KeycloakSecurityContext.refreshToken(String... scope) method, then
>>>>>>>>> the
>>>>>>>>> app has one place to request the refresh of one or more claims.
>>>>>>>>>
>>>>>>>>> i.e.
>>>>>>>>>
>>>>>>>>> token = context.refreshToken("facebook", "google");
>>>>>>>>>
>>>>>>>>> String facebookToken = token.getClaim("broker.facebook.token");
>>>>>>>> I'm still not sure if this is right. Specially when using scopes for
>>>>>>>> that.
>>>>>>>>
>>>>>>>> Regarding app permissions, know if an app has an identity provider
>>>>>>>> enabled
>>>>>>>> and has access to retrieve its tokens is not enough ?
>>>>>>>>
>>>>>>> What does "app has an identity provider enabled" mean again?
>>>>>> Currently, you can enable/disable identity providers for each
>>>>>> application.
>>>>>> I'm also going to add another option to enable/disable token retrieval,
>>>>>> as
>>>>>> Stian suggested.
>>>>>>
>>>>> What does enable/disable entity provider per application mean?  A
>>>>> disabled "facebook" would mean that a "facebook" user couldn't visit the
>>>>> app?
>>>> It means that an application does not supports Facebook login. We just
>>>> hide
>>>> the Facebook button from the login page for a particular application.
>>>>
>>>>>>>> And we can also provide a single place to request refresh for multiple
>>>>>>>> claims.
>>>>>>>>
>>>>>>> Err...that's the same thing I was suggesting.  IMO, most apps won't
>>>>>>> have
>>>>>>> to manually do a refresh, they can just rely on the adapter to do it
>>>>>>> for
>>>>>>> them.  The way I'm proposing requires no changes to adapter code and
>>>>>>> the
>>>>>>> user can let the adapter refresh things as appropriate.
>>>>>> Sorry, what I meant is the broker being the single place to refresh
>>>>>> tokens.
>>>>>> And not some where else.
>>>>>>
>>>>>> How are you going to specify which providers the user wants to
>>>>>> automatically refresh tokens ? keycloak.json ?
>>>>> In admin consonle, admin would configure the app to add the facebook
>>>>> token claim to the JWT access token.  When the application invokes
>>>>> refreshToken, this claim will be updated if needed.  It will all be a
>>>>> callback through the ProtocolMapper SPI I'm creating.
>>>>>
>>>>> If the application wants to refresh only one claim, then it would
>>>>> specify a "scope" with the refreshToken request.
>>>>>
>>>>> All this refreshing would happen between one API.  Then there is nothing
>>>>> broker specific for the application, only one URL to refresh everything.
>>>> Ok.
>>>>
>>>>> --
>>>>> 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 psilva at redhat.com  Fri Feb 27 11:42:55 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 27 Feb 2015 11:42:55 -0500 (EST)
Subject: [keycloak-dev] apps access to and refresh of facebook tokens
In-Reply-To: <54F09784.9020604@redhat.com>
References: <54EF3EDB.4060903@redhat.com>
	<999442242.20609060.1424977452320.JavaMail.zimbra@redhat.com>
	<54EF77BE.3020901@redhat.com>
	<764234478.20641140.1424980123285.JavaMail.zimbra@redhat.com>
	<1162494918.16931566.1425017298440.JavaMail.zimbra@redhat.com>
	<54F06075.5090300@redhat.com>
	<441046235.21111280.1425042593519.JavaMail.zimbra@redhat.com>
	<54F09784.9020604@redhat.com>
Message-ID: <1409918241.21284831.1425055375011.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Pedro Igor Silva" <psilva at redhat.com>
> Cc: "Stian Thorgersen" <stian at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Friday, February 27, 2015 1:12:52 PM
> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
> 
> On 27.2.2015 14:09, Pedro Igor Silva wrote:
> > ----- Original Message -----
> >> From: "Marek Posolda" <mposolda at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>, "Pedro Igor Silva"
> >> <psilva at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Friday, February 27, 2015 9:17:57 AM
> >> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
> >>
> >> One thing to consider: Does all identity brokers support refreshing of
> >> tokens? For example it seems that Facebook doesn't (not 100% sure) and
> >> instead they have long-lived access tokens. So when application wants to
> >> refresh expired Facebook access token, it would need to browser redirect
> >> to Keycloak with "k_idp_hint=facebook" and KC will need to redirect to
> >> Facebook and then back to app with refreshed token.
> >>
> >> For minimum of HTTP requests needed, but good usability I would do it
> >> like this:
> >>
> >> * Access token sent from KC to the application embeds all 3rd party
> >> access tokens accessible by configured claims. There is risk application
> >> doesn't need them all for particular request, but IMO it is better to
> >> have 1 HTTP request with bigger JSON accessToken response then another
> >> separate request from application to KC just to retrieve Facebook access
> >> token.
> >>
> >> * Adapter has method on RefreshableKeycloakSecurityContext like this:
> >>
> >> updateThirdpartyToken("facebook", 10, httpFacade)
> >>
> >> which will update facebook access token just if it's going to expire in
> >> next 10 seconds. Otherwise no network calls needed. Adapter should know
> >> when is Facebook access token going to expire from the KC accessToken
> >> (It should have all needed info). If token is going to expire,
> >> HttpFacade may be needed to perform redirect to KC with idp_hint.
> > Like I said during our meeting, different providers may have different
> > strategies to refresh tokens even when using standard protocols. This is
> > the case of Facebook. I think you are right, Facebook does not provides a
> > refresh token. So we always need a redirect in order to get a fresh one if
> > token expires or was invalidated. But I think Bill is considering that
> > some how with his solution.
> Actually not sure unless I understand it bad? In first mail, Bill
> mentioned adding "scope" parameter to refreshToken endpoint to specify
> which 3rd party tokens to refresh. But refreshing tokens from adapter is
> done through backend request. So if refreshing Facebook token requires
> browser redirect, this approach won't work.

Bill is full of surprises :)

> 
> >
> > I understand the usability arguments for embedding tokens in KC access
> > token and also the new method to refresh them. But I still think that we
> > don't need that.
> >
> > IMO, each provide should implement how its tokens are refreshed. We would
> > just need a new endpoint in broker. And just let apps invoke this endpoint
> > in order to refresh tokens. The code for doing that is very simple and
> > minimal without bring complexity to apps.
> Yeah, I agree that endpoint in broker should be fine for most cases.
> However how will endpoint help with refreshing Facebook access token if
> they require browser redirect? Should there be config option on adapter
> to specify if provider supports refreshing token through broker endpoint
> or if it requires full browser redirect with "idpHint" ?
> 
> Also adapter may need to specify: "Give me current facebook accessToken
> if it's not going to expire in next 10 seconds. Otherwise refresh
> facebook token". Something similar to method "updateToken" we have in
> keycloak.js. I was thinking that method "updateThirdpartyToken" will
> handle this for you.

I think we can just start simple. Each provider has its own characteristics. If facebook requires a redirect apps just use k_idp_hint like the example app.

If the provider supports backend refresh, they just use the endpoint ...

In both cases, we are saving them code and time. Apps just need to deal with the KC server.

> 
> Marek
> 
> >
> >> Maybe identity broker should allow to specify if provider supports
> >> refreshing tokens (in this case backend refresh from app to KC could
> >> happen), but otherwise it would really need to go through browser
> >> redirects IMO.
> >>
> >> Marek
> >>
> >> On 27.2.2015 07:08, Stian Thorgersen wrote:
> >>> I don't see the need to include the facebook token into the Keycloak
> >>> token.
> >>> IMO the way an application would use it is (pseudo code not real code):
> >>>
> >>> function callInternalEndpoint() {
> >>>     var internalToken = kc.getToken();
> >>>     if (internalToken.isExpired()) {
> >>>       internalToken = kc.updateToken()
> >>>     }
> >>>     invokeRestEndpointSecuredByKc(internalToken, someData);
> >>>
> >>> }
> >>>
> >>> function callExternalEndpoint() {
> >>>     var facebookToken = kc.getToken("facebook");
> >>>     if (facebookToken.isExpired()) {
> >>>       facebookToken = kc.updateToken("facebook")
> >>>     }
> >>>     invokeFacebook(facebookToken, someData);
> >>> }
> >>>
> >>> I just don't see the need to refresh all these tokens at the same time.
> >>> In
> >>> the first function the internal token is required, in the second the
> >>> facebook token is required. If you have more linked identities to the
> >>> same
> >>> user it could get even worse. For example to call Facebook you'd end up
> >>> refreshing Keycloak, Facebook, Google, Twitter, etc tokens. That's a lot
> >>> of unnecessary calls.
> >>>
> >>> Also, it would be pretty complex to do. When does for example the
> >>> internal
> >>> token expire? I assume that would have to be the shortest amount of time
> >>> for any of the included tokens to expire.
> >>>
> >>> I just think we're making something quite simple into something a lot
> >>> more
> >>> complex for no benefit.
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> From: "Pedro Igor Silva" <psilva at redhat.com>
> >>>> To: "Bill Burke" <bburke at redhat.com>
> >>>> Cc: keycloak-dev at lists.jboss.org
> >>>> Sent: Thursday, February 26, 2015 8:48:43 PM
> >>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook
> >>>> tokens
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>> Sent: Thursday, February 26, 2015 4:45:02 PM
> >>>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook
> >>>>> tokens
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 2/26/2015 2:04 PM, Pedro Igor Silva wrote:
> >>>>>> ----- Original Message -----
> >>>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>>>> Sent: Thursday, February 26, 2015 3:41:21 PM
> >>>>>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook
> >>>>>>> tokens
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On 2/26/2015 1:16 PM, Pedro Igor Silva wrote:
> >>>>>>>> ----- Original Message -----
> >>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
> >>>>>>>>> Cc: keycloak-dev at lists.jboss.org
> >>>>>>>>> Sent: Thursday, February 26, 2015 2:09:09 PM
> >>>>>>>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook
> >>>>>>>>> tokens
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On 2/26/2015 11:09 AM, Pedro Igor Silva wrote:
> >>>>>>>>>> ----- Original Message -----
> >>>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
> >>>>>>>>>>> To: keycloak-dev at lists.jboss.org
> >>>>>>>>>>> Sent: Thursday, February 26, 2015 12:42:19 PM
> >>>>>>>>>>> Subject: [keycloak-dev] apps access to and refresh of facebook
> >>>>>>>>>>> tokens
> >>>>>>>>>>>
> >>>>>>>>>>> At least for openid connect, I think we hashed this through on
> >>>>>>>>>>> our
> >>>>>>>>>>> dev
> >>>>>>>>>>> call today.
> >>>>>>>>>>>
> >>>>>>>>>>> * There will be a Protocol Claim Mapper that can add a facebook
> >>>>>>>>>>> token
> >>>>>>>>>>> and expiration claim to the application's access token.
> >>>>>>>>>> I would create a specific claim set for that instead of individual
> >>>>>>>>>> claims.
> >>>>>>>>>> Something like:
> >>>>>>>>>>
> >>>>>>>>>> "k_act" : {
> >>>>>>>>>>          "identity-provider": {
> >>>>>>>>>>              "id" : "facebook",
> >>>>>>>>>>              "access_token": "12312312",
> >>>>>>>>>>              "expires": "12312321"
> >>>>>>>>>>          }
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> (k_act : keycloak authentication context)
> >>>>>>>>>>
> >>>>>>>>>> That way we can use this k_act for exchange information regarding
> >>>>>>>>>> the
> >>>>>>>>>> authentication context when issuing access tokens or even id
> >>>>>>>>>> tokens.
> >>>>>>>>>>
> >>>>>>>>> Yeah, token mapping be able to generate any json you want.
> >>>>>>>>>
> >>>>>>>>>>> * the refreshToken endpoint will accept a "scope" parameter.  The
> >>>>>>>>>>> application can then request the refresh of any external token by
> >>>>>>>>>>> specifying this token in the "scope parameter.
> >>>>>>>>>> I was thinking about adding a refreshToken endpoint to the
> >>>>>>>>>> identity
> >>>>>>>>>> broker.
> >>>>>>>>>> Isn't better ?
> >>>>>>>>>>
> >>>>>>>>> A different endpoint would require the identity broker to know if
> >>>>>>>>> the
> >>>>>>>>> app has permission to request it. Also, with my idea, you can
> >>>>>>>>> refresh
> >>>>>>>>> multiple things with one request.
> >>>>>>>>>
> >>>>>>>>>      From an application perspective we can provide a
> >>>>>>>>> KeycloakSecurityContext.refreshToken(String... scope) method, then
> >>>>>>>>> the
> >>>>>>>>> app has one place to request the refresh of one or more claims.
> >>>>>>>>>
> >>>>>>>>> i.e.
> >>>>>>>>>
> >>>>>>>>> token = context.refreshToken("facebook", "google");
> >>>>>>>>>
> >>>>>>>>> String facebookToken = token.getClaim("broker.facebook.token");
> >>>>>>>> I'm still not sure if this is right. Specially when using scopes for
> >>>>>>>> that.
> >>>>>>>>
> >>>>>>>> Regarding app permissions, know if an app has an identity provider
> >>>>>>>> enabled
> >>>>>>>> and has access to retrieve its tokens is not enough ?
> >>>>>>>>
> >>>>>>> What does "app has an identity provider enabled" mean again?
> >>>>>> Currently, you can enable/disable identity providers for each
> >>>>>> application.
> >>>>>> I'm also going to add another option to enable/disable token
> >>>>>> retrieval,
> >>>>>> as
> >>>>>> Stian suggested.
> >>>>>>
> >>>>> What does enable/disable entity provider per application mean?  A
> >>>>> disabled "facebook" would mean that a "facebook" user couldn't visit
> >>>>> the
> >>>>> app?
> >>>> It means that an application does not supports Facebook login. We just
> >>>> hide
> >>>> the Facebook button from the login page for a particular application.
> >>>>
> >>>>>>>> And we can also provide a single place to request refresh for
> >>>>>>>> multiple
> >>>>>>>> claims.
> >>>>>>>>
> >>>>>>> Err...that's the same thing I was suggesting.  IMO, most apps won't
> >>>>>>> have
> >>>>>>> to manually do a refresh, they can just rely on the adapter to do it
> >>>>>>> for
> >>>>>>> them.  The way I'm proposing requires no changes to adapter code and
> >>>>>>> the
> >>>>>>> user can let the adapter refresh things as appropriate.
> >>>>>> Sorry, what I meant is the broker being the single place to refresh
> >>>>>> tokens.
> >>>>>> And not some where else.
> >>>>>>
> >>>>>> How are you going to specify which providers the user wants to
> >>>>>> automatically refresh tokens ? keycloak.json ?
> >>>>> In admin consonle, admin would configure the app to add the facebook
> >>>>> token claim to the JWT access token.  When the application invokes
> >>>>> refreshToken, this claim will be updated if needed.  It will all be a
> >>>>> callback through the ProtocolMapper SPI I'm creating.
> >>>>>
> >>>>> If the application wants to refresh only one claim, then it would
> >>>>> specify a "scope" with the refreshToken request.
> >>>>>
> >>>>> All this refreshing would happen between one API.  Then there is
> >>>>> nothing
> >>>>> broker specific for the application, only one URL to refresh
> >>>>> everything.
> >>>> Ok.
> >>>>
> >>>>> --
> >>>>> 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 mposolda at redhat.com  Fri Feb 27 11:51:21 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 27 Feb 2015 17:51:21 +0100
Subject: [keycloak-dev] apps access to and refresh of facebook tokens
In-Reply-To: <1409918241.21284831.1425055375011.JavaMail.zimbra@redhat.com>
References: <54EF3EDB.4060903@redhat.com>
	<999442242.20609060.1424977452320.JavaMail.zimbra@redhat.com>
	<54EF77BE.3020901@redhat.com>
	<764234478.20641140.1424980123285.JavaMail.zimbra@redhat.com>
	<1162494918.16931566.1425017298440.JavaMail.zimbra@redhat.com>
	<54F06075.5090300@redhat.com>
	<441046235.21111280.1425042593519.JavaMail.zimbra@redhat.com>
	<54F09784.9020604@redhat.com>
	<1409918241.21284831.1425055375011.JavaMail.zimbra@redhat.com>
Message-ID: <54F0A089.2060809@redhat.com>

On 27.2.2015 17:42, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Pedro Igor Silva" <psilva at redhat.com>
>> Cc: "Stian Thorgersen" <stian at redhat.com>, keycloak-dev at lists.jboss.org
>> Sent: Friday, February 27, 2015 1:12:52 PM
>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
>>
>> On 27.2.2015 14:09, Pedro Igor Silva wrote:
>>> ----- Original Message -----
>>>> From: "Marek Posolda" <mposolda at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>, "Pedro Igor Silva"
>>>> <psilva at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Friday, February 27, 2015 9:17:57 AM
>>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens
>>>>
>>>> One thing to consider: Does all identity brokers support refreshing of
>>>> tokens? For example it seems that Facebook doesn't (not 100% sure) and
>>>> instead they have long-lived access tokens. So when application wants to
>>>> refresh expired Facebook access token, it would need to browser redirect
>>>> to Keycloak with "k_idp_hint=facebook" and KC will need to redirect to
>>>> Facebook and then back to app with refreshed token.
>>>>
>>>> For minimum of HTTP requests needed, but good usability I would do it
>>>> like this:
>>>>
>>>> * Access token sent from KC to the application embeds all 3rd party
>>>> access tokens accessible by configured claims. There is risk application
>>>> doesn't need them all for particular request, but IMO it is better to
>>>> have 1 HTTP request with bigger JSON accessToken response then another
>>>> separate request from application to KC just to retrieve Facebook access
>>>> token.
>>>>
>>>> * Adapter has method on RefreshableKeycloakSecurityContext like this:
>>>>
>>>> updateThirdpartyToken("facebook", 10, httpFacade)
>>>>
>>>> which will update facebook access token just if it's going to expire in
>>>> next 10 seconds. Otherwise no network calls needed. Adapter should know
>>>> when is Facebook access token going to expire from the KC accessToken
>>>> (It should have all needed info). If token is going to expire,
>>>> HttpFacade may be needed to perform redirect to KC with idp_hint.
>>> Like I said during our meeting, different providers may have different
>>> strategies to refresh tokens even when using standard protocols. This is
>>> the case of Facebook. I think you are right, Facebook does not provides a
>>> refresh token. So we always need a redirect in order to get a fresh one if
>>> token expires or was invalidated. But I think Bill is considering that
>>> some how with his solution.
>> Actually not sure unless I understand it bad? In first mail, Bill
>> mentioned adding "scope" parameter to refreshToken endpoint to specify
>> which 3rd party tokens to refresh. But refreshing tokens from adapter is
>> done through backend request. So if refreshing Facebook token requires
>> browser redirect, this approach won't work.
> Bill is full of surprises :)
>
>>> I understand the usability arguments for embedding tokens in KC access
>>> token and also the new method to refresh them. But I still think that we
>>> don't need that.
>>>
>>> IMO, each provide should implement how its tokens are refreshed. We would
>>> just need a new endpoint in broker. And just let apps invoke this endpoint
>>> in order to refresh tokens. The code for doing that is very simple and
>>> minimal without bring complexity to apps.
>> Yeah, I agree that endpoint in broker should be fine for most cases.
>> However how will endpoint help with refreshing Facebook access token if
>> they require browser redirect? Should there be config option on adapter
>> to specify if provider supports refreshing token through broker endpoint
>> or if it requires full browser redirect with "idpHint" ?
>>
>> Also adapter may need to specify: "Give me current facebook accessToken
>> if it's not going to expire in next 10 seconds. Otherwise refresh
>> facebook token". Something similar to method "updateToken" we have in
>> keycloak.js. I was thinking that method "updateThirdpartyToken" will
>> handle this for you.
> I think we can just start simple. Each provider has its own characteristics. If facebook requires a redirect apps just use k_idp_hint like the example app.
>
> If the provider supports backend refresh, they just use the endpoint ...
>
> In both cases, we are saving them code and time. Apps just need to deal with the KC server.
Yeah, but it would be nice if application doesn't manually need to 
handle when to refresh 3rd party token like:

if (currentFBAccessToken.expiration > currentTime + 10) {
   return currentFBAccessToken;
} else {
   redirectToRefreshFBToken;
}

We should handle this logic on adapter side IMO

Marek

>
>> Marek
>>
>>>> Maybe identity broker should allow to specify if provider supports
>>>> refreshing tokens (in this case backend refresh from app to KC could
>>>> happen), but otherwise it would really need to go through browser
>>>> redirects IMO.
>>>>
>>>> Marek
>>>>
>>>> On 27.2.2015 07:08, Stian Thorgersen wrote:
>>>>> I don't see the need to include the facebook token into the Keycloak
>>>>> token.
>>>>> IMO the way an application would use it is (pseudo code not real code):
>>>>>
>>>>> function callInternalEndpoint() {
>>>>>      var internalToken = kc.getToken();
>>>>>      if (internalToken.isExpired()) {
>>>>>        internalToken = kc.updateToken()
>>>>>      }
>>>>>      invokeRestEndpointSecuredByKc(internalToken, someData);
>>>>>
>>>>> }
>>>>>
>>>>> function callExternalEndpoint() {
>>>>>      var facebookToken = kc.getToken("facebook");
>>>>>      if (facebookToken.isExpired()) {
>>>>>        facebookToken = kc.updateToken("facebook")
>>>>>      }
>>>>>      invokeFacebook(facebookToken, someData);
>>>>> }
>>>>>
>>>>> I just don't see the need to refresh all these tokens at the same time.
>>>>> In
>>>>> the first function the internal token is required, in the second the
>>>>> facebook token is required. If you have more linked identities to the
>>>>> same
>>>>> user it could get even worse. For example to call Facebook you'd end up
>>>>> refreshing Keycloak, Facebook, Google, Twitter, etc tokens. That's a lot
>>>>> of unnecessary calls.
>>>>>
>>>>> Also, it would be pretty complex to do. When does for example the
>>>>> internal
>>>>> token expire? I assume that would have to be the shortest amount of time
>>>>> for any of the included tokens to expire.
>>>>>
>>>>> I just think we're making something quite simple into something a lot
>>>>> more
>>>>> complex for no benefit.
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Pedro Igor Silva" <psilva at redhat.com>
>>>>>> To: "Bill Burke" <bburke at redhat.com>
>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>> Sent: Thursday, February 26, 2015 8:48:43 PM
>>>>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook
>>>>>> tokens
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>> Sent: Thursday, February 26, 2015 4:45:02 PM
>>>>>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook
>>>>>>> tokens
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2/26/2015 2:04 PM, Pedro Igor Silva wrote:
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>>>> Sent: Thursday, February 26, 2015 3:41:21 PM
>>>>>>>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook
>>>>>>>>> tokens
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2/26/2015 1:16 PM, Pedro Igor Silva wrote:
>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>>>>> To: "Pedro Igor Silva" <psilva at redhat.com>
>>>>>>>>>>> Cc: keycloak-dev at lists.jboss.org
>>>>>>>>>>> Sent: Thursday, February 26, 2015 2:09:09 PM
>>>>>>>>>>> Subject: Re: [keycloak-dev] apps access to and refresh of facebook
>>>>>>>>>>> tokens
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 2/26/2015 11:09 AM, Pedro Igor Silva wrote:
>>>>>>>>>>>> ----- Original Message -----
>>>>>>>>>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>>>>>>>>>> To: keycloak-dev at lists.jboss.org
>>>>>>>>>>>>> Sent: Thursday, February 26, 2015 12:42:19 PM
>>>>>>>>>>>>> Subject: [keycloak-dev] apps access to and refresh of facebook
>>>>>>>>>>>>> tokens
>>>>>>>>>>>>>
>>>>>>>>>>>>> At least for openid connect, I think we hashed this through on
>>>>>>>>>>>>> our
>>>>>>>>>>>>> dev
>>>>>>>>>>>>> call today.
>>>>>>>>>>>>>
>>>>>>>>>>>>> * There will be a Protocol Claim Mapper that can add a facebook
>>>>>>>>>>>>> token
>>>>>>>>>>>>> and expiration claim to the application's access token.
>>>>>>>>>>>> I would create a specific claim set for that instead of individual
>>>>>>>>>>>> claims.
>>>>>>>>>>>> Something like:
>>>>>>>>>>>>
>>>>>>>>>>>> "k_act" : {
>>>>>>>>>>>>           "identity-provider": {
>>>>>>>>>>>>               "id" : "facebook",
>>>>>>>>>>>>               "access_token": "12312312",
>>>>>>>>>>>>               "expires": "12312321"
>>>>>>>>>>>>           }
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> (k_act : keycloak authentication context)
>>>>>>>>>>>>
>>>>>>>>>>>> That way we can use this k_act for exchange information regarding
>>>>>>>>>>>> the
>>>>>>>>>>>> authentication context when issuing access tokens or even id
>>>>>>>>>>>> tokens.
>>>>>>>>>>>>
>>>>>>>>>>> Yeah, token mapping be able to generate any json you want.
>>>>>>>>>>>
>>>>>>>>>>>>> * the refreshToken endpoint will accept a "scope" parameter.  The
>>>>>>>>>>>>> application can then request the refresh of any external token by
>>>>>>>>>>>>> specifying this token in the "scope parameter.
>>>>>>>>>>>> I was thinking about adding a refreshToken endpoint to the
>>>>>>>>>>>> identity
>>>>>>>>>>>> broker.
>>>>>>>>>>>> Isn't better ?
>>>>>>>>>>>>
>>>>>>>>>>> A different endpoint would require the identity broker to know if
>>>>>>>>>>> the
>>>>>>>>>>> app has permission to request it. Also, with my idea, you can
>>>>>>>>>>> refresh
>>>>>>>>>>> multiple things with one request.
>>>>>>>>>>>
>>>>>>>>>>>       From an application perspective we can provide a
>>>>>>>>>>> KeycloakSecurityContext.refreshToken(String... scope) method, then
>>>>>>>>>>> the
>>>>>>>>>>> app has one place to request the refresh of one or more claims.
>>>>>>>>>>>
>>>>>>>>>>> i.e.
>>>>>>>>>>>
>>>>>>>>>>> token = context.refreshToken("facebook", "google");
>>>>>>>>>>>
>>>>>>>>>>> String facebookToken = token.getClaim("broker.facebook.token");
>>>>>>>>>> I'm still not sure if this is right. Specially when using scopes for
>>>>>>>>>> that.
>>>>>>>>>>
>>>>>>>>>> Regarding app permissions, know if an app has an identity provider
>>>>>>>>>> enabled
>>>>>>>>>> and has access to retrieve its tokens is not enough ?
>>>>>>>>>>
>>>>>>>>> What does "app has an identity provider enabled" mean again?
>>>>>>>> Currently, you can enable/disable identity providers for each
>>>>>>>> application.
>>>>>>>> I'm also going to add another option to enable/disable token
>>>>>>>> retrieval,
>>>>>>>> as
>>>>>>>> Stian suggested.
>>>>>>>>
>>>>>>> What does enable/disable entity provider per application mean?  A
>>>>>>> disabled "facebook" would mean that a "facebook" user couldn't visit
>>>>>>> the
>>>>>>> app?
>>>>>> It means that an application does not supports Facebook login. We just
>>>>>> hide
>>>>>> the Facebook button from the login page for a particular application.
>>>>>>
>>>>>>>>>> And we can also provide a single place to request refresh for
>>>>>>>>>> multiple
>>>>>>>>>> claims.
>>>>>>>>>>
>>>>>>>>> Err...that's the same thing I was suggesting.  IMO, most apps won't
>>>>>>>>> have
>>>>>>>>> to manually do a refresh, they can just rely on the adapter to do it
>>>>>>>>> for
>>>>>>>>> them.  The way I'm proposing requires no changes to adapter code and
>>>>>>>>> the
>>>>>>>>> user can let the adapter refresh things as appropriate.
>>>>>>>> Sorry, what I meant is the broker being the single place to refresh
>>>>>>>> tokens.
>>>>>>>> And not some where else.
>>>>>>>>
>>>>>>>> How are you going to specify which providers the user wants to
>>>>>>>> automatically refresh tokens ? keycloak.json ?
>>>>>>> In admin consonle, admin would configure the app to add the facebook
>>>>>>> token claim to the JWT access token.  When the application invokes
>>>>>>> refreshToken, this claim will be updated if needed.  It will all be a
>>>>>>> callback through the ProtocolMapper SPI I'm creating.
>>>>>>>
>>>>>>> If the application wants to refresh only one claim, then it would
>>>>>>> specify a "scope" with the refreshToken request.
>>>>>>>
>>>>>>> All this refreshing would happen between one API.  Then there is
>>>>>>> nothing
>>>>>>> broker specific for the application, only one URL to refresh
>>>>>>> everything.
>>>>>> Ok.
>>>>>>
>>>>>>> --
>>>>>>> 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 mposolda at redhat.com  Fri Feb 27 11:56:11 2015
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 27 Feb 2015 17:56:11 +0100
Subject: [keycloak-dev] apps access to and refresh of facebook tokens
In-Reply-To: <54F093DC.3070702@redhat.com>
References: <54EF3EDB.4060903@redhat.com>	<1946967211.20445048.1424966958888.JavaMail.zimbra@redhat.com>	<54EF5335.6010501@redhat.com>	<1952677297.20565895.1424974594063.JavaMail.zimbra@redhat.com>	<54EF68D1.5020504@redhat.com>	<999442242.20609060.1424977452320.JavaMail.zimbra@redhat.com>	<54EF77BE.3020901@redhat.com>	<764234478.20641140.1424980123285.JavaMail.zimbra@redhat.com>	<1162494918.16931566.1425017298440.JavaMail.zimbra@redhat.com>
	<54F093DC.3070702@redhat.com>
Message-ID: <54F0A1AB.9090608@redhat.com>

As mentioned in other mails, there might be an issue if provider doesn't 
support refreshing tokens via out-of-bound request as mentioned in 
specs. Which seems to be the case of Facebook:-(

It looks the only possibility to refresh expired FB access token is 
browser  redirection.

Marek

On 27.2.2015 16:57, Bill Burke wrote:
> On 2/27/2015 1:08 AM, Stian Thorgersen wrote:
>> I just think we're making something quite simple into something a lot more complex for no benefit.
>>
> I think you are making our design more complex or less performant than
> it needs to be.  I don't want a specific endpoint just to refresh a
> token for a specific broker.  We're also going to want to embed nested
> access tokens for specific keycloak nested application invocations.  I
> don't want a separate REST service just for that too.
>
> I also want nested REST invocations to work without having to invoke on
> the auth server for every request.  The access token should have
> everything the application needs so that it can reduce traffic with the
> server.  What if a stateless, bearer-only REST services needs the
> facebook token?  If we're talking Javascript apps, then the backend will
> be entirely bearer-only stateless REST services.
>
> I don't want to require adapter specific configuration.
>
> I the vast majority of cases, I think facebook token refreshing can be
> handled automatically by the adapter and the auth-server-side configured
> token policies.  We can make the facebook token policy have different
> configuration options to:
>
> * never to refresh the token
> * modify the access token's expiration to sync with the facebook one.
>
> We could add a "scope" parameter to refreshToken endpoint to give a hint
> to the facebook token policy on whether it needs to refresh or not.
>
> Finally, every refreshAccessToken invocation gives the auth-server the
> opportunity to recheck revocation policies and upgrade/downgrade the
> user's and application's permissions.
>


From bburke at redhat.com  Fri Feb 27 12:09:11 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 27 Feb 2015 12:09:11 -0500
Subject: [keycloak-dev] apps access to and refresh of facebook tokens
In-Reply-To: <54F093DC.3070702@redhat.com>
References: <54EF3EDB.4060903@redhat.com>	<1946967211.20445048.1424966958888.JavaMail.zimbra@redhat.com>	<54EF5335.6010501@redhat.com>	<1952677297.20565895.1424974594063.JavaMail.zimbra@redhat.com>	<54EF68D1.5020504@redhat.com>	<999442242.20609060.1424977452320.JavaMail.zimbra@redhat.com>	<54EF77BE.3020901@redhat.com>	<764234478.20641140.1424980123285.JavaMail.zimbra@redhat.com>	<1162494918.16931566.1425017298440.JavaMail.zimbra@redhat.com>
	<54F093DC.3070702@redhat.com>
Message-ID: <54F0A4B7.5090908@redhat.com>

FYI, Facebook has 2 types of tokens:

* short lived..usually last for hours
* long lived usually lasts for 60 days

As Marek pointed out, token refreshes require a browser redirect for 
Facebook.  Knowing that, a REST service is not going to be able to 
refresh a facebook token.  Let's take this further with an example.

You have a "Contact-List" service that obtains a list of contacts from a 
social provider.  You have a separate Javascript application that wants 
to display a list of contacts.  The "Contact-List" service has to know 
the token and the social provider type.

So given the above, the Javascript application would have to manage 
facebook tokens.  How would that even work?  It would have to be done 
without the Javascript app losing its state.

On 2/27/2015 10:57 AM, Bill Burke wrote:
> On 2/27/2015 1:08 AM, Stian Thorgersen wrote:
>>
>> I just think we're making something quite simple into something a lot more complex for no benefit.
>>
>
> I think you are making our design more complex or less performant than
> it needs to be.  I don't want a specific endpoint just to refresh a
> token for a specific broker.  We're also going to want to embed nested
> access tokens for specific keycloak nested application invocations.  I
> don't want a separate REST service just for that too.
>
> I also want nested REST invocations to work without having to invoke on
> the auth server for every request.  The access token should have
> everything the application needs so that it can reduce traffic with the
> server.  What if a stateless, bearer-only REST services needs the
> facebook token?  If we're talking Javascript apps, then the backend will
> be entirely bearer-only stateless REST services.
>
> I don't want to require adapter specific configuration.
>
> I the vast majority of cases, I think facebook token refreshing can be
> handled automatically by the adapter and the auth-server-side configured
> token policies.  We can make the facebook token policy have different
> configuration options to:
>
> * never to refresh the token
> * modify the access token's expiration to sync with the facebook one.
>
> We could add a "scope" parameter to refreshToken endpoint to give a hint
> to the facebook token policy on whether it needs to refresh or not.
>
> Finally, every refreshAccessToken invocation gives the auth-server the
> opportunity to recheck revocation policies and upgrade/downgrade the
> user's and application's permissions.
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From psilva at redhat.com  Fri Feb 27 12:23:04 2015
From: psilva at redhat.com (Pedro Igor Silva)
Date: Fri, 27 Feb 2015 12:23:04 -0500 (EST)
Subject: [keycloak-dev] apps access to and refresh of facebook tokens
In-Reply-To: <54F0A4B7.5090908@redhat.com>
References: <54EF3EDB.4060903@redhat.com> <54EF68D1.5020504@redhat.com>
	<999442242.20609060.1424977452320.JavaMail.zimbra@redhat.com>
	<54EF77BE.3020901@redhat.com>
	<764234478.20641140.1424980123285.JavaMail.zimbra@redhat.com>
	<1162494918.16931566.1425017298440.JavaMail.zimbra@redhat.com>
	<54F093DC.3070702@redhat.com> <54F0A4B7.5090908@redhat.com>
Message-ID: <1575632441.21308963.1425057784961.JavaMail.zimbra@redhat.com>

Maybe using an iframe ?

For mobile apps this can be accomplished by using a web view, I think.

----- Original Message -----
From: "Bill Burke" <bburke at redhat.com>
To: keycloak-dev at lists.jboss.org
Sent: Friday, February 27, 2015 2:09:11 PM
Subject: Re: [keycloak-dev] apps access to and refresh of facebook tokens

FYI, Facebook has 2 types of tokens:

* short lived..usually last for hours
* long lived usually lasts for 60 days

As Marek pointed out, token refreshes require a browser redirect for 
Facebook.  Knowing that, a REST service is not going to be able to 
refresh a facebook token.  Let's take this further with an example.

You have a "Contact-List" service that obtains a list of contacts from a 
social provider.  You have a separate Javascript application that wants 
to display a list of contacts.  The "Contact-List" service has to know 
the token and the social provider type.

So given the above, the Javascript application would have to manage 
facebook tokens.  How would that even work?  It would have to be done 
without the Javascript app losing its state.

On 2/27/2015 10:57 AM, Bill Burke wrote:
> On 2/27/2015 1:08 AM, Stian Thorgersen wrote:
>>
>> I just think we're making something quite simple into something a lot more complex for no benefit.
>>
>
> I think you are making our design more complex or less performant than
> it needs to be.  I don't want a specific endpoint just to refresh a
> token for a specific broker.  We're also going to want to embed nested
> access tokens for specific keycloak nested application invocations.  I
> don't want a separate REST service just for that too.
>
> I also want nested REST invocations to work without having to invoke on
> the auth server for every request.  The access token should have
> everything the application needs so that it can reduce traffic with the
> server.  What if a stateless, bearer-only REST services needs the
> facebook token?  If we're talking Javascript apps, then the backend will
> be entirely bearer-only stateless REST services.
>
> I don't want to require adapter specific configuration.
>
> I the vast majority of cases, I think facebook token refreshing can be
> handled automatically by the adapter and the auth-server-side configured
> token policies.  We can make the facebook token policy have different
> configuration options to:
>
> * never to refresh the token
> * modify the access token's expiration to sync with the facebook one.
>
> We could add a "scope" parameter to refreshToken endpoint to give a hint
> to the facebook token policy on whether it needs to refresh or not.
>
> Finally, every refreshAccessToken invocation gives the auth-server the
> opportunity to recheck revocation policies and upgrade/downgrade the
> user's and application's permissions.
>

-- 
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 Feb 27 12:23:56 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 27 Feb 2015 12:23:56 -0500
Subject: [keycloak-dev] apps access to and refresh of facebook tokens
In-Reply-To: <54F0A4B7.5090908@redhat.com>
References: <54EF3EDB.4060903@redhat.com>	<1946967211.20445048.1424966958888.JavaMail.zimbra@redhat.com>	<54EF5335.6010501@redhat.com>	<1952677297.20565895.1424974594063.JavaMail.zimbra@redhat.com>	<54EF68D1.5020504@redhat.com>	<999442242.20609060.1424977452320.JavaMail.zimbra@redhat.com>	<54EF77BE.3020901@redhat.com>	<764234478.20641140.1424980123285.JavaMail.zimbra@redhat.com>	<1162494918.16931566.1425017298440.JavaMail.zimbra@redhat.com>	<54F093DC.3070702@redhat.com>
	<54F0A4B7.5090908@redhat.com>
Message-ID: <54F0A82C.5030104@redhat.com>

A few more thoughts:

* Why wouldn't we just ask for long-lived tokens with a social login? 
Why wouldn't we set the max SSO session to be shorter than the 
long-lived token timeout?  Then there is no refresh logic required

* Google uses refresh tokens.

* I don't think Twitter expires access tokens :)

* You could handle this generically without specific broker knowledge. 
AccessTokenResponse from a refreshToken call could just state that the 
adapter must redirect back to the auth server in order to execute the 
refresh.

On 2/27/2015 12:09 PM, Bill Burke wrote:
> FYI, Facebook has 2 types of tokens:
>
> * short lived..usually last for hours
> * long lived usually lasts for 60 days
>
> As Marek pointed out, token refreshes require a browser redirect for
> Facebook.  Knowing that, a REST service is not going to be able to
> refresh a facebook token.  Let's take this further with an example.
>
> You have a "Contact-List" service that obtains a list of contacts from a
> social provider.  You have a separate Javascript application that wants
> to display a list of contacts.  The "Contact-List" service has to know
> the token and the social provider type.
>
> So given the above, the Javascript application would have to manage
> facebook tokens.  How would that even work?  It would have to be done
> without the Javascript app losing its state.
>
> On 2/27/2015 10:57 AM, Bill Burke wrote:
>> On 2/27/2015 1:08 AM, Stian Thorgersen wrote:
>>>
>>> I just think we're making something quite simple into something a lot more complex for no benefit.
>>>
>>
>> I think you are making our design more complex or less performant than
>> it needs to be.  I don't want a specific endpoint just to refresh a
>> token for a specific broker.  We're also going to want to embed nested
>> access tokens for specific keycloak nested application invocations.  I
>> don't want a separate REST service just for that too.
>>
>> I also want nested REST invocations to work without having to invoke on
>> the auth server for every request.  The access token should have
>> everything the application needs so that it can reduce traffic with the
>> server.  What if a stateless, bearer-only REST services needs the
>> facebook token?  If we're talking Javascript apps, then the backend will
>> be entirely bearer-only stateless REST services.
>>
>> I don't want to require adapter specific configuration.
>>
>> I the vast majority of cases, I think facebook token refreshing can be
>> handled automatically by the adapter and the auth-server-side configured
>> token policies.  We can make the facebook token policy have different
>> configuration options to:
>>
>> * never to refresh the token
>> * modify the access token's expiration to sync with the facebook one.
>>
>> We could add a "scope" parameter to refreshToken endpoint to give a hint
>> to the facebook token policy on whether it needs to refresh or not.
>>
>> Finally, every refreshAccessToken invocation gives the auth-server the
>> opportunity to recheck revocation policies and upgrade/downgrade the
>> user's and application's permissions.
>>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bburke at redhat.com  Fri Feb 27 20:04:22 2015
From: bburke at redhat.com (Bill Burke)
Date: Fri, 27 Feb 2015 20:04:22 -0500
Subject: [keycloak-dev] gotta love this download curve
Message-ID: <54F11416.8000308@redhat.com>

http://sourceforge.net/projects/keycloak/files/stats/timeline?dates=2013-02-22+to+2015-02-28


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

From bruno at abstractj.org  Sat Feb 28 06:22:24 2015
From: bruno at abstractj.org (Bruno Oliveira)
Date: Sat, 28 Feb 2015 03:22:24 -0800 (PST)
Subject: [keycloak-dev] gotta love this download curve
In-Reply-To: <54F11416.8000308@redhat.com>
References: <54F11416.8000308@redhat.com>
Message-ID: <1425122543346.06de43f1@Nodemailer>

Amazing and congrats!



?

abstractj
PGP: 0x84DC9914

On Fri, Feb 27, 2015 at 10:04 PM, Bill Burke <bburke at redhat.com> wrote:

> http://sourceforge.net/projects/keycloak/files/stats/timeline?dates=2013-02-22+to+2015-02-28
> -- 
> 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/20150228/688bdb79/attachment.html