From stian at redhat.com  Mon Dec  1 07:49:34 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 1 Dec 2014 07:49:34 -0500 (EST)
Subject: [keycloak-user] REST services supporting basic auth and bearer
 tokens
In-Reply-To: <2102923959.15427560.1417187983153.JavaMail.zimbra@redhat.com>
References: <648294658.14664021.1417010058756.JavaMail.zimbra@redhat.com>
	<560122619.6615545.1417098022956.JavaMail.zimbra@redhat.com>
	<602281263.15207272.1417098371862.JavaMail.zimbra@redhat.com>
	<547735AF.90608@redhat.com>
	<1308843455.15212297.1417099032933.JavaMail.zimbra@redhat.com>
	<547741AF.1000606@redhat.com>
	<2119641692.7035795.1417159191128.JavaMail.zimbra@redhat.com>
	<2102923959.15427560.1417187983153.JavaMail.zimbra@redhat.com>
Message-ID: <1913632965.7845813.1417438174654.JavaMail.zimbra@redhat.com>

Merged

The role mappings where missing in the test as the app didn't have a scope mapping. I added full scope mappings for the app in https://github.com/keycloak/keycloak/commit/e069f303a4f42f80541a7c123cfe9920868e359b.

Thanks

----- Original Message -----
> From: "Gary Brown" <gbrown at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: "Marek Posolda" <mposolda at redhat.com>, keycloak-user at lists.jboss.org
> Sent: Friday, 28 November, 2014 4:19:43 PM
> Subject: Re: [keycloak-user] REST services supporting basic auth and bearer tokens
> 
> Hi Stian and Marek
> 
> PR submitted: https://github.com/keycloak/keycloak/pull/874
> 
> I've added a comment to the jira
> (https://issues.jboss.org/browse/KEYCLOAK-861) about roles - if whoever
> reviews the PR could let me know.
> 
> Thanks.
> 
> Regards
> Gary
> 
> ----- Original Message -----
> > I think in the long run if we try to show all features in the demo it'll
> > end
> > up getting to bloated. It's probably best to keep the demo to the core
> > features (SSO, etc) and have separate basic examples (quickstarts?) for the
> > rest.
> > 
> > ----- Original Message -----
> > > From: "Marek Posolda" <mposolda at redhat.com>
> > > To: "Gary Brown" <gbrown at redhat.com>
> > > Cc: "Stian Thorgersen" <stian at redhat.com>, keycloak-user at lists.jboss.org
> > > Sent: Thursday, 27 November, 2014 4:22:23 PM
> > > Subject: Re: [keycloak-user] REST services supporting basic auth and
> > > bearer
> > > tokens
> > > 
> > > Oki, sounds good to me.
> > > 
> > > Marek
> > > 
> > > On 27.11.2014 15:37, Gary Brown wrote:
> > > > Hi Marek
> > > >
> > > > I was originally thinking the same - but it would complicate the demo
> > > > more.
> > > >
> > > > Its possible that the database-service could simply be changed to
> > > > support
> > > > both bearer and basic auth, and then provide curl instructions to
> > > > demonstrate basic auth access, but then there wouldn't be an example
> > > > showing a bearer-only configuration.
> > > >
> > > > So assuming that a 'bearer-only' example is still required, then having
> > > > a
> > > > completely independent basic auth example may be the next best thing -
> > > > and
> > > > then leave it as an exercise for the user to enable basic auth on the
> > > > database-service?
> > > >
> > > > Regards
> > > > Gary
> > > >
> > > > ----- Original Message -----
> > > >> Sent previous email before I figured that you guys already decide on
> > > >> something, so feel free to ignore me:-)
> > > >>
> > > >> On the other hand, it may be nice to show in the example that
> > > >> particular
> > > >> jaxrs endpoint is able to support both bearer and basic auth in same
> > > >> application imo.
> > > >>
> > > >> Marek
> > > >>
> > > >> On 27.11.2014 15:26, Gary Brown wrote:
> > > >>> Ok sounds good.
> > > >>>
> > > >>> ----- Original Message -----
> > > >>>> Another option is to add a separate basic example outside of the
> > > >>>> demo,
> > > >>>> like
> > > >>>> what was done for multi-tenancy. A single jax-rs endpoint that
> > > >>>> supports
> > > >>>> basic auth and an example curl command to invoke it?
> > > >>>>
> > > >>>> ----- Original Message -----
> > > >>>>> From: "Gary Brown" <gbrown at redhat.com>
> > > >>>>> To: "Stian Thorgersen" <stian at redhat.com>
> > > >>>>> Cc: "Marek Posolda" <mposolda at redhat.com>,
> > > >>>>> keycloak-user at lists.jboss.org
> > > >>>>> Sent: Thursday, 27 November, 2014 2:59:46 PM
> > > >>>>> Subject: Re: [keycloak-user] REST services supporting basic auth
> > > >>>>> and
> > > >>>>> bearer
> > > >>>>> tokens
> > > >>>>>
> > > >>>>> In terms of example, was thinking the database-service is ideal -
> > > >>>>> however
> > > >>>>> I'm
> > > >>>>> guessing it also needs to be shown as a 'bearer-only' example (as
> > > >>>>> now).
> > > >>>>>
> > > >>>>> In the same way that there is multiple customer-apps, one approach
> > > >>>>> could
> > > >>>>> be
> > > >>>>> to have an alternate database-service supporting basic auth as
> > > >>>>> well,
> > > >>>>> but
> > > >>>>> then would also need a separate copy of the testrealm.json.
> > > >>>>>
> > > >>>>> Thoughts?
> > > >>>>>
> > > >>>>> ----- Original Message -----
> > > >>>>>> Great, if you do a PR include an example we can merge it before a
> > > >>>>>> 1.1.0.Beta2
> > > >>>>>> release (probably next week)
> > > >>>>>>
> > > >>>>>> ----- Original Message -----
> > > >>>>>>> From: "Gary Brown" <gbrown at redhat.com>
> > > >>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
> > > >>>>>>> Cc: "Marek Posolda" <mposolda at redhat.com>,
> > > >>>>>>> keycloak-user at lists.jboss.org
> > > >>>>>>> Sent: Thursday, 27 November, 2014 1:48:55 PM
> > > >>>>>>> Subject: Re: [keycloak-user] REST services supporting basic auth
> > > >>>>>>> and
> > > >>>>>>> bearer
> > > >>>>>>> tokens
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> ----- Original Message -----
> > > >>>>>>>> Looks good to me, but I'd like it to be an optional feature that
> > > >>>>>>>> is
> > > >>>>>>>> enabled
> > > >>>>>>>> in keycloak.json (should be disabled by default).
> > > >>>>>>> Sounds reasonable - I'll call the property 'enableBasicAuth'.
> > > >>>>>>>
> > > >>>>>>>> Another thing is that we should add an example + documentation
> > > >>>>>>>> for
> > > >>>>>>>> this
> > > >>>>>>>> feature.
> > > >>>>>>> Will do.
> > > >>>>>>>
> > > >>>>>>>> ----- Original Message -----
> > > >>>>>>>>> From: "Gary Brown" <gbrown at redhat.com>
> > > >>>>>>>>> To: "Marek Posolda" <mposolda at redhat.com>
> > > >>>>>>>>> Cc: keycloak-user at lists.jboss.org
> > > >>>>>>>>> Sent: Thursday, 27 November, 2014 10:58:21 AM
> > > >>>>>>>>> Subject: Re: [keycloak-user] REST services supporting basic
> > > >>>>>>>>> auth
> > > >>>>>>>>> and
> > > >>>>>>>>> bearer
> > > >>>>>>>>> tokens
> > > >>>>>>>>>
> > > >>>>>>>>> Hi Marek
> > > >>>>>>>>>
> > > >>>>>>>>> ----- Original Message -----
> > > >>>>>>>>>> Hi,
> > > >>>>>>>>>>
> > > >>>>>>>>>> I am not 100% sure if having basic auth with direct grant
> > > >>>>>>>>>> directly
> > > >>>>>>>>>> in
> > > >>>>>>>>>> our adapters is way to go. Probably yes as for your use-case
> > > >>>>>>>>>> it
> > > >>>>>>>>>> makes
> > > >>>>>>>>>> sense, so I am slightly for push your change as PR. But maybe
> > > >>>>>>>>>> others
> > > >>>>>>>>>> from team have different opinion.
> > > >>>>>>>>>>
> > > >>>>>>>>>> Earlier this week I've added DirectAccessGrantsLoginModule to
> > > >>>>>>>>>> KC
> > > >>>>>>>>>> codebase, which is quite similar and is intended to be used
> > > >>>>>>>>>> for
> > > >>>>>>>>>> non-web
> > > >>>>>>>>>> applications (like SSH), which rely on JAAS. But I guess that
> > > >>>>>>>>>> using
> > > >>>>>>>>>> this
> > > >>>>>>>>>> one is not good option for you as you want support for Basic
> > > >>>>>>>>>> and
> > > >>>>>>>>>> Bearer
> > > >>>>>>>>>> authentication in same web application, right?
> > > >>>>>>>>> Thats correct.
> > > >>>>>>>>>
> > > >>>>>>>>>> Few more minor points to your changes:
> > > >>>>>>>>>> - Is it possible to use net.iharder.Base64 instead of
> > > >>>>>>>>>> org.apache.commons.codec.binary.Base64? Whole KC code has
> > > >>>>>>>>>> dependency
> > > >>>>>>>>>> on
> > > >>>>>>>>>> net.iharder, so would be likely better to use this one to
> > > >>>>>>>>>> avoid
> > > >>>>>>>>>> possible
> > > >>>>>>>>>> dependency issues in adapters.
> > > >>>>>>>>> That shouldn't be a problem.
> > > >>>>>>>>>
> > > >>>>>>>>>> - Wonder if it's possible to simplify a bit, like have single
> > > >>>>>>>>>> "completeAuthentication" method for both bearer and basic
> > > >>>>>>>>>> authenticator
> > > >>>>>>>>>> (afaik only difference among them is different authMethod
> > > >>>>>>>>>> right?).
> > > >>>>>>>>>> But
> > > >>>>>>>>>> this is really minor.
> > > >>>>>>>>> Will do.
> > > >>>>>>>>>
> > > >>>>>>>>> I'll wait until mid next week before doing any more on this, to
> > > >>>>>>>>> see
> > > >>>>>>>>> whether
> > > >>>>>>>>> others have an opinion.
> > > >>>>>>>>>
> > > >>>>>>>>> If the PR was accepted, any chance it could go into 1.1 even
> > > >>>>>>>>> though
> > > >>>>>>>>> in
> > > >>>>>>>>> beta?
> > > >>>>>>>>> If no, any idea what the timescale is for 1.2.beta1?
> > > >>>>>>>>>
> > > >>>>>>>>> Thanks for your feedback.
> > > >>>>>>>>>
> > > >>>>>>>>> Regards
> > > >>>>>>>>> Gary
> > > >>>>>>>>>
> > > >>>>>>>>>> Marek
> > > >>>>>>>>>>
> > > >>>>>>>>>> On 26.11.2014 14:54, Gary Brown wrote:
> > > >>>>>>>>>>> Hi
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Concrete use case - we have implemented the OASIS S-RAMP
> > > >>>>>>>>>>> specification,
> > > >>>>>>>>>>> in
> > > >>>>>>>>>>> which it requires basic auth support
> > > >>>>>>>>>>> (http://docs.oasis-open.org/s-ramp/s-ramp/v1.0/s-ramp-v1.0-part2-atom-binding.html
> > > >>>>>>>>>>> section 5 "The S-RAMP Specification does not attempt to
> > > >>>>>>>>>>> define
> > > >>>>>>>>>>> a
> > > >>>>>>>>>>> security
> > > >>>>>>>>>>> model for products that implement it.  For the Atom Binding,
> > > >>>>>>>>>>> the
> > > >>>>>>>>>>> only
> > > >>>>>>>>>>> security requirement is that at a minimum, client and server
> > > >>>>>>>>>>> implementations MUST be capable of being configured to use
> > > >>>>>>>>>>> HTTP
> > > >>>>>>>>>>> Basic
> > > >>>>>>>>>>> Authentication in conjunction with a connection made with
> > > >>>>>>>>>>> TLS.").
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> However we also need the same service to support bearer
> > > >>>>>>>>>>> token,
> > > >>>>>>>>>>> for
> > > >>>>>>>>>>> use
> > > >>>>>>>>>>> within our KeyCloak SSO session.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> I've implemented a possible solution, details defined on
> > > >>>>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-861.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> If this solution is on the right path, I would appreciate any
> > > >>>>>>>>>>> feedback
> > > >>>>>>>>>>> on
> > > >>>>>>>>>>> any changes that might be required before submitting a PR.
> > > >>>>>>>>>>> Currently
> > > >>>>>>>>>>> there
> > > >>>>>>>>>>> are no tests, but would aim to provide some with the PR.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Regards
> > > >>>>>>>>>>> Gary
> > > >>>>>>>>>>> _______________________________________________
> > > >>>>>>>>>>> keycloak-user mailing list
> > > >>>>>>>>>>> keycloak-user at lists.jboss.org
> > > >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> > > >>>>>>>>> _______________________________________________
> > > >>>>>>>>> keycloak-user mailing list
> > > >>>>>>>>> keycloak-user at lists.jboss.org
> > > >>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> > > >>>>>>>>>
> > > >>
> > > 
> > > 
> > 
> 

From gbrown at redhat.com  Mon Dec  1 08:31:28 2014
From: gbrown at redhat.com (Gary Brown)
Date: Mon, 1 Dec 2014 08:31:28 -0500 (EST)
Subject: [keycloak-user] REST services supporting basic auth and bearer
 tokens
In-Reply-To: <1913632965.7845813.1417438174654.JavaMail.zimbra@redhat.com>
References: <648294658.14664021.1417010058756.JavaMail.zimbra@redhat.com>
	<602281263.15207272.1417098371862.JavaMail.zimbra@redhat.com>
	<547735AF.90608@redhat.com>
	<1308843455.15212297.1417099032933.JavaMail.zimbra@redhat.com>
	<547741AF.1000606@redhat.com>
	<2119641692.7035795.1417159191128.JavaMail.zimbra@redhat.com>
	<2102923959.15427560.1417187983153.JavaMail.zimbra@redhat.com>
	<1913632965.7845813.1417438174654.JavaMail.zimbra@redhat.com>
Message-ID: <1634351083.15998179.1417440688565.JavaMail.zimbra@redhat.com>

Ok thanks.

Regards
Gary

----- Original Message -----
> Merged
> 
> The role mappings where missing in the test as the app didn't have a scope
> mapping. I added full scope mappings for the app in
> https://github.com/keycloak/keycloak/commit/e069f303a4f42f80541a7c123cfe9920868e359b.
> 
> Thanks
> 
> ----- Original Message -----
> > From: "Gary Brown" <gbrown at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: "Marek Posolda" <mposolda at redhat.com>, keycloak-user at lists.jboss.org
> > Sent: Friday, 28 November, 2014 4:19:43 PM
> > Subject: Re: [keycloak-user] REST services supporting basic auth and bearer
> > tokens
> > 
> > Hi Stian and Marek
> > 
> > PR submitted: https://github.com/keycloak/keycloak/pull/874
> > 
> > I've added a comment to the jira
> > (https://issues.jboss.org/browse/KEYCLOAK-861) about roles - if whoever
> > reviews the PR could let me know.
> > 
> > Thanks.
> > 
> > Regards
> > Gary
> > 
> > ----- Original Message -----
> > > I think in the long run if we try to show all features in the demo it'll
> > > end
> > > up getting to bloated. It's probably best to keep the demo to the core
> > > features (SSO, etc) and have separate basic examples (quickstarts?) for
> > > the
> > > rest.
> > > 
> > > ----- Original Message -----
> > > > From: "Marek Posolda" <mposolda at redhat.com>
> > > > To: "Gary Brown" <gbrown at redhat.com>
> > > > Cc: "Stian Thorgersen" <stian at redhat.com>,
> > > > keycloak-user at lists.jboss.org
> > > > Sent: Thursday, 27 November, 2014 4:22:23 PM
> > > > Subject: Re: [keycloak-user] REST services supporting basic auth and
> > > > bearer
> > > > tokens
> > > > 
> > > > Oki, sounds good to me.
> > > > 
> > > > Marek
> > > > 
> > > > On 27.11.2014 15:37, Gary Brown wrote:
> > > > > Hi Marek
> > > > >
> > > > > I was originally thinking the same - but it would complicate the demo
> > > > > more.
> > > > >
> > > > > Its possible that the database-service could simply be changed to
> > > > > support
> > > > > both bearer and basic auth, and then provide curl instructions to
> > > > > demonstrate basic auth access, but then there wouldn't be an example
> > > > > showing a bearer-only configuration.
> > > > >
> > > > > So assuming that a 'bearer-only' example is still required, then
> > > > > having
> > > > > a
> > > > > completely independent basic auth example may be the next best thing
> > > > > -
> > > > > and
> > > > > then leave it as an exercise for the user to enable basic auth on the
> > > > > database-service?
> > > > >
> > > > > Regards
> > > > > Gary
> > > > >
> > > > > ----- Original Message -----
> > > > >> Sent previous email before I figured that you guys already decide on
> > > > >> something, so feel free to ignore me:-)
> > > > >>
> > > > >> On the other hand, it may be nice to show in the example that
> > > > >> particular
> > > > >> jaxrs endpoint is able to support both bearer and basic auth in same
> > > > >> application imo.
> > > > >>
> > > > >> Marek
> > > > >>
> > > > >> On 27.11.2014 15:26, Gary Brown wrote:
> > > > >>> Ok sounds good.
> > > > >>>
> > > > >>> ----- Original Message -----
> > > > >>>> Another option is to add a separate basic example outside of the
> > > > >>>> demo,
> > > > >>>> like
> > > > >>>> what was done for multi-tenancy. A single jax-rs endpoint that
> > > > >>>> supports
> > > > >>>> basic auth and an example curl command to invoke it?
> > > > >>>>
> > > > >>>> ----- Original Message -----
> > > > >>>>> From: "Gary Brown" <gbrown at redhat.com>
> > > > >>>>> To: "Stian Thorgersen" <stian at redhat.com>
> > > > >>>>> Cc: "Marek Posolda" <mposolda at redhat.com>,
> > > > >>>>> keycloak-user at lists.jboss.org
> > > > >>>>> Sent: Thursday, 27 November, 2014 2:59:46 PM
> > > > >>>>> Subject: Re: [keycloak-user] REST services supporting basic auth
> > > > >>>>> and
> > > > >>>>> bearer
> > > > >>>>> tokens
> > > > >>>>>
> > > > >>>>> In terms of example, was thinking the database-service is ideal -
> > > > >>>>> however
> > > > >>>>> I'm
> > > > >>>>> guessing it also needs to be shown as a 'bearer-only' example (as
> > > > >>>>> now).
> > > > >>>>>
> > > > >>>>> In the same way that there is multiple customer-apps, one
> > > > >>>>> approach
> > > > >>>>> could
> > > > >>>>> be
> > > > >>>>> to have an alternate database-service supporting basic auth as
> > > > >>>>> well,
> > > > >>>>> but
> > > > >>>>> then would also need a separate copy of the testrealm.json.
> > > > >>>>>
> > > > >>>>> Thoughts?
> > > > >>>>>
> > > > >>>>> ----- Original Message -----
> > > > >>>>>> Great, if you do a PR include an example we can merge it before
> > > > >>>>>> a
> > > > >>>>>> 1.1.0.Beta2
> > > > >>>>>> release (probably next week)
> > > > >>>>>>
> > > > >>>>>> ----- Original Message -----
> > > > >>>>>>> From: "Gary Brown" <gbrown at redhat.com>
> > > > >>>>>>> To: "Stian Thorgersen" <stian at redhat.com>
> > > > >>>>>>> Cc: "Marek Posolda" <mposolda at redhat.com>,
> > > > >>>>>>> keycloak-user at lists.jboss.org
> > > > >>>>>>> Sent: Thursday, 27 November, 2014 1:48:55 PM
> > > > >>>>>>> Subject: Re: [keycloak-user] REST services supporting basic
> > > > >>>>>>> auth
> > > > >>>>>>> and
> > > > >>>>>>> bearer
> > > > >>>>>>> tokens
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>> ----- Original Message -----
> > > > >>>>>>>> Looks good to me, but I'd like it to be an optional feature
> > > > >>>>>>>> that
> > > > >>>>>>>> is
> > > > >>>>>>>> enabled
> > > > >>>>>>>> in keycloak.json (should be disabled by default).
> > > > >>>>>>> Sounds reasonable - I'll call the property 'enableBasicAuth'.
> > > > >>>>>>>
> > > > >>>>>>>> Another thing is that we should add an example + documentation
> > > > >>>>>>>> for
> > > > >>>>>>>> this
> > > > >>>>>>>> feature.
> > > > >>>>>>> Will do.
> > > > >>>>>>>
> > > > >>>>>>>> ----- Original Message -----
> > > > >>>>>>>>> From: "Gary Brown" <gbrown at redhat.com>
> > > > >>>>>>>>> To: "Marek Posolda" <mposolda at redhat.com>
> > > > >>>>>>>>> Cc: keycloak-user at lists.jboss.org
> > > > >>>>>>>>> Sent: Thursday, 27 November, 2014 10:58:21 AM
> > > > >>>>>>>>> Subject: Re: [keycloak-user] REST services supporting basic
> > > > >>>>>>>>> auth
> > > > >>>>>>>>> and
> > > > >>>>>>>>> bearer
> > > > >>>>>>>>> tokens
> > > > >>>>>>>>>
> > > > >>>>>>>>> Hi Marek
> > > > >>>>>>>>>
> > > > >>>>>>>>> ----- Original Message -----
> > > > >>>>>>>>>> Hi,
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> I am not 100% sure if having basic auth with direct grant
> > > > >>>>>>>>>> directly
> > > > >>>>>>>>>> in
> > > > >>>>>>>>>> our adapters is way to go. Probably yes as for your use-case
> > > > >>>>>>>>>> it
> > > > >>>>>>>>>> makes
> > > > >>>>>>>>>> sense, so I am slightly for push your change as PR. But
> > > > >>>>>>>>>> maybe
> > > > >>>>>>>>>> others
> > > > >>>>>>>>>> from team have different opinion.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> Earlier this week I've added DirectAccessGrantsLoginModule
> > > > >>>>>>>>>> to
> > > > >>>>>>>>>> KC
> > > > >>>>>>>>>> codebase, which is quite similar and is intended to be used
> > > > >>>>>>>>>> for
> > > > >>>>>>>>>> non-web
> > > > >>>>>>>>>> applications (like SSH), which rely on JAAS. But I guess
> > > > >>>>>>>>>> that
> > > > >>>>>>>>>> using
> > > > >>>>>>>>>> this
> > > > >>>>>>>>>> one is not good option for you as you want support for Basic
> > > > >>>>>>>>>> and
> > > > >>>>>>>>>> Bearer
> > > > >>>>>>>>>> authentication in same web application, right?
> > > > >>>>>>>>> Thats correct.
> > > > >>>>>>>>>
> > > > >>>>>>>>>> Few more minor points to your changes:
> > > > >>>>>>>>>> - Is it possible to use net.iharder.Base64 instead of
> > > > >>>>>>>>>> org.apache.commons.codec.binary.Base64? Whole KC code has
> > > > >>>>>>>>>> dependency
> > > > >>>>>>>>>> on
> > > > >>>>>>>>>> net.iharder, so would be likely better to use this one to
> > > > >>>>>>>>>> avoid
> > > > >>>>>>>>>> possible
> > > > >>>>>>>>>> dependency issues in adapters.
> > > > >>>>>>>>> That shouldn't be a problem.
> > > > >>>>>>>>>
> > > > >>>>>>>>>> - Wonder if it's possible to simplify a bit, like have
> > > > >>>>>>>>>> single
> > > > >>>>>>>>>> "completeAuthentication" method for both bearer and basic
> > > > >>>>>>>>>> authenticator
> > > > >>>>>>>>>> (afaik only difference among them is different authMethod
> > > > >>>>>>>>>> right?).
> > > > >>>>>>>>>> But
> > > > >>>>>>>>>> this is really minor.
> > > > >>>>>>>>> Will do.
> > > > >>>>>>>>>
> > > > >>>>>>>>> I'll wait until mid next week before doing any more on this,
> > > > >>>>>>>>> to
> > > > >>>>>>>>> see
> > > > >>>>>>>>> whether
> > > > >>>>>>>>> others have an opinion.
> > > > >>>>>>>>>
> > > > >>>>>>>>> If the PR was accepted, any chance it could go into 1.1 even
> > > > >>>>>>>>> though
> > > > >>>>>>>>> in
> > > > >>>>>>>>> beta?
> > > > >>>>>>>>> If no, any idea what the timescale is for 1.2.beta1?
> > > > >>>>>>>>>
> > > > >>>>>>>>> Thanks for your feedback.
> > > > >>>>>>>>>
> > > > >>>>>>>>> Regards
> > > > >>>>>>>>> Gary
> > > > >>>>>>>>>
> > > > >>>>>>>>>> Marek
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> On 26.11.2014 14:54, Gary Brown wrote:
> > > > >>>>>>>>>>> Hi
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> Concrete use case - we have implemented the OASIS S-RAMP
> > > > >>>>>>>>>>> specification,
> > > > >>>>>>>>>>> in
> > > > >>>>>>>>>>> which it requires basic auth support
> > > > >>>>>>>>>>> (http://docs.oasis-open.org/s-ramp/s-ramp/v1.0/s-ramp-v1.0-part2-atom-binding.html
> > > > >>>>>>>>>>> section 5 "The S-RAMP Specification does not attempt to
> > > > >>>>>>>>>>> define
> > > > >>>>>>>>>>> a
> > > > >>>>>>>>>>> security
> > > > >>>>>>>>>>> model for products that implement it.  For the Atom
> > > > >>>>>>>>>>> Binding,
> > > > >>>>>>>>>>> the
> > > > >>>>>>>>>>> only
> > > > >>>>>>>>>>> security requirement is that at a minimum, client and
> > > > >>>>>>>>>>> server
> > > > >>>>>>>>>>> implementations MUST be capable of being configured to use
> > > > >>>>>>>>>>> HTTP
> > > > >>>>>>>>>>> Basic
> > > > >>>>>>>>>>> Authentication in conjunction with a connection made with
> > > > >>>>>>>>>>> TLS.").
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> However we also need the same service to support bearer
> > > > >>>>>>>>>>> token,
> > > > >>>>>>>>>>> for
> > > > >>>>>>>>>>> use
> > > > >>>>>>>>>>> within our KeyCloak SSO session.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> I've implemented a possible solution, details defined on
> > > > >>>>>>>>>>> https://issues.jboss.org/browse/KEYCLOAK-861.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> If this solution is on the right path, I would appreciate
> > > > >>>>>>>>>>> any
> > > > >>>>>>>>>>> feedback
> > > > >>>>>>>>>>> on
> > > > >>>>>>>>>>> any changes that might be required before submitting a PR.
> > > > >>>>>>>>>>> Currently
> > > > >>>>>>>>>>> there
> > > > >>>>>>>>>>> are no tests, but would aim to provide some with the PR.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> Regards
> > > > >>>>>>>>>>> Gary
> > > > >>>>>>>>>>> _______________________________________________
> > > > >>>>>>>>>>> keycloak-user mailing list
> > > > >>>>>>>>>>> keycloak-user at lists.jboss.org
> > > > >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> > > > >>>>>>>>> _______________________________________________
> > > > >>>>>>>>> keycloak-user mailing list
> > > > >>>>>>>>> keycloak-user at lists.jboss.org
> > > > >>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> > > > >>>>>>>>>
> > > > >>
> > > > 
> > > > 
> > > 
> > 
> 

From robin1233 at gmail.com  Mon Dec  1 16:35:37 2014
From: robin1233 at gmail.com (robinfernandes .)
Date: Mon, 1 Dec 2014 16:35:37 -0500
Subject: [keycloak-user] Production Database
Message-ID: <CAFOTW4YHdCFdnG_zFmSo1A26H5kfBvUMtrzFKw1izp98zAaFBg@mail.gmail.com>

Hi Guys,

We were planning on using OpenLDAP along with H2, do we still need to move
to a better relational database like Postgres or MySQL for production
environments instead of H2?
Is there any major concern when using H2?
I am just curious to know because the user guide clearly mentions to "move
to a better relational database in production"
Any thoughts, comments?

Thanks,
Robin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141201/45381fc1/attachment.html 

From mikhail.kuznetsov at hp.com  Mon Dec  1 16:37:26 2014
From: mikhail.kuznetsov at hp.com (Kuznetsov, Mike)
Date: Mon, 1 Dec 2014 21:37:26 +0000
Subject: [keycloak-user] Configuring Session Timeout Settings on a per
 Application-basis rather than a per-Realm
Message-ID: <66122567ABACCC42B5B568EC7E90551A19711C61@G6W2492.americas.hpqcorp.net>

Hello,

My team is working on a project where we have multiple applications where each applications needs to have different timeout settings. From using Keycloak, I see that the timeout settings can only be specified for the entire realm. Therefore, we are forced to have each applications in a separate realms with each realm having its own timeout settings. This means that we will have many realms which are almost the same except for the timeout settings.

Would it be possible to configure the timeout settings on a per-application basis, so that the applications can be in the same realm but have separate timeout settings?

Regards,

-          Mikhail Kuznetsov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141201/c6c16618/attachment-0001.html 

From bburke at redhat.com  Mon Dec  1 21:09:44 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 01 Dec 2014 21:09:44 -0500
Subject: [keycloak-user] Production Database
In-Reply-To: <CAFOTW4YHdCFdnG_zFmSo1A26H5kfBvUMtrzFKw1izp98zAaFBg@mail.gmail.com>
References: <CAFOTW4YHdCFdnG_zFmSo1A26H5kfBvUMtrzFKw1izp98zAaFBg@mail.gmail.com>
Message-ID: <547D1F68.90408@redhat.com>

Depends on whether you cluster or not.  Not sure how good H2 is when you 
hit it with a lot of volume.

On 12/1/2014 4:35 PM, robinfernandes . wrote:
> Hi Guys,
>
> We were planning on using OpenLDAP along with H2, do we still need to
> move to a better relational database like Postgres or MySQL for
> production environments instead of H2?
> Is there any major concern when using H2?
> I am just curious to know because the user guide clearly mentions to
> "move to a better relational database in production"
> Any thoughts, comments?
>
> Thanks,
> Robin
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

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

From bburke at redhat.com  Mon Dec  1 21:11:35 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 01 Dec 2014 21:11:35 -0500
Subject: [keycloak-user] Configuring Session Timeout Settings on a per
 Application-basis rather than a per-Realm
In-Reply-To: <66122567ABACCC42B5B568EC7E90551A19711C61@G6W2492.americas.hpqcorp.net>
References: <66122567ABACCC42B5B568EC7E90551A19711C61@G6W2492.americas.hpqcorp.net>
Message-ID: <547D1FD7.5000708@redhat.com>

We have been planning to allow different access/refresh token timeouts 
per application.  Enough people are asking so we should probably make it 
a priority now.

On 12/1/2014 4:37 PM, Kuznetsov, Mike wrote:
> Hello,
>
> My team is working on a project where we have multiple applications
> where each applications needs to have different timeout settings. From
> using Keycloak, I see that the timeout settings can only be specified
> for the entire realm. Therefore, we are forced to have each applications
> in a separate realms with each realm having its own timeout settings.
> This means that we will have many realms which are almost the same
> except for the timeout settings.
>
> Would it be possible to configure the timeout settings on a
> per-application basis, so that the applications can be in the same realm
> but have separate timeout settings?
>
> Regards,
>
> -Mikhail Kuznetsov
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

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

From stian at redhat.com  Tue Dec  2 05:10:15 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 2 Dec 2014 05:10:15 -0500 (EST)
Subject: [keycloak-user] Production Database
In-Reply-To: <CAFOTW4YHdCFdnG_zFmSo1A26H5kfBvUMtrzFKw1izp98zAaFBg@mail.gmail.com>
References: <CAFOTW4YHdCFdnG_zFmSo1A26H5kfBvUMtrzFKw1izp98zAaFBg@mail.gmail.com>
Message-ID: <555508930.8551211.1417515015872.JavaMail.zimbra@redhat.com>

H2 doesn't by default have row-level locking so will only work with a low load. If you only have a few users it should be fine, but I would certainly do some load testing before going to production. During stress tests we didn't have many concurrent users at all before we started getting failed requests due to lock contention.

You can enable row-level locking, see http://www.h2database.com/html/advanced.html#mvcc, but it looks like it's not a stable feature. You could also increase the lock time-out.

For another embedded database you could also try Apache Derby, which has row-level locking. I've had good experiences with it in the past.

If you want clustering, which I would consider for availability even if you don't need it for scalability, or if you have more than a handful of users (50+?) I'd highly recommend MySQL or PostgreSQL.

----- Original Message -----
> From: "robinfernandes ." <robin1233 at gmail.com>
> To: keycloak-user at lists.jboss.org
> Sent: Monday, 1 December, 2014 10:35:37 PM
> Subject: [keycloak-user] Production Database
> 
> Hi Guys,
> 
> We were planning on using OpenLDAP along with H2, do we still need to move to
> a better relational database like Postgres or MySQL for production
> environments instead of H2?
> Is there any major concern when using H2?
> I am just curious to know because the user guide clearly mentions to "move to
> a better relational database in production"
> Any thoughts, comments?
> 
> Thanks,
> Robin
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

From christinalau28 at icloud.com  Tue Dec  2 11:38:11 2014
From: christinalau28 at icloud.com (Christina Lau)
Date: Tue, 02 Dec 2014 11:38:11 -0500
Subject: [keycloak-user] How to disable https for Keycloak on Openshift?
Message-ID: <CC4F3B5B-518F-4D47-8E19-55663E4582A6@icloud.com>

Hi, I like to run my instance of Keycloak on Openshift using http, however I cannot figure out how to do it.

The default install from cartridge is using https. I tried to set require ssl to none in the master realm, but it has no effect.

I am wondering if we need to update the standalone.xml, but the Openshift version and the appliance version is very different and unsure what to change. Pls advise. Thx?

Christina

From bburke at redhat.com  Tue Dec  2 11:48:21 2014
From: bburke at redhat.com (Bill Burke)
Date: Tue, 02 Dec 2014 11:48:21 -0500
Subject: [keycloak-user] How to disable https for Keycloak on Openshift?
In-Reply-To: <CC4F3B5B-518F-4D47-8E19-55663E4582A6@icloud.com>
References: <CC4F3B5B-518F-4D47-8E19-55663E4582A6@icloud.com>
Message-ID: <547DED55.5040002@redhat.com>

Define "no effect".  Can you log into the admin console via http?

On 12/2/2014 11:38 AM, Christina Lau wrote:
> Hi, I like to run my instance of Keycloak on Openshift using http, however I cannot figure out how to do it.
>
> The default install from cartridge is using https. I tried to set require ssl to none in the master realm, but it has no effect.
>
> I am wondering if we need to update the standalone.xml, but the Openshift version and the appliance version is very different and unsure what to change. Pls advise. Thx?
>
> Christina
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

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

From christinalau28 at icloud.com  Wed Dec  3 06:44:22 2014
From: christinalau28 at icloud.com (Christina Lau)
Date: Wed, 03 Dec 2014 06:44:22 -0500
Subject: [keycloak-user] How to disable https for Keycloak on Openshift?
Message-ID: <C52DE12B-AFB0-4A85-9B02-91498A9C5AD6@icloud.com>

No, I cannot login the admin console via http after I change require ssl to none on Openshift keycloak cartridge.



From stian at redhat.com  Wed Dec  3 06:53:03 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 3 Dec 2014 06:53:03 -0500 (EST)
Subject: [keycloak-user] How to disable https for Keycloak on Openshift?
In-Reply-To: <C52DE12B-AFB0-4A85-9B02-91498A9C5AD6@icloud.com>
References: <C52DE12B-AFB0-4A85-9B02-91498A9C5AD6@icloud.com>
Message-ID: <898467382.9532042.1417607583105.JavaMail.zimbra@redhat.com>

You really need to provide us with more details

----- Original Message -----
> From: "Christina Lau" <christinalau28 at icloud.com>
> To: keycloak-user at lists.jboss.org
> Sent: Wednesday, 3 December, 2014 12:44:22 PM
> Subject: Re: [keycloak-user] How to disable https for Keycloak on Openshift?
> 
> No, I cannot login the admin console via http after I change require ssl to
> none on Openshift keycloak cartridge.
> 
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
> 

From christinalau28 at icloud.com  Wed Dec  3 06:57:00 2014
From: christinalau28 at icloud.com (Christina Lau)
Date: Wed, 03 Dec 2014 06:57:00 -0500
Subject: [keycloak-user] How to disable https for Keycloak on Openshift?
In-Reply-To: <898467382.9532042.1417607583105.JavaMail.zimbra@redhat.com>
References: <C52DE12B-AFB0-4A85-9B02-91498A9C5AD6@icloud.com>
	<898467382.9532042.1417607583105.JavaMail.zimbra@redhat.com>
Message-ID: <BD77EBDC-1458-4515-9888-11CCCAACE4D0@icloud.com>

What detail do you need, here are my steps to deploy KC on our Enterprise Openshift product. My company is Dell Software btw so your Openshift teams will be familiar with our Openshift configuration.

rhc app create mytestapp http://cartreflect-claytondev.rhcloud.com/github/keycloak/openshift-keycloak-cartridge mysql-5.5 -s -g medium

After the mytestapp is created, it is https.

I login as admin and change the require ssl to none, restart the server

Still it is https.




> On Dec 3, 2014, at 6:53 AM, Stian Thorgersen <stian at redhat.com> wrote:
> 
> You really need to provide us with more details
> 
> ----- Original Message -----
>> From: "Christina Lau" <christinalau28 at icloud.com>
>> To: keycloak-user at lists.jboss.org
>> Sent: Wednesday, 3 December, 2014 12:44:22 PM
>> Subject: Re: [keycloak-user] How to disable https for Keycloak on Openshift?
>> 
>> No, I cannot login the admin console via http after I change require ssl to
>> none on Openshift keycloak cartridge.
>> 
>> 
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141203/7725ad4c/attachment.html 

From stian at redhat.com  Wed Dec  3 10:03:30 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 3 Dec 2014 10:03:30 -0500 (EST)
Subject: [keycloak-user] How to disable https for Keycloak on Openshift?
In-Reply-To: <BD77EBDC-1458-4515-9888-11CCCAACE4D0@icloud.com>
References: <C52DE12B-AFB0-4A85-9B02-91498A9C5AD6@icloud.com>
	<898467382.9532042.1417607583105.JavaMail.zimbra@redhat.com>
	<BD77EBDC-1458-4515-9888-11CCCAACE4D0@icloud.com>
Message-ID: <294850.9701772.1417619010362.JavaMail.zimbra@redhat.com>

Assuming that your problem is you open:

  http://my-app.rhcloud.com/auth

But end up at:

  https://my-app.rhcloud.com/auth

This is caused by the Keycloak cartridge being configured to redirect to https. You can disable this by editing auth-server.war/WEB-INF/web.xml and removing the security-constraint element.

----- Original Message -----
> From: "Christina Lau" <christinalau28 at icloud.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-user at lists.jboss.org
> Sent: Wednesday, 3 December, 2014 12:57:00 PM
> Subject: Re: [keycloak-user] How to disable https for Keycloak on Openshift?
> 
> What detail do you need, here are my steps to deploy KC on our Enterprise
> Openshift product. My company is Dell Software btw so your Openshift teams
> will be familiar with our Openshift configuration.
> 
> rhc app create mytestapp
> http://cartreflect-claytondev.rhcloud.com/github/keycloak/openshift-keycloak-cartridge
> mysql-5.5 -s -g medium
> 
> After the mytestapp is created, it is https.
> 
> I login as admin and change the require ssl to none, restart the server
> 
> Still it is https.
> 
> 
> 
> 
> > On Dec 3, 2014, at 6:53 AM, Stian Thorgersen <stian at redhat.com> wrote:
> > 
> > You really need to provide us with more details
> > 
> > ----- Original Message -----
> >> From: "Christina Lau" <christinalau28 at icloud.com>
> >> To: keycloak-user at lists.jboss.org
> >> Sent: Wednesday, 3 December, 2014 12:44:22 PM
> >> Subject: Re: [keycloak-user] How to disable https for Keycloak on
> >> Openshift?
> >> 
> >> No, I cannot login the admin console via http after I change require ssl
> >> to
> >> none on Openshift keycloak cartridge.
> >> 
> >> 
> >> _______________________________________________
> >> keycloak-user mailing list
> >> keycloak-user at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-user
> >> 
> 
> 

From chaluwa at gmail.com  Wed Dec  3 11:19:13 2014
From: chaluwa at gmail.com (Odili Charles Opute)
Date: Wed, 3 Dec 2014 17:19:13 +0100
Subject: [keycloak-user] Unknown Authentication Method Error
Message-ID: <CANOsvDM+bnjiacaOVRhmVPUEA8TFRZYGz798z7_hH0qC1r-JEA@mail.gmail.com>

Hello guys, I am trying to secure an Errai app with Keycloak. I have added
the application and user roles to the keycloak server (running as an
appliance but with a different port), and also
added <auth-method>KEYCLOAK</auth-method> under <login-config> in the
web.xml file of the app. However, when I try to test the app (with mvn
gwt:run), I get a RuntimeException "caused by Unknown authentication
mechanism KEYCLOAK". Any hints as to why this is ?

-- 
Kind Regards
Odili Charles Opute
*Twitter : @chaluwa*
*Author : **http://goo.gl/v54jy <http://goo.gl/v54jy>*
*Manager : Google Developer Group, Benin.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141203/19a8040b/attachment.html 

From pmadden at tomsawyer.com  Wed Dec  3 11:35:16 2014
From: pmadden at tomsawyer.com (Patrick V. Madden)
Date: Wed, 3 Dec 2014 08:35:16 -0800 (PST)
Subject: [keycloak-user] failed to turn code into token error
Message-ID: <1362395433.1051003.1417624516367.JavaMail.zimbra@tomsawyer.com>

Hi, 

We have a standalone keycloak 1.0.4.Final appliance installation that supports SSL. I understand that it uses Wildfly 8.1.0.Final as its core. 

We have a Wildfly 8.0.0.Final Domain for testing with a number of cluster nodes all running the same 8.0 Wildfly version with the keycloak 1.0.4.Final adapter installed. The domain is fronted by Apache HTTP that supports SSL. 

We are trying to deploy some web applications to the domain to authenticate against keycloak. Things look good at first. Our apps redirect to our Active Directory Realm but upon redirect we get 403 - Forbidden errors. Stack trace is below. 

My question is could the problem be that we have two different versions of undertow core and servlet jars between domain nodes and standalone keycloak? Should we upgrade out testing domain to use 8.1.0.Final? Any thoughts are greatly appreciated! Also what about Wildfly 8.2.0.Final. If I'm going to upgrade my domain I would like to possibly use that. I could rebuild 1.0.4.Final using 8.2.0 artifacts? 

Any help is greatly appreciated. 
Thanks Patrick 

This is the error we see on our domain controller node: 

2014-12-03 07:48:08,718 ERROR [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-13) failed to turn code into token: org.apache.http.conn.HttpHostConnectExceptionentity.testing.tomsawyer.com refused 
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:190) [httpclient-4.2.1.jar:4.2.1] 
at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:151) [httpclient-4.2.1.jar:4.2.1] 
at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:125) [httpclient-4.2.1.jar:4.2.1] 
at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:640) [httpclient-4.2.1.jar:4.2.1] 
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:479) [httpclient-4.2.1.jar:4.2.1] 
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906) [httpclient-4.2.1.jar:4.2.1] 
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805) [httpclient-4.2.1.jar:4.2.1] 
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784) [httpclient-4.2.1.jar:4.2.1] 
at org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:116) [keycloak-adapter-core-1.0.4.Final.jar:] 
at org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:93) [keycloak-adapter-core-1.0.4.Final.jar:] 
at org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuthenticator.java:256) [keycloak-adapter-core-1.0.4.Final.jar:] 
at org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:205) [keycloak-adapter-core-1.0.4.Final.jar:] 
at org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:68) [keycloak-adapter-core-1.0.4.Final.jar:] 
at org.keycloak.adapters.undertow.UndertowKeycloakAuthMech.keycloakAuthenticate(UndertowKeycloakAuthMech.java:82) [keycloak-undertow-adapter-1.0.4.Final.jar:] 
at org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:61) [keycloak-undertow-adapter-1.0.4.Final.jar:] 
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.0.Final.jar:1.0.0.Final] 
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.0.Final.jar:1.0.0.Final] 
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.0.Final.jar:1.0.0.Final] 
at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.0.Final.jar:1.0.0.Final] 
at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.0.Final.jar:1.0.0.Final] 
at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.0.Final.jar:1.0.0.Final] 
at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50) [undertow-core-1.0.0.Final.jar:1.0.0.Final] 
at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Final.jar:1.0.0.Final] 
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Final.jar:1.0.0.Final] 
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.0 
at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.0.Final.jar:1.0 
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Final.jar:1.0.0.Final] 
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.0.Final.jar:1 
at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.0.Final.jar:1.0.0.Final] 
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Final.jar:1.0.0.Final] 
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) 
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Final.jar:1.0.0.Final] 
at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69) [keycloak-undertow-adapter-1.0.4.Final.jar:] 
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Final.jar:1.0.0.Final] 
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] 
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] 
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] 
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final] 
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168) [undertow-core-1.0.0.Final.jar:1.0.0.Final] 
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687) [undertow-core-1.0.0.Final.jar:1.0.0.Final] 
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] 
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] 
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] 
Caused by: java.net.ConnectException: Connection timed out: connect 
at java.net.TwoStacksPlainSocketImpl.socketConnect(Native Method) [rt.jar:1.7.0_51] 
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) [rt.jar:1.7.0_51] 
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) [rt.jar:1.7.0_51] 
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) [rt.jar:1.7.0_51] 
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172) [rt.jar:1.7.0_51] 
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) [rt.jar:1.7.0_51] 
at java.net.Socket.connect(Socket.java:579) [rt.jar:1.7.0_51] 
at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:618) [jsse.jar:1.7.0_51] 
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:549) [httpclient-4.2.1.jar:4.2.1] 
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180) [httpclient-4.2.1.jar:4.2.1] 
... 42 more 


Patrick Madden 
Principal Design Engineer 
Tom Sawyer Software 
1997 El Dorado Avenue 
Berkeley, CA 94707 

Cell: +1 (845) 416-4629 
E-mail: pmadden@ tomsawyer.com 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141203/7fcc4546/attachment-0001.html 

From bburke at redhat.com  Wed Dec  3 14:01:25 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 03 Dec 2014 14:01:25 -0500
Subject: [keycloak-user] Unknown Authentication Method Error
In-Reply-To: <CANOsvDM+bnjiacaOVRhmVPUEA8TFRZYGz798z7_hH0qC1r-JEA@mail.gmail.com>
References: <CANOsvDM+bnjiacaOVRhmVPUEA8TFRZYGz798z7_hH0qC1r-JEA@mail.gmail.com>
Message-ID: <547F5E05.8050005@redhat.com>

Did you edit standalone.xml to add the keycloak subsystem according to 
the docs?

On 12/3/2014 11:19 AM, Odili Charles Opute wrote:
> Hello guys, I am trying to secure an Errai app with Keycloak. I have
> added the application and user roles to the keycloak server (running as
> an appliance but with a different port), and also
> added <auth-method>KEYCLOAK</auth-method> under <login-config> in the
> web.xml file of the app. However, when I try to test the app (with mvn
> gwt:run), I get a RuntimeException "caused by Unknown authentication
> mechanism KEYCLOAK". Any hints as to why this is ?
>
> --
> Kind Regards
> Odili Charles Opute
> *Twitter : @chaluwa*
> *Author :**http://goo.gl/v54jy**
> *
> *Manager : Google Developer Group, Benin.*
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

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

From christinalau28 at icloud.com  Wed Dec  3 15:27:35 2014
From: christinalau28 at icloud.com (Christina Lau)
Date: Wed, 03 Dec 2014 15:27:35 -0500
Subject: [keycloak-user] Failed executing GET
 /realms/master/login-status-iframe.html:
 org.jboss.resteasy.spi.BadRequestException: Invalid origin
Message-ID: <411AF554-771B-499F-BA60-3D6C5995F143@icloud.com>

I now get a new error running this command to create a new app.

rhc app create testapp http://cartreflect-claytondev.rhcloud.com/github/keycloak/openshift-keycloak-cartridge mysql-5.5 -s -g medium

When I login as admin, I see this in the log, and I cannot even change the ssl setting. Any idea? I haven?t done anything yet other than to create a new app to try to change the web.xml. 


2014-12-03 15:12:53,380 WARN  [org.jboss.resteasy.core.ExceptionHandler] (default task-2) Failed executing GET /realms/master/login-status-iframe.html: org.jboss.resteasy.spi.BadRequestException: Invalid origin
	at org.keycloak.services.resources.RealmsResource.getLoginStatusIframe(RealmsResource.java:99) [keycloak-services-1.0.3.Final.jar:]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_05]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_05]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_05]
	at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0_05]
	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.8.Final.jar:]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296) [resteasy-jaxrs-3.0.8.Final.jar:]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250) [resteasy-jaxrs-3.0.8.Final.jar:]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:237) [resteasy-jaxrs-3.0.8.Final.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.8.Final.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.8.Final.jar:]
	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.8.Final.jar:]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.8.Final.jar:]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.8.Final.jar:]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at org.keycloak.services.filters.ClientConnectionFilter.doFilter(ClientConnectionFilter.java:41) [keycloak-services-1.0.3.Final.jar:]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:40) [keycloak-services-1.0.3.Final.jar:]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_05]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_05]
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_05]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141203/311ba43d/attachment.html 

From stian at redhat.com  Thu Dec  4 02:52:54 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Thu, 4 Dec 2014 02:52:54 -0500 (EST)
Subject: [keycloak-user] failed to turn code into token error
In-Reply-To: <1362395433.1051003.1417624516367.JavaMail.zimbra@tomsawyer.com>
References: <1362395433.1051003.1417624516367.JavaMail.zimbra@tomsawyer.com>
Message-ID: <2096021387.10175281.1417679574090.JavaMail.zimbra@redhat.com>

Hi,

We use the latest version of WildFly for our distribution and will soon upgrade to 8.2.0.Final. I believe Keycloak should run fine on it. That being said there's no reason your applications can't run on 8.0.0.Final with Keycloak itself on 8.1.0.Final.

>From the stacktrace below it looks like there's a timeout from the adapter trying to contact the server, so looks more like a networking issue to me.

----- Original Message -----
> From: "Patrick V. Madden" <pmadden at tomsawyer.com>
> To: keycloak-user at lists.jboss.org
> Sent: Wednesday, 3 December, 2014 5:35:16 PM
> Subject: [keycloak-user] failed to turn code into token error
> 
> Hi,
> 
> We have a standalone keycloak 1.0.4.Final appliance installation that
> supports SSL. I understand that it uses Wildfly 8.1.0.Final as its core.
> 
> We have a Wildfly 8.0.0.Final Domain for testing with a number of cluster
> nodes all running the same 8.0 Wildfly version with the keycloak 1.0.4.Final
> adapter installed. The domain is fronted by Apache HTTP that supports SSL.
> 
> We are trying to deploy some web applications to the domain to authenticate
> against keycloak. Things look good at first. Our apps redirect to our Active
> Directory Realm but upon redirect we get 403 - Forbidden errors. Stack trace
> is below.
> 
> My question is could the problem be that we have two different versions of
> undertow core and servlet jars between domain nodes and standalone keycloak?
> Should we upgrade out testing domain to use 8.1.0.Final? Any thoughts are
> greatly appreciated! Also what about Wildfly 8.2.0.Final. If I'm going to
> upgrade my domain I would like to possibly use that. I could rebuild
> 1.0.4.Final using 8.2.0 artifacts?
> 
> Any help is greatly appreciated.
> Thanks Patrick
> 
> This is the error we see on our domain controller node:
> 
> 2014-12-03 07:48:08,718 ERROR
> [org.keycloak.adapters.OAuthRequestAuthenticator] (default task-13) failed
> to turn code into token:
> org.apache.http.conn.HttpHostConnectExceptionentity.testing.tomsawyer.com
> refused
> at
> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:190)
> [httpclient-4.2.1.jar:4.2.1]
> at
> org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:151)
> [httpclient-4.2.1.jar:4.2.1]
> at
> org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:125)
> [httpclient-4.2.1.jar:4.2.1]
> at
> org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:640)
> [httpclient-4.2.1.jar:4.2.1]
> at
> org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:479)
> [httpclient-4.2.1.jar:4.2.1]
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
> [httpclient-4.2.1.jar:4.2.1]
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
> [httpclient-4.2.1.jar:4.2.1]
> at
> org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784)
> [httpclient-4.2.1.jar:4.2.1]
> at
> org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:116)
> [keycloak-adapter-core-1.0.4.Final.jar:]
> at
> org.keycloak.adapters.ServerRequest.invokeAccessCodeToToken(ServerRequest.java:93)
> [keycloak-adapter-core-1.0.4.Final.jar:]
> at
> org.keycloak.adapters.OAuthRequestAuthenticator.resolveCode(OAuthRequestAuthenticator.java:256)
> [keycloak-adapter-core-1.0.4.Final.jar:]
> at
> org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:205)
> [keycloak-adapter-core-1.0.4.Final.jar:]
> at
> org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:68)
> [keycloak-adapter-core-1.0.4.Final.jar:]
> at
> org.keycloak.adapters.undertow.UndertowKeycloakAuthMech.keycloakAuthenticate(UndertowKeycloakAuthMech.java:82)
> [keycloak-undertow-adapter-1.0.4.Final.jar:]
> at
> org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:61)
> [keycloak-undertow-adapter-1.0.4.Final.jar:]
> at
> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281)
> [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at
> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298)
> [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at
> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268)
> [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at
> io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131)
> [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at
> io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106)
> [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at
> io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99)
> [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at
> io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50)
> [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at
> io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
> [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at
> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
> [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at
> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
> [undertow-servlet-1.0.0
> at
> io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
> [undertow-servlet-1.0.0.Final.jar:1.0
> at
> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at
> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
> [undertow-servlet-1.0.0.Final.jar:1
> at
> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at
> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at
> org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69)
> [keycloak-undertow-adapter-1.0.4.Final.jar:]
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25)
> [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at
> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240)
> [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
> [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at
> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
> [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at
> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
> [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168)
> [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687)
> [undertow-core-1.0.0.Final.jar:1.0.0.Final]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [rt.jar:1.7.0_51]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.net.ConnectException: Connection timed out: connect
> at java.net.TwoStacksPlainSocketImpl.socketConnect(Native Method)
> [rt.jar:1.7.0_51]
> at
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
> [rt.jar:1.7.0_51]
> at
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
> [rt.jar:1.7.0_51]
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
> [rt.jar:1.7.0_51]
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
> [rt.jar:1.7.0_51]
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> [rt.jar:1.7.0_51]
> at java.net.Socket.connect(Socket.java:579) [rt.jar:1.7.0_51]
> at sun.security.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:618)
> [jsse.jar:1.7.0_51]
> at
> org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:549)
> [httpclient-4.2.1.jar:4.2.1]
> at
> org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
> [httpclient-4.2.1.jar:4.2.1]
> ... 42 more
> 
> 
> Patrick Madden
> Principal Design Engineer
> Tom Sawyer Software
> 1997 El Dorado Avenue
> Berkeley, CA 94707
> 
> Cell: +1 (845) 416-4629
> E-mail: pmadden@ tomsawyer.com
> 
> 
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

From eric.wittmann at redhat.com  Thu Dec  4 11:10:47 2014
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Thu, 04 Dec 2014 11:10:47 -0500
Subject: [keycloak-user] Obtaining the user name from the security
	context
In-Reply-To: <54738562.2050409@redhat.com>
References: <1869846893.11462243.1416414017373.JavaMail.zimbra@redhat.com>	<546CD999.9000808@redhat.com>	<1510952577.11835794.1416479122326.JavaMail.zimbra@redhat.com>	<546FB533.3020601@redhat.com>	<33553618.13189506.1416828179585.JavaMail.zimbra@redhat.com>
	<54738562.2050409@redhat.com>
Message-ID: <54808787.1070101@redhat.com>

Any update on the beta2 release?  I've got keycloak really nicely 
included in apiman, just waiting on beta2 before I push the code.  :)

-Eric

On 11/24/2014 2:22 PM, Marek Posolda wrote:
> Not sure, probably this or next week.
>
> Marek
>
> On 24.11.2014 12:22, Gary Brown wrote:
>> Thanks that works fine now.
>>
>> Any idea when beta2 will be released?
>>
>> Regards
>> Gary
>>
>> ----- Original Message -----
>>> Hi,
>>>
>>> I've just tried it and figured that it doesn't work due to bug
>>> https://issues.jboss.org/browse/KEYCLOAK-857 . It's fixed in latest
>>> keycloak master and will be available in next release 1.1.0.Beta2 . The
>>> easiest workaround is to configure absolute URI for auth-server-url . So
>>> instead of "/auth", you can use "http://localhost:8080/auth" or
>>> something like that according to your env.
>>>
>>> Hope it helps,
>>> Marek
>>>
>>> On 20.11.2014 11:25, Gary Brown wrote:
>>>> Hi
>>>>
>>>> Thanks for the information.
>>>>
>>>> However, I've tried it without success - I also tried using this attribute
>>>> in the keycloak unconfigured-demo and preconfigured-demo examples for
>>>> customer-app/product-app, and didn't have an effect on them either.
>>>>
>>>> Just wondering whether the text in the doc "OpenID Connection ID Token
>>>> attribute to populate the UserPrincipal name with" implies that this
>>>> attribute only works for OpenID?
>>>>
>>>> With the unconfigured version, it wasn't clear whether this attribute would
>>>> be set under the realm or secure-deployment elements, so initially I tried
>>>> just under the realm but then eventually defined the attribute under both.
>>>> Attached the wildfly standalone-full.xml.
>>>>
>>>> Regards
>>>> Gary
>>>>
>>>> ----- Original Message -----
>>>>> If you have 1.1.0.Beta1, you can try to use "principal-attribute" with
>>>>> value "|preferred_username" in the configuration of your adapter. More
>>>>> info in |http://docs.jboss.org/keycloak/docs/1.1.0.Beta1/userguide
>>>>> /html/ch07.html#adapter-config .
>>>>>
>>>>> It should also work to cast getUserPrincipal() to KeycloakPrincipal and
>>>>> use something like:
>>>>>
>>>>> ((KeycloakPrincipal)getUserPrincipal()).getKeycloakSecurityContext().getToken().getPreferredUsername()
>>>>>
>>>>> this should also work on older versions, but your code may need to have
>>>>> dependencies on keycloak.
>>>>>
>>>>> Marek
>>>>>
>>>>> On 19.11.2014 17:20, Gary Brown wrote:
>>>>>> Hi
>>>>>>
>>>>>> When I access getUserPrincipal().getName() in
>>>>>> javax.ws.rs.core.SecurityContext I get the UID.
>>>>>>
>>>>>> Is it possible to obtain the actual user name?
>>>>>>
>>>>>> Regards
>>>>>> Gary
>>>>>> _______________________________________________
>>>>>> keycloak-user mailing list
>>>>>> keycloak-user at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

From bburke at redhat.com  Thu Dec  4 12:03:09 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 04 Dec 2014 12:03:09 -0500
Subject: [keycloak-user] Obtaining the user name from the security
	context
In-Reply-To: <54808787.1070101@redhat.com>
References: <1869846893.11462243.1416414017373.JavaMail.zimbra@redhat.com>	<546CD999.9000808@redhat.com>	<1510952577.11835794.1416479122326.JavaMail.zimbra@redhat.com>	<546FB533.3020601@redhat.com>	<33553618.13189506.1416828179585.JavaMail.zimbra@redhat.com>	<54738562.2050409@redhat.com>
	<54808787.1070101@redhat.com>
Message-ID: <548093CD.10109@redhat.com>

Waiting on the AS7 adapter to be fixed.  I can just push one out today I 
guess.

On 12/4/2014 11:10 AM, Eric Wittmann wrote:
> Any update on the beta2 release?  I've got keycloak really nicely
> included in apiman, just waiting on beta2 before I push the code.  :)
>
> -Eric
>
> On 11/24/2014 2:22 PM, Marek Posolda wrote:
>> Not sure, probably this or next week.
>>
>> Marek
>>
>> On 24.11.2014 12:22, Gary Brown wrote:
>>> Thanks that works fine now.
>>>
>>> Any idea when beta2 will be released?
>>>
>>> Regards
>>> Gary
>>>
>>> ----- Original Message -----
>>>> Hi,
>>>>
>>>> I've just tried it and figured that it doesn't work due to bug
>>>> https://issues.jboss.org/browse/KEYCLOAK-857 . It's fixed in latest
>>>> keycloak master and will be available in next release 1.1.0.Beta2 . The
>>>> easiest workaround is to configure absolute URI for auth-server-url . So
>>>> instead of "/auth", you can use "http://localhost:8080/auth" or
>>>> something like that according to your env.
>>>>
>>>> Hope it helps,
>>>> Marek
>>>>
>>>> On 20.11.2014 11:25, Gary Brown wrote:
>>>>> Hi
>>>>>
>>>>> Thanks for the information.
>>>>>
>>>>> However, I've tried it without success - I also tried using this attribute
>>>>> in the keycloak unconfigured-demo and preconfigured-demo examples for
>>>>> customer-app/product-app, and didn't have an effect on them either.
>>>>>
>>>>> Just wondering whether the text in the doc "OpenID Connection ID Token
>>>>> attribute to populate the UserPrincipal name with" implies that this
>>>>> attribute only works for OpenID?
>>>>>
>>>>> With the unconfigured version, it wasn't clear whether this attribute would
>>>>> be set under the realm or secure-deployment elements, so initially I tried
>>>>> just under the realm but then eventually defined the attribute under both.
>>>>> Attached the wildfly standalone-full.xml.
>>>>>
>>>>> Regards
>>>>> Gary
>>>>>
>>>>> ----- Original Message -----
>>>>>> If you have 1.1.0.Beta1, you can try to use "principal-attribute" with
>>>>>> value "|preferred_username" in the configuration of your adapter. More
>>>>>> info in |http://docs.jboss.org/keycloak/docs/1.1.0.Beta1/userguide
>>>>>> /html/ch07.html#adapter-config .
>>>>>>
>>>>>> It should also work to cast getUserPrincipal() to KeycloakPrincipal and
>>>>>> use something like:
>>>>>>
>>>>>> ((KeycloakPrincipal)getUserPrincipal()).getKeycloakSecurityContext().getToken().getPreferredUsername()
>>>>>>
>>>>>> this should also work on older versions, but your code may need to have
>>>>>> dependencies on keycloak.
>>>>>>
>>>>>> Marek
>>>>>>
>>>>>> On 19.11.2014 17:20, Gary Brown wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> When I access getUserPrincipal().getName() in
>>>>>>> javax.ws.rs.core.SecurityContext I get the UID.
>>>>>>>
>>>>>>> Is it possible to obtain the actual user name?
>>>>>>>
>>>>>>> Regards
>>>>>>> Gary
>>>>>>> _______________________________________________
>>>>>>> keycloak-user mailing list
>>>>>>> keycloak-user at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

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

From ssilvert at redhat.com  Thu Dec  4 13:20:49 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 04 Dec 2014 13:20:49 -0500
Subject: [keycloak-user] Obtaining the user name from the security
	context
In-Reply-To: <548093CD.10109@redhat.com>
References: <1869846893.11462243.1416414017373.JavaMail.zimbra@redhat.com>	<546CD999.9000808@redhat.com>	<1510952577.11835794.1416479122326.JavaMail.zimbra@redhat.com>	<546FB533.3020601@redhat.com>	<33553618.13189506.1416828179585.JavaMail.zimbra@redhat.com>	<54738562.2050409@redhat.com>
	<54808787.1070101@redhat.com> <548093CD.10109@redhat.com>
Message-ID: <5480A601.4040409@redhat.com>

On 12/4/2014 12:03 PM, Bill Burke wrote:
> Waiting on the AS7 adapter to be fixed.  I can just push one out today I
> guess.
I should be done in a couple of hours as long as I don't run into any 
new issues.
>
> On 12/4/2014 11:10 AM, Eric Wittmann wrote:
>> Any update on the beta2 release?  I've got keycloak really nicely
>> included in apiman, just waiting on beta2 before I push the code.  :)
>>
>> -Eric
>>
>> On 11/24/2014 2:22 PM, Marek Posolda wrote:
>>> Not sure, probably this or next week.
>>>
>>> Marek
>>>
>>> On 24.11.2014 12:22, Gary Brown wrote:
>>>> Thanks that works fine now.
>>>>
>>>> Any idea when beta2 will be released?
>>>>
>>>> Regards
>>>> Gary
>>>>
>>>> ----- Original Message -----
>>>>> Hi,
>>>>>
>>>>> I've just tried it and figured that it doesn't work due to bug
>>>>> https://issues.jboss.org/browse/KEYCLOAK-857 . It's fixed in latest
>>>>> keycloak master and will be available in next release 1.1.0.Beta2 . The
>>>>> easiest workaround is to configure absolute URI for auth-server-url . So
>>>>> instead of "/auth", you can use "http://localhost:8080/auth" or
>>>>> something like that according to your env.
>>>>>
>>>>> Hope it helps,
>>>>> Marek
>>>>>
>>>>> On 20.11.2014 11:25, Gary Brown wrote:
>>>>>> Hi
>>>>>>
>>>>>> Thanks for the information.
>>>>>>
>>>>>> However, I've tried it without success - I also tried using this attribute
>>>>>> in the keycloak unconfigured-demo and preconfigured-demo examples for
>>>>>> customer-app/product-app, and didn't have an effect on them either.
>>>>>>
>>>>>> Just wondering whether the text in the doc "OpenID Connection ID Token
>>>>>> attribute to populate the UserPrincipal name with" implies that this
>>>>>> attribute only works for OpenID?
>>>>>>
>>>>>> With the unconfigured version, it wasn't clear whether this attribute would
>>>>>> be set under the realm or secure-deployment elements, so initially I tried
>>>>>> just under the realm but then eventually defined the attribute under both.
>>>>>> Attached the wildfly standalone-full.xml.
>>>>>>
>>>>>> Regards
>>>>>> Gary
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> If you have 1.1.0.Beta1, you can try to use "principal-attribute" with
>>>>>>> value "|preferred_username" in the configuration of your adapter. More
>>>>>>> info in |http://docs.jboss.org/keycloak/docs/1.1.0.Beta1/userguide
>>>>>>> /html/ch07.html#adapter-config .
>>>>>>>
>>>>>>> It should also work to cast getUserPrincipal() to KeycloakPrincipal and
>>>>>>> use something like:
>>>>>>>
>>>>>>> ((KeycloakPrincipal)getUserPrincipal()).getKeycloakSecurityContext().getToken().getPreferredUsername()
>>>>>>>
>>>>>>> this should also work on older versions, but your code may need to have
>>>>>>> dependencies on keycloak.
>>>>>>>
>>>>>>> Marek
>>>>>>>
>>>>>>> On 19.11.2014 17:20, Gary Brown wrote:
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> When I access getUserPrincipal().getName() in
>>>>>>>> javax.ws.rs.core.SecurityContext I get the UID.
>>>>>>>>
>>>>>>>> Is it possible to obtain the actual user name?
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Gary
>>>>>>>> _______________________________________________
>>>>>>>> keycloak-user mailing list
>>>>>>>> keycloak-user at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>


From christinalau28 at icloud.com  Thu Dec  4 16:03:55 2014
From: christinalau28 at icloud.com (Christina Lau)
Date: Thu, 04 Dec 2014 16:03:55 -0500
Subject: [keycloak-user] Failed executing GET
 /realms/master/login-status-iframe.html:
 org.jboss.resteasy.spi.BadRequestException: Invalid origin
Message-ID: <61367B20-4B83-4D61-8815-5B66B57849EF@icloud.com>

We were able to backup to keycloak 1.0.1 cartridge and this problem did not exist. We also tried the 1.0.3 on openshift online and have the exact problem.

To reproduce, login to admin, then click on the pages, in FF you will see errors such as:
Network error: 400 bad request - https://?.. /realms/master/login-status-iframe.html??.

We cannot make changes and save them as a result.

Christina



From peterson.dean at gmail.com  Thu Dec  4 23:48:32 2014
From: peterson.dean at gmail.com (Dean Peterson)
Date: Thu, 4 Dec 2014 22:48:32 -0600
Subject: [keycloak-user] org.keycloak.util.JsonSerialization does not seem
	to support @JsonTypeInfo
Message-ID: <CAFGzvP=dCyNvizX6dRv6Oj=PNxJj_Va5Drm2yhzAvDVnUnTF8Q@mail.gmail.com>

I receive the following error only when using
org.keycloak.util.JsonSerialization to deserialize:
Unrecognized field "class" (Class com.abecorn.model.Item), not marked as
ignorable

Here is the setup:

@JsonTypeInfo(use = JsonTypeInfo.Id.CLASS, include = As.PROPERTY, property
= "class")
@JsonIgnoreProperties(ignoreUnknown = true)
@Entity
@Indexed
public class Item {
.
.
.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141204/a447942b/attachment.html 

From stian at redhat.com  Fri Dec  5 03:27:22 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Fri, 5 Dec 2014 03:27:22 -0500 (EST)
Subject: [keycloak-user] org.keycloak.util.JsonSerialization does not
 seem	to support @JsonTypeInfo
In-Reply-To: <CAFGzvP=dCyNvizX6dRv6Oj=PNxJj_Va5Drm2yhzAvDVnUnTF8Q@mail.gmail.com>
References: <CAFGzvP=dCyNvizX6dRv6Oj=PNxJj_Va5Drm2yhzAvDVnUnTF8Q@mail.gmail.com>
Message-ID: <2023560185.11174086.1417768042990.JavaMail.zimbra@redhat.com>

I wouldn't recommend using org.keycloak.util.JsonSerialization for your own application. It's an internal utility class and can be changed/removed at any point.

----- Original Message -----
> From: "Dean Peterson" <peterson.dean at gmail.com>
> To: keycloak-user at lists.jboss.org
> Sent: Friday, 5 December, 2014 5:48:32 AM
> Subject: [keycloak-user] org.keycloak.util.JsonSerialization does not seem	to support @JsonTypeInfo
> 
> I receive the following error only when using
> org.keycloak.util.JsonSerialization to deserialize:
> Unrecognized field "class" (Class com.abecorn.model.Item), not marked as
> ignorable
> 
> Here is the setup:
> 
> @JsonTypeInfo(use = JsonTypeInfo.Id.CLASS, include = As.PROPERTY, property =
> "class")
> @JsonIgnoreProperties(ignoreUnknown = true)
> @Entity
> @Indexed
> public class Item {
> .
> .
> .
> 
> 
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

From bburke at redhat.com  Fri Dec  5 21:08:53 2014
From: bburke at redhat.com (Bill Burke)
Date: Fri, 05 Dec 2014 21:08:53 -0500
Subject: [keycloak-user] Keycloak 1.1.0.Beta2 released
Message-ID: <54826535.3000802@redhat.com>

A lot of new features this release.

     Tomcat 6, 7, and 8 adapters
     Jetty 8.1, 9.1, and 9.2 adapters
     HTTP Security Proxy for platforms that don?t have an adapter based 
on Undertow.
     Wildfly subsystem for auth server.  Allows you to run keycloak in 
domain mode to make it easier to run in a cluster.

Hope to do 1.1.0.Final sometime end of January.  See http://keycloak.org 
for more details

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

From lanabe.lanabe at gmail.com  Fri Dec  5 22:59:27 2014
From: lanabe.lanabe at gmail.com (lanabe)
Date: Sat, 6 Dec 2014 12:59:27 +0900
Subject: [keycloak-user] Keycloak 1.1.0.Beta2 released
In-Reply-To: <54826535.3000802@redhat.com>
References: <54826535.3000802@redhat.com>
Message-ID: <CAKhWDPR1hpWrM7rmqeBVNrMgrRLcGnVokiSt5VHwGGachoE4Xw@mail.gmail.com>

Congratulations!

Recently I started to apply Kyecloak to my personally simple blog
application(using WildFly 8.2.0.FInal, JSF, JAX-RS,...).
Keycloak is very easy to use!

BTW,  the download page(http://keycloak.jboss.org/downloads) remains
1.1.0.Beta1.
# I got the new binary at
http://sourceforge.net/projects/keycloak/files/1.1.0.Beta2 .

Thanks.

Yoshimasa Tanabe

On Sat, Dec 6, 2014 at 11:08 AM, Bill Burke <bburke at redhat.com> wrote:

> A lot of new features this release.
>
>      Tomcat 6, 7, and 8 adapters
>      Jetty 8.1, 9.1, and 9.2 adapters
>      HTTP Security Proxy for platforms that don?t have an adapter based
> on Undertow.
>      Wildfly subsystem for auth server.  Allows you to run keycloak in
> domain mode to make it easier to run in a cluster.
>
> Hope to do 1.1.0.Final sometime end of January.  See http://keycloak.org
> for more details
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141206/b23fa715/attachment-0001.html 

From bburke at redhat.com  Sat Dec  6 09:20:02 2014
From: bburke at redhat.com (Bill Burke)
Date: Sat, 06 Dec 2014 09:20:02 -0500
Subject: [keycloak-user] Keycloak 1.1.0.Beta2 released
In-Reply-To: <CAKhWDPR1hpWrM7rmqeBVNrMgrRLcGnVokiSt5VHwGGachoE4Xw@mail.gmail.com>
References: <54826535.3000802@redhat.com>
	<CAKhWDPR1hpWrM7rmqeBVNrMgrRLcGnVokiSt5VHwGGachoE4Xw@mail.gmail.com>
Message-ID: <54831092.50609@redhat.com>

Fixed download page to point back to sf.net

On 12/5/2014 10:59 PM, lanabe wrote:
> Congratulations!
>
> Recently I started to apply Kyecloak to my personally simple blog
> application(using WildFly 8.2.0.FInal, JSF, JAX-RS,...).
> Keycloak is very easy to use!
>
> BTW,  the download page(http://keycloak.jboss.org/downloads) remains
> 1.1.0.Beta1.
> # I got the new binary at
> http://sourceforge.net/projects/keycloak/files/1.1.0.Beta2 .
>
> Thanks.
>
> Yoshimasa Tanabe
>
> On Sat, Dec 6, 2014 at 11:08 AM, Bill Burke <bburke at redhat.com
> <mailto:bburke at redhat.com>> wrote:
>
>     A lot of new features this release.
>
>           Tomcat 6, 7, and 8 adapters
>           Jetty 8.1, 9.1, and 9.2 adapters
>           HTTP Security Proxy for platforms that don?t have an adapter based
>     on Undertow.
>           Wildfly subsystem for auth server.  Allows you to run keycloak in
>     domain mode to make it easier to run in a cluster.
>
>     Hope to do 1.1.0.Final sometime end of January.  See http://keycloak.org
>     for more details
>
>     --
>     Bill Burke
>     JBoss, a division of Red Hat
>     http://bill.burkecentral.com
>     _______________________________________________
>     keycloak-user mailing list
>     keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>

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

From prabhalar at yahoo.com  Sat Dec  6 14:43:51 2014
From: prabhalar at yahoo.com (prab rrrr)
Date: Sat, 6 Dec 2014 19:43:51 +0000 (UTC)
Subject: [keycloak-user] SPNEGO and OpenID connect end points
In-Reply-To: <2141017149.3725307.1417893893203.JavaMail.yahoo@jws100137.mail.ne1.yahoo.com>
References: <2141017149.3725307.1417893893203.JavaMail.yahoo@jws100137.mail.ne1.yahoo.com>
Message-ID: <2021931506.3029168.1417895031149.JavaMail.yahoo@jws100101.mail.ne1.yahoo.com>


Hi Bill and team - Congratulations on the new functionality in 1.1 Beta2. Now that Keycloak has a good deal of functionality, would you be able provide timelines?for the below functionality:1) SPNEGO (Kerberos)?authentication functionality 2) Complete OpenID Connect endpoint compatibility and plans for dynamic discovery?Thanks,Raghu?

  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141206/c9706b4e/attachment.html 

From bburke at redhat.com  Sat Dec  6 18:59:15 2014
From: bburke at redhat.com (Bill Burke)
Date: Sat, 06 Dec 2014 18:59:15 -0500
Subject: [keycloak-user] SPNEGO and OpenID connect end points
In-Reply-To: <2021931506.3029168.1417895031149.JavaMail.yahoo@jws100101.mail.ne1.yahoo.com>
References: <2141017149.3725307.1417893893203.JavaMail.yahoo@jws100137.mail.ne1.yahoo.com>
	<2021931506.3029168.1417895031149.JavaMail.yahoo@jws100101.mail.ne1.yahoo.com>
Message-ID: <54839853.5070207@redhat.com>

WE're deciding on timelines next week at our face to face.

On 12/6/2014 2:43 PM, prab rrrr wrote:
>
> Hi Bill and team - Congratulations on the new functionality in 1.1
> Beta2. Now that Keycloak has a good deal of functionality, would you be
> able provide timelines for the below functionality:
> 1) SPNEGO (Kerberos) authentication functionality
> 2) Complete OpenID Connect endpoint compatibility and plans for dynamic
> discovery
> Thanks,
> Raghu
>
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

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

From jayblanc at gmail.com  Mon Dec  8 05:15:21 2014
From: jayblanc at gmail.com (=?UTF-8?B?SsOpcsO0bWUgQmxhbmNoYXJk?=)
Date: Mon, 08 Dec 2014 10:15:21 +0000
Subject: [keycloak-user] Migration to Keycloak
Message-ID: <CAPNq5vbvMdKtZ2XKK-G=aKOUKN6O04NaJm+=JARWfjtxF3Q7+w@mail.gmail.com>

Hi all,
I have a question about migrating my application to keycloak.
My application is based on :
- some EJB components
- a main REST interface driving the EJB components,
- a HTML5/Angular GUI client
- some remote REST api acting as clients of the main REST api.
According to the documentation, I plane to use the adapters according to my
components but I'm facing a problame for the main REST interface.

By default, the main REST interface handles requests using a dedicated
GUEST account. It's a kind of default account that is propagated to the EJB
container using a classic login mechanism. This is handle in a
ServletFilter that looks for HTTP Authentication headers. If headers are
not found, authentication on the container is done using the default login
'guest'.
For this special account, a dedicated login-module is used in the wildfly
security domain (<login-module code="Identity" flag="required">)

I'm trying to migrate to keycloak using the undertow adapter but I'm not
able to handle a default login propagated to the EJB layer.

The use case is that a simpe call to the REST api without authentication
token header should result as a container authenticated user guest whereas
requests with token included should try to perform the token base
authentication. In that way, unauthenticated usage of HTML5/JS interface
should result as guest requests and login process only required when main
REST api throws AccessDeniedException.

Is there is any way to perform this using the KEYCLOAK auth-method or do I
have to write a specific Filter handling a kind of dual auth mechanism
(guest and keycloak) ?

Best regards, J?r?me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141208/e415bbef/attachment.html 

From mposolda at redhat.com  Mon Dec  8 06:20:33 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 08 Dec 2014 12:20:33 +0100
Subject: [keycloak-user] Keycloak 1.1.0.Beta2 released
In-Reply-To: <54826535.3000802@redhat.com>
References: <54826535.3000802@redhat.com>
Message-ID: <54858981.7060407@redhat.com>

It seems there is missing version update in bower.json in 
keycloak-js-bower . Sent PR for this, but can't merge it. Also it would 
be needed to push 1.1.0.Beta2 tag to keycloak-js-bower repo.

Marek

On 6.12.2014 03:08, Bill Burke wrote:
> A lot of new features this release.
>
>       Tomcat 6, 7, and 8 adapters
>       Jetty 8.1, 9.1, and 9.2 adapters
>       HTTP Security Proxy for platforms that don?t have an adapter based
> on Undertow.
>       Wildfly subsystem for auth server.  Allows you to run keycloak in
> domain mode to make it easier to run in a cluster.
>
> Hope to do 1.1.0.Final sometime end of January.  See http://keycloak.org
> for more details
>


From mposolda at redhat.com  Mon Dec  8 08:04:28 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 08 Dec 2014 14:04:28 +0100
Subject: [keycloak-user] Migration to Keycloak
In-Reply-To: <CAPNq5vbvMdKtZ2XKK-G=aKOUKN6O04NaJm+=JARWfjtxF3Q7+w@mail.gmail.com>
References: <CAPNq5vbvMdKtZ2XKK-G=aKOUKN6O04NaJm+=JARWfjtxF3Q7+w@mail.gmail.com>
Message-ID: <5485A1DC.1010003@redhat.com>

Hi,

I afraid that we don't have support for the usecase like this yet afaik, 
as adapters are driven by servlet security and if you access protected 
URL without token, you will just receive 401. Maybe optional support for 
guest authentication in rest requests is something to consider to add 
into keycloak though...

One possible alternative we have is pure jaxrs filter, which you can 
possibly add to your REST application if you're using jaxrs: 
https://github.com/keycloak/keycloak/blob/master/integration/jaxrs-oauth-client/src/main/java/org/keycloak/jaxrs/JaxrsBearerTokenFilterImpl.java 
. Problem is that you will still have to override at least method 
"bearerAuthentication" to not send error in case of missing token, but 
use your guest account instead . Also I am really not sure if jaxrs 
SecurityContext will be propagated to EJB layer, probably not.

Marek


On 8.12.2014 11:15, J?r?me Blanchard wrote:
> Hi all,
> I have a question about migrating my application to keycloak.
> My application is based on :
> - some EJB components
> - a main REST interface driving the EJB components,
> - a HTML5/Angular GUI client
> - some remote REST api acting as clients of the main REST api.
> According to the documentation, I plane to use the adapters according 
> to my components but I'm facing a problame for the main REST interface.
>
> By default, the main REST interface handles requests using a dedicated 
> GUEST account. It's a kind of default account that is propagated to 
> the EJB container using a classic login mechanism. This is handle in a 
> ServletFilter that looks for HTTP Authentication headers. If headers 
> are not found, authentication on the container is done using the 
> default login 'guest'.
> For this special account, a dedicated login-module is used in the 
> wildfly security domain (<login-module code="Identity" flag="required">)
>
> I'm trying to migrate to keycloak using the undertow adapter but I'm 
> not able to handle a default login propagated to the EJB layer.
>
> The use case is that a simpe call to the REST api without 
> authentication token header should result as a container authenticated 
> user guest whereas requests with token included should try to perform 
> the token base authentication. In that way, unauthenticated usage of 
> HTML5/JS interface should result as guest requests and login process 
> only required when main REST api throws AccessDeniedException.
>
> Is there is any way to perform this using the KEYCLOAK auth-method or 
> do I have to write a specific Filter handling a kind of dual auth 
> mechanism (guest and keycloak) ?
>
> Best regards, J?r?me.
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141208/181acc59/attachment.html 

From carlosthe19916 at gmail.com  Mon Dec  8 08:06:11 2014
From: carlosthe19916 at gmail.com (Carlos Feria)
Date: Mon, 8 Dec 2014 08:06:11 -0500
Subject: [keycloak-user] Full Scope Allowed OFF
Message-ID: <CAAdSQ6g2bkRwj7u0z1qzUhMXzKP=5HHMWjt4nFeWF9++w8MKPg@mail.gmail.com>

Hi. Sorry by the question but i have a problem that i can?t solve.

I?m using ?Pure Client Javascript Adapter? and a APPLICATION WITH ?Full
Scope Allowed OFF, and Assigned Roles ?.

When i do ?*keycloak.init({ onLoad: ?login-required? })*? the login page
shows, but there accept all user accounts, I need login just users with
Assigned Roles on Scope?. Is there a bug? how can i solve my problem?
Thanks for all.


-- 
Carlos E. Feria Vila
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141208/b037b3db/attachment-0001.html 

From mposolda at redhat.com  Mon Dec  8 08:17:40 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Mon, 08 Dec 2014 14:17:40 +0100
Subject: [keycloak-user] Full Scope Allowed OFF
In-Reply-To: <CAAdSQ6g2bkRwj7u0z1qzUhMXzKP=5HHMWjt4nFeWF9++w8MKPg@mail.gmail.com>
References: <CAAdSQ6g2bkRwj7u0z1qzUhMXzKP=5HHMWjt4nFeWF9++w8MKPg@mail.gmail.com>
Message-ID: <5485A4F4.3010300@redhat.com>

Hi,

javascript application itself always accept all authenticated users, 
there is no authorization check of roles done in javascript adapter 
inside browser after authentication. But after successful 
authentication, your javascript app will receive accessToken and this 
token will have only roles limited by scopes you configured. Basically 
the roles in access token is intersection of:
- roles, which user is assigned to
- roles, configured by scope mapping of your application

The access token can then be used for REST calls and authorization of 
the token and granted roles is done by these rest calls.

Marek

On 8.12.2014 14:06, Carlos Feria wrote:
> Hi. Sorry by the question but i have a problem that i can?t solve.
>
> I?m using ?Pure Client Javascript Adapter? and a APPLICATION WITH 
> ?Full Scope Allowed OFF, and Assigned Roles ?.
>
> When i do ?*keycloak.init({ onLoad: ?login-required? })*? the login 
> page shows, but there accept all user accounts, I need login just 
> users with Assigned Roles on Scope?. Is there a bug? how can i solve 
> my problem? Thanks for all.
>
>
> -- 
> Carlos E. Feria Vila
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141208/98c5e94e/attachment.html 

From sarbx at hotmail.com  Mon Dec  8 15:32:01 2014
From: sarbx at hotmail.com (Bellan Saravanan)
Date: Mon, 8 Dec 2014 12:32:01 -0800
Subject: [keycloak-user] Federation
Message-ID: <COL126-W51A866F80245915A5A2154B5640@phx.gbl>

Hello,
The latest release notes talk about multi tenant enhancements like supporting multiple realms for a single application. Is it possible for a realm to delegate the authentication to a external identity provider like Ping or Okta  (using SAML or OpenID Connect) providing some kind of identity federation. 
One of the requirements for our app is that one or more of out tenants can use their own AD directory for authenticating users into our service. Eventhough keycloak has support for LDAP/AD, I'm not sure if customers will open up their directory for direct connectivity from our cloud service into their on premise AD. 
Thanks,
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141208/8fe9fa04/attachment.html 

From John.Schneider at carrier.utc.com  Mon Dec  8 18:45:18 2014
From: John.Schneider at carrier.utc.com (Schneider, John            DODGE CONSULTING SERVICES, LLC)
Date: Mon, 8 Dec 2014 23:45:18 +0000
Subject: [keycloak-user] 1.1 documentation update for running in domain HA
	mode
Message-ID: <D5998B55A61D334EA803FEB70395CFD70B0F31EB@UUSNWE3K.na.utcmail.com>

Hi guys,

Thanks so much for getting clustering support working in 1.1.  I have it up and running well in a Wildfly 8 domain setup under the "full-ha" profile.  One thing that I was pulling my hair out about for a while today were some errors related to Infinispan config.  I figured out that if running in HA cluster, you must include the "transport" element under the cache-container config (i.e. <transport lock-timeout="60000" />).  It would be great if you could update Chapter 23 of the documentation to reflect this requirement.

Thanks,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141208/0990bd41/attachment.html 

From gerbermichi at me.com  Tue Dec  9 04:53:41 2014
From: gerbermichi at me.com (Michael Gerber)
Date: Tue, 09 Dec 2014 09:53:41 +0000 (GMT)
Subject: [keycloak-user] Direct Grand loggins not listed in Sessions and
	Tokens
Message-ID: <ceea86ab-6c8d-45eb-b63f-55dc849df0a6@me.com>

Hi,

I use the REST WebService?/realms/{realm}/tokens/grants/access?to grant access to resources protected by Keycloak.

But these logged in users are not listed in the Sessions and Tokens section on the Admin page.?

Is there any way to get all active sessions for a given realm?

kind regards
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141209/d30e5b4a/attachment.html 

From gerbermichi at me.com  Tue Dec  9 10:56:05 2014
From: gerbermichi at me.com (Michael Gerber)
Date: Tue, 09 Dec 2014 15:56:05 +0000 (GMT)
Subject: [keycloak-user] How to get an access code via rest service
Message-ID: <94ea471b-22f4-416c-9d9e-727029ae58bb@me.com>

Hi,

I've got a fat client and a web application.?
My client wants to get an access code to open a new browser with these access code as URL parameter, so the users are directly logged in without reentering their credentials.

Thank you for your help!

kind regards
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141209/36e45d9e/attachment.html 

From John.Schneider at carrier.utc.com  Tue Dec  9 18:57:03 2014
From: John.Schneider at carrier.utc.com (Schneider, John            DODGE CONSULTING SERVICES, LLC)
Date: Tue, 9 Dec 2014 23:57:03 +0000
Subject: [keycloak-user] 1.1 Beta2 in Wildfly cluster
Message-ID: <D5998B55A61D334EA803FEB70395CFD70B0F34CF@UUSNWE3K.na.utcmail.com>

Hi,

Correction, I *thought* everything was running in Wildfly domain mode.  It turns out I just got lucky by hitting the same server node in my initial test.  After a reboot and further testing today, I?m not able to login to the Keycloak admin console when both nodes in my cluster are running.  After attempting login, I am either taken back to a blank login page, or I see error ?Unknown code, please login again through your application.?  Once in awhile, I can login without error. I should note that I?m using an Apache reverse proxy via mod_cluster.

I see no errors in the server logs.  I do see message ?JBAS010281: Started <x> cache from keycloak container? for each of ?realms?, ?sessions?, ?loginFailures?, ?users?.  So, it looks like my domain config is working.  However, I can?t tell for sure that Keycloak is attempting to use the infinispan caches.  Some additional log output showing the values from keycloak-server.json would be helpful.  I used the CLI to upload ?/profile=full-ha/subsystem=keycloak/auth-server=keycloak-1/:update-server-config(bytes-to-upload=/usr/local/wildfly/domain/configuration/keycloak-server.json~,overwrite=true)?  The response was ?success? and then I restarted Wildfly on both nodes in the cluster.

Has anyone been able to get Keycloak 1.1 Beta 2 working in a wildfly domain, and using mod_cluster?  If so, could you please provide guidance?

Thanks,
John

From: Schneider, John DODGE CONSULTING SERVICES, LLC
Sent: Monday, December 08, 2014 6:43 PM
To: keycloak-user at lists.jboss.org
Subject: 1.1 documentation update for running in domain HA mode

Hi guys,

Thanks so much for getting clustering support working in 1.1.  I have it up and running well in a Wildfly 8 domain setup under the ?full-ha? profile.  One thing that I was pulling my hair out about for a while today were some errors related to Infinispan config.  I figured out that if running in HA cluster, you must include the ?transport? element under the cache-container config (i.e. <transport lock-timeout=?60000? />).  It would be great if you could update Chapter 23 of the documentation to reflect this requirement.

Thanks,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141209/05dca411/attachment-0001.html 

From jayblanc at gmail.com  Thu Dec 11 05:31:33 2014
From: jayblanc at gmail.com (=?UTF-8?B?SsOpcsO0bWUgQmxhbmNoYXJk?=)
Date: Thu, 11 Dec 2014 10:31:33 +0000
Subject: [keycloak-user] Migration to Keycloak
References: <CAPNq5vbvMdKtZ2XKK-G=aKOUKN6O04NaJm+=JARWfjtxF3Q7+w@mail.gmail.com>
Message-ID: <CAPNq5vbNFtUNkVMWD_w6jNPiaSyP1v=4AtneQGWdVnTsajUVqw@mail.gmail.com>

Hi everybody,

I'm trying to migrate an existing application to keycloak and I'm facing
some problems.
My application is an ear composed of :
- one war containing Servlet and JaxRS resources (which are not session
beans but only rest resources calling EJBs)
- one jar containing EJB components secured with a dedicated SecurityDomain.
-one HTML5/Angular client application

I've configured the security domain in standalone-full.xml using the
KeycloakLoginModule .
I've also configured the war using jboss-web.xml to use the security domain
of EJBs
Finally I've include the JAX-RS filter in order to allows BearerToken
authentication on the REST api in the WAR.

Angular application is able to loggin and to send the bearer token in the
http header. The jaxRS logs shows that token is received and user name is
retreive.
What happens is that authentication is not propagated to the EJB Layer and
the LoginModule is never called.

Anybody has an idea on how to make this propagation works ?

Thanks for your help, best regards, J?r?me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141211/e52dfade/attachment.html 

From rubenlop88 at gmail.com  Thu Dec 11 12:07:22 2014
From: rubenlop88 at gmail.com (Ruben Lopez)
Date: Thu, 11 Dec 2014 14:07:22 -0300
Subject: [keycloak-user] Questions about keycloak
In-Reply-To: <2084644196.7048027.1417161849834.JavaMail.zimbra@redhat.com>
References: <CA+L_nNiTRZ2ySW7+XG-5461nmdi0XXuNV=foOBXugO-chcFNcw@mail.gmail.com>
	<54774560.8050809@redhat.com>
	<CA+L_nNiYQm4FRXGehR4n331dETJsdAv4Mis_VJSE=op3uZPo3g@mail.gmail.com>
	<2084644196.7048027.1417161849834.JavaMail.zimbra@redhat.com>
Message-ID: <CA+L_nNh_C3c_fw_+jP8vhyVsMVt50AEYWDUVfdW2XZoytDXg_w@mail.gmail.com>

I have a couple more questions.

1) Will you implement the features requested in KEYCLOAK-402 and
KEYCLOAK-405? If so, when?
2) Are there any plans to support Integrated Windows Authentication?

Thanks :)

2014-11-28 5:04 GMT-03:00 Stian Thorgersen <stian at redhat.com>:

>
>
> ----- Original Message -----
> > From: "Ruben Lopez" <rubenlop88 at gmail.com>
> > To: "Marek Posolda" <mposolda at redhat.com>
> > Cc: keycloak-user at lists.jboss.org
> > Sent: Thursday, 27 November, 2014 5:37:45 PM
> > Subject: Re: [keycloak-user] Questions about keycloak
> >
> > Hi Marek,
> >
> > 2014-11-27 12:38 GMT-03:00 Marek Posolda < mposolda at redhat.com > :
> >
> >
> >
> >
> >
> > 1 - Is there any way to obtain an access token for an OAuth Client via
> Client
> > Credentials[1]?
> > You mean something like Service account like this from OAuth2 specs
> > http://tools.ietf.org/html/rfc6749#page-40 ? We don't have that yet, but
> > there are plans to support it afaik.
> >
> >
> >
> >
> > Yes, I was talking about secction 4.4 Client Credentials Grant. Any idea
> > about when it will be implemented?
>
> I can't give you and exact date, but it's becoming more and more of a
> priority so should be within a few months. We also plan to add cert based
> authentication for clients.
>
> In the mean-time you can work-around this issue by creating a user on
> behalf of the client and use Resource Owner Password Credentials Grant
> (section #4.3). Look at 'examples/preconfigured-demo/admin-access' in the
> download for an example.
>
> >
> >
> >
> >
> >
> >
> > 2 - If we make a request to an Application (Resource Server) with an
> access
> > token and this Application needs to talk to another protected
> Application to
> > form the response to the client, how does the first Application
> > authenticates to the second Application? Does Keycloak implements
> something
> > like Chain Grant Type Profile[2]?
> > yes, that is doable. We have an example where we have frontend
> application
> > like 'customer-portal', which is able to retrieve accessToken from
> keycloak
> > like here:
> >
> https://github.com/keycloak/keycloak/blob/master/examples/demo-template/customer-app/src/main/java/org/keycloak/example/CustomerDatabaseClient.java#L48
> > and then use this accessToken to send request to backend application
> > 'database-service' in Authorization header
> >
> https://github.com/keycloak/keycloak/blob/master/examples/demo-template/customer-app/src/main/java/org/keycloak/example/CustomerDatabaseClient.java#L54
> > . Database-service is then able to authenticate the token.
> >
> > Currently our database-service is directly serving requests and send back
> > data, but it shouldn't be a problem to add another application to the
> chain,
> > so that database-service will send the token again to another app like
> > 'real-database-service', which will return data and those data will be
> sent
> > back to the original frontent requestor (customer-portal). Is it
> something
> > what you meant?
> >
> > Thats exactly what I meant. I will take a look at the example.
> >
> > Thank you very much.
> >
> >
> >
> >
> >
> > Marek
> >
> >
> >
> >
> > Thanks in advance.
> >
> >
> > _______________________________________________
> > keycloak-user mailing list keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
> >
> >
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141211/ea80eb11/attachment.html 

From mikhail.kuznetsov at hp.com  Thu Dec 11 17:20:32 2014
From: mikhail.kuznetsov at hp.com (Kuznetsov, Mike)
Date: Thu, 11 Dec 2014 22:20:32 +0000
Subject: [keycloak-user] Clarification of use case: simultaneous requests
	with expired token
Message-ID: <66122567ABACCC42B5B568EC7E90551A1971349F@G6W2492.americas.hpqcorp.net>

Hello,

We are in the process of securing our REST APIs using Keycloak. Please confirm our understanding of the following:

We have a use case where our web client may SIMULTANEOUSLY send several REST API calls (r1, r2,r3...) to our server using the Access Token (at1) and Refresh Token (rt1).
When r1 is being handled, assuming that at1 is expired, server-side adapter will be taking care of getting new tokens (at2, rt2). Is it safe to assume that r2 and r3 will get hold of at2 and rt2? If so, is it valid to conclude that the adapter is maintaining state for the token.

Thank You,

Mikhail Kuznetsov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141211/8d1ac9d0/attachment.html 

From Luke_Adams at ao.uscourts.gov  Thu Dec 11 17:31:36 2014
From: Luke_Adams at ao.uscourts.gov (Luke_Adams at ao.uscourts.gov)
Date: Thu, 11 Dec 2014 17:31:36 -0500
Subject: [keycloak-user] Key Cloak Support
Message-ID: <OF7C936745.C6A1BC1E-ON85257DAB.007B7C18-85257DAB.007BBE20@uscmail.uscourts.gov>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141211/4e80a63e/attachment.html 

From mposolda at redhat.com  Fri Dec 12 04:43:56 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 12 Dec 2014 10:43:56 +0100
Subject: [keycloak-user] Questions about keycloak
In-Reply-To: <CA+L_nNh_C3c_fw_+jP8vhyVsMVt50AEYWDUVfdW2XZoytDXg_w@mail.gmail.com>
References: <CA+L_nNiTRZ2ySW7+XG-5461nmdi0XXuNV=foOBXugO-chcFNcw@mail.gmail.com>	<54774560.8050809@redhat.com>	<CA+L_nNiYQm4FRXGehR4n331dETJsdAv4Mis_VJSE=op3uZPo3g@mail.gmail.com>	<2084644196.7048027.1417161849834.JavaMail.zimbra@redhat.com>
	<CA+L_nNh_C3c_fw_+jP8vhyVsMVt50AEYWDUVfdW2XZoytDXg_w@mail.gmail.com>
Message-ID: <548AB8DC.4070207@redhat.com>

On 11.12.2014 18:07, Ruben Lopez wrote:
> I have a couple more questions.
>
> 1) Will you implement the features requested in KEYCLOAK-402 and 
> KEYCLOAK-405? If so, when?
Hard to say exactly, but looks that it will be quite soon as it is 
requirement from more people and potential customers . Hopefully in 
terms of weeks/months, but hard to promise exact date... I think it 
would require enhance our existing password policies, but those would be 
a bit harder to add than current simple policies as it will also require 
to store some info in database (like password expiration time and older 
passwords)
> 2) Are there any plans to support Integrated Windows Authentication?
You mean login to KC when user is already logged in windows domain? Yes, 
we have plan for add Kerberos/spnego soon and I think that it should 
solve windows domain authentication too. Hopefully around January.

Marek
>
> Thanks :)
>
> 2014-11-28 5:04 GMT-03:00 Stian Thorgersen <stian at redhat.com 
> <mailto:stian at redhat.com>>:
>
>
>
>     ----- Original Message -----
>     > From: "Ruben Lopez" <rubenlop88 at gmail.com
>     <mailto:rubenlop88 at gmail.com>>
>     > To: "Marek Posolda" <mposolda at redhat.com
>     <mailto:mposolda at redhat.com>>
>     > Cc: keycloak-user at lists.jboss.org
>     <mailto:keycloak-user at lists.jboss.org>
>     > Sent: Thursday, 27 November, 2014 5:37:45 PM
>     > Subject: Re: [keycloak-user] Questions about keycloak
>     >
>     > Hi Marek,
>     >
>     > 2014-11-27 12:38 GMT-03:00 Marek Posolda < mposolda at redhat.com
>     <mailto:mposolda at redhat.com> > :
>     >
>     >
>     >
>     >
>     >
>     > 1 - Is there any way to obtain an access token for an OAuth
>     Client via Client
>     > Credentials[1]?
>     > You mean something like Service account like this from OAuth2 specs
>     > http://tools.ietf.org/html/rfc6749#page-40 ? We don't have that
>     yet, but
>     > there are plans to support it afaik.
>     >
>     >
>     >
>     >
>     > Yes, I was talking about secction 4.4 Client Credentials Grant.
>     Any idea
>     > about when it will be implemented?
>
>     I can't give you and exact date, but it's becoming more and more
>     of a priority so should be within a few months. We also plan to
>     add cert based authentication for clients.
>
>     In the mean-time you can work-around this issue by creating a user
>     on behalf of the client and use Resource Owner Password
>     Credentials Grant (section #4.3). Look at
>     'examples/preconfigured-demo/admin-access' in the download for an
>     example.
>
>     >
>     >
>     >
>     >
>     >
>     >
>     > 2 - If we make a request to an Application (Resource Server)
>     with an access
>     > token and this Application needs to talk to another protected
>     Application to
>     > form the response to the client, how does the first Application
>     > authenticates to the second Application? Does Keycloak
>     implements something
>     > like Chain Grant Type Profile[2]?
>     > yes, that is doable. We have an example where we have frontend
>     application
>     > like 'customer-portal', which is able to retrieve accessToken
>     from keycloak
>     > like here:
>     >
>     https://github.com/keycloak/keycloak/blob/master/examples/demo-template/customer-app/src/main/java/org/keycloak/example/CustomerDatabaseClient.java#L48
>     > and then use this accessToken to send request to backend application
>     > 'database-service' in Authorization header
>     >
>     https://github.com/keycloak/keycloak/blob/master/examples/demo-template/customer-app/src/main/java/org/keycloak/example/CustomerDatabaseClient.java#L54
>     > . Database-service is then able to authenticate the token.
>     >
>     > Currently our database-service is directly serving requests and
>     send back
>     > data, but it shouldn't be a problem to add another application
>     to the chain,
>     > so that database-service will send the token again to another
>     app like
>     > 'real-database-service', which will return data and those data
>     will be sent
>     > back to the original frontent requestor (customer-portal). Is it
>     something
>     > what you meant?
>     >
>     > Thats exactly what I meant. I will take a look at the example.
>     >
>     > Thank you very much.
>     >
>     >
>     >
>     >
>     >
>     > Marek
>     >
>     >
>     >
>     >
>     > Thanks in advance.
>     >
>     >
>     > _______________________________________________
>     > keycloak-user mailing list keycloak-user at lists.jboss.org
>     <mailto:keycloak-user at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/keycloak-user
>     >
>     >
>     >
>     > _______________________________________________
>     > keycloak-user mailing list
>     > keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141212/817a236c/attachment-0001.html 

From mposolda at redhat.com  Fri Dec 12 04:47:33 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 12 Dec 2014 10:47:33 +0100
Subject: [keycloak-user] Federation
In-Reply-To: <COL126-W51A866F80245915A5A2154B5640@phx.gbl>
References: <COL126-W51A866F80245915A5A2154B5640@phx.gbl>
Message-ID: <548AB9B5.9030102@redhat.com>

On 8.12.2014 21:32, Bellan Saravanan wrote:
> Hello,
>
> The latest release notes talk about multi tenant enhancements like 
> supporting multiple realms for a single application. Is it possible 
> for a realm to delegate the authentication to a external identity 
> provider like Ping or Okta  (using SAML or OpenID Connect) providing 
> some kind of identity federation.
The work on this is already in progress and hopefully will be in next 
version.

Marek
>
> One of the requirements for our app is that one or more of out tenants 
> can use their own AD directory for authenticating users into our 
> service. Eventhough keycloak has support for LDAP/AD, I'm not sure if 
> customers will open up their directory for direct connectivity from 
> our cloud service into their on premise AD.
>
> Thanks,
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141212/2a6df5dd/attachment.html 

From mposolda at redhat.com  Fri Dec 12 05:18:25 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 12 Dec 2014 11:18:25 +0100
Subject: [keycloak-user] Migration to Keycloak
In-Reply-To: <CAPNq5vbNFtUNkVMWD_w6jNPiaSyP1v=4AtneQGWdVnTsajUVqw@mail.gmail.com>
References: <CAPNq5vbvMdKtZ2XKK-G=aKOUKN6O04NaJm+=JARWfjtxF3Q7+w@mail.gmail.com>
	<CAPNq5vbNFtUNkVMWD_w6jNPiaSyP1v=4AtneQGWdVnTsajUVqw@mail.gmail.com>
Message-ID: <548AC0F1.9050203@redhat.com>

On 11.12.2014 11:31, J?r?me Blanchard wrote:
> Hi everybody,
>
> I'm trying to migrate an existing application to keycloak and I'm 
> facing some problems.
> My application is an ear composed of :
> - one war containing Servlet and JaxRS resources (which are not 
> session beans but only rest resources calling EJBs)
> - one jar containing EJB components secured with a dedicated 
> SecurityDomain.
> -one HTML5/Angular client application
>
> I've configured the security domain in standalone-full.xml using the 
> KeycloakLoginModule .
> I've also configured the war using jboss-web.xml to use the security 
> domain of EJBs
> Finally I've include the JAX-RS filter in order to allows BearerToken 
> authentication on the REST api in the WAR.
>
> Angular application is able to loggin and to send the bearer token in 
> the http header. The jaxRS logs shows that token is received and user 
> name is retreive.
> What happens is that authentication is not propagated to the EJB Layer 
> and the LoginModule is never called.
yes, the propagation from Jax-rs filter to EJB unfortunately doesn't 
work. You can use the adapter and servlet authentication and in this 
case it should be propagated as described in reference guide - 
http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/ch07.html#jboss-adapter 
. But in another thread you also mention the requirement of "guest" 
authentication (like if Authorization header with bearer token is not 
present, your app will use some kind of guest account instead of sending 
back 401 error). Is it still requirement?

It seems that easiest short-term solution might be to add support for 
guest authentication to our KC adapter. It will be optional feature, 
which will be disabled by default. If it's enabled, it will use some 
predefined guest account and guest roles in case that Authorization 
header is not present. But I am not sure if it's something, which we 
want to support in KC...

Marek
>
> Anybody has an idea on how to make this propagation works ?
>
> Thanks for your help, best regards, J?r?me.
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141212/cf173827/attachment.html 

From mposolda at redhat.com  Fri Dec 12 05:32:53 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 12 Dec 2014 11:32:53 +0100
Subject: [keycloak-user] Clarification of use case: simultaneous
 requests with expired token
In-Reply-To: <66122567ABACCC42B5B568EC7E90551A1971349F@G6W2492.americas.hpqcorp.net>
References: <66122567ABACCC42B5B568EC7E90551A1971349F@G6W2492.americas.hpqcorp.net>
Message-ID: <548AC455.30203@redhat.com>

On 11.12.2014 23:20, Kuznetsov, Mike wrote:
>
> Hello,
>
> We are in the process of securing our REST APIs using Keycloak. Please 
> confirm our understanding of the following:
>
> We have a use case where our web client may SIMULTANEOUSLY send 
> several REST API calls (r1, r2,r3?) to our server using the Access 
> Token (at1) and Refresh Token (rt1).
>
> When r1 is being handled, assuming that at1 is expired, server-side 
> adapter will be taking care of getting new tokens (at2, rt2). Is it 
> safe to assume that r2 and r3 will get hold of at2 and rt2? If so, is 
> it valid to conclude that the adapter is maintaining state for the token.
>
Your web client is servlet application secured by keycloak?

Actually it's the frontend application, which handles refreshing of 
tokens. You can take a look at our example, where frontend application 
is sending rest requests to backend application: 
https://github.com/keycloak/keycloak/blob/master/examples/demo-template/customer-app/src/main/java/org/keycloak/example/CustomerDatabaseClient.java#L54 
. In this case when the code is calling:

session.getTokenString()

the adapter will automatically handle refreshing the token (it checks if 
token is expired and automatically refresh if it is). So later you can 
use this accessToken to send parallel requests to your REST endpoints 
and it should be ok to assume that accessToken is not expired.

Marek
>
> Thank You,
>
> Mikhail Kuznetsov
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141212/2291e589/attachment.html 

From mposolda at redhat.com  Fri Dec 12 06:23:57 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 12 Dec 2014 12:23:57 +0100
Subject: [keycloak-user] 1.1 documentation update for running in domain
 HA mode
In-Reply-To: <D5998B55A61D334EA803FEB70395CFD70B0F31EB@UUSNWE3K.na.utcmail.com>
References: <D5998B55A61D334EA803FEB70395CFD70B0F31EB@UUSNWE3K.na.utcmail.com>
Message-ID: <548AD04D.6020303@redhat.com>

I've updated documentation. It's updated in master, so will be in online 
docs for next version. Thanks a lot for reporting this!

Marek

On 9.12.2014 00:45, Schneider, John DODGE CONSULTING SERVICES, LLC wrote:
>
> Hi guys,
>
> Thanks so much for getting clustering support working in 1.1.  I have 
> it up and running well in a Wildfly 8 domain setup under the ?full-ha? 
> profile.  One thing that I was pulling my hair out about for a while 
> today were some errors related to Infinispan config.  I figured out 
> that if running in HA cluster, you must include the ?transport? 
> element under the cache-container config (i.e. <transport 
> lock-timeout=?60000? />).  It would be great if you could update 
> Chapter 23 of the documentation to reflect this requirement.
>
> Thanks,
>
> John
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141212/b791cf4b/attachment-0001.html 

From mposolda at redhat.com  Fri Dec 12 06:55:55 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 12 Dec 2014 12:55:55 +0100
Subject: [keycloak-user] 1.1 Beta2 in Wildfly cluster
In-Reply-To: <D5998B55A61D334EA803FEB70395CFD70B0F34CF@UUSNWE3K.na.utcmail.com>
References: <D5998B55A61D334EA803FEB70395CFD70B0F34CF@UUSNWE3K.na.utcmail.com>
Message-ID: <548AD7CB.702@redhat.com>

Are you using shared database among both cluster nodes? Also when you 
start node1 and then start node2, you should see some message similar to 
this in the log of node1, which indicates that cluster nodes are connected:

wfnode_1 | 11:28:30,888 INFO 
[org.infinispan.remoting.transport.jgroups.JGroupsTransport] 
(Incoming-1,shared=udp) ISPN000094: Received new cluster view: 
[wfnode1/web|1] (2) [wfnode1/web, wfnode2/web]
wfnode_1 | 11:28:33,767 INFO 
[org.infinispan.remoting.transport.jgroups.JGroupsTransport] 
(Incoming-10,shared=udp) ISPN000094: Received new cluster view: 
[wfnode1/keycloak|1] (2) [wfnode1/keycloak, wfnode2/keycloak]



For more logging of which provider is used by keycloak-server.json, you 
can enable DEBUG logging for keycloak in standalone-full.xml (or 
domain.xml or whatever you are using):

                 <logger category="org.keycloak">
                     <level name="DEBUG"/>
                 </logger>

Also I think that editing file 
|standalone/configuration/keycloak-server.json is just for standalone, 
but probably doesn't work for wildfly domain.

|
Maybe you can first try if cluster works in standalone configuration. If 
it helps, we can figure the domain later.

Marek

On 10.12.2014 00:57, Schneider, John DODGE CONSULTING SERVICES, LLC wrote:
>
> Hi,
>
> Correction, I **thought** everything was running in Wildfly domain 
> mode.  It turns out I just got lucky by hitting the same server node 
> in my initial test.  After a reboot and further testing today, I?m not 
> able to login to the Keycloak admin console when both nodes in my 
> cluster are running.  After attempting login, I am either taken back 
> to a blank login page, or I see error ?Unknown code, please login 
> again through your application.?  Once in awhile, I can login without 
> error. I should note that I?m using an Apache reverse proxy via 
> mod_cluster.
>
> I see no errors in the server logs.  I do see message ?JBAS010281: 
> Started <x> cache from keycloak container? for each of ?realms?, 
> ?sessions?, ?loginFailures?, ?users?.  So, it looks like my domain 
> config is working.  However, I can?t tell for sure that Keycloak is 
> attempting to use the infinispan caches.  Some additional log output 
> showing the values from keycloak-server.json would be helpful.  I used 
> the CLI to upload 
> ?/profile=full-ha/subsystem=keycloak/auth-server=keycloak-1/:update-server-config(bytes-to-upload=/usr/local/wildfly/domain/configuration/keycloak-server.json~,overwrite=true)? 
> The response was ?success? and then I restarted Wildfly on both nodes 
> in the cluster.
>
> Has anyone been able to get Keycloak 1.1 Beta 2 working in a wildfly 
> domain, and using mod_cluster?  If so, could you please provide guidance?
>
> Thanks,
>
> John
>
> *From:*Schneider, John DODGE CONSULTING SERVICES, LLC
> *Sent:* Monday, December 08, 2014 6:43 PM
> *To:* keycloak-user at lists.jboss.org
> *Subject:* 1.1 documentation update for running in domain HA mode
>
> Hi guys,
>
> Thanks so much for getting clustering support working in 1.1.  I have 
> it up and running well in a Wildfly 8 domain setup under the ?full-ha? 
> profile.  One thing that I was pulling my hair out about for a while 
> today were some errors related to Infinispan config.  I figured out 
> that if running in HA cluster, you must include the ?transport? 
> element under the cache-container config (i.e. <transport 
> lock-timeout=?60000? />).  It would be great if you could update 
> Chapter 23 of the documentation to reflect this requirement.
>
> Thanks,
>
> John
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141212/29e5479b/attachment.html 

From eric.wittmann at redhat.com  Fri Dec 12 08:06:11 2014
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Fri, 12 Dec 2014 08:06:11 -0500
Subject: [keycloak-user] Sub-resource authentication (edge case)
Message-ID: <548AE843.1020206@redhat.com>

In apiman I have a bit of an edge case that currently isn't working as I 
was hoping (running in wildfly 8.2 - not tested on any other platform).

The issue is that I have a WAR with two sub-contexts:

/api - JAX-RS endpoints to configure the API Gateway
/gateway - the API Gateway (reverse proxy)

I wanted /api to be protected by keycloak, but for /gateway to be 
unprotected.

My web.xml looks like this:

   <security-constraint>
     <web-resource-collection>
       <web-resource-name>apiman-gateway</web-resource-name>
       <url-pattern>/api/*</url-pattern>
     </web-resource-collection>
     <auth-constraint>
       <role-name>apiadmin</role-name>
     </auth-constraint>
   </security-constraint>
   <login-config>
     <auth-method>BASIC</auth-method>
     <realm-name>apiman</realm-name>
   </login-config>
   <security-role>
     <role-name>apiadmin</role-name>
   </security-role>


It all works great until I send a request to /gateway/* that includes an 
"Authorization" http header.  If I do that, the adapter tries to 
authenticate with those credentials and fails with a 401 if they don't 
match (which they don't).

I realize this is an odd case, but I did expect that if the web.xml 
specified that only /api/* were protected then other paths would simply 
pass through any Authorization headers.  That may be an incorrect 
expectation - not sure what the servlet spec requires in this case.

Thoughts?

Currently I'm probably going to work around this by splitting up the API 
and Gateway servlets into separate WARs.

-Eric

From jayblanc at gmail.com  Fri Dec 12 08:27:03 2014
From: jayblanc at gmail.com (=?UTF-8?B?SsOpcsO0bWUgQmxhbmNoYXJk?=)
Date: Fri, 12 Dec 2014 13:27:03 +0000
Subject: [keycloak-user] Migration to Keycloak
References: <CAPNq5vbvMdKtZ2XKK-G=aKOUKN6O04NaJm+=JARWfjtxF3Q7+w@mail.gmail.com>
	<CAPNq5vbNFtUNkVMWD_w6jNPiaSyP1v=4AtneQGWdVnTsajUVqw@mail.gmail.com>
	<548AC0F1.9050203@redhat.com>
Message-ID: <CAPNq5vYB=7OArd71sYjUbLf3UJBJvs3hEPfKkYiPG1_TCMH8VA@mail.gmail.com>

Hi,

I've finally change my use case to avoid giving the guest user a particular
r?le (user) and switch to a completely anonymous way of working in EJB. In
this case, avoiding a particular security-constraint in the webapp let the
keycloak undertow adapter pass some anonymous request goes throught EJB
and, in the case of an existing Bearer token, authenticate and propagate
principal.

So now, we have a working solution that fits with our needs. Next step is
configuration of Grant Token for external webapps to access REST interface
using a Grant Token, but it's another story.

Thank for your support. Best regards, J?r?me.

Le Fri Dec 12 2014 at 11:18:30, Marek Posolda <mposolda at redhat.com> a
?crit :

> On 11.12.2014 11:31, J?r?me Blanchard wrote:
>
> Hi everybody,
>
>  I'm trying to migrate an existing application to keycloak and I'm facing
> some problems.
> My application is an ear composed of :
> - one war containing Servlet and JaxRS resources (which are not session
> beans but only rest resources calling EJBs)
> - one jar containing EJB components secured with a dedicated
> SecurityDomain.
> -one HTML5/Angular client application
>
>  I've configured the security domain in standalone-full.xml using the
> KeycloakLoginModule .
> I've also configured the war using jboss-web.xml to use the security
> domain of EJBs
> Finally I've include the JAX-RS filter in order to allows BearerToken
> authentication on the REST api in the WAR.
>
>  Angular application is able to loggin and to send the bearer token in
> the http header. The jaxRS logs shows that token is received and user name
> is retreive.
> What happens is that authentication is not propagated to the EJB Layer and
> the LoginModule is never called.
>
> yes, the propagation from Jax-rs filter to EJB unfortunately doesn't work.
> You can use the adapter and servlet authentication and in this case it
> should be propagated as described in reference guide -
> http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/ch07.html#jboss-adapter
> . But in another thread you also mention the requirement of "guest"
> authentication (like if Authorization header with bearer token is not
> present, your app will use some kind of guest account instead of sending
> back 401 error). Is it still requirement?
>
> It seems that easiest short-term solution might be to add support for
> guest authentication to our KC adapter. It will be optional feature, which
> will be disabled by default. If it's enabled, it will use some predefined
> guest account and guest roles in case that Authorization header is not
> present. But I am not sure if it's something, which we want to support in
> KC...
>
> Marek
>
>
>  Anybody has an idea on how to make this propagation works ?
>
>  Thanks for your help, best regards, J?r?me.
>
>
> _______________________________________________
> keycloak-user mailing listkeycloak-user at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141212/3cacb40b/attachment.html 

From mposolda at redhat.com  Fri Dec 12 11:33:06 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Fri, 12 Dec 2014 17:33:06 +0100
Subject: [keycloak-user] Sub-resource authentication (edge case)
In-Reply-To: <548AE843.1020206@redhat.com>
References: <548AE843.1020206@redhat.com>
Message-ID: <548B18C2.7080502@redhat.com>

Hi,

if you want to use keycloak for authentication you should rather use:

<auth-method>KEYCLOAK</auth-method>

Also I don't know how are you sending request to "/api/*" . I guess it 
is javascript application or some other servlet application, which is 
sending jax-rs requests to api? In this cases, you should add manually 
"Authorization" header with either "Authorization: Bearer ..." with 
bearer token attached or "Authorization: Basic ...." with keycloak 
username/password attached (bearer token is much better, so you can 
avoid direct grant and you don't need to share credentials with your 
application)

Marek

On 12.12.2014 14:06, Eric Wittmann wrote:
> In apiman I have a bit of an edge case that currently isn't working as I
> was hoping (running in wildfly 8.2 - not tested on any other platform).
>
> The issue is that I have a WAR with two sub-contexts:
>
> /api - JAX-RS endpoints to configure the API Gateway
> /gateway - the API Gateway (reverse proxy)
>
> I wanted /api to be protected by keycloak, but for /gateway to be
> unprotected.
>
> My web.xml looks like this:
>
>     <security-constraint>
>       <web-resource-collection>
>         <web-resource-name>apiman-gateway</web-resource-name>
>         <url-pattern>/api/*</url-pattern>
>       </web-resource-collection>
>       <auth-constraint>
>         <role-name>apiadmin</role-name>
>       </auth-constraint>
>     </security-constraint>
>     <login-config>
>       <auth-method>BASIC</auth-method>
>       <realm-name>apiman</realm-name>
>     </login-config>
>     <security-role>
>       <role-name>apiadmin</role-name>
>     </security-role>
>
>
> It all works great until I send a request to /gateway/* that includes an
> "Authorization" http header.  If I do that, the adapter tries to
> authenticate with those credentials and fails with a 401 if they don't
> match (which they don't).
>
> I realize this is an odd case, but I did expect that if the web.xml
> specified that only /api/* were protected then other paths would simply
> pass through any Authorization headers.  That may be an incorrect
> expectation - not sure what the servlet spec requires in this case.
>
> Thoughts?
>
> Currently I'm probably going to work around this by splitting up the API
> and Gateway servlets into separate WARs.
>
> -Eric
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user


From John.Schneider at carrier.utc.com  Fri Dec 12 13:07:38 2014
From: John.Schneider at carrier.utc.com (Schneider, John            DODGE CONSULTING SERVICES, LLC)
Date: Fri, 12 Dec 2014 18:07:38 +0000
Subject: [keycloak-user] [External] Re:  1.1 Beta2 in Wildfly cluster
In-Reply-To: <548AD7CB.702@redhat.com>
References: <D5998B55A61D334EA803FEB70395CFD70B0F34CF@UUSNWE3K.na.utcmail.com>
	<548AD7CB.702@redhat.com>
Message-ID: <D5998B55A61D334EA803FEB70395CFD70B0F3A23@UUSNWE3K.na.utcmail.com>

Hi Marek,

Thanks for getting back to me.  I did see the ISPN000094 message you described in my log files, but it didn?t look like the messages you listed.  My messages only noted one node.  After disabling the firewall on both nodes, Keycloak is now working in domain mode with Infinispan providers in my config.  Now I just have to figure out all the ports necessary for JGroups to function correctly.  Once I figure this out, I will respond back.  Hopefully you can add this info to the documentation to help others out in the future.

Thanks again for your help,
John


From: Marek Posolda [mailto:mposolda at redhat.com]
Sent: Friday, December 12, 2014 6:56 AM
To: Schneider, John DODGE CONSULTING SERVICES, LLC; keycloak-user at lists.jboss.org
Subject: [External] Re: [keycloak-user] 1.1 Beta2 in Wildfly cluster

Are you using shared database among both cluster nodes? Also when you start node1 and then start node2, you should see some message similar to this in the log of node1, which indicates that cluster nodes are connected:

wfnode_1 | 11:28:30,888 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-1,shared=udp) ISPN000094: Received new cluster view: [wfnode1/web|1] (2) [wfnode1/web, wfnode2/web]
wfnode_1 | 11:28:33,767 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-10,shared=udp) ISPN000094: Received new cluster view: [wfnode1/keycloak|1] (2) [wfnode1/keycloak, wfnode2/keycloak]



For more logging of which provider is used by keycloak-server.json, you can enable DEBUG logging for keycloak in standalone-full.xml (or domain.xml or whatever you are using):

                <logger category="org.keycloak">
                    <level name="DEBUG"/>
                </logger>

Also I think that editing file standalone/configuration/keycloak-server.json is just for standalone, but probably doesn't work for wildfly domain.


Maybe you can first try if cluster works in standalone configuration. If it helps, we can figure the domain later.

Marek

On 10.12.2014 00:57, Schneider, John DODGE CONSULTING SERVICES, LLC wrote:
Hi,

Correction, I *thought* everything was running in Wildfly domain mode.  It turns out I just got lucky by hitting the same server node in my initial test.  After a reboot and further testing today, I?m not able to login to the Keycloak admin console when both nodes in my cluster are running.  After attempting login, I am either taken back to a blank login page, or I see error ?Unknown code, please login again through your application.?  Once in awhile, I can login without error. I should note that I?m using an Apache reverse proxy via mod_cluster.

I see no errors in the server logs.  I do see message ?JBAS010281: Started <x> cache from keycloak container? for each of ?realms?, ?sessions?, ?loginFailures?, ?users?.  So, it looks like my domain config is working.  However, I can?t tell for sure that Keycloak is attempting to use the infinispan caches.  Some additional log output showing the values from keycloak-server.json would be helpful.  I used the CLI to upload ?/profile=full-ha/subsystem=keycloak/auth-server=keycloak-1/:update-server-config(bytes-to-upload=/usr/local/wildfly/domain/configuration/keycloak-server.json~,overwrite=true)?  The response was ?success? and then I restarted Wildfly on both nodes in the cluster.

Has anyone been able to get Keycloak 1.1 Beta 2 working in a wildfly domain, and using mod_cluster?  If so, could you please provide guidance?

Thanks,
John

From: Schneider, John DODGE CONSULTING SERVICES, LLC
Sent: Monday, December 08, 2014 6:43 PM
To: keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>
Subject: 1.1 documentation update for running in domain HA mode

Hi guys,

Thanks so much for getting clustering support working in 1.1.  I have it up and running well in a Wildfly 8 domain setup under the ?full-ha? profile.  One thing that I was pulling my hair out about for a while today were some errors related to Infinispan config.  I figured out that if running in HA cluster, you must include the ?transport? element under the cache-container config (i.e. <transport lock-timeout=?60000? />).  It would be great if you could update Chapter 23 of the documentation to reflect this requirement.

Thanks,
John




_______________________________________________

keycloak-user mailing list

keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>

https://lists.jboss.org/mailman/listinfo/keycloak-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141212/0def23f5/attachment.html 

From eric.wittmann at redhat.com  Fri Dec 12 13:18:51 2014
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Fri, 12 Dec 2014 13:18:51 -0500
Subject: [keycloak-user] Sub-resource authentication (edge case)
In-Reply-To: <548B18C2.7080502@redhat.com>
References: <548AE843.1020206@redhat.com> <548B18C2.7080502@redhat.com>
Message-ID: <548B318B.2060909@redhat.com>

Well, my understanding is that when configuring via the subsystem in 
wildfly, BASIC was the way to go.  That said, I don't have a particular 
preference.

But is that detail perhaps beside the point?

The /api/* endpoint works exactly as you have described.  In 
standalone.xml I've configured it to enable both bearer token and basic 
auth.  So requests can be sent to /api/* with the Authorization header 
set (bearer token and basic auth credentials both work fine).

The problem comes when sending a request to /gateway/*, which is just a 
servlet.  I can successfully send a request to /gateway/* without an 
Authorization header.  This works (unauthenticated access).  However if 
I send a request to /gateway/* with an Authorization header, then 
keycloak attempts to authenticate.  Even though the web.xml doesn't 
indicate that /gateway/* should be protected.

I was expecting any *unprotected* resources to simply pass through any 
Authorization information, not attempt to actually process it.

Again, this is perhaps an incorrect expectation on my part.

-Eric

On 12/12/2014 11:33 AM, Marek Posolda wrote:
> Hi,
>
> if you want to use keycloak for authentication you should rather use:
>
> <auth-method>KEYCLOAK</auth-method>
>
> Also I don't know how are you sending request to "/api/*" . I guess it
> is javascript application or some other servlet application, which is
> sending jax-rs requests to api? In this cases, you should add manually
> "Authorization" header with either "Authorization: Bearer ..." with
> bearer token attached or "Authorization: Basic ...." with keycloak
> username/password attached (bearer token is much better, so you can
> avoid direct grant and you don't need to share credentials with your
> application)
>
> Marek
>
> On 12.12.2014 14:06, Eric Wittmann wrote:
>> In apiman I have a bit of an edge case that currently isn't working as I
>> was hoping (running in wildfly 8.2 - not tested on any other platform).
>>
>> The issue is that I have a WAR with two sub-contexts:
>>
>> /api - JAX-RS endpoints to configure the API Gateway
>> /gateway - the API Gateway (reverse proxy)
>>
>> I wanted /api to be protected by keycloak, but for /gateway to be
>> unprotected.
>>
>> My web.xml looks like this:
>>
>>     <security-constraint>
>>       <web-resource-collection>
>>         <web-resource-name>apiman-gateway</web-resource-name>
>>         <url-pattern>/api/*</url-pattern>
>>       </web-resource-collection>
>>       <auth-constraint>
>>         <role-name>apiadmin</role-name>
>>       </auth-constraint>
>>     </security-constraint>
>>     <login-config>
>>       <auth-method>BASIC</auth-method>
>>       <realm-name>apiman</realm-name>
>>     </login-config>
>>     <security-role>
>>       <role-name>apiadmin</role-name>
>>     </security-role>
>>
>>
>> It all works great until I send a request to /gateway/* that includes an
>> "Authorization" http header.  If I do that, the adapter tries to
>> authenticate with those credentials and fails with a 401 if they don't
>> match (which they don't).
>>
>> I realize this is an odd case, but I did expect that if the web.xml
>> specified that only /api/* were protected then other paths would simply
>> pass through any Authorization headers.  That may be an incorrect
>> expectation - not sure what the servlet spec requires in this case.
>>
>> Thoughts?
>>
>> Currently I'm probably going to work around this by splitting up the API
>> and Gateway servlets into separate WARs.
>>
>> -Eric
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

From John.Schneider at carrier.utc.com  Fri Dec 12 14:09:18 2014
From: John.Schneider at carrier.utc.com (Schneider, John            DODGE CONSULTING SERVICES, LLC)
Date: Fri, 12 Dec 2014 19:09:18 +0000
Subject: [keycloak-user] [External] Re:  1.1 Beta2 in Wildfly cluster
References: <D5998B55A61D334EA803FEB70395CFD70B0F34CF@UUSNWE3K.na.utcmail.com>
	<548AD7CB.702@redhat.com> 
Message-ID: <D5998B55A61D334EA803FEB70395CFD70B0F3ACA@UUSNWE3K.na.utcmail.com>

I now have it working with my firewall enabled.  The Wildfly config is socket-binding with name ?jgroups-udp?.  For an HA domain cluster, this is within socket-binding-group ?ha-sockets?.  Default values are UDP port 55200 and multicast port 45688 with multicast address 230.0.0.4.  I think it would be helpful to mention this in the Keycloak docs.  The Wildfly docs for clustering only note information applicable to mod_cluster, which is different than this.

Thanks,
John

From: Schneider, John DODGE CONSULTING SERVICES, LLC
Sent: Friday, December 12, 2014 1:08 PM
To: 'Marek Posolda'; keycloak-user at lists.jboss.org
Subject: RE: [External] Re: [keycloak-user] 1.1 Beta2 in Wildfly cluster

Hi Marek,

Thanks for getting back to me.  I did see the ISPN000094 message you described in my log files, but it didn?t look like the messages you listed.  My messages only noted one node.  After disabling the firewall on both nodes, Keycloak is now working in domain mode with Infinispan providers in my config.  Now I just have to figure out all the ports necessary for JGroups to function correctly.  Once I figure this out, I will respond back.  Hopefully you can add this info to the documentation to help others out in the future.

Thanks again for your help,
John


From: Marek Posolda [mailto:mposolda at redhat.com]
Sent: Friday, December 12, 2014 6:56 AM
To: Schneider, John DODGE CONSULTING SERVICES, LLC; keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>
Subject: [External] Re: [keycloak-user] 1.1 Beta2 in Wildfly cluster

Are you using shared database among both cluster nodes? Also when you start node1 and then start node2, you should see some message similar to this in the log of node1, which indicates that cluster nodes are connected:

wfnode_1 | 11:28:30,888 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-1,shared=udp) ISPN000094: Received new cluster view: [wfnode1/web|1] (2) [wfnode1/web, wfnode2/web]
wfnode_1 | 11:28:33,767 INFO  [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-10,shared=udp) ISPN000094: Received new cluster view: [wfnode1/keycloak|1] (2) [wfnode1/keycloak, wfnode2/keycloak]



For more logging of which provider is used by keycloak-server.json, you can enable DEBUG logging for keycloak in standalone-full.xml (or domain.xml or whatever you are using):

                <logger category="org.keycloak">
                    <level name="DEBUG"/>
                </logger>

Also I think that editing file standalone/configuration/keycloak-server.json is just for standalone, but probably doesn't work for wildfly domain.


Maybe you can first try if cluster works in standalone configuration. If it helps, we can figure the domain later.

Marek

On 10.12.2014 00:57, Schneider, John DODGE CONSULTING SERVICES, LLC wrote:
Hi,

Correction, I *thought* everything was running in Wildfly domain mode.  It turns out I just got lucky by hitting the same server node in my initial test.  After a reboot and further testing today, I?m not able to login to the Keycloak admin console when both nodes in my cluster are running.  After attempting login, I am either taken back to a blank login page, or I see error ?Unknown code, please login again through your application.?  Once in awhile, I can login without error. I should note that I?m using an Apache reverse proxy via mod_cluster.

I see no errors in the server logs.  I do see message ?JBAS010281: Started <x> cache from keycloak container? for each of ?realms?, ?sessions?, ?loginFailures?, ?users?.  So, it looks like my domain config is working.  However, I can?t tell for sure that Keycloak is attempting to use the infinispan caches.  Some additional log output showing the values from keycloak-server.json would be helpful.  I used the CLI to upload ?/profile=full-ha/subsystem=keycloak/auth-server=keycloak-1/:update-server-config(bytes-to-upload=/usr/local/wildfly/domain/configuration/keycloak-server.json~,overwrite=true)?  The response was ?success? and then I restarted Wildfly on both nodes in the cluster.

Has anyone been able to get Keycloak 1.1 Beta 2 working in a wildfly domain, and using mod_cluster?  If so, could you please provide guidance?

Thanks,
John

From: Schneider, John DODGE CONSULTING SERVICES, LLC
Sent: Monday, December 08, 2014 6:43 PM
To: keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>
Subject: 1.1 documentation update for running in domain HA mode

Hi guys,

Thanks so much for getting clustering support working in 1.1.  I have it up and running well in a Wildfly 8 domain setup under the ?full-ha? profile.  One thing that I was pulling my hair out about for a while today were some errors related to Infinispan config.  I figured out that if running in HA cluster, you must include the ?transport? element under the cache-container config (i.e. <transport lock-timeout=?60000? />).  It would be great if you could update Chapter 23 of the documentation to reflect this requirement.

Thanks,
John



_______________________________________________

keycloak-user mailing list

keycloak-user at lists.jboss.org<mailto:keycloak-user at lists.jboss.org>

https://lists.jboss.org/mailman/listinfo/keycloak-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141212/0adb75f2/attachment-0001.html 

From bburke at redhat.com  Sat Dec 13 09:19:02 2014
From: bburke at redhat.com (Bill Burke)
Date: Sat, 13 Dec 2014 09:19:02 -0500
Subject: [keycloak-user] sorry, we were away
Message-ID: <548C4AD6.2000009@redhat.com>

Hey Keycloak community,

Sorry if we were unresponsive last week...We were in Brno for a face to 
face meeting of entire team.  One of us will blog about it next week 
sometime.


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

From bburke at redhat.com  Sat Dec 13 19:49:30 2014
From: bburke at redhat.com (Bill Burke)
Date: Sat, 13 Dec 2014 19:49:30 -0500
Subject: [keycloak-user] Sub-resource authentication (edge case)
In-Reply-To: <548B318B.2060909@redhat.com>
References: <548AE843.1020206@redhat.com> <548B18C2.7080502@redhat.com>
	<548B318B.2060909@redhat.com>
Message-ID: <548CDE9A.3050901@redhat.com>

Its really a problem with wildfly, not keycloak.  Keycloak just 
implements the auth SPI of wildfly.

On 12/12/2014 1:18 PM, Eric Wittmann wrote:
> Well, my understanding is that when configuring via the subsystem in
> wildfly, BASIC was the way to go.  That said, I don't have a particular
> preference.
>
> But is that detail perhaps beside the point?
>
> The /api/* endpoint works exactly as you have described.  In
> standalone.xml I've configured it to enable both bearer token and basic
> auth.  So requests can be sent to /api/* with the Authorization header
> set (bearer token and basic auth credentials both work fine).
>
> The problem comes when sending a request to /gateway/*, which is just a
> servlet.  I can successfully send a request to /gateway/* without an
> Authorization header.  This works (unauthenticated access).  However if
> I send a request to /gateway/* with an Authorization header, then
> keycloak attempts to authenticate.  Even though the web.xml doesn't
> indicate that /gateway/* should be protected.
>
> I was expecting any *unprotected* resources to simply pass through any
> Authorization information, not attempt to actually process it.
>
> Again, this is perhaps an incorrect expectation on my part.
>
> -Eric
>
> On 12/12/2014 11:33 AM, Marek Posolda wrote:
>> Hi,
>>
>> if you want to use keycloak for authentication you should rather use:
>>
>> <auth-method>KEYCLOAK</auth-method>
>>
>> Also I don't know how are you sending request to "/api/*" . I guess it
>> is javascript application or some other servlet application, which is
>> sending jax-rs requests to api? In this cases, you should add manually
>> "Authorization" header with either "Authorization: Bearer ..." with
>> bearer token attached or "Authorization: Basic ...." with keycloak
>> username/password attached (bearer token is much better, so you can
>> avoid direct grant and you don't need to share credentials with your
>> application)
>>
>> Marek
>>
>> On 12.12.2014 14:06, Eric Wittmann wrote:
>>> In apiman I have a bit of an edge case that currently isn't working as I
>>> was hoping (running in wildfly 8.2 - not tested on any other platform).
>>>
>>> The issue is that I have a WAR with two sub-contexts:
>>>
>>> /api - JAX-RS endpoints to configure the API Gateway
>>> /gateway - the API Gateway (reverse proxy)
>>>
>>> I wanted /api to be protected by keycloak, but for /gateway to be
>>> unprotected.
>>>
>>> My web.xml looks like this:
>>>
>>>      <security-constraint>
>>>        <web-resource-collection>
>>>          <web-resource-name>apiman-gateway</web-resource-name>
>>>          <url-pattern>/api/*</url-pattern>
>>>        </web-resource-collection>
>>>        <auth-constraint>
>>>          <role-name>apiadmin</role-name>
>>>        </auth-constraint>
>>>      </security-constraint>
>>>      <login-config>
>>>        <auth-method>BASIC</auth-method>
>>>        <realm-name>apiman</realm-name>
>>>      </login-config>
>>>      <security-role>
>>>        <role-name>apiadmin</role-name>
>>>      </security-role>
>>>
>>>
>>> It all works great until I send a request to /gateway/* that includes an
>>> "Authorization" http header.  If I do that, the adapter tries to
>>> authenticate with those credentials and fails with a 401 if they don't
>>> match (which they don't).
>>>
>>> I realize this is an odd case, but I did expect that if the web.xml
>>> specified that only /api/* were protected then other paths would simply
>>> pass through any Authorization headers.  That may be an incorrect
>>> expectation - not sure what the servlet spec requires in this case.
>>>
>>> Thoughts?
>>>
>>> Currently I'm probably going to work around this by splitting up the API
>>> and Gateway servlets into separate WARs.
>>>
>>> -Eric
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

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

From h.p.przybysz at gmail.com  Sun Dec 14 11:36:49 2014
From: h.p.przybysz at gmail.com (Hubert Przybysz)
Date: Sun, 14 Dec 2014 17:36:49 +0100
Subject: [keycloak-user] How to add users in bulk
Message-ID: <CAJMEJTXDvbGDYxvEmMz1pS3NWETadBWThxeLHeorC-0mOwLvHQ@mail.gmail.com>

Hi,
Is there an easy way of adding a large number users to a realm, where
usernames and initial passwords follow a certain pattern?
Best regards / Hubert.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141214/576229aa/attachment.html 

From stian at redhat.com  Mon Dec 15 04:21:14 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 15 Dec 2014 04:21:14 -0500 (EST)
Subject: [keycloak-user] Key Cloak Support
In-Reply-To: <OF7C936745.C6A1BC1E-ON85257DAB.007B7C18-85257DAB.007BBE20@uscmail.uscourts.gov>
References: <OF7C936745.C6A1BC1E-ON85257DAB.007B7C18-85257DAB.007BBE20@uscmail.uscourts.gov>
Message-ID: <1160679035.17713197.1418635274833.JavaMail.zimbra@redhat.com>

Hi Luke,

There's currently no commercial support for Keycloak, but it's something we're working towards.

I've added Divya Mehra and Boles?aw Dawidowicz in CC as they may be able to provide more details.

Stian Thorgersen

----- Original Message -----
> From: "Luke Adams" <Luke_Adams at ao.uscourts.gov>
> To: keycloak-user at lists.jboss.org
> Sent: Thursday, 11 December, 2014 11:31:36 PM
> Subject: [keycloak-user] Key Cloak Support
> 
> Does anyone know if there is a commercial company supporting Key Cloak?
> 
> Luke
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user


From stian at redhat.com  Mon Dec 15 05:08:54 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 15 Dec 2014 05:08:54 -0500 (EST)
Subject: [keycloak-user] How to get an access code via rest service
In-Reply-To: <94ea471b-22f4-416c-9d9e-727029ae58bb@me.com>
References: <94ea471b-22f4-416c-9d9e-727029ae58bb@me.com>
Message-ID: <213058213.17732949.1418638134874.JavaMail.zimbra@redhat.com>

That's an interesting use-case. There's no rest endpoints to retrieve access codes, only authorization tokens which you don't really want to send as a URL query parameter.

For a SSO solution between your fat client and the web apps the solutions I can think of are:

* Use browser to login fat client - we have cli examples that do this
* Use Kerberos - this is more complicated and we only plan to add support to authenticate via Kerberos tickets, not to issue tickets ourselves

We have discussed the idea of adding an identity token to direct grant api. The idea was that a cli (or fat client) could use the direct grant to obtain an identity token (token for a sso session), which could be stored somewhere on the local file-system. This token could then be used by other apps to retrieve authorization tokens without having to provide user credentials. Maybe this idea could somehow be used by web apps as well, by passing something in the url param.

----- Original Message -----
> From: "Michael Gerber" <gerbermichi at me.com>
> To: keycloak-user at lists.jboss.org
> Sent: Tuesday, 9 December, 2014 4:56:05 PM
> Subject: [keycloak-user] How to get an access code via rest service
> 
> Hi,
> 
> I've got a fat client and a web application.
> My client wants to get an access code to open a new browser with these access
> code as URL parameter, so the users are directly logged in without
> reentering their credentials.
> 
> Thank you for your help!
> 
> kind regards
> Michael
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

From jayblanc at gmail.com  Mon Dec 15 09:13:06 2014
From: jayblanc at gmail.com (=?UTF-8?B?SsOpcsO0bWUgQmxhbmNoYXJk?=)
Date: Mon, 15 Dec 2014 14:13:06 +0000
Subject: [keycloak-user] HTML5/JS and download URL.
Message-ID: <CAPNq5vY2NO8RHE_C5=OSmtAEL_+0xYLudiY84M7goi4o+WmDbQ@mail.gmail.com>

Hi all,
We have a use case where an HTML5/Angular application is calling a REST
interface using keycloak for authentication SSO. Everything works fine
until we need to download files or preview images (using <img> tag). In
both case, this is the browser which perform the request on the REST url
and, because of a specific XHR authentication putting the bearer token in
the headers, a 'classic' browser request for downloading a file result in
an UNauthenticated request because of unexisting bearer token.

We're minding if there is a best practice to handle this case. We plan to
include a dedicated token as a download request parameter and to check this
particular query paramter programmatically in the /download JAX-RS
operation. What kind of token should have to put in the query and is there
an already existing mechanism to catch such token in jax-rs server-side
operations nor programmatically ?

Thanks a lot for your support and so good work, Best Regards, J?r?me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141215/834acd4f/attachment.html 

From stian at redhat.com  Mon Dec 15 10:49:12 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 15 Dec 2014 10:49:12 -0500 (EST)
Subject: [keycloak-user] HTML5/JS and download URL.
In-Reply-To: <CAPNq5vY2NO8RHE_C5=OSmtAEL_+0xYLudiY84M7goi4o+WmDbQ@mail.gmail.com>
References: <CAPNq5vY2NO8RHE_C5=OSmtAEL_+0xYLudiY84M7goi4o+WmDbQ@mail.gmail.com>
Message-ID: <1315224945.18004787.1418658552122.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "J?r?me Blanchard" <jayblanc at gmail.com>
> To: keycloak-user at lists.jboss.org
> Sent: Monday, 15 December, 2014 3:13:06 PM
> Subject: [keycloak-user] HTML5/JS and download URL.
> 
> Hi all,
> We have a use case where an HTML5/Angular application is calling a REST
> interface using keycloak for authentication SSO. Everything works fine until
> we need to download files or preview images (using <img> tag). In both case,
> this is the browser which perform the request on the REST url and, because
> of a specific XHR authentication putting the bearer token in the headers, a
> 'classic' browser request for downloading a file result in an
> UNauthenticated request because of unexisting bearer token.
> 
> We're minding if there is a best practice to handle this case. We plan to
> include a dedicated token as a download request parameter and to check this
> particular query paramter programmatically in the /download JAX-RS
> operation. What kind of token should have to put in the query and is there
> an already existing mechanism to catch such token in jax-rs server-side
> operations nor programmatically ?

We actually had the same issue in our admin console as we provide a download option for the application config. AFAIK there's two solutions:

* Generate a temporary token - basically what you're suggesting. There's two ways you can do this, always generate one and add it to the link, second is to use a redirect that only generates the token on demand
* Use XHR to get the file, which allows setting the Authorization header, then use JavaScript to download

There's currently no direct support for this in Keycloak, but it would be interesting to add.

> 
> Thanks a lot for your support and so good work, Best Regards, J?r?me.
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user


From stian at redhat.com  Tue Dec 16 06:38:14 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 16 Dec 2014 06:38:14 -0500 (EST)
Subject: [keycloak-user] Merry Christmas from the Keycloak team
In-Reply-To: <1674960151.18619710.1418729886484.JavaMail.zimbra@redhat.com>
Message-ID: <1852578705.18619737.1418729894635.JavaMail.zimbra@redhat.com>

2014 was the year of Keycloak! At least that was the case for us on the Keycloak team. In January we released the very first alpha of the project. The first stable release wasn?t out until September, but in return we added a lot more features as well as reaching a very high level of stability for a 1.0.

Since then we?ve delivered a number of security and bug fixes for 1.0, while continuing to bake in new exiting features for 1.1. We?re planning to do a stable release of 1.1 early in the New Year, which will bring SAML 2, much improved clustering and a number of new application adapters.

Not only have we managed to provide a feature rich and easy to use open source security solution, but we?ve also managed to build an awesome community around the project. We?ve had over 5000 downloads, over 2500 commits from 32 contributors and our developer and user mailing lists are very active. Keycloak is already in use in production on a number of projects, in fact some has even used it in production since our first alpha release!

Our road-map for 2015 is not written in stone, but expect at least some of the following features to be delivered in 2015:

  * Custom user profiles ? this will let you configure the attributes for a user profile, which should be visible on the registration screen and account management, as well as specify validation
  * Identity Brokering ? we?re adding support to authenticate with external Identity Providers via OpenID Connect, SAML 2.0 and Kerberos
  * Two-Factor Authentication ? currently we only support Google Authenticator or FreeOTP applications for two-factor authentication, but we plan to make it possible to add your own and provide some more out of the box
  * Client Accounts ? these will be special user accounts directly linked to a client, allowing a client to access services as itself not just on-behalf of users
  * Client Certificates ? support authentication of clients with certificates
  * Client Types ? at the moment we have applications and oauth clients, the main difference being oauth clients require users to grant permissions to roles. To simplify the admin console we plan to introduce a single unified view for clients and also introduce new types such as devices
  * Internationalization ? internationalization support for login and account management pages
  * SMS ? enable SMS to recover passwords, as a 2nd factor authentication mechanism and to be notified about events like login failures
  * OpenID Connect Dynamic Registration ?  allows clients to dynamically register with Keycloak. We?ll also look at passing the OpenID Connect Interop testing
  * Mapping of users and tokens ? custom mapping of user profiles from external identity stores and tokens from external Identity Providers

We also have ideas for some bigger features, but we?ll leave those as a surprise for 2015!

Finally, I?d like to wish everyone a Merry Christmas and a Happy New Year.


From traviskds at gmail.com  Tue Dec 16 06:40:54 2014
From: traviskds at gmail.com (Travis De Silva)
Date: Tue, 16 Dec 2014 22:40:54 +1100
Subject: [keycloak-user] Merry Christmas from the Keycloak team
In-Reply-To: <1852578705.18619737.1418729894635.JavaMail.zimbra@redhat.com>
References: <1674960151.18619710.1418729886484.JavaMail.zimbra@redhat.com>
	<1852578705.18619737.1418729894635.JavaMail.zimbra@redhat.com>
Message-ID: <CACQJ6LQjFesqxdieFFjZyQgHBTD5+dW4ZxnpHEBixz=2oW4hvw@mail.gmail.com>

Congratulations and thank you to the entire KeyCloak team. This is a great
project and wishing it gets better and better over the course of next year.

Merry Christmas and Happy New Year to everyone.

On Tue, Dec 16, 2014 at 10:38 PM, Stian Thorgersen <stian at redhat.com> wrote:

> 2014 was the year of Keycloak! At least that was the case for us on the
> Keycloak team. In January we released the very first alpha of the project.
> The first stable release wasn?t out until September, but in return we added
> a lot more features as well as reaching a very high level of stability for
> a 1.0.
>
> Since then we?ve delivered a number of security and bug fixes for 1.0,
> while continuing to bake in new exiting features for 1.1. We?re planning to
> do a stable release of 1.1 early in the New Year, which will bring SAML 2,
> much improved clustering and a number of new application adapters.
>
> Not only have we managed to provide a feature rich and easy to use open
> source security solution, but we?ve also managed to build an awesome
> community around the project. We?ve had over 5000 downloads, over 2500
> commits from 32 contributors and our developer and user mailing lists are
> very active. Keycloak is already in use in production on a number of
> projects, in fact some has even used it in production since our first alpha
> release!
>
> Our road-map for 2015 is not written in stone, but expect at least some of
> the following features to be delivered in 2015:
>
>   * Custom user profiles ? this will let you configure the attributes for
> a user profile, which should be visible on the registration screen and
> account management, as well as specify validation
>   * Identity Brokering ? we?re adding support to authenticate with
> external Identity Providers via OpenID Connect, SAML 2.0 and Kerberos
>   * Two-Factor Authentication ? currently we only support Google
> Authenticator or FreeOTP applications for two-factor authentication, but we
> plan to make it possible to add your own and provide some more out of the
> box
>   * Client Accounts ? these will be special user accounts directly linked
> to a client, allowing a client to access services as itself not just
> on-behalf of users
>   * Client Certificates ? support authentication of clients with
> certificates
>   * Client Types ? at the moment we have applications and oauth clients,
> the main difference being oauth clients require users to grant permissions
> to roles. To simplify the admin console we plan to introduce a single
> unified view for clients and also introduce new types such as devices
>   * Internationalization ? internationalization support for login and
> account management pages
>   * SMS ? enable SMS to recover passwords, as a 2nd factor authentication
> mechanism and to be notified about events like login failures
>   * OpenID Connect Dynamic Registration ?  allows clients to dynamically
> register with Keycloak. We?ll also look at passing the OpenID Connect
> Interop testing
>   * Mapping of users and tokens ? custom mapping of user profiles from
> external identity stores and tokens from external Identity Providers
>
> We also have ideas for some bigger features, but we?ll leave those as a
> surprise for 2015!
>
> Finally, I?d like to wish everyone a Merry Christmas and a Happy New Year.
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141216/503430a2/attachment-0001.html 

From mposolda at redhat.com  Tue Dec 16 08:23:23 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 16 Dec 2014 14:23:23 +0100
Subject: [keycloak-user] [External] Re:  1.1 Beta2 in Wildfly cluster
In-Reply-To: <D5998B55A61D334EA803FEB70395CFD70B0F3ACA@UUSNWE3K.na.utcmail.com>
References: <D5998B55A61D334EA803FEB70395CFD70B0F34CF@UUSNWE3K.na.utcmail.com>
	<548AD7CB.702@redhat.com>
	<D5998B55A61D334EA803FEB70395CFD70B0F3ACA@UUSNWE3K.na.utcmail.com>
Message-ID: <5490324B.30400@redhat.com>

Thanks, I've added small "troubleshooting" section to our clustering 
docs and mentioned this info here.

Cheers,
Marek

On 12.12.2014 20:09, Schneider, John DODGE CONSULTING SERVICES, LLC wrote:
>
> I now have it working with my firewall enabled.  The Wildfly config is 
> socket-binding with name ?jgroups-udp?.  For an HA domain cluster, 
> this is within socket-binding-group ?ha-sockets?. Default values are 
> UDP port 55200 and multicast port 45688 with multicast address 
> 230.0.0.4.  I think it would be helpful to mention this in the 
> Keycloak docs.  The Wildfly docs for clustering only note information 
> applicable to mod_cluster, which is different than this.
>
> Thanks,
>
> John
>
> *From:*Schneider, John DODGE CONSULTING SERVICES, LLC
> *Sent:* Friday, December 12, 2014 1:08 PM
> *To:* 'Marek Posolda'; keycloak-user at lists.jboss.org
> *Subject:* RE: [External] Re: [keycloak-user] 1.1 Beta2 in Wildfly cluster
>
> Hi Marek,
>
> Thanks for getting back to me.  I did see the ISPN000094 message you 
> described in my log files, but it didn?t look like the messages you 
> listed.  My messages only noted one node. After disabling the firewall 
> on both nodes, Keycloak is now working in domain mode with Infinispan 
> providers in my config.  Now I just have to figure out all the ports 
> necessary for JGroups to function correctly.  Once I figure this out, 
> I will respond back.  Hopefully you can add this info to the 
> documentation to help others out in the future.
>
> Thanks again for your help,
>
> John
>
> *From:*Marek Posolda [mailto:mposolda at redhat.com]
> *Sent:* Friday, December 12, 2014 6:56 AM
> *To:* Schneider, John DODGE CONSULTING SERVICES, LLC; 
> keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
> *Subject:* [External] Re: [keycloak-user] 1.1 Beta2 in Wildfly cluster
>
> Are you using shared database among both cluster nodes? Also when you 
> start node1 and then start node2, you should see some message similar 
> to this in the log of node1, which indicates that cluster nodes are 
> connected:
>
> wfnode_1 | 11:28:30,888 INFO 
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport] 
> (Incoming-1,shared=udp) ISPN000094: Received new cluster view: 
> [wfnode1/web|1] (2) [wfnode1/web, wfnode2/web]
> wfnode_1 | 11:28:33,767 INFO 
> [org.infinispan.remoting.transport.jgroups.JGroupsTransport] 
> (Incoming-10,shared=udp) ISPN000094: Received new cluster view: 
> [wfnode1/keycloak|1] (2) [wfnode1/keycloak, wfnode2/keycloak]
>
>
>
> For more logging of which provider is used by keycloak-server.json, 
> you can enable DEBUG logging for keycloak in standalone-full.xml (or 
> domain.xml or whatever you are using):
>
>                 <logger category="org.keycloak">
>                     <level name="DEBUG"/>
>                 </logger>
>
> Also I think that editing file 
> |standalone/configuration/keycloak-server.json is just for standalone, 
> but probably doesn't work for wildfly domain.|
>
>
> Maybe you can first try if cluster works in standalone configuration. 
> If it helps, we can figure the domain later.
>
> Marek
>
> On 10.12.2014 00:57, Schneider, John DODGE CONSULTING SERVICES, LLC wrote:
>
>     Hi,
>
>     Correction, I **thought** everything was running in Wildfly domain
>     mode.  It turns out I just got lucky by hitting the same server
>     node in my initial test.  After a reboot and further testing
>     today, I?m not able to login to the Keycloak admin console when
>     both nodes in my cluster are running.  After attempting login, I
>     am either taken back to a blank login page, or I see error
>     ?Unknown code, please login again through your application.?  Once
>     in awhile, I can login without error. I should note that I?m using
>     an Apache reverse proxy via mod_cluster.
>
>     I see no errors in the server logs.  I do see message ?JBAS010281:
>     Started <x> cache from keycloak container? for each of ?realms?,
>     ?sessions?, ?loginFailures?, ?users?.  So, it looks like my domain
>     config is working.  However, I can?t tell for sure that Keycloak
>     is attempting to use the infinispan caches.  Some additional log
>     output showing the values from keycloak-server.json would be
>     helpful.  I used the CLI to upload
>     ?/profile=full-ha/subsystem=keycloak/auth-server=keycloak-1/:update-server-config(bytes-to-upload=/usr/local/wildfly/domain/configuration/keycloak-server.json~,overwrite=true)?
>     The response was ?success? and then I restarted Wildfly on both
>     nodes in the cluster.
>
>     Has anyone been able to get Keycloak 1.1 Beta 2 working in a
>     wildfly domain, and using mod_cluster?  If so, could you please
>     provide guidance?
>
>     Thanks,
>
>     John
>
>     *From:*Schneider, John DODGE CONSULTING SERVICES, LLC
>     *Sent:* Monday, December 08, 2014 6:43 PM
>     *To:* keycloak-user at lists.jboss.org
>     <mailto:keycloak-user at lists.jboss.org>
>     *Subject:* 1.1 documentation update for running in domain HA mode
>
>     Hi guys,
>
>     Thanks so much for getting clustering support working in 1.1.  I
>     have it up and running well in a Wildfly 8 domain setup under the
>     ?full-ha? profile.  One thing that I was pulling my hair out about
>     for a while today were some errors related to Infinispan config. 
>     I figured out that if running in HA cluster, you must include the
>     ?transport? element under the cache-container config (i.e.
>     <transport lock-timeout=?60000? />).  It would be great if you
>     could update Chapter 23 of the documentation to reflect this
>     requirement.
>
>     Thanks,
>
>     John
>
>
>
>     _______________________________________________
>
>     keycloak-user mailing list
>
>     keycloak-user at lists.jboss.org  <mailto:keycloak-user at lists.jboss.org>
>
>     https://lists.jboss.org/mailman/listinfo/keycloak-user
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141216/e2de8825/attachment.html 

From n.preusker at gmail.com  Tue Dec 16 08:55:37 2014
From: n.preusker at gmail.com (Nils Preusker)
Date: Tue, 16 Dec 2014 14:55:37 +0100
Subject: [keycloak-user] IE9 compatibility
Message-ID: <CA+HCLu8pxFx3EDXJy3ZXdC4b6_2P+6Cro2G8cvCU+3rTqizUsQ@mail.gmail.com>

Hi all,

we are currently in the process of going live with a web application that
uses keycloak. During our initial tests we encountered and fixed some
issues with Internet Explorer 9.

Since the changes we applied don't require any API changes and only address
the way keycloak.js communicates with the embedded login status iframe
(login-status-iframe.html), we'd love to see a 1.0.5.Final release with our
patch (see attachment).

In addition to the patch, we added the following HTML5 cross browser
polyfills:
* https://github.com/davidchambers/Base64.js
* https://github.com/devote/HTML5-History-API

Let me know if you have any additional questions!

Cheers,
Nils
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141216/001e6948/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ie9.patch
Type: application/octet-stream
Size: 2410 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-user/attachments/20141216/001e6948/attachment.obj 

From stian at redhat.com  Tue Dec 16 09:02:29 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 16 Dec 2014 09:02:29 -0500 (EST)
Subject: [keycloak-user] IE9 compatibility
In-Reply-To: <CA+HCLu8pxFx3EDXJy3ZXdC4b6_2P+6Cro2G8cvCU+3rTqizUsQ@mail.gmail.com>
References: <CA+HCLu8pxFx3EDXJy3ZXdC4b6_2P+6Cro2G8cvCU+3rTqizUsQ@mail.gmail.com>
Message-ID: <1317019018.18856885.1418738549183.JavaMail.zimbra@redhat.com>

Looks good, any chance you can do a PR on GitHub? If that's not convenient for you I can apply the patch manually.

We can add a reference to those polyfills in our documentation.

----- Original Message -----
> From: "Nils Preusker" <n.preusker at gmail.com>
> To: keycloak-user at lists.jboss.org
> Sent: Tuesday, 16 December, 2014 2:55:37 PM
> Subject: [keycloak-user] IE9 compatibility
> 
> Hi all,
> 
> we are currently in the process of going live with a web application that
> uses keycloak. During our initial tests we encountered and fixed some issues
> with Internet Explorer 9.
> 
> Since the changes we applied don't require any API changes and only address
> the way keycloak.js communicates with the embedded login status iframe
> (login-status-iframe.html), we'd love to see a 1.0.5.Final release with our
> patch (see attachment).
> 
> In addition to the patch, we added the following HTML5 cross browser
> polyfills:
> * https://github.com/davidchambers/Base64.js
> * https://github.com/devote/HTML5-History-API
> 
> Let me know if you have any additional questions!
> 
> Cheers,
> Nils
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

From n.preusker at gmail.com  Tue Dec 16 09:28:50 2014
From: n.preusker at gmail.com (Nils Preusker)
Date: Tue, 16 Dec 2014 15:28:50 +0100
Subject: [keycloak-user] IE9 compatibility
In-Reply-To: <1317019018.18856885.1418738549183.JavaMail.zimbra@redhat.com>
References: <CA+HCLu8pxFx3EDXJy3ZXdC4b6_2P+6Cro2G8cvCU+3rTqizUsQ@mail.gmail.com>
	<1317019018.18856885.1418738549183.JavaMail.zimbra@redhat.com>
Message-ID: <CA+HCLu-Jmx9Z9te=dt+EOvyxoXNxE_pqNfOsP-YrYH4wDKBxGg@mail.gmail.com>

Hey Stian,

no problem, I'm just not sure which branch I should use as target for the
pull request.

...master and you create the 1.0.5.Final Tag with cherry-pick?

Cheers,
Nils

On Tue, Dec 16, 2014 at 3:02 PM, Stian Thorgersen <stian at redhat.com> wrote:
>
> Looks good, any chance you can do a PR on GitHub? If that's not convenient
> for you I can apply the patch manually.
>
> We can add a reference to those polyfills in our documentation.
>
> ----- Original Message -----
> > From: "Nils Preusker" <n.preusker at gmail.com>
> > To: keycloak-user at lists.jboss.org
> > Sent: Tuesday, 16 December, 2014 2:55:37 PM
> > Subject: [keycloak-user] IE9 compatibility
> >
> > Hi all,
> >
> > we are currently in the process of going live with a web application that
> > uses keycloak. During our initial tests we encountered and fixed some
> issues
> > with Internet Explorer 9.
> >
> > Since the changes we applied don't require any API changes and only
> address
> > the way keycloak.js communicates with the embedded login status iframe
> > (login-status-iframe.html), we'd love to see a 1.0.5.Final release with
> our
> > patch (see attachment).
> >
> > In addition to the patch, we added the following HTML5 cross browser
> > polyfills:
> > * https://github.com/davidchambers/Base64.js
> > * https://github.com/devote/HTML5-History-API
> >
> > Let me know if you have any additional questions!
> >
> > Cheers,
> > Nils
> >
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141216/489e59d7/attachment.html 

From stian at redhat.com  Tue Dec 16 09:28:54 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 16 Dec 2014 09:28:54 -0500 (EST)
Subject: [keycloak-user] IE9 compatibility
In-Reply-To: <1317019018.18856885.1418738549183.JavaMail.zimbra@redhat.com>
References: <CA+HCLu8pxFx3EDXJy3ZXdC4b6_2P+6Cro2G8cvCU+3rTqizUsQ@mail.gmail.com>
	<1317019018.18856885.1418738549183.JavaMail.zimbra@redhat.com>
Message-ID: <2107088863.18886723.1418740134013.JavaMail.zimbra@redhat.com>

BTW we don't have any plans for a 1.0.5.Final, instead 1.1.0.Final should be out in January.

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Nils Preusker" <n.preusker at gmail.com>
> Cc: keycloak-user at lists.jboss.org
> Sent: Tuesday, 16 December, 2014 3:02:29 PM
> Subject: Re: [keycloak-user] IE9 compatibility
> 
> Looks good, any chance you can do a PR on GitHub? If that's not convenient
> for you I can apply the patch manually.
> 
> We can add a reference to those polyfills in our documentation.
> 
> ----- Original Message -----
> > From: "Nils Preusker" <n.preusker at gmail.com>
> > To: keycloak-user at lists.jboss.org
> > Sent: Tuesday, 16 December, 2014 2:55:37 PM
> > Subject: [keycloak-user] IE9 compatibility
> > 
> > Hi all,
> > 
> > we are currently in the process of going live with a web application that
> > uses keycloak. During our initial tests we encountered and fixed some
> > issues
> > with Internet Explorer 9.
> > 
> > Since the changes we applied don't require any API changes and only address
> > the way keycloak.js communicates with the embedded login status iframe
> > (login-status-iframe.html), we'd love to see a 1.0.5.Final release with our
> > patch (see attachment).
> > 
> > In addition to the patch, we added the following HTML5 cross browser
> > polyfills:
> > * https://github.com/davidchambers/Base64.js
> > * https://github.com/devote/HTML5-History-API
> > 
> > Let me know if you have any additional questions!
> > 
> > Cheers,
> > Nils
> > 
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
> 

From stian at redhat.com  Tue Dec 16 09:39:49 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 16 Dec 2014 09:39:49 -0500 (EST)
Subject: [keycloak-user] IE9 compatibility
In-Reply-To: <CA+HCLu-Jmx9Z9te=dt+EOvyxoXNxE_pqNfOsP-YrYH4wDKBxGg@mail.gmail.com>
References: <CA+HCLu8pxFx3EDXJy3ZXdC4b6_2P+6Cro2G8cvCU+3rTqizUsQ@mail.gmail.com>
	<1317019018.18856885.1418738549183.JavaMail.zimbra@redhat.com>
	<CA+HCLu-Jmx9Z9te=dt+EOvyxoXNxE_pqNfOsP-YrYH4wDKBxGg@mail.gmail.com>
Message-ID: <948281461.18908729.1418740789743.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Nils Preusker" <n.preusker at gmail.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-user at lists.jboss.org
> Sent: Tuesday, 16 December, 2014 3:28:50 PM
> Subject: Re: [keycloak-user] IE9 compatibility
> 
> Hey Stian,
> 
> no problem, I'm just not sure which branch I should use as target for the
> pull request.
> 
> ...master and you create the 1.0.5.Final Tag with cherry-pick?

Master - afraid we can't do a 1.0.5.Final just for this fix, especially not when 1.1.0.Final will be released soon

> 
> Cheers,
> Nils
> 
> On Tue, Dec 16, 2014 at 3:02 PM, Stian Thorgersen <stian at redhat.com> wrote:
> >
> > Looks good, any chance you can do a PR on GitHub? If that's not convenient
> > for you I can apply the patch manually.
> >
> > We can add a reference to those polyfills in our documentation.
> >
> > ----- Original Message -----
> > > From: "Nils Preusker" <n.preusker at gmail.com>
> > > To: keycloak-user at lists.jboss.org
> > > Sent: Tuesday, 16 December, 2014 2:55:37 PM
> > > Subject: [keycloak-user] IE9 compatibility
> > >
> > > Hi all,
> > >
> > > we are currently in the process of going live with a web application that
> > > uses keycloak. During our initial tests we encountered and fixed some
> > issues
> > > with Internet Explorer 9.
> > >
> > > Since the changes we applied don't require any API changes and only
> > address
> > > the way keycloak.js communicates with the embedded login status iframe
> > > (login-status-iframe.html), we'd love to see a 1.0.5.Final release with
> > our
> > > patch (see attachment).
> > >
> > > In addition to the patch, we added the following HTML5 cross browser
> > > polyfills:
> > > * https://github.com/davidchambers/Base64.js
> > > * https://github.com/devote/HTML5-History-API
> > >
> > > Let me know if you have any additional questions!
> > >
> > > Cheers,
> > > Nils
> > >
> > > _______________________________________________
> > > keycloak-user mailing list
> > > keycloak-user at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
> 

From n.preusker at gmail.com  Tue Dec 16 10:17:07 2014
From: n.preusker at gmail.com (Nils Preusker)
Date: Tue, 16 Dec 2014 16:17:07 +0100
Subject: [keycloak-user] IE9 compatibility
In-Reply-To: <948281461.18908729.1418740789743.JavaMail.zimbra@redhat.com>
References: <CA+HCLu8pxFx3EDXJy3ZXdC4b6_2P+6Cro2G8cvCU+3rTqizUsQ@mail.gmail.com>
	<1317019018.18856885.1418738549183.JavaMail.zimbra@redhat.com>
	<CA+HCLu-Jmx9Z9te=dt+EOvyxoXNxE_pqNfOsP-YrYH4wDKBxGg@mail.gmail.com>
	<948281461.18908729.1418740789743.JavaMail.zimbra@redhat.com>
Message-ID: <CA+HCLu9Tv7-mmHRgUEX34Oop3XY0ptEamRBh5_4CY-ho45i58Q@mail.gmail.com>

No problem, 1.1.0.Final in January will do!

Here's the pull request:
https://github.com/keycloak/keycloak/pull/891

Thanks!
Nils

On Tue, Dec 16, 2014 at 3:39 PM, Stian Thorgersen <stian at redhat.com> wrote:
>
>
>
> ----- Original Message -----
> > From: "Nils Preusker" <n.preusker at gmail.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-user at lists.jboss.org
> > Sent: Tuesday, 16 December, 2014 3:28:50 PM
> > Subject: Re: [keycloak-user] IE9 compatibility
> >
> > Hey Stian,
> >
> > no problem, I'm just not sure which branch I should use as target for the
> > pull request.
> >
> > ...master and you create the 1.0.5.Final Tag with cherry-pick?
>
> Master - afraid we can't do a 1.0.5.Final just for this fix, especially
> not when 1.1.0.Final will be released soon
>
> >
> > Cheers,
> > Nils
> >
> > On Tue, Dec 16, 2014 at 3:02 PM, Stian Thorgersen <stian at redhat.com>
> wrote:
> > >
> > > Looks good, any chance you can do a PR on GitHub? If that's not
> convenient
> > > for you I can apply the patch manually.
> > >
> > > We can add a reference to those polyfills in our documentation.
> > >
> > > ----- Original Message -----
> > > > From: "Nils Preusker" <n.preusker at gmail.com>
> > > > To: keycloak-user at lists.jboss.org
> > > > Sent: Tuesday, 16 December, 2014 2:55:37 PM
> > > > Subject: [keycloak-user] IE9 compatibility
> > > >
> > > > Hi all,
> > > >
> > > > we are currently in the process of going live with a web application
> that
> > > > uses keycloak. During our initial tests we encountered and fixed some
> > > issues
> > > > with Internet Explorer 9.
> > > >
> > > > Since the changes we applied don't require any API changes and only
> > > address
> > > > the way keycloak.js communicates with the embedded login status
> iframe
> > > > (login-status-iframe.html), we'd love to see a 1.0.5.Final release
> with
> > > our
> > > > patch (see attachment).
> > > >
> > > > In addition to the patch, we added the following HTML5 cross browser
> > > > polyfills:
> > > > * https://github.com/davidchambers/Base64.js
> > > > * https://github.com/devote/HTML5-History-API
> > > >
> > > > Let me know if you have any additional questions!
> > > >
> > > > Cheers,
> > > > Nils
> > > >
> > > > _______________________________________________
> > > > keycloak-user mailing list
> > > > keycloak-user at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/keycloak-user
> > >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141216/0bc63f71/attachment.html 

From rubenlop88 at gmail.com  Tue Dec 16 11:18:04 2014
From: rubenlop88 at gmail.com (Ruben Lopez)
Date: Tue, 16 Dec 2014 16:18:04 +0000
Subject: [keycloak-user] Questions about keycloak
References: <CA+L_nNiTRZ2ySW7+XG-5461nmdi0XXuNV=foOBXugO-chcFNcw@mail.gmail.com>
	<54774560.8050809@redhat.com>
	<CA+L_nNiYQm4FRXGehR4n331dETJsdAv4Mis_VJSE=op3uZPo3g@mail.gmail.com>
	<2084644196.7048027.1417161849834.JavaMail.zimbra@redhat.com>
	<CA+L_nNh_C3c_fw_+jP8vhyVsMVt50AEYWDUVfdW2XZoytDXg_w@mail.gmail.com>
	<548AB8DC.4070207@redhat.com>
Message-ID: <CA+L_nNgkTq9YxtJHcPE1ff7bJTVsMY1sF0vR0M3sY5-2FUfYQw@mail.gmail.com>

Thanks for the quick answers!

I couldn't find documentation about how to install Keycloak 1.0 in a
clustered environment. I know that Keycloak 1.1 does have documentation
about this but it is still in beta and the company I work for needs to know
if there is a similar mechanism that can be implemented with Keycloak 1.0.

El Fri Dec 12 2014 at 6:44:00 AM, Marek Posolda <mposolda at redhat.com>
escribi?:

> On 11.12.2014 18:07, Ruben Lopez wrote:
>
> I have a couple more questions.
>
>  1) Will you implement the features requested in KEYCLOAK-402 and
> KEYCLOAK-405? If so, when?
>
> Hard to say exactly, but looks that it will be quite soon as it is
> requirement from more people and potential customers . Hopefully in terms
> of weeks/months, but hard to promise exact date... I think it would require
> enhance our existing password policies, but those would be a bit harder to
> add than current simple policies as it will also require to store some info
> in database (like password expiration time and older passwords)
>
>   2) Are there any plans to support Integrated Windows Authentication?
>
> You mean login to KC when user is already logged in windows domain? Yes,
> we have plan for add Kerberos/spnego soon and I think that it should solve
> windows domain authentication too. Hopefully around January.
>
>
> Marek
>
>
>  Thanks :)
>
> 2014-11-28 5:04 GMT-03:00 Stian Thorgersen <stian at redhat.com>:
>
>>
>>
>> ----- Original Message -----
>> > From: "Ruben Lopez" <rubenlop88 at gmail.com>
>> > To: "Marek Posolda" <mposolda at redhat.com>
>> > Cc: keycloak-user at lists.jboss.org
>> > Sent: Thursday, 27 November, 2014 5:37:45 PM
>> > Subject: Re: [keycloak-user] Questions about keycloak
>> >
>> > Hi Marek,
>> >
>> > 2014-11-27 12:38 GMT-03:00 Marek Posolda < mposolda at redhat.com > :
>> >
>> >
>> >
>> >
>> >
>> > 1 - Is there any way to obtain an access token for an OAuth Client via
>> Client
>> > Credentials[1]?
>> > You mean something like Service account like this from OAuth2 specs
>> > http://tools.ietf.org/html/rfc6749#page-40 ? We don't have that yet,
>> but
>> > there are plans to support it afaik.
>> >
>> >
>> >
>> >
>> > Yes, I was talking about secction 4.4 Client Credentials Grant. Any idea
>> > about when it will be implemented?
>>
>> I can't give you and exact date, but it's becoming more and more of a
>> priority so should be within a few months. We also plan to add cert based
>> authentication for clients.
>>
>> In the mean-time you can work-around this issue by creating a user on
>> behalf of the client and use Resource Owner Password Credentials Grant
>> (section #4.3). Look at 'examples/preconfigured-demo/admin-access' in the
>> download for an example.
>>
>> >
>> >
>> >
>> >
>> >
>> >
>> > 2 - If we make a request to an Application (Resource Server) with an
>> access
>> > token and this Application needs to talk to another protected
>> Application to
>> > form the response to the client, how does the first Application
>> > authenticates to the second Application? Does Keycloak implements
>> something
>> > like Chain Grant Type Profile[2]?
>> > yes, that is doable. We have an example where we have frontend
>> application
>> > like 'customer-portal', which is able to retrieve accessToken from
>> keycloak
>> > like here:
>> >
>> https://github.com/keycloak/keycloak/blob/master/examples/demo-template/customer-app/src/main/java/org/keycloak/example/CustomerDatabaseClient.java#L48
>> > and then use this accessToken to send request to backend application
>> > 'database-service' in Authorization header
>> >
>> https://github.com/keycloak/keycloak/blob/master/examples/demo-template/customer-app/src/main/java/org/keycloak/example/CustomerDatabaseClient.java#L54
>> > . Database-service is then able to authenticate the token.
>> >
>> > Currently our database-service is directly serving requests and send
>> back
>> > data, but it shouldn't be a problem to add another application to the
>> chain,
>> > so that database-service will send the token again to another app like
>> > 'real-database-service', which will return data and those data will be
>> sent
>> > back to the original frontent requestor (customer-portal). Is it
>> something
>> > what you meant?
>> >
>> > Thats exactly what I meant. I will take a look at the example.
>> >
>> > Thank you very much.
>> >
>> >
>> >
>> >
>> >
>> > Marek
>> >
>> >
>> >
>> >
>> > Thanks in advance.
>> >
>> >
>> > _______________________________________________
>> > keycloak-user mailing list keycloak-user at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>> >
>> >
>> >
>> > _______________________________________________
>> > keycloak-user mailing list
>> > keycloak-user at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141216/3b69c879/attachment-0001.html 

From jayblanc at gmail.com  Tue Dec 16 11:51:37 2014
From: jayblanc at gmail.com (=?UTF-8?B?SsOpcsO0bWUgQmxhbmNoYXJk?=)
Date: Tue, 16 Dec 2014 17:51:37 +0100
Subject: [keycloak-user] HTML5/JS and download URL.
In-Reply-To: <1315224945.18004787.1418658552122.JavaMail.zimbra@redhat.com>
References: <CAPNq5vY2NO8RHE_C5=OSmtAEL_+0xYLudiY84M7goi4o+WmDbQ@mail.gmail.com>
	<1315224945.18004787.1418658552122.JavaMail.zimbra@redhat.com>
Message-ID: <CAPNq5vYjeQhB0KFiPOzv6u+P-iuR5nV4W8SjfdHF3kvgpFKYcQ@mail.gmail.com>

Hi,

Thank you for your answer. Sorry for my lake of knowledge in OAuth but
speaking about generating a temporary token to include in the link, what
kind of token do you mean and what is the best way to do that with Keycloak.

Best regards, J?r?me.

2014-12-15 16:49 GMT+01:00 Stian Thorgersen <stian at redhat.com>:
>
>
>
> ----- Original Message -----
> > From: "J?r?me Blanchard" <jayblanc at gmail.com>
> > To: keycloak-user at lists.jboss.org
> > Sent: Monday, 15 December, 2014 3:13:06 PM
> > Subject: [keycloak-user] HTML5/JS and download URL.
> >
> > Hi all,
> > We have a use case where an HTML5/Angular application is calling a REST
> > interface using keycloak for authentication SSO. Everything works fine
> until
> > we need to download files or preview images (using <img> tag). In both
> case,
> > this is the browser which perform the request on the REST url and,
> because
> > of a specific XHR authentication putting the bearer token in the
> headers, a
> > 'classic' browser request for downloading a file result in an
> > UNauthenticated request because of unexisting bearer token.
> >
> > We're minding if there is a best practice to handle this case. We plan to
> > include a dedicated token as a download request parameter and to check
> this
> > particular query paramter programmatically in the /download JAX-RS
> > operation. What kind of token should have to put in the query and is
> there
> > an already existing mechanism to catch such token in jax-rs server-side
> > operations nor programmatically ?
>
> We actually had the same issue in our admin console as we provide a
> download option for the application config. AFAIK there's two solutions:
>
> * Generate a temporary token - basically what you're suggesting. There's
> two ways you can do this, always generate one and add it to the link,
> second is to use a redirect that only generates the token on demand
> * Use XHR to get the file, which allows setting the Authorization header,
> then use JavaScript to download
>
> There's currently no direct support for this in Keycloak, but it would be
> interesting to add.
>
> >
> > Thanks a lot for your support and so good work, Best Regards, J?r?me.
> >
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141216/4e6f7247/attachment.html 

From mposolda at redhat.com  Tue Dec 16 11:55:45 2014
From: mposolda at redhat.com (Marek Posolda)
Date: Tue, 16 Dec 2014 17:55:45 +0100
Subject: [keycloak-user] Questions about keycloak
In-Reply-To: <CA+L_nNgkTq9YxtJHcPE1ff7bJTVsMY1sF0vR0M3sY5-2FUfYQw@mail.gmail.com>
References: <CA+L_nNiTRZ2ySW7+XG-5461nmdi0XXuNV=foOBXugO-chcFNcw@mail.gmail.com>
	<54774560.8050809@redhat.com>
	<CA+L_nNiYQm4FRXGehR4n331dETJsdAv4Mis_VJSE=op3uZPo3g@mail.gmail.com>
	<2084644196.7048027.1417161849834.JavaMail.zimbra@redhat.com>
	<CA+L_nNh_C3c_fw_+jP8vhyVsMVt50AEYWDUVfdW2XZoytDXg_w@mail.gmail.com>
	<548AB8DC.4070207@redhat.com>
	<CA+L_nNgkTq9YxtJHcPE1ff7bJTVsMY1sF0vR0M3sY5-2FUfYQw@mail.gmail.com>
Message-ID: <54906411.7010903@redhat.com>

If you are interested in just Keycloak 1.0 server running in cluster and 
not secured applications themselves, then just those 2 things are required:
1) Use 'jpa' or 'mongo' as userSession provider in keycloak-server.json 
and use shared database among all cluster nodes. By default keycloak is 
using 'mem' provider, which means that User sessions are stored in 
memory of particular keycloak server. This performs well, but is not 
cluster aware.
2) Disable both realm and user cache in admin console, as caches are 
also stored just in local memory.

Both (1) and (2) should ensure that your keycloak server will be 
cluster-safe, but they are quite bad for performance. From 1.1.0.Beta1 
we have infinispan provider for user sessions, realm caches and user 
caches. This ensures both cluster-safety and good performance.

Marek

On 16.12.2014 17:18, Ruben Lopez wrote:
> Thanks for the quick answers!
>
> I couldn't find documentation about how to install Keycloak 1.0 in a 
> clustered environment. I know that Keycloak 1.1 does have 
> documentation about this but it is still in beta and the company I 
> work for needs to know if there is a similar mechanism that can be 
> implemented with Keycloak 1.0.
>
> El Fri Dec 12 2014 at 6:44:00 AM, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> escribi?:
>
>     On 11.12.2014 18:07, Ruben Lopez wrote:
>>     I have a couple more questions.
>>
>>     1) Will you implement the features requested in KEYCLOAK-402 and
>>     KEYCLOAK-405? If so, when?
>     Hard to say exactly, but looks that it will be quite soon as it is
>     requirement from more people and potential customers . Hopefully
>     in terms of weeks/months, but hard to promise exact date... I
>     think it would require enhance our existing password policies, but
>     those would be a bit harder to add than current simple policies as
>     it will also require to store some info in database (like password
>     expiration time and older passwords)
>
>>     2) Are there any plans to support Integrated Windows Authentication?
>     You mean login to KC when user is already logged in windows
>     domain? Yes, we have plan for add Kerberos/spnego soon and I think
>     that it should solve windows domain authentication too. Hopefully
>     around January.
>
>
>     Marek
>
>>
>>     Thanks :)
>>
>>     2014-11-28 5:04 GMT-03:00 Stian Thorgersen <stian at redhat.com
>>     <mailto:stian at redhat.com>>:
>>
>>
>>
>>         ----- Original Message -----
>>         > From: "Ruben Lopez" <rubenlop88 at gmail.com
>>         <mailto:rubenlop88 at gmail.com>>
>>         > To: "Marek Posolda" <mposolda at redhat.com
>>         <mailto:mposolda at redhat.com>>
>>         > Cc: keycloak-user at lists.jboss.org
>>         <mailto:keycloak-user at lists.jboss.org>
>>         > Sent: Thursday, 27 November, 2014 5:37:45 PM
>>         > Subject: Re: [keycloak-user] Questions about keycloak
>>         >
>>         > Hi Marek,
>>         >
>>         > 2014-11-27 12:38 GMT-03:00 Marek Posolda <
>>         mposolda at redhat.com <mailto:mposolda at redhat.com> > :
>>         >
>>         >
>>         >
>>         >
>>         >
>>         > 1 - Is there any way to obtain an access token for an OAuth
>>         Client via Client
>>         > Credentials[1]?
>>         > You mean something like Service account like this from
>>         OAuth2 specs
>>         > http://tools.ietf.org/html/rfc6749#page-40 ? We don't have
>>         that yet, but
>>         > there are plans to support it afaik.
>>         >
>>         >
>>         >
>>         >
>>         > Yes, I was talking about secction 4.4 Client Credentials
>>         Grant. Any idea
>>         > about when it will be implemented?
>>
>>         I can't give you and exact date, but it's becoming more and
>>         more of a priority so should be within a few months. We also
>>         plan to add cert based authentication for clients.
>>
>>         In the mean-time you can work-around this issue by creating a
>>         user on behalf of the client and use Resource Owner Password
>>         Credentials Grant (section #4.3). Look at
>>         'examples/preconfigured-demo/admin-access' in the download
>>         for an example.
>>
>>         >
>>         >
>>         >
>>         >
>>         >
>>         >
>>         > 2 - If we make a request to an Application (Resource
>>         Server) with an access
>>         > token and this Application needs to talk to another
>>         protected Application to
>>         > form the response to the client, how does the first Application
>>         > authenticates to the second Application? Does Keycloak
>>         implements something
>>         > like Chain Grant Type Profile[2]?
>>         > yes, that is doable. We have an example where we have
>>         frontend application
>>         > like 'customer-portal', which is able to retrieve
>>         accessToken from keycloak
>>         > like here:
>>         >
>>         https://github.com/keycloak/keycloak/blob/master/examples/demo-template/customer-app/src/main/java/org/keycloak/example/CustomerDatabaseClient.java#L48
>>         > and then use this accessToken to send request to backend
>>         application
>>         > 'database-service' in Authorization header
>>         >
>>         https://github.com/keycloak/keycloak/blob/master/examples/demo-template/customer-app/src/main/java/org/keycloak/example/CustomerDatabaseClient.java#L54
>>         > . Database-service is then able to authenticate the token.
>>         >
>>         > Currently our database-service is directly serving requests
>>         and send back
>>         > data, but it shouldn't be a problem to add another
>>         application to the chain,
>>         > so that database-service will send the token again to
>>         another app like
>>         > 'real-database-service', which will return data and those
>>         data will be sent
>>         > back to the original frontent requestor (customer-portal).
>>         Is it something
>>         > what you meant?
>>         >
>>         > Thats exactly what I meant. I will take a look at the example.
>>         >
>>         > Thank you very much.
>>         >
>>         >
>>         >
>>         >
>>         >
>>         > Marek
>>         >
>>         >
>>         >
>>         >
>>         > Thanks in advance.
>>         >
>>         >
>>         > _______________________________________________
>>         > keycloak-user mailing list keycloak-user at lists.jboss.org
>>         <mailto:keycloak-user at lists.jboss.org>
>>         > https://lists.jboss.org/mailman/listinfo/keycloak-user
>>         >
>>         >
>>         >
>>         > _______________________________________________
>>         > keycloak-user mailing list
>>         > keycloak-user at lists.jboss.org
>>         <mailto:keycloak-user at lists.jboss.org>
>>         > https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141216/414ae5d6/attachment-0001.html 

From kevin.minder at hortonworks.com  Tue Dec 16 23:45:37 2014
From: kevin.minder at hortonworks.com (Kevin Minder)
Date: Tue, 16 Dec 2014 23:45:37 -0500
Subject: [keycloak-user] Protecting Hadoop UIs with Keycloak?
Message-ID: <54910A71.1070600@hortonworks.com>

Hi Keycloak,

I'm interested in putting together a quick POC of Keycloak as the SSO 
server for several Hadoop UIs.  Most Hadoop UIs use an embedded Jetty 
server and they provide a Hadoop specific authentication plugin mechanism.
See: 
https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/AuthenticationHandler.java

I was hoping to find in docs or in an example on the web a non-container 
managed servlet filter integration that I could rework into a Hadoop 
AuthenticationHandler.

Anyway, would I be on the right track if I...

1) Wrap the adapters below in Hadoop AuthenticationHandlers having 
AuthenticationHandler.authenticate call *Authenticator.authenticate
keycloak/integration/adapter-core/src/main/java/org/keycloak/adapters/BasicAuthRequestAuthenticator.java
keycloak/integration/adapter-core/src/main/java/org/keycloak/adapters/BearerTokenRequestAuthenticator.java

2) In those, wrap the request/response in this
keycloak/integration/jetty/jetty-core/src/main/java/org/keycloak/adapters/jetty/JettyHttpFacade.java

3) Create the KeycloakDeployment via the builder with these with a 
keystone.js input stream from somewhere
keycloak/integration/adapter-core/src/main/java/org/keycloak/adapters/KeycloakDeployment.java
keycloak/integration/adapter-core/src/main/java/org/keycloak/adapters/KeycloakDeploymentBuilder.java

What totally obvious things am I missing?

Is it possible to have a container agnostic integration like this?

For one I'm not seeing how the KeycloakSecurityContext attribute that 
JettyHttpFacade expects is setup in the Jetty adapter.

Kevin.

-- 
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.

From stian at redhat.com  Wed Dec 17 03:05:17 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 17 Dec 2014 03:05:17 -0500 (EST)
Subject: [keycloak-user] HTML5/JS and download URL.
In-Reply-To: <CAPNq5vYjeQhB0KFiPOzv6u+P-iuR5nV4W8SjfdHF3kvgpFKYcQ@mail.gmail.com>
References: <CAPNq5vY2NO8RHE_C5=OSmtAEL_+0xYLudiY84M7goi4o+WmDbQ@mail.gmail.com>
	<1315224945.18004787.1418658552122.JavaMail.zimbra@redhat.com>
	<CAPNq5vYjeQhB0KFiPOzv6u+P-iuR5nV4W8SjfdHF3kvgpFKYcQ@mail.gmail.com>
Message-ID: <1558343345.19574462.1418803517929.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "J?r?me Blanchard" <jayblanc at gmail.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-user at lists.jboss.org
> Sent: Tuesday, 16 December, 2014 5:51:37 PM
> Subject: Re: [keycloak-user] HTML5/JS and download URL.
> 
> Hi,
> 
> Thank you for your answer. Sorry for my lake of knowledge in OAuth but
> speaking about generating a temporary token to include in the link, what
> kind of token do you mean and what is the best way to do that with Keycloak.

We don't have any support for this at the moment so you would have to make it yourself. With regards to token all I mean is a something temporary that allows the server to verify the user has permissions to download the file.

For example the token could be the base64 encoded signature (hmac, rsa or whatever you'd like) of userid, timestamp/expiration and file-url. That way the server can simply verify the signature on the server-side when the user is trying to download the file and check that it matches.

> 
> Best regards, J?r?me.
> 
> 2014-12-15 16:49 GMT+01:00 Stian Thorgersen <stian at redhat.com>:
> >
> >
> >
> > ----- Original Message -----
> > > From: "J?r?me Blanchard" <jayblanc at gmail.com>
> > > To: keycloak-user at lists.jboss.org
> > > Sent: Monday, 15 December, 2014 3:13:06 PM
> > > Subject: [keycloak-user] HTML5/JS and download URL.
> > >
> > > Hi all,
> > > We have a use case where an HTML5/Angular application is calling a REST
> > > interface using keycloak for authentication SSO. Everything works fine
> > until
> > > we need to download files or preview images (using <img> tag). In both
> > case,
> > > this is the browser which perform the request on the REST url and,
> > because
> > > of a specific XHR authentication putting the bearer token in the
> > headers, a
> > > 'classic' browser request for downloading a file result in an
> > > UNauthenticated request because of unexisting bearer token.
> > >
> > > We're minding if there is a best practice to handle this case. We plan to
> > > include a dedicated token as a download request parameter and to check
> > this
> > > particular query paramter programmatically in the /download JAX-RS
> > > operation. What kind of token should have to put in the query and is
> > there
> > > an already existing mechanism to catch such token in jax-rs server-side
> > > operations nor programmatically ?
> >
> > We actually had the same issue in our admin console as we provide a
> > download option for the application config. AFAIK there's two solutions:
> >
> > * Generate a temporary token - basically what you're suggesting. There's
> > two ways you can do this, always generate one and add it to the link,
> > second is to use a redirect that only generates the token on demand
> > * Use XHR to get the file, which allows setting the Authorization header,
> > then use JavaScript to download
> >
> > There's currently no direct support for this in Keycloak, but it would be
> > interesting to add.
> >
> > >
> > > Thanks a lot for your support and so good work, Best Regards, J?r?me.
> > >
> > > _______________________________________________
> > > keycloak-user mailing list
> > > keycloak-user at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
> 


From stian at redhat.com  Wed Dec 17 03:06:47 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 17 Dec 2014 03:06:47 -0500 (EST)
Subject: [keycloak-user] Questions about keycloak
In-Reply-To: <54906411.7010903@redhat.com>
References: <CA+L_nNiTRZ2ySW7+XG-5461nmdi0XXuNV=foOBXugO-chcFNcw@mail.gmail.com>
	<54774560.8050809@redhat.com>
	<CA+L_nNiYQm4FRXGehR4n331dETJsdAv4Mis_VJSE=op3uZPo3g@mail.gmail.com>
	<2084644196.7048027.1417161849834.JavaMail.zimbra@redhat.com>
	<CA+L_nNh_C3c_fw_+jP8vhyVsMVt50AEYWDUVfdW2XZoytDXg_w@mail.gmail.com>
	<548AB8DC.4070207@redhat.com>
	<CA+L_nNgkTq9YxtJHcPE1ff7bJTVsMY1sF0vR0M3sY5-2FUfYQw@mail.gmail.com>
	<54906411.7010903@redhat.com>
Message-ID: <1198624677.19575020.1418803607711.JavaMail.zimbra@redhat.com>

Keycloak 1.1 will be out in beginning of January, and as Marek said it'll have much improved clustering support over 1.0

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Ruben Lopez" <rubenlop88 at gmail.com>, "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-user at lists.jboss.org
> Sent: Tuesday, 16 December, 2014 5:55:45 PM
> Subject: Re: [keycloak-user] Questions about keycloak
> 
> If you are interested in just Keycloak 1.0 server running in cluster and
> not secured applications themselves, then just those 2 things are required:
> 1) Use 'jpa' or 'mongo' as userSession provider in keycloak-server.json
> and use shared database among all cluster nodes. By default keycloak is
> using 'mem' provider, which means that User sessions are stored in
> memory of particular keycloak server. This performs well, but is not
> cluster aware.
> 2) Disable both realm and user cache in admin console, as caches are
> also stored just in local memory.
> 
> Both (1) and (2) should ensure that your keycloak server will be
> cluster-safe, but they are quite bad for performance. From 1.1.0.Beta1
> we have infinispan provider for user sessions, realm caches and user
> caches. This ensures both cluster-safety and good performance.
> 
> Marek
> 
> On 16.12.2014 17:18, Ruben Lopez wrote:
> > Thanks for the quick answers!
> >
> > I couldn't find documentation about how to install Keycloak 1.0 in a
> > clustered environment. I know that Keycloak 1.1 does have
> > documentation about this but it is still in beta and the company I
> > work for needs to know if there is a similar mechanism that can be
> > implemented with Keycloak 1.0.
> >
> > El Fri Dec 12 2014 at 6:44:00 AM, Marek Posolda <mposolda at redhat.com
> > <mailto:mposolda at redhat.com>> escribi?:
> >
> >     On 11.12.2014 18:07, Ruben Lopez wrote:
> >>     I have a couple more questions.
> >>
> >>     1) Will you implement the features requested in KEYCLOAK-402 and
> >>     KEYCLOAK-405? If so, when?
> >     Hard to say exactly, but looks that it will be quite soon as it is
> >     requirement from more people and potential customers . Hopefully
> >     in terms of weeks/months, but hard to promise exact date... I
> >     think it would require enhance our existing password policies, but
> >     those would be a bit harder to add than current simple policies as
> >     it will also require to store some info in database (like password
> >     expiration time and older passwords)
> >
> >>     2) Are there any plans to support Integrated Windows Authentication?
> >     You mean login to KC when user is already logged in windows
> >     domain? Yes, we have plan for add Kerberos/spnego soon and I think
> >     that it should solve windows domain authentication too. Hopefully
> >     around January.
> >
> >
> >     Marek
> >
> >>
> >>     Thanks :)
> >>
> >>     2014-11-28 5:04 GMT-03:00 Stian Thorgersen <stian at redhat.com
> >>     <mailto:stian at redhat.com>>:
> >>
> >>
> >>
> >>         ----- Original Message -----
> >>         > From: "Ruben Lopez" <rubenlop88 at gmail.com
> >>         <mailto:rubenlop88 at gmail.com>>
> >>         > To: "Marek Posolda" <mposolda at redhat.com
> >>         <mailto:mposolda at redhat.com>>
> >>         > Cc: keycloak-user at lists.jboss.org
> >>         <mailto:keycloak-user at lists.jboss.org>
> >>         > Sent: Thursday, 27 November, 2014 5:37:45 PM
> >>         > Subject: Re: [keycloak-user] Questions about keycloak
> >>         >
> >>         > Hi Marek,
> >>         >
> >>         > 2014-11-27 12:38 GMT-03:00 Marek Posolda <
> >>         mposolda at redhat.com <mailto:mposolda at redhat.com> > :
> >>         >
> >>         >
> >>         >
> >>         >
> >>         >
> >>         > 1 - Is there any way to obtain an access token for an OAuth
> >>         Client via Client
> >>         > Credentials[1]?
> >>         > You mean something like Service account like this from
> >>         OAuth2 specs
> >>         > http://tools.ietf.org/html/rfc6749#page-40 ? We don't have
> >>         that yet, but
> >>         > there are plans to support it afaik.
> >>         >
> >>         >
> >>         >
> >>         >
> >>         > Yes, I was talking about secction 4.4 Client Credentials
> >>         Grant. Any idea
> >>         > about when it will be implemented?
> >>
> >>         I can't give you and exact date, but it's becoming more and
> >>         more of a priority so should be within a few months. We also
> >>         plan to add cert based authentication for clients.
> >>
> >>         In the mean-time you can work-around this issue by creating a
> >>         user on behalf of the client and use Resource Owner Password
> >>         Credentials Grant (section #4.3). Look at
> >>         'examples/preconfigured-demo/admin-access' in the download
> >>         for an example.
> >>
> >>         >
> >>         >
> >>         >
> >>         >
> >>         >
> >>         >
> >>         > 2 - If we make a request to an Application (Resource
> >>         Server) with an access
> >>         > token and this Application needs to talk to another
> >>         protected Application to
> >>         > form the response to the client, how does the first Application
> >>         > authenticates to the second Application? Does Keycloak
> >>         implements something
> >>         > like Chain Grant Type Profile[2]?
> >>         > yes, that is doable. We have an example where we have
> >>         frontend application
> >>         > like 'customer-portal', which is able to retrieve
> >>         accessToken from keycloak
> >>         > like here:
> >>         >
> >>         https://github.com/keycloak/keycloak/blob/master/examples/demo-template/customer-app/src/main/java/org/keycloak/example/CustomerDatabaseClient.java#L48
> >>         > and then use this accessToken to send request to backend
> >>         application
> >>         > 'database-service' in Authorization header
> >>         >
> >>         https://github.com/keycloak/keycloak/blob/master/examples/demo-template/customer-app/src/main/java/org/keycloak/example/CustomerDatabaseClient.java#L54
> >>         > . Database-service is then able to authenticate the token.
> >>         >
> >>         > Currently our database-service is directly serving requests
> >>         and send back
> >>         > data, but it shouldn't be a problem to add another
> >>         application to the chain,
> >>         > so that database-service will send the token again to
> >>         another app like
> >>         > 'real-database-service', which will return data and those
> >>         data will be sent
> >>         > back to the original frontent requestor (customer-portal).
> >>         Is it something
> >>         > what you meant?
> >>         >
> >>         > Thats exactly what I meant. I will take a look at the example.
> >>         >
> >>         > Thank you very much.
> >>         >
> >>         >
> >>         >
> >>         >
> >>         >
> >>         > Marek
> >>         >
> >>         >
> >>         >
> >>         >
> >>         > Thanks in advance.
> >>         >
> >>         >
> >>         > _______________________________________________
> >>         > keycloak-user mailing list keycloak-user at lists.jboss.org
> >>         <mailto:keycloak-user at lists.jboss.org>
> >>         > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >>         >
> >>         >
> >>         >
> >>         > _______________________________________________
> >>         > keycloak-user mailing list
> >>         > keycloak-user at lists.jboss.org
> >>         <mailto:keycloak-user at lists.jboss.org>
> >>         > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >>
> >>
> >
> 
> 


From bburke at redhat.com  Wed Dec 17 07:56:41 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 17 Dec 2014 07:56:41 -0500
Subject: [keycloak-user] Protecting Hadoop UIs with Keycloak?
In-Reply-To: <54910A71.1070600@hortonworks.com>
References: <54910A71.1070600@hortonworks.com>
Message-ID: <54917D89.80803@redhat.com>

Really depends how the Hadoop UI works.  Is it a Javascript app making 
REST calls to the server only?  Then you would use keycloak.js, 
BearerTokenRequestAuthenticator.  Or does the server render the UI?  If 
so, then you should implement a version of RequestAuthenticator (both 
bearer and redirect) and hook it in via your AuthanticationHandler.

If you get something working, we'd be happy to include it in keycloak 
and maintain it.

On 12/16/2014 11:45 PM, Kevin Minder wrote:
> Hi Keycloak,
>
> I'm interested in putting together a quick POC of Keycloak as the SSO
> server for several Hadoop UIs.  Most Hadoop UIs use an embedded Jetty
> server and they provide a Hadoop specific authentication plugin mechanism.
> See:
> https://github.com/apache/hadoop/blob/trunk/hadoop-common-project/hadoop-auth/src/main/java/org/apache/hadoop/security/authentication/server/AuthenticationHandler.java
>
> I was hoping to find in docs or in an example on the web a non-container
> managed servlet filter integration that I could rework into a Hadoop
> AuthenticationHandler.
>
> Anyway, would I be on the right track if I...
>
> 1) Wrap the adapters below in Hadoop AuthenticationHandlers having
> AuthenticationHandler.authenticate call *Authenticator.authenticate
> keycloak/integration/adapter-core/src/main/java/org/keycloak/adapters/BasicAuthRequestAuthenticator.java
> keycloak/integration/adapter-core/src/main/java/org/keycloak/adapters/BearerTokenRequestAuthenticator.java
>
> 2) In those, wrap the request/response in this
> keycloak/integration/jetty/jetty-core/src/main/java/org/keycloak/adapters/jetty/JettyHttpFacade.java
>
> 3) Create the KeycloakDeployment via the builder with these with a
> keystone.js input stream from somewhere
> keycloak/integration/adapter-core/src/main/java/org/keycloak/adapters/KeycloakDeployment.java
> keycloak/integration/adapter-core/src/main/java/org/keycloak/adapters/KeycloakDeploymentBuilder.java
>
> What totally obvious things am I missing?
>
> Is it possible to have a container agnostic integration like this?
>
> For one I'm not seeing how the KeycloakSecurityContext attribute that
> JettyHttpFacade expects is setup in the Jetty adapter.
>
> Kevin.
>

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

From stian at redhat.com  Wed Dec 17 08:01:46 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Wed, 17 Dec 2014 08:01:46 -0500 (EST)
Subject: [keycloak-user] How to add users in bulk
In-Reply-To: <CAJMEJTXDvbGDYxvEmMz1pS3NWETadBWThxeLHeorC-0mOwLvHQ@mail.gmail.com>
References: <CAJMEJTXDvbGDYxvEmMz1pS3NWETadBWThxeLHeorC-0mOwLvHQ@mail.gmail.com>
Message-ID: <640209939.19901720.1418821306427.JavaMail.zimbra@redhat.com>

You can import users from json files, see http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/export-import.html

----- Original Message -----
> From: "Hubert Przybysz" <h.p.przybysz at gmail.com>
> To: keycloak-user at lists.jboss.org
> Sent: Sunday, 14 December, 2014 5:36:49 PM
> Subject: [keycloak-user] How to add users in bulk
> 
> Hi,
> Is there an easy way of adding a large number users to a realm, where
> usernames and initial passwords follow a certain pattern?
> Best regards / Hubert.
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

From bdawidow at redhat.com  Wed Dec 17 08:42:43 2014
From: bdawidow at redhat.com (=?UTF-8?B?Qm9sZXPFgmF3IERhd2lkb3dpY3o=?=)
Date: Wed, 17 Dec 2014 14:42:43 +0100
Subject: [keycloak-user] Key Cloak Support
In-Reply-To: <1160679035.17713197.1418635274833.JavaMail.zimbra@redhat.com>
References: <OF7C936745.C6A1BC1E-ON85257DAB.007B7C18-85257DAB.007BBE20@uscmail.uscourts.gov>
	<1160679035.17713197.1418635274833.JavaMail.zimbra@redhat.com>
Message-ID: <54918853.9090104@redhat.com>

Hi, Luke

Divya can comment more on commercial support plans.

We would be interested to hear your feedback regarding current Keycloak 
usage and it's feature set. Could you share more about your requirements 
and needs? We are working on the roadmap and prioritizing various 
features. Your input would be valuable for us.

Regards
Boles?aw Dawidowicz

W dniu 2014-12-15 o 10:21, Stian Thorgersen pisze:
> Hi Luke,
>
> There's currently no commercial support for Keycloak, but it's something we're working towards.
>
> I've added Divya Mehra and Boles?aw Dawidowicz in CC as they may be able to provide more details.
>
> Stian Thorgersen
>
> ----- Original Message -----
>> From: "Luke Adams" <Luke_Adams at ao.uscourts.gov>
>> To: keycloak-user at lists.jboss.org
>> Sent: Thursday, 11 December, 2014 11:31:36 PM
>> Subject: [keycloak-user] Key Cloak Support
>>
>> Does anyone know if there is a commercial company supporting Key Cloak?
>>
>> Luke
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user

-- 
Boles?aw Dawidowicz
Supervisor, Software Engineering | Red Hat Middleware Security


From bburke at redhat.com  Wed Dec 17 23:15:30 2014
From: bburke at redhat.com (Bill Burke)
Date: Wed, 17 Dec 2014 23:15:30 -0500
Subject: [keycloak-user] How to add users in bulk
In-Reply-To: <640209939.19901720.1418821306427.JavaMail.zimbra@redhat.com>
References: <CAJMEJTXDvbGDYxvEmMz1pS3NWETadBWThxeLHeorC-0mOwLvHQ@mail.gmail.com>
	<640209939.19901720.1418821306427.JavaMail.zimbra@redhat.com>
Message-ID: <549254E2.8040902@redhat.com>

YOu can also use the admin REST API.

On 12/17/2014 8:01 AM, Stian Thorgersen wrote:
> You can import users from json files, see http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/export-import.html
>
> ----- Original Message -----
>> From: "Hubert Przybysz" <h.p.przybysz at gmail.com>
>> To: keycloak-user at lists.jboss.org
>> Sent: Sunday, 14 December, 2014 5:36:49 PM
>> Subject: [keycloak-user] How to add users in bulk
>>
>> Hi,
>> Is there an easy way of adding a large number users to a realm, where
>> usernames and initial passwords follow a certain pattern?
>> Best regards / Hubert.
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

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

From h.p.przybysz at gmail.com  Thu Dec 18 04:56:20 2014
From: h.p.przybysz at gmail.com (Hubert Przybysz)
Date: Thu, 18 Dec 2014 10:56:20 +0100
Subject: [keycloak-user] How to add users in bulk
In-Reply-To: <549254E2.8040902@redhat.com>
References: <CAJMEJTXDvbGDYxvEmMz1pS3NWETadBWThxeLHeorC-0mOwLvHQ@mail.gmail.com>
	<640209939.19901720.1418821306427.JavaMail.zimbra@redhat.com>
	<549254E2.8040902@redhat.com>
Message-ID: <CAJMEJTXQY2=14a3hEE8LducV7gxW_8xFYHret7KofC1O_dUNRg@mail.gmail.com>

Thanks both for quick responses.

I have a large number of users I want to migrate from another system to
keycloak. I could, as Bill suggests, write a piece of code that reads the
users from the existing system and adds them to keycloak using the admin
REST API. While not difficult, it takes a bit of work/time.

I looked earlier at export-import but understood that in order to import
users I had to first export them, meaning that they must have been already
provisioned in keycloak, correct? If that's not true, perhaps I can add my
users to the import file in some way ?

On Thu, Dec 18, 2014 at 5:15 AM, Bill Burke <bburke at redhat.com> wrote:
>
> YOu can also use the admin REST API.
>
> On 12/17/2014 8:01 AM, Stian Thorgersen wrote:
> > You can import users from json files, see
> http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/export-import.html
> >
> > ----- Original Message -----
> >> From: "Hubert Przybysz" <h.p.przybysz at gmail.com>
> >> To: keycloak-user at lists.jboss.org
> >> Sent: Sunday, 14 December, 2014 5:36:49 PM
> >> Subject: [keycloak-user] How to add users in bulk
> >>
> >> Hi,
> >> Is there an easy way of adding a large number users to a realm, where
> >> usernames and initial passwords follow a certain pattern?
> >> Best regards / Hubert.
> >>
> >> _______________________________________________
> >> keycloak-user mailing list
> >> keycloak-user at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-user
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141218/1d361550/attachment.html 

From alexander.chriztopher at gmail.com  Thu Dec 18 04:57:03 2014
From: alexander.chriztopher at gmail.com (Alexander Chriztopher)
Date: Thu, 18 Dec 2014 10:57:03 +0100
Subject: [keycloak-user] We're sorry ... Unknown code,
	please login again through your application.
Message-ID: <CAJfT+Ooxn+aRwfxp8DUyhMf+Jw_+R9Ld-01+pO1P+CAYYKJ=GA@mail.gmail.com>

Hi All,

Am having the following behaviour within keycloak :

# 1 / Open my application home page which brings me to the keycloak login
page;
# 2 / Click on Forgot Password then enter my login and validate. Keep this
page open in my browser -this page contains a link : back to login;
# 3 / Open the received mail and click on the link to reset password which
opens a new tab in my browser;
# 4 / Switch to the previous tab where i left the login page open and click
on the link back to login;
# 5 / A new page opens with the message : We're sorry ... Unknown code,
please login again through your application.

Could any one tell me why am getting this ?

Thanks for your help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141218/15cf1fd9/attachment.html 

From alexander.chriztopher at gmail.com  Thu Dec 18 08:21:29 2014
From: alexander.chriztopher at gmail.com (Alexander Chriztopher)
Date: Thu, 18 Dec 2014 14:21:29 +0100
Subject: [keycloak-user] Realm and User Cache
Message-ID: <CAJfT+OpUtgDeybwFo36Z5gdvEMku6i9jOnujULy59vCTHGgRmQ@mail.gmail.com>

Hi,

We are using Keycloak with all its data persisted to an Oracle database.

Actually, when we disable the caches for realm and user then save and
reboot our server we find that the cache is enabled again !

Is this a normal behaviour or a bug ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141218/0fbb666b/attachment.html 

From ssilvert at redhat.com  Thu Dec 18 08:39:52 2014
From: ssilvert at redhat.com (Stan Silvert)
Date: Thu, 18 Dec 2014 08:39:52 -0500
Subject: [keycloak-user] Hacking on Keycloak
Message-ID: <5492D928.1040205@redhat.com>

I've created a Wiki to show it's not tricky,
To start working with our fine code.
It's short and it's sweet, and it's not quite complete,
But for now it is all that I showed.

https://github.com/keycloak/keycloak/wiki/Hacking-on-Keycloak

Feel free to add your own tips to this page.  Just refrain from poor 
verse like above.



From bburke at redhat.com  Thu Dec 18 09:02:53 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 18 Dec 2014 09:02:53 -0500
Subject: [keycloak-user] Hacking on Keycloak
In-Reply-To: <5492D928.1040205@redhat.com>
References: <5492D928.1040205@redhat.com>
Message-ID: <5492DE8D.5040408@redhat.com>

lol

On 12/18/2014 8:39 AM, Stan Silvert wrote:
> I've created a Wiki to show it's not tricky,
> To start working with our fine code.
> It's short and it's sweet, and it's not quite complete,
> But for now it is all that I showed.
>
> https://github.com/keycloak/keycloak/wiki/Hacking-on-Keycloak
>
> Feel free to add your own tips to this page.  Just refrain from poor
> verse like above.
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

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

From bburke at redhat.com  Thu Dec 18 09:03:34 2014
From: bburke at redhat.com (Bill Burke)
Date: Thu, 18 Dec 2014 09:03:34 -0500
Subject: [keycloak-user] Realm and User Cache
In-Reply-To: <CAJfT+OpUtgDeybwFo36Z5gdvEMku6i9jOnujULy59vCTHGgRmQ@mail.gmail.com>
References: <CAJfT+OpUtgDeybwFo36Z5gdvEMku6i9jOnujULy59vCTHGgRmQ@mail.gmail.com>
Message-ID: <5492DEB6.4090300@redhat.com>

You have to manually shut it off in keycloak_server.json to persist 
between restarts.  That's just the way it works right now.

Were you having problems with the cache?

On 12/18/2014 8:21 AM, Alexander Chriztopher wrote:
> Hi,
>
> We are using Keycloak with all its data persisted to an Oracle database.
>
> Actually, when we disable the caches for realm and user then save and
> reboot our server we find that the cache is enabled again !
>
> Is this a normal behaviour or a bug ?
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

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

From alexander.chriztopher at gmail.com  Thu Dec 18 09:12:31 2014
From: alexander.chriztopher at gmail.com (Alexander Chriztopher)
Date: Thu, 18 Dec 2014 15:12:31 +0100
Subject: [keycloak-user] Realm and User Cache
In-Reply-To: <5492DEB6.4090300@redhat.com>
References: <CAJfT+OpUtgDeybwFo36Z5gdvEMku6i9jOnujULy59vCTHGgRmQ@mail.gmail.com>
	<5492DEB6.4090300@redhat.com>
Message-ID: <CAJfT+Oqc66V5AdAx6aNT98CbGtx6-bszJbETfDz1s8JP-4aLzg@mail.gmail.com>

ok then.

>> Were you having problems with the cache?

Yes ! We are working with a custom federation provider and we are having
problems with users that did not have an email adress when they first
logged in. Once these users logged in it is impossible to udpdate their
email adress without doing a hard sync from the admin console. We DO NOT
need things to work this way as it needs a human action with all the
drawbacks (not realtime, week-ends, administrator absent, etc.) and we
prefer something more automated.

The only way i see is to disable the cache and force the user information
to be updated from the database all the time or .. you could have a better
solution probably !

On Thu, Dec 18, 2014 at 3:03 PM, Bill Burke <bburke at redhat.com> wrote:
>
> You have to manually shut it off in keycloak_server.json to persist
> between restarts.  That's just the way it works right now.
>
> Were you having problems with the cache?
>
> On 12/18/2014 8:21 AM, Alexander Chriztopher wrote:
> > Hi,
> >
> > We are using Keycloak with all its data persisted to an Oracle database.
> >
> > Actually, when we disable the caches for realm and user then save and
> > reboot our server we find that the cache is enabled again !
> >
> > Is this a normal behaviour or a bug ?
> >
> >
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141218/4012383c/attachment.html 

From jayblanc at gmail.com  Thu Dec 18 12:07:18 2014
From: jayblanc at gmail.com (=?UTF-8?B?SsOpcsO0bWUgQmxhbmNoYXJk?=)
Date: Thu, 18 Dec 2014 17:07:18 +0000
Subject: [keycloak-user] Undertow Bearer Token in Cookie
References: <CAPNq5vY2NO8RHE_C5=OSmtAEL_+0xYLudiY84M7goi4o+WmDbQ@mail.gmail.com>
	<1315224945.18004787.1418658552122.JavaMail.zimbra@redhat.com>
	<CAPNq5vYjeQhB0KFiPOzv6u+P-iuR5nV4W8SjfdHF3kvgpFKYcQ@mail.gmail.com>
	<1558343345.19574462.1418803517929.JavaMail.zimbra@redhat.com>
	<CAPNq5vb66FCTqwb_4Ui_kok4vFZXWbrUPV_mJ32triaM_j4p+w@mail.gmail.com>
Message-ID: <CAPNq5vZdG2eZVy0tnC9Wv62+0mUocOn0cJSLECrHWo+uMuP1Uw@mail.gmail.com>

Hi all,

Is it possible to configure the servlet adapter to check presence of a
bearer token in a cookie instead of in a header ?
This question is about the download file usecase. If the bearer token will
be placed in a cookie by the javascript client at the same time settnig the
header, his will ensure that this cookie will be sent by the navigator in
the case of a download file or a <img> tag that would happen outside of a
XHR.

Thanks, Best Regards, J?r?me.

Le Wed Dec 17 2014 at 18:12:35, J?r?me Blanchard <jayblanc at gmail.com> a
?crit :

> Hi Stian,
>
> Thanks for your precisions, we have choose to implement the solution of a
> time based password.
> Using a ServletFilter and the Servlet 3.0 HttpRequest.login() feature
> we're able to intercept token from query parameter and propagate it to the
> JAAS stack. A dedicated LoginModule validate this token to enforce
> principal in the EJB SecurityContext and, according to this, our custom
> authorisation system is used ASIS without the need to create a hook in the
> download operation.
> This solution give the advantage to not interfer with the classic OAuth
> authentication in case of using a XHR Header nor a RESTClient that
> programmatically include the bearer token in the request header.
>
> Thanks a lot for your support, Best Regards, J?r?me.
>
>
>
> Le Wed Dec 17 2014 at 09:05:22, Stian Thorgersen <stian at redhat.com> a
> ?crit :
>
>
>>
>> ----- Original Message -----
>> > From: "J?r?me Blanchard" <jayblanc at gmail.com>
>> > To: "Stian Thorgersen" <stian at redhat.com>
>> > Cc: keycloak-user at lists.jboss.org
>> > Sent: Tuesday, 16 December, 2014 5:51:37 PM
>> > Subject: Re: [keycloak-user] HTML5/JS and download URL.
>> >
>> > Hi,
>> >
>> > Thank you for your answer. Sorry for my lake of knowledge in OAuth but
>> > speaking about generating a temporary token to include in the link, what
>> > kind of token do you mean and what is the best way to do that with
>> Keycloak.
>>
>> We don't have any support for this at the moment so you would have to
>> make it yourself. With regards to token all I mean is a something temporary
>> that allows the server to verify the user has permissions to download the
>> file.
>>
>> For example the token could be the base64 encoded signature (hmac, rsa or
>> whatever you'd like) of userid, timestamp/expiration and file-url. That way
>> the server can simply verify the signature on the server-side when the user
>> is trying to download the file and check that it matches.
>>
>> >
>> > Best regards, J?r?me.
>> >
>> > 2014-12-15 16:49 GMT+01:00 Stian Thorgersen <stian at redhat.com>:
>> > >
>> > >
>> > >
>> > > ----- Original Message -----
>> > > > From: "J?r?me Blanchard" <jayblanc at gmail.com>
>> > > > To: keycloak-user at lists.jboss.org
>> > > > Sent: Monday, 15 December, 2014 3:13:06 PM
>> > > > Subject: [keycloak-user] HTML5/JS and download URL.
>> > > >
>> > > > Hi all,
>> > > > We have a use case where an HTML5/Angular application is calling a
>> REST
>> > > > interface using keycloak for authentication SSO. Everything works
>> fine
>> > > until
>> > > > we need to download files or preview images (using <img> tag). In
>> both
>> > > case,
>> > > > this is the browser which perform the request on the REST url and,
>> > > because
>> > > > of a specific XHR authentication putting the bearer token in the
>> > > headers, a
>> > > > 'classic' browser request for downloading a file result in an
>> > > > UNauthenticated request because of unexisting bearer token.
>> > > >
>> > > > We're minding if there is a best practice to handle this case. We
>> plan to
>> > > > include a dedicated token as a download request parameter and to
>> check
>> > > this
>> > > > particular query paramter programmatically in the /download JAX-RS
>> > > > operation. What kind of token should have to put in the query and is
>> > > there
>> > > > an already existing mechanism to catch such token in jax-rs
>> server-side
>> > > > operations nor programmatically ?
>> > >
>> > > We actually had the same issue in our admin console as we provide a
>> > > download option for the application config. AFAIK there's two
>> solutions:
>> > >
>> > > * Generate a temporary token - basically what you're suggesting.
>> There's
>> > > two ways you can do this, always generate one and add it to the link,
>> > > second is to use a redirect that only generates the token on demand
>> > > * Use XHR to get the file, which allows setting the Authorization
>> header,
>> > > then use JavaScript to download
>> > >
>> > > There's currently no direct support for this in Keycloak, but it
>> would be
>> > > interesting to add.
>> > >
>> > > >
>> > > > Thanks a lot for your support and so good work, Best Regards,
>> J?r?me.
>> > > >
>> > > > _______________________________________________
>> > > > keycloak-user mailing list
>> > > > keycloak-user at lists.jboss.org
>> > > > https://lists.jboss.org/mailman/listinfo/keycloak-user
>> > >
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141218/56a153f1/attachment-0001.html 

From peterson.dean at gmail.com  Thu Dec 18 14:59:38 2014
From: peterson.dean at gmail.com (Dean Peterson)
Date: Thu, 18 Dec 2014 13:59:38 -0600
Subject: [keycloak-user] Best way to get subject without adding it as
 request parameter in cross domain back end REST service
Message-ID: <CAFGzvPnT8E2sr0+ObTO_x-JyA1wc43nyirpdemMUXE+Jofg8Eg@mail.gmail.com>

I am able to use a bearer token to call a java REST service from a pure
javascript client.  Unfortunately the KeycloakSecurityContext is
essentially empty on the back end.  I need to filter and update data by
subject (idToken.subject)  Initially I setup my back end REST application
as a bearer token only application; thinking that was the problem, I
switched to a confidential back end application but the
KeycloakSecurityContext is still not populated.  In order to communicate
with the service in a cross domain way, I still need to send a bearer
token, regardless of the type of application.  I can get the subject in
javascript and add it to the list of request parameters, however, it seems
that leaves me open to anyone with a valid token being able to request
another user's data.  What is the best way to handle this kind of situation
using Keycloak?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141218/ca92c6f5/attachment.html 

From alexander.chriztopher at gmail.com  Fri Dec 19 10:06:56 2014
From: alexander.chriztopher at gmail.com (Alexander Chriztopher)
Date: Fri, 19 Dec 2014 16:06:56 +0100
Subject: [keycloak-user] HTTP 403 Forbidden on Keycloak.getInstance
Message-ID: <CAJfT+Oq-x2f3Wfz1mvUR=YqE+0hPXgHUbemM7yUyHVHdWFb0nA@mail.gmail.com>

Hi,

I have a realm with an application called : examples-admin-client
<http://localhost:8080/auth/admin/master/console/#/realms/cv/applications/983779c1-3224-459f-8be9-5c2c443158a8>
and
would like to use it to manage my realm but i get an error
: javax.ws.rs.ClientErrorException: HTTP 403 Forbidden every time i make
the following call :

Keycloak keycloak = Keycloak.getInstance(authServer, "realm-name", "User1",
"password", "examples-admin-client",
"a5890cdf-e1df-40c0-9d50-26ad2f7badde");

When i try to do the same thing with the example realm (i use the json
example-realm.json provided by the keycloak project) this works nicely
actually !

Btw, i can successfully login with the user : User1 with that password.

This is the json for my realm :

{
  "realm": "realm-name",
  "realm-public-key":
"MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCxwUIE6W3BZYlSxDPpwkknb2ObnrEsGMUJGy3HfNEfkfu9rcY5bxkllLsW32KlR78++xtuI11IE2nuh6nJmUsIKMb55Ez9n7/E9kPmSF6lxavZlQY0HfBnR3ZWgzsoUUz4n7pOhmqHIAGXeuxnMDQ5/upwcolFIZRor1v7oT/H8QIDAQAB",
  "auth-server-url": "http://localhost:8080/auth",
  "ssl-required": "none",
  "resource": "examples-admin-client",
  "credentials": {
    "secret": "a5890cdf-e1df-40c0-9d50-26ad2f7badde"
  }
}

Thanks for any help on this one !
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141219/40b70f9a/attachment.html 

From alexander.chriztopher at gmail.com  Fri Dec 19 13:36:05 2014
From: alexander.chriztopher at gmail.com (Alexander Chriztopher)
Date: Fri, 19 Dec 2014 19:36:05 +0100
Subject: [keycloak-user] Is it possible to update users with the admin client
Message-ID: <CAJfT+OovZG0nsaFUcAE9NF36xBaOUwc2p5D6rviroDBnczN4hA@mail.gmail.com>

Hi,

I would like to use the admin client to update a user in order to force him
to change his password next time he logs in ?

So far i have failed miserably to do it so i was wondering if this is at
all possible ?

This is basically what am doing :

        Keycloak keycloak = Keycloak.getInstance(authServer, "example",
"examples-admin-client", "password", "examples-admin-client", "password");
        RealmResource realm = keycloak.realm("example");
        UsersResource users = realm.users();
        List<UserRepresentation> users_ = users.search("", 0, 1000000); //
This gets me all my users
        for (UserRepresentation user_ : users_) {
            if (user_.getUsername().equals("examples-admin-client")) {
                user_.setEmailVerified(true);
            }
        }
        RealmRepresentation realm_ = realm.toRepresentation();
        realm_.setUsers(users_);
        realm.update(realm_);

Does the method update of realm support users update ?

Thanks for any help on this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141219/f727a966/attachment.html 

From peterson.dean at gmail.com  Fri Dec 19 14:07:53 2014
From: peterson.dean at gmail.com (Dean Peterson)
Date: Fri, 19 Dec 2014 13:07:53 -0600
Subject: [keycloak-user] Best way to get subject without adding it as
 request parameter in cross domain back end REST service
In-Reply-To: <CAFGzvPnT8E2sr0+ObTO_x-JyA1wc43nyirpdemMUXE+Jofg8Eg@mail.gmail.com>
References: <CAFGzvPnT8E2sr0+ObTO_x-JyA1wc43nyirpdemMUXE+Jofg8Eg@mail.gmail.com>
Message-ID: <CAFGzvPnraunY_fHRpBbxAjvRnRZrWLH5ySdsMS4yFt5pkw294w@mail.gmail.com>

Ok I found the answer by reading the question just above mine: "Obtaining
the username from the security context".  I did not realize that
session.getToken() contained the information I need.  I was checking in
session.getIdToken().

On Thu, Dec 18, 2014 at 1:59 PM, Dean Peterson <peterson.dean at gmail.com>
wrote:

> I am able to use a bearer token to call a java REST service from a pure
> javascript client.  Unfortunately the KeycloakSecurityContext is
> essentially empty on the back end.  I need to filter and update data by
> subject (idToken.subject)  Initially I setup my back end REST application
> as a bearer token only application; thinking that was the problem, I
> switched to a confidential back end application but the
> KeycloakSecurityContext is still not populated.  In order to communicate
> with the service in a cross domain way, I still need to send a bearer
> token, regardless of the type of application.  I can get the subject in
> javascript and add it to the list of request parameters, however, it seems
> that leaves me open to anyone with a valid token being able to request
> another user's data.  What is the best way to handle this kind of situation
> using Keycloak?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141219/05d4a07d/attachment.html 

From peterson.dean at gmail.com  Fri Dec 19 17:05:20 2014
From: peterson.dean at gmail.com (Dean Peterson)
Date: Fri, 19 Dec 2014 16:05:20 -0600
Subject: [keycloak-user] Best way to get subject without adding it as
 request parameter in cross domain back end REST service
In-Reply-To: <CAFGzvPnraunY_fHRpBbxAjvRnRZrWLH5ySdsMS4yFt5pkw294w@mail.gmail.com>
References: <CAFGzvPnT8E2sr0+ObTO_x-JyA1wc43nyirpdemMUXE+Jofg8Eg@mail.gmail.com>
	<CAFGzvPnraunY_fHRpBbxAjvRnRZrWLH5ySdsMS4yFt5pkw294w@mail.gmail.com>
Message-ID: <CAFGzvPkOcF2PR=RbubBs7PW_vn=4zxYx8Tiv2DPXkKHgGPv=Wg@mail.gmail.com>

Actually, I see it's session.getToken().getSubject();

On Fri, Dec 19, 2014 at 1:07 PM, Dean Peterson <peterson.dean at gmail.com>
wrote:

> Ok I found the answer by reading the question just above mine: "Obtaining
> the username from the security context".  I did not realize that
> session.getToken() contained the information I need.  I was checking in
> session.getIdToken().
>
> On Thu, Dec 18, 2014 at 1:59 PM, Dean Peterson <peterson.dean at gmail.com>
> wrote:
>
>> I am able to use a bearer token to call a java REST service from a pure
>> javascript client.  Unfortunately the KeycloakSecurityContext is
>> essentially empty on the back end.  I need to filter and update data by
>> subject (idToken.subject)  Initially I setup my back end REST application
>> as a bearer token only application; thinking that was the problem, I
>> switched to a confidential back end application but the
>> KeycloakSecurityContext is still not populated.  In order to communicate
>> with the service in a cross domain way, I still need to send a bearer
>> token, regardless of the type of application.  I can get the subject in
>> javascript and add it to the list of request parameters, however, it seems
>> that leaves me open to anyone with a valid token being able to request
>> another user's data.  What is the best way to handle this kind of situation
>> using Keycloak?
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141219/5fa66c93/attachment.html 

From prabhalar at yahoo.com  Sat Dec 20 07:32:38 2014
From: prabhalar at yahoo.com (prab rrrr)
Date: Sat, 20 Dec 2014 12:32:38 +0000 (UTC)
Subject: [keycloak-user] Merry Christmas from the Keycloak team
In-Reply-To: <CACQJ6LQjFesqxdieFFjZyQgHBTD5+dW4ZxnpHEBixz=2oW4hvw@mail.gmail.com>
References: <CACQJ6LQjFesqxdieFFjZyQgHBTD5+dW4ZxnpHEBixz=2oW4hvw@mail.gmail.com>
Message-ID: <847608453.972436.1419078758134.JavaMail.yahoo@jws10029.mail.ne1.yahoo.com>

Hi Stian - Thanks for sharing your roadmap for 2015. Really looking forward to see identity brokering and? Openid Dynamic registration.?Do you have any plans to?support 1) FIDO specifications (UAT and U2F)?2) Any other NoSQL databases like Cassandra?
Congratulations on a great product key cloak team and Happy holidays to all of you.
Raghu
?      From: Travis De Silva <traviskds at gmail.com>
 To: Stian Thorgersen <stian at redhat.com> 
Cc: keycloak dev <keycloak-dev at lists.jboss.org>; keycloack-users <keycloak-user at lists.jboss.org> 
 Sent: Tuesday, December 16, 2014 6:40 AM
 Subject: Re: [keycloak-user] Merry Christmas from the Keycloak team
   
Congratulations and thank you to the entire KeyCloak team. This is a great project and wishing it gets better and better over the course of next year.
Merry Christmas and Happy New Year to everyone.


On Tue, Dec 16, 2014 at 10:38 PM, Stian Thorgersen <stian at redhat.com> wrote:

2014 was the year of Keycloak! At least that was the case for us on the Keycloak team. In January we released the very first alpha of the project. The first stable release wasn?t out until September, but in return we added a lot more features as well as reaching a very high level of stability for a 1.0.

Since then we?ve delivered a number of security and bug fixes for 1.0, while continuing to bake in new exiting features for 1.1. We?re planning to do a stable release of 1.1 early in the New Year, which will bring SAML 2, much improved clustering and a number of new application adapters.

Not only have we managed to provide a feature rich and easy to use open source security solution, but we?ve also managed to build an awesome community around the project. We?ve had over 5000 downloads, over 2500 commits from 32 contributors and our developer and user mailing lists are very active. Keycloak is already in use in production on a number of projects, in fact some has even used it in production since our first alpha release!

Our road-map for 2015 is not written in stone, but expect at least some of the following features to be delivered in 2015:

? * Custom user profiles ? this will let you configure the attributes for a user profile, which should be visible on the registration screen and account management, as well as specify validation
? * Identity Brokering ? we?re adding support to authenticate with external Identity Providers via OpenID Connect, SAML 2.0 and Kerberos
? * Two-Factor Authentication ? currently we only support Google Authenticator or FreeOTP applications for two-factor authentication, but we plan to make it possible to add your own and provide some more out of the box
? * Client Accounts ? these will be special user accounts directly linked to a client, allowing a client to access services as itself not just on-behalf of users
? * Client Certificates ? support authentication of clients with certificates
? * Client Types ? at the moment we have applications and oauth clients, the main difference being oauth clients require users to grant permissions to roles. To simplify the admin console we plan to introduce a single unified view for clients and also introduce new types such as devices
? * Internationalization ? internationalization support for login and account management pages
? * SMS ? enable SMS to recover passwords, as a 2nd factor authentication mechanism and to be notified about events like login failures
? * OpenID Connect Dynamic Registration ?? allows clients to dynamically register with Keycloak. We?ll also look at passing the OpenID Connect Interop testing
? * Mapping of users and tokens ? custom mapping of user profiles from external identity stores and tokens from external Identity Providers

We also have ideas for some bigger features, but we?ll leave those as a surprise for 2015!

Finally, I?d like to wish everyone a Merry Christmas and a Happy New Year.

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


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

  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141220/1f1b709e/attachment-0001.html 

From bburke at redhat.com  Mon Dec 22 10:24:48 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 22 Dec 2014 10:24:48 -0500
Subject: [keycloak-user] Undertow Bearer Token in Cookie
In-Reply-To: <CAPNq5vZdG2eZVy0tnC9Wv62+0mUocOn0cJSLECrHWo+uMuP1Uw@mail.gmail.com>
References: <CAPNq5vY2NO8RHE_C5=OSmtAEL_+0xYLudiY84M7goi4o+WmDbQ@mail.gmail.com>	<1315224945.18004787.1418658552122.JavaMail.zimbra@redhat.com>	<CAPNq5vYjeQhB0KFiPOzv6u+P-iuR5nV4W8SjfdHF3kvgpFKYcQ@mail.gmail.com>	<1558343345.19574462.1418803517929.JavaMail.zimbra@redhat.com>	<CAPNq5vb66FCTqwb_4Ui_kok4vFZXWbrUPV_mJ32triaM_j4p+w@mail.gmail.com>
	<CAPNq5vZdG2eZVy0tnC9Wv62+0mUocOn0cJSLECrHWo+uMuP1Uw@mail.gmail.com>
Message-ID: <549837C0.400@redhat.com>

Servlet adapter already does this.

* 1.0.x Keycloak attaches the token to the Http Session.
* 1.1 Beta+ Keycloak adapter has an option to store the token in a 
cookie instead of the HttpSession.

On 12/18/2014 12:07 PM, J?r?me Blanchard wrote:
> Hi all,
>
> Is it possible to configure the servlet adapter to check presence of a
> bearer token in a cookie instead of in a header ?
> This question is about the download file usecase. If the bearer token
> will be placed in a cookie by the javascript client at the same time
> settnig the header, his will ensure that this cookie will be sent by the
> navigator in the case of a download file or a <img> tag that would
> happen outside of a XHR.
>
> Thanks, Best Regards, J?r?me.
>
> Le Wed Dec 17 2014 at 18:12:35, J?r?me Blanchard <jayblanc at gmail.com
> <mailto:jayblanc at gmail.com>> a ?crit :
>
>     Hi Stian,
>
>     Thanks for your precisions, we have choose to implement the solution
>     of a time based password.
>     Using a ServletFilter and the Servlet 3.0 HttpRequest.login()
>     feature we're able to intercept token from query parameter and
>     propagate it to the JAAS stack. A dedicated LoginModule validate
>     this token to enforce principal in the EJB SecurityContext and,
>     according to this, our custom authorisation system is used ASIS
>     without the need to create a hook in the download operation.
>     This solution give the advantage to not interfer with the classic
>     OAuth authentication in case of using a XHR Header nor a RESTClient
>     that programmatically include the bearer token in the request header.
>
>     Thanks a lot for your support, Best Regards, J?r?me.
>
>
>
>     Le Wed Dec 17 2014 at 09:05:22, Stian Thorgersen <stian at redhat.com
>     <mailto:stian at redhat.com>> a ?crit :
>
>
>
>         ----- Original Message -----
>          > From: "J?r?me Blanchard" <jayblanc at gmail.com
>         <mailto:jayblanc at gmail.com>>
>          > To: "Stian Thorgersen" <stian at redhat.com
>         <mailto:stian at redhat.com>>
>          > Cc: keycloak-user at lists.jboss.org
>         <mailto:keycloak-user at lists.jboss.org>
>          > Sent: Tuesday, 16 December, 2014 5:51:37 PM
>          > Subject: Re: [keycloak-user] HTML5/JS and download URL.
>          >
>          > Hi,
>          >
>          > Thank you for your answer. Sorry for my lake of knowledge in
>         OAuth but
>          > speaking about generating a temporary token to include in the
>         link, what
>          > kind of token do you mean and what is the best way to do that
>         with Keycloak.
>
>         We don't have any support for this at the moment so you would
>         have to make it yourself. With regards to token all I mean is a
>         something temporary that allows the server to verify the user
>         has permissions to download the file.
>
>         For example the token could be the base64 encoded signature
>         (hmac, rsa or whatever you'd like) of userid,
>         timestamp/expiration and file-url. That way the server can
>         simply verify the signature on the server-side when the user is
>         trying to download the file and check that it matches.
>
>          >
>          > Best regards, J?r?me.
>          >
>          > 2014-12-15 16:49 GMT+01:00 Stian Thorgersen <stian at redhat.com
>         <mailto:stian at redhat.com>>:
>          > >
>          > >
>          > >
>          > > ----- Original Message -----
>          > > > From: "J?r?me Blanchard" <jayblanc at gmail.com
>         <mailto:jayblanc at gmail.com>>
>          > > > To: keycloak-user at lists.jboss.org
>         <mailto:keycloak-user at lists.jboss.org>
>          > > > Sent: Monday, 15 December, 2014 3:13:06 PM
>          > > > Subject: [keycloak-user] HTML5/JS and download URL.
>          > > >
>          > > > Hi all,
>          > > > We have a use case where an HTML5/Angular application is
>         calling a REST
>          > > > interface using keycloak for authentication SSO.
>         Everything works fine
>          > > until
>          > > > we need to download files or preview images (using <img>
>         tag). In both
>          > > case,
>          > > > this is the browser which perform the request on the REST
>         url and,
>          > > because
>          > > > of a specific XHR authentication putting the bearer token
>         in the
>          > > headers, a
>          > > > 'classic' browser request for downloading a file result in an
>          > > > UNauthenticated request because of unexisting bearer token.
>          > > >
>          > > > We're minding if there is a best practice to handle this
>         case. We plan to
>          > > > include a dedicated token as a download request parameter
>         and to check
>          > > this
>          > > > particular query paramter programmatically in the
>         /download JAX-RS
>          > > > operation. What kind of token should have to put in the
>         query and is
>          > > there
>          > > > an already existing mechanism to catch such token in
>         jax-rs server-side
>          > > > operations nor programmatically ?
>          > >
>          > > We actually had the same issue in our admin console as we
>         provide a
>          > > download option for the application config. AFAIK there's
>         two solutions:
>          > >
>          > > * Generate a temporary token - basically what you're
>         suggesting. There's
>          > > two ways you can do this, always generate one and add it to
>         the link,
>          > > second is to use a redirect that only generates the token
>         on demand
>          > > * Use XHR to get the file, which allows setting the
>         Authorization header,
>          > > then use JavaScript to download
>          > >
>          > > There's currently no direct support for this in Keycloak,
>         but it would be
>          > > interesting to add.
>          > >
>          > > >
>          > > > Thanks a lot for your support and so good work, Best
>         Regards, J?r?me.
>          > > >
>          > > > ___________________________________________________
>          > > > keycloak-user mailing list
>          > > > keycloak-user at lists.jboss.org
>         <mailto:keycloak-user at lists.jboss.org>
>          > > >
>         https://lists.jboss.org/__mailma__n/listinfo/keycloak-user
>         <https://lists.jboss.org/mailman/listinfo/keycloak-user>
>          > >
>          >
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

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

From bburke at redhat.com  Mon Dec 22 10:25:57 2014
From: bburke at redhat.com (Bill Burke)
Date: Mon, 22 Dec 2014 10:25:57 -0500
Subject: [keycloak-user] Best way to get subject without adding it as
 request parameter in cross domain back end REST service
In-Reply-To: <CAFGzvPnT8E2sr0+ObTO_x-JyA1wc43nyirpdemMUXE+Jofg8Eg@mail.gmail.com>
References: <CAFGzvPnT8E2sr0+ObTO_x-JyA1wc43nyirpdemMUXE+Jofg8Eg@mail.gmail.com>
Message-ID: <54983805.6000707@redhat.com>

So, with Bearer token auth, the KeycloakSecurityContext is null?  Or it 
doesn't have any information?

On 12/18/2014 2:59 PM, Dean Peterson wrote:
> I am able to use a bearer token to call a java REST service from a pure
> javascript client.  Unfortunately the KeycloakSecurityContext is
> essentially empty on the back end.  I need to filter and update data by
> subject (idToken.subject)  Initially I setup my back end REST
> application as a bearer token only application; thinking that was the
> problem, I switched to a confidential back end application but the
> KeycloakSecurityContext is still not populated.  In order to communicate
> with the service in a cross domain way, I still need to send a bearer
> token, regardless of the type of application.  I can get the subject in
> javascript and add it to the list of request parameters, however, it
> seems that leaves me open to anyone with a valid token being able to
> request another user's data.  What is the best way to handle this kind
> of situation using Keycloak?
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

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

From jayblanc at gmail.com  Tue Dec 23 04:03:11 2014
From: jayblanc at gmail.com (=?UTF-8?B?SsOpcsO0bWUgQmxhbmNoYXJk?=)
Date: Tue, 23 Dec 2014 09:03:11 +0000
Subject: [keycloak-user] Undertow Bearer Token in Cookie
References: <CAPNq5vY2NO8RHE_C5=OSmtAEL_+0xYLudiY84M7goi4o+WmDbQ@mail.gmail.com>
	<1315224945.18004787.1418658552122.JavaMail.zimbra@redhat.com>
	<CAPNq5vYjeQhB0KFiPOzv6u+P-iuR5nV4W8SjfdHF3kvgpFKYcQ@mail.gmail.com>
	<1558343345.19574462.1418803517929.JavaMail.zimbra@redhat.com>
	<CAPNq5vb66FCTqwb_4Ui_kok4vFZXWbrUPV_mJ32triaM_j4p+w@mail.gmail.com>
	<CAPNq5vZdG2eZVy0tnC9Wv62+0mUocOn0cJSLECrHWo+uMuP1Uw@mail.gmail.com>
	<549837C0.400@redhat.com>
Message-ID: <CAPNq5vaYyYMfpvq=5DtnYLfsfN4oha+dT9CQj8r4mbRbz8ff-g@mail.gmail.com>

Hi, by mentionning the servlet adapter, you mean the WAR configured using
web.xml (server side) ? or the client servlet adapter ?

In our configuration we have a REST API prtoected using the WAR wildfly
adapter (ensuring EJB auth propagation) and a JS client.

I tried using the configuration of cookie token store (

"token-store": "cookie"

) in the wildfly adapter (server side) but no cookie is set in my HTML5/JS
client and it seem no cookie is catched by the wildfly adapter...
Did I missed something ?

Best regards, J?r?me.

Le Mon Dec 22 2014 at 16:24:58, Bill Burke <bburke at redhat.com> a ?crit :

Servlet adapter already does this.
>
> * 1.0.x Keycloak attaches the token to the Http Session.
> * 1.1 Beta+ Keycloak adapter has an option to store the token in a
> cookie instead of the HttpSession.
>
> On 12/18/2014 12:07 PM, J?r?me Blanchard wrote:
> > Hi all,
> >
> > Is it possible to configure the servlet adapter to check presence of a
> > bearer token in a cookie instead of in a header ?
> > This question is about the download file usecase. If the bearer token
> > will be placed in a cookie by the javascript client at the same time
> > settnig the header, his will ensure that this cookie will be sent by the
> > navigator in the case of a download file or a <img> tag that would
> > happen outside of a XHR.
> >
> > Thanks, Best Regards, J?r?me.
> >
> > Le Wed Dec 17 2014 at 18:12:35, J?r?me Blanchard <jayblanc at gmail.com
> > <mailto:jayblanc at gmail.com>> a ?crit :
> >
> >     Hi Stian,
> >
> >     Thanks for your precisions, we have choose to implement the solution
> >     of a time based password.
> >     Using a ServletFilter and the Servlet 3.0 HttpRequest.login()
> >     feature we're able to intercept token from query parameter and
> >     propagate it to the JAAS stack. A dedicated LoginModule validate
> >     this token to enforce principal in the EJB SecurityContext and,
> >     according to this, our custom authorisation system is used ASIS
> >     without the need to create a hook in the download operation.
> >     This solution give the advantage to not interfer with the classic
> >     OAuth authentication in case of using a XHR Header nor a RESTClient
> >     that programmatically include the bearer token in the request header.
> >
> >     Thanks a lot for your support, Best Regards, J?r?me.
> >
> >
> >
> >     Le Wed Dec 17 2014 at 09:05:22, Stian Thorgersen <stian at redhat.com
> >     <mailto:stian at redhat.com>> a ?crit :
> >
> >
> >
> >         ----- Original Message -----
> >          > From: "J?r?me Blanchard" <jayblanc at gmail.com
> >         <mailto:jayblanc at gmail.com>>
> >          > To: "Stian Thorgersen" <stian at redhat.com
> >         <mailto:stian at redhat.com>>
> >          > Cc: keycloak-user at lists.jboss.org
> >         <mailto:keycloak-user at lists.jboss.org>
> >          > Sent: Tuesday, 16 December, 2014 5:51:37 PM
> >          > Subject: Re: [keycloak-user] HTML5/JS and download URL.
> >          >
> >          > Hi,
> >          >
> >          > Thank you for your answer. Sorry for my lake of knowledge in
> >         OAuth but
> >          > speaking about generating a temporary token to include in the
> >         link, what
> >          > kind of token do you mean and what is the best way to do that
> >         with Keycloak.
> >
> >         We don't have any support for this at the moment so you would
> >         have to make it yourself. With regards to token all I mean is a
> >         something temporary that allows the server to verify the user
> >         has permissions to download the file.
> >
> >         For example the token could be the base64 encoded signature
> >         (hmac, rsa or whatever you'd like) of userid,
> >         timestamp/expiration and file-url. That way the server can
> >         simply verify the signature on the server-side when the user is
> >         trying to download the file and check that it matches.
> >
> >          >
> >          > Best regards, J?r?me.
> >          >
> >          > 2014-12-15 16:49 GMT+01:00 Stian Thorgersen <stian at redhat.com
> >         <mailto:stian at redhat.com>>:
> >          > >
> >          > >
> >          > >
> >          > > ----- Original Message -----
> >          > > > From: "J?r?me Blanchard" <jayblanc at gmail.com
> >         <mailto:jayblanc at gmail.com>>
> >          > > > To: keycloak-user at lists.jboss.org
> >         <mailto:keycloak-user at lists.jboss.org>
> >          > > > Sent: Monday, 15 December, 2014 3:13:06 PM
> >          > > > Subject: [keycloak-user] HTML5/JS and download URL.
> >          > > >
> >          > > > Hi all,
> >          > > > We have a use case where an HTML5/Angular application is
> >         calling a REST
> >          > > > interface using keycloak for authentication SSO.
> >         Everything works fine
> >          > > until
> >          > > > we need to download files or preview images (using <img>
> >         tag). In both
> >          > > case,
> >          > > > this is the browser which perform the request on the REST
> >         url and,
> >          > > because
> >          > > > of a specific XHR authentication putting the bearer token
> >         in the
> >          > > headers, a
> >          > > > 'classic' browser request for downloading a file result
> in an
> >          > > > UNauthenticated request because of unexisting bearer
> token.
> >          > > >
> >          > > > We're minding if there is a best practice to handle this
> >         case. We plan to
> >          > > > include a dedicated token as a download request parameter
> >         and to check
> >          > > this
> >          > > > particular query paramter programmatically in the
> >         /download JAX-RS
> >          > > > operation. What kind of token should have to put in the
> >         query and is
> >          > > there
> >          > > > an already existing mechanism to catch such token in
> >         jax-rs server-side
> >          > > > operations nor programmatically ?
> >          > >
> >          > > We actually had the same issue in our admin console as we
> >         provide a
> >          > > download option for the application config. AFAIK there's
> >         two solutions:
> >          > >
> >          > > * Generate a temporary token - basically what you're
> >         suggesting. There's
> >          > > two ways you can do this, always generate one and add it to
> >         the link,
> >          > > second is to use a redirect that only generates the token
> >         on demand
> >          > > * Use XHR to get the file, which allows setting the
> >         Authorization header,
> >          > > then use JavaScript to download
> >          > >
> >          > > There's currently no direct support for this in Keycloak,
> >         but it would be
> >          > > interesting to add.
> >          > >
> >          > > >
> >          > > > Thanks a lot for your support and so good work, Best
> >         Regards, J?r?me.
> >          > > >
> >          > > > ___________________________________________________
> >          > > > keycloak-user mailing list
> >          > > > keycloak-user at lists.jboss.org
> >         <mailto:keycloak-user at lists.jboss.org>
> >          > > >
> >         https://lists.jboss.org/__mailma__n/listinfo/keycloak-user
> >         <https://lists.jboss.org/mailman/listinfo/keycloak-user>
> >          > >
> >          >
> >
> >
> >
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141223/892c59a3/attachment-0001.html 

From stian at redhat.com  Mon Dec 29 02:13:59 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 29 Dec 2014 02:13:59 -0500 (EST)
Subject: [keycloak-user] Merry Christmas from the Keycloak team
In-Reply-To: <847608453.972436.1419078758134.JavaMail.yahoo@jws10029.mail.ne1.yahoo.com>
References: <CACQJ6LQjFesqxdieFFjZyQgHBTD5+dW4ZxnpHEBixz=2oW4hvw@mail.gmail.com>
	<847608453.972436.1419078758134.JavaMail.yahoo@jws10029.mail.ne1.yahoo.com>
Message-ID: <2043314637.1933851.1419837239753.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "prab rrrr" <prabhalar at yahoo.com>
> To: "Travis De Silva" <traviskds at gmail.com>, "Stian Thorgersen" <stian at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>, "keycloack-users" <keycloak-user at lists.jboss.org>
> Sent: Saturday, 20 December, 2014 1:32:38 PM
> Subject: Re: [keycloak-user] Merry Christmas from the Keycloak team
> 
> Hi Stian - Thanks for sharing your roadmap for 2015. Really looking forward
> to see identity brokering and? Openid Dynamic registration.?Do you have any
> plans to?support 1) FIDO specifications (UAT and U2F)?2) Any other NoSQL
> databases like Cassandra?

Most likely yes to FIDO, but most likely no to Cassandra or other DBs unless there's a lot of demand for it.

> Congratulations on a great product key cloak team and Happy holidays to all
> of you.
> Raghu
> ?      From: Travis De Silva <traviskds at gmail.com>
>  To: Stian Thorgersen <stian at redhat.com>
> Cc: keycloak dev <keycloak-dev at lists.jboss.org>; keycloack-users
> <keycloak-user at lists.jboss.org>
>  Sent: Tuesday, December 16, 2014 6:40 AM
>  Subject: Re: [keycloak-user] Merry Christmas from the Keycloak team
>    
> Congratulations and thank you to the entire KeyCloak team. This is a great
> project and wishing it gets better and better over the course of next year.
> Merry Christmas and Happy New Year to everyone.
> 
> 
> On Tue, Dec 16, 2014 at 10:38 PM, Stian Thorgersen <stian at redhat.com> wrote:
> 
> 2014 was the year of Keycloak! At least that was the case for us on the
> Keycloak team. In January we released the very first alpha of the project.
> The first stable release wasn?t out until September, but in return we added
> a lot more features as well as reaching a very high level of stability for a
> 1.0.
> 
> Since then we?ve delivered a number of security and bug fixes for 1.0, while
> continuing to bake in new exiting features for 1.1. We?re planning to do a
> stable release of 1.1 early in the New Year, which will bring SAML 2, much
> improved clustering and a number of new application adapters.
> 
> Not only have we managed to provide a feature rich and easy to use open
> source security solution, but we?ve also managed to build an awesome
> community around the project. We?ve had over 5000 downloads, over 2500
> commits from 32 contributors and our developer and user mailing lists are
> very active. Keycloak is already in use in production on a number of
> projects, in fact some has even used it in production since our first alpha
> release!
> 
> Our road-map for 2015 is not written in stone, but expect at least some of
> the following features to be delivered in 2015:
> 
> ? * Custom user profiles ? this will let you configure the attributes for a
> ? user profile, which should be visible on the registration screen and
> ? account management, as well as specify validation
> ? * Identity Brokering ? we?re adding support to authenticate with external
> ? Identity Providers via OpenID Connect, SAML 2.0 and Kerberos
> ? * Two-Factor Authentication ? currently we only support Google
> ? Authenticator or FreeOTP applications for two-factor authentication, but
> ? we plan to make it possible to add your own and provide some more out of
> ? the box
> ? * Client Accounts ? these will be special user accounts directly linked to
> ? a client, allowing a client to access services as itself not just
> ? on-behalf of users
> ? * Client Certificates ? support authentication of clients with certificates
> ? * Client Types ? at the moment we have applications and oauth clients, the
> ? main difference being oauth clients require users to grant permissions to
> ? roles. To simplify the admin console we plan to introduce a single unified
> ? view for clients and also introduce new types such as devices
> ? * Internationalization ? internationalization support for login and account
> ? management pages
> ? * SMS ? enable SMS to recover passwords, as a 2nd factor authentication
> ? mechanism and to be notified about events like login failures
> ? * OpenID Connect Dynamic Registration ?? allows clients to dynamically
> ? register with Keycloak. We?ll also look at passing the OpenID Connect
> ? Interop testing
> ? * Mapping of users and tokens ? custom mapping of user profiles from
> ? external identity stores and tokens from external Identity Providers
> 
> We also have ideas for some bigger features, but we?ll leave those as a
> surprise for 2015!
> 
> Finally, I?d like to wish everyone a Merry Christmas and a Happy New Year.
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
> 
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
> 
> 


From stian at redhat.com  Mon Dec 29 02:38:38 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 29 Dec 2014 02:38:38 -0500 (EST)
Subject: [keycloak-user] Undertow Bearer Token in Cookie
In-Reply-To: <CAPNq5vaYyYMfpvq=5DtnYLfsfN4oha+dT9CQj8r4mbRbz8ff-g@mail.gmail.com>
References: <CAPNq5vY2NO8RHE_C5=OSmtAEL_+0xYLudiY84M7goi4o+WmDbQ@mail.gmail.com>
	<1315224945.18004787.1418658552122.JavaMail.zimbra@redhat.com>
	<CAPNq5vYjeQhB0KFiPOzv6u+P-iuR5nV4W8SjfdHF3kvgpFKYcQ@mail.gmail.com>
	<1558343345.19574462.1418803517929.JavaMail.zimbra@redhat.com>
	<CAPNq5vb66FCTqwb_4Ui_kok4vFZXWbrUPV_mJ32triaM_j4p+w@mail.gmail.com>
	<CAPNq5vZdG2eZVy0tnC9Wv62+0mUocOn0cJSLECrHWo+uMuP1Uw@mail.gmail.com>
	<549837C0.400@redhat.com>
	<CAPNq5vaYyYMfpvq=5DtnYLfsfN4oha+dT9CQj8r4mbRbz8ff-g@mail.gmail.com>
Message-ID: <654211106.1940596.1419838718114.JavaMail.zimbra@redhat.com>

The JS adapter doesn't support this. You could drop using the JS adapter, instead use the WildFly/EAP adapter to secure the html files. As long as you're serving the html files and rest endpoints from the same WAR that'll work with the cookie approach.

----- Original Message -----
> From: "J?r?me Blanchard" <jayblanc at gmail.com>
> To: "Bill Burke" <bburke at redhat.com>, keycloak-user at lists.jboss.org
> Sent: Tuesday, 23 December, 2014 10:03:11 AM
> Subject: Re: [keycloak-user] Undertow Bearer Token in Cookie
> 
> Hi, by mentionning the servlet adapter, you mean the WAR configured using
> web.xml (server side) ? or the client servlet adapter ?
> 
> In our configuration we have a REST API prtoected using the WAR wildfly
> adapter (ensuring EJB auth propagation) and a JS client.
> 
> I tried using the configuration of cookie token store (
> "token-store": "cookie"
> ) in the wildfly adapter (server side) but no cookie is set in my HTML5/JS
> client and it seem no cookie is catched by the wildfly adapter...
> Did I missed something ?
> 
> Best regards, J?r?me.
> 
> Le Mon Dec 22 2014 at 16:24:58, Bill Burke < bburke at redhat.com > a ?crit :
> 
> 
> 
> Servlet adapter already does this.
> 
> * 1.0.x Keycloak attaches the token to the Http Session.
> * 1.1 Beta+ Keycloak adapter has an option to store the token in a
> cookie instead of the HttpSession.
> 
> On 12/18/2014 12:07 PM, J?r?me Blanchard wrote:
> > Hi all,
> > 
> > Is it possible to configure the servlet adapter to check presence of a
> > bearer token in a cookie instead of in a header ?
> > This question is about the download file usecase. If the bearer token
> > will be placed in a cookie by the javascript client at the same time
> > settnig the header, his will ensure that this cookie will be sent by the
> > navigator in the case of a download file or a <img> tag that would
> > happen outside of a XHR.
> > 
> > Thanks, Best Regards, J?r?me.
> > 
> > Le Wed Dec 17 2014 at 18:12:35, J?r?me Blanchard < jayblanc at gmail.com
> > <mailto: jayblanc at gmail.com >> a ?crit :
> > 
> > Hi Stian,
> > 
> > Thanks for your precisions, we have choose to implement the solution
> > of a time based password.
> > Using a ServletFilter and the Servlet 3.0 HttpRequest.login()
> > feature we're able to intercept token from query parameter and
> > propagate it to the JAAS stack. A dedicated LoginModule validate
> > this token to enforce principal in the EJB SecurityContext and,
> > according to this, our custom authorisation system is used ASIS
> > without the need to create a hook in the download operation.
> > This solution give the advantage to not interfer with the classic
> > OAuth authentication in case of using a XHR Header nor a RESTClient
> > that programmatically include the bearer token in the request header.
> > 
> > Thanks a lot for your support, Best Regards, J?r?me.
> > 
> > 
> > 
> > Le Wed Dec 17 2014 at 09:05:22, Stian Thorgersen < stian at redhat.com
> > <mailto: stian at redhat.com >> a ?crit :
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "J?r?me Blanchard" < jayblanc at gmail.com
> > <mailto: jayblanc at gmail.com >>
> > > To: "Stian Thorgersen" < stian at redhat.com
> > <mailto: stian at redhat.com >>
> > > Cc: keycloak-user at lists.jboss.org
> > <mailto: keycloak-user at lists. j boss.org >
> > > Sent: Tuesday, 16 December, 2014 5:51:37 PM
> > > Subject: Re: [keycloak-user] HTML5/JS and download URL.
> > > 
> > > Hi,
> > > 
> > > Thank you for your answer. Sorry for my lake of knowledge in
> > OAuth but
> > > speaking about generating a temporary token to include in the
> > link, what
> > > kind of token do you mean and what is the best way to do that
> > with Keycloak.
> > 
> > We don't have any support for this at the moment so you would
> > have to make it yourself. With regards to token all I mean is a
> > something temporary that allows the server to verify the user
> > has permissions to download the file.
> > 
> > For example the token could be the base64 encoded signature
> > (hmac, rsa or whatever you'd like) of userid,
> > timestamp/expiration and file-url. That way the server can
> > simply verify the signature on the server-side when the user is
> > trying to download the file and check that it matches.
> > 
> > > 
> > > Best regards, J?r?me.
> > > 
> > > 2014-12-15 16:49 GMT+01:00 Stian Thorgersen < stian at redhat.com
> > <mailto: stian at redhat.com >>:
> > > > 
> > > > 
> > > > 
> > > > ----- Original Message -----
> > > > > From: "J?r?me Blanchard" < jayblanc at gmail.com
> > <mailto: jayblanc at gmail.com >>
> > > > > To: keycloak-user at lists.jboss.org
> > <mailto: keycloak-user at lists. j boss.org >
> > > > > Sent: Monday, 15 December, 2014 3:13:06 PM
> > > > > Subject: [keycloak-user] HTML5/JS and download URL.
> > > > > 
> > > > > Hi all,
> > > > > We have a use case where an HTML5/Angular application is
> > calling a REST
> > > > > interface using keycloak for authentication SSO.
> > Everything works fine
> > > > until
> > > > > we need to download files or preview images (using <img>
> > tag). In both
> > > > case,
> > > > > this is the browser which perform the request on the REST
> > url and,
> > > > because
> > > > > of a specific XHR authentication putting the bearer token
> > in the
> > > > headers, a
> > > > > 'classic' browser request for downloading a file result in an
> > > > > UNauthenticated request because of unexisting bearer token.
> > > > > 
> > > > > We're minding if there is a best practice to handle this
> > case. We plan to
> > > > > include a dedicated token as a download request parameter
> > and to check
> > > > this
> > > > > particular query paramter programmatically in the
> > /download JAX-RS
> > > > > operation. What kind of token should have to put in the
> > query and is
> > > > there
> > > > > an already existing mechanism to catch such token in
> > jax-rs server-side
> > > > > operations nor programmatically ?
> > > > 
> > > > We actually had the same issue in our admin console as we
> > provide a
> > > > download option for the application config. AFAIK there's
> > two solutions:
> > > > 
> > > > * Generate a temporary token - basically what you're
> > suggesting. There's
> > > > two ways you can do this, always generate one and add it to
> > the link,
> > > > second is to use a redirect that only generates the token
> > on demand
> > > > * Use XHR to get the file, which allows setting the
> > Authorization header,
> > > > then use JavaScript to download
> > > > 
> > > > There's currently no direct support for this in Keycloak,
> > but it would be
> > > > interesting to add.
> > > > 
> > > > > 
> > > > > Thanks a lot for your support and so good work, Best
> > Regards, J?r?me.
> > > > > 
> > > > > ______________________________ _____________________
> > > > > keycloak-user mailing list
> > > > > keycloak-user at lists.jboss.org
> > <mailto: keycloak-user at lists. j boss.org >
> > > > > 
> > https://lists.jboss.org/__ mai lma__n/listinfo/keycloak- user
> > < https://lists.jboss.org/ mail man/listinfo/keycloak-user >
> > > > 
> > > 
> > 
> > 
> > 
> > ______________________________ _________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/ mailma n/listinfo/keycloak-user
> > 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> ______________________________ _________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/ mailma n/listinfo/keycloak-user
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user


From stian at redhat.com  Mon Dec 29 02:56:48 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 29 Dec 2014 02:56:48 -0500 (EST)
Subject: [keycloak-user] Is it possible to update users with the admin
 client
In-Reply-To: <CAJfT+OovZG0nsaFUcAE9NF36xBaOUwc2p5D6rviroDBnczN4hA@mail.gmail.com>
References: <CAJfT+OovZG0nsaFUcAE9NF36xBaOUwc2p5D6rviroDBnczN4hA@mail.gmail.com>
Message-ID: <1150479689.1946495.1419839808952.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Alexander Chriztopher" <alexander.chriztopher at gmail.com>
> To: keycloak-user at lists.jboss.org
> Sent: Friday, 19 December, 2014 7:36:05 PM
> Subject: [keycloak-user] Is it possible to update users with the admin client
> 
> Hi,
> 
> I would like to use the admin client to update a user in order to force him
> to change his password next time he logs in ?
> 
> So far i have failed miserably to do it so i was wondering if this is at all
> possible ?
> 
> This is basically what am doing :
> 
> Keycloak keycloak = Keycloak.getInstance(authServer, "example",
> "examples-admin-client", "password", "examples-admin-client", "password");
> RealmResource realm = keycloak.realm("example");
> UsersResource users = realm.users();
> List<UserRepresentation> users_ = users.search("", 0, 1000000); // This gets
> me all my users
> for (UserRepresentation user_ : users_) {
> if (user_.getUsername().equals("examples-admin-client")) {
> user_.setEmailVerified(true);
> }
> }
> RealmRepresentation realm_ = realm.toRepresentation();
> realm_.setUsers(users_);
> realm.update(realm_);
> 
> Does the method update of realm support users update ?

Here's the code to require a user with username "user1" to update password on next login:

    UserResource user = realm.users().get("user1");
    UserRepresentation userRep = user.toRepresentation();
    if (!userRep.getRequiredActions().contains("UPDATE_PASSWORD")) {
        userRep.getRequiredActions().add("UPDATE_PASSWORD");
        user.update(userRep);  
    }

> 
> Thanks for any help on this.
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

From stian at redhat.com  Mon Dec 29 03:11:05 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 29 Dec 2014 03:11:05 -0500 (EST)
Subject: [keycloak-user] How to add users in bulk
In-Reply-To: <CAJMEJTXQY2=14a3hEE8LducV7gxW_8xFYHret7KofC1O_dUNRg@mail.gmail.com>
References: <CAJMEJTXDvbGDYxvEmMz1pS3NWETadBWThxeLHeorC-0mOwLvHQ@mail.gmail.com>
	<640209939.19901720.1418821306427.JavaMail.zimbra@redhat.com>
	<549254E2.8040902@redhat.com>
	<CAJMEJTXQY2=14a3hEE8LducV7gxW_8xFYHret7KofC1O_dUNRg@mail.gmail.com>
Message-ID: <671052063.1949546.1419840665134.JavaMail.zimbra@redhat.com>



----- Original Message -----
> From: "Hubert Przybysz" <h.p.przybysz at gmail.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-user at lists.jboss.org
> Sent: Thursday, 18 December, 2014 10:56:20 AM
> Subject: Re: [keycloak-user] How to add users in bulk
> 
> Thanks both for quick responses.
> 
> I have a large number of users I want to migrate from another system to
> keycloak. I could, as Bill suggests, write a piece of code that reads the
> users from the existing system and adds them to keycloak using the admin
> REST API. While not difficult, it takes a bit of work/time.
> 
> I looked earlier at export-import but understood that in order to import
> users I had to first export them, meaning that they must have been already
> provisioned in keycloak, correct? If that's not true, perhaps I can add my
> users to the import file in some way ?

Just double checked the approach I suggested. I thought we had made it possible to import users into an existing realm, but that's not the case. You have to create the whole realm. It's still possible to do it this way, first create the realm and add an example user. Stop the server and run it again with:

  bin/standalone.sh -Dkeycloak.migration.action=export -Dkeycloak.migration.provider=dir -Dkeycloak.migration.realmName=<realm name> -Dkeycloak.migration.dir=<dir name>

* Replace <realm name> and <dir name>

In <dir name> you should then get a few json files. You can then update <realm name>-users-0.json to add the users you want to import.

As Bill points out the admin client could be a good alternative approach. We also have a Java client that makes it simpler to use. Have a look at the admin-client example.

> 
> On Thu, Dec 18, 2014 at 5:15 AM, Bill Burke < bburke at redhat.com > wrote:
> 
> YOu can also use the admin REST API.
> 
> On 12/17/2014 8:01 AM, Stian Thorgersen wrote:
> > You can import users from json files, see
> > http://docs.jboss.org/keycloak/docs/1.1.0.Beta2/userguide/html/export-import.html
> > 
> > ----- Original Message -----
> >> From: "Hubert Przybysz" < h.p.przybysz at gmail.com >
> >> To: keycloak-user at lists.jboss.org
> >> Sent: Sunday, 14 December, 2014 5:36:49 PM
> >> Subject: [keycloak-user] How to add users in bulk
> >> 
> >> Hi,
> >> Is there an easy way of adding a large number users to a realm, where
> >> usernames and initial passwords follow a certain pattern?
> >> Best regards / Hubert.
> >> 
> >> _______________________________________________
> >> keycloak-user mailing list
> >> keycloak-user at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-user
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> > 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

From stian at redhat.com  Mon Dec 29 03:18:05 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Mon, 29 Dec 2014 03:18:05 -0500 (EST)
Subject: [keycloak-user] We're sorry ... Unknown code,
 please login again through your application.
In-Reply-To: <CAJfT+Ooxn+aRwfxp8DUyhMf+Jw_+R9Ld-01+pO1P+CAYYKJ=GA@mail.gmail.com>
References: <CAJfT+Ooxn+aRwfxp8DUyhMf+Jw_+R9Ld-01+pO1P+CAYYKJ=GA@mail.gmail.com>
Message-ID: <839214297.1949973.1419841085143.JavaMail.zimbra@redhat.com>

This is caused by the "code" on the login page not being valid any more after the user has clicked the reset password link in the email. It's not very elegant so please create a JIRA and we'll try to improve it.

----- Original Message -----
> From: "Alexander Chriztopher" <alexander.chriztopher at gmail.com>
> To: keycloak-user at lists.jboss.org
> Sent: Thursday, 18 December, 2014 10:57:03 AM
> Subject: [keycloak-user] We're sorry ... Unknown code,	please login again through your application.
> 
> Hi All,
> 
> Am having the following behaviour within keycloak :
> 
> # 1 / Open my application home page which brings me to the keycloak login
> page;
> # 2 / Click on Forgot Password then enter my login and validate. Keep this
> page open in my browser -this page contains a link : back to login;
> # 3 / Open the received mail and click on the link to reset password which
> opens a new tab in my browser;
> # 4 / Switch to the previous tab where i left the login page open and click
> on the link back to login;
> # 5 / A new page opens with the message : We're sorry ... Unknown code,
> please login again through your application.
> 
> Could any one tell me why am getting this ?
> 
> Thanks for your help.
> 
> 
> 
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

From alexander.chriztopher at gmail.com  Mon Dec 29 04:53:12 2014
From: alexander.chriztopher at gmail.com (Alexander Chriztopher)
Date: Mon, 29 Dec 2014 10:53:12 +0100
Subject: [keycloak-user] Merry Christmas from the Keycloak team
In-Reply-To: <2043314637.1933851.1419837239753.JavaMail.zimbra@redhat.com>
References: <CACQJ6LQjFesqxdieFFjZyQgHBTD5+dW4ZxnpHEBixz=2oW4hvw@mail.gmail.com>
	<847608453.972436.1419078758134.JavaMail.yahoo@jws10029.mail.ne1.yahoo.com>
	<2043314637.1933851.1419837239753.JavaMail.zimbra@redhat.com>
Message-ID: <CAJfT+Opoqr=4P7WKiWznwRtLM4+Uyw2yQ0M6fXuHdTQB7=gkjQ@mail.gmail.com>

Happy new year to everyone and congrats to all the keycloak team for the
great product and for the great job. The mailing list is really one of the
best i have seen in quality, responsiveness and openess.

Thank you guys and keep going ..


On Mon, Dec 29, 2014 at 8:13 AM, Stian Thorgersen <stian at redhat.com> wrote:

>
>
> ----- Original Message -----
> > From: "prab rrrr" <prabhalar at yahoo.com>
> > To: "Travis De Silva" <traviskds at gmail.com>, "Stian Thorgersen" <
> stian at redhat.com>
> > Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>, "keycloack-users" <
> keycloak-user at lists.jboss.org>
> > Sent: Saturday, 20 December, 2014 1:32:38 PM
> > Subject: Re: [keycloak-user] Merry Christmas from the Keycloak team
> >
> > Hi Stian - Thanks for sharing your roadmap for 2015. Really looking
> forward
> > to see identity brokering and  Openid Dynamic registration. Do you have
> any
> > plans to support 1) FIDO specifications (UAT and U2F)?2) Any other NoSQL
> > databases like Cassandra?
>
> Most likely yes to FIDO, but most likely no to Cassandra or other DBs
> unless there's a lot of demand for it.
>
> > Congratulations on a great product key cloak team and Happy holidays to
> all
> > of you.
> > Raghu
> >        From: Travis De Silva <traviskds at gmail.com>
> >  To: Stian Thorgersen <stian at redhat.com>
> > Cc: keycloak dev <keycloak-dev at lists.jboss.org>; keycloack-users
> > <keycloak-user at lists.jboss.org>
> >  Sent: Tuesday, December 16, 2014 6:40 AM
> >  Subject: Re: [keycloak-user] Merry Christmas from the Keycloak team
> >
> > Congratulations and thank you to the entire KeyCloak team. This is a
> great
> > project and wishing it gets better and better over the course of next
> year.
> > Merry Christmas and Happy New Year to everyone.
> >
> >
> > On Tue, Dec 16, 2014 at 10:38 PM, Stian Thorgersen <stian at redhat.com>
> wrote:
> >
> > 2014 was the year of Keycloak! At least that was the case for us on the
> > Keycloak team. In January we released the very first alpha of the
> project.
> > The first stable release wasn?t out until September, but in return we
> added
> > a lot more features as well as reaching a very high level of stability
> for a
> > 1.0.
> >
> > Since then we?ve delivered a number of security and bug fixes for 1.0,
> while
> > continuing to bake in new exiting features for 1.1. We?re planning to do
> a
> > stable release of 1.1 early in the New Year, which will bring SAML 2,
> much
> > improved clustering and a number of new application adapters.
> >
> > Not only have we managed to provide a feature rich and easy to use open
> > source security solution, but we?ve also managed to build an awesome
> > community around the project. We?ve had over 5000 downloads, over 2500
> > commits from 32 contributors and our developer and user mailing lists are
> > very active. Keycloak is already in use in production on a number of
> > projects, in fact some has even used it in production since our first
> alpha
> > release!
> >
> > Our road-map for 2015 is not written in stone, but expect at least some
> of
> > the following features to be delivered in 2015:
> >
> >   * Custom user profiles ? this will let you configure the attributes
> for a
> >   user profile, which should be visible on the registration screen and
> >   account management, as well as specify validation
> >   * Identity Brokering ? we?re adding support to authenticate with
> external
> >   Identity Providers via OpenID Connect, SAML 2.0 and Kerberos
> >   * Two-Factor Authentication ? currently we only support Google
> >   Authenticator or FreeOTP applications for two-factor authentication,
> but
> >   we plan to make it possible to add your own and provide some more out
> of
> >   the box
> >   * Client Accounts ? these will be special user accounts directly
> linked to
> >   a client, allowing a client to access services as itself not just
> >   on-behalf of users
> >   * Client Certificates ? support authentication of clients with
> certificates
> >   * Client Types ? at the moment we have applications and oauth clients,
> the
> >   main difference being oauth clients require users to grant permissions
> to
> >   roles. To simplify the admin console we plan to introduce a single
> unified
> >   view for clients and also introduce new types such as devices
> >   * Internationalization ? internationalization support for login and
> account
> >   management pages
> >   * SMS ? enable SMS to recover passwords, as a 2nd factor authentication
> >   mechanism and to be notified about events like login failures
> >   * OpenID Connect Dynamic Registration ?  allows clients to dynamically
> >   register with Keycloak. We?ll also look at passing the OpenID Connect
> >   Interop testing
> >   * Mapping of users and tokens ? custom mapping of user profiles from
> >   external identity stores and tokens from external Identity Providers
> >
> > We also have ideas for some bigger features, but we?ll leave those as a
> > surprise for 2015!
> >
> > Finally, I?d like to wish everyone a Merry Christmas and a Happy New
> Year.
> >
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
> >
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
> >
> >
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141229/2c4cb619/attachment-0001.html 

From stian at redhat.com  Tue Dec 30 07:31:44 2014
From: stian at redhat.com (Stian Thorgersen)
Date: Tue, 30 Dec 2014 07:31:44 -0500 (EST)
Subject: [keycloak-user] HTTP 403 Forbidden on Keycloak.getInstance
In-Reply-To: <CAJfT+Oq-x2f3Wfz1mvUR=YqE+0hPXgHUbemM7yUyHVHdWFb0nA@mail.gmail.com>
References: <CAJfT+Oq-x2f3Wfz1mvUR=YqE+0hPXgHUbemM7yUyHVHdWFb0nA@mail.gmail.com>
Message-ID: <398767687.2248733.1419942704559.JavaMail.zimbra@redhat.com>

Did you enable 'Direct Grant API' for your realm? If not open the admin console click on the realm -> settings -> login and toggle 'Direct Grant API' to ON

----- Original Message -----
> From: "Alexander Chriztopher" <alexander.chriztopher at gmail.com>
> To: keycloak-user at lists.jboss.org
> Sent: Friday, 19 December, 2014 4:06:56 PM
> Subject: [keycloak-user] HTTP 403 Forbidden on Keycloak.getInstance
> 
> Hi,
> 
> I have a realm with an application called : examples-admin-client and would
> like to use it to manage my realm but i get an error :
> javax.ws.rs.ClientErrorException: HTTP 403 Forbidden every time i make the
> following call :
> 
> Keycloak keycloak = Keycloak.getInstance(authServer, "realm-name", "User1",
> "password", "examples-admin-client",
> "a5890cdf-e1df-40c0-9d50-26ad2f7badde");
> 
> When i try to do the same thing with the example realm (i use the json
> example-realm.json provided by the keycloak project) this works nicely
> actually !
> 
> Btw, i can successfully login with the user : User1 with that password.
> 
> This is the json for my realm :
> 
> {
> "realm": "realm-name",
> "realm-public-key":
> "MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCxwUIE6W3BZYlSxDPpwkknb2ObnrEsGMUJGy3HfNEfkfu9rcY5bxkllLsW32KlR78++xtuI11IE2nuh6nJmUsIKMb55Ez9n7/E9kPmSF6lxavZlQY0HfBnR3ZWgzsoUUz4n7pOhmqHIAGXeuxnMDQ5/upwcolFIZRor1v7oT/H8QIDAQAB",
> "auth-server-url": " http://localhost:8080/auth ",
> "ssl-required": "none",
> "resource": "examples-admin-client",
> "credentials": {
> "secret": "a5890cdf-e1df-40c0-9d50-26ad2f7badde"
> }
> }
> 
> Thanks for any help on this one !
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

From alexander.chriztopher at gmail.com  Tue Dec 30 12:30:04 2014
From: alexander.chriztopher at gmail.com (Alexander Chriztopher)
Date: Tue, 30 Dec 2014 18:30:04 +0100
Subject: [keycloak-user] HTTP 403 Forbidden on Keycloak.getInstance
In-Reply-To: <CAJfT+OrzfNAc+3a7LA+d3J6mhBcnKzKCKnXfbeN1hm_94YZ-eQ@mail.gmail.com>
References: <CAJfT+Oq-x2f3Wfz1mvUR=YqE+0hPXgHUbemM7yUyHVHdWFb0nA@mail.gmail.com>
	<398767687.2248733.1419942704559.JavaMail.zimbra@redhat.com>
	<CAJfT+OrzfNAc+3a7LA+d3J6mhBcnKzKCKnXfbeN1hm_94YZ-eQ@mail.gmail.com>
Message-ID: <CAJfT+OrN0n=OXaMsCAHvTeg2=ADYhKtjDNj09DuFdF5QBV=s_Q@mail.gmail.com>

ok, i had to go to : User1 | ROLE MAPPING | APPLICATION ROLES | select the
application : realm-management | add the role : realm-admin to my user and
now it is working !

Questions :

# 1 / Why is the application : realm-management involved in this ? In the
example am using the application : examples-admin-client which is
completely different !
# 2 / When someone needs to administer a realm via the admin client which
client id do you recommend using ? do we have to create a new client id (i
mean application) or should we use some application created by default
within the realm such as : realm-management on or : security-admin-console ?


On Tue, Dec 30, 2014 at 6:08 PM, Alexander Chriztopher <
alexander.chriztopher at gmail.com> wrote:

> Yes that option was activated for the realm !!
>
> On Tue, Dec 30, 2014 at 1:31 PM, Stian Thorgersen <stian at redhat.com>
> wrote:
>
>> Did you enable 'Direct Grant API' for your realm? If not open the admin
>> console click on the realm -> settings -> login and toggle 'Direct Grant
>> API' to ON
>>
>> ----- Original Message -----
>> > From: "Alexander Chriztopher" <alexander.chriztopher at gmail.com>
>> > To: keycloak-user at lists.jboss.org
>> > Sent: Friday, 19 December, 2014 4:06:56 PM
>> > Subject: [keycloak-user] HTTP 403 Forbidden on Keycloak.getInstance
>> >
>> > Hi,
>> >
>> > I have a realm with an application called : examples-admin-client and
>> would
>> > like to use it to manage my realm but i get an error :
>> > javax.ws.rs.ClientErrorException: HTTP 403 Forbidden every time i make
>> the
>> > following call :
>> >
>> > Keycloak keycloak = Keycloak.getInstance(authServer, "realm-name",
>> "User1",
>> > "password", "examples-admin-client",
>> > "a5890cdf-e1df-40c0-9d50-26ad2f7badde");
>> >
>> > When i try to do the same thing with the example realm (i use the json
>> > example-realm.json provided by the keycloak project) this works nicely
>> > actually !
>> >
>> > Btw, i can successfully login with the user : User1 with that password.
>> >
>> > This is the json for my realm :
>> >
>> > {
>> > "realm": "realm-name",
>> > "realm-public-key":
>> >
>> "MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCxwUIE6W3BZYlSxDPpwkknb2ObnrEsGMUJGy3HfNEfkfu9rcY5bxkllLsW32KlR78++xtuI11IE2nuh6nJmUsIKMb55Ez9n7/E9kPmSF6lxavZlQY0HfBnR3ZWgzsoUUz4n7pOhmqHIAGXeuxnMDQ5/upwcolFIZRor1v7oT/H8QIDAQAB",
>> > "auth-server-url": " http://localhost:8080/auth ",
>> > "ssl-required": "none",
>> > "resource": "examples-admin-client",
>> > "credentials": {
>> > "secret": "a5890cdf-e1df-40c0-9d50-26ad2f7badde"
>> > }
>> > }
>> >
>> > Thanks for any help on this one !
>> >
>> > _______________________________________________
>> > keycloak-user mailing list
>> > keycloak-user at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141230/f7e80070/attachment.html